Skip to content
Illustration of a city skyline with a street pole carrying a CCTV camera and Wi-Fi, linked by fiber back to the network, for the TheWriter.id guide to GPON for smart city networks.

FTTH Network • Smart-city fiber

GPON for Smart City: What Fits, Camera Bandwidth Math and a Phased Rollout

By Junun Saleh · Updated · Built on ITU-T standards, a published smart-city GPON case and camera bitrate guidance, each linked below

A smart city is not one network. It is a few hundred poles, a few thousand endpoints and a dozen city departments that each want a connection yesterday. GPON can serve most of the fixed ones well, because it brings one fiber to many poles through a passive splitter. It is not the answer to everything, though, and the camera numbers decide more projects than the technology brochure does. This page shows where GPON fits, how to size camera backhaul, and how to roll out without overbuilding.

Quick answer: GPON suits fixed smart-city endpoints that send steady data from a pole or cabinet: CCTV, public Wi-Fi backhaul, traffic signal controllers, smart lighting and public address. It does not suit battery sensors (use LoRaWAN or NB-IoT), moving vehicles (use 5G or LTE) or hard real-time control (use dedicated Ethernet). GPON offers 1.244 Gbit/s upstream per port, so at a 60% planning load one port carries about 373 cameras at 2 Mbps each, or 149 at 5 Mbps. Start with one pilot district, build the shared poles, ducts and trunk fiber once, and add districts only after the pilot’s numbers hold.

In this page, GPON means a gigabit-capable passive optical network, standardised in ITU-T G.984, where one fiber from an optical line terminal (OLT) is split passively to many optical network terminals (ONTs). A PON port is one OLT interface and the shared capacity behind it. Planning load is the share of that capacity we allow for steady traffic, leaving headroom for peaks; this page uses 60%. Backhaul means carrying an endpoint’s traffic back to the city’s control room or data center.

Where does GPON fit in a smart city, and where does it not?

GPON fits fixed endpoints with steady data and a pole or cabinet to host an ONT. It does not fit endpoints that are mobile, battery-powered or in need of guaranteed real-time response. Sorting the city’s endpoints first saves you from forcing one technology onto every use.

A published case shows the fit. Tejas Networks describes a GPON network in the ELCITA industrial township in Electronic City, Bengaluru, built with OLTs at three access nodes and ONTs and switches on street poles. It covers more than 100 poles and 200 video cameras, and carries video surveillance, public announcement, smart lighting, smart waste management and Wi-Fi hotspots, with IoT devices integrated into the network operations center. The case study is from 2020, so treat it as a design example, not a current benchmark.

Which smart-city uses suit a passive optical networkTwo columns. Fixed endpoints with steady data, such as CCTV backhaul, public Wi-Fi backhaul, traffic signal controllers, smart lighting controllers and public address, suit a PON, and a light pulse runs down their fiber. Battery sensors, moving vehicles, city-wide aggregation and hard real-time control need other technology: LoRaWAN or NB-IoT, 5G or LTE, metro Ethernet or transport, and dedicated Ethernet.Suits a PONNeeds another technologyCCTV backhaulsteady video from fixed polesPublic Wi-Fi backhaulmany users, one shared uplinkTraffic signal controllersfixed, mains-powered, modest dataSmart lighting controllersfixed, small data, many nodesPublic address and signagefixed, modest dataBattery-powered sensorsLoRaWAN or NB-IoTMoving vehicles and people5G or LTECity-wide aggregationmetro Ethernet or transportHard real-time controldedicated Ethernet or ringIllustrative sorting. Confirm each endpoint's data rate, power and mobility.Which smart-city uses suit a passive optical networkTwo columns. Fixed endpoints with steady data, such as CCTV backhaul, public Wi-Fi backhaul, traffic signal controllers, smart lighting controllers and public address, suit a PON, and a light pulse runs down their fiber. Battery sensors, moving vehicles, city-wide aggregation and hard real-time control need other technology: LoRaWAN or NB-IoT, 5G or LTE, metro Ethernet or transport, and dedicated Ethernet.Suits a PONCCTV backhaulsteady video from fixed polesPublic Wi-Fi backhaulmany users, one shared uplinkTraffic signal controllersfixed, mains-powered, modest dataSmart lighting controllersfixed, small data, many nodesPublic address and signagefixed, modest dataNeeds another technologyBattery-powered sensorsLoRaWAN or NB-IoTMoving vehicles and people5G or LTECity-wide aggregationmetro Ethernet or transportHard real-time controldedicated Ethernet or ringIllustrative sorting. Confirm each endpoint.

