Why an industrial cellular router for smart street lighting — not a radio mesh, not a fibre drop — is what turns 10,000 light poles into a city-wide edge network that actually pencils out.
Written by E-Lins Engineering Team
Choosing the right industrial cellular router for smart street lighting is the decision that decides whether a connected lighting programme scales past its own pilot. Every city already owns the densest, best-powered, best-permitted piece of real estate it will ever have. It is not a rooftop, not a data centre, not a cell tower lease. It is the light pole — spaced 25 to 40 metres apart along every road the city maintains, with a mains feed at the base and a legal right to be exactly where it is. Put a router in every pole and you have accidentally built the densest edge network in the city. The interesting engineering question is not whether that is possible. It is whether it survives contact with a spreadsheet.
This is written from the deployments we have supported: retrofit tenders in Southern Europe, new-build corridors in the Gulf, and a handful of brownfield municipal projects where the lighting contractor, the CCTV contractor and the connectivity contractor all showed up on day one and discovered they had never met. What follows is the part that rarely makes it into a tender document — the power arithmetic, the thermal reality inside a steel pole, the security model an auditor will accept, and the provisioning process that decides whether your rollout takes six months or three years.
The Pole Is Already There — and That Changes the Whole Calculation
A municipal lighting network is not a greenfield IoT deployment. It is an existing civil asset with a known inventory, a known power feed, and a maintenance crew that already drives past every node once a month. That is an enormous head start, and it is why smart street lighting monitoring and control has become the entry point for most smart city programmes rather than an afterthought.
Consider what you get for free. A mains connection at the base of every pole — no new wayleave, no new trenching, no new utility application. A physical structure rated for wind loading and already insured. A service vehicle route that passes every node. And crucially, a budget line that already exists: the lighting department is already spending money on these poles every year, mostly on electricity and mostly on reactive repair.
That last point is the one that unlocks funding. Energy is typically 30 to 40 % of a municipality’s electricity bill, and street lighting is the single largest controllable slice of it. Moving from a fixed schedule to adaptive dimming routinely cuts lighting energy by 50 to 70 % once you add LED. That saving is what pays for the connectivity layer, and it is why so many projects are structured as an energy performance contract rather than a capital purchase.
But here is where projects go wrong: the business case is approved on energy savings, and then the connectivity design is inherited from a pilot that had 200 poles. The pilot works. The 10,000-pole rollout does not — not because the radio is worse, but because every cost in the model was linear in the wrong variable. The pilot never had to provision 10,000 SIMs, never had to roll firmware across 10,000 devices, never had to answer an auditor asking what happens when someone opens a pole base door on a quiet street at 3 a.m.
| The framing we use with customers |
| Do not design a lighting control system that happens to have a network. Design a city-scale edge network that happens to be funded by lighting. The second framing survives scale; the first one does not. |
Everything in this article follows from that reframing. It changes which router you pick, which radio you pick, how you segment traffic, how you provision, and how you model cost.
Three Generations of Streetlight Networking — and Why the Second One Breaks
Streetlight connectivity has gone through three architectural generations, and understanding why generation two fails at scale explains most of the design decisions in generation three.
Generation 1: standalone photocell and time clock
Each luminaire decides independently, using a photocell or an astronomical clock. Zero communication, zero visibility, and a failure mode — a lamp stuck on during the day — that is only discovered when a resident complains. Energy savings from LED retrofit are real, but you cannot dim adaptively, you cannot verify the saving, and you cannot prove compliance to whoever funded the project.
Generation 2: RF mesh and sub-GHz star
The first generation of “smart” lighting added a radio: ZigBee mesh between luminaires, or a LoRa/sigfox star back to a gateway. On 200 poles this is genuinely elegant — low module cost, long battery-free operation, no recurring connectivity fee. Cities liked it, vendors demoed it beautifully, and it was specified into hundreds of tenders.
Then deployments hit real size, and four problems appeared that the pilot never showed:
- Gateway density becomes a civil engineering project. A sub-GHz star needs gateways on buildings. Every gateway is a lease, a power drop, a backhaul circuit, and a landlord negotiation. The “cheap radio” savings get eaten by gateway real estate.
- The backhaul is a single point of failure for hundreds of poles. One gateway serving 300 luminaires means one fibre cut takes out a district. You have converted 300 independent failures into one correlated failure — the exact opposite of what a resilience case wants.
- Nodes are not individually IP-addressable. A luminaire behind a proprietary mesh gateway is not a network endpoint you can ping, patch, or reconfigure. It is a row in a vendor’s database. The moment you want to add a camera, a sensor, or an EV charger to that pole, the architecture has no clean answer.
- Firmware updates do not scale. Over-the-air updates through a low-bandwidth mesh are measured in days, sometimes weeks, for a large fleet. Rolling back a bad update is worse. We have seen fleets frozen on an old firmware version for two years because nobody trusted the update path.
RF mesh is not wrong. It is right for a campus, a port, a car park, an industrial site — bounded deployments with a few hundred nodes and a single owner. It is wrong for a city, because a city is not a bounded deployment and has more than one owner.
Generation 3: cellular-first, per-pole IP
The third generation gives every pole its own router, its own IP identity, its own SIM, and its own encrypted tunnel to the management platform. Bandwidth per pole goes from bytes per hour to megabits per second. Latency goes from minutes to tens of milliseconds. And — this is the part that matters commercially — the pole stops being a lighting endpoint and becomes a multi-tenant platform.
The objection is always the same: a monthly SIM fee per pole, forever. That objection was correct in 2015 and it is much weaker now, for two reasons. First, per-pole IoT data tariffs have fallen to a level where the connectivity opex is a small fraction of the energy saving the pole generates. Second — and this is the subject of the next section — the device cost at the pole has finally collapsed too.
The RedCap Inflection Point
Full 5G NR is over-specified for a light pole. A pole needs to carry a dimming command, a meter reading, a fault report, an occasional firmware delta, and maybe a burst of camera traffic. It does not need gigabit throughput. But for years the only way to get 5G core-network authentication, network slicing and a long standards runway was to buy a full 5G modem — and pay for it in money, in watts, and in cubic centimetres.
5G RedCap (Reduced Capability, introduced in 3GPP Release 17 and extended by eRedCap in Release 18) is the answer to that mismatch. It narrows the bandwidth, reduces the antenna count, and simplifies the modem — while keeping the device on the 5G core, with the same subscriber identity, the same authentication, the same slice and QoS framework, and the same operator roadmap as a full 5G device.
What that means concretely at the pole:
| Parameter | Full 5G NR (Sub-6) | 5G RedCap | LTE Cat 4 |
|---|---|---|---|
| Peak downlink | 1–2 Gbps | ~150–220 Mbps | 150 Mbps |
| Bandwidth | 100 MHz | 20 MHz | 20 MHz |
| Receive branches / MIMO | 4×4 typical | 1×2 or 2×2 | 2×2 |
| 5G standalone core | Yes | Yes | No (EPC) |
| Network slicing / 5G QoS | Full | Supported | No |
| Module cost and power | High | Substantially lower | Low |
| Suits a 15–20 year pole asset | Yes, but over-spec | Best fit | Sunset risk |
The last row is the one that decides it. A light pole is a 15 to 20 year civil asset. A cellular modem generation is a 7 to 10 year commercial reality. If you specify LTE Cat 4 today you are locking a twenty-year pole to a technology whose operator sunset is already being discussed in some markets. If you specify full 5G you are paying a premium that the application never consumes. RedCap is the only option that lines the technology lifetime up with the asset lifetime, which is exactly what a 5G RedCap router for smart poles should be judged on.
| A specification trap worth naming |
| RedCap availability is per-operator and per-market. Before you write “RedCap” into a tender, confirm your chosen MNO has it live on the bands your poles will use — and make sure the router you specify falls back cleanly to LTE where it does not. A RedCap router that cannot fall back is a liability, not a feature. |
This is why our pole-grade device is the H685frc: a 5G RedCap router at 100 × 60 × 21 mm and 220 g without antennas, which is small enough to disappear into the pole base compartment or a Zhaga-adjacent service cavity, and which falls back through 4G LTE where RedCap is not yet live. Two Gigabit Ethernet ports, four digital inputs/outputs, optional GNSS, optional serial, and PoE-PD on 802.3af/at/bt.
The Power Budget Nobody Models
Here is a specification error we see constantly: the router is chosen on peak throughput, and the deployment then fails on idle current.
A light pole is lit for roughly 4,000 hours a year. But the communications equipment inside it is on for 8,760. The energy a router draws at idle, multiplied by 8,760 hours and by 10,000 poles, is a real line in the operating budget — and, more importantly, it is pure overhead against the saving the project was funded to deliver. Every watt you spend on communications is a watt you have to justify to a finance department that thought it was buying an energy-saving project.
Run the numbers on a compact industrial router. At 12 V DC:
- Idle: typically 100 mA → about 1.2 W
- Transmitting / receiving: typically 300 mA → about 3.6 W
- Worst case: up to 800 mA → about 9.6 W, momentarily
Across a year at mostly-idle duty, that is on the order of 10–15 kWh per pole per year for the router alone. At 10,000 poles that is 100–150 MWh — noticeable, but crucially it is small relative to the 60–70 MWh per 1,000 poles that dimming typically saves. The communications layer costs you a few percent of what it enables. That is the argument that wins the internal review.
The second half of the power story is the opposite direction: the pole has to supply power, not just consume it. A camera, a LiDAR or radar traffic sensor, an environmental pod, a small cell, a digital signage panel — none of these come with their own mains drop. They expect Power over Ethernet. Which is why the PoE PSE industrial router for pole cameras matters more than any other single feature on the spec.
Our H900pf is the device we place where the pole has to feed something: a Gigabit 5G router with dual SIM and two LAN ports that act as PoE PSE at 802.3af / at / bt, delivered from a 48 V supply at 1 A, 1.5 A or 2 A depending on the load. One device terminates the cellular link, runs the tunnel, and powers the camera and the sensor pod — no separate PoE switch in the pole base, no second power supply, no second failure point, and one less truck roll when something needs replacing.
One more power detail that saves projects: dual power inputs with failover. On a pole fed from a lighting circuit that is switched at dusk, a single-input device will reboot every evening unless you take a permanent feed. Where a permanent feed is not available, dual inputs with automatic failover let you run from the switched circuit and a small backup, and the router survives the transition without a cold boot. It sounds like a trivial line item. On a 10,000-pole fleet, a reboot storm every evening at dusk will look exactly like a network outage in your monitoring, and your team will spend weeks finding it.
Heat, Water, and the Solar Chimney You Just Built
A light pole base is a small, sealed, sun-exposed steel cabinet sitting on hot asphalt. In a Gulf summer, or an inland Spanish or Australian summer, the internal air temperature of a pole base compartment routinely exceeds 60 °C and can approach 70 °C. Add the heat rejected by the LED driver and the power supply, and you have engineered — entirely by accident — a solar chimney.
Electronics rated to commercial temperature ranges will not survive that for a decade. They will not fail in month one either, which is what makes this dangerous: they will fail in year three, in a scattered pattern across the fleet, in a way that looks like random infant mortality rather than a design error. By the time the pattern is visible you have already replaced a few hundred units.
The specification to write into the tender:
| −35~75 °C |
| Ambient operating range |
| IP68 |
| Pole-mount outdoor option |
| 5–60 V |
| Wide DC input option |
| 5–95 % |
| Non-condensing humidity |
Note that −35 °C is the cold end, not the hot end, and it matters just as much: Nordic and Canadian municipalities need a device that cold-starts in January without a heater. Specifying 0 °C to 40 °C hardware into a municipal tender is a common and expensive mistake.
Water is the second killer, and here the question is not the router — it is where the router lives. There are two valid answers:
- Inside the pole base compartment, behind the locked service door. Use a fanless metal-enclosure router with a convection-cooled design and an IP30-class housing, mounted high in the compartment rather than low, with cable glands at the bottom and a drip loop on every cable. Keep it away from the driver’s heat.
- Outside the pole, where there is no usable compartment — which is most of the retrofit estate. Use a genuinely sealed device such as the H820QO: IP68, built-in high-gain cellular and Wi-Fi antennas with reserved connectors for external N-type antennas, and pole-mount as a first-class installation option rather than an afterthought bracket.
For teams writing the tender, the phrase to put in the schedule is IP68 pole-mount outdoor router, and the acceptance test is a hose, not a datasheet. We will take the sealed outdoor unit over a clever mounting bracket almost every time. A bracket is a field improvisation; an IP68 pole-mount design is tested as a system, including the antenna seals, which is where water actually gets in.
Anatomy of a Connected Pole
Once you accept that the router is the pole’s convergence device, the rest of the architecture becomes straightforward. Four interfaces matter, and each one has a failure mode if you get it wrong.
DI/DO: switching the luminaire
The simplest and most robust control path is still a relay. A digital output drives the lighting contactor; a digital input reads back the contactor state and the door switch. This is how you distinguish “the lamp is off because we commanded it off” from “the lamp is off because the driver failed” — a distinction your maintenance team will ask for within a month of go-live. Four DI/DO channels is the practical minimum: contactor out, contactor state in, door switch in, spare.
RS485: talking to the driver
On-off is table stakes; the real energy saving is in dimming. Modern luminaires accept DALI or 0–10 V, and in brownfield projects that usually means a small gateway translating one of them to Modbus over RS485 — the classic DALI and 0-10V dimming gateway over RS485 pattern. Route that into the router’s serial port and the CMS can command a dimming level per pole rather than per circuit. This is the interface that turns a 30 % saving into a 60 % saving, and it is the reason we keep a serial port on the pole device even though the network is entirely IP.
For legacy luminaire retrofit work, this is where we place the H820: a 4G LTE router with a DB9 RS232/RS485 serial port, five Gigabit Ethernet LAN/WAN ports, and PoE as either PD or PSE. It talks to the legacy dimming gateway over serial, aggregates anything else in the cabinet over Ethernet, and gives the segment a single managed uplink. It is the least glamorous device in the deployment and usually the one that makes the brownfield poles work.
GNSS: inventory, geofencing, and proof
Positioning sounds redundant on a pole — the city knows where the poles are. In practice it earns its place three times over. First, during installation: a contractor scanning a QR code and confirming GNSS coordinates catches poles physically wired to the wrong logical ID, which is otherwise discovered months later as a dimming anomaly on the wrong street. Second, for adaptive dimming with GNSS geofencing — the pole knows its own position and can derive local dusk and dawn without depending on a central schedule, so a network outage degrades to autonomous operation instead of to darkness or to lights-on-at-noon. Third, for audit: geotagged commissioning records are what let you prove to a funding body that 10,000 poles really were converted.
Ethernet and PoE: everything that arrives later
Cameras, sensors, small cells, EV chargers, signage — every revenue-generating tenant on the pole arrives over Ethernet, and most want power with it. Two PoE-capable ports is the difference between a lighting pole and a platform pole. Size for the tenant you do not have yet.
| Design rule we apply |
| Give every pole more interfaces than the lighting scope requires. The marginal cost of a serial port or a PoE port at tender time is a few euros. The marginal cost of retrofitting one into 10,000 installed poles is the entire project contingency. |
One Router, Three Tenants
A modern smart pole carries traffic belonging to organisations that actively do not trust each other. The lighting department owns the dimming commands. The police or a transport authority owns the CCTV. A commercial partner owns the public Wi-Fi or the digital signage. Each has a different security posture, a different uptime requirement, a different data-retention obligation, and a different appetite for being blamed when something goes wrong.
The naive answer is one router per tenant per pole — three boxes, three power supplies, three SIMs. That is three times the cost, three times the truck rolls, and three times the failure surface. The right answer is one router, logically partitioned with VLAN segmentation for lighting and CCTV traffic.
Concretely, on IEEE 802.1Q:
- VLAN 10 — Lighting OT. CMS commands, dimming, metering, fault reporting. Highest integrity requirement, lowest bandwidth. Strictly inbound-denied from the WAN; the pole initiates the tunnel, nothing initiates to the pole.
- VLAN 20 — CCTV and sensors. High bandwidth, bursty, tolerant of brief buffering. Separate QoS queue so a firmware-camera stream cannot starve a dimming command.
- VLAN 30 — Public / guest. Wi-Fi, signage, open data. Internet-only egress, no route to VLAN 10 or 20 under any circumstances, client isolation on. This is the segment that will be attacked first and most often.
- VLAN 99 — Management. Router itself, NMS, syslog, and out-of-band access. Reachable only from the operations network.
Add per-VLAN firewall rules and per-VLAN QoS, and the lighting tenant is mathematically unable to see camera traffic even though both cross the same box and the same SIM. When the CCTV contractor’s camera is compromised — and over a ten-year life, one will be — the blast radius stops at the VLAN boundary.
There is also a procurement benefit that is easy to miss. When the tenders for lighting, CCTV and Wi-Fi are awarded separately — which they usually are — a partitioned architecture lets each contractor have their own credentials, their own VLAN, and their own log stream, without any of them being able to touch another’s configuration. That is the difference between a multi-vendor project that runs and one that ends up in a dispute.
Your Lighting Network Is a Botnet With Arms and Legs
This is the section that gets skipped, and it is the section that ends projects. A fleet of 10,000 always-on, internet-reachable, physically accessible Linux devices distributed across every street in a city is an extremely attractive target. It is not a theoretical risk — compromised municipal IoT has been recruited into botnets before, and a lighting network is more attractive than most because the nodes are powered, permanent, and nobody looks at them.
The uncomfortable detail is physical: a light pole base is a locked door on a public street, at ground level, with no alarm. Assume an attacker will eventually open one. What can they reach?
Zones and conduits, applied to a street
The clean way to structure this is IEC 62443 zones and conduits for smart cities — the same model used in industrial control, mapped onto a municipal deployment:
- Enterprise / Operations zone. The CMS, the NMS, the PKI. Hardened, bastion-accessed, MFA, jump-hosted.
- DMZ zone. Where pole traffic terminates: VPN concentrators, broker, patch and update servers, syslog collectors. Nothing here trusts anything, and nothing here is trusted by the operations zone.
- Pole / field zone. 10,000 devices, physically exposed, individually untrusted. Each one authenticates, each one gets the minimum reach it needs, and none of them can address another.
Every crossing between zones is a conduit, and every conduit gets an explicit security control: IPsec or WireGuard for the tunnel, 802.1x or certificate-based authentication for device identity, and a zone-based firewall enforcing least privilege at each boundary. Pole-to-pole traffic is denied by default — there is almost no legitimate reason for one pole to talk to another, and denying it removes the single most useful lateral movement path an attacker has.
The shared-PSK antipattern
The single most common failure we see: one pre-shared key configured across the entire fleet, because it is easy to provision. The moment one pole is physically opened, the key is extracted, and it is valid for all 10,000. There is no way to revoke a device — only a fleet-wide rekey, which in practice means firmware and config trucks to every pole, which in practice means it never happens.
Use per-device certificates, issued at staging and rotated automatically, with a PKI that can revoke an individual pole. Combine that with signed firmware — the router refuses to boot an unsigned image — and a physical compromise gets you one device with no keys worth having, rather than a fleet credential.
Physical tamper as a first-class event
That unused DI channel from section 06? Wire it to the pole base door switch. Door opens, the router raises an alarm to the NMS within seconds, correlated with the pole ID and its GNSS position. It costs nothing — the input is already there — and it converts an invisible physical compromise into a logged, alertable, dispatchable event. Pair it with a cabinet-open timer so a maintenance crew that forgets to close a door also gets flagged.
Finally: log everything to a central collector. When something goes wrong — and over ten years, something will — the difference between a two-hour investigation and a two-week investigation is whether you have the syslog from the pole, the tunnel, and the platform, all with synchronised time. Ship logs to the DMZ collector, not to the pole’s own flash.
From Day-1 to Day-3000: Provisioning a Fleet You Cannot Touch
Commissioning 200 poles is a networking project. Commissioning 10,000 poles is a logistics project that happens to involve networking. The constraint is not bandwidth or coverage — it is that you cannot send a laptop-wielding engineer to every pole, and you cannot afford for the configuration to depend on which technician did which street.
Zero-touch provisioning for streetlight fleets is the answer, and it breaks into four stages:
Stage 1 — Identity before installation
Each pole gets an identity at the depot, not on the street: a pole ID bound to a device certificate, a SIM or eSIM profile, and a GNSS reference position from the survey. The installer’s job becomes purely physical — mount, terminate, scan a barcode, close the door. With eSIM and eUICC support, carrier profile selection can happen remotely after installation, which means you can change MNO on a fleet without touching a single SIM card.
Stage 2 — Auto-registration and zero-touch bootstrap
On first power the router brings up the cellular link, reaches a bootstrap endpoint, authenticates with its certificate, and pulls its configuration — VLANs, tunnel endpoints, CMS address, VLAN-to-port mapping, reporting intervals. TR-069 is the workhorse here, backed by an NMS that auto-registers the device against the expected pole ID and flags any mismatch for human review. A pole that registers at the wrong coordinates is caught on day one rather than discovered in month nine.
Stage 3 — Ring-based firmware rollout
Never update 10,000 poles at once. Push to a canary ring of 20–50 poles across representative geography, hold for 48 hours while you watch syslog and link statistics, then 5 %, then 25 %, then the remainder. Every stage needs an automatic abort and a rollback path — which in practice means the router must support dual bank firmware with a watchdog fallback, so a failed update reverts on its own rather than bricking the pole. A bricked pole is a truck roll; a rolled-back pole is a log entry.
Stage 4 — Steady-state telemetry and adaptive reporting
Design the payload before you buy the data plan. A pole in a steady state should be sending a heartbeat every 15 minutes and nothing else. Events — lamp failure, driver fault, door open, tunnel flap, dimming command — burst immediately. Firmware deltas are scheduled to off-peak windows. Getting this right typically halves the per-pole monthly data cost, which over 10,000 poles and ten years is a number large enough to matter in the tender.
The platform matters as much as the device here. A router that cannot be managed in bulk is a router you will manage one at a time, which means you will not manage it at all. Look for an NMS that does configuration templates, group policy, bulk firmware, per-device certificate lifecycle, and per-pole data usage reporting — and check that it exposes an API, because the CMS vendor will want to integrate with it.
The Truck Roll Is the Real Cost Line
Municipal tenders compare routers on unit price, which is the wrong comparison, because unit price is not the dominant cost. The dominant cost is sending a person in a van to a pole — which is why truck roll cost reduction for connected streetlights should be an explicit scoring criterion in the tender rather than an afterthought in the operations manual.
A truck roll — a technician, a vehicle, a bucket truck where the pole needs one, traffic management, and the administrative overhead of the work order — realistically lands somewhere between €80 and €150 for a simple ground-level visit, and several times that when a bucket truck and lane closure are involved. Now put that next to the device decision:
| Scenario | Unit delta | Truck rolls avoided | Net over 10 yrs, 10,000 poles |
|---|---|---|---|
| Pay €60 more for an industrial router with a 10-year design life instead of a commercial-grade unit | + €600,000 | ~4,000 avoided replacements | Decisively better |
| Pay €25 more for dual-SIM multi-carrier failover | + €250,000 | Every carrier-outage visit, plus every “is it the network?” diagnostic visit | Better |
| Pay €15 more for PoE PSE in the router instead of a separate pole PoE switch | + €150,000 | One fewer device to fail per pole | Better |
| Pay nothing extra for a door-switch DI input wired at install | €0 | Converts silent tamper into a dispatchable alarm | Free win |
The pattern is consistent: any device feature that removes one truck roll per pole over the asset’s life is worth more than a substantial unit-price increase. And the features that remove truck rolls are not the glamorous ones. They are dual-SIM resilience, dual-bank firmware with watchdog rollback, remote diagnostics good enough to tell you which of the three field-replaceable parts failed, and a wide input voltage range that tolerates a sagging circuit instead of brown-out rebooting.
| Field note |
| “The tender scored us on unit price and we won on unit price. Eighteen months in, we were doing 40 truck rolls a month, nearly all of them for devices that had simply rebooted and needed a hand-held reset. The cheapest line in the spreadsheet became the most expensive line in the project.” |
| Operations lead, municipal retrofit programme — shared with permission, details withheld |
This is also where dual-SIM failover for municipal lighting networks earns its keep, and not for the reason people expect. The value is not the extra uptime during a carrier outage — those are rare. The value is diagnostic: when a pole goes dark, a dual-SIM router can tell you definitively whether the failure is the local carrier, the wiring, or the device, without a site visit. Every ambiguous alarm you can resolve remotely is a truck roll you did not pay for.
And one more that belongs in the model: the pole is a revenue asset, and only a connected pole is a leasable one. Small cells, EV chargers, digital signage and environmental sensing all want pole space, and all of them will pay for it — but only if the pole already has managed, secure, segmented, bandwidth-provisioned connectivity. A pole with a router is leasable. A pole without one is a steel tube. In several programmes we have seen, the connectivity layer is what converts lighting from a cost centre into the host for three or four other revenue lines.
Picking the Right Router for the Pole
There is no single right answer, because poles are not all the same. What matters is matching the industrial cellular router for smart street lighting to the pole’s physical reality and to the tenant mix, rather than standardising on one model and forcing every pole into it. Here is the mapping we use.
| Model | Radio | Why it goes on a pole | Envelope |
|---|---|---|---|
| H685frc Pole-base fleet device | 5G RedCap + 4G LTE fallback | The volume device. 100 × 60 × 21 mm / 220 g fits a pole base compartment; 2× GbE, DI/DO × 4, optional serial and GNSS, PoE-PD 802.3af/at/bt, dual power inputs. Idle ~100 mA @ 12 V. | −35~75 °C 5–40 V DC (5–60 V opt) |
| H900pf Platform / tenant pole | 5G SA+NSA, dual SIM | PoE PSE on two LAN ports at 802.3af/at/bt (48 V 1 A / 1.5 A / 2 A) — powers camera and sensor pods without a separate switch. Use on the 10–20 % of poles carrying tenants. | −35~75 °C 168 × 104 × 25 mm |
| H820QO No-compartment pole | 4G LTE | IP68 with built-in high-gain cellular and Wi-Fi antennas, external N-type option, and pole mount as a designed installation. The retrofit answer where there is no usable pole base. | −35~75 °C 185 × 172 × 82 mm |
| H820 Legacy retrofit & segment aggregation | 4G LTE | DB9 RS232/RS485 for the DALI / 0–10 V dimming gateway and energy meter, plus 5× GbE LAN/WAN for everything else in the cabinet, PoE as PD or PSE, VLAN 802.1Q and VRRP. | −35~75 °C 168 × 104 × 25 mm |
| M400 Inventory & serial pipe | 4G LTE | Compact 83 × 53 × 25 mm modem with RS232/RS485/USB and GPS/BeiDou/GNSS. Commissioning-time asset capture, or a pure serial-to-cellular pipe where no routing is needed. | −35~75 °C RS232/485/USB |
One practical note on the retrofit estate specifically: budget for a site survey that classifies poles before you order hardware. The split between “has a usable base compartment”, “has a compartment but it is full of driver and cabling”, and “has no compartment at all” drives three different bills of materials, and discovering it at installation time is how schedules slip by a quarter.
Frequently Asked Questions
Q1：Can we just use the lighting vendor’s built-in radio instead of adding a router?
You can, and for a pilot you should. The problem appears when a second tenant arrives. A vendor-proprietary radio gets you lighting control and nothing else — no camera VLAN, no third-party sensor, no path to a small cell. If your ten-year plan includes any tenant beyond lighting, the per-pole router pays for itself the first time you avoid a second radio deployment.
Q2：Is private LTE or Wi-SUN a better fit than public cellular?
Private LTE is compelling when you control a bounded, dense site — a port, an airport, an industrial campus — and already own spectrum. It is much harder across a whole city, because the base station estate belongs to someone else and you inherit their deployment cost. Our usual recommendation is public cellular with per-pole tunnels as the default, and private LTE only where a specific site justifies its own RAN.
Q3：What happens to the lights if the cellular network goes down?
Design for graceful degradation, not for perfection. Each pole should hold a local schedule — astronomical dusk/dawn derived from its GNSS position and date — so a central outage means the lights still come on and go off correctly, just without adaptive dimming or fault reporting. Two SIMs from different carriers, plus a wired WAN where a segment cabinet has fibre, make a total connectivity loss genuinely rare.
Q4：How much data does a connected pole actually use per month?
A lighting-only pole with well-designed payloads sits comfortably in the tens of megabytes per month: a heartbeat every 15 minutes, event-triggered faults, and scheduled firmware. Add a camera and the number jumps by orders of magnitude — which is why cameras belong on a separate VLAN with their own QoS and their own budget, and why pole designs should never share one data plan across tenants.
Q5：Do we really need per-device certificates? Isn’t that overkill for a streetlight?
It is not overkill; it is cheaper than the alternative. The alternative is a shared pre-shared key, which means one physically opened pole compromises the fleet and revocation requires a fleet-wide rekey you will never actually perform. Certificate issuance can be automated at staging, so the operational burden is roughly zero, and the revocation story is the one your auditor will ask about.
Q6：What is the realistic service life of the communications hardware versus the pole?
The pole is 25–40 years, the luminaire 15–20, and the cellular router realistically 8–12 — limited more by modem generation sunset than by silicon wear. Design for that mismatch explicitly: specify industrial temperature ranges and a metal fanless enclosure so the router is not the first thing to fail, and keep it physically accessible so the modem generation can be swapped without replacing the whole pole assembly.
Q7：How do we handle the fact that two or three contractors all need access to the same pole?
Segment first, then delegate. Give each contractor their own VLAN, their own credentials, and their own log stream, and deny pole-to-pole and cross-VLAN routing by default. Most multi-vendor disputes on these projects trace back to a flat network where everyone could reach everyone and nobody could prove whose change broke what.
Q8：Can the router power the camera, or do we need a separate PoE switch in the pole?
On poles with tenants, use a router with integrated PoE PSE — the H900pf delivers 802.3af/at/bt from two LAN ports at 48 V. That removes a device, a power supply, a mounting bracket, and a future failure point from a compartment that is already too small. Keep a separate switch only where you need more powered ports than the router offers.
The pole was always the platform. The network is what makes it one.
City-scale smart street lighting is not a lighting project with some radios bolted on. It is the construction of a permanent, powered, city-wide edge network that happens to be funded by an energy-saving business case. Once you see it that way, the design priorities reorder themselves: per-pole IP instead of a proprietary mesh, because you will add tenants; 5G RedCap instead of full 5G or LTE Cat 4, because the asset outlives the modem generation; idle current instead of peak throughput, because the router runs 8,760 hours and the lamp runs 4,000; VLAN segmentation instead of three boxes, because the tenants do not trust each other; per-device certificates instead of a shared key, because the pole base door will eventually be opened; and zero-touch provisioning instead of laptop commissioning, because nobody is driving to 10,000 poles twice.
The unit price of the router is the least interesting number in that list. The number that decides whether the programme succeeds is how many times in ten years you have to send somebody to look at a pole.
Planning a connected lighting rollout?
Send us your pole inventory, tenant mix and coverage constraints. We will come back with a per-pole BOM, a power budget, and a provisioning plan you can put straight into a tender — no charge, no obligation.
