| Internet-Draft | STSP | May 2026 |
| Aldana Flores | Expires 2 November 2026 | [Page] |
This document defines the Smart Traffic Synchronization Protocol (STSP), version 1.0 -- an open, extensible protocol for real-time coordination of urban traffic signal infrastructure across distributed networks of intersections.¶
STSP defines a standard message format, node state machine, synchronization algorithm, and inter-node communication model that enables any compliant traffic controller to participate in a federated intelligent network -- regardless of manufacturer, city, or country of deployment.¶
The key contribution of STSP is the definition of the Infrastructure-to-Infrastructure (I2I) coordination layer -- a communication model between traffic signal nodes that does not exist as an open standard in any currently published specification. Existing standards such as SAE J2735 SPaT/MAP and ETSI ITS-G5 address Vehicle-to-Infrastructure (V2I) communication. STSP addresses the orthogonal problem: how nodes coordinate with each other.¶
This document is placed in the public domain under CC BY 4.0 with Open Implementation Clause. Any city, government, company, or individual may implement STSP freely, provided that original authorship is attributed in all implementations, documentation, and derivative works as follows: "Implements STSP, designed by Gustavo Angel Aldana Flores (draft-aldana-stsp)."¶
This Internet-Draft constitutes the first formal public disclosure of the STSP protocol specification. The conceptual foundation was developed independently by the author beginning approximately in 2015. The first working implementation was completed on 1 May 2026 and validated on ARM64 hardware (Raspberry Pi 4, 8GB RAM) running a full Docker stack including the STSP engine, TimescaleDB, Apache Kafka, Redis, and Grafana. The author asserts perpetual moral rights to this work under Mexican copyright law (Ley Federal del Derecho de Autor, as a Mexican citizen born 21 July 1992) and under the Berne Convention for the Protection of Literary and Artistic Works.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 November 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Urban traffic congestion represents one of the most pervasive and quantifiable quality-of-life challenges in modern cities. According to INRIX Global Traffic Scorecard data, the average driver in a major metropolitan area loses between 50 and 150 hours per year to traffic delays. The aggregate economic cost exceeds hundreds of billions of US dollars annually worldwide.¶
The root cause of this problem is not vehicle density alone -- it is the absence of coordination between traffic signal controllers. The vast majority of traffic signals deployed worldwide operate on fixed-cycle timers programmed once and rarely updated. These controllers have no knowledge of real-time queue conditions, no awareness of neighboring intersections, and no mechanism for inter-city coordination.¶
Existing adaptive systems (SCATS, SCOOT, Siemens SiTraffic, Kapsch) address portions of this problem but share critical limitations: they are proprietary, city-siloed, non-interoperable, and incapable of federated coordination across administrative boundaries.¶
This document specifies STSP -- a protocol designed to be for urban mobility infrastructure what TCP/IP is for digital communication: an open, implementable, universally adoptable standard that enables any conforming node to participate in a global intelligent traffic network.¶
The key insight motivating STSP is the distinction between two communication layers that existing standards conflate or ignore:¶
Current traffic management systems worldwide share the following structural deficiencies, each of which STSP is designed to resolve:¶
Proprietary protocols prevent interoperability. A city deploying System A cannot coordinate with an adjacent city running System B, even when both cities share the same physical corridor.¶
Static timing plans do not respond to real demand. Fixed green cycles optimized for average conditions perform poorly during peak hours, incidents, special events, or adverse weather.¶
Absence of federation means no city benefits from another city's operational data. Cities independently develop solutions that could be shared. No equivalent of internet routing exists for urban traffic.¶
The convergence of edge computing, 5G connectivity, computer vision, and reinforcement learning creates the technical conditions for a fundamentally different approach. STSP specifies the coordination layer -- the protocol -- that allows these technologies to compose into a coherent, federated, open system.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
STSP operates across three hierarchical layers. Each layer functions independently. Higher layers augment but do not replace lower layers.¶
Each STSP Node maintains an autonomous state machine governing its phase transitions. The Node broadcasts its current state via the STSP message format at a configurable interval (default: 200ms). A Node MUST be capable of operating indefinitely in Degraded Mode without network connectivity.¶
Nodes within communication range of one another form a corridor. The Green Wave algorithm (Section 7) coordinates phase transitions across corridors based on vehicle travel time between Nodes.¶
Regions (cities) connect to the STSP federation via a standardized gRPC interface. Federation enables cross-city route optimization, shared model training via Federated Learning, and global traffic event dissemination. Participation in the federation is OPTIONAL for Node and Corridor layer functionality.¶
All STSP messages are encoded as JSON objects transmitted over WebSocket [RFC6455] or MQTT (ISO/IEC 20922). Future versions MAY specify binary encoding for bandwidth-constrained deployments.¶
The following is the normative STSP/1.0 message schema:¶
{
"stsp_version": "1.0",
"node_id": "MX-QRO-CONST-042",
"region_id": "MX-QRO",
"grid_row": 2,
"grid_col": 4,
"latitude": 20.5928,
"longitude": -100.4048,
"phase": "NS_GREEN",
"phase_remaining_ms": 18400,
"timestamp_utc": 1746123456.789,
"queue_ns": 3,
"queue_ew": 0,
"density_ns": 0.30,
"density_ew": 0.00,
"neighbor_ids": ["MX-QRO-CONST-041",
"MX-QRO-CONST-043"],
"green_wave_offset_ms": 0,
"emergency_override": false,
"uptime_s": 86432.1,
"firmware_ver": "0.1.0",
"degraded_mode": false
}
¶
For high-frequency broadcasts (greater than 10Hz), Nodes MAY transmit the compact form, which omits static identity fields:¶
{
"id": "MX-QRO-CONST-042",
"ph": "NS_GREEN",
"rm": 18400,
"qns": 3,
"qew": 0,
"ts": 1746123456.789
}
¶
STSP defines four canonical phase values. Implementations MUST NOT use any other values in the "phase" or "ph" fields:¶
NS_GREEN -- North-South has right of way. NS_YELLOW -- Transition from NS_GREEN. Minimum: 3 seconds. EW_GREEN -- East-West has right of way. EW_YELLOW -- Transition from EW_GREEN. Minimum: 3 seconds.¶
Nodes with non-orthogonal street geometry SHOULD map their local phase names to the nearest STSP canonical phase and document the mapping in their configuration.¶
Node IDs MUST follow the hierarchical format:¶
{COUNTRY}-{REGION}-{CORRIDOR}-{SEQUENCE}
Example: MX-QRO-CONST-042
MX -- ISO 3166-1 alpha-2 country code
QRO -- Region/city identifier (max 8 chars, uppercase)
CONST -- Corridor identifier (max 8 chars, uppercase)
042 -- Zero-padded sequence number within corridor
¶
Each STSP Node implements a deterministic four-state cyclic machine. The transition function f(phase) is defined as:¶
NS_GREEN --[timer_expired]--> NS_YELLOW NS_YELLOW --[timer_expired]--> EW_GREEN EW_GREEN --[timer_expired]--> EW_YELLOW EW_YELLOW --[timer_expired]--> NS_GREEN¶
Phase durations are statically configured. Minimum yellow duration MUST be 3 seconds. Maximum green duration SHOULD NOT exceed 90 seconds. This mode is the mandatory Degraded Mode fallback. Default durations: NS_GREEN 26s, NS_YELLOW 4s, EW_GREEN 26s, EW_YELLOW 4s.¶
Phase durations are computed dynamically by the Adaptive Controller (Section 8). MIN_GREEN default: 10 seconds. MAX_GREEN default: 45 seconds.¶
When emergency_override is set to TRUE by an authenticated and authorized source, the Node MUST immediately transition to a predefined safe state and hold that state for the override duration. The override MUST expire automatically. Manual reset MUST be available at all times.¶
When Node N transitions to a green phase, it SHOULD notify its downstream neighbor N+1 to schedule its own green phase transition at time T + delta, where:¶
delta = D / V_design D -- physical distance between N and N+1, in meters V_design -- corridor design speed, in meters per second¶
The notified Node schedules the transition only if it has already served its minimum green duration (MIN_GREEN).¶
Wave propagation is bidirectional. Nodes SHOULD compute offsets for both upstream and downstream neighbors to accommodate traffic in both directions of a corridor simultaneously.¶
When a Node receives conflicting wave triggers from two different corridors simultaneously, it MUST prioritize the trigger with the higher queue density on the requesting direction.¶
For each green phase, the controller MUST compute:¶
ratio = queue_active / (queue_active + queue_waiting) duration = MIN_GREEN + ratio * (MAX_GREEN - MIN_GREEN) queue_active -- vehicles queued in the currently green direction queue_waiting -- vehicles queued in the opposing direction¶
A green phase MAY be terminated early (but not before MIN_GREEN) if the ratio of queue_waiting to queue_active exceeds SWITCH_IMBALANCE (default: 1.8) AND queue_active is zero or near-zero (less than 1 vehicle) AND MIN_GREEN has been served.¶
Implementations MAY replace the demand ratio policy with a full reinforcement learning controller, subject to the following normative constraints:¶
State: S = (q_ns_bucket, q_ew_bucket, current_phase)
Bucket size: 3 vehicles. Buckets: {0,1,2,3,4}
Actions: A = {EXTEND_GREEN, SWITCH_NOW}
Reward: R = alpha * throughput - beta * weighted_wait
Default: alpha=0.8, beta=1.0
¶
The RL controller MUST respect all hard bounds defined in Sections 6.1 and 6.2. Minimum yellow duration is non-negotiable.¶
Individual vehicle trajectories and personally identifiable information MUST NOT be transmitted in any STSP message or shared across regional boundaries. Only aggregate queue metrics and phase states are federated. This requirement is normative and reflects a core design principle of STSP.¶
Regions participating in the federation MAY share model gradients (not training data) for improving adaptive controllers globally. This approach follows the Federated Learning paradigm and ensures that no city's raw traffic data leaves its administrative boundary.¶
Regions communicate via gRPC over TLS 1.3. The inter-region message format extends the compact STSP message with additional fields for regional routing and model versioning. Full specification is deferred to STSP/2.0.¶
This section specifies MANDATORY failsafe behavior. Implementations that do not conform to this section MUST NOT be deployed in production traffic infrastructure.¶
A Node MUST enter Degraded Mode automatically upon any of the following conditions:¶
In Degraded Mode, the Node MUST:¶
Traffic signal infrastructure is critical public safety infrastructure. Implementations MUST address all threat vectors described in this section.¶
All STSP messages MUST be authenticated using HMAC-SHA256 or equivalent. Unauthenticated messages MUST be silently discarded. Message replay attacks MUST be mitigated via timestamp validation with a maximum tolerance window of 5 seconds.¶
The emergency_override field MUST only be accepted from authenticated sources with explicit override authorization. Unauthorized override attempts MUST be logged and reported to the regional engine immediately.¶
Nodes MUST implement rate limiting on incoming STSP messages. A Node receiving more than 100 messages per second from a single source SHOULD enter protective throttle mode and alert the regional engine.¶
Node hardware MUST be deployed in tamper-evident enclosures rated minimum IP67. Physical access MUST require multi-factor authentication. All tamper events MUST be logged with timestamp and reported to the regional engine.¶
This document requests the following IANA registrations:¶
The author requests that IANA reserve the "stsp" identifier across relevant registries to prevent namespace collision with future incompatible uses.¶
A complete reference implementation of STSP/1.0 exists and is operational as of the date of this document. The implementation includes:¶
Repository: https://github.com/smartflow-stsp/reference [Publication pending]¶
State: S = (q_ns_bucket, q_ew_bucket, current_phase)
Actions: A = {EXTEND_GREEN, SWITCH_NOW}
Reward: R = 0.8 * throughput - 1.0 * weighted_wait
Bucket mapping:
0 -- 0 vehicles (empty)
1 -- 1-3 vehicles (light)
2 -- 4-6 vehicles (moderate)
3 -- 7-9 vehicles (heavy)
4 -- 10+ vehicles (saturated)
¶
I, Gustavo Angel Aldana Flores, hereby declare that I am the sole inventor and author of the Smart Traffic Synchronization Protocol (STSP) as specified in this document. The conceptual foundation of this protocol was developed independently beginning approximately in 2015. The first working implementation was completed on 1 May 2026 and validated on physical ARM64 hardware (Raspberry Pi 4, 8GB RAM) running a full production stack. This Internet-Draft constitutes the first formal public disclosure of the STSP protocol specification.¶
I hereby irrevocably dedicate the STSP protocol specification to the global commons under CC BY 4.0 with Open Implementation Clause. My intent is that this protocol serve as open infrastructure for the benefit of cities, governments, and citizens worldwide -- without commercial enclosure -- while preserving permanent attribution to its author.¶
This protocol was developed independently, without funding from any government, corporation, or institution. No entity holds rights over this specification other than those expressly granted in the copyright notice. The author is not affiliated with any traffic signal manufacturer, smart city platform provider, or standards body at the time of this writing.¶
The author developed this protocol independently. This document was first drafted on 1 May 2026 in Peachtree City, Georgia, USA.¶