Figure 1: Which smart-city uses suit a PON (illustrative). Fixed endpoints with steady data ride the fiber. Mobile, battery and real-time uses need something else.
Smart-city uses and the connection that suits them
Use Data profile Fit for GPON What to use instead, or alongside
CCTV Steady video, upstream-heavy Strong, if sized with the camera math XGS-PON for dense 4K clusters
Public Wi-Fi Many users, bursty Strong for backhaul to the access point Keep it on its own VLAN or port group
Traffic signals Fixed, modest data Good for controller backhaul Dedicated Ethernet or a ring where the agency requires guaranteed response
Smart lighting, public address Many nodes, small data Good; they already share poles LoRaWAN is an option for lighting-only networks
Battery sensors (waste, parking, air) Tiny readings, rare Poor; the ONT is overkill LoRaWAN or NB-IoT, with a gateway on a GPON pole
Vehicles and people on the move Mobile None 5G or LTE
City-wide aggregation Many PON ports combined Not its job Metro Ethernet or a transport network between OLT sites

The low-rate row matters. An overview of LPWAN in smart cities ties LoRaWAN and NB-IoT to streetlights, parking, waste, air quality and smart meters. It describes LoRaWAN as long range, up to 15 km, and NB-IoT as running on existing LTE networks. These sensors send small readings, so a gateway on a GPON pole can backhaul many of them at once. That is a better use of the pole than a dedicated ONT per sensor.

Choosing a connection for a smart-city endpointA decision path. If the endpoint is not at a fixed pole or cabinet, use 5G or LTE. If it does not send video or steady megabits, such as a small battery sensor, use LoRaWAN or NB-IoT. If it needs more than one PON port's share, use dedicated fiber or metro Ethernet. Otherwise use a GPON ONT on the pole and size it with the camera math.Endpoint to connectany smart-city deviceFixed location with a pole or cabinet?5G or LTEmobile endpointsNoSends video or steady Mbps?LoRaWAN or NB-IoTsmall, battery sensorsNoNeeds more than one PON port's share?Dedicated fiberor metro EthernetYesGPON ONT on the polesize it with the camera mathYesYesNoIllustrative decision path.Confirm with a design review.Choosing a connection for a smart-city endpointA decision path. If the endpoint is not at a fixed pole or cabinet, use 5G or LTE. If it does not send video or steady megabits, such as a small battery sensor, use LoRaWAN or NB-IoT. If it needs more than one PON port's share, use dedicated fiber or metro Ethernet. Otherwise use a GPON ONT on the pole and size it with the camera math.Endpoint to connectany smart-city deviceFixed location with a pole or cabinet?No5G or LTEmobile endpointsSends video or steady Mbps?NoLoRaWAN or NB-IoTsmall, battery sensorsNeeds more than one PON port's share?YesDedicated fiberor metro EthernetYesYesNoGPON ONT on the polesize it with the camera mathIllustrative path. Confirm with a design review.

Figure 2: A decision path for one endpoint (illustrative). Mobility, data profile and capacity share decide the connection.

Choose this if

