Updated 2026-10-08
Four places the bytes live
1. The RSU message store (SNMP). Stored broadcast messages sit in rsuMsgRepeatTable under NTCIP 1218 (1.3.6.1.4.1.1206.4.2.18.3.2.1). An snmpwalk returns the payload column as hex: a bare J2735 MessageFrame starting 00 1F (TIM), 00 12 (MAP) or 00 21 (RSM). Paste it straight into the decoder. No wrapper, no signature.
2. Received-message forwarding (UDP). NTCIP 1218 and CTI 4001 let the RSU forward messages it receives over the air (BSMs, SRMs, PSMs) to a back-office address, configured in rsuReceivedMsgTable (...18.5.2.1) with a destination IP and port per PSID. The forwarded datagram is the bare MessageFrame when rsuReceivedMsgSecure is 0, or the full IEEE 1609.2 SPDU when it is 1. Capture with tcpdump -i <if> udp port <port> -w rx.pcap on the collector, export a packet's UDP payload as hex, and decode it. The decoder recognises both forms.
3. Immediate-forward input (UDP). Messages sent to the RSU for immediate transmission (SPaT from a controller, SSM from a priority server) arrive on the RSU's immediate-forward port, by convention UDP 1516, as raw bytes or a vendor text framing (the legacy RSU 4.1 Appendix C format on older units). If you are debugging a controller-to-RSU link, capture on that port.
4. Over the air (PC5 or DSRC). A C-V2X sniffer, an OBU in monitor mode, or a vendor's capture tool produces full frames: WSMP header, then the 1609.2 SPDU, then the MessageFrame. Some tools export Ethernet-encapsulated frames with EtherType 0x88DC. Paste the whole frame; the decoder reports the PSID, the signer and the signature type before it decodes the payload.
Reading what the decoder tells you about the wrapper
| Layer line | Meaning |
|---|---|
| Ethernet II, EtherType 0x88DC | A full frame from a capture tool; MAC addresses shown |
| IEEE 1609.3 WSMP, PSID 0x8003 | Networking header; the PSID should match the message type (TIM here) |
| IEEE 1609.2 SPDU, signedData, signer digest | The message was signed; the signer is identified by a certificate digest (the full certificate is sent periodically) |
| IEEE 1609.2 SPDU, unsecuredData | The message was not signed; receivers in production discard these |
| trailing bytes | The decoder finished before the end of the input: padding, a second message, or a vendor trailer |
Vendor consoles and logs
Commsignia, Yunex, Kapsch, Cohda, Danlaw and Applied Information consoles all expose the stored messages and usually a recent-received log as hex. The ODE (USDOT Operational Data Environment) and CDOT-style pipelines publish decoded JSON and the original hex in the metadata; the hex is what to paste when you want an independent decode.
Keep in mind
- Positions in a BSM are the vehicle's; in a MAP or TIM they are the agency's reference points. The map view uses the same projection for both, so a lane that lands in the wrong place is a wrong offset, not a map error.
- The 2024 dictionary decodes most 2016 and 2020 messages, but a few renamed or re-ordered fields exist. If a known-good older capture fails, tell us; the next portal release will add selectable schema sets.
- Never paste credentials into the decoder. It does not need them, and the pasted text is processed on ITS Roads servers.