Skip to main content

SREM

Version

Look for the current version via the link in the table at the message-type introduction page

caution

As of mid november 2024, Mobilidata has changed version regarding AMQP headers (version 0.9 to 1.0). This is caused by changes in the C-Roads (TF4 spec release 2.1.0) specification.

Description​

The Signal Request Message (SRM) is a message sent by a Dedicated Short Range Communications (DSRC) equipped entity ( such as avehicle) to the RoadSide Unit (RSU) in a signalized intersection. It is used for either a priority signal request or a pre-emption signalrequest depending on the way each request is set. Each request defines a path through the intersection which is desired in terms oflanes and approaches to be used. Each request can also contain the time of arrival and the expected duration of the service. Multiplerequests to multiple intersections are supported. The requestor identifies itself in various ways (using methods supported by the RequestorDescription data frame), and its current speed, heading and location can be placed in this structure as well. The specific request for service is typically based on previously decoding and examining the list of lanes and approaches for that intersection (sent in MAP messages). The outcome of all of the pending requests to a signal can be found in the Signal Status Message (SSM), and maybe reflected in the SPAT message contents if successful.

The SRM message is used for either a priority signal request or a pre-emption signal request in the form of:

  • SRM
    Used fo priority requests as described above.
  • SRM0
    Used for vehicles, not using priority requests by nature, indicating which direction the vehicle takes on the iTLC.
  • SRM1
    Specifly meant for usage by active road users, indicating a complex direction (e.g. first the byciclepath straighttrough and then to the left)

Usage​

The priority requests are similar to the flow diagram in the figure:

Point in timeIVRITo/from vehicleVehicleRemarks
T0MAPtoiVRI information based on location, in order to determine approach
T+nfromSRM initiatorStarting Prio request sequence
T+n+1SSMtoAcknowledge the request is received and yes/no action is undertaken
T+ofromSRM updatePrio request update if necessary (e.g. different time to arrive at iVRI)
T+oSSMto
T+pfromSRM cancelPassing the stopline of the iVRI means the end of the request

Depending on the iVRI where the request is sent to, the iVRI will switch to green immediately or uses the “Esitmated Time of Arrival” for green. For this, it is advised to wait with the request until the map area of the iVRI is entered, or that the vehicle is in short distance. Since the behaviour of different iVRI’s is dependent on local authorities, no strict rules for filling the messages can be provided.

Design rules:

  • Update messages can be sent in an interval or when there is a change in situation.
  • If, for any reason, the initiating SRM is missed by the iVRI, the first received SRM is assumed to be the initiator.
  • SRM cancel message must be sent after crossing the stop-line of the entered approach.
  • The CAM messages of the vehicle are sent independently from the SRM messages.
  • Not all iVRI’s need a valid in the MAP fitting CAM message from the SRM sending vehicle to react on the request.

Estimated Time of Arrival (ETA)​

When the vehicle is not in the proximity (within the iTLC geofence) of the iTLC for which the priority request is made, the SRM have a mandatory filled-in ETA, based on the vehicles own speed, distance and expectation when arriving at the stop-line of the approach-lane of the iTLC.
Within the iTLC geofence, as drawn by the lane traces in the corresponding MAP message, the SRM has to be accompanied by CAM. The latter with an interval of one per second. The iTLC will then calculate the expected time of arrival, taking the signalgroup switching into account.

Priority Validator​

Before a SRM from a service provider is sent to the TLEX, the content will be checked against the rules defined in the Priority Validator. These rules are set by the road-administrator to obtain the most logical and optimal local iTLC handling. In the case of not valid content, the priority validator will return a SSM with status rejected and will not deliver the SRM at the TLEX.

caution

Data packages are encoded/decoded to ASN.1 standard, using the 'UPER' encoding rules.

Attributes​

{
    "Header": {
    "ProtocolVersion": 2,
    "MessageID": 9,
    "StationID": 120399645
  },
    "Srm": {
    ...
    }
}

The stationID in the message header is a combination your unique prefix service provider for the first 6 bits and the vehicle ID. See the onboarding documentation for more information on requesting your unique CROW prefix service provider.

info

An SREM message has 2 big objects, a Requests object and a Requestor object.

Requests​

The Requests object contains a list of SignalRequestPackage objects. Each SignalRequestPackage object contains a Request object and metadata.

"Srm": {
  ...
  "Requests":{
  "SignalRequestPackage":[
        {
          "Request": {
            "Id": {
              "Region": 4001,
              "Id": 811
            },
            "RequestID": 2,
            "Requesttype": 1,
            "InboundLane": {
              "Lane": 0,
              "Approach": 3,
              "Connection": 0
            },
            "OutboundLane": null,
            "Regional": null
          },
          ...
  ]
  }
}

The Id contains info on the intersection to which the request is relevant. The RequestID provides a unique link to the SSEM. The Requesttype indicates if a request is new, update or cancelation.

RequestTypes (extract from Dutch Profile)

  • 1: New
  • 2: Update
  • 3: Cancel
"Srm": {
  ...
  "Requests":{
  "Requestor":{
    ...
    "Type":{
      ...
      "Role": 6,
      "Subrole": 5,
      "Request": 12,

      ...
    }

  }
  }
}

The weight of the request is given in the Requestor.Type object. The Role attribute is used to define the type of basic vehicle role and the subrole attribute is used to define the type of vehicle subrole. The Request attribute is used to enrich information provided by the basic vehicle rol. The Request field is value that is defined by the road authority and received from the Priority Broker Configurator. This value indicates the request importance level and can be set differently by the road authority for every traffic light individually.

Role (extract from Dutch Profile)

  • 0: default
  • 1: public transport
  • 3: dangerous goods
  • 6: emergency
  • 8: agriculture
  • 10: military

Subrole (extract from Dutch Profile)

  • 0: unknown
  • 1: bus
  • 2: tram
  • 5: emergency

Example​

An extended description of the SREM ASN.1 can be found here.

SREM AMQP Header example
{
    "id": ",4001-1371,",
    "latitude": "51.22016505",
    "quadTree": ",120202130223030112,",
    "longitude": "4.35565284",
    "custom-mobilidata-timestamp": "1712750496212",
    "messageType": "SREM",
    "publisherId": "BE00005",
    "publicationId": "BE00005:SREM_02",
    "baselineVersion": "2.1.0",
    "custom-mobilidata-baselineVersion": "D"
    "dtapEnvironment": "production",
    "protocolVersion": "SREM:1.3.1",
    "originatingCountry": "BE",
    "shardId": "1",
    "shardCount": "1"
}
SREM Message example
0209072d271d733f0631cd0103043e840cac089367e0c8e927041cb49c75819718a82e9874db6483a8adc38ad8862c983372e5b346a0
Tags:
Last updated on by Jasper De Keukelaere (imec)