Choose GPON if…

  • The endpoint is fixed on a pole or in a cabinet with power nearby.
  • It sends video or steady data to a central control room.
  • Several services share the same pole, so one ONT can serve them.
  • You want a passive, unpowered splitter network that is cheap to maintain.
  • The camera math shows headroom on each PON port.

Choose another technology if…

  • The device is battery-powered and sends tiny readings: LoRaWAN or NB-IoT.
  • It moves, such as a vehicle or a person: 5G or LTE.
  • One site needs more than a PON port’s share: dedicated fiber or metro Ethernet.
  • The agency requires a guaranteed response time: dedicated Ethernet or a ring.
  • You are linking OLT sites together: metro Ethernet or transport.

How many CCTV cameras can one GPON port carry?

About 149 to 373 cameras per port at a 60% planning load, depending on resolution. Camera video flows upstream, so the upstream rate sets the limit. ITU-T G.984 GPON offers 2.488 Gbit/s downstream and 1.244 Gbit/s upstream, with a passive splitter of 32 or 64 outputs, according to ITwissen. The upstream is shared by every ONT on the port.

Step 1: pick a bitrate per camera

Bitrate depends on resolution, frame rate, codec and how busy the scene is. Video Experts Group’s recommended settings give typical H.265 ranges for 15–30 fps with moderate motion, and note that busy streets may need more. Use the top of the range for planning. When the camera count outgrows GPON, our XGS-PON network design guide shows the next step, and GPON to XGS-PON migration covers the upgrade order.

Cameras per GPON port at a 60% planning load
Camera class (H.265) Typical bitrate Planned at Cameras per port Per pole if all 64 ONTs are full
1080p 1–2 Mbps 2 Mbps 373 5
4 MP 2–3 Mbps 3 Mbps 248 3
4K (8 MP) 3–5 Mbps 5 Mbps 149 2

Step 2: apply the planning load

Our rule is to plan steady traffic at 60% of the upstream, which leaves headroom for motion peaks, Wi-Fi backhaul and growth. That is 1,244 Mbps × 60% = 746 Mbps usable. Divide by the planned bitrate and round down: 746 ÷ 2 = 373, 746 ÷ 3 = 248 and 746 ÷ 5 = 149. The 60% figure is a design choice, not a standard, so change it to match your own risk tolerance.

Cameras per GPON port at a 60 percent planning loadA bar chart. With 746 megabits per second usable on a GPON port's 1,244 megabit upstream, a port carries about 373 cameras at a planned 2 megabits each (1080p H.265), 248 cameras at 3 megabits (4 megapixel) and 149 cameras at 5 megabits (4K). XGS-PON upstream is about eight times larger.Cameras one GPON port can carry at a 60% planning loadUpstream 1,244 Mbps x 60% = 746 Mbps usable (our planning rule)1080p, H.2651–2 Mbps, planned at 2 Mbps373 cameras4 MP, H.2652–3 Mbps, planned at 3 Mbps248 cameras4K (8 MP), H.2653–5 Mbps, planned at 5 Mbps149 camerasXGS-PON upstream is 10 Gbit/s, about 8 times the headroom of GPON.Cameras per GPON port at a 60 percent planning loadA bar chart. With 746 megabits per second usable on a GPON port's 1,244 megabit upstream, a port carries about 373 cameras at a planned 2 megabits each (1080p H.265), 248 cameras at 3 megabits (4 megapixel) and 149 cameras at 5 megabits (4K). XGS-PON upstream is about eight times larger.Cameras per GPON port, 60% load746 Mbps usable of 1,244 Mbps upstream1080p, H.2651–2 Mbps, planned at 2 Mbps3734 MP, H.2652–3 Mbps, planned at 3 Mbps2484K (8 MP), H.2653–5 Mbps, planned at 5 Mbps149XGS-PON upstream is 10 Gbit/s,about 8 times GPON's headroom.

Figure 3: Cameras one GPON port can carry at a 60% planning load (illustrative). Higher resolution means fewer cameras per port.

