How a Smart Street Lighting Network Connects: Mesh, Cellular, and the Gateway Model

• CMS, Smart urban lighting

In a smart street lighting network, every luminaire has to do two things: talk to the luminaires around it, and get its data to the cloud. Those are two different jobs, and the strongest deployments solve them separately. Luminaire controllers communicate locally over a low-power RF mesh, where each node relays for its neighbours and the network routes around any node that drops. Their data then reaches the platform through a cellular uplink, usually aggregated so one modem carries a whole group instead of a SIM card in every pole. Built to open standards such as Zhaga Book 18, DALI-2, and TALQ, that split lets a municipality or a smart-city system integrator mix hardware from several vendors and replace one layer without touching the rest. Lusety builds its controllers and the HORIZON cloud platform on this model. The radio you pick matters far less than the architecture around it.

What a proprietary uplink costs at hardware-refresh time

The reason to keep those two jobs separate shows up the first time a city replaces hardware. A Zhaga Book 18 socket exists so a controller can be swapped without touching the luminaire, because the LED module and the driver normally outlive the control electronics sitting on top of them. That promise holds only if the link the controller talks over is open too.

When the mesh protocol and the platform interface are proprietary, a new supplier’s controller cannot join the network that is already in the street. A partial refresh then means running two parallel networks and two platforms, or replacing every controller in the city in one go. The socket stays open while the network stays closed, and the closed half is the one that costs money.

The uplink is also how a deployed fleet stays current. Firmware goes over the air, so most capability changes happen on the software side, and only genuinely new hardware capability calls for new hardware. Lose the ability to update over your own uplink and every change turns into a truck roll.

How does the local mesh between luminaires work?

Luminaire controllers talk to each other over a low-power RF link arranged as a mesh. Each controller relays messages for the ones near it, so data does not have to travel from a central point to every device. That extends range, and it lets the network route around a node that goes offline, so the section behind it stays online. Lusety’s controllers work this way: they relay over the low-power RF mesh and report into the HORIZON cloud platform through the uplink.

The controller connects to the luminaire through a Zhaga Book 18 socket, defined by the Zhaga Consortium, for the physical fit, and through DALI-2 including its D4i part, for control. Both are open, so the same physical setup accepts controllers and sensors from more than one vendor.

The motion sensors run 24 hours a day. Power stays on at the luminaire even when the light itself is off, so the controller is never asleep waiting to be woken, and nothing has to warm up before a movement event turns into light.

How does the data reach the cloud: per-device cellular or an aggregated uplink?

There are two paths to the platform. In the first, a controller carries its own cellular modem and connects straight to the cloud, which suits sparse or isolated installations. In the second, a gateway controller with a modem collects data from a group of luminaires that relay over the local RF mesh and sends it up in one stream, so many poles share a single cellular uplink. For dense deployments the second path cuts both the number of SIM cards and the number of things that can fail.

Node capacity is a separate matter from the radio mesh. On the wired side of a single node, up to 64 devices can share one controller over the wired DALI-2 bus. That is a limit on how many luminaires and sensors hang off one controller, not on how many poles the mesh can relay to a shared uplink.

At the cabinet level the measurement is different again. Light Keeper, Lusety’s cabinet controller, monitors and measures a whole feeder, tracking the supply to a whole run of poles, where each pole controller sees only its own luminaire.

LTE, NB-IoT, or LoRa: which network should carry the uplink?

For most deployments, standard cellular over LTE is the pragmatic default, and it is the uplink Lusety uses today. It gives constant, always-on monitoring and works anywhere there is mobile coverage, on the same public networks a phone uses.

NB-IoT was designed for a narrower case: infrequent messages from battery-powered devices in awkward places. 3GPP specified it in Release 13 on a single 180 kHz carrier, with a maximum coupling loss of 164 dB, roughly 20 dB more link budget than legacy LTE, in exchange for peak rates around 26 kbit/s down and 62 kbit/s up. For a fixed, mains-powered streetlight controller the battery saving buys nothing, and the throughput ceiling works against continuous monitoring. Lusety’s modems support NB-IoT; it is not the uplink Lusety runs. The counter-case holds, though: that 164 dB budget is real, so on a feeder where LTE coverage is weak, in an underpass or a dense urban canyon, NB-IoT can reach a device that LTE cannot.

