A GPON T-CONT decides how much upstream timeslot an ONU gets and when it gets it; a GEM Port decides whose traffic that timeslot is carrying. GPON downstream is broadcast, upstream is time-division multiplexed. ITU-T G.984.2 fixes the line rate at 2.488 Gbit/s downstream and 1.244 Gbit/s upstream with a 28 dB Class B+ optical budget, so that 1.244 Gbit/s upstream pipe is shared by every ONU on the port. Who transmits in which slot, and for how long, is decided by the OLT's DBA (dynamic bandwidth assignment) engine — and the smallest unit that engine accounts for is the T-CONT, the transmission container defined in ITU-T G.984.3 and identified by an Alloc-ID.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
Once traffic enters that container it still needs a label, or the OLT receives a pile of unclaimed GEM frames. The GEM Port (GPON Encapsulation Method port) is that label: G.984.3 gives the GEM Port ID 12 bits, so a single PON port can theoretically number 4,096 of them. How many service streams you split a subscriber into depends on the mapping between GEM Port and VLAN.
The division of labour is one sentence long. T-CONT answers "how many timeslots, and when"; GEM Port answers "whose business is riding this slot". Configuring a T-CONT is capacity planning, configuring a GEM Port is service routing, and neither can substitute for the other.
T-CONT comes in five types, and the difference is how three parameters — fixed bandwidth, assured bandwidth, maximum bandwidth — are combined. The original G.984.3 classification is still the underlying logic of every vendor's template today, even if each interface names it differently.
| Bandwidth behaviour | Typical service | Cost and caveat |
|---|---|---|
| Fixed | E1 leased line, TDM emulation, clock synchronisation | Slots are permanently reserved and never released when idle — the lowest utilisation of the five |
| Assured | VoIP voice, signalling channels | Set it too low and calls drop; set it too high and upstream capacity is wasted |
| Assured + non-assured | Video conferencing, enterprise leased line | The non-assured part is squeezed under congestion and must be excluded from the contract SLA |
| Best effort | Residential broadband | Only a maximum is set, so queues form at the evening peak |
| Fixed + assured + maximum | Residential multi-service, enterprise integrated access | The most parameters, and the longest fault-finding chain when something is misconfigured |
Residential deployments are overwhelmingly Type 4 and Type 5; Type 1 shows up almost only in leased-line projects. Be careful with the non-assured portion of Type 3 and Type 5: it is not written into the contract SLA, so when a subscriber complains you have nothing to point at. That gap is a recurring source of disputes in the field.
There are three binding methods, which vendor interfaces usually label VLAN mode, 802.1p priority mode and port mode:
VLAN mode. Traffic is mapped to a GEM Port by the user-side VLAN ID. This suits projects with a clean VLAN plan, one VLAN per service stream.
802.1p priority mode. Traffic is split by the 3-bit priority field inside the VLAN tag (values 0–7). Carriers commonly assign 5 or 6 to voice, 4 to IPTV and 0 to best-effort broadband.
Port mode. Traffic is split by the ONU's UNI port. When a multi-port ONU carries one service per port, this is the least work.
The relationship is asymmetric: one T-CONT can carry several GEM Ports, but a GEM Port belongs to exactly one T-CONT. So "voice and internet share a T-CONT" is permitted — at the cost of voice queuing behind browsing traffic. The moment upstream congests, VoIP jitter climbs. Standard practice is to give voice its own Type 1 or Type 2 T-CONT, with assured bandwidth sized at concurrent calls × roughly 100 kbit/s each (G.711 plus headers).
That is where careful VLAN configuration pays off. Per-user VLAN and gemport numbers should match one to one, so a fault on one subscriber never blurs into another's.
Take a dual-PON-port OLT — for instance Rayin's L102P, a 2-port GPON unit with 2×GE plus 1×SFP+ 10GE uplink and a 1:128 split ratio per port — with 100 subscribers hanging off one PON port, each on a nominal 100 Mbps plan. Work it step by step.
Step 1 — available upstream. The line is 1.244 Gbit/s. Deduct GEM framing overhead, upstream burst preamble, DBA reporting and FEC, and the practical carrying efficiency lands around 88–92%. Taking 90%: usable GPON upstream bandwidth ≈ 1.12 Gbit/s.
Step 2 — subscription total and oversubscription. 100 subscribers × 100 Mbps = 10 Gbit/s. Upstream oversubscription = 10 ÷ 1.12 ≈ 8.9:1. Downstream is 2.488 Gbit/s, about 2.24 Gbit/s at the same efficiency, so 10 ÷ 2.24 ≈ 4.5:1. For residential statistical multiplexing both ratios are normal.
Step 3 — the average each subscriber can actually get. Split evenly, each subscriber gets 1.12 Gbit/s ÷ 100 ≈ 11.2 Mbps. That number is what the "assured" column should be written from: 20 Mbps is overselling, 8 Mbps is genuinely coverable.
Step 4 — check against concurrency. Evening-peak concurrency for residential service is usually estimated at 30%: 30 subscribers × 100 Mbps = 3 Gbit/s, still well above the 1.12 Gbit/s available. So either cap each subscriber's maximum at 30–50 Mbps, or add PON ports to thin out the subscriber count. At 1:128 the split ratio is not the bottleneck — total upstream is.
Step 5 — set the T-CONT parameters. Give each subscriber one Type 5: fixed 0, assured 15 Mbps, maximum 100 Mbps, with leftover bandwidth contested on demand. Alloc-ID consumption is 100 subscribers × 1 = 100, or 5–10% of a single port's Alloc-ID space (commonly 1,024 or 2,048). Plenty of room. The real constraint is that 11.2 Mbps mean from step 3 — it is what stops the assured column being filled in casually.
If 20 of those 100 subscribers also need VoIP, add 20 Type 2 containers with 200 kbit/s assured each (sized for two concurrent calls), 4 Mbit/s in total, or 0.36% of 1.12 Gbit/s. The proportion makes the point: voice bandwidth is cheap. What is valuable is that voice has its own timeslot priority.
The snippet below uses generic syntax to show the sequence and where each parameter lives. It is not a real command line from any vendor — check the device manual for actual parameters.
; Step 1: DBA profile — holds the bandwidth parameters a T-CONT can use ; Step 2: line profile — where a T-CONT is tied to a GEM Port ; Step 3: service profile — describes the ONU's user-side port capability ; Step 4: register the ONU and push the service flow (VLAN mapped to the GEM Port) service-port 100 vlan 100 gpon 0/1/1 ont 1 gemport 1 user-vlan 100
Reversing the order fails immediately: with no DBA profile in place, the line profile cannot reference its profile-id; and if a service flow is pushed for a GEM Port that does not exist, the ONU shows online but no traffic passes. Order matters even more in batch rollouts — one mistyped template and dozens of units have to be rolled back.
| Symptom | Likely cause | Action |
|---|---|---|
| ONU online, subscriber cannot reach the internet | GEM Port not bound to a service flow, or service-port VLAN does not match the user side | Re-check that per-user VLAN and gemport numbers pair one to one |
| Fine all day, packet loss after 20:00 | Assured bandwidth set too low, squeezed during upstream congestion | Recalculate per-subscriber assured bandwidth, or cap the peak rate |
| Voice breaks up, noticeably worse while browsing | Voice and internet share one T-CONT | Give voice its own Type 1 or Type 2 container |
| Stuck at 30 Mbps on a speed test | Line profile caps the T-CONT maximum at 30 Mbps | Change the DBA profile max and re-push |
| Every plan change means reconfiguring device by device | Rollout hardcoded the parameters instead of using templates | Move to templates plus bulk push |
| IPTV artefacts, multicast stuttering | Multicast not mapped to its own GEM Port | Map it separately by 802.1p priority or VLAN |
One boundary is easy to miss: Type 1 fixed bandwidth is occupied permanently, even when the business is idle. A project that reserved 1 Mbps fixed per subscriber for voice quality would commit 100 Mbps across 100 subscribers — 9% of the 1.12 Gbit/s available — without anyone noticing until the capacity review. Run that arithmetic at the planning stage, not after.
Residential internet is the main service. Type 4 or Type 5, with assured bandwidth set to upstream available ÷ subscribers × 0.6 and the maximum set to the plan's nominal rate.
VoIP is in the mix. A separate Type 1 or Type 2 container for voice, assured at concurrent calls × 100 kbit/s, with 30% headroom.
IPTV or multicast is in the mix. Multicast rides its own GEM Port and never shares a T-CONT with unicast.
Leased line or TDM. Type 1 fixed bandwidth, and accept the hard capacity cost that comes with it.
Split ratio versus subscriber count. 1:128 is a question of optical power; subscriber count is a question of upstream capacity. Keep the two calculations apart.
Rayin's PON access portfolio covers the OLT, splitter and ONU ends of this chain; a 2-port GPON mini OLT such as the L102P pushes DBA templates down to each ONU individually, which suits dispersed sites with modest subscriber counts. The PON access solution page and the industrial switch solution page list the port and capacity options of each line.
Is a T-CONT the same thing as an Alloc-ID? Not the same layer of concept, but they are bound one to one. The Alloc-ID is the identifier the OLT assigns to a T-CONT, and DBA reporting and grants both follow the Alloc-ID. Under G.984.3 the Alloc-ID space is set by the OLT chip, commonly 1,024 or 2,048 per PON port. Plan on at least one T-CONT per ONU: 100 subscribers consume 100, which leaves the space comfortable.
How many T-CONTs can one ONU have? The specification sets no hard ceiling; the practical limit comes from the OLT chip's Alloc-ID space and the ONU's own capability. One to eight per ONU is what engineering practice typically uses. A common arrangement is three: one for VoIP (Type 2, 200 kbit/s assured), one for IPTV (Type 5) and one for internet access (Type 4). Splitting further buys almost nothing and makes the service-flow mapping much harder to troubleshoot.
Why are there 4,096 GEM Ports on paper but only a few dozen configurable? The 12-bit field is the width of the protocol field, not what a device can build. The real count is bounded by OLT chip table entries and the ONU's GEM processing capability and memory. Most compact OLTs manage tens to a few hundred GEM Ports per port. Check the device's service-flow ceiling before deciding to subdivide by VLAN — one GEM Port per subscriber on a 128-subscriber port is already close to that limit.
If the plan goes from 100 Mbps to 200 Mbps, does the service have to be reprovisioned? What changes is the maximum bandwidth in the DBA profile, after which the T-CONT parameters are re-pushed. The ONU does not re-register and the service does not drop. Under template-based rollout on an OLT such as Rayin's L102P, editing one template ID applies in bulk; if the parameters were hardcoded onto each ONU at install time, every unit has to be edited by hand. That is the reason spending half an hour on templates before rollout is worth it.
Does a finer T-CONT mean better network quality? No. The finer the containers, the more fragmented the timeslots each one receives, and DBA scheduling overhead and reporting frequency both climb — measured upstream efficiency drops from around 92% to around 88%. At an average 11.2 Mbps load there is little difference between 100 subscribers in 100 T-CONTs and the same 100 in 25 T-CONTs grouped four to a container. Fine granularity only pays off when individual subscribers max out their links. Divide by service type, not blindly by subscriber count.
OLT Bulk Provisioning: DBA and Line Profile Templates Explained
GPON Upstream Bandwidth Shared: Why 1.244 Gbit/s Is Not Yours Alone
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
