Engineering Decides Your Margin

Where do MVNO’s margins really come from? Most people point to wholesale rates, marketing, and customer acquisition cost. They all matter. But I feel the bigger number is in the packet core. It is what the core costs you to carry one subscriber. And that is set by engineering choices, made long before you launch.

I have built and studied these systems for years. Let me share how I think about that cost. This is not about any one product. These are general principles, and they hold for any packet core, from any vendor. Together they decide your cost per subscriber. And that decides your margin.

Converge the user plane

Think about what the user plane does to a subscriber's traffic. It runs deep packet inspection, or DPI, to see what kind of traffic it is. Then it applies policy and charging rules. It acts as a Gi-firewall, and does carrier-grade NAT to translate the address out to the internet. That is a lot of work, on every packet.

These functions are known together as Gi-LAN services. A common way to build them is as separate components, chained one after another. The packet is copied and passed down the chain. It feels modular and clean. But every handoff has a cost. And each one is another thing that can break.

Why chain them at all, when they can run together? A converged user plane does DPI, policy, firewall, and NAT in one place, not in a chain.

I should be honest about one thing. None of these functions are new. DPI, policy, firewall, and NAT existed as their own network functions for years. Some are older than the PGW itself. As the PGW grew up, pulling these generic functions into one place made sense, rather than keeping them apart.

And the payoff is real. One converged user plane carries far more subscribers per server. Latency is lower, and fewer parts can fail at 2am. That saving repeats on every packet, for as long as you run it.

Treat hardware footprint as a running cost

Then there is the size of the whole core. You pay for hardware footprint every month, not just once when you buy it.

Hardware needs power, cooling, space, and people to run it. Every extra node adds to all of those costs. Run a GGSN for 2G and 3G, then an SGW and PGW for 4G, then a UPF for 5G. Keep them as separate stacks, and you pay that bill many times. Why not run them as one converged node, rather than many?

The tighter the user plane is built, the less hardware it needs for the same throughput. That means less to buy, less to power, and fewer people to run it. And a small footprint keeps that bill low, every month, for years.

Decide performance early

The next question is throughput; how much each server actually carries. Performance and scalability are not features you add later. You decide them in the design, or you inherit whatever you get.

Take the path traffic follows inside the server. A general-purpose operating system kernel is built to do everything. It is not built to move millions of packets a second. You can either pay that kernel overhead on every packet. Or you use kernel-bypass, and take the packets straight from the network card. That one choice can mean several times the throughput per core, on the same commodity hardware.

Scalability works the same way. Does cost rise with your subscribers, or faster than that? A user plane built for scale lets you take twice the customers and pay less than twice as much. If it is not built for scale, cost grows faster than your subscriber base. You get less profitable as you grow. That is set in the architecture, up front. You inherit it, and you do not get to change it later. So, it is worth getting right early, isn't it?

Build observability in from the start

The fourth one usually gets left for last. I think that is a mistake.

A user plane running at full throughput is too busy to log everything. You cannot write a record for every packet at millions a second. Visibility has to be built in from the start. That means live counters, and latency measured as the traffic moves. It also means a way to turn up detail on a running node, without stopping it.

If you treat observability as an afterthought, you are blind just when it matters. Build it in, and you can see your real spare capacity. Then you stop over-buying hardware just to feel safe. That extra hardware is only money spent because you were not sure. When you can see inside the core, you can run it close to the limit with confidence.

How this becomes margin

Now put the four together.

Each one helps in a different way. Converging the user plane puts more subscribers on one server. A small footprint cuts the monthly bill. Deciding performance and scale early means the same hardware serves more as you grow. And building observability in means you only buy the hardware you actually need.

They all lower the same number, the cost to carry a subscriber. And that cost shapes what your commercial team can do on price. When it is low, you have room to move. You can go lower, chase a thin segment, and still make money. When it is high, that room shrinks.

Engineering decides your margin, not just your commercial team. And it is decided early, in technical choices most operators never look at and cannot easily change later.

You do not need to be an engineer to act on this. You just need to ask the right questions, and weigh the answers:

• What does it cost to carry a subscriber today, and at five times the scale?
• How many servers, and how many people, does it take to run this at our scale?
• What can you see inside it, in real time, when something goes wrong?

If a vendor answers these clearly, their cost per subscriber is probably low. If they cannot, be cautious.

Whether you build the core, buy it, or rent it, ask one question. How much of your margin is already set deep in the core, out of your sight?