Lately I’ve had a passive exposure to Digital Signaling Processing
(DPS) and Software Defined Radio (SDRs), as some of my colleagues
work with these technologies. Given my complete ignorance when it
comes to radio signals, I decided to take up the opportunity that
has been given to me to explore this new world. In this blog post I
want to explain the main structure of a
4G network, and how, with
some software and hardware, you can create your own personal 4G
network at home.
As for the structure of this blog post, I will first introduce the core architecture of a 4G network, then I’ll describe all the hardware and software requirements needed to make your own network work, and finally I’ll show step by step how to compile and execute each software in order to connect a real phone to a custom 4G network. Hope it’s an interesting read that can shed some light into a fascinating area of technology!
DISCLAIMER: Given my lack of in depth knowledge when it comes to radio signals, anything I can mention could be not completely accurate. If you spot some errors feel free to correct me in the comments below.
Structure of a 4G network⌗
First of all, if you come from a background in networking, the first thing to understand is that much of what you know about networking in the digital realm remains very much relevant to the world of mobile, and in particular of 4G networks. The main idea of a 4G network is to combine together radio signals, on the one hand, with your typical digital network packets.
From a high level abstraction, a 4G network is made up of three main parts, which are described as follows:
User Equipment: This is the device of the end-user. This is the phone, or, in general, the end-device you use to connect to the network. The user equipment is able to send and transmit radio signals at particular frequencies.
Core Network: You can think of the core network as a sort of “cloud” in the context of mobile networks. Internally, the core network is made up of various components, which communicate with eachother in order to keeps track of the internal state of the mobile network, of the various UEs currently connected, of the various services that need to be given to the various UEs and many other things of the sort.
Base Station: Between the UE and the core network there’s the third and final component, which is the base station. This is the station that communicates with the user equipment through the usage of radio signals. It is the bridge that connets a UE to a core network.
The following picture should make things clearer
As we can see, the UE (User Equipment) is able to communicate with the core network by going through the base station. While the communication between UE and base station only consists of radio signals, the communication between base station and core network consists of both radio signals as well as the more traditional way of transmitting data through wires. This architecture makes a lot of sense, because radio signals give you flexibility of movement, something required by UEs, while wire communication allows you to have a more reliable and scalable way of transfering user data for long distances.
While in the demo at the end of this blog post I’ll work with only a single base station, in real networks there are actually lots of base stations scattered across a given region of space, each one covering a particular area of interest. All these stations, taken together, form a particular radio access network, which in 4G is called the E-UTRAN. Whenever a user equipment goes out of the range of one base station, it can hopefully find another base station in order to keep the connection it has established with the core network.
In the world of telecomunications there are, sadly, lots of acronyms. Here I mention a really limited number of acronyms that can be found while studying 4G networks:
- UE: stands for “User Equipment”
- EPC: stands for “Evolved Packet Core”, and its the name given the core network in 4G networks.
- eNodeB: stands for “Evolved Node B”, and its the name given to the radio base station in 4G networks.
- E-UTRAN: stands for “Evolved Universal Terrestrial Radio Access Network”, and represents the air interface for 4G networks.
The tragedy here is that these acronyms change between the various evolutions of the protocols. So, for example, the base station for 5G networks is called gNodeB instead of eNodeb, although conceptually it refers to the same component of the network. It sort of makes sense to have different names, since the technical specs are different. Still, the jargon is really heavy. I’ll not mention much about 5G in this blog post, but it’s something to keep in mind when trying to make sense of these domains.
Digging deeper into the architecture, the core network is actually made up of different internal components, each of which deals with a specific aspect of the network.
Below I give a brief description for the most important components that so far I myself have understood:
Mobility Management Entity (MME): The MME is the entry point of the network when it comes to the data control channel. The base stations that form the E-UTRAN network communicate with the MME for exchanging information on various topics such as security procuderes (UE authentication, confidentiality and integrity protection), as well as the basic session management between the UE and the core network.
Home Subscriber Server (HSS): This acts as the main subscriber database which provide details of the subscribers to the other components of the core network. This is used during the authentication procedure to generate the challenge vectors that are then sent to the UE. This challenge vectors are generated by knowing the secret key \(k\) that is also stored within the SIM of the UE.
Serving Gateway (SGW)
Packet Data Network Gateway (PGW)
Access Network Discovery and Selection Function (ANDSF)
Evolved Packet Data Gateway (eDPG)
When a User Equipment (UE) wants to connect to the network, first it finds a base station that supports the desired connection. Then, between the UE and the selected eNodeB, a radio channel is created, and within this radio channel the UE sends to the core network an attach request, which is used to initialize a particular authentication procedure that allows the core to correctly identify the UE that wants to join the network.
There are various protocols involved in this attach procedure. Some of these protocols have to do with the management of the radio channel between the UE and the base station and between the base station and the core. I have no idea how these protocols work in detail. There are also other protocols which I understand better, such as the cryptographic protocols that are used to perform authentication and to protect the data sent through confidentiality and integrity.
From a cryptographic point of view, the idea here is that before the UE even attempts at connecting to the core network, UE and CORE both share the same secret \(k\). This is the secret that is written into the SIM of the UE device and into the HSS component of the core network. By using this shared secret the core network is able to authenticate the UE device with a challenge-response protocol that only the device that knows the shared key \(k\) can correctly respond. Once authentication has been correctly completed, a series of keys are generated starting from the symmetric keys. These keys are used to protect the confidentiality and the integrity of various sessions that are established during the communication between the various components of the network. Some of these sessions involve the UE and the core network, while some other involve the UE and the base station. After cryptography has been taken care of, the core network starts to offer various services to the UE. These services depend on many factors. Some of these factors have to do with the capabilities offered by the particular UE. Below you can find some of these messages taken from a network trace of an attach request.
The authentication procedure here is wrapped within messages of
NAS-EPS protocol, where
NAS stands for
it is one of the main protocol that is used between the UE and the
core network. In any authentication procedure we typically find
the following messages:
Attach Request, Identity Request, Identity Response, Authentication Request, Authentication Response, Security mode command, Security mode complete
These messages are used to authenticate the user and to establish
the security context. Out of all these messages, the
Identity request and
Identity response are sent only the first time the UE
connects to the core network. These messages are critical because
they contain the IMSI, which is the unique identifier of the UE
within the network of an operator. For subsequent connections
these messages are not sent, and other temporary identifiers are
instead exchanged. The
security mode command message establishes
the algorithms that will be used to protect the messages at the
There is much more to say that I have not mentioned here. The protocol stack of mobile networks is quite complicated, because a lot of protocols are wrapped within messages of other protocols. Anyhow, we should now have a good enough picture of the main architecture and the various components of a 4G network.
We can now describe in detail all the requirements needed to create a custom 4G network using your own personal computer. In terms of requirements, we distinguish two main classes of requirements: hardware requirements and software requirements.
In terms of hardware, the most important thing we need is a device that is able to send and receive specific radio signal. Lately Software Defined Radios (SDRs) have been very useful when working with radio signals, especially in research, as they allow to send and receive various types of radio signals with good performances. The cool thing about SDRs is that they are programmable through software. This means that with a given SDR we can program it to listen to wifi signal, or 4G signal, or 5G signal, or even other types of radio signals. I do not know the details, but this re-programmability feature is mostly obtained through the usage of Field Programmable Gate Arrays (FPGAs).
A friend of mine (Thanks Raffaele), also reminded me to mention the fact that not all SDRs are fit for this particular task. While they can be modified through software, the hardware of each SDR still has some limitations on how it can functions, or what kind of radio frequency it can transmit and receive. In general, SDRs can be characterized by various things, such as the ability to be full-duplex, meaning that it can send and receive radio signals at the same time. Below you can find a table with some characteristics of various SDRs.
In this particular blog post I will use the USRP B210 developed by
Ettus, because that’s something that was available in the lab I’m
working. This type of device allows to receive and send signals
with a frequency ranging from
70 MHz to
6 Ghz, a range that is
good for 4G networks, since they typically require between
3.8 Ghz. This device is also full-duplex, and this is why we
can easily use it to act as a base station in a 4G network. All in
all, it cosfts between
2.000€. An image of the device is
I think you can get a 4G network working also with cheaper options, maybe by buying two cheaper SDRs that are not full-duplex but that can handle only a single direction, and combining them through software to have a virtual full-duplex SDR. Other than the SDR itself we also need a couple of antennas to stick on the board. To be honest I don’t know the particular model of these antennas. I should ask some of my colleagues. Anyways, here they are
Continuing, other hardware requirements have to do with SIM related stuff. Specifically, if we want to use a custom SIM within our UE, we need to program the SIM to hold the custom data that will also be saved in the core network for enabling a correct authentication. This can be done with programmable 4G-SIM. I’m using the one from open-cells. There is also a device that is used to write custom data on the SIM.
Finally, the last thing we need is a smartphone. In terms of
smartphone, for this blog post I’ll be using the
model. Not all smartphones are the same for testing purposes
because some of them might reject the custom data we will write
into the SIM. For example, I’ve also tried to use an
iPhone 11 pro
iPhone 6S, and to make them work with our testbed you have
to change two particular values which are called
MCC, which stands
for “Mobile Country Code”, and
MNC, which stand for “Mobile
So, to recap, we have the following hardware requirements:
- Computer with linux
- SDR + Antenna
- Programmable SIM + Writer for SIM
In terms of software, we need mainly three different software: one for managing the SDR, one for writing custom data to the SIM, and one for managing the base station and the core network.
First things first, let us install all the relative dependencies
for all the software we need. These dependencies are to be
installed on an
arch linux system. For other distributions you
have to find the relative packages.
pacman -S base-devel cmake mbdetls fftw boost lksctp-tools pip install mako
USRP Ettus SDR driver⌗
The first software we need are the drivers that let us work with the SDR we have decided to use. Given that my SDR model is the Ettus B210, the respective drivers can be found in the following github repository: https://github.com/EttusResearch/uhd.
In this demo we will use version
git clone -b "v126.96.36.199" https://github.com/EttusResearch/uhd
To build it and install it execute the following commands
mkdir uhd/host/build cd uhd/host/build cmake ../ -DENABLE-DPDK=OFF make -j$(nproc --ignore=1) make install
After the installation is completed we execute
ldconfig to update
the shared libraries, and we download all the available driver
images using the command
sudo ldconfig sudo uhd_images_downloader
At this point we can connect the board to the computer in which
we installed the driver and we can obtained information about the
connected devices through the command
uhd_find_devices. If the
command does not work by itself, I sugges to add the environment
LD_LIBRARY_PATH, and set it to the directory where there
libuhd.so is installed.
$ sudo LD_LIBRARY_PATH=/usr/local/lib/ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_108100; UHD_4.4.0.main-0-753792a8 [INFO] [B200] Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex... -------------------------------------------------- -- UHD Device 0 -------------------------------------------------- Device Address: serial: XXXXXXX name: MyB210 product: B210 type: b200
As we can see, the UHD device is a
B210 board. From the output I’ve omitted the serial number.
Open Cells UICC/SIM programming⌗
The second software we need is the one we will use to write custom data on our SIM. The software can be obtained from the Open Cells Project Website from the following command
$ curl https://open-cells.com/d5138782a8739209ec5760865b1e53b0/uicc-v3.2.tgz > /tmp/uicc-v3.2.tgz
Notice the version of the software is
uicc-v3.2. By taking a
sha256sum we obtain the following hash
$ sha256sum uicc-v3.2.tgz 6425f05999ff3902e31419f4d94de38632871495a264ee4ad0879c1e20da3719 uicc-v3.2.tgz
we can open it using
tar and compile it using
$ tar -xvf uicc-v3.2.tgz $ cd uicc-v3.2 $ make clean $ make
we can then execute to see the various options
$ ./program_uicc --help ./program_uicc: unrecognized option '--help' unrecognized option: 63 non-option ARGV-elements: Possible options are: --port Linux port to access the card reader (/dev/ttyUSB0) --adm The ADM code of the card (the master password) --iccid the UICC id to set
The srsRAN project implements the majority of the code we will be using to have our custom 4G network. In particular, it implements a 4G core network as well as 4G base station. The software can be used with various SDRs, including the Ettus B210 model. The project is overall very interesting, and you can find more information regarding the srsRAN 4G project at the following link: https://docs.srsran.com/projects/4g/en/latest/index.html
We will use the release with tagged version
23.04 from the
official github repo.
curl -L https://github.com/srsran/srsRAN_4G/archive/refs/tags/release_23_04.tar.gz > /tmp/srsRAN_23_04.tar.gz
we can open the archive and build it as follows. This step has to be done AFTER we have compiled the uhd drivers.
cd /tmp tar -xvf srsRAN_23_04.tar.gz cd srsRAN_23_04 mkdir build cd build cmake ../ make -j$(nproc --ignore=1)
After compilation is over, in the build directory there should be
three directories, named respectively
each of which will contain an ELF binary that implements a
specific component of a 4G network. In particular we have:
./srsepc/src/srsepc, binary that implements the core network.
./srsenb/src/srsenb, binary that implements the base station.
./srsenb/src/srsue, binary that implements the UE.
To make sure everything has been built correctly we can perform the test by executing the following command in the build directory
After this, the last thing we do is we install the software in the system by doing
then we execute this last script to move the configuration files
We are now ready to show how to use these software and hardware pieces to create a custom 4G network.
Making it work⌗
In order to create our custom 4G network we first have to write the UE credentials in two places: within the HSS component of the 4G core network, and within the SIM to be used by the UE.
user_db.csv file, present in the configuration directory of
the core, which is to be found in
~/.config/srsran/, we write
# # .csv to store UE's information in HSS # Kept in the following format: "Name,Auth,IMSI,Key,OP_Type,OP/OPc,AMF,SQN,QCI,IP_alloc" # # Name: Human readable name to help distinguish UE's. Ignored by the HSS # Auth: Authentication algorithm used by the UE. Valid algorithms are XOR # (xor) and MILENAGE (mil) # IMSI: UE's IMSI value # Key: UE's key, where other keys are derived from. Stored in hexadecimal # OP_Type: Operator's code type, either OP or OPc # OP/OPc: Operator Code/Cyphered Operator Code, stored in hexadecimal # AMF: Authentication management field, stored in hexadecimal # SQN: UE's Sequence number for freshness of the authentication # QCI: QoS Class Identifier for the UE's default bearer. # IP_alloc: IP allocation stratagy for the SPGW. # With 'dynamic' the SPGW will automatically allocate IPs # With a valid IPv4 (e.g. '172.16.0.2') the UE will have a statically assigned IP. # # Note: Lines starting by '#' are ignored and will be overwritten ue2,mil,001010123456780,00112233445566778899aabbccddeeff,opc,63bfa50ee6523365ff14c1f45f88737d,8000,0000000014a9,7,dynamic ue1,xor,001010123456789,00112233445566778899aabbccddeeff,opc,63bfa50ee6523365ff14c1f45f88737d,9001,000000001234,7,dynamic
The data here contains various information about the UE that can
correctly authenticate to our custom 4G network. I don’t know the
meaning of all these fields, but the second value, which is
the first row and
xor in the second, is used to specify the
algorithms to be used during the challenges in the authentication
procedure. Then we find the
IMSI, which is sort of a unique
identifier for the UE. Then we have the
key, which is the
symmetric key shared by the UE and the core.
Notice here that the IMSI value actually represents three
different things. The first three digits represent the
there are two or three digits for the
MNC, and the remaining is
MCC -> Mobile Country Code MNC -> Mobile Network Code MSIN -> Mobile Subscription Identification Number
The next step is to write the same IMSI value as well as the same key into the SIM that will be inserted in the UE. Before executing this command we have to insert the SIM writer into the computer.
The command is then the following one. Notice that the
is specific to the SIM and its written on top of the SIM. In the
command I have omitted the specific value that I used.
sudo ./program_uicc --adm XXXXXXXX --imsi 001010123456780 --acc 0001 --key 00112233445566778899aabbccddeeff --opc 63bfa50ee6523365ff14c1f45f88737d -spn "Test" --authenticate --noreadafter
We should see an output similar to this one
Existing values in USIM ICCID: 89860061100000000150 WARNING: iccid luhn encoding of last digit not done USIM IMSI: 001010123456780 USIM MSISDN: 00000001 USIM Service Provider Name: Test Setting new values Succeeded to authentify with SQN: 5280 set HSS SQN value as: 5312 ...
After we write to it we can read the contents by executing
and we get
Existing values in USIM ICCID: 89860061100000000151 WARNING: iccid luhn encoding of last digit not done USIM IMSI: 001010123456780 USIM MSISDN: 00000151 USIM Service Provider Name: open cells No ADM code of 8 figures, can't program the UICC
Once we do that we can insert the SIM into the UE.
Continuing, we mount the antenna on the SDR and connect the SDR to the computer through the USB cable.
Once this is done we can check if the computer sees the correct
SDR by executing
$ sudo LD_LIBRARY_PATH=/usr/local/lib/ uhd_find_devices [INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_108100; UHD_4.4.0.main-0-753792a8 -------------------------------------------------- -- UHD Device 0 -------------------------------------------------- Device Address: serial: XXXXX name: MyB210 product: B210 type: b200
At this point we can execute the core network and the base
station. Before executing the components we check the config files
to change a few lines. In the config file of the core, which is
/root/.config/srsran/epc.conf we change the
interent under the
[mme] section. This is to allow
the UE to use the internet by going through the core. Depending on
the IMSI we decided to use, we might also have to change the
mnc values. For example, when testing the
connectivity I had to change
[mme] mme_code = 0x1a mme_group = 0x0001 tac = 0x0007 mcc = 001 mnc = 01 mme_bind_addr = 127.0.1.100 apn = internet dns_addr = 188.8.131.52 encryption_algo = EEA0 integrity_algo = EIA1 paging_timer = 2 request_imeisv = false lac = 0x0006
We can also, optionally, enable the pcap option in order to save
the traffic that core receives into a pcap file. This is to be
found in the
[pcap] enable = true filename = /tmp/epc.pcap
Once these changes have been made, we can execute the core with the command
we should see the following output, which indicates that the various components of the core have been correctly initialized.
Built in Release mode using commit 98499b8 on branch main. --- Software Radio Systems EPC --- Couldn't open , trying /root/.config/srsran/epc.conf Reading configuration file /root/.config/srsran/epc.conf... Couldn't open user_db.csv, trying /root/.config/srsran/user_db.csv HSS Initialized. MME S11 Initialized MME GTP-C Initialized MME Initialized. MCC: 0xf001, MNC: 0xff01 SPGW GTP-U Initialized. SPGW S11 Initialized. SP-GW Initialized.
The last component to enable is the base station. First change the
configuration file of the base station, which is to be found in
~/.srsran/config/enb.conf. We change in particular
[rf], where we change the
device_name value from
uhd as well as the
device_args value from
send_frame_size=512,recv_frame_size=512,type=b200. At the end we
will have the following
[rf] #dl_earfcn = 3350 tx_gain = 80 rx_gain = 40 device_name = uhd # For best performance in 2x2 MIMO and >= 15 MHz use the following device_args settings: # USRP B210: num_recv_frames=64,num_send_frames=64 # And for 75 PRBs, also append ",master_clock_rate=15.36e6" to the device args # For best performance when BW<5 MHz (25 PRB), use the following device_args settings: # USRP B210: send_frame_size=512,recv_frame_size=512 device_args = send_frame_size=512,recv_frame_size=512,type=b200
Once the configuration is done, we can execute the base station
and we get the following
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_zmq.so Inactive RF plugins: --- Software Radio Systems LTE eNodeB --- Couldn't open , trying /root/.config/srsran/enb.conf Reading configuration file /root/.config/srsran/enb.conf... Couldn't open sib.conf, trying /root/.config/srsran/sib.conf Couldn't open rr.conf, trying /root/.config/srsran/rr.conf Couldn't open rb.conf, trying /root/.config/srsran/rb.conf WARNING: cpu0 scaling governor is not set to performance mode. Realtime processing could be compromised. Consider setting it to performance mode before running the application. Built in Release mode using commit 98499b8 on branch main. Opening 1 channels in RF device=uhd with args=send_frame_size=512,recv_frame_size=512,type=b200 Supported RF device list: UHD zmq file [INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_108100; UHD_4.4.0.main-0-753792a8 [INFO] [LOGGING] Fastpath logging disabled at runtime. Opening USRP channels=1, args: send_frame_size=512,recv_frame_size=512,type=b200,master_clock_rate=23.04e6 [INFO] [UHD RF] RF UHD Generic instance constructed [INFO] [B200] Detected Device: B210 [INFO] [B200] Loading FPGA image: /usr/local/share/uhd/images/usrp_b210_fpga.bin... [INFO] [B200] Operating over USB 2. [INFO] [B200] Detecting internal GPSDO.... [INFO] [GPS] No GPSDO found [WARNING] [B200] The recv_frame_size must be a multiple of 8 bytes and not a multiple of 512 bytes. Requested recv_frame_size of 512 coerced to 520. [INFO] [B200] Initialize CODEC control... [INFO] [B200] Initialize Radio control... [INFO] [B200] Performing register loopback test... [INFO] [B200] Register loopback test passed [INFO] [B200] Performing register loopback test... [INFO] [B200] Register loopback test passed [INFO] [B200] Asking for clock rate 23.040000 MHz... [INFO] [B200] Actually got clock rate 23.040000 MHz. ==== eNodeB started === Type <t> to view trace Setting frequency: DL=2680.0 Mhz, UL=2560.0 MHz for cc_idx=0 nof_prb=50 [INFO] [UHD RF] Tx while waiting for EOB, timed out... 1.73016 >= 0. Starting new burst...
Notice the warning telling us to put the scaling governor of
to performance mode. This has to do for performance reasons, and I
shall not do it for this particular test. For more information I
suggest to look into it in the following URL: wiki.archlinux.org -
CPU frequency scaling.
After we have started the base station, if we then look at the output from the core process, we should see the base station attaching to the core
Received S1 Setup Request. S1 Setup Request - eNB Name: srsenb01, eNB id: 0x19b S1 Setup Request - MCC:001, MNC:01 S1 Setup Request - TAC 7, B-PLMN 0xf110 S1 Setup Request - Paging DRX v128 Sending S1 Setup Response ...
At this point the base station has started to work and send
signals. The only thing that remain is to power on the UE and
attach it to the network. With respect to the UE configuration, we
just have to remember to put the SIM with our custom
authentication data inside the UE. We also need to set within the
APN with the
type value set to
As soon as we activate the SIM, we should see the core output as well as the base station output activate.
From the output of the base station we see
RACH: tti=851, cc=0, pci=1, preamble=29, offset=0, temp_crnti=0x46 User 0x46 connected
From the output of the core network we see the attach request of
the UE, the authentication procedure and a bunch of other things
that happen during the initial attachment. Notice how it printed
our custom IMSI, which is
Initial UE message: LIBLTE_MME_MSG_TYPE_ATTACH_REQUEST Received Initial UE message -- Attach Request Attach request -- IMSI: 001010123456780 Attach request -- eNB-UE S1AP Id: 1 Attach request -- Attach type: 2 Attach Request -- UE Network Capabilities EEA: 11110000 Attach Request -- UE Network Capabilities EIA: 11110000 Attach Request -- MS Network Capabilities Present: true PDN Connectivity Request -- EPS Bearer Identity requested: 0 PDN Connectivity Request -- Procedure Transaction Id: 23 PDN Connectivity Request -- ESM Information Transfer requested: true Downlink NAS: Sending Authentication Request UL NAS: Received Authentication Response Authentication Response -- IMSI 001010123456780 UE Authentication Accepted. Generating KeNB with UL NAS COUNT: 0 Downlink NAS: Sending NAS Security Mode Command. UL NAS: Received Security Mode Complete Security Mode Command Complete -- IMSI: 001010123456780 Sending ESM information request UL NAS: Received ESM Information Response ESM Info: APN internet ESM Info: 6 Protocol Configuration Options Getting subscription information -- QCI 7 Sending Create Session Request. Creating Session Response -- IMSI: 1010123456780 Creating Session Response -- MME control TEID: 1 Received GTP-C PDU. Message type: GTPC_MSG_TYPE_CREATE_SESSION_REQUEST SPGW: Allocated Ctrl TEID 1 SPGW: Allocated User TEID 1 SPGW: Allocate UE IP 172.16.0.2 Received Create Session Response Create Session Response -- SPGW control TEID 1 Create Session Response -- SPGW S1-U Address: 127.0.1.100 SPGW Allocated IP 172.16.0.2 to IMSI 001010123456780 Adding attach accept to Initial Context Setup Request Sent Initial Context Setup Request. E-RAB id 5 Received Initial Context Setup Response E-RAB Context Setup. E-RAB id 5 E-RAB Context -- eNB TEID 0x1; eNB GTP-U Address 127.0.1.1 UL NAS: Received Attach Complete Unpacked Attached Complete Message. IMSI 1010123456780 Unpacked Activate Default EPS Bearer message. EPS Bearer id 5 Received GTP-C PDU. Message type: GTPC_MSG_TYPE_MODIFY_BEARER_REQUEST Sending EMM Information
At this point if we try to go to the internet with the phone, we
will not be able to. This is because to enable internet
connectivity we have to go back to the main folder in which we
srsran and execute the following script, where here
wlan0 is the name of the interface that gives internet to the
computer that hosts the core network. With this command the UE
will be able to connect to the internet by using the core’s
sudo ./srsepc/srsepc_if_masq.sh wlan0
And that’s it, we have our own custom 4G network! We can browse the internet and… well, for now just that. We can also change the name of the network that is shown in the phone.
While I was writing this blog post I made the same setup on two
different machine: the laptop that I use for work, and the desktop
computer I have at home. While in the laptop I had some problems
related to the setting of
APNs within the cellphone, after fixing
these small issues everything worked fine and reliably. With the
desktop setup however things turned out quite problematic, and
I’ve yet to figure out what does not work properly. I suspect at
this point that the problem is related to the old hardware that
runs on my desktop, not sure if the processor or the motherboard
itself, because whenever I try to connect the UE to the base
station, I get nothing, not even an attempt, just nothing, the
base station reads nothing.
The only difference I’ve noticed between the two setup is that
when I connect the SDR to my laptop, there is a red and green
light, where the red lights up the
TX/RX port, while the green
light lights up the
RX2 port. When I connect the SDR to the
desktop however while the green like remains the same, the red
light is much weaker and barely lights up. Having said that, I’m
pretty ignorant when it comes to radio signal, so at this moment
I’m not able to debug this particular problem. Could this
difference mean something?
UPDATE 1: A colleague told me that this behavior might have to do with power issues, meaning that when the red light doesn’t blink that much its because it doesn’t receive enough power through the USB port. This devices have also an external power plug, but sometimes the USB cable is enough. It appears that in my desktop not enough power goes through the USB cable, and therefore I have this sort of problems.
UPDATE 2: I actually tried to power it up with an external power plug, and the problem remains. Now I suspect it has to do with the fact that the USB ports in my desktop are really slow, and they’re not as fast as the SDR requires them to be.
We have created our own custom 4G network that allows a basic UE
to connect to the core network. With this we can grant internet to
the UE by using the internet connection of the core network. There
are, however, a whole lot of things that can be improved. Just to
mention one, for example, this custom 4G network does not support
VoLTE. There are other things like this that can be
extended, most of which I do not even know. This is just to point
out the obvious: this setup is just a very limited 4G testbed.
What about 5G?⌗
To finish this long blog post, let us now wonder: and what about
5G then? What does it change from 5G to 4G?
As I repeated multiple times, I’m no expert in this. However, from the little I understand, one can view the 5G network architecture as an extension of the 4G network architecture. The basic building blocks remain still the UE, the base station and the core network, but in 5G the core network is much more complex and offers advanced services such as 5G network slicing. At the same time, the UE and the base station have also changed to offer even greater speeds and reliability.
The core network portion of the 5G network is very similar to a
traditional cloud, and different components communicate with
eachothers using HTTP REST APIs protected through TLS. This
structure is called the Service Based Architecture (
There many other changes going from 4G to 5G. Another change that I do know about is that in 4G the IMSI is sent in clear the first time the UE connects to the network. This privacy gap has allowed for the development so-called IMSI-catcher, which are malicious devices that act as 4G base stations and force UEs to connect to them in order to steal their IMSI. In 5G this gap has been closed, by protecting the IMSI with encryption even in the first attach request. The way in which this is actually implemented are very complicated, and have to do with special SIMs called eSIMs. Anyways, this blog post is already too long.
That’s it. I hope it was an interesting read. In future blog posts, maybe, I can also write in more detail about the 4G authentication flow with more cryptographic detail, which is something I understand much better than, say, the procedure used by the UE to establish the radio channel with the base station. Having said that, it would be also cool to understand a little bit better how Digital Signaling Processing actually works under the hood.
Some useful references for understanding more about 4G and 5G