Updated 2026-10-09
What a BSM stream looks like
An RSU at a busy intersection hears every equipped vehicle within a few hundred meters, each sending ten BSMs a second. With twenty equipped vehicles in range that is 200 messages a second, each 80 to 300 bytes plus the security envelope. Most of the content is the same from one message to the next: the position moves a meter or two, secMark advances by 100, msgCnt by 1. The information is in the sequence: a breadcrumb trail per id with speed, heading, acceleration, brake and event flags along it, and the moment the trail ends when the vehicle leaves range or its id rotates.
The live view shows that stream as moving markers with trails, a per-vehicle panel, and a message rate chart; alongside it shows SPaT states for the intersections it knows, and SRM and SSM badges for vehicles asking for priority. If you have no RSU yet, the demo feed replays a synthetic stream over the portal's example intersection.
Getting messages from an RSU to the portal
NTCIP 1218 defines a standard way for an RSU to forward what it receives over the air to an IP destination: a row in rsuReceivedMsgTable. Each row says which PSID to forward, where to send it, how, and when:
| Object | Meaning | Value for the portal |
|---|---|---|
rsuReceivedMsgPsid | PSID to forward | 20 for BSM; add rows for 8002 SPaT, E0000016 SRM, E0000015 SSM, 27 PSM, 8010 SDSM |
rsuReceivedMsgDestIpAddr, rsuReceivedMsgDestPort | Where to send | the ingest address and port shown on your live view settings page for your account |
rsuReceivedMsgProtocol | UDP or TCP | UDP |
rsuReceivedMsgRssi | Minimum signal strength to forward | −100 dBm to take everything |
rsuReceivedMsgInterval | Forward every Nth message | 1 for all, 10 to sample one per second per vehicle |
rsuReceivedMsgDeliveryStart, rsuReceivedMsgDeliveryStop | Time window | open-ended for a permanent feed |
rsuReceivedMsgSecure | Forward the full secured PDU or only the payload | full PDU lets the portal report certificate presence; payload only is smaller |
rsuReceivedMsgAuthMsgInterval | How often to forward messages that failed verification | 0 to drop them |
rsuReceivedMsgStatus | Row status | active |
Set the rows with any SNMPv3 tool or your vendor's management interface; the portal's RSU page can write them for a registered device in the same way it writes the store-and-repeat table. Vendor consoles expose the same function under names such as "message forwarding", "received message relay" or "V2X data export"; whatever the name, the fields are the table above. The RSU adds a small header to each forwarded message in some implementations; the portal's ingest peels the common ones and the IEEE 1609.2 envelope, as the capturing messages guide explains.
The feed is UDP from the RSU's management interface to the portal's ingest address, so the agency firewall must allow outbound UDP to that address and port. Nothing flows back. For an agency that cannot open an outbound path, ITS Roads runs a managed instance inside the agency network (see TMC integration).
Breadcrumbs, recording and exports
Each vehicle id becomes a track: the sequence of positions with time, speed, heading, acceleration, brakes, events and, when present, the sender's path history. Tracks end after a configurable silence (default 10 s) or when the id rotates, which happens about every five minutes on a production vehicle, so one physical vehicle appears as a series of short tracks that cannot be rejoined by design.
Recording captures everything the ingest receives for an account into a session with a name, start and stop. Exports come in three forms:
| Format | What it contains | Use |
|---|---|---|
| CSV | One row per message: received_utc, rsu, psid, message, temp_id, msg_cnt, sec_mark, lat, lon, elev_m, speed_mps, heading_deg, accel_long, accel_lat, yaw_rate, brakes_applied, events, lights, path_history_points, signed, cert_present | Spreadsheets, R, pandas |
| GeoJSON | A FeatureCollection of LineString tracks (one per temp_id with start and end times and summary statistics) and Point features for events and SRM/SSM | GIS, QGIS, web maps |
| JSONL | One JSON object per line with the full decoded MessageFrame as the decoder shows it, plus the receive metadata object (received_utc, rsu, psid, rssi when the RSU supplies it, raw_hex) | Reprocessing with your own tools, reproducible research |
SPaT, SRM, SSM, PSM and SDSM messages in a recording are exported in the same files with their own decoded fields, so a priority pilot gets requests, statuses and signal states in one timeline. The API returns the same exports for scripted collection.
Triggers and alerts
A trigger evaluates each decoded message against a rule and records a hit, with optional webhook or e-mail:
| Trigger | Rule |
|---|---|
| Geofence | Position inside a polygon you draw (a crosswalk, a school zone, a work zone) |
| Speed | speed above or below a threshold inside an optional geofence |
| Hard brake | events bit eventHardBraking set, or longitudinal deceleration beyond a threshold |
| ABS or traction | eventABSactivated or eventTractionControlLoss set, which clusters on slippery pavement |
| SRM | Any SRM, or SRM with a given role, with the matching SSM status when it arrives |
| Signal conflict | A BSM crossing the stop line of a MAP lane while the lane's signal group is stop-And-Remain, as a red-light-running proxy |
| Silence | No messages from an RSU for N minutes, which is the simplest RSU health check |
Hits are listed with the message that caused them and are included in exports.
Privacy: what to store and what not to
A BSM is engineered not to identify a vehicle: the id is random, it rotates with the certificate about every five minutes, and the certificate itself is a pseudonym. Position, speed and time are still sensitive in combination, and a trail from a driveway to an office is personal even without a name. The portal applies these rules, and an agency should adopt them for anything it keeps:
- No persistent identifiers are created. Tracks are keyed by the temporary
idand are not rejoined across rotations. - Raw recordings are kept for a limited time (the current retention is shown on the recordings page) and are deleted with the account.
- Exports aggregate where the purpose allows: counts, speeds and events per road segment and 15-minute bin are enough for most performance measures, and they contain no trails.
- Certificate contents are not stored beyond "present" and "verified"; the certificate's identifiers are not logged.
- Geofenced recording near residences and sensitive sites is discouraged; put the fence on the roadway.
- Publish the retention policy to the public; several pilots have been delayed by not doing so.
Store trails only when the study needs them (for example signal performance from stop-line crossings), for the shortest time that serves the study, and with access controls. Do not attempt to join V2X data to license plate readers, tolling or transit fare data.
The pcap import
If you already have captures (from an RSU's interface log, tcpdump on a cabinet switch, or a sniffer), upload the pcap on the live view's import panel. The portal walks the frames, peels Ethernet, WSMP and IEEE 1609.2 layers, decodes every J2735 message it finds with the dictionary you choose, and treats the result as a recording with the pcap time stamps, so the same breadcrumbs, triggers and exports apply. Frames that are not V2X are skipped and counted. Large files are processed in the background and you are notified when the recording is ready. The capturing messages guide covers how to make such a capture and what wrappers to expect.
Related reading
- NTCIP 1218 v01A, the
rsuReceivedMsgTableandrsuInterfaceLogTablegroups; SAE J2945/1 for ID rotation and certificate change; USDOT's privacy guidance for connected vehicle pilots. - BSM, capturing messages, research and pilots, TMC and ATMS integration, NTCIP 1218 push.