Mar 08, 2011

A Visitor's Guide to Telecom-Land

by Kris Raney

By Kris Raney

Stepping into the world of telecom from Internet-Land is an interesting experience. It’s an area where I have a slightly unusual perspective, having started my career in telecom, but having been away long enough to develop a different worldview. This makes the experience both nostalgic and slightly puzzling at the same time.

The first thing I was reminded of on returning to Telecom-Land is that it’s made of alphabet soup. Just about every concept or component is named with a TLA, or three-letter acronym. These three-letter names get repeated to the point that the full name is sometimes kind of forgotten. Why call it a “packet” when it can be a “protocol data unit,” or PDU? This practice has been institutionalized long enough that acronyms are commonly nested in acronyms — such as “GTP,” which stands for “GPRS Tunneling Protocol,” or “PGW,” which means “PDN gateway.”

The Internet as Second-Class Citizen

This brings up the second thing I was reminded of, which is that the Internet is a second-class citizen in Telecom-Land — kind of an unwanted guest. It’s not even called “the Internet” in telecom-ese; it’s called a “packet data network,” or PDN. You may notice that I said a packet data network and not the packet data network. In Internet-Land, it’s common to assume that having a connection to somewhere in the Internet means you can talk to anywhere in the Internet, but telecom makes no such assumption. You never know when you might need to hook into some proprietary network that can’t be reached through the Internet, or if this Internet fad might get replaced with something else. So the Internet is just one of who-knows-how-many PDNs to integrate with.

This perspective on the Internet is a symptom of history, influenced by practical concerns. The telcos have vast infrastructures in place, and it’s not reasonable to think they could just swap it all out in one big upgrade. Thus every new level of integration builds on what’s gone before. It’s probably fair to say that the “Internet as second-class citizen” mentality is mostly gone, but because of all the legacy infrastructure, it can’t yet be forgotten. That is why returning to telecom from the outside gives an interesting perspective: when you are looking at the system without paying due respect to the old way of things, the way things work now can seem kind of odd.

The Long, Strange Trip of the LTE Packet

LTE (long-term evolution) is a case in point. One key benefit that LTE is intended to provide is the System Architecture Evolution, or SAE (not, in this case, the Society of Automotive Engineers). This is built on the “evolved packet core,” or EPC, which is an all-IP network or AIPN. (I’m not kidding; it really is referred to as AIPN.) The upshot of all this is that inside the telecom network, they’ll be able to use off-the-shelf IP routers and other infrastructure and take advantage of the economy of scale that goes with that.

The other benefit of LTE is higher throughput and lower latency for user data going through the network — which is what every smartphone user wants. You might be tempted to think that passing the end user’s IP data through an IP network would be a trivial affair, but you’d be forgetting about the legacy of the Internet as second-class citizen in Telecom-Land. The end user’s data may be built on the same technology as the EPC’s data, but in Telecom-Land it’s still a PDU — some sort of packet data passing over a voice network.

To show you what I mean, let’s take a look at an example user packet as it passes through the EPC. I’ll pick an HTTP GET request as an example.

To save typing, this is a very simple GET request with an 8-byte payload — “GET /” followed by a two-character linefeed. On a plain IP network, it looks like this:

This PDU needs to be packaged up for traversal over the telecom network. With LTE, that means it will be carried over a GTP tunnel that traverses the EPC. Since the EPC is IP-based, that GTP tunnel is actually implemented over UDP (or potentially TCP). So, after wrapping things up into the tunnel, the packet looks like this:

So what we have here is IP-inside-telecom-inside-IP. This extra overhead means not only more bytes on the wire, but also more CPU cycles calculating checksums at each layer. It’s the lingering effect of the Internet-as-second-class-citizen mentality that I mentioned.

But that’s not all. You see, the cell towers in the telecom network have historically had dedicated links back to the core network. These links are getting old and oversaturated. They would be expensive to upgrade, since that would require digging trenches and laying new fiber. So instead, there’s an effort to use broadband — just lease a new connection over the Internet. When that happens, well, you can’t pass that telecom data over a public network unencrypted, so it gets wrapped one more time, in an IPSec layer. So ultimately that GET request looks like this:

So your packet goes from your cell phone (in telecom-ese, the “user equipment,” or UE) to the cell tower (or eNB), where it’s wrapped up like an onion and passed over the Internet back to the telecom core. It’s handed around there before it’s unwrapped by the PGW or PDN gateway, and then put back on the Internet and routed to the server.

You can make this even more amusing if you assume that you’ve signed your phone onto your office VPN (adding another layer), that the “cell tower” is actually a femtocell or microcell connected to your office network, and that the server you’re talking to is right down the hall in the server closet.

Here’s where I have to confess that the example is a bit contrived to exaggerate the overhead relative to the payload — but only a bit. I’ve also avoided mentioning that, while getting your packet from point A to point B may be the central point of the whole operation, it’s not the only thing that the telecom world needs to worry about. A telecom provider has to handle a moving phone that gets handed off from one cell tower to another. It has FCC-mandated uptime requirements. It’s required by law to support Lawful Intercept, such that they have to make your data accessible to law enforcement. They have to track usage for billing purposes. Users from some other company’s network may be roaming on your telco’s network. All of those conditions compel your telco to bring your data home to the core network before setting it free on the Internet.

Long Live Internet Protocol!

Still, having lived in Internet-Land for some time, I can’t escape the perspective that voice is data and needs to be packaged up to pass over the data network, not the other way around. From that perspective, it’s hard to see LTE as “long term.” Rather, it seems to me like a temporary step toward a network that not only runs over IP, but is fundamentally IP-based. That is to say, when your phone generates an IP packet, it travels over the network as is, and most likely, your phone calls are 100% voice-over-IP (VoIP). Your phone might live in its own tiny subnet so that handoffs as you move from cell tower to cell tower could be handled by routing updates.

That’s my Internet-enabled dream. It could be one of the telecom companies that makes this happen — or Google thanks to Android, or Apple thanks to Facetime, or maybe a new startup — but it’s bound to be coming.

Related content: