Aug 10, 2010

The LTE Diaries: S1AP Support, Because Wireless Traffic Doesn't Handle Itself

by Eric Reeves

NOTE: This is one post in a long series, catch up on the most recent LTE development updates, or check out our recent LTE webcast.

If you've been reading this blog for the past few weeks, you're already aware of the extremely rapid development cycle we're following as we add capabilities to our product for simulating Long Term Evolution (LTE) networks. (If you're not, or if you just want a refresher on what's at stake and why LTE is important, check out Dennis's post explaining this development cycle.)

My part of this project involves our support for S1AP, a control-plane signaling protocol that handles wireless network traffic between two key parts of LTE networks, the eNodeB and the MME. As Dennis put it in the post I just cited, "Think of eNodeB as comprising all the communications architecture that makes LTE possible, including communications between the tower, the SGW (Serving Gateway) and the MME (Mobility Management Entity), which is the main signaling node that deals with registration and a lot more."

What Is S1AP?

S1AP -- which stands for "S1 Application Part" -- is the specific piece of an LTE network that signals between an eNodeB and an MME. It does four important things:

Establish a default bearer channel. The default bearer channel gives the user equipment (UE) -- for example, the smartphone in your pocket -- its "always-on" functionality. In line with this, S1AP establishes the "context" of the UE's connection to the network, meaning that it identifies the interactions between the UE and the eNodeB. This lets the MME know which eNodeB it should use to talk to which UE.
Non-access stratum (NAS) transport. When a UE wants to connect to a data network, for example, it sends a NAS message via an eNodeB (which doesn't process the message) to the MME. S1AP handles this in an orderly way.
Mobility and handoffs. The UE and eNodeB are constantly communicating, at least until the signal gets too weak between them. At that point, S1AP negotiates the handoff that allows the UE to switch its connection from one eNodeB to the next. In practice, this happens when the network switches your mobile device's connection from one cell tower to another.
Paging. When your UE detaches from the network, the MME goes through paging procedure to confirm (or attempt to confirm) the location of the UE. This happens, for example, when you turn your phone off or put it in airplane mode. S1AP helps the MME as it tries to locate the UE.

S1AP Development Plans

As we've worked on integrating S1AP into our product, we've followed three main steps:

Understanding the S1AP protocol. Fortunately, the 3GPP standards group has written a great spec for S1AP, which makes my work as an engineer much easier.
Understand packet flow in S1AP. We have great capabilities for packet capture, but there has still been a good deal of homework done to grasp exactly what goes on in the control plane and the user plane while S1AP carries out its tasks.
Build S1AP into the application simulator component of our product. This has meant mastering all parts of the mobility/handoff workflow, then programming building blocks of Ruby code into our library so that the machine simulates S1AP realistically -- and at the blazing speeds needed for an LTE network.

This process has been made easier for me (and my colleagues working on other aspects of LTE) by our homegrown codebase, the tight integration of our hardware and firmware, and the power of the network processor architecture of the BreakingPoint Storm CTM.

Advantage, BreakingPoint Architecture

If you’ve noticed, we are developing our LTE support at an extremely fast pace. The reason we are able to do this much more quickly than conventional testing vendors is due to our unique network processor-based product architecture. This architecture allows each of the BreakingPoint engineers performing LTE development to work in parallel. Additionally, our architecture allows us to introduce updates to all of our customers through firmware updates and our Application and Threat Intelligence (ATI) Updates.

This gives BreakingPoint a big advantage for organizations doing LTE testing. For example, I work on the Application Simulator component. I know the requirements for new protocols as they pertain to the simulator engine and have the ability to design, develop, and debug within this engine. We then introduce these applications, such as S1AP, immediately into the product through the ATI Update. In parallel, as described by Scott Canion in the last LTE Diaries post, we can provide the critical ability to transmit traffic using SCTP. The same thing is happening with our development of DHCP Client Support, GTP Support, and other critical elements for LTE. Rather than spending upwards of a year developing LTE support like traditional testing tool vendors, we will accomplish it in a matter of weeks.

Digging into S1AP has been an interesting technical project, and it reflects our overall commitment to find out what's really going on "under the hood" of the most advanced network technology. This kind of work is hard, but it's also fun as an engineering challenge -- and, more than that, it means that our customers will be able to simulate realistic LTE network conditions with confidence.