A worked example (illustrative)

Looks fineA district plans 4 cameras at 4 MP on every pole and a full 1:64 split. That is 64 × 4 × 3 Mbps = 768 Mbps on one port.
Fix it768 Mbps is above the 746 Mbps planning load, before any Wi-Fi traffic. Use a 1:32 split (384 Mbps), move some poles to a second PON port, or step up to XGS-PON.

Step 3: decide when to move to XGS-PON

ITU-T G.9807.1 defines XGS-PON at a nominal 10 Gbit/s in both directions, about eight times GPON’s upstream. If the camera math fails on a district, or you plan to add 4K cameras and analytics later, specify an OLT and splitter design that can move up without re-laying fiber. Where the math passes with headroom, GPON stays the lower-cost option.

Where PoE-powered endpoints fit

The fiber does not carry power, so each pole needs its own. The usual design is mains power to a cabinet, an ONT, and a PoE switch that powers the cameras and the Wi-Fi access point over copper. IEEE 802.3 port limits are 15.4 W (802.3af), 30 W (802.3at) and up to 90 W (802.3bt). Add up the peak draw of every endpoint, including pan-tilt-zoom cameras and heaters, and keep the total under the switch budget. Read the data sheet’s peak draw, not its typical draw.

Powering cameras on a PON poleA flow from the optical line terminal through a passive 1 to 64 splitter to a pole ONT, then a PoE switch that powers a fixed camera, a PTZ camera and a Wi-Fi access point. A note says to add the peak draw of every endpoint and keep the total under the switch budget.One pole: fiber in, power and data outOLThub or exchange1:64Pole ONTin the cabinetPoE switchsums peak drawFixed cameraPoEPTZ cameraoften higher PoEWi-Fi APcheck peak drawAdd the peak draw of every endpoint and keep the total under the switch budget.Port limits: 802.3af 15.4 W, 802.3at 30 W, 802.3bt up to 90 W.Powering cameras on a PON poleA flow from the optical line terminal through a passive 1 to 64 splitter to a pole ONT, then a PoE switch that powers a fixed camera, a PTZ camera and a Wi-Fi access point. A note says to add the peak draw of every endpoint and keep the total under the switch budget.OLThub or exchange1:64 splitterpassive, no powerPole ONTin the cabinetPoE switchsums peak drawFixed cameraPoEPTZ camerahigher PoEWi-Fi APcheck drawAdd every endpoint's peak draw.Keep the total under the switch budget.802.3af 15.4 W, 802.3at 30 W, 802.3bt up to 90 W.

Figure 4: One pole, fiber in and power out (illustrative). The ONT and PoE switch share a cabinet. The splitter upstream needs no power.

Before the crew goes out, give them a checklist. TheWriter.id’s free Technician Checklist Generator builds a pre-installation list for field technicians, which suits repeated pole installs where every ONT, switch and camera must be checked the same way.

How should a city phase a GPON rollout?

Start with one pilot district, build the shared infrastructure once, then repeat the proven pattern. The expensive parts of a smart-city network are the poles, ducts, power and trunk fiber. They are also the parts you can build once and share, so a phased plan spends most of the money where it is reused. For ducts under streets, see underground FTTH network design.

A phased smart-city GPON rolloutThree phases shown in order. Phase 1 pilot district: one of twelve districts live. Phase 2 shared backbone: four of twelve live. Phase 3 city coverage: all twelve live. A light pulse moves along a timeline and each phase highlights in turn.A start-small plan, illustrative city of 12 districtsPhase 1: pilot districtProve the design, the buildand the operations1 of 12 districts livePhase 2: shared backboneExtend the trunk and openmore districts4 of 12 districts livePhase 3: city coverageRepeat the proven patterndistrict by district12 of 12 districts liveA phased smart-city GPON rolloutThree phases shown in order. Phase 1 pilot district: one of twelve districts live. Phase 2 shared backbone: four of twelve live. Phase 3 city coverage: all twelve live. A light pulse moves along a timeline and each phase highlights in turn.A start-small plan, illustrative 12 districtsPhase 1: pilot districtProve the design, the build and the operations1 of 12 districts livePhase 2: shared backboneExtend the trunk and open more districts4 of 12 districts livePhase 3: city coverageRepeat the proven pattern district by district12 of 12 districts live

