A Walk Through the Telco Network — From Tower to Public Cloud
Stand at a BTS shelter and walk inward. Each tier you pass is a different cloud decision, with its own physics, economics, and regulator.
Telco cloud diagrams treat the network like a stack. In practice it is a walk — from the customer’s antenna inward, through aggregation, into the core, out to the analytics estate, and finally to the public cloud edge. Each step you take crosses a boundary the cloud strategy has to respect. Here is the walk, the boundary at each step, and what it costs to cross. The walk is the same in Dhaka as it is in Jakarta or Lagos; the parameters that change are the regulator’s posture, the spectrum economics, and the density of the BDIX-equivalent peering layer.
Tier 1 — the BTS shelter
You are standing at a tower. Inside the shelter is a small compute footprint: a CDN cache, a uMEC node, on a 5G site a User Plane Function running on DPDK/SR-IOV bare metal. The constraint here is power and floor space, not orchestration philosophy. Latency targets are single-digit milliseconds. Hyperscaler regions are not in the conversation. What lives here is whatever has to live here: cached video for the local catchment, a small subscriber-aware analytics function, a pre-aggregation node for network telemetry. Nothing else fits. Edge cabinets across a national network are operationally identical to a bank’s branch IT estate twenty years ago — you optimise for footprint, power draw, and zero-touch remote management, because nobody is driving to the tower at 2 a.m. to reboot a server.
Tier 2 — the regional sovereign cloud
You walk inward toward Dhaka or Chattogram. Here lives the OSS/BSS, the CRM, the billing feeds, the churn data lake. The constraint is residency: subscriber data does not leave Bangladesh by default. The economics favour a BTRC-licensed sovereign operator with BDIX peering — round-trip under fifty milliseconds, BDT-billed, audit-grade logs. This is the tier where the cloud decision actually has the most leverage. Nearly every operational system that touches a subscriber transits this layer at some point: payments, recharge, plan management, fraud detection, customer self-service, marketing automation, churn modelling. Get this tier right and the rest of the network is straightforward; get it wrong and the support team is paying for it twice a quarter.
Tier 3 — the national private cloud
You arrive at the operator’s own facility. HSS/HLR, MSC, IN/charging. Often still bare-metal NFV. The constraint is regulator-mandated inspectability — BTRC’s lawful-interception requirements demand a control plane the operator’s own staff can audit instruction-by-instruction. The hardware here looks unlike anything else in the estate: SR-IOV NICs at line rate, DPDK fast paths, vendor-specific NF acceleration cards, purpose-built billing platforms with decade-long licensing tails. Cloud- nativifying this tier is the long, expensive project most operators have formally committed to and informally deferred. The reasons are defensible: the licensing economics of NFV often do not work; the hardware acceleration assumptions break under hypervisor abstraction; and the regulator wants a control plane it can read.
Tier 4 — the selective public cloud edge
You step out to the world. Burst analytics, frontier ML inference for language tasks, global SaaS integrations, out-of-country disaster recovery for non-regulated systems. The constraint here is purposeful scope — workloads that genuinely benefit from elasticity or global reach, nothing more. The trap operators fall into at this tier is scope creep: a small CDN integration becomes a full marketing data lake, then a customer-experience platform, then a regulated workload that should never have left the country. The discipline is to put a data-classification gate at the boundary and police it.
CDN · uMEC · 5G UPF · DPDK/SR-IOV bare-metal · single-digit-ms latency
OSS/BSS · CRM · billing · churn lake · BDIX-peered, BDT-billed
HSS/HLR · MSC · IN/charging · operator-inspectable control plane
Burst · frontier ML · global SaaS · out-of-country DR
Where the steady-state weight sits
Source: Composite from Bangladeshi operator engagements.
The interconnect is where the walk earns its keep
The four tiers above only work if the network glue between them is treated as a first-class engineering investment. MPLS or eVPN between the regional sovereign cloud and the national private cloud, with deterministic latency and predictable cost. BGP peering with the BDIX participants and the regional content providers. A purposeful out-of-country circuit with explicit data-classification rules at the boundary. Operators that defer this work spend the first two years of their hybrid programme retro- fitting interconnect under load, which is the most expensive way to build a network.
Read next
- Cloud Strategy
A Letter on the Bangladesh Cloud Economy
Annual letter to the Cloud Digit board on the shape, drivers, and trajectory of the Bangladeshi cloud market. Written in the long-form-thesis style that serious investors actually read.
- Cloud Strategy
Five Truths About Building a Sovereign Cloud in Bangladesh
Hard-won lessons from the field — what every newcomer underestimates about the licensing, the customer, the currency, and the country.
- Compliance
Three Letters to Three Regulators
How public cloud actually fits inside the Bangladeshi regulatory frame, written as three pieces of correspondence — to BTRC, to Bangladesh Bank, and to the Data Protection Authority.