Receiving V2X at the roadside, over the network

V2X without a radio

Vehicles broadcast over ITS-G5 or PC5. A roadside application that wants to act on that traffic has two ways to hear it. One is to fit an ITS-G5 radio at every point of interest. The other is to let the network carry the messages. ETSI GS MEC 030 [1] takes the second route. The stack ingests the V2X at the edge, and an application subscribes to receive the messages of its area over the network.

That path is V2N2I, vehicle to network to infrastructure. A traffic-management application, a data recorder, or a corridor operator can consume live CAM, DENM and CPM without any radio hardware of its own. The subscription and delivery model is defined in MEC 030 §5.5.10, publish and subscribe and notify.

Vehicle to network to infrastructure

The subscription

A roadside application registers a subscription with the message types and the area it cares about. The filterCriteria carries the standards organisation, the message types, and optionally the geographic scope. The platform answers 201 Created with the subscription body and a Location header for the new resource.

curl -sS -X POST https://mec.skyv2x.com/vis/v2/subscriptions \
  -H 'Content-Type: application/json' \
  -d '{
    "subscriptionType": "V2xMsgSubscription",
    "callbackReference": "mqtt://roadside-app.local/talaia",
    "filterCriteria": {
      "stdOrganization": "ETSI",
      "msgType": ["denm", "cpm"]
    }
  }'

{
  "subscriptionType": "V2xMsgSubscription",
  "callbackReference": "mqtt://roadside-app.local/talaia",
  "filterCriteria": {
    "stdOrganization": "ETSI",
    "msgType": ["denm", "cpm"]
  },
  "_links": {
    "self": { "href": "/vis/v2/subscriptions/{id}" }
  }
}

Scope by area as well as by type. filterCriteria.locationInfo narrows a subscription to the zone the roadside application covers, so a corridor operator receives the traffic of its corridor and nothing else. The platform matches every incoming message against the filter before it delivers.

The notification

A message reaches the platform by one of two routes, from the ITS-G5 stack over the air or published to the VIS over REST. Either way it is matched against the active subscriptions, and every match delivers a V2xMsgNotification (MEC 030 §6.4.5) to the subscriber's callback. The same message is relayed to the Annex A topic /vis/ue/v2x_msg on the MQTT v5 broker, where topic consumers read it. Both routes converge on one notification path.

{
  "notificationType": "V2xMsgNotification",
  "timeStamp": { "seconds": 1788731849, "nanoSeconds": 436542034 },
  "msgPropertiesValues": {
    "stdOrganization": "ETSI",
    "msgType": 2,
    "msgProtocolVersion": 2,
    "locationInfo": { "geoArea": { "latitude": 41.39, "longitude": 2.13 } }
  },
  "msgRepresentationFormat": "hexadecimal",
  "msgContent": "020200000001ba530059ca10bc0d91daa403e83e8001b7743e0000012000003fe1ed0403ffe3fff400",
  "_links": { "subscription": { "href": "/vis/v2/subscriptions/{id}" } }
}

locationInfo comes from the decoded CAM itself, the reference position the sending vehicle put in the message, and msgContent carries those same bytes verbatim.

Talaia does not verify the signature. The V2X Information Service relays the message without opening it: MEC 030 §6.2.7 defines msgContent as content formatted by the publishing standardization organization, and the specification places no verification duty on the service. The sending ITS station signs the message, and the roadside application verifies it, with trust anchored to a C-ITS PKI such as Castell. The signed message travels unchanged in msgContent.

What this covers

This is an integration path, receiving V2X over the network. Acting on it is the application's own concern. Talaia carries the messages and, through the QoS prediction interface, can tell an application what the network is likely to do along a route before it distributes information to a corridor. It does not regulate signals, close lanes, or issue hazard warnings; those are decisions an application makes on data it trusts and verifies.

[1] ETSI GS MEC 030 V3.2.1, V2X Information Service API. §5.5.10, §6.2.7, §6.4.5, Annex A. PDF.