Mobilidata Profile v1.0.0
Introduction
C-ROADS is a joint initiative of several European member states in which a cross-border standardization and harmonization of C-ITS related services is developed. From this working group, various standardizations and concepts are established to ensure this interoperability, which can be found on the website or via special webpage.
Given the architectural setup and purpose of the Mobilidata ecosystem, the implementation will follow the guidelines from TF4: C-ITS IP Based Interface Profile and consequently set up an Interchange (network) that complies with the guidelines and message specifications described in this profile.
However, these specifications are not sufficiently comprehensive to support all proposed use cases. For example, in C-ROADS there is currently no explicit attention paid to the delivery of messages to specific actors in the interchange network (no uni-cast, but only geocast). Also, the Mobilidata Interface (MI), an extension of the C-ROADS Basic Interface (BI), contains additional pyload types that are not specified in the C-ROADS working group.
Finally, Mobilidata also has an additional requirement that iTLC communication and protocols follow the Dutch Profile as elaborated from the Talking Traffic Program and further being actively developed by Mobilidata and Talking Traffic together. This profile differs from the C-ROADS standard in certain aspects, more about this later.
To meet these aspects of the Mobilidata ecosystem, a specific profile is defined that all interchanges and local C-ITS actors must meet in order to be able to connect to the Mobilidata ecosystem.
In what follows, the various extensions to the C-ROADS TF4 Profile are elaborated and described in their context. The specifications as established down here are therefore an official part of the Mobilidata Interface specification.
The Mobilidata profile version 1.0.0 has been created to be in line with the latest C-ROADS 2.1 specifications. The AMQP properties will therefore contain a few minor adjustments to comply with all the provisions in the TF4 Profile of C-ROADS 2.1
Mobilidata Profile
The mobilidata ecosystem works in full compliance with the specifications of the C-ROADS provisions in working group TF4 to ensure international compatibility. However, the ecosystem goes a step further than C-ROADS and adds additional application headers to support mobilidata-specific functionalities. Examples of this are: unicasting to road infrastructure objects, sharding of producers to be able to perform load scaling, sending Road User Feedback,...
Common application headers
The following table lists the common application headers that need to be filled in for each possible message type. Specifically, the application properties in table must be filled in for all DENM, IVI, SPATEM, MAPEM, SREM, SSEM, CAM and DATEX2 messages.
| Name | Type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| publisherId | String | A two-letter country code (based on ISO 3166-1 alpha-2) and a numerical identifier (value between 0 and 16383 including leading zeroes) based on ISO 14816 (same as used for providerIdentifier in IVIM). If you do not have an ISO 14816 identifier, you can contact your local interchange provider to get a temporary code to be used. E.g. "NO00001", "SE15608". | M | M | No changes |
| publicationId | String | Concatenation of publisherId and a unique identifier for the dataset/publication with a ":" between, e.g. "DE15608:IVIM_BERLIN_067" or "NO73944:679ABX92". This property was already used in practice in v0.9. | O | M | New official addition. |
| originatingCountry | String | Country code (based on ISO 3166-1 alpha-2) where the payload message is created | M | M | No changes |
| protocolVersion | String | Represent the version of the standard used to create the message. E.g. "DENM:1.2.2" "DATEX2:2.3" | M | M | No changes |
| serviceType | String | Comma separated list starting and ending with a comma. Acronym of C-ITS use case(s) defined in latest version of Common C-ITS Service and Use Case Definitions TF2 document of C-ROADS. E.g. ",HLN-RLX," or ",SI-GLOSA,SI-SPTI," | O | O | Breaking changes: changed from a single string to a comma delimited list of strings |
| baselineVersion | String | The baseline version indicates which release of the C-Roads specifications were used to create the C-ITS message. E.g. "2.1.0" | O | M, set to 2.1.0 | New addition |
| messageType | String | This is the type of the Published Message. E.g. "DENM" "DATEX2". Valid types are: DENM, IVIM, SPATEM, MAPEM, SREM, SSEM, CAM, DATEX2 | M | M | No changes |
| latitude | floatDecimal | Latitude of the event published; for DENM (eventPosition) and for IVI and SPATEM/MAPEM/SSEM/SREM (referencePosition) according to WGS 84/EPSG:4326 | O | M | No changes |
| longitude | floatDecimal | Longitude of the event published; for DENM (eventPosition) and for IVI and SPATEM/MAPEM/SSEM/SREM (referencePosition) according to WGS 84/EPSG:4326 | O | M | No changes |
| quadTree | String | Relevant spatial index location of the C-ITS message. In order to specify a larger area for the message, a set of quadTree values or a higher zoom level must be provided from the message producer. The minimum length for each quadTree is 18 when publishing. If a larger area is needed, you need to chain multiple quadTree values together, separated by a comma. The property needs to start and end with a comma. E.g., ,202320120232120101, (single value) or ,202320120232120101,202320120232120102,202320120232120103, (multiple values chained) | M | M | No changes |
| shardId | Integer | The shard number of the current message if sharding is enabled for the capability for the message. The id starts at 1 and the highest id is equal to the shardCount. | O | O | New addition |
| shardCount | Integer | Defines the amount of shards for the capability | O | O | New addition |
| custom-mobilidata-timestamp | Long | Timestamp set by the client when sending the message in UNIX time (Epoch time). May be used to calculate latency over the interchange. The property needs to start and end with a comma. | / | O | Changed property name to add custom-mobilidata prefix. All regional extensions now need to use this prefix for its own properties |
| custom-mobilidata-baselineVersion | String | The baseline version indicates which version of the Mobilidata standard needs to be adhered to when processing the incoming or outgoing messages. For DENM, IVI, and DATEXII messages, the baseline version relates to the Mobilidata baseline specification version. Current baseline version will be "1.0.0". CAM, SPATEM, MAPEM, SREM, and SSEM messages will use the baselineVersion header to indicate which Dutch Profile version is used by the underlying road infrastructure object. This version identifier should be in line with the versions used in the UDAP system administration API for Talking Traffic NL. Currently, only the "consolidation baseline" is supported in Mobilidata. This means that the baselineVersion will be set to "D" for CAM, SPATEM, MAPEM, SREM, and SSEM messages. | Non-existent in C-ROADS, custom header | M, set to "1.0.0" for DENM, IVI, and DATEXII messages. Set to "D" for CAM, SPATEM, MAPEM, SREM, and SSEM messages. | Changed property name to add custom-mobilidata prefix. Also made mandatory. |
| custom-mobilidata-publisherType | String | The publisherType allows the Mobilidata interchange network to route messages to specific actors in the ecosystem. Mandatory for Public Information actors in the ecosystem, optional for service provider actors. Possible values are: - PIP - Service Provider | Non-existent in C-ROADS, custom header | O | Changed property name to add custom-mobilidata prefix. |
| custom-mobilidata-dtapEnvironment | String | Capability to indicate the dtap environment in which the messages are produced. Possible values are: - Development - Test - Acceptance - Production | Non-existent in C-ROADS, custom header | M | Changed property name to add custom-mobilidata prefix. |
| custom-mobilidata-heading | Float | The driving direction of the vehicle 0-365 degrees. The heading is passed to indicate the driving direction on feedback for point locations. | / | O | Changed property name to add custom-mobilidata prefix. |
| custom-mobilidata-usage | String | Mobility backend providers can indicate how the message can be interpreted. Possible values are: - feedback-new-raw - feedback-new-aggregated - feedback-existing-raw - feedback-existing-aggregated | Non-existent in C-ROADS, custom header | O | Changed property name to add custom-mobilidata prefix. |
| custom-mobilidata-useCase | Integer | The use-case number for which the message is destined. This number is used for interchange governance purposes of the interchange and should always be set by every publishing actor that publishes one of the mandatory message types. This means in typical cases: the PIP and service providers providing road user feedback messages. | Non-existent in C-ROADS, custom header | Mandatory for following message types: DENM, IVI, DATEX2. Optional for following message types: SPLASH, MAP, CAM, SREM, SSEM |
Table 1: Common Application headers for Mobilidata Profile of C-ROADS BI
The following tables list the message type dependent application properties that must be included with the AMQP messages when they are produced. It is possible to filter on all application properties as a subscriber by using a JMS selector. (see HYB_066/2 of C-ROADS TF4 "C-ITS IP Based Interface Profile")
DENM specific application headers
| Name | Type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| causeCode | Integer | CauseCode from ETSI_EN_302_637-3. For cancellation DENMs this property shall be set to -1 (negative one). | M | M | Changed from string to integer. Cancellation DENMs now also need to have causeCode -1 which means setting JMS selectors on causeCode will no longer work as before. |
| subCauseCode | Integer | subCauseCode from ETSI_EN_302_637-3. For cancellation DENMs this property shall be set to -1 (negative one). | M | O | Changed from string to integer. Cancellation DENMs now also need to have subCauseCode -1 which means setting JMS selectors on subCauseCode will no longer work as before. |
| custom-mobilidata-vehicleType | String | Additional vehicleType information to overcome the limitations of the DENM standard. This field can optionally be used to define more granular vehicle types for mobilidata use-cases UC3/UC6/UC7/UC24. Possible values are: ambulance, fireBrigade, police, customs, towService, roadsideAssistance, trafficGuard, gritterService, impactAttenuator, mower | Non-existent in C-ROADS, custom header | O | Changed property name to add custom-mobilidata prefix. All regional extensions now need to use this prefix for its own properties. |
| custom-mobilidata-alertCCodes | Integer | Additional detailed event information to overcome the limitations of the DENM cause and subcause codes. The alertCCodes follow the ISO 148192 specifications. | Non-existent in C-ROADS, custom header | O | Changed property name to add custom-mobilidata prefix. All regional extensions now need to use this prefix for its own properties. |
Table 2: DENM specific application headers
IVI specific application headers
| Name | Type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| iviType | String | Comma separated list starting and ending with a comma, e.g. ",1," (single value) or ",1,0,2," (multiple values chained) as an IVIM may contain more than one iviType | O | O | No changes |
| iconCategoryCode | String | The ISO 14823 pictogramCategoryCode is a combined numeral value (nature and serialNumber) referring to a specific sign of the ISO 14823 sign catalogue, e.g. 557 = Maximum speed limit. Either a single numerical value (e.g. 557) or a comma separated list (e.g. 557,559,612) of numerical values as an IVIM may contain more than one pictogramCategoryCode | O | O | No changes |
| iviContainer | String | All valid IviContainer abbreviations in the ISO 19321 standard starting and ending with a comma, e.g. ",giv," or ",rcc," or ",tc," or ",avc," (single values) or comma separated combinations of that, e.g. ",giv,tc,avc," (multiple values chained) | O | O | No changes |
| custom-mobilidata-dynamicSignType | String | Can either be "zone30" or "matrix". Using this field, the service provider can identify which IVI messages are matrix signs above highways or which ones are dynamic zone30 signs. This field is also used in the interchange governance to only supply matrix signs or zone30 signs. | Non-existent in C-ROADS, custom header | M | No changes |
Table 3: IVI specific application headers
Datex2 specific application headers
| Name | Type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| custom-mobilidata-publisherName | String | This is the identifier for the datex message distributer. Obtained from the nationalIdentifier section of the datex document. | Non-existent in C-ROADS, custom header | M, mandatory in case of DATEX2 message type | Changed property name to be in line with the C-ROADS 2.1 TF4 specifications |
| custom-mobilidata-publicationType | String | Publication type - only one value of xsi:type of the PayloadPublication element. Possible values are: - GenericPublication - SituationPublication | Non-existent in C-ROADS, custom header | M, mandatory in case of DATEX2 message type | Changed property name to be in line with the C-ROADS 2.1 TF4 specifications |
| custom-mobilidata-publicationSubType | String | Every Payload publication comes with a sub type. This property should contain a list of the element types in the datex payload separated by a comma (","). The string should start with a comma and end with a comma, and contain no spaces or other white space characters. E.g: ,MaintenanceWorks,WeatherRelatedRoadConditions,MeasurementSiteRecord,VmsUnitRecord,parkingStatusPublication,parkingTablePublication, | Non-existent in C-ROADS, custom header | O | Changed property name to add custom-mobilidata prefix. |
Table 4: Datex2 specific application headers
Sharding
Some data streams require in-order delivery of messages. For high-volume data flows, horizontal scaling may be required at the interchange level. In this way, a theoretically infinite scaling of the interchange network is possible. To support this scaling, a sharding mechanism is implemented in release 2.1.0 of C-Roads so that actors can distribute deliveries and subscriptions across multiple endpoints without compromising in-order delivery.
The image below illustrates the problem:
- two interchanges (X and Y)
- One local actor for interchange X that produces data for one capability
- One local actor for interchange Y that consumes data from this capability
- Interchange Y scaled the capability horizontally across three nodes
- The messages sent by producer X must be delivered in-order and can be processed in conusmer Y
e.g. SPAT messages from TLCs A, B and C
However, the interchange is currently unaware of "in-order" contexts of the produced data streams that allow messages from streams A, B and C to be mixed across different endpoints. This creates a risk that messages from 1 data stream can come through out-of-order in consumer Y
After adding sharding, the problem can be solved as follows:
- The local actor or interchange II endpoint specifies how many shards are provided for a capability based on the shardCount property. This property is optional in capability. If no shardcount is specified, only 1 shard is provided
- Producers must add an application property "shard" to the messages for each AMQP message if the shardcount of the corresponding capability is greater than 1. If a local actor has specified a capability with a shard count > 1, and no shard application property is provided, the messages will be dropped by the interchange
Since the producer of data is the only actor in the ecosystem who knows the ordering of messages, it is up to the producer to indicate and ensure that data flows that have a sequence are in the same shard. An interchange must then ensure that the messages can never be delivered out-of-order to the consumer within 1 shard
Below is an example of the new method via sharding:
- One interchange
- A local actor for the interchange that is producing data for one capability (SPAT) with shard count 3 (e.g.: 1 shard per TLC)
- Producer X sends the messages to the interchange with 3 nodes and specifies which messages belong to the same shard
- A posts belong to shard 1
- B posts belong to shard 2
- C posts belong to shard 3
- In this way, it is guaranteed that 'subflows' A, B and C always arrive at in-order in consumer Y
Dutch Profile mapping on MI
The goal of the Mobilidata ecosystem is to connect to the Dutch Profiles for national iTLC standards as laid down within the Partnership Talking Traffic in the Netherlands. This profile builds on the ETSI specifications of iTLC related messages and will describe its own technical and functional profiles that ITSApplications, RIS installations, Service Providers, Applications must comply with. These deviate from European standards in some aspects and expand them. The Mobilidata 1.0.0 profile uses the Dutch Profile consolidated baseline for all message deletions. This means that all connected actors must have implemented the latest baseline and that older Dutch Profile versions are not supported in the ecosystem.
In the context of these deviations, with every iVRI related ETSI message that is exchanged, an evaluation will be made of the compatibility between the C-ROADS specifications and Dutch Profile and will impose a Mobilidata specific profile on top of the official C-ROADS specifications. The goal is always to define non-breaking changes on the C-ROADS TF4 Profile in order to preserve international compatibility and concepts as much as possible.
Specifically, the following message types from the C-ROADS TF4 BI will be evaluated and expanded where necessary:
- MapData Messages (MAPEM)
- Signal Phase State Messages (SPATEM)
- Cooperative Awareness Messages (CAM)
- Signal Request Messages (SREM)
- Signal Status Messages (SSEM)
MAP Messages
At the time of writing, the C-ROADS BI contains the following profile (AMQP headers) for MAP messages that are distributed over an interchange.
| Name | Value and type | Description | Mandatory/Optional |
|---|---|---|---|
| id | String comma-separated list of IntersectionReferenceIds starting and ending with a comma. E.g.: ",557," (single value) or ",557,559,612," (multiple values) or integer (0 ... 65535). Can be a list since a MAP message can contain multiple intersections. | (IntersectionReferenceID) Combination of region and id from the IntersectionReferenceID in the MAP message. An IntersectionReferenceID must be unique to each country. Reference: C-ITS Infrastructure Functions and Specifications | Optional |
| name | String | A free textual name as named by the road authority | Optional |
Table 5: C-ROADS BI Profile V2.1 for MAPEM messages
In the context of Dutch Profile and the TLEX-FI standard that is used in the Netherlands, the C-ITS actors have additional information that can be obtained from the TLEX-FI standard. This exposes the TLCID (or rather, objectID) from which the MAP message was sent. This additional information is used by Mobility Backend (Service Provider in Talking Traffic standard) to verify that an incoming MAP is indeed correct as a TLCID is generated based on information in the MAP. In this way, misconfigured MAP messages can be filtered out by the C-ITS actors who consume this information.
To accommodate this functionality, an additional header field is defined in the Mobilidata Profile that contains the TLCID. In this way, the interoperability between the Flemish and Dutch ecosystems is also preserved and all actors in both ecosystems have the same basic information at their disposal. This makes it possible to monitor current and possible future changes to the Dutch Profile that are based on this information.
Specifically, the Mobilidata Profile will contain the following AMQP headers:
| Name | Value and type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| id | String comma-separated list of IntersectionReferenceIds starting and ending with a comma. E.g.: ",557," (single value) or ",557,559,612," (multiple values) or integer (0 ... 65535). Can be a list since a MAP message can contain multiple intersections. The values are obtained by concatenating the 16 bit regionID and 16 bit intersectionID which results in a 32 bit IntersectionReferenceID. | (IntersectionReferenceID) Combination of region and id from the IntersectionReferenceID in the MAP message. An IntersectionReferenceID must be unique to each country. Reference: C-ITS Infrastructure Functions and Specifications Example for intersection with regionID 536 and intersectionID 11: RegionID = 1 (decimal) = 0x0218 (hex) IntersectionID = 1 (decimal) = 0x000B (hex) => IntersectionReferenceID = 0x0218000B (hex) = 35127307 (decimal) | Optional | Optional | No changes |
| name | String comma-separated list of intersection names, beginning and ending with a comma. E.g.: ",name1," (1 intersection) or ",name1,name2,name3," (multiple intersections). Can be a list as a single MAP and SPAT can contain multiple intersections | A free textual name as named by the road authority | Optional | Optional | Breaking: Name has gone from a single string to a list. |
| custom-mobilidata-tlcID | String | The TLCID/objectID as distributed by AWV to the controller sending the MAP | Optional | Obligatory | AMQP property name changed as it is a regional extension. |
Table 6: Mobilidata MI Profile v1.0.0 for MAPEM messages
Since TLCID is used to verify valid MAP transmission, international compatibility has been preserved. An international player can ignore this field and start submitting Dutch Profile compliant priority requests without this information. However, if Dutch Profile later contains functional specifications that are based on the knowledge of the TLC ID, this information is also available in Flanders and the Flemish actors can connect to the standard without any problems.
SPAT MESSAGES
Splash messages have an analogous specification to MAP messages in the current C-ROADS BI Profile
| Name | Value and type | Description | Mandatory/Optional |
|---|---|---|---|
| id | String comma-separated list of IntersectionReferenceIds starting and ending with a comma. E.g.: ",557," (single value) or ",557,559,612," (multiple values). The values are obtained by concatenating the 16 bit regionID and 16 bit intersectionID which results in a 32 bit IntersectionReferenceID. Can be a list since a MAP message can contain multiple intersections. | (IntersectionReferenceID) Combination of region and id from the IntersectionReferenceID in the MAP message. An IntersectionReferenceID must be unique to each country. Reference: C-ITS Infrastructure Functions and Specifications Example for intersection with regionID 536 and intersectionID 11: RegionID = 1 (decimal) = 0x0218 (hex) IntersectionID = 1 (decimal) = 0x000B (hex) => IntersectionReferenceID = 0x0218000B (hex) = 35127307 (decimal) | Optional |
| name | String comma-separated list of intersection names, beginning and ending with a comma. E.g.: ",name1," (1 intersection) or ",name1,name2,name3," (multiple intersections). Can be a list as a single MAP and SPAT can contain multiple intersections | A free textual name as named by the road authority | Optional |
Table 7: C-ROADS BI Profile V2.1 for SPATEM messages
In Flanders, we will also use a similar profile to that used for MAP messages. However, forwarding a tlcID with each SPAT message will be considered optional. Since a traffic light controller or other road infrastructure must always send a MAP before sending out SPAT messages, the consuming C-ITS actuators have already obtained the TLCID information and should not receive it again via SPAT messages.
As a result, the Mobilidata Profile of the C-ROADS BI contains the following AMQP header specifications
| Name | Value and type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| id | String comma-separated list of IntersectionReferenceIds starting and ending with a comma. E.g.: ",557," (single value) or ",557,559,612," (multiple values) or integer (0 ... 65535). Can be a list since a MAP message can contain multiple intersections. The values are obtained by concatenating the 16 bit regionID and 16 bit intersectionID which results in a 32 bit IntersectionReferenceID. Can be a list since a MAP message can contain multiple intersections. | (IntersectionReferenceID) Combination of region and id from the IntersectionReferenceID in the MAP message. An IntersectionReferenceID must be unique to each country. Reference: C-ITS Infrastructure Functions and Specifications Example for intersection with regionID 536 and intersectionID 11: RegionID = 1 (decimal) = 0x0218 (hex) IntersectionID = 1 (decimal) = 0x000B (hex) => IntersectionReferenceID = 0x0218000B (hex) = 35127307 (decimal) | Optional | Optional | No changes |
| name | String | A free textual name as named by the road authority | Optional | Optional | Breaking: Name has gone from a single string to a list. |
| custom-mobilidata-tlcID | String | The TLCID/objectID as distributed by AWV to the controller sending the MAP | Optional | Optional | AMQP property name changed as it is a regional extension. |
Table 8: C-ROADS MI Profile v1.0.0 Profile for SPATEM messages
CAM Messages
In the Talking Traffic architecture and C-ROADS specifications, CAM messages have defined a different division of roles for routing CAM messages to the correct road infrastructure. In the C-ROADS standard, geocasting is used and the C-ITS actors who wish to obtain this information will define geo zones within which they are active. It is then up to the interchange to route the messages to the right consumers using the quad tree and JMS selectors.
In the Talking Traffic ecosystem, the responsibility for routing messages lies with the service providers (Mobility Backend in Mobilidata). It is the responsibility of the service providers to determine to which intersections, and by extension, to which TLC objects the CAM message should be sent. Talking Traffic has opted for a unicasting approach where CAM messages are sent to specific objects.
Since Mobilidata requires that Dutch Profile is followed, the C-ROADS Mobilidata will provide profile header fields for CAM messages so that unicasting and targeting of messages becomes a possibility.
Specifically, the following headers are defined:
| Name | Value and type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| custom-mobilidata-Id | String comma-separated list of IntersectionReferenceIds starting and ending with a comma. E.g.: ",557," (single value) or ",557,559,612," (multiple values) or integer (0 ... 65535). | (IntersectionReferenceID) Combination of region and id from the IntersectionReferenceID in the MAP message. An IntersectionReferenceID must be unique to each country. Reference: C-ITS Infrastructure Functions and Specifications Example for intersection with regionID 536 and intersectionID 11: RegionID = 1 (decimal) = 0x0218 (hex) IntersectionID = 1 (decimal) = 0x000B (hex) => IntersectionReferenceID = 0x0218000B (hex) = 35127307 (decimal) | Non-existent in C-ROADS | Obligatory | Property name changed as it has become a regional extension in C-ROADS 2.1 |
| Station Type | integerValues between 0 - 15 | The station type as described in CROW Dutch Profile CAM messages | Obligatory | Obligatory | New AMQP property |
| vehicleRole | integerValues between 0 - 12 | The vehicleRole as described in CRIW Dutch Profile CAM messages | Optional | Optional | New AMQP property |
Table 9: Mobilidata MI Profile v1.0.0 for CAM messages
By adding intersectionReferenceIds, the possibility of unicasting is added without having to rely on the TLCID which is specific to the Netherlands. In this way, we facilitate a better internationalization since these are internationally known notions (intersectionReferenceID) and we follow the example of C-ROADS where SRM messages also includes an IntersectionReferenceId list as an optional header.
Disclaimer: Adding the mandatory intersectionReferenceID field means that no geocasting is supported for sending CAM messages in Flanders. Transmitters will always have to rely on the unicasting of the CAM for transmitting CAM messages to TLCs and iVRI spec compliant road infrastructure
SRM Messages
SRM messages follow the same reasoning as CAM messages and will therefore also rely on unicasting to target requests on individual intersections without using geofiltering.
The current C-ROADS BI specifications describe the following AMQP headers for SRM messages
| Name | Value and type | Description | Mandatory/Optional C-ROADS |
|---|---|---|---|
| id | String comma-separated list of IntersectionReferenceIds starting and ending with a comma. E.g.: ",557," (single value) or ",557,559,612," (multiple values) or integer (0 ... 65535). Can be a list since a MAP message can contain multiple intersections. | (IntersectionReferenceID) Combination of region and id from the IntersectionReferenceID in the MAP message. An IntersectionReferenceID must be unique to each country. Reference: C-ITS Infrastructure Functions and Specifications Example for intersection with regionID 536 and intersectionID 11: RegionID = 1 (decimal) = 0x0218 (hex) IntersectionID = 1 (decimal) = 0x000B (hex) => IntersectionReferenceID = 0x0218000B (hex) = 35127307 (decimal) | Optional |
Table 10: C-ROADS BI Profile V2.1 for SRM messages
Since Mobilidata will rely on unicasting, the Mobilidata Profile will make the id field mandatory so that routing can be done using the intersectionReferenceIDs
| Name | Value and type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| id | String comma-separated list of IntersectionReferenceIds starting and ending with a comma. E.g.: ",557," (single value) or ",557,559,612," (multiple values) or integer (0 ... 65535). Can be a list since a MAP message can contain multiple intersections. | (IntersectionReferenceID) Combination of region and id from the IntersectionReferenceID in the MAP message. An IntersectionReferenceID must be unique to each country. Reference: C-ITS Infrastructure Functions and Specifications Example for intersection with regionID 536 and intersectionID 11: RegionID = 1 (decimal) = 0x0218 (hex) IntersectionID = 1 (decimal) = 0x000B (hex) => IntersectionReferenceID = 0x0218000B (hex) = 35127307 (decimal) | Optional | Obligatory | No changes |
Table 11: Mobilidata MI Profile v1.0.0 for SRM messages
SSM Messages
For receiving SSM messages, there are no functional and technical discrepancies between C-ROADS and Dutch Profile/ Talking Traffic setup. The Mobilidata Profile will therefore follow the current C-ROADS specifications for SSEM messages without modifications
| Name | Value and type | Description | Mandatory/Optional C-ROADS | Mandatory/Optional Mobilidata | Changes compared to Mobilidata Interface V0.9 |
|---|---|---|---|---|---|
| id | String comma-separated list of IntersectionReferenceIds starting and ending with a comma. E.g.: ",557," (single value) or ",557,559,612," (multiple values) or integer (0 ... 65535). Can be a list since a MAP message can contain multiple intersections. | (IntersectionReferenceID) Combination of region and id from the IntersectionReferenceID in the MAP message. An IntersectionReferenceID must be unique to each country. Reference: C-ITS Infrastructure Functions and Specifications Example for intersection with regionID 536 and intersectionID 11: RegionID = 1 (decimal) = 0x0218 (hex) IntersectionID = 1 (decimal) = 0x000B (hex) => IntersectionReferenceID = 0x0218000B (hex) = 35127307 (decimal) | Optional | Optional | No changes |
Table 12: Mobilidata MI Profile v1.0.0 for SSM messages