]> Aldana Innovations

Peachtree City Georgia United States of America g.aldana@aldanainnovations.com https://github.com/smartflow-stsp

General Independent Submission traffic signal synchronization smart city green wave adaptive infrastructure I2I protocol open standard 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.

Introduction 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:

• V2I (Vehicle-to-Infrastructure): the layer that informs vehicles of the current signal phase. Standards such as SAE J2735 SPaT/MAP and ETSI ITS-G5 address this layer.
• I2I (Infrastructure-to-Infrastructure): the layer that enables traffic signals to coordinate with each other in real time. No open standard exists for this layer. STSP fills this gap.

Problem Statement

Fragmentation of Existing Systems 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 Technical Opportunity 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.

Terminology 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 when, and only when, they appear in all capitals, as shown here.

Node

A single traffic signal controller implementing STSP.

Region

A set of nodes within a single administrative boundary (city, district).

Federation

A collection of Regions participating in the STSP global network.

Phase

The current signal state of a Node. One of: NS_GREEN, NS_YELLOW, EW_GREEN, EW_YELLOW.

Green Wave

A coordinated sequence of phase transitions across adjacent Nodes timed to allow vehicles traveling at design speed to encounter consecutive green signals.

Degraded Mode

The autonomous fixed-cycle operation a Node reverts to when network connectivity is lost.

I2I

Infrastructure-to-Infrastructure. The communication layer between STSP Nodes. Distinct from V2I (Vehicle-to-Infrastructure) as defined in SAE J2735 and ETSI ITS-G5.

STSP/1.0

The wire format and protocol version defined in this document.

Protocol Overview STSP operates across three hierarchical layers. Each layer functions independently. Higher layers augment but do not replace lower layers.

Node Layer 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.

Corridor Layer 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.

Federation Layer 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.

Message Format (STSP/1.0) All STSP messages are encoded as JSON objects transmitted over WebSocket or MQTT (ISO/IEC 20922). Future versions MAY specify binary encoding for bandwidth-constrained deployments.

Standard STSP Message The following is the normative STSP/1.0 message schema:

Compact Form For high-frequency broadcasts (greater than 10Hz), Nodes MAY transmit the compact form, which omits static identity fields:

Phase Enumeration STSP defines four canonical phase values. Implementations MUST NOT use any other values in the "phase" or "ph" fields: 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 ID Format Node IDs MUST follow the hierarchical format:

Node State Machine Each STSP Node implements a deterministic four-state cyclic machine. The transition function f(phase) is defined as: NS_YELLOW NS_YELLOW --[timer_expired]--> EW_GREEN EW_GREEN --[timer_expired]--> EW_YELLOW EW_YELLOW --[timer_expired]--> NS_GREEN ]]>

Fixed Mode 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.

Adaptive Mode Phase durations are computed dynamically by the Adaptive Controller (Section 8). MIN_GREEN default: 10 seconds. MAX_GREEN default: 45 seconds.

Emergency Override 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.

Green Wave Synchronization Algorithm

Offset Calculation 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: The notified Node schedules the transition only if it has already served its minimum green duration (MIN_GREEN).

Bidirectional Propagation Wave propagation is bidirectional. Nodes SHOULD compute offsets for both upstream and downstream neighbors to accommodate traffic in both directions of a corridor simultaneously.

Priority Resolution 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.

Adaptive Phase Control

Demand Ratio Policy (Normative Baseline) For each green phase, the controller MUST compute:

Early Termination 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.

Reinforcement Learning Extension (Optional) Implementations MAY replace the demand ratio policy with a full reinforcement learning controller, subject to the following normative constraints: The RL controller MUST respect all hard bounds defined in Sections 6.1 and 6.2. Minimum yellow duration is non-negotiable.

Federated Network Architecture

Data Sovereignty 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.

Federated Learning 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.

Inter-Region Protocol 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.

Degraded Mode and Failsafe This section specifies MANDATORY failsafe behavior. Implementations that do not conform to this section MUST NOT be deployed in production traffic infrastructure.

Degraded Mode Triggers A Node MUST enter Degraded Mode automatically upon any of the following conditions:

• Network connectivity loss exceeding 30 seconds
• Regional engine heartbeat timeout
• Hardware sensor failure detected by watchdog
• Watchdog timer expiry
• Explicit authenticated operator command

Degraded Mode Behavior In Degraded Mode, the Node MUST:

• Revert to fixed-cycle operation with pre-configured durations
• Continue operating indefinitely without network connectivity
• NOT require operator intervention to enter Degraded Mode
• Log the trigger event with UTC timestamp and cause code

Recovery When connectivity is restored, the Node MAY re-synchronize after a mandatory stabilization period of not less than one complete phase cycle. Re-synchronization MUST be gradual and MUST NOT cause abrupt phase changes visible to road users.

Security Considerations Traffic signal infrastructure is critical public safety infrastructure. Implementations MUST address all threat vectors described in this section.

Message Authentication 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.

Emergency Override Authorization 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.

Denial of Service 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.

Physical Security 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.

IANA Considerations This document requests the following IANA registrations:

• WebSocket Subprotocol "stsp": for STSP/1.0 over WebSocket connections per the WebSocket subprotocol registry ().
• MQTT Topic Namespace "stsp/": reserved for STSP message routing per MQTT specification (ISO/IEC 20922).
• A dedicated TCP port number for STSP engine-to-engine communication is requested (specific number pending IANA assignment).

The author requests that IANA reserve the "stsp" identifier across relevant registries to prevent namespace collision with future incompatible uses.

Reference Implementation A complete reference implementation of STSP/1.0 exists and is operational as of the date of this document. The implementation includes:

• Python 3.12 asyncio engine with WebSocket server (RFC 6455)
• Intersection state machine (models/intersection.py)
• Traffic network model -- 5x4 node grid (models/network.py)
• Adaptive controller with demand ratio and Q-Learning derived policy (algorithms/adaptive.py)
• Green Wave coordinator with offset calculation (algorithms/green_wave.py)
• STSP protocol encoder/decoder (protocol/stsp.py)
• TimescaleDB schema for time-series metrics persistence
• Docker Compose stack: engine + Kafka KRaft + Redis + Grafana
• REST API: /health, /state, /stats, /mode
• Validated on ARM64 (Raspberry Pi 4, 8GB RAM) and Apple M3

Repository: https://github.com/smartflow-stsp/reference [Publication pending]

References Normative References Informative References SAE International ETSI

Appendix A: RL State Space (Non-Normative)

Appendix B: Glossary

IETF

Internet Engineering Task Force

I2I

Infrastructure-to-Infrastructure communication

V2I

Vehicle-to-Infrastructure communication

STSP

Smart Traffic Synchronization Protocol

SPaT

Signal Phase and Timing (SAE J2735)

SCATS

Sydney Coordinated Adaptive Traffic System

SCOOT

Split Cycle Offset Optimization Technique

RL

Reinforcement Learning

HMAC

Hash-based Message Authentication Code

gRPC

Google Remote Procedure Call (open protocol)

OT

Operational Technology (industrial control systems)

HSM

Hardware Security Module

Author's Declarations

Declaration of Priority 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.

Declaration of Open Intent 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.

Declaration of Independence 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.

Acknowledgements The author developed this protocol independently. This document was first drafted on 1 May 2026 in Peachtree City, Georgia, USA.