Figure 5: A start-small plan for an illustrative city of 12 districts. One pilot, then a shared backbone, then city coverage.
  1. Pick a pilot district that shows real mixed use. Include CCTV, public Wi-Fi and a few controllers on shared poles, so the pilot tests the worst case for a port.
  2. Measure before you scale. Record upstream load per PON port, PoE headroom per pole and the time to repair a fault. These are the three numbers that decide whether phase 2 is safe.
  3. Build shared infrastructure once. Lay the trunk with spare fibers, size ducts for the full city and give each pole power and space for an ONT and switch.
  4. Add districts by repeating the pattern. Each new district is a splitter, some ONTs and a few cameras. If a port passes its planning load, add a port or move up to XGS-PON.
  5. Hand over to operations early. Write procedures, naming and escalation rules during the pilot, so the network operations center runs district two the way it ran district one.
Shared infrastructure layers for a smart-city PONThree stacked layers. At the bottom, poles, ducts and power are built once and shared by every service. In the middle, the fiber trunk, splitters and OLT ports are laid with spare fibers and extended per district. On top, services such as cameras, Wi-Fi, signals and lighting are turned on one at a time. A light pulse rises through the layers.ServicesTurned on per phase, one by oneFiber trunk, splitters and OLT portsSpare fibers laid once; splitters added per districtPoles, ducts and powerBuilt once, shared by every serviceCamerasWi-FiSignalsLightingIllustrative. Build the bottom layers once, then add services as each phase proves out.Shared infrastructure layers for a smart-city PONThree stacked layers. At the bottom, poles, ducts and power are built once and shared by every service. In the middle, the fiber trunk, splitters and OLT ports are laid with spare fibers and extended per district. On top, services such as cameras, Wi-Fi, signals and lighting are turned on one at a time. A light pulse rises through the layers.ServicesTurned on per phase, one by oneFiber, splitters, OLT portsSpare fibers laid onceSplitters added per districtPoles, ducts and powerBuilt once, shared by every serviceCamerasWi-FiSignalsLightingBuild the bottom layers once, then addservices as each phase proves out.

Figure 6: Shared infrastructure layers (illustrative). Poles, ducts and trunk fiber are built once. Services are turned on one by one as each phase proves out.
A phased plan and the test for moving on
Phase What you build Prove before moving on
1. Pilot district One OLT site, splitters, ONTs on a set of poles, CCTV and Wi-Fi Port load stays under the planning load; PoE headroom holds; faults are repaired to target
2. Shared backbone Trunk with spare fibers, ducts and power for more districts; second OLT card if needed New districts come up from the same pattern with no redesign
3. City coverage Repeat per district; add services such as signals and lighting as each proves out Operations runs every district from the same procedures

Indonesia shows why the national backbone and the street network are separate jobs. A 2018 DCD analysis reported that the Ministry of Communications and Informatics launched its “100 smart cities” initiative in 2017, and described the Palapa Ring as a national backbone of about 12,000 km of fiber. The article is dated, but the point stands: a backbone does not give each district its own last-mile design. That is what a pilot district tests.

Plan the maintenance notice too. A planned outage on a pole network affects the traffic center, the police control room and public Wi-Fi users at once. Write the notices before the work. TheWriter.id’s free Outage Message Generator drafts copy-ready messages for email, SMS and status pages.

What should you confirm before committing to GPON for a smart city?

