LTE GTP Tunnel: We're Not In Mayberry Anymore
by Kris RaneyBy Kris Raney
In an earlier post I talked about the overhead that telecom’s legacy puts onto each data packet in an LTE network. I’d like to dig a little deeper into why that is. Before I begin, let me give a very brief (and very approximate) history of how phones work.
The way the phone system worked in the old days became a TV cliche. Remember how it worked in Mayberry? Andy picks up the receiver and jiggles the hook a few times to get Mabel’s attention back at the central office. Then he tells her who he wants to talk to, and she plugs a big quarter inch plug into the switchboard in front of her, and now Andy has a complete, dedicated circuit back to Opie at the house.
It didn’t take long for automation to put Mabel out of a job, but the dedicated circuit lived on for quite a while. Eventually, the ability to digitize the sound meant that the data could be broken down into packets, and one physical circuit could carry multiple calls by having them take turns transmitting packets down the wire.
So imagine a time when customers have leased dedicated circuits, and that’s the ubiquitous way to operate, but the telco has figured out a way to get more capacity out of the same wires. This is a little bit difficult to market - the telco needs to convince their customer that sharing the wires is going to be just as good as having a dedicated circuit, because it’s digital data. Otherwise, the customer won’t want the new service, or worse, will expect a price break. So the telco is very concerned about guaranteeing that the customer still gets all the bandwidth they need — that they still get the same quality of service (QoS). This led to a conceptual “virtual circuit”: When you start to make a call, all the necessary bandwidth is reserved from end to end, so you’re guaranteed that all your voice data will flow just like the old days when you had your own circuit.
LTE GTP Tunnel: The Virtual Circuit Lives On
The virtual circuit lives on in LTE in the form of the GTP tunnel, called the “bearer” in LTE terminology. This is very similar to what’s called a packet data protocol or PDP context in LTE’s predecessor, 3G. However, unlike an old telephone, which only has work to do if you are talking on it, data communications tend to keep the virtual circuit at least somewhat occupied. While your phone is in your pocket, it might be checking for new emails, or waiting for notices from instant messenger, or doing a myriad of other things. So in LTE, there is a default bearer that is activated as soon as the phone is turned on, and stays active until the phone is turned off. It’s practical to do this because, unlike with a voice call, data traffic doesn’t always keep your phone busy with a steady flow of bits.
One important side effect of the default bearer is that your phone always has an IP address assigned to it. This is in contrast to 3G, where the IP is assigned when you first establish a “packet call.” This makes your phone much more like other things that live on the Internet — like the computer on your desk.
If you’ll remember, one of the important aspects of the virtual circuit is that it’s supposed to guarantee a certain level of QoS, which is primarily concerned with latency and bandwidth. The QoS requirements of the default bearer are fairly minimal, though, since it’s targeted at handling the traffic from the phone while it’s in your pocket. As soon as you take out the phone and start playing with it, though, that minimal QoS guarantee may not be enough, especially if you begin streaming voice or video. So LTE also provides the ability to create dedicated bearers, similar to secondary PDPs in 3G.
This dedicated bearer represents a separate virtual circuit — most likely with a higher QoS guarantee — but not an extra IP address. The phone decides which bearer to send data through based on a traffic flow template, or TFT. A TFT is set up when the dedicated bearer is created, but it can also be modified over the life of the dedicated bearer. This arrangement allows a dedicated bearer that happens to be at the right QoS to be reused for multiple separate traffic streams, which is a good thing because (a) the maximum possible number of bearers per smartphone is 11, and (b) there is a setup cost for activating a bearer, in the form of a flurry of messages among LTE entities.
Here’s a quick rundown of what happens. First, let’s name the interested parties:
UE User Equipment — Your phone, or your computer’s aircard.
eNodeB Enhanced NodeB — Essentially, the cell tower your phone is talking to.
MME Mobility Management Entity — This component essentially has Mabel’s job: It’s what the phone talks to in order to set things up, and it makes sure the phone belongs on the network.
SGW Serving Gateway — Mabel’s switchboard: This entity routes and forwards all of the user traffic. In IP terms, this is the router.
PDN-GW Packet Data Network Gateway — Another router, in this case charged with taking user data off the telecom network and putting it on the Internet, or vice-versa.
And now, here is what they say to each other in order to get a dedicated bearer fully set up and ready to handle traffic:
All of this messaging sets up the virtual circuit, and makes sure that it can be tracked for billing purposes. That’s a whole heap of up-front latency that’s undertaken in order to guarantee good latency across the life of the connection. One would hope that, in the common case, traffic would begin to flow on the default bearer first, letting you take your chances with QoS. In the meantime, the complicated setup shown above happens; once the bearer is ready, the TFT is modified to shift the already-running traffic over to the dedicated bearer. One can always hope.
The good news is that, for the most part, this messaging is an up-front cost that can be amortized over a lot of traffic to follow, especially for the default bearer, which is always on. In 3G Land, it’s possible to see better setup latency by setting up a VPN connection, thus forcing all your traffic over a single connection from the telco’s point of view, and forcing a similar always-on approach for the PDP.
Now, IP technology has a different history. It started life as one big circuit loop that a group of computers in a lab or office would share. Two computers might try to talk at once, causing a collision, and they’d just back off and retry a little later, like you’d do if the same thing happened during a conversation. That shared circuit was a “network,” and when you had computers sitting on more than one network, you could forward stuff between them, allowing “internet” communication. Once they all grew together, you had THE “Internet”. Interestingly, IP tech started at the opposite extreme from where telecom started, but also evolved away from that extreme — your modern office doesn’t have one big circuit loop any more. Each computer has a dedicated circuit, at least back to the switch closet. Once it gets past the switch closet, though, it’s not a dedicated circuit end-to-end like old telecom was, since it still relies on a series of network devices to pick traffic up on one segment and pass it on to the next.
Despite this different history, IP technology is no stranger to QoS, and has its own way of providing for different QoS levels. It shows up in the IP packet header:
DS stands for “Differentiated Services,” and is the IP way of identifying packets to be treated with different QoS rules. TOS stands for “Type of Service” and is an older, deprecated interpretation of the same bits that serves basically the same purpose.
Either way, it’s a fixed part of the IP header that’s present in every packet you send, whether you make use of it or not. The idea is that the host flags the packet with a codepoint value in the DS field that says what quality of service it should get. Since it’s right there in the header, routers can take a look and “do the right thing” without digging too deep into the packet or having to think too hard. It was designed this way on purpose to avoid raising the cost of infrastructure equipment unnecessarily.
Now, I don’t mean to imply that the telecom guys are unaware of these bits in their packets. In fact, this header field is one of the criteria that can be used in the TFT to decide which traffic goes on which bearer. RFC 2474, which defines the DS field, deliberately leaves the mechanism used to make QoS happen unspecified, but I would say that the telecom usage doesn’t quite follow the intent of the RFC, since only the endpoints (UE and PGW) will look at the DS bits, and then package up the packet into GTP, which the core network components will look at instead of DS.
LTE GTP Tunnel: More Than Just QoS
This raises a question: Given that within the all-IP network (AIPN), QoS could be handled using the IP header, what value does the GTP tunnel provide? The answer is that its virtual circuit job description includes more than just QoS. The other important job for GTP is to wrap up and hide the user’s IP information so that telecom can insert its own IP header and thus have more direct control over where the data flows within their network. This helps ensure that a user’s IP packet flows via the SGW to the PDN-GW, which then unpackages it and dumps it onto the Internet, rather than choosing the first convenient path to its destination.
This is important for billing and also for lawful intercept, because it means all of your data traffic can be routed through San Francisco, where a fiberoptic splitter can feed that data to the NSA. (I’m being slightly facetious here. I don’t think the telco is routing all your traffic to San Francisco so it can be monitored. I’m sure there’s a similar fiberoptic splitter setup more local to your region.)
In this role GTP is acting a little like another concept from IP networks, the VPN or virtual private network — only without enforcing authentication or doing encryption. Those jobs are left to the signaling side of the network, or to a second IPSec tunnel layer, leaving GTP only the job of making the UE appear to be a network element local to the PDN-GW (making it more of a virtual private network.)
Like I mentioned in a previous post, I tend to think this virtual circuit has outlived its usefulness. I think all this overhead and complexity makes telcos vulnerable to competitors who build directly on IP networks. A provider that is willing to find a business model other than billing on per-kilobyte usage could avoid a lot of messaging overhead. I think they’d attract a lot of customers at the same time. If they could find a way to meet lawful intercept requirements that wasn’t always-on, they could send packets over shortcut routes and avoid some bandwidth overhead. They could use off-the-shelf IP-native QoS solutions.
I don’t really picture the telcos evolving to take this approach, although there are some solutions that try to make this happen. The reason why I doubt that development path is that bypassing the telecom infrastructure also bypasses billing, and I don’t anticipate any hurry for telcos to do that. What I imagine, instead, is a service provider that approaches the problem from the other direction, where making VoIP calls over Wi-Fi is the “native” interface, and the telecom data network is just used to fill in the gaps. The technology to do this is in use already — think Skype and Facetime.
The missing piece is only how people buy into the service. For the revolution to happen, cell service from Random-Carrier-You-Don’t-Really-Care-About would need to become part of the package that provides you VoIP service. It could work something like the Amazon Kindle, which connects wirelessly to Amazon’s e-book service . . . without the user even needing to know which carrier is providing the connection. The same thing is happening with 3G service on the iPad, even though Apple has chosen for business reasons to enable Facetime only for Wi-Fi, not 3G.
It will be interesting to see how different players — telcos, device makers, content suppliers — approach the technical and commercial questions raised by LTE and other new transmission modes in the years to come. One thing’s for sure, though: We’re not in Mayberry anymore.
Related Content:
