A streetlight CMS architecture connects field controllers or nodes to a communications path and a central management system (CMS), where authorized users can view assets, receive status information, and send control actions. A gateway may sit between nodes and the CMS in some designs, but it is not universal: the topology depends on the selected system and communications method.
For cities and transportation agencies, the important question is not whether a diagram contains the most boxes. It is whether each box has a clear role, a documented interface, and an owner across the system lifecycle.
Key takeaways
- A node is the field-level controller associated with an individual streetlight or other managed device.
- An outdoor device network is the communications path that carries data and authorized commands between the field and central software.
- A gateway can aggregate or bridge communications in some architectures; direct-connect designs may not use one as a separate layer.
- The CMS is the central software role for organizing assets, status, user access, reporting, and configured controls.
- Architecture selection requires more than a product comparison: agencies should validate interfaces, lifecycle support, communications behavior, access governance, and project-specific requirements.
What a streetlight CMS architecture is
A streetlight management architecture is a reference model for how outdoor lighting assets, communications, central software, and operator-facing applications work together. It is useful because terms such as node, gateway, network, and CMS are sometimes used interchangeably in product discussions even though they refer to different functions.
At a high level, the model looks like this:
1. Field device and node/controller
2. Outdoor device network
- Optional gateway, where the selected topology requires one
- Central management system
- Operator applications and workflows
Reference model only; actual topology and interfaces vary by deployment.
The diagram is conceptual, not a universal wiring or communications design. In one deployment, a node may communicate through a gateway. In another, it may use a direct connection to central software. The names, protocols, backhaul arrangements, and local behavior must be verified for the system under consideration.
The U.S. Department of Energy describes connected lighting systems as systems with distributed intelligence, sensors, and modern network interfaces. It also notes that their ability to monitor operation can support data-driven uses, while questions about performance and value still need to be evaluated for a given deployment. DOE’s connected-lighting overview is a useful starting point for that distinction.
The five roles in the system
The following definitions make a streetlight CMS architecture easier to evaluate. They describe roles, not a requirement that every project use the same hardware, software, or topology.
Node or streetlight controller
A node, often called a controller in outdoor-lighting systems, is associated with a field device such as a luminaire. Its role may include receiving an allowed command, reporting a defined device status, or providing a point of identity for the managed asset.
That description deliberately stops short of claiming a specific capability for every controller. Whether a node can report a given condition, execute a particular dimming profile, retain settings during a communications interruption, or work with a particular luminaire depends on its model, configuration, and documented system design.
For procurement, separate the node’s physical location from its functional responsibilities. Ask which asset it represents, which data fields it can report, how it is commissioned, and what it does when central communications are unavailable. Those questions are more useful than treating every connected controller as equivalent.
Outdoor device network
The outdoor device network is the path that moves information between field devices and the systems that manage them. It may include one or more communications elements, but a reference architecture should not assume a method before the project documents establish one.
The network is more than a line on a diagram. It defines how the system identifies devices, transports status and commands, handles connections, and exposes operational boundaries. An agency should ask where the network begins and ends, who operates each segment, and how coverage and backhaul assumptions are documented.
The communications path also affects operations. A status value is only meaningful when the project team understands what produced it, how often it is reported, and what the CMS does with it. A system diagram should make those handoffs visible rather than collapsing them into the label “smart network.”
Gateway
A gateway is an architecture-dependent bridge or aggregation point. In a gateway-mediated design, it may collect communications from multiple field devices and pass them to a wider network or central service. It can also mark a boundary between a local device network and another communications environment.
That does not mean every outdoor device network needs a gateway. A direct-connect design can place a node in communication with central services without a distinct gateway layer. The presence of a gateway is therefore a design fact to validate, not a proxy for system quality, resilience, or interoperability.
When a gateway is proposed, ask what happens if it loses power or backhaul, which devices depend on it, how it is identified and managed, and what local behavior remains available. The answers belong in the supplier’s technical documentation and the project’s operational plan.
Central management system (CMS)
The CMS is the central software role in a streetlight management architecture. Depending on the system, it may organize the asset inventory, receive and present device information, apply configured controls, manage user access, and support reporting. A CMS does not replace the field controller; it coordinates information and actions across many managed assets.
This distinction matters when comparing proposals. A dashboard can display a device state, but the device and its controller still need a defined way to produce that state. Likewise, an operator’s action in a CMS still needs an authorized communications path and a compatible field controller to reach the physical asset.
The delivery and hosting model are implementation-specific. The article’s reference model does not endorse any one approach. Instead, it gives an agency a basis for asking where data is stored, who administers accounts, what audit information is available, and how the system connects to other approved applications.
Applications and operator workflows
Applications are the interfaces and processes through which people use the CMS. Depending on the documented system, this can include asset views, maps, alerts, reports, user administration, or a workflow that routes an issue to a maintenance team.
Do not assume that an application feature guarantees an outcome. An alarm, for example, may represent a reported condition that still requires triage, field verification, and a local work process. Similarly, an integration with a work-order system should be confirmed through current interface documentation, not inferred from a dashboard screenshot.
Keeping applications separate from the CMS itself makes responsibilities clearer. The CMS manages central data and control functions; applications help specific users act on that information within their own operating procedures.
How information and commands move through the architecture
An architecture becomes easier to assess when it is read as two related flows: a status or data flow toward central software, and an authorized command flow back to the field.
- A field node records a defined status or event. The event might be a state that the system is configured to report. The exact fields and timing are implementation-specific.
- The outdoor device network transports that information. The path may include an optional gateway or another communications boundary.
- The CMS receives, stores, displays, or applies a configured rule to the information. This is where asset records, user roles, reporting, and operational logic are considered together.
- An authorized action returns through the selected path to the relevant controller. The field device’s response depends on the compatible controller, configuration, and project design.
This model avoids two common errors. First, a CMS should not be described as if it directly performs the physical action at a pole or fixture. Second, a controller should not be described as if it independently provides the central inventory, reporting, and user-governance functions of the CMS.
For a concrete first-party example, LEOTEK describes RenAI as the central management system within its Intelligent Lighting System and describes streetlight controllers as field components for data collection and command execution. Readers evaluating that approach can review the connected streetlight management information and the RenAI roadway asset management platform. Those pages describe LEOTEK’s offering; they do not establish a universal architecture or a project-specific result.
What changes when a gateway is present or absent
The most practical way to compare gateway-mediated and direct-connect patterns is to identify the boundaries that change.
In a gateway-mediated pattern, an agency may need to account for an additional managed component, its location, its upstream connection, and how a loss of that component affects the field devices associated with it. This can make local grouping visible in the architecture, but it also adds a component that needs inventory, access management, updates, and support procedures.
In a direct-connect pattern, the design may remove the distinct gateway layer, but it does not remove the need to understand communications. The agency still needs documentation for device identity, network dependency, central-service access, configuration, and what happens when a connection is interrupted.
Neither pattern can be chosen responsibly from a generic diagram alone. The right review is project-specific: corridor conditions, existing communications assets, operating ownership, maintenance capabilities, procurement requirements, and the selected vendor’s documentation all matter. Do not treat a topology as a substitute for engineering, cybersecurity, or operational review.
Architecture questions for cities and transportation agencies
The questions below turn a high-level streetlight network architecture into an evaluable scope of work.
Asset and lifecycle questions
- What identifier connects the pole, luminaire, node, and CMS asset record?
- Which status fields and history are documented for each asset?
- How are devices added, replaced, retired, or reassigned over their lifecycle?
- Which party maintains the inventory, configuration record, and documentation after commissioning?
These questions help prevent a gap between the physical asset register and the central software view. They also clarify what must be preserved when equipment is serviced or a contract changes.
Integration and data questions
- What documented interfaces are available, and what information can pass through them?
- Who owns the operational data, administers access, and defines retention?
- Can the agency export records in a documented format if operations change?
- Which systems are authoritative for asset identity, maintenance history, and user administration?
Interoperability should be investigated, not assumed. DOE research on connected-lighting interoperability notes that APIs can facilitate integration but also identifies challenges, limitations, and tradeoffs. A stated API or integration feature alone does not prove that two systems will meet a project’s requirements.
Network and resilience questions
- What communications path is proposed for each device group?
- How are coverage, backhaul, device identity, and loss-of-communications behavior documented and tested?
- If a gateway is used, which devices depend on it and how is it monitored and supported?
- What actions, if any, are expected to remain local when central communications are unavailable?
These are validation questions, not installation instructions. The agency should require answers that correspond to the actual deployment, not just a generic network diagram.
Cybersecurity and governance questions
Connected field devices introduce lifecycle questions that extend beyond the initial installation. NIST notes that Internet of Things devices can affect cybersecurity and privacy risks differently from conventional IT devices and recommends managing those risks throughout device lifecycles. NISTIR 8228 provides the relevant risk-management context.
For a streetlight CMS architecture, ask for documented practices covering user access, device and gateway administration, software updates, incident handling, data handling, and role ownership. The appropriate controls and privacy obligations depend on the deployment, jurisdiction, data collected, and agency policy. A vendor description is not a substitute for the agency’s technical, legal, and security review.
Use the reference model to make the next conversation specific
The value of a streetlight CMS architecture is clarity. Nodes operate at the field layer. The outdoor device network carries communications. A gateway may bridge or aggregate that network. The CMS organizes central information and authorized actions. Applications put those functions into an operator’s workflow.
With those roles separated, a city or transportation agency can ask targeted questions about interfaces, ownership, operating behavior, and lifecycle support before selecting a system. For source documents and model-specific information, consult LEOTEK technical documents. If a project has defined connected-lighting requirements, it may also be appropriate to discuss a roadway infrastructure project with LEOTEK. Neither path replaces project-specific engineering, cybersecurity, or procurement review.
Frequently asked questions
Is a gateway required for every smart streetlight network?
No. A gateway may aggregate or bridge communications in some designs, but direct-connect designs may not have a separate gateway layer. Confirm the selected system’s topology and communications documentation rather than assuming one pattern.
What is the difference between a node and a CMS?
A node or controller is associated with a field device and participates in reporting status or receiving permitted commands. A CMS is the central software role that organizes assets, user access, reporting, and configured control functions across the system.
What should a city ask before selecting a streetlight management platform?
Ask for documentation on asset identity, status fields, communications dependencies, interface availability, data ownership, user administration, update practices, and loss-of-communications behavior. Then assess those answers against the agency’s operating and procurement requirements.
Does a CMS prove that devices are interoperable?
No. A CMS can provide central management functions, but interoperability depends on documented interfaces, data models, configuration, and the systems being connected. It must be evaluated for the specific project.
References
- U.S. Department of Energy, Connected Lighting Systems; accessed July 26, 2026.
- U.S. Department of Energy, Connected Lighting Interoperability; accessed July 26, 2026.
- National Institute of Standards and Technology, Considerations for Managing Internet of Things Cybersecurity and Privacy Risks; accessed July 26, 2026.
- LEOTEK, LEOLink Solutions; accessed July 26, 2026.
- LEOTEK, RenAI AI Roadway Infrastructure Management System; accessed July 26, 2026.
- LEOTEK, Resources and Documents; accessed July 26, 2026.