Confirm the endpoints, the camera math, the power and the pilot, in that order. This list turns the sections above into questions for a vendor or an integrator.

  • Which endpoints are fixed with steady data, and which are battery-powered, mobile or real-time?
  • What camera resolution, codec and bitrate will you plan at, and why?
  • How many cameras per PON port at your planning load, and does every district pass?
  • What split ratio will each port use, and what is the worst-case load on a full split?
  • What is the peak power draw per pole, and does the PoE switch budget cover it?
  • Can an OLT and splitter design move a district to XGS-PON without re-laying fiber?
  • How will OLT sites be linked together, and by what technology?
  • Is the pilot district defined, with measures for port load, PoE headroom and repair time?
  • Who writes the operations procedures, and when?

GPON for smart city: frequently asked questions

What is GPON in a smart city?

GPON (Gigabit-capable passive optical network) is a fiber access technology standardised in ITU-T G.984. One fiber from an optical line terminal (OLT) is split passively to serve many optical network terminals (ONTs). In a smart city the ONTs sit on poles and in street cabinets, where they connect cameras, public Wi-Fi access points and controllers.

Can GPON carry CCTV for a whole city?

Yes, when each PON port is sized for the video it carries. GPON offers 2.488 Gbit/s downstream and 1.244 Gbit/s upstream, and camera video flows upstream. At a 60% planning load that is about 746 Mbps per port, or roughly 373 cameras at 2 Mbps each. Busy streets and higher resolutions need fewer cameras per port.

How many cameras can one GPON port support?

With our planning rule of 60% of the 1,244 Mbps upstream, one port supports about 373 cameras at 2 Mbps (1080p H.265), 248 at 3 Mbps (4 MP) or 149 at 5 Mbps (4K). Subtract Wi-Fi backhaul and other traffic on the same port first. The bitrates are typical ranges, so measure your own scenes.

Should a smart city use GPON or XGS-PON?

XGS-PON is defined in ITU-T G.9807.1 with a nominal 10 Gbit/s in both directions, about eight times GPON's upstream. It suits dense 4K camera clusters and long-life networks. GPON remains a sound, lower-cost choice for districts where the camera math shows enough headroom. Plan the OLT and splitter design so a district can move up later.

Do smart-city poles need separate power for cameras?

Fiber carries light, not power, so the pole needs its own supply. Most designs bring mains power to a cabinet and use a PoE switch to power cameras and access points over copper. Add up the peak draw of every endpoint and keep the total under the switch budget: 802.3af offers 15.4 W, 802.3at 30 W and 802.3bt up to 90 W per port.

Which smart-city uses do not suit GPON?

Battery-powered sensors that send tiny readings suit LPWAN options such as LoRaWAN or NB-IoT. Moving vehicles and people need 5G or LTE. City-wide aggregation and hard real-time control usually need metro Ethernet, transport networks or dedicated links. GPON suits fixed endpoints with steady data and a pole or cabinet to host an ONT.

Sources

  1. ITU-T: Recommendation G.984.1, Gigabit-capable passive optical networks (GPON): General characteristics
  2. ITU-T: Recommendation G.9807.1, 10-Gigabit-capable symmetric passive optical network (XGS-PON), summary (02/2023)
  3. ITwissen: gigabit PON (GPON), line rates and splitter outputs
  4. Tejas Networks: ELCITA smart township GPON case study (2020)
  5. Video Experts Group: Recommended bitrate settings
  6. Newark: LPWAN connectivity is boosting smart infrastructure in a smart city scenario
  7. DatacenterDynamics: The shape of smart cities in Indonesia (20 March 2018)

Figures 1 to 6, the planning load (60%), the camera-per-port numbers and the phased plan are our illustrations and recommendations, not published standards. Camera bitrates are typical ranges and vary with scene, frame rate and codec; measure your own. The Tejas case study (2020) and the DCD article (2018) are older sources. PoE port limits are the IEEE 802.3 values. Confirm split ratio, optical budget and equipment limits with your vendor.