Updated 2026-10-09
Priority versus preemption
Preemption seizes the controller: a train or an emergency vehicle gets its movement green as fast as clearance intervals allow, and everything else waits. Priority asks the controller to adjust within its rules: extend the current green a few seconds so the bus makes it, or bring the next green early, without violating minimum greens, pedestrian clearances or coordination. Preemption is for safety-critical responders; priority is for service quality: on-time buses, plows that keep moving so the road stays clear, freight that does not stop a loaded truck on an upgrade. The V2X messages are the same for both; the difference is in the requester's role and in what the controller is configured to do with it.
The conversation, step by step
| Step | Who | What happens | Message or interface |
|---|---|---|---|
| 1 | RSU | Broadcasts MAP (1 Hz) and SPaT (10 Hz) for the intersection | MAP, SPaT |
| 2 | Vehicle OBU | Hears the MAP, matches its lane, computes the ingress lane and expected egress lane and its arrival time at the stop line | on-board |
| 3 | Vehicle OBU | Decides it is eligible (on route, behind schedule, lights active, inside the agency's rules) | on-board policy |
| 4 | Vehicle OBU | Sends an SRM: intersection ID, requestID, priorityRequest, in and out lanes, arrival minute/second, duration, role, importance, position | SRM on PSID 0xE0000016, signed with a certificate whose SSP allows that role |
| 5 | RSU | Verifies the signature and the SSP, decodes the SRM, forwards it to the priority request server (PRS) | RSU application or forwarding to a cabinet or back-office PRS |
| 6 | PRS | Validates the request against the MAP and policy, translates lane to phase, computes the service strategy (extend, early green, phase insertion), and places the request with the controller | NTCIP 1211 priority request objects, or a vendor controller interface |
| 7 | Controller | Serves the request within its constraints; sets signalPriorityIsActive in its status | controller priority logic, NTCIP 1202 priority objects |
| 8 | PRS → RSU | Builds the SSM echoing the requester with status requested, processing, granted, rejected, maxPresence or reserviceLocked | SSM on PSID 0xE0000015, 1 Hz |
| 9 | Vehicle OBU | Shows the status to the operator; sends priorityRequestUpdate if the arrival estimate changes, priorityCancellation when through or diverted | SRM |
| 10 | PRS and TMC | Logs the request, the strategy and the outcome for performance measurement | TMC integration |
In the SPaT the vehicle also sees the result: the status bit signalPriorityIsActive or preemptIsActive, and the timing of its signal group moving in its favor.
Roles, importance and permissions
The SRM's requestor.type carries a role (transit, truck, emergency, police, fire, ambulance, roadWork, dot, safetyCar and others), an agency-defined subrole (1 … 14) and an importance level (1 … 14). The agency's policy, implemented in the PRS, decides what each combination earns: an ambulance with lights on gets preemption; a bus more than two minutes late with passengers aboard gets an extension; a plow in a storm gets early green on its route; a freight truck gets a green extension only on the designated corridor and only off-peak.
Permissions are enforced by the certificate. The OBU's application certificate must carry PSID 0xE0000016 with service-specific permissions that state which roles the vehicle may claim; an RSU rejects an SRM whose claimed role exceeds its SSP. That is why fleet enrollment in the SCMS is part of every priority project: a bus must be enrolled as a bus.
Controller-side standards
NTCIP 1211 (Signal Control and Prioritization) defines the roles: the Priority Request Generator (PRG) on the vehicle or in a central system, the Priority Request Server (PRS) that receives, arbitrates and places requests, and the Coordinator (CO) inside the controller that decides how to serve them. It defines the objects for submitting a request (vehicle class, level, estimated time of arrival, service duration) and reading its status. Many agencies run the PRS as vendor software in the cabinet or on the RSU; some controllers embed it.
NTCIP 1202 v03 and v04 carry the controller's priority and preemption objects and the SPaT block the generator reads; v04 aligns the connected-vehicle objects with CTI 4501.
SAE J2945/B gives the performance requirements for the SRM/SSM application: when a vehicle may request, update rates, how an RSU validates, timing of the SSM, and the mapping between request types and controller actions.
What each use case needs
| Transit (bus) | Winter operations (snow plow) | Freight (truck) | EMS and fire | |
|---|---|---|---|---|
| Mode | Priority: green extension, early green, sometimes phase insertion | Priority on plow routes, often time-limited to storm operations | Priority on freight corridors, weighted by truck class and grade | Preemption, or high-level priority where preemption is not configured |
| Trigger on the vehicle | Behind schedule by N seconds, doors closed, on route (from CAD/AVL) | Plow blade down or route active, during a declared event | On corridor, above weight class, often any time | Lights and siren active, en route to a call |
| OBU | Certified OBU with SCMS enrollment, PSID 0xE0000016 SSP for transit; CAD/AVL integration for schedule and occupancy | OBU with SSP for dot or roadWork role (agency choice); integration with the plow's controls or AVL | OBU with SSP for truck; hpmsType set to the axle class | OBU with SSP for emergency, fire, ambulance or police; optionally EVA alongside the BSM |
| Roadside | RSU with PRS, MAP and SPaT in place, NTCIP 1211 or vendor path to the controller | Same; policy table limited to plow routes and storm windows | Same; policy may require the outbound lane to be a through movement | Same, plus preemption inputs on the controller; many agencies keep an infrared or GPS-based preemption system in parallel and use V2X as a second channel |
| TMC | Priority logs, on-time performance measures, policy editing | Storm activation of the policy, plow tracking | Corridor performance measures, truck travel time | Dispatch integration, preemption logs, conflict resolution with rail preemption |
| What the SSM status means to the operator | Extension or early green granted; reserviceLocked if just served | Granted along the route; maxPresence if the plow stops in the approach | Granted; rejected off-corridor or during peak | Granted immediately; watchOtherTraffic if another responder is also being served |
How to pilot it
- Pick one corridor and one fleet. Three to five signalized intersections on a bus route or a plow route, with controllers that support NTCIP 1211 or a vendor PRS, and five to ten vehicles.
- Author and verify MAP and SPaT at each intersection with the map builder and the binding checks in MAP to SPaT. Priority is impossible without a correct MAP, because the SRM's lanes come from it.
- Enroll the vehicles in the SCMS with the right roles and SSPs; enroll the RSUs with 0xE0000015. See SCMS.
- Write the policy table: role, subrole, importance, time of day, lateness threshold, allowed strategies, maximum extension, re-service lock-out. Load it into the PRS.
- Bench test with the portal: encode an SRM from the template with your intersection ID and lanes, push it from a test RSU (or play it from a vehicle), and watch for the SSM in the live view. Decode both in the decoder and check the echo fields.
- Field test with one vehicle and a technician at the cabinet watching the controller's priority status, then expand.
- Measure: requests, grants, rejections, extension seconds, bus schedule adherence or plow cycle time before and after, side-street delay. The portal's exports give you the request and status rows with time stamps.
How the portal shows it
The live view draws each requesting vehicle with a badge for its role and the latest SSM status, draws the intersection with signalPriorityIsActive and preemptIsActive indicators from the SPaT, and lists the request timeline: SRM sent, SSM requested, granted, SPaT signal group timing change, vehicle through. The demo feed replays a late bus getting a green extension and an ambulance getting preemption so you can see the sequence before you have a fleet. The SRM and SSM templates in the creator are the same pair the demo uses.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| No SSM at all | RSU does not forward SRMs to a PRS, or rejects them on signature or SSP |
SSM rejected immediately | Role not allowed by policy, intersection ID mismatch, in-bound lane not an ingress lane with a connection |
SSM stuck at processing | PRS cannot reach the controller (NTCIP 1211 path down, wrong controller address) |
granted but the signal does not change | Controller priority not enabled for that phase, or the request arrived too late to act within the constraints |
maxPresence on every request | Vehicle sends priorityRequest repeatedly instead of priorityRequestUpdate, or never cancels |
| Works for one intersection only | MAP revisions or signal group tables differ between the generator and the MAP at the others |
Related reading
- SAE J2945/B; SAE J2735_202409 SRM and SSM modules; NTCIP 1211; NTCIP 1202 v03/v04; CTI 4501; the FHWA transit signal priority handbook and USDOT's Multi-Modal Intelligent Traffic Signal System (MMITSS) reports for freight, transit and emergency priority logic.
- SRM and SSM, how signal timing works, MAP to SPaT, TMC and ATMS integration, research and pilots.