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 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
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
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
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
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
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
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
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
- 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.