Handing a subscriber "100 Mbps" on a GPON OLT takes three templates that must agree with each other — a DBA profile for the upstream average, a traffic policing profile for the peak, and a service profile that binds both to a GEM Port and a VLAN. Change one layer and leave the others alone, and the package either does not take effect or quietly outperforms its own limit.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
What follows is how the parameters interact, why a single wrong burst value stalls a speed test at 40–60 Mbps, and a full worked example for 100 subscribers on a 100M/50M plan. Every GPON network pairs a shared upstream with a broadcast downstream, and the two are limited in different places.
Committed Access Rate is the enforcement mechanism, defined in RFC 2697 for single-rate three-colour marking and RFC 2698 for the dual-rate variant. In practice four values have to be filled in:
CIR (Committed Information Rate) — the committed rate, the long-term average the network guarantees. Traffic below it is treated as green and passed.
CBS (Committed Burst Size) — the committed burst, which is the depth of the token bucket. CIR is how fast fuel is added; CBS is how big the tank is.
PIR (Peak Information Rate) — the peak rate. Traffic above it is dropped or re-marked.
PBS (Peak Burst Size) — the peak burst allowance.
There are three things you can do to over-rate traffic: drop it, re-mark it (usually lowering the DSCP or 802.1p priority) and pass it. Home broadband nearly always drops. A campus network that cannot afford to hurt a critical application will choose remark, demoting excess traffic to a lower queue instead of discarding it.
CBS matters more to the user experience than CIR does. The bucket depth sets how much burst the link tolerates. Set CBS too small and TCP slow start trips the bucket the moment the window exceeds it: the first batch of packets is dropped, retransmission and congestion-window backoff follow, and measured throughput can settle at 30%–50% of the nominal rate. Set it too large — a few hundred megabytes, say — and the limiter becomes decorative, because a burst can occupy the upstream before the shaper reacts.
A workable way to pick it is the in-flight data for one round-trip time. At 100 Mbps with a 20 ms RTT, in-flight data = 100 Mbps x 20 ms / 8 = 250 KB. A CBS of 250–500 KB covers exactly one RTT, so TCP does not retransmit because the tank is too small.
The two directions use different machinery, and getting the direction wrong is a common mistake.
Downstream (OLT to ONU) is enforced on the OLT. Downstream is a broadcast, and the OLT knows which GEM Port each frame belongs to and which ONU receives it. Limiting can be applied at GEM Port, ONU or subscriber-port granularity, by traffic shaping (buffer, then transmit at the rate) or policing (drop above the rate). Traffic shaping is friendlier to applications but consumes OLT buffer and adds latency under congestion.
Upstream (ONU to OLT) needs DBA plus shaping on the ONU. DBA, defined in ITU-T G.984.3, allocates upstream timeslots per T-CONT, and what it guarantees is a long-term average: a Type 4 T-CONT with a 50 Mbps maximum is not throttled below 50 Mbps in any arbitrary 10 ms window. Without local shaping on the ONU, a burst goes straight into the upstream timeslot and affects other subscribers on the same PON port. The correct approach is therefore two-sided: the DBA profile governs the average, and CAR on the ONU or OLT side governs the peak.
Configure DBA without CAR and a single subscriber running a BitTorrent download will still crowd out the neighbours, even though the average is capped — the complaint shows up as "other people's web pages sometimes will not open". Configure CAR without DBA and the T-CONT never gets enough slots, so the rate limit is meaningless.
| Direction | Enforcement point | Mechanism | Parameter carrier |
|---|---|---|---|
| Downstream | OLT side | Shaping or policing, per GEM Port or per ONU | Port traffic profile |
| Upstream (average) | OLT DBA engine | Timeslot allocation per T-CONT (G.984.3) | DBA profile |
| Upstream (peak) | ONU side or OLT CAR | Token bucket clipping | Port traffic profile |
| Priority | 802.1p field in the 802.1Q tag | 3 bits, values 0–7 | Service profile / mapping rule |
On a GPON network a package is really three templates bound in a fixed order:
DBA profile — the T-CONT type and its bandwidth (Type 4 fills in only the maximum; Type 5 adds a guaranteed rate).
Port or subscriber traffic profile — the CAR values CIR / CBS / PIR / PBS and the over-rate action.
Service profile — ties GEM Port, VLAN, priority and traffic profile together and produces the service-port.
Two binding mistakes are typical. One is a service profile pointing at a traffic profile that does not exist: the device either errors out or silently ignores it, and the result is a plan that says 100M but is not actually rate-limited. The other is a traffic profile whose PIR is lower than the DBA profile's maximum, which means the subscriber can never measure the nominal rate, because the bottleneck sits one layer earlier.
There is a stability rule worth memorising: the DBA profile's maximum must be less than or equal to the port traffic profile's PIR. An upstream DBA max of 50 Mbps with a port PIR of 50 Mbps is self-consistent. A DBA of 100 Mbps with a limit of 50 Mbps doubles the upstream slot requests — the line will not actually saturate, but the scheduler is reserving resources for traffic that will never exist.
This is the payoff of templating a rollout. There are three cases, by type of change:
Rate change only (100M to 200M). Change the DBA profile maximum or the traffic profile PIR, and re-issue to the associated ONUs. GEM Port, VLAN and service-port do not change, subscriber traffic is not interrupted, and measured effect is usually inside one second.
VLAN or service-type change. The service-port must be rebuilt, which causes a second-scale interruption the subscriber may notice as a brief drop.
ONU model or capability change. The ONU must re-register, so the interruption follows the registration sequence, typically 20–30 seconds.
Two boundaries should be settled up front. A template that is referenced cannot be deleted, only modified, so template IDs have to be planned correctly the first time. And on some implementations a template change only takes effect after the ONU re-registers, which turns a transparent change into a 20-second outage — verify the effective path with a test ONU before going live.
The scenario: a dual-PON OLT, 2.488 Gbit/s downstream per port and 1.244 Gbit/s upstream, 100 subscribers on one PON port, plan 100 Mbps down and 50 Mbps up.
Step 1 — usable bandwidth. Deduct encapsulation and protocol overhead at 90% efficiency: 2.24 Gbit/s down, 1.12 Gbit/s up.
Step 2 — oversubscription ratio. Downstream subscription 100 x 100 Mbps = 10 Gbit/s, so the ratio is 10 / 2.24 ≈ 4.5:1. Upstream subscription 100 x 50 Mbps = 5 Gbit/s, so 5 / 1.12 ≈ 4.5:1. Both sides match, which confirms that the plan's 2:1 up/down split lines up with the PON port's 2.488:1.244 = 2:1. The plan is sound.
Step 3 — per-subscriber share. Downstream 2.24 Gbit/s / 100 ≈ 22.4 Mbps; upstream 1.12 Gbit/s / 100 ≈ 11.2 Mbps. Those two figures are the ceiling on "guaranteed bandwidth" — writing anything higher is overselling.
Step 4 — check against a concurrency assumption. Assume 30% of subscribers at full rate in the evening peak: 30 x 100 Mbps = 3 Gbit/s, above the 2.24 Gbit/s available, so it cannot hold. The peak has to be clipped by CAR: set PIR to 100 Mbps so a single subscriber can use the full rate briefly for the experience, and rely on statistical multiplexing overall — 30% concurrency is a long-standing planning figure and the probability of everyone saturating at once is lower. If the project requires "never below 50M under any circumstance", size at 2.24 G / 0.1 G = 22 subscribers per PON port, which cuts the subscriber count by nearly four times.
Step 5 — CAR values. Downstream: CIR 0 (no commitment on home broadband), PIR 100 Mbps, CBS set to one RTT of in-flight data at 250 KB, PBS 250 KB, over-rate action drop. Upstream: CIR 0, PIR 50 Mbps, CBS 125 KB (50 Mbps x 20 ms / 8), PBS 125 KB. Set the DBA profile at Type 4 with a 50 Mbps maximum, matching the upstream PIR.
Step 6 — what CBS actually tolerates. At 100 Mbps, 250 KB sustains a burst of 250 x 1024 x 8 / 100e6 ≈ 20.5 ms. That covers one RTT of in-flight data, so TCP slow start does not hit the bucket. Push CBS down to 16 KB and the tolerance falls to 1.3 ms: the slow-start window exceeds it almost immediately, retransmission follows, and the speed test settles in the 40–60 Mbps range. "The limit value is right but the speed test will not climb" is the complaint this causes, and this is usually why.
The snippet uses generic syntax to show the options and their order; it is not a real command line from any vendor.
; Step 1: create the DBA profile (upstream average rate) add dba-profile profile-id 20 type4 max 50000 ; Step 2: create the port traffic profile (CAR parameters, peak clipping) add traffic-profile profile-id 20 cir 0 pir 100000 cbs 256000 pbs 256000 exceed-action drop ; Step 3: create the service profile binding GEM Port, VLAN and traffic profile add service-profile profile-id 20 gem 1 vlan 100 traffic-profile-id 20 priority 0 ; Step 4: push to the ONUs (template parameter changes apply in bulk, no restart) ont modify 0 1 ont-lineprofile-id 10 ont-srvprofile-id 20 service-port 100 vlan 100 gpon 0/1/1 ont 1 gemport 1 traffic-profile-id 20
The order in step 3 cannot be reversed: the GEM Port has to exist in the line profile before the service profile has anything to bind. The bulk push in step 4 is where templating pays off — changing 100 subscribers by hand is measured in person-days, and by template in minutes.
| Risk | Symptom | Mitigation |
|---|---|---|
| CBS too small | Speed test stuck at 40%–60% of nominal, high retransmission | Set CBS to 1–2 RTT of in-flight data |
| PIR below DBA max | Nominal rate never measurable | Align the two layers; DBA max ≤ upstream PIR |
| DBA without CAR | One subscriber's burst crowds out the same PON port | Add CAR on the ONU or OLT side upstream |
| Traffic profile referenced by a service profile | Template can be neither changed nor deleted | Plan template IDs up front; make changes as parameter edits |
| Policing instead of shaping downstream | Packet loss under congestion, blocky video artefacts | Use shaping for latency-sensitive services |
| Template change requires ONU restart | A transparent change becomes a 20–30 second outage | Verify the effective path with a test ONU before rollout |
| Oversubscription sized to peak | Either cost runs away or experience collapses | Fix the concurrency assumption first, then derive the subscriber ceiling |
One more point is easy to miss: rate limiting itself consumes OLT processing. GEM Port granularity needs more table entries and more forwarding-path overhead than ONU granularity, and at scale — a hundred GEM Ports per port each with its own limit — forwarding performance suffers. For home broadband, where each subscriber has one set of parameters, prefer ONU or subscriber-port granularity and reserve GEM Port granularity for dedicated-line customers who need their own policy.
Fix the concurrency assumption first. 30% for home broadband, 60%–80% for enterprise lines; this number sets the subscriber ceiling.
Check the up/down ratio. The closer the plan's split is to the PON port's split, the more balanced the oversubscription.
Align the parameters. DBA max ≤ upstream PIR; downstream PIR = the plan's downstream rate.
Pick CBS by RTT. Compute it as bandwidth x RTT / 8 rather than guessing a small round number.
Choose the over-rate action. Drop for home broadband, remark for critical campus traffic.
Verify the change path. Test whether a template edit needs an ONU restart before going live.
Plan template IDs. Leave a reserved block for expansion so a referenced template never blocks a later change.
Rayin's L102P 2-port GPON mini OLT issues DBA and traffic profiles per ONU, with 2xGE plus 1xSFP+ 10GE uplinks for connecting to a campus Layer 3 network; the PON access solution page lists the full port and capacity figures. Where the OLT uplink lands on a Layer 3 switch, the industrial switch solution page covers that side.
The plan was changed to 200M but the speed test still reads 100M. Why? Two frequent causes. Either the traffic profile PIR was not changed along with the DBA profile maximum — upstream is bound by DBA, downstream by PIR, so changing one layer produces nothing. Or the change was never actually pushed to the ONU, because the template was edited but not re-bound. Check the active limit values on the device first, then work out whether the bottleneck sits on the access side or the uplink.
Can CIR be set for home broadband too? It can, at a cost. Setting CIR commits guaranteed bandwidth, and 100 subscribers at 22 Mbps each would consume the entire 2.24 Gbit/s downstream, giving up the benefit of statistical multiplexing and roughly doubling cost. That is why home broadband generally uses CIR 0 with a PIR limit and spreads cost through oversubscription; enterprise dedicated lines set CIR because the customer is buying "never below this value".
What CBS value is right? Take one RTT of in-flight data: bandwidth x RTT / 8. At 100 Mbps and 20 ms that is 250 KB; at 10 Mbps and 20 ms, 25 KB. Below that value TCP throughput suffers; above roughly twice it, burst tolerance is so wide the limit becomes decorative. Below 10 Mbps — a 1 Mbps narrowband plan, say — keep CBS at no less than 8–16 KB, or a single TCP window will not fit.
Why limit upstream on both sides instead of one? With DBA alone, bursts leak through and affect other subscribers on the same PON port. With CAR alone, the T-CONT never receives enough slots and the limit never has a chance to be reached. The two work together because DBA decides what can be drawn over the long run and CAR decides how high a single instant can spike. This is also why upstream problems are harder to diagnose than downstream: downstream has one enforcement point, upstream has two, and their parameters must line up.
How many subscribers can one OLT carry — is it set by split ratio or by bandwidth? Both constraints apply, and the smaller one wins. The split ratio comes from the optical power budget: a Class B+ module gives 28 dB, a two-stage 1:32 split costs about 17.7 dB of insertion loss, and after leaving margin for connectors and ageing there is usually room for 1:64 or even 1:128. The bandwidth constraint comes from upstream capacity: 100 subscribers on a 50M upstream plan is already at a 4.5:1 oversubscription, so more subscribers means either a lower plan or another PON port. In real projects bandwidth tends to run out first, while the split ratio still has headroom.
About the author: Sara — Customer Manager at Shenzhen Rayin Technology Co., Ltd., 10+ years helping ISPs and integrators build industrial networks.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