LoRaWAN is a different animal. In Europe it runs in the unlicensed 863 to 870 MHz band, needs no SIM cards, and its network belongs to the city or a local operator. The trade is regulatory: ETSI EN 300 220-2 caps the main EU868 sub-bands at a 1% duty cycle, about 36 seconds of transmit time per hour per channel, with data rates between 0.25 and 50 kbit/s. That is comfortable for a few status messages a day and thin for continuous monitoring. LoRa is not a Lusety product today. Where a municipality already operates a LoRaWAN network it is worth putting on the table; where it does not, building one to run streetlights is a project of its own, and in Lithuania the coverage to build on is patchy.

For a mains-powered, continuously monitored lighting network, LTE is usually the right answer, and the case for anything else starts with infrastructure the city already owns.

Why do open standards matter more than the radio you choose?

Three open standards carry the load. Zhaga Book 18 defines the physical socket, DALI-2 and its D4i part define how the controller talks to the luminaire, and the TALQ Consortium specification defines how devices exchange data with a management platform. Because the three are open, a municipality is not tied to one manufacturer: hardware from different suppliers can run side by side, and one part can change without the whole system changing with it. HORIZON is TALQ certified as a central management system, Lusety is an associate member of the consortium, and its controllers are built to Zhaga Book 18 and DALI-2 including D4i.

The limits are worth knowing before a tender goes out. TALQ has mandatory items plus optional parts, so two products built to the specification can still miss each other on an optional part that one of them never implemented. Ask for the specific data you need, on the device side and on the platform side. What each standard covers is set out in our guide to open standards in street lighting: TALQ, Zhaga, and DALI.

This is why the radio ends up being a deployment detail. The interoperability sits in the specifications, so no single supplier’s link is what holds the system together.

What happens to the streetlights if the connection goes down?

They keep working. Each controller has an internal clock and holds its own rules, so switching, dimming, and motion response all run on the device itself, and because the mesh routes around a failed node, one device going down does not take the section behind it. Which decisions sit on the device and which sit in the cloud is covered in our piece on edge versus cloud control in street lighting.

Frequently asked questions

Does every streetlight need its own SIM card?

No. A controller can carry its own cellular modem, or a single modem can aggregate a group of luminaires that talk over the local RF mesh, so one uplink serves many poles.

Is NB-IoT better than LTE for street lighting?

Usually not. NB-IoT suits battery devices that send data rarely, with peak rates near 26 kbit/s down and 62 kbit/s up. Streetlight controllers are mains-powered and benefit from constant monitoring, so LTE is the more practical uplink.

Can a smart lighting network use a city’s LoRa network?

Where a city already runs a LoRaWAN network it can be a sensible uplink, since it needs no SIM cards. The 1% duty cycle in the EU868 band limits how much a device can send, so it fits periodic reporting better than continuous monitoring. Lusety does not offer LoRa today.

What is an RF mesh and why does it help?

An RF mesh is a local radio network in which luminaire controllers relay messages for one another, so no device has to reach a central point directly. That extends range and lets the network route around a node that drops, so a single failure does not isolate the section behind it.

Does the lighting keep working if the internet connection fails?

Yes. Each controller stores its own schedule and rules and runs them locally, including motion response. The cloud carries data and pushes changes, while the lights operate from the device.

What standards should a city or integrator require to avoid vendor lock-in?

Zhaga Book 18 sockets, DALI-2 control including D4i, and systems built to TALQ specifications. Together they let a city run hardware from several suppliers on a single management platform, with the integration between them scoped against a documented interface.

How many luminaires can one node handle?

Up to 64 devices can share a single node over the wired DALI-2 bus running to one controller. That is separate from how many poles the RF mesh relays to a shared uplink.

Conclusions: getting street lighting connectivity right

The connectivity decision in smart street lighting is architectural first and radio second. Solve the two jobs separately, a local mesh for coordination and an aggregated cellular uplink for the cloud, build to open standards, and keep the control logic on the device. A network built that way survives a dead node or a lost connection, and it costs less to run because a handful of uplinks serve many poles. For the municipality that owns the asset and the integrator that has to deploy and support it, the payoff arrives years later: the radio stops being a lock-in decision, so when a better option appears, or the city stands up its own network, you can move to it without rebuilding what sits underneath.

Learn more

If you are planning a smart street lighting rollout and want the network architecture right from the start, we are happy to talk it through.

Email us: info@lusety.com

Call us: +370 649 91222

About Lusety

Lusety is a smart urban lighting company based in Kaunas, Lithuania. It builds street lighting controllers and the HORIZON cloud platform that lets cities and integrators manage lighting networks centrally. The system is built to open standards, including Zhaga Book 18 and DALI-2, and HORIZON is TALQ certified as a central management system, so integrating another maker’s devices stays a scoped piece of work, and cities keep control of their own infrastructure.