Tracing LTE on the phone

As a short additional note to my first experiments running an LTE eNodeB: I wanted to know how this looks on the phone. The protocol I am interested in is RRC (Radio Resource Control) for LTE (specified in TS 36.331). RRC also transports the NAS messages which are exchanged between the eNodeB and the MME.

The USB LTE Dongle I use for my experiments is based on a Qualcomm chipsets. I used Qualcomm based phones for quite a while so I already know some parts of how tracing works on them. I was able to locate the LTE messages in the traces and extend GSMTAP slightly so that it is able to handle LTE RRC messages too.

Here is how it looks in WireShark when a phone registers to the LTE cell:

The red colored lines are uplink messages (from UE to eNodeB), the blue lines are the response from the eNodeB. The trace also contains a few of the System Information messages the phone has to decode to get all the required information to communicate with the eNodeB. Otherwise you can see that the NAS messages exactly match those seen on the S1-AP interface (of course, this is expected).

Running your own LTE eNodeB

Finally I got all the required parts together for a fully functional LTE eNodeB. The eNodeB (E-UTRAN Node-B or Evolved Node-B) is the LTE equivalent of a GSM BTS or a 3G Node-B. Considering that its was only less than two years ago when I started to experiment with 3G Node-Bs, obtaining LTE equipment went faster than expected, especially considering that LTE is still in the deployment phase.

Compared to what is needed to run a 3G Node-B, an LTE eNodeB really deserves the "Evolved" in its name. All the functionally of the 3G RNC is contained in the eNodeB (e.g. all the RLC/MAC and radio functionality) and only the higher layers are exposed through the so called "S1" interface. This interface is IP based, there are no such things like E1/T1 or ATM any more.

In case you wonder from where all the configuration parameters for the eNodeB like EARFCN or RF Output Power come from: They have to be configured when setting up the eNodeB, in my case you can configure a few hundred parameters. Luckily most of them have default values which for a start can be taken without modification.

The S1 interface is divided into S1-AP (Application Part) which is specified in TS 36.413. This is the interface to the MME (Mobility Management Entity) which is somehow comparable to a GSM MSC and it uses SCTP. The communication between MME and phone (abbreviated UE like in 3G) are the so called NAS (Non-access stratum) messages, in LTE this is mainly Mobility Management and Session Management, there is no Call Control. LTE NAS is specified in TS 24.301.

The second part of S1 is called S1-U for the user plane traffic which is GTP-U (GPRS Tunneling Protocol) specified in TS 29.281 and using UDP. S1-U connects to the S-GW (Serving Gateway), basically comparable to a GPRS SGSN.

The eNodeB also has a second interface called "X2-AP" (TS 36.423), it is used to interconnect multiple eNodeBs (this is needed for example for handling handover which is done be the eNodeBs themselves). I did not care about X2-AP yet because right now I only have one eNodeB.

So far I wrote a very simple "Proof-of-Concept" so that a phone (in my case an LTE USB Dongle) can register to the LTE cell and transfer data (IP traffic). Just to mention a few of the differences to 3G/GSM:

• The keys generated by the USIM in the UE (you can use a 3G USIM for LTE too) are not directly used for integrity protection or ciphering. Instead they are used to derive various keys, two of them are the ones used for ciphering/integrity protection on the air interface, this is done in the eNodeB.
• The NAS messages between UE and MME are also protected (integrity protected and optionally ciphered), another derived set of keys is used for this. This means that even if the keys in the eNodeB can be obtained, the NAS messages are still protected.
• One Mobility and one Session Management message can be transferred at once in one message over the S1-AP interface, this is for improving speed and saves data transfer on the core network.

Here is how it looks in WireShark when a phone registers to the LTE cell (recent versions of WireShark can handle S1-AP):

The colored lines are uplink messages (from UE to MME), the white lines are the response from the MME. You can see that a default bearer is configured together with attaching to the network. This means that without any further S1-AP messages user plane traffic can start immediately afterwards, at least if the default bearer is sufficient (e.g. the offered quality of service is good enough).

This all is just a very first start with LTE, I hope to find more time for it in the future and explore my eNodeB and LTE further.

Sometimes you need Wireshark to get an RF Power Amplifier running

I recently had the need for an RF Power Amplifier for the UMTS 2100 MHz band. As I didn't have a suitable amplifier at hand, I though of using one of the RF Power Amplifier modules of my Nokia Ultrasite cabinet which is a Node-B configured for UMTS 2100 MHz. The RF Power Amplifier modules in the cabinet can easily be removed, they are directly connected to the power supply line of the cabinet and they have standard RF connectors for RF In and RF Out. So it should be quite easy to operate them outside the cabinet.

Connecting power to the RF Power Amplifier module was easy, however this wasn't enough, the amplifier didn't amplify any RF although the status LED of the module was on. Also the power consumption was quite low, so obviously the actual RF Power Amplifier in the module was not yet on. I didn't want to modify the electronic inside the module so I had to find out how the module gets enabled in the cabinet.

Nearly all of the various modules in the Nokia Ultrasite cabinet are connected at the backplane to Ethernet through a hub (yes, a hub, there is no switch). This Ethernet network is mainly used for controlling the modules, fast data transfer between the modules is done somewhere else. The RF Power Amplifier module is no exception, it's connected to this control Ethernet network too. The configuration and management port of the cabinet is also an Ethernet port connected to the same control network. And because an Ethernet hub is used, all the traffic on this network can be monitored without any further tricks if you are connected to the cabinet's configuration and management port.

So I run Wireshark and captured a trace of the traffic on the cabinet's control network. I already knew the IP address of the RF Power Amplifier module from running it externally, however it only responded to a ping but no TCP or UDP port was open. (BTW, if you wonder how the module gets its IP address: depending on the slot where the module is inserted into the cabinet, different ID pins of the module are grounded. The levels on those ID pins define the MAC and IP address of the module).

From the trace I was able to find out hot it works, it's actually quite evolved:

• First a certain UDP packet has to be send to the RF Power Amplifier module. Not just destination IP address and port have to match, also the source IP address and port have to be a specific value, if not the module just reports an ICMP error that the port is unreachable (that's the reason why I didn't find an open port during my first try).
• This UDP package causes the module to initiate a TCP connection back to the sender, when the TCP connection is open the module sends some kind of initialization message and expects an acknowledgment.
• Only after the TCP connection is open and properly initialized, another UDP package can be send to the module which finally turns the RF Power Amplifier inside the module on.

I am not sure why the TCP connection is necessary, so far I only found out that it is used to control the status LED of the module and to return the operational status (e.g. if a fault was detected). Over UDP it's also possible to query the serial number of the module or to tell it to periodically return RF power measurements. So as you can see, sometimes even just a "simple" thing like an RF Power Amplifier can require quite complicated interaction to run it.