Srslte Docs

srsRAN 4G Documentation
Release 22.10
[’Software Radio Systems’]
Feb 22, 2023

GENERAL
1 Getting Started 2
2 srsRAN 4G Features 3
2.1 srsUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 srsENB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 srsEPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Reporting issues 6
4 Installation Guide 7
4.1 Which Installation Should I Use? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Package Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Installation from Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Getting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 Release Notes 11
6 Contributions 17
6.1 FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7 Troubleshooting 19
7.1 Building with Debug Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2 Examining PCAPs with Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8 LTE Setup Guide 21

8.1 Baseline Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2 Running a 4G End-to-end System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9 UE User Manual 24
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.3 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.4 Advanced Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.5 Configuration Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.6 Command Line Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10 eNodeB User Manual 39

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
i
10.4 Advanced Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.6 Command Line Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11 EPC User Manual 53

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
12 srsRAN 4G with ZMQ Virtual Radios 60

12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.2 ZeroMQ Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.3 Running a full end-to-end LTE network on a single computer . . . . . . . . . . . . . . 61
12.4 GNU-Radio Companion Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
12.5 Known issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
13 COTS UE 65
13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.2 Driver & Conf. File Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.3 Connecting a COTS UE to srsRAN 4G . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14 Intra-eNB & S1 Handover 78

14.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
14.2 Intra-eNB Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
14.3 S1 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
15 Carrier Aggregation 101

15.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
15.2 Carrier Aggregation using SDR Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 101
15.3 Carrier Aggregation using ZeroMQ RF emulation . . . . . . . . . . . . . . . . . . . . 103
15.4 Known issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
16 C-V2X Signalling 104

16.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
16.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
16.3 Anatomy of a C-V2X Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
16.4 Decoding C-V2X Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
17 eMBMS End-to-End 109

17.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
17.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
17.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
18 NB-IoT Signalling 112

18.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
18.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
18.3 Spotting local NB-IoT deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
18.4 Decoding the NB-IoT transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
18.5 Transmit and Receive Downlink Signal . . . . . . . . . . . . . . . . . . . . . . . . . . 116
ii
18.6 Known issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
19 srsRAN 4G on Raspberry Pi 4 119

19.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
19.2 Pi4 eNodeB Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
19.3 Software Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
19.4 Pi4 eNodeB Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
19.5 Running the Pi4 eNodeB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
19.6 Known issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
19.7 Running on Ubuntu 22.04 LTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
20 Hardware Options 126

20.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
20.2 Choosing Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
20.3 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
20.4 ZMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
20.5 Choosing a USRP and RF Daughter Card . . . . . . . . . . . . . . . . . . . . . . . . . 130
21 5G SA End-to-End 131
21.1 Network & Hardware Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
21.2 Set-up The Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
21.3 Testing the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
22 5G SA COTS UE 141
22.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
22.3 Preparing COTS UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
22.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
22.5 Connecting to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
22.6 srsENB Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
22.8 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
22.9 Tested Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
23 5G SA srsUE 152
23.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.2 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.3 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
23.5 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
23.6 Running the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
23.7 Console Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
24 5G NSA End-to-End 159

24.1 5G NSA Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
24.3 Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
24.4 Network Set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.5 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
25 5G NSA COTS UE 169

25.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
iii
25.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
25.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
25.5 Connecting to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
25.6 Confirming connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
26 5G NSA srsUE 182

26.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
26.2 5G NSA: What you need to know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
26.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
26.4 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
26.5 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
26.6 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
26.7 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
iv
srsRAN 4G Documentation, Release 22.10
srsRAN 4G is an open-source 4G software radio suite from SRS.

Featuring UE, eNodeB and lightweight EPC applications, srsRAN 4G can be used to build a complete
end-to-end LTE mobile wireless network. For more information, see www.srsran.com.
The srsRAN 4G suite currently includes:
• srsUE: a full-stack 4G UE application with prototype 5G features
• srsENB: a full-stack 4G eNodeB
• srsEPC: a light-weight 4G EPC implementation with MME, HSS and S/P-GW
All srsRAN 4G software runs in linux with off-the-shelf compute and radio hardware.
For our ORAN-native 5G CU/DU solution, see the srsRAN Project documentation.
GENERAL 1
CHAPTER
ONE
GETTING STARTED
Get srsRAN 4G installed on your computer:

- Installation
Get a network up and running:

- End-to-end Network Setup
Read the user manuals:

- UE User Manual
- eNodeB User Manual
- EPC User Manual
Read the srsRAN 4G Application Notes:

- Application Notes
Take a look at the source code:

- srsRAN 4G on GitHub
Learn about the team behind srsRAN 4G:

- Software Radio Systems
Join our mailing list for news and user support:

- Mailing List
2
CHAPTER
TWO
SRSRAN 4G FEATURES
2.1 srsUE
srsUE is a 4G LTE UE modem with prototype 5G NR features implemented entirely in software. Running
as an application on a standard Linux-based operating system, srsUE connects to any LTE network and
provides a standard network interface with high-speed mobile connectivity.
The SRS UE includes the following features:
• LTE Release 10 aligned with features up to release 15
• Prototype 5G NSA and SA support
• TDD and FDD configurations
• Tested bandwidths: 1.4, 3, 5, 10, 15 and 20 MHz
• Transmission modes 1 (single antenna), 2 (transmit diversity), 3 (CCD) and 4 (closed-loop spatial
multiplexing)
• Manually configurable DL/UL carrier frequencies
• Soft USIM supporting XOR/Milenage authentication
• Hard USIM support via PC/SC
• Snow3G and AES integrity/ciphering support
• TUN virtual network kernel interface integration for Linux OS
• Detailed log system with per-layer log levels and hex dumps
• MAC and NAS layer wireshark packet captures
• Command-line trace metrics
• Detailed input configuration files
• Evolved multimedia broadcast and multicast service (eMBMS)
• Frequency-based ZF and MMSE equalizers
• Highly optimized Turbo Decoder available in Intel SSE4.1/AVX2 (+150 Mbps)
• Channel simulator for EPA, EVA, and ETU 3GPP channels
• QoS support
• 150 Mbps DL in 20 MHz MIMO TM3/TM4 or 2xCA configuration (195 Mbps with QAM256)
• 75 Mbps DL in 20 MHz SISO configuration (98 Mbps with QAM256)
3
• 36 Mbps DL in 10 MHz SISO configuration

• Supports Ettus USRP B2x0/X3x0 families, BladeRF, LimeSDR
Read the UE User Manual. for further info on the UE.
2.2 srsENB
The srsENB LTE eNodeB includes the following features:

• Prototype 5G NR support for both 5G NSA and SA
• FDD configuration
• Transmission mode 1 (single antenna), 2 (transmit diversity), 3 (CCD) and 4 (closed-loop spatial
multiplexing)
• Frequency-based ZF and MMSE equalizer
• MAC layer wireshark packet capture
• ZeroMQ-based fake RF driver for I/Q over IPC/network
• Intra-ENB and Inter-ENB (S1) mobility support
• Proportional-fair and round-robin MAC scheduler with FAPI-like C++ API
• SR support
• Periodic and Aperiodic CQI feedback support
• Standard S1AP and GTP-U interfaces to the Core Network
• 150 Mbps DL in 20 MHz MIMO TM3/TM4 with commercial UEs (195 Mbps with QAM256)
• 75 Mbps DL in SISO configuration with commercial UEs
• 50 Mbps UL in 20 MHz with commercial UEs
• User-plane encryption
Read the ENB User Manual. for further info on the eNB.
4 Chapter 2. srsRAN 4G Features

2.3 srsEPC
srsEPC is a lightweight implementation of a complete LTE core network (EPC). The srsEPC application
runs as a single binary but provides the key EPC components of Home Subscriber Service (HSS), Mobil-
ity Management Entity (MME), Service Gateway (S-GW) and Packet Data Network Gateway (P-GW).
The srsEPC application is not intended for deployment but can be used for testing.
Read the EPC User Manual. for further info on the EPC.
2.3. srsEPC 5
CHAPTER
THREE
REPORTING ISSUES
For contributing code and reporting issues we generally encourage users to directly use the Github’s pull
request or issue tracking system. This allows easy tracking and also make enhancements and fixes coming
from public users available to everyone immediately.
For issues or fixes that could potentially affect the security of users we also provide a dedicated mail ad-
dress [email protected] that shall be used for private communication. The srsRAN team will carefully
check and analyse each submission and assign a threat category to make sure it is addressed appropriately.
6
CHAPTER
FOUR
INSTALLATION GUIDE
4.1 Which Installation Should I Use?
srsRAN 4G can be installed from packages or from source. The following decision tree should help users
decide which is best for them:
In short, users looking for a simple installation who only expect to run basic srsRAN 4G applications
7
with USRP front-ends should use the package installation. Users who wish to modify srsRAN 4G and/or
use alternative RF front-ends such as limeSDR and BladeRF should install from source.
4.2 Package Installation
The srsRAN 4G software suite can be installed using packages on Ubuntu:
sudo add-apt-repository ppa:softwareradiosystems/srsran_4g

sudo apt-get update
sudo apt-get install srsran_4g -y
Package installs are also available for other distributions.

• openSUSE
• Arch Linux
• Debian (Pop OS, Mint, etc)
Note, only the Launchpad packages for Ubuntu are maintained by SRS. Different distributions will main-
tain their own packages for srsRAN 4G, which may or may not be up to date. Check the available version
before installing to ensure you are using the desired version of srsRAN 4G.
Fedora does not yet have support for a package installation of srsRAN 4G.
4.3 Installation from Source
• Mandatory requirements:
– Common:
∗ cmake
∗ libfftw
∗ mbedTLS
– srsUE:
∗ Boost
– srsENB:
∗ Boost
∗ lksctp
∗ config
– srsEPC:
∗ Boost
∗ lksctp
∗ config
For example, on Ubuntu, one can install the required libraries with:
8 Chapter 4. Installation Guide

sudo apt-get install build-essential cmake libfftw3-dev libmbedtls-dev␣

˓→libboost-program-options-dev libconfig++-dev libsctp-dev
or on Fedora:
dnf install cmake fftw3-devel mbedtls-devel lksctp-tools-devel libconfig-

˓→devel boost-devel
For CentOS, use the Fedora packages but replace libconfig-devel with just libconfig.
Note that depending on your flavor and version of Linux, the actual package names may be different.
• Optional requirements:
– srsGUI - for real-time plotting.
– libpcsclite-dev - for accessing smart card readers
– libdw-dev libdw - for truly informative backtraces using backward-cpp
• RF front-end driver:
– UHD
– SoapySDR
– BladeRF
– ZeroMQ
Note: If using UHD we recommended the LTS version of UHD, i.e. either 3.9.7 or 3.15.
Warning: All mandatory requirements, optional requirements, and RF front-end drivers must be
installed prior to building srsRAN 4G. Failing to do this will result in errors at run-time or prevent
srsRAN 4G from building correctly.
Download and build srsRAN 4G:
git clone https://github.com/srsRAN/srsRAN_4G.git

cd srsRAN_4G
mkdir build
cd build
cmake ../
make
make test
Install srsRAN 4G:
sudo make install

srsran_4g_install_configs.sh user
This installs srsRAN 4G and also copies the default srsRAN 4G config files to ~/.config/srsran_4g.
4.3. Installation from Source 9

4.4 Getting Support
Join the community on the srsRAN 4G users mailing list. The mailing list is a great place to ask questions,
get support from the community and learn more about the various projects users are working on.
10 Chapter 4. Installation Guide

CHAPTER
FIVE
RELEASE NOTES
• 22.10
– Fix DL NAS integrity checks in srsUE
– Remove Travis and LGTM as CI platforms
– Remove polarssl as optional dependency (only mbedTLS used and required for security)
– Allow to specify multiple PLMNs in SIB1
– Allow non-blocking S1AP connect and expose various other SCTP options
– Add support to broadcast MAC backoff indicator
– Seperate T300/T301 timer in srsENB
– Fix in eMBMS payload buffer handling
– Fix memleak in NR scheduler
• 22.04.1
– Bug-fixes in RLC AM and PDCP in NR
– Fix for UE crashing when attempting to re-establish connection in SA mode
– Removed fixed coreset0 index for SSB
– Added support for SIB5 and SIB6 transmission in LTE
• 22.04
– Added baseline 5G-SA support to srsUE and srsENB
– Added dynamic loading of RF libraries
– Added RRC Redirect to srsUE
– Added support for A5 measurement events to srsENB
– Added Crest Factor Reduction (CFR) for srsENB downlink and srsUE uplink on LTE carriers
– Raise C++ standard to C++14
– Other bug-fixes and improved stability and performance in all parts
• 21.10
– Created initial version of srsGNB supporting NSA mode with srsENB
– srsGNB tested with OnePlus Nord 5G
11
– Improved interoperability of srsUE in NSA mode

– Added enhanced instrumentation to file using JSON format
– Fixed stability issues with Ettus N310
– Added BLER-adaptive MCS scheduling to srsENB
• 21.04
– Rename project from srsLTE to srsRAN
– Add initial 5G NSA support to srsUE (including x86-optimized FEC and PHY layer)
– Add PDCP discard support
– Add UL power control, measurement gaps and a new proportional fair scheduler to srsENB
– Extend GTP-U tunneling to support tunnel forwarding over S1
– Optimize many data structures, remove dynamic memory allocations in data plane
– Improved S1AP error handling and enhanced event reporting
– Update ASN.1 packing/unpacking, RRC to Rel 15.11, S1AP to Rel 16.1
– Update PCAP writer to use UDP framing
• 20.10.1
– Fix eNB issue relating to uplink hybrid ARQ
• 20.10
– EUTRA mobility support
– Fix for QAM256 support for eNB
– New logging framework
– PHY optimizations
– Other performance and stability improvements
• 20.04.1
– Fix for UE MIMO segfault issue
– Fix for eNodeB SR configuration
– Clang compilation warning fixes
– Fix GPS tracking synchronization
• 20.04
– Carrier Aggregation and Time Alignment in srsENB
– Complete Sidelink PHY layer (all transmission modes)
– Complete NB-IoT PHY downlink signals
– New S1AP packing/unpacking library
12 Chapter 5. Release Notes

– EVM and EPRE measurements

– Remove system timers in srsUE and srsENB
– Refactor eNB to prepare for mobility support
• 19.12
– Add 5G NR RRC and NGAP ASN1 packing/unpacking
– Add sync routines and broadcast channel for Sidelink
– Add cell search and MIB decoder for NB-IoT
– Add PDCP discard
– Improve RRC Reestablishment handling
– Improve RRC cell measurements and procedure handling
– Add multi-carrier and MIMO support to ZMQ radio
– Refactor eNB scheduler to support multiple carriers
– Apply clang-format style on entire code base
• 19.09
– Add initial support for NR in MAC/RLC/PDCP
– Add sync code for NB-IoT
– Add support for EIA3/EEA3 (i.e. ZUC)
– Add support for CSFB in srsENB
– Add adaptation layer to run TTCN-3 conformance tests for srsUE
– Add High Speed Train model to channel simulator
– Rework RRC and NAS layer and make them non-blocking
– Fixes in ZMQ, bladeRF and Soapy RF modules
• 19.06
– Add QAM256 support in srsUE
– Add QoS support in srsUE
– Add UL channel emulator
– Refactor UE and eNB architecture
– Many bug-fixes and improved stability and performance in all parts
• 19.03
– PHY library refactor
– TDD support for srsUE
13
– Carrier Aggregation support for srsUE

– Paging support for srsENB and srsEPC
– User-plane encryption for srsENB
– Channel simulator for EPA, EVA, and ETU 3GPP channels
– ZeroMQ-based fake RF driver for I/Q over IPC/network
• 18.12
– Add new RRC ASN1 message pack/unpack library
– Refactor EPC and add encryption support
– Add IPv6 support to srsUE
– Fixed compilation issue for ARM and AVX512
– Add clang-format file
• 18.09
– Improved Turbo Decoder performance
– Configurable SGi interface name and M1U params
– Support for GPTU echo mechanism
– Added UE detach capability
– Refactor RLC/PDCP classes
– Various fixes for ARM-based devices
– Added support for bladeRF 2.0 micro
• 18.06.1
– Fixed RLC reestablish
– Fixed aperiodic QCI retx
– Fixed eNB instability
– Fixed Debian packaging
• 18.06
– Added eMBMS support in srsUE/srsENB/srsEPC
– Added support for hard SIM cards
• 18.03.1
– Fixed compilation for NEON
– Fixed logging and RLC AM issue

• 18.03
• 17.12
– Added support for MIMO 2x2 in srsENB (i.e. TM3/TM4)
– Added srsEPC, a light-weight core network implementation
– Added support for X2/S1 handover in srsUE
– Added support for user-plane encryption in srsUE
– Many bug-fixes and improved stability and performance in srsUE/srsENB
• 17.09
– Added MIMO 2x2 in the PHY layer and srsUE (i.e. TM3/TM4)
– eMBMS support in the PHY layer
– Many bug-fixes and improved stability and performance in srsUE/srsENB
• 002.000.000
– Added fully functional srsENB to srsRAN code
– Merged srsUE code into srsRAN and reestructured PHY code
– Added support for SoapySDR devices (eg LimeSDR)
– Fixed issues in RLC AM
– Added support for NEON and AVX in many kernels and Viterbi decoder
– Added support for CPU affinity
– Other minor bug-fixes and new features
• 001.004.000
– Fixed issue in rv for format1C causing incorrect SIB1 decoding in some networks
– Improved PDCCH decoding BER (fixed incorrect trellis initialization)
– Improved PUCCH RX performance
• 001.003.000
– Bugfixes:
∗ x300 master clock rate
∗ PHICH: fixed bug causing more NACKs
∗ PBCH: fixed bug in encoding function
∗ channel estimation: fixed issue in time interpolation
∗ DCI: Fixed bug in Format1A packing
∗ DCI: Fixed bug in Format1C for RA-RNTI
∗ DCI: Fixed overflow in MIMO formats
– Improvements:
15
∗ Changed and cleaned DCI blind search API

∗ Added eNodeB PHY processing functions
• 001.002.000
– Bugfixes:
∗ Estimation of extrapolated of out-of-band carriers
∗ PDCCH REG interleaving for certain cell IDs
∗ MIB decoding
∗ Overflow in viterbi in PBCH
– Improvements:
∗ Synchronization in long multipath channels
∗ Better calibration of synchronization and estimation
∗ Averaging in channel estimation
∗ Improved 2-port diversity decoding
• 001.001.000
– Added support for BladeRF

CHAPTER
SIX
CONTRIBUTIONS
Contributions to the srsRAN 4G software suite are always welcome. The easiest way to contribute is by
issuing a pull request on the srsRAN 4G repository. We use clang-format to maintain consistent code
style - see our default format.
We ask srsRAN 4G contributors to agree to a Copyright License Agreement. This provides us with
necessary permissions to use contributed code. For more information, see the FAQ below. Viewing and
accepting the CLA agreement is integrated into the GitHub pull request workflow using CLAassistant.
6.1 FAQ
6.1.1 1. What is a Copyright License Agreement (CLA) and why do I need one?
A Copyright License Agreement is a legal document in which you state you are entitled to contribute
the code/documentation/translation to the project you’re contributing to and are willing to have it used in
distributions and derivative works. This means that should there be any kind of legal issue in the future
as to the origins and ownership of any particular piece of code, then that project has the necessary forms
on file from the contributor(s) saying they were permitted to make this contribution.
The CLA also ensures that once you have provided a contribution, you cannot try to withdraw permission
for its use at a later date. People and companies can therefore use that software, confident that they will
not be asked to stop using pieces of the code at a later date.
The agreements used by the srsRAN 4G project are standard documents provided by Project Harmony, a
community-centered group focused on contributor agreements for free and open source software (FOSS).
For more information, see www.harmonyagreements.org.
6.1.2 2. How do I complete and submit the CLA?
The srsRAN 4G CLA for Individual contributions can be found here. The srsRAN 4G CLA for Entity
contributions can be found here. Download the appropriate CLA, then print, sign and scan the document
before sending by email to [email protected].
17
6.1.3 3. How will my contributions to srsRAN 4G be used?
The srsRAN 4G project was created and is maintained by Software Radio Systems (SRS), a private
limited company headquartered in Ireland. SRS provides srsRAN 4G under both the open-source AG-
PLv3 license and commercial licenses. SRS also sells proprietary software products which build upon
the srsRAN 4G codebase. In this way, we attempt to ensure the ongoing development, evolution and
sustainability of the srsRAN 4G project.
Through the license agreements, we ask you to grant us permission to use your contributions within
srsRAN 4G and to continue to provide srsRAN 4G under open-source and commercial licenses and
within proprietary products. As we do not ask for copyright assignment, you retain complete ownership
of your contributions and have the same rights to use or license those contributions which you would
have had without entering into a license agreement.
If you have any questions about srsRAN 4G licensing and contributions, please contact us at licens-
[email protected]
18 Chapter 6. Contributions
CHAPTER
SEVEN
TROUBLESHOOTING
7.1 Building with Debug Symbols
First make sure srsRAN 4G has been downloaded, and you have created and navigated to the build folder:
git clone https://github.com/srsran/srsran_4g.git

cd srsRAN_4G
mkdir build
cd build
To build srsRAN 4G with debug symbols, the following steps can be taken. If srsRAN 4G has already
been built, the original build folder should be cleared before proceeding. This can be done with the
following command:
rm -rf *
make clean
The following command can then be used to build srsRAN 4G with debug symbols enabled:
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ../

make
make test
The log file containing the debug info can be found in the srsran_backtrace.log file.
7.2 Examining PCAPs with Wireshark
The srsRAN 4G applications support packet capture at the MAC and NAS layers of the network stack.
Packet capture files (pcaps) can be viewed using Wireshark (www.wireshark.org). pcaps are encoded
in compact MAC-LTE and MAC-NR form. They can be found in the /tmp folder where other logs are
located. To view in wireshark, edit the preferences of the DLT_USER dissector.
To decode MAC pcaps add an entry with the following:
• DLT=149
• Payload Protocol=udp
Further, enable the heuristic dissection in UDP under: Analyze > Enabled Protocols > MAC-LTE >
mac_lte_udp and MAC-NR > mac_nr_udp
19
Using the same filename for mac_filename and mac_nr_filename writes both MAC-LTE and MAC-NR
to the same file allowing a better analysis.
To decode NAS pcaps add and entry with the following:
• DLT=148
• Payload Protocol=nas-eps
For more information, see https://wiki.wireshark.org/MAC-LTE.
The srsEPC application supports packet capture (pcap) of S1AP messages between the MME and eN-
odeBs. Enable packet captures in epc.conf or on the command line, by setting the pcap.enable value to
true. To view in wireshark, edit the preferences of the DLT_USER dissector.
To decode S1AP pcaps add an entry with:
• DLT=150
• Payload Protocol=s1ap
20 Chapter 7. Troubleshooting
CHAPTER
EIGHT
LTE SETUP GUIDE
8.1 Baseline Hardware Requirements
Fig. 1: Basic srsRAN 4G LTE set-up with USRPs
The overall system requires 2 x RF-frontends and 2 x PCs with a Linux based OS. This can be broken
down as follows:
Table 1: System Hardware Requirements

Network Element RF-Frontend Linux based PC
srsUE X X
srsENB X X
srsEPC X
The UE will be instantiated on machine 1 with an RF-frontend attached. The eNB will run on machine 2
with an RF-frontend attached to communicate over the air with the UE. The EPC will be instantiated on
the same machine as the eNB. See the following figure which outlines the overall system architecture.
A list of supported RF front-end drivers is outlined here. We also have some suggested hardware pack-
ages, which can be found here.
8.2 Running a 4G End-to-end System
The following execution instructions are for users that have the appropriate RF-hardware to simulate a
network. If you would like to test the use of srsRAN 4G without RF-hardware please see the ZeroMQ
application note.
The srsUE, srsENB and srsEPC applications include example configuration files that should be copied
(manually or by using the convenience script) and modified, if needed, to meet the system configuration.
On many systems they should work out of the box.
By default, all applications will search for config files in the user’s home directory (~/.srs) upon startup.
21
Note that you have to execute the applications with root privileges to enable real-time thread priorities
and to permit creation of virtual network interfaces.
srsENB and srsEPC can run on the same machine as a network-in-the-box configuration. srsUE needs to
run on a separate machine.
If you have installed the software suite using `sudo make install` and have installed the example
config files using `sudo srsRAN_4G_install_configs.sh`, you may just start all applications with
their default parameters.
8.2.1 srsEPC
On machine 1, run srsEPC as follows:
sudo srsepc
Using the default configuration, this creates a virtual network interface named “srs_spgw_sgi” on ma-
chine 1 with IP 172.16.0.1. All connected UEs will be assigned an IP in this network.
8.2.2 srsENB
Also on machine 1, but in another console, run srsENB as follows:
sudo srsenb
8.2.3 srsUE
On machine 2, run srsUE as follows:
sudo srsue
Using the default configuration, this creates a virtual network interface named “tun_srsue” on machine
2 with an IP in the network 172.16.0.x. Assuming the UE has been assigned IP 172.16.0.2, you may
now exchange IP traffic with machine 1 over the LTE link. For example, run a ping to the default SGi IP
address:
ping 172.16.0.1
8.3 Examples
If srsRAN 4G is built from source, then pre-configured example use-cases can be found in the following
folder: `./srsRAN_4G/build/lib/examples`
The following list outlines some of the use-cases covered:
• Cell Search
• NB-IoT Cell Search
• A UE capable of decoding PDSCH packets
22 Chapter 8. LTE Setup Guide

• An eNB capable of creating and transmitting PDSCH packets

Note, the above examples require RF-hardware to run. These examples also support the use of srsGUI
for real time plotting of data.
8.3. Examples 23
CHAPTER
NINE
UE USER MANUAL
9.1 Introduction
9.1.1 Overview
SrsUE is a 4G LTE UE modem implemented entirely in software. Running as an application on a standard

Linux-based operating system, srsUE connects to any LTE network and provides a standard network
interface with high-speed mobile connectivity. To transmit and receive radio signals over the air, srsUE
requires SDR hardware such as the Ettus Research USRP.
To provide a complete end-to-end LTE network, use srsUE with srsENB and srsEPC.
This User Guide provides all the information needed to get up and running with the srsUE application,
to become familiar with all of the key features and to achieve optimal performance. For information on
extending or modifying the srsUE source code, please see the srsUE Developers Guide.
9.1.2 Features
The SRS UE includes the following features:

• Prototype 5G NSA and SA support
• TDD and FDD configurations
• Transmission modes 1 (single antenna), 2 (transmit diversity), 3 (CCD) and 4 (closed-loop spatial
multiplexing)
• Manually configurable DL/UL carrier frequencies
• Soft USIM supporting XOR/Milenage authentication
24
• Hard USIM support via PC/SC

• Snow3G and AES integrity/ciphering support
• TUN virtual network kernel interface integration for Linux OS
• MAC and NAS layer wireshark packet captures
• Frequency-based ZF and MMSE equalizers
• QoS support
• 150 Mbps DL in 20 MHz MIMO TM3/TM4 or 2xCA configuration (195 Mbps with QAM256)
• 75 Mbps DL in 20 MHz SISO configuration (98 Mbps with QAM256)
• 36 Mbps DL in 10 MHz SISO configuration
• Supports Ettus USRP B2x0/X3x0 families, BladeRF, LimeSDR
9.1.3 UE architecture
Fig. 1: Basic UE Architecture
9.1. Introduction 25
The srsUE application includes layers 1, 2 and 3 as shown in the figure above.
At the bottom of the UE protocol stack, the Physical (PHY) layer carries all information from the MAC
over the air interface. It is responsible for link adaptation, power control, cell search and cell measure-
ment.
The Medium Access Control (MAC) layer multiplexes data between one or more logical channels into
Transport Blocks (TBs) which are passed to/from the PHY layer. The MAC is responsible for control
and scheduling information exchange with the eNodeB, retransmission and error correction (HARQ) and
priority handling between logical channels.
The Radio Link Control (RLC) layer can operate in one of three modes: Transparent Mode (TM), Unac-
knowledged Mode (UM) and Acknowledged Mode (AM). The RLC manages multiple logical channels or
bearers, each of which operates in one of these three modes. Transparent Mode bearers simply pass data
through the RLC. Unacknowledged Mode bearers perform concatenation, segmentation and reassembly
of data units, reordering and duplication detection. Acknowledged Mode bearers additionally perform
retransmission of missing data units and resegmentation.
The Packet Data Convergence Protocol (PDCP) layer is responsible for ciphering of control and data
plane traffic, integrity protection of control plane traffic, duplicate discarding and in-sequence delivery
of control and data plane traffic to/from the RRC and GW layers respectively. The PDCP layer also
performs header compression (ROHC) of IP data if supported.
The Radio Resource Control (RRC) layer manages control plane exchanges between the UE and the
eNodeB. It uses System Information broadcast by the network to configure the lower layers of the UE and
handles the establishment, maintenance and release of the RRC connection with the eNodeB. The RRC
manages cell search to support cell selection as well as cell measurement reporting and mobility control
for handover between neighbouring cells. The RRC is also responsible for handling and responding to
paging messages from the network. Finally, the RRC manages security functions for key management
and the establishment, configuration, maintenance and release of radio bearers.
The Non-Access Stratum (NAS) layer manages control plane exchanges between the UE and entities
within the core network (EPC). It controls PLMN selection and manages network attachment proce-
dures, exchanging identification and authentication information with the EPC. The NAS is responsible
for establishing and maintaining IP connectivity between the UE and the PDN gateway within the EPC.
The Gateway (GW) layer within srsUE is responsible for the creation and maintenance of the TUN virtual
network kernel interface, simulating a network layer device within the Linux operating system. The GW
layer permits srsUE to run as a user-space application and operates with data plane IP packets.
9.2 Getting Started
To get started with srsUE you will require a PC with a GNU/Linux based operating system and an SDR
RF front-end. An SDR RF front-end is a generic radio device such as the Ettus Research USRP that
connects to your PC and supports transmission and reception of raw radio signals.
If you are using Ubuntu operating system, you can install srsUE from the binary packages provided:
sudo add-apt-repository ppa:srslte/releases

sudo apt-get update
sudo apt-get install srsue
If you are using a different distribution, you can install from source using the guide provided in the
project’s GitHub page.
26 Chapter 9. UE User Manual

After installing the software you can install the configuration files into the default location (~/.config/
srsran_4g), by running:
9.2.1 Running the software
To run srsUE with default parameters, run sudo srsue on the command line. srsUE needs to run with
sudo admin privileges in order to be able to create high-priority threads and to create a TUN device
upon successful network attach. Upon starting, srsUE will attempt to find your RF front-end device and
connect to a local cell.
If srsUE successfully attaches to a local network, it will start a TUN interface tun_srsue. The TUN
interface can be used as any other network interface on your PC, supporting data traffic to and from the
network.
Example console output for a successful network attach:
linux; GNU C++ version 6.3.0 20170618; Boost_106200; UHD_003.009.007-release

Reading configuration file /.config/srsran_4g/ue.conf...
Built in RelWithDebInfo mode using commit 6b2961fce on branch next.
Opening 1 RF devices with 2 RF channels...

Opening USRP with args: type=b200,master_clock_rate=30.72e6
Waiting PHY to initialize ... done!
Attaching UE...
Searching cell in DL EARFCN=2850, f_dl=2630.0 MHz, f_ul=2510.0 MHz
Found Cell: Mode=FDD, PCI=1, PRB=6, Ports=2, CFO=1.3 KHz
Found PLMN: Id=00101, TAC=7
Random Access Transmission: seq=42, ra-rnti=0x2
RRC Connected
Random Access Complete. c-rnti=0x46, ta=0
Network attach successful. IP: 192.168.3.2
With the UE attached to the network, type t in the console to enable the metrics trace. Example metrics
trace:
---------Signal-----------|-----------------DL-----------------|-----------UL-
˓→----------
rat pci rsrp pl cfo | mcs snr iter brate bler ta_us | mcs buff ␣
˓→brate bler
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 1 0 23u | 27 70 1.0 8.5M 0% 0.0 | 28 36k ␣
˓→8.3M 0%
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 1 0 23u | 27 70 1.0 9.2M 0% 0.0 | 28 24k ␣
˓→8.1M 0%
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0% (continues on next page)
9.2. Getting Started 27

(continued from previous page)

nr 500 2 0 23u | 27 69 1.0 4.6M 0% 0.0 | 28 19k ␣
˓→4.2M 0%
9.2.2 Configuration
The UE can be configured through the configuration file: ue.conf. This configuration file provides
parameters relating to operating frequencies, transmit power levels, USIM properties, logging levels and
much more. To run srsUE with the installed configuration file, use sudo srsue ~/.config/srsran/
ue.conf.
All parameters specified in the configuration file can also be overwritten on the command line. For
example, to run the UE with a different EARFCN, use sudo srsue ~/.config/srsran_4g/ue.conf
--rf.dl_earfcn 3350.
By default, srsUE uses a virtual USIM card, with parameters from ue.conf. These parameters are:
• ALGO - the authentication algorithm to use (MILENAGE or XOR)
• IMSI - the unique identifier of the USIM
• K - the secret key shared with the HSS in the EPC
• OP or OPc - the Operator Code (only used with MILENAGE algorithm)
To connect successfully to a network, these parameters will need to match those in the HSS of the EPC.
MILENAGE is the algorithm used in most networks, the XOR algorithm is used primarily by test equip-
ment and test USIM cards. OP is the network-wide operator code and OPc is the USIM-specific encrypted
operator code - both are supported by srsUE.
9.2.3 Hardware Setup
To use srsUE to connect over-the-air to a local network, you will need an RF front-end and suitable
antennas. The default EARFCN is 3400 (2565MHz uplink, 2685MHz downlink). To reduce TX-RX
crosstalk, we recommend orienting TX and RX antennas at a 90 degree angle to each other.
The srsUE can also be used over a cabled connection. The cable configuration and required RF compo-
nents will depend upon your RF front-end. For RF front-ends such as the USRP, connect TX to RX and
ensure at least 30dB of attenuation to avoid damage to your devices.
For more detailed information about cabled connections, see Advanced Usage.
9.2.4 Operating System Setup
The srsUE runs in user-space with standard linux kernels. For best performance, we recommend disabling
CPU frequency scaling. To disable frequency scaling use:
echo "performance" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_

˓→governor

9.2.5 Observing results
To observe srsUE results, use the generated log files and packet captures.
Log files are created by default at /tmp/ue.log. The srsUE configuration file can be used to specify log
levels for each layer of the network stack and to enable hex message output. Supported log levels are
debug, info, warning, error and none.
Log messages take the following format:
Timestamp [Layer ] Level Content
e.g.:
17:52:25.246 [RLC ] Info DRB1 Tx SDU
or with hex message output enabled:

0000: 8b 45 00 00 c7 f3 8b 40 00 01 11 d1 f6 c0 a8 03
0010: 01 ef ff ff fa 92 55 07 6c 00 b3 ee 41 4d 2d 53
PHY-layer log messages have additional details:
Timestamp [Layer] Level [Subframe] Channel: Content
e.g.:
17:52:26.094 [PHY1] Info [05788] PDSCH: l_crb= 1, harq=0, snr=22.1 dB,␣

˓→CW0: tbs=55, mcs=22, rv=0, crc=OK, it=1, dec_time= 12 us
The srsUE application supports packet capture at two levels - MAC layer and NAS layer. MAC layer
captures include both control and data traffic and will be encrypted if configured by the network. NAS
layer captures include control traffic only and will not be encrypted. Packet capture (pcap) files can be
viewed using Wireshark (www.wireshark.org).
See the explanation here on setting up wireshark to decode pcaps.
9.3 Troubleshooting
9.3.1 RF Configuration
The srsUE software application generates and consumes raw radio signals in the form of baseband I/Q
samples. In order to transmit and receive these signals over the air, an RF front end device is needed.
Devices supported by srsRAN 4G include e.g. USRP, BladeRF and LimeSDR.
When using an RF front-end, the dl_earfcn field in ue.conf should be populated. This field provides
the UE with a list (comma separated) of DL EARFCNs. The UE will perform the cell search procedure
using the specified EARFCNs. The UL EARFCN is normally deduced from the DL EARFCN but it
could optionally forced by setting ul_earfcn:
9.3. Troubleshooting 29
[rf]
dl_earfcn = 3400
#ul_earfcn = 21400
...
In some cases, one may use some custom bands which do not mach with any EARFCN. In these cases,
the downlink and uplink frequencies can be forced by setting dl_frequency and ul_frequency respectively
in Hertz:
...
dl_freq = 400e6
ul_freq = 450e6
...
Attention: the eNB and UE DL EARFCNs calculate some security sequences using the DL EARFCN.
If they do not match, the UE may fail to perform some actions.
Most off-the-shelf RF front-ends have relatively low-accuracy clocks, resulting in high frequency offsets
(> 1kHz) from base stations (which use high-accuracy GPS disciplined clock sources). A large frequency
offset deteriorates the UE receiver performance. It is recommended setting the parameter freq_offset (Hz)
in order manually correct large offsets. This parameter applies an offset to the received DL signal and will
mitigate the impairment caused by the carrier frequency offset. Also, the UE will apply a proportional
correction in the UL frequency.
...
freq_offset = -6600
...
The current UE does not support open or closed loop power control. The RF front end gain is controlled
by the user before running the UE. The transmit gain (tx_gain) is specified in dB and maximum transmit
power range varies between brands and models.
At the receiver side, an Automatic Gain Control (AGC) module is activated when the receiver gain
(rx_gain in dB) is not specified. Otherwise, it sets a fixed receive gain. Once again, the range of gain
varies between brands and models.
...
tx_gain = 80
#rx_gain = 40
...
When transmitting, the srsUE application provides a radio signal to the front-end and specifies the time
at which the signal should be transmitted. Typically, an RF front-end will have a small fixed timing offset
caused by delays in the RF chain. This offset is usually in the order of microseconds and can vary between
different devices. To calibrate this offset, it is possible to use the time_adv_nsamples parameter. This
compensates the delay and will ensure that the UE transmits at the correct time.

9.3.2 Network Attach
There are two main reasons for a network attach failing:

• A misconfigured network
• RF issues
Either may stop the UE being able to see the eNB, cause the UE to fail to connect, or cause the UE to
connect but with poor stability.
Misconfigured Network
A misconfigured network may stop the UE being able to see the eNB and/ or connect to the EPC. It
may be helpful to reference the EPC user manual, namely the configuration section to ensure the EPC
has been configured correctly. The UE configuration file should also be checked to ensure the relevant
information is reflected across the two files. See the configuration section of the UE documentation for
notes on this.
An unsuccessful attach can be down to how the UE’s credentials are reflected in the EPC’s config file
and database. See the COTS UE Application Note for info on how to add a UE to the EPC’s database
and ensure the correct network configuration. Note, this is for connecting a COTS UE but may also be
useful for troubleshooting issues when connecting srsUE using an SDR.
Users should also keep an eye on the console outputs of the UE, eNB and EPC to ensure no errors
were given when starting up the network. Errors during network instantiation may lead to elements not
connecting properly.
RF Issues
The RF hardware and configuration should also be checked if a network attach continues to fail.
First check that the hardware is correctly connected and running over USB 3.0, also check the drivers for
your HW are up to date. The latest drivers can be found here.
The antenna choice and position is important to ensure the correct operation of the SDR and overall
network. We recommend using the Vert2450 antenna from Ettus (or similar). The antennae should be
positioned at 90° to each other. You should also ensure the correct ports are used for the antennae. For
example, on the b200 mini the TRX and RX2 ports are used.
It is also important that the correct configuration settings are used as described above.
If possible you should use a spectrum analyser or other such piece of equipment to check the state of the
signal(s) being transmitted by the RF-hardware. If the signal is too weak or malformed then an attach
will not be successful. The gr-fosphor tool is a very useful SDR spectrum analyzer which can be used to
check the properties of transmitted RF signals.
Carrier frequency offset (CFO) may also result in a UE not being able to successfully attach to an eNB.
Check the configuration files so that EARFCNs and carrier frequencies match. You may also need to
calibrate your SDR, as low clock accuracy may result in the CFO being outside of the accepted tolerance.
Multiple open source tools like Kalibrate-RTL can be used to calculate the oscillator offset of your SDR
and help to minimize CFO. An external clock reference or GPSODO can also be used to increase clock
accuracy. Calibrating your SDR may also help with peak throughput and stability.
9.3.3 Peak Throughput
Maximum achievable srsUE peak throughput may be limited for a number of different reasons. These
include limitations in the PC being used, the network configuration, the RF-hardware and the physical
network conditions.
Computational Power
In order to achieve peak throughput, we recommend using a PC with an 8th Gen i7 processor or above,
running Ubuntu 16.04 OS or higher. Machines with lower specs can also run srsRAN 4G successfully
but with lower maximum throughput.
The CPU governor of the PC should be set to performance mode to allow for maximum compute power
and throughput. This can be configured for e.g. Ubuntu using:

˓→governor
Again, you should also ensure your SDR drivers are up to date and that you are running over USB 3.0,
as this will also affect maximum throughput.
If using a laptop, users should keep the PC connected to a power-source at all times while running srsRAN
4G, as this will avoid performance loss due to CPU frequency scaling on the machine.
The computational requirements of the srsUE application are closely tied to the bandwidth of the LTE
or NR carrier being used. For example, maximum throughput using 100-PRB carrier will require a
more powerful CPU than maximum throughput using a 25-PRB carrier. If your machine is not powerful
enough to support srsUE with a given network configuration, you will see Late and/or Overflow packet
reports from the SDR front-end.
RF Hardware
The RF-signal itself can also affect the peak throughput a network can achieve. Ensure the radio being
used is correctly calibrated and that the appropriate gain settings are used. The health of an RF-signal
can be quickly checked using the console trace output by srsUE.
The following is an example of a console trace from srsUE running in 5G NSA mode over the air:
---------Signal-----------|-----------------DL-----------------|-----------UL-
˓→----------
˓→brate bler
lte 1 -33 33 -101m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 0 0 431m | 28 20 2.0 15M 0% 0.0 | 28 91k ␣
˓→ 10M 0%
lte 1 -33 33 -25m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 0 0 -8.6 | 28 20 1.9 16M 0% 0.0 | 28 216k ␣
˓→ 14M 0%
lte 1 -33 33 -191m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
(continues on next page)


nr 500 0 0 -5.7 | 28 21 1.7 16M 0% 0.0 | 28 256k ␣
˓→ 15M 0%
lte 1 -33 33 -21m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 0 0 8.8 | 28 20 1.8 16M 0% 0.0 | 28 226k ␣
˓→ 15M 0%
lte 1 -33 33 50m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 0 0 -13 | 28 20 1.8 16M 0% 0.0 | 28 165k ␣
˓→ 15M 0%
lte 1 -33 33 -71m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 0 0 724m | 28 21 1.9 17M 0% 0.0 | 28 191k ␣
˓→ 15M 0%
lte 1 -33 33 -54m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 0 0 13 | 28 20 1.9 17M 0% 0.0 | 28 120k ␣
˓→ 15M 0%
lte 1 -33 33 -115m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 0 0 -3.6 | 28 21 1.9 17M 0% 0.0 | 28 194k ␣
˓→ 15M 0%
lte 1 -33 33 -43m | 0 34 0.0 0.0 0% 1.6 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 0 0 -2.5 | 28 21 1.9 17M 0% 0.0 | 28 205k ␣
˓→ 15M 0%
The SNR, CFO and BLER can be used to debug the health of a signal connection. See the section on UE
command line reference for information regarding the console trace.
9.4 Advanced Usage
9.4.1 External USIM
This section is only needed if you do not have access to the USIM credentials, or have no control
over the network. Note, most programmable or test USIM cards ship with their credentials.
Using an actual SIM card to authenticate the user against the network is an advanced feature. It requires
a SIM card reader attached to the PC running srsUE that is supported by PCSClite.
Before using a SIM card, please make sure to disable PIN activation using a regular phone.
In order to compile srsUE with support for it, the pcsclite development headers as well as the pcsc daemon
need to be installed and running. On Ubuntu (or other Debian derivates), this can be done with:
sudo apt-get install libpcsclite-dev pcscd pcsc-tools
After this is done, please verify you’ve got a PCSC-compatible reader by running ‘pcsc_scan’.
Now, CMake should pick up the pcsc libraries and build the support code for it. If that is not the case,
try with a clean build folder or remove your exisiting CMakeCache.txt:
9.4. Advanced Usage 33

$ cmake ..
...
-- PCSC LIBRARIES: /usr/lib/x86_64-linux-gnu/libpcsclite.so
-- PCSC INCLUDE DIRS: /usr/include/PCSC
-- Building with PCSC support.
...
$ make
After the build is complete, you can verify the correct operation with the pcsc_usim_test application.
Please verify that the IMSI can be read from the card:
$ ./srsue/test/upper/pcsc_usim_test
..
09:06:36.064073 [USIM] [D] SCARD: MNC length=2
09:06:36.064079 [USIM] [D] MNC length 2
IMSI: 21XXXXXXXXXXXX
09:06:36.064095 [USIM] [D] SCARD: UMTS auth - RAND
0000: bc 4c b0 27 b3 4b 7f 51 21 5e 56 5f 67 3f de 4f
09:06:36.064102 [USIM] [D] SCARD: UMTS auth - AUTN
0000: 5a 17 77 3c 62 57 90 01 cf 47 f7 6d b3 a0 19 46
09:06:36.064107 [USIM] [D] SCARD: scard_transmit: send
0000: 00 11 00 81 22 10 bc ac b1 17 13 4b 6f 51 21 5e
0010: 47 47 6d b3 a0 19 46
09:06:36.119675 [USIM] [D] SCARD: SCardTransmit: recv
0000: 98 62
09:06:36.119707 [USIM] [D] SCARD: UMTS alg response
0000: 98 62
09:06:36.119717 [USIM] [W] SCARD: UMTS auth failed - MAC != XMAC
09:06:36.119725 [USIM] [E] SCARD: Failure during USIM UMTS authentication
09:06:36.119732 [USIM] [D] SCARD: deinitializing smart card interface
If those steps completed successfully we can now start srsUE by either enabling the PCSC USIM in the
config file or by passing the option as an command line argument, e.g., run:
$ ./srsue/src/srsue --usim.mode=pcsc
9.4.2 Channel Emulator
The srsUE application includes an internal channel emulator in the downlink receive path which can
emulate uncorrelated fading channels, propagation delay and Radio-Link failure.
The channel emulator can be enabled and disabled with the parameter channel.dl.enable.
[channel]
dl.enable = true
...
As mentioned above, the channel emulator can simulate fading channels. It supports 4 different models:
• none: single tap with no delay, doppler dispersion can be applied if specified.
• epa: Extended Pedestrian A, described in 3GPP 36.101 Section B.2.1

• eva: Extended Vehicular A model, described in 3GPP 36.101 Section B.2.1

• etu: Extended Typical Urban model, described in 3GPP 36.101 Section B.2.1
The fading emulator has two parameters: enable and model. The parameter model is the channel model
mentioned above, followed by the maximum Doppler dispersion (e.g. eva5). The following example
enables the fading submodule with a EVA fading model and a maximum doppler dispersion of 5 Hz.
...
dl.fading.enable = true
dl.fading.model = eva5
...
The delay simulator generates the delay according to the next formula:
(︁ )︁
2𝜋𝑡
1 + sin delay.period
𝑑(𝑡) = delay.min_us + (delay.max_us − delay.min_us) ·
2
Where delay.min_us and delay.max_us are specified in microseconds while delay.period must be in sec-
onds.
Hence, the maximum simulated speed is given by:
300𝜋
𝑣max = (delay.max_us − delay.min_us) ·
delay.period
The following example enables the delay simulator for having a period of 1h with a minimum delay of
10 microseconds and a maximum delay of 100 microseconds:
...
dl.delay.enable = true
dl.delay.period = 3600
dl.delay.max_us = 100
dl.delay.min_us = 10
...
Finally, the Radio-Link Failure (RLF) simulator has two states:

• on: the UE receives baseband signal, unaffected by the simulator.
• off: the UE does not receive any signal, the simulator substitutes the baseband with zeros.
The time the emulator spends in on is parametrized by rlf.t_on_ms and rlf.t_off_ms for off. Both param-
eters are expected to be in milliseconds.
The following example enables the RLF simulator for having 2 seconds of blackout every 10 seconds of
full baseband signal:
...
dl.rlf.enable = true
dl.rlf.t_on_ms = 10000
dl.rlf.t_off_ms = 2000
...

9.4.3 MIMO
The srsUE supports MIMO operation for transmission modes 1, 2, 3 and 4. The user can select the
number of select antennas in the ue.conf
...
[rf]
...
nof_rx_ant = 2
...
Do you want to attach to a 2 port eNb and you have only one receive channel?
No problem. The UE can attach to 2 port cell and be in TM3 or TM4 without having a second receive
antenna. Nevertheless, it will not take advantage of spatial multiplexing and it will not achieve the max-
imum throughput.
9.4.4 5G NR
srsRAN 4G 21.10 and 22.04 brought prototype 5G NSA and 5G SA capabilities to srsUE respectively.
These capabilities can be enabled via the srsUE configuration file. See the links in the following sections
for information on 5G NSA/ SA and how to enable these features on srsUE.
5G NSA
For information on what 5G NSA is, and how a 5G NSA network can be configured with srsRAN 4G
take a look at the following sections of our documentation:
• 5G NSA overview
• Creating an E2E 5G NSA Network with srsRAN 4G
srsUE is also compatible with 3rd party eNB and gNB applications and equipment. An example of this
can be seen in our guide outlining how to connect srsUE to an Amarisoft Callbox.
5G SA
For information on what 5G SA is, and how a 5G SA network can be configured with srsRAN 4G take a
look at the following sections of our documentation:
• 5G SA overview
• Creating an E2E 5G NA Network with srsRAN 4G

9.5 Configuration Reference
The srsUE example configuration file contains detailed descriptions of all UE configuration parameters.
9.6 Command Line Reference
The srsUE application runs in the console. When running, type t in the console to enable the metrics
trace.
4G LTE console trace:
---------Signal-----------|-----------------DL-----------------|-----------UL-
˓→----------
cc pci rsrp pl cfo | mcs snr iter brate bler ta_us | mcs buff ␣
˓→brate bler
0 1 50 -50 -1.4u | 26 141 1.0 3.2M 0% 0.0 | 21 56 ␣
˓→151k 0%
0 1 50 -50 -899n | 26 140 1.0 3.5M 0% 0.0 | 22 169 ␣
˓→110k 0%
0 1 50 -50 -349n | 26 140 1.0 3.5M 0% 0.0 | 23 112 ␣
˓→100k 0%
0 1 50 -50 -842n | 26 140 1.0 3.5M 0% 0.0 | 23 56 ␣
˓→98k 0%
0 1 50 -50 -760n | 26 140 1.0 3.5M 0% 0.0 | 23 167 ␣
˓→100k 0%
0 1 50 -50 -754n | 26 140 1.0 3.5M 0% 0.0 | 23 114 ␣
˓→100k 0%
0 1 50 -50 106n | 26 140 1.0 3.1M 0% 0.0 | 23 169 ␣
˓→88k 0%
5G NR console trace:
---------Signal-----------|-----------------DL-----------------|-----------UL-
˓→----------
˓→brate bler
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 1 0 23u | 27 70 1.0 8.5M 0% 0.0 | 28 36k ␣
˓→8.3M 0%
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 1 0 23u | 27 70 1.0 9.2M 0% 0.0 | 28 24k ␣
˓→8.1M 0%
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 2 0 23u | 27 69 1.0 4.6M 0% 0.0 | 28 19k ␣
˓→4.2M 0%
Metrics are generated once per second by default. This can be configured using the ex-
pert.metrics_period_secs parameter in ue.conf.
9.5. Configuration Reference 37

Metrics are provided for the received signal (Signal), downlink (DL) and uplink (UL) respectively. The
following metrics are provided:
rat Component carrier, will be either LTE or NR
cc Component carrier (LTE)
pci Physical Cell Identifier
rsrp Reference Signal Receive Power (dBm)
pl Pathloss (dB)
cfo Carrier Frequency Offset (Hz)
mcs Modulation and coding scheme (0-28)
snr Signal-to-Noise Ratio (dB)
iter Average number of turbo decoder iterations
brate Bitrate (bits/sec)
bler Block error rate
ta_us Timing advance (uS)
buff Uplink buffer status - data waiting to be transmitted (bytes)

CHAPTER
TEN
ENODEB USER MANUAL
10.1 Introduction
10.1.1 Overview
srsENB is an LTE eNodeB basestation implemented entirely in software. Running as an application on

a standard Linux-based operating system, srsENB connects to any LTE core network (EPC) and creates
a local LTE cell. To transmit and receive radio signals over the air, srsENB requires SDR hardware such
as the Ettus Research USRP.
• To provide an end-to-end LTE network, use srsENB with srsEPC and srsUE.
srsENB also has prototype 5G NR capabilities.
• To provide an end-to-end 5G NSA network use srsUE, srsENB and srsEPC.
• To provide an end-to-end 5G SA network use srsUE, srsENB and a third party 5G core.
This User Guide provides all the information needed to get up and running with the srsENB application,
extending or modifying the srsENB source code, please see the srsENB Developers Guide.
10.1.2 Features
The srsENB LTE eNodeB includes the following features:

• Prototype 5G NR support for both 5G NSA and SA
• FDD configuration
39
• Transmission mode 1 (single antenna), 2 (transmit diversity), 3 (CCD) and 4 (closed-loop spatial
multiplexing)
• Frequency-based ZF and MMSE equalizer
• MAC layer wireshark packet capture
• ZeroMQ-based fake RF driver for I/Q over IPC/network
• Intra-ENB and Inter-ENB (S1) mobility support
• Proportional-fair and round-robin MAC scheduler with FAPI-like C++ API
• SR support
• Periodic and Aperiodic CQI feedback support
• Standard S1AP and GTP-U interfaces to the Core Network
• 150 Mbps DL in 20 MHz MIMO TM3/TM4 with commercial UEs (195 Mbps with QAM256)
• 75 Mbps DL in SISO configuration with commercial UEs
• 50 Mbps UL in 20 MHz with commercial UEs
• User-plane encryption
10.1.3 eNodeB architecture
The srsENB application includes layers 1, 2 and 3 as shown in the figure above.
At the bottom of the protocol stack, the Physical (PHY) layer carries all information from the MAC over
the air interface. It is responsible for link adaptation and power control.
The Medium Access Control (MAC) layer multiplexes data between one or more logical channels into
Transport Blocks (TBs) which are passed to/from the PHY layer. The MAC is responsible for scheduling
uplink and downlink transmissions for connected UEs via control signalling, retransmission and error
correction (HARQ) and priority handling between logical channels.
The Radio Link Control (RLC) layer can operate in one of three modes: Transparent Mode (TM), Un-
acknowledged Mode (UM) and Acknowledged Mode (AM). The RLC manages multiple logical chan-
nels or bearers for each connected UE. Each bearer operates in one of these three modes. Transparent
Mode bearers simply pass data through the RLC. Unacknowledged Mode bearers perform concatenation,
segmentation and reassembly of data units, reordering and duplication detection. Acknowledged Mode
bearers additionally perform retransmission of missing data units and resegmentation.
The Packet Data Convergence Protocol (PDCP) layer is responsible for ciphering of control and data
plane traffic, integrity protection of control plane traffic, duplicate discarding and in-sequence delivery
of control and data plane traffic to/from the RRC and GTP-U layers respectively. The PDCP layer also
performs header compression (ROHC) of IP data if supported.
40 Chapter 10. eNodeB User Manual

Fig. 1: Basic eNodeB Architecture
The Radio Resource Control (RRC) layer manages control plane exchanges between the eNodeB and
connected UEs. It generates the System Information Blocks (SIBs) broadcast by the eNodeB and handles
the establishment, maintenance and release of RRC connections with the UEs. The RRC also manages
security functions for ciphering and integrity protection between the eNodeB and UEs.
Above the RRC, the S1 Application Protocol (S1-AP) layer provides the control plane connection between
the eNodeB and the core network (EPC). The S1-AP connects to the Mobility Management Entity (MME)
in the core network. Messages from the MME to UEs are forwarded by S1-AP to the RRC layer, where
they are encapsulated in RRC messages and sent down the stack for transmission. Messages from UEs
to the MME are similarly encapsulated by the UE RRC and extracted at the eNodeB RRC before being
passed to the S1-AP and on to the MME.
The GPRS Tunnelling Protocol User Plane (GTP-U) layer within srsENB provides the data plane connec-
tion between the eNodeB and the core network (EPC). The GTP-U layer connects to the Serving Gateway
(S-GW) in the core network. Data plane IP traffic is encapsulated in GTP packets at the GTP-U layer and
these GTP packets are tunneled through the EPC. That IP traffic is extracted from the tunnel at the Packet
Data Network Gateway (P-GW) and passed out into the internet.
10.1. Introduction 41
10.2 Getting Started
To get started with srsENB you will require a PC with a GNU/Linux based operating system and an SDR
RF front-end. An SDR RF front-end is a generic radio device such as the Ettus Research USRP that
connects to your PC and supports transmission and reception of raw radio signals.
If you are using Ubuntu operating system, you can install srsENB from the binary packages provided:

sudo apt-get update
sudo apt-get install srsenb
To run srsENB with default parameters, run sudo srsenb on the command line. srsENB needs to run
with sudo admin privileges in order to be able to create high-priority threads. Upon starting, srsENB
will attempt to find your RF front-end device, attempt to attach to the core network (EPC) and start
broadcasting.
Example console output:
linux; GNU C++ version 6.3.0 20170618; Boost_106200; UHD_003.009.007-release

Built in RelWithDebInfo mode using commit 6b2961fce on branch next.
--- Software Radio Systems LTE eNodeB ---
Reading configuration file /conf/enb.conf...

Setting number of control symbols to 3 for 25 PRB cell.
Opening USRP with args: type=b200,master_clock_rate=30.72e6
Setting frequency: DL=2630.0 Mhz, UL=2510.0 MHz
Setting Sampling frequency 5.76 MHz
Enter t to stop trace.
==== eNodeB started ===
Upon receiving a UE connection:
RACH: tti=3381, preamble=3, offset=1, temp_crnti=0x46

User 0x46 connected
With the eNodeB running and one or more UEs connected, type t in the console to enable the metrics
trace. Example metrics trace:

------DL------------------------------UL----------------------------------
rnti cqi ri mcs brate bler snr phr mcs brate bler bsr
46 14.1 2.0 25.1 28.4M 0.8% 24.8 0.0 23.1 9.60M 2.2% 140k
46 14.8 2.0 26.6 30.7M 0% 24.9 0.0 23.2 9.92M 0% 140k
46 14.7 2.0 26.3 30.1M 0.8% 24.9 0.0 23.1 9.90M 0% 140k
46 14.8 2.0 26.5 30.6M 0% 24.9 0.0 23.1 9.90M 0% 140k
46 15.0 2.0 26.7 30.9M 0% 24.8 0.0 23.1 9.83M 0% 140k
46 14.5 2.0 26.1 30.0M 0% 24.9 0.0 23.1 9.88M 0% 140k
46 14.8 2.0 26.3 30.3M 0% 24.8 0.0 23.1 9.84M 0% 140k
46 14.7 2.0 26.4 30.4M 0% 24.9 0.0 23.1 9.89M 0% 140k
46 14.7 2.0 26.4 30.4M 0% 24.9 0.0 23.2 9.91M 0% 140k
46 14.7 2.0 26.3 30.4M 0% 24.9 0.0 23.1 9.87M 0% 140k
46 14.8 2.0 26.4 30.4M 0% 24.9 0.0 23.1 9.88M 0% 140k
10.2.2 Configuration
The eNodeb can be configured through the configuration file: enb.conf. This configuration file provides
parameters relating to the cell configuration, operating frequencies, transmit power levels, logging levels
and much more. To run srsENB with the installed configuration file, use sudo srsenb ~/.config/
srsran/enb.conf.
All parameters specified in the configuration file can also be overwritten on the command line. For
example, to run the eNodeB with a different EARFCN, use sudo srsenb ~/.config/srsran_4g/
enb.conf --rf.dl_earfcn 3350.
In addition to the top-level configuration file, srsENB uses separate files to configure SIBs (sib.conf),
radio resources (rr.conf) and data bearers (drb.conf). These additional configuration files are listed under
[enb_files] in the top-level enb.conf and defaults are provided for each.
A key eNodeB parameter is enb.mme_addr, which specifies the IP address of the core network MME.
The default configuration assumes that srsEPC is running on the same machine. For more information,
as well instructions for using an EPC on a separate machine, see the EPC user manual.
10.2.3 Hardware Setup
To use srsENB to create an over-the-air local cell, you will need an RF front-end and suitable antennas.
The default EARFCN is 3400 (2565MHz uplink, 2685MHz downlink). To reduce TX-RX crosstalk, we
recommend orienting TX and RX antennas at a 90 degree angle to each other.
The srsENB can also be used over a cabled connection. The cable configuration and required RF com-
ponents will depend upon your RF front-end. For RF front-ends such as the USRP, connect TX to RX
and ensure at least 30dB of attenuation to avoid damage to your devices. For more detailed information
about cabled connections, see Advanced Usage.

10.2.4 Operating System Setup
The srsENB runs in user-space with standard linux kernels. For best performance, we recommend dis-
abling CPU frequency scaling. To disable frequency scaling use:

˓→governor
To observe srsENB results, use the generated log files and packet captures.
Log files are created by default at /tmp/enb.log. The srsENB configuration file can be used to specify
log levels for each layer of the network stack and to enable hex message output. Supported log levels are
debug, info, warning, error and none.
Log messages take the following format:
Timestamp [Layer ] Level Content
e.g.:
or with hex message output enabled:

0000: 8b 45 00 00 c7 f3 8b 40 00 01 11 d1 f6 c0 a8 03
0010: 01 ef ff ff fa 92 55 07 6c 00 b3 ee 41 4d 2d 53
PHY-layer log messages have additional details:
Timestamp [Layer] Level [Subframe] Channel: Content
e.g.:
17:52:26.094 [PHY1] Info [05788] PDSCH: l_crb= 1, harq=0, snr=22.1 dB,␣

˓→CW0: tbs=55, mcs=22, rv=0, crc=OK, it=1, dec_time= 12 us
See the explanation here on setting up wireshark to decdode the pcaps captured by srsENB.
10.3 Troubleshooting
10.3.1 COTS UE Issues
The following are the most common issues when using a COTS UE with srsENB. A full application note
on this can be found here. Reference this for more detail on the following issues.

UE Can’t See The Network
The most likely reasons for a UE not seeing the network are the eNB/EPC configuration, the RF conditions
and the frequency accuracy of the RF frontend being used.
The first thing to check is that the LTE frequency band and EARFCN which you have configured are
supported by the UE which you are using. Most UE devices support a subset of the bands allocated
for LTE. Ensure also that the full bandwidth of the configured LTE carrier is within the frequency band
which you are using.
Some UE devices fail to see networks configured with test PLMN MCC/MNC values. For example,
commonly used MCC/MNC values of 999/70, 901/70 or 001/01 may not work, particularly with iPhone
devices using Intel baseband chipsets. Instead, try setting the MCC of your network to your country
specific value (e.g. 272 for Ireland). A full list of MCC codes can be found here. The MNC value can
then be set to any value that is not currently in use by a Mobile Network Operator in your country.
The RF conditions can be affected by the antenna being used, we recommend the Vert2450 antenna from
Ettus (or similar). Ensure the antennae are placed at a 90° angle to each other to minimize cross-talk. If
possible you should use a spectrum analyser or other such piece of equipment to check the quality of the
signal(s) being transmitted by the RF-hardware. If signals are too weak or malformed then a UE may
not successfully receive them and will not attempt to attach. The gr-fosphor tool is a very useful SDR
spectrum analyzer which can be used to check the properties of transmitted RF signals.
Low carrier frequency accuracy in the RF front-end may also cause a UE to fail to see the network. The
clock accuracy in most SDR front-ends is quite low without the use of an external reference clock input.
It may be possible to use lab equipment or open source tools such as Kalibrate-RTL to estimate the CFO
of your RF front-end and to manually compensate by setting small frequency offsets in the Downlink and
Uplink carrier frequency settings of the eNodeB configuration file.
UE Won’t Attach
If the UE sees the network but cannot successfully attach, you can check the MAC-layer PCAP provided
by srsENB using Wireshark to see at which point in the attach procedure it fails. For more information
about the MAC-layer PCAP and using Wireshark, see here in the documentation.
Can’t Access Internet
If an attached UE cannot access the internet, this may be due to a misconfigured APN in the UE and/ or
eNB. See the app note for information on how to configure this.
Another common reason is misconfigured IP routing at the EPC. If using srsEPC, make sure to follow
the instructions on IP Masquerading in the app note.
10.3.2 Peak Throughput
Maximum achievable srsENB peak throughput may be limited for a number of different reasons. These
include limitations in the PC being used, the network configuration, the RF-hardware and the physical
network conditions.
Computational Power
In order to achieve peak throughput, we recommend using a PC with an 8th Gen i7 processor or above,
running Ubuntu 16.04 OS or highe. Machines with lower specs can also run srsENB sucessfully but with
lower maximum achievable throughput.
The CPU governor of the PC should be set to performance mode to allow for maximum compute power
and throughput. This can be configured for e.g. Ubuntu using:

˓→governor
Again, you should also ensure your SDR drivers are up to date and that you are running over USB 3.0,
as this will also affect maximum throughput.
If using a laptop, users should keep the PC connected to a power-source at all times while running srsENB,
as this will avoid performance loss due to CPU frequency scaling on the machine.
The computational requirements of the srsENB application are closely tied to the bandwidth of the LTE
carrier being used. For example, maximum throughput using 100-PRB carrier will require a more pow-
erful CPU than maximum throughput using a 25-PRB carrier. If your machine is not powerful enough
to support srsENB with a given network configuration, you will see Late and/or Overflow packet reports
from the SDR front-end.
RF Hardware
The RF-signal itself can also affect the peak throughput a network can achieve. Ensure the radio being
used is correctly calibrated and that the appropriate gain settings are used. The health of an RF-signal
can be quickly checked using the console trace output by srsENB.

10.4 Advanced Usage
10.4.1 MIMO
The srsENB supports MIMO transmission modes 2, 3, and 4. You only need to set up the transmission
mode and the number of eNb ports in the enb.conf file:
...
[enb]
...
tm = 3
nof_ports = 2
...
The eNb configures the UE for reporting the Rank Indicator for transmission modes 3 and 4. You can set
the rank indicator periodic report in the file rr.conf field m_ri. This value is multiples of CQI report
period. For example, if the CQI period is 40ms and m_ri is 8, the rank indicator will be reported every
320ms.
10.4.2 5G NR
The srsENB supports prototype 5G features for both NSA and SA modes of operation however, these
features are no longer under active development. Instead we recommend the srsRAN Project, our ORAN-
native 5G CU/DU solution.
5G NSA
5G Non-Standalone (NSA) mode adds 5G support on top of existing 4G infrastructure. This is the ap-
proach used for many commercial 5G network deployments to date, supporting higher data rates on a
secondary 5G carrier while continuing to carry control traffic on the legacy 4G carrier. New 5G NSA-
capable UEs can take advantage of 5G NSA services, but existing 4G devices on the network are not
disrupted.
What is 5G NSA Mode?
To activate the secondary 5G NSA carrier, the UE first connects to the 4G network. If both the UE and
eNB support NSA, and a 5G secondary cell is present then a secondary bearer will be activated on that
5G cell. The NR node is deployed as a Secondary Node (SN) to the LTE Master Node (MN). The 4G
anchor carrier is used for control plane signaling while the secondary 5G carrier is used for high-speed
data plane traffic. This can result in improved data rates compared to a standard LTE connection.
The following signaling procedure is used when initiating a 5G NSA link:
The above signaling procedure for secondary bearer activation occurs after the initial LTE connection
between the UE and eNB is made. The NR connection is then made via the RRC Connection Reconfig-
uration process.

Fig. 2: 5G NSA Mode 3

Fig. 3: 5G NSA Signaling Procedure. Modified from here.

Implementing 5G NSA with srsENB
To enable a 5G NSA connection with srsENB you will need to modify the configuration files for srsENB.
Namely, the rr.conf file, by enabling an NR secondary carrier for the existing eNB. This is covered in
more detail in the relevant app note detailing how to use ZMQ to create an E2E 5G NSA network using
4G.
5G SA
5G SA, or 5G Standalone, is a 5G NR transmission mode that uses 5G cells for both control and data
traffic. It also uses a full 5G Packet Core in place of a 4G EPC. This is considered to be end-to-end 5G,
and removes the need for 4G LTE hardware to manage control traffic as seen in 5G NSA.
What is 5G SA Mode?
As shown in the above figure, 5G SA allows a 5G SA UE to connect to a 5G SA gNB, which is inturn

connected to the 5G Core (namely the AMF and UPF) by the N2 and N3 interfaces. This UE has access
to the full 5G SA network, and full 5G data-plane and control-plane rates. Unlike 5G NSA which only
allows the UE to use a 5G connection for its data-plane traffic.

Implementing 5G SA with srsENB
To enable a 5G SA connection with srsENB you will need to modify the configuration files for srsENB.
Much like for 5G NSA, a NR cell must be added to the rr.conf file. The difference for 5G SA is that all
4G LTE cells must be removed.
This is covered in more detail in the relevant app note detailing how to use ZMQ to create an E2E 5G
SA network using srsRAN 4G and Open5GS.
The srsENB example configuration file contains detailed descriptions of all eNodeB configuration pa-
rameters.
In addition to the top-level configuration file, srsENB uses separate files to configure SIBs sib.conf, radio
resources rr.conf and data bearers rb.conf. These files use libconfig format.
10.6 Command Line Reference
The srsENB application runs in the console. When running, type t in the console to enable the metrics
trace.
4G LTE Output:
-----------------DL----------------|-------------------------
˓→UL-------------------------
rat pci rnti cqi ri mcs brate ok nok (%) | pusch pucch phr mcs ␣
˓→brate ok nok (%) bsr
lte 1 47 15 0 26 1.3M 321 0 0% | 99.9 99.9 30 21 ␣
˓→84k 53 0 0% 0.0
lte 1 47 15 0 26 3.5M 875 0 0% | 99.9 99.9 30 23 ␣
˓→98k 48 0 0% 0.0
lte 1 47 15 0 26 3.5M 876 0 0% | 99.9 99.9 30 22 ␣
˓→111k 56 0 0% 0.0
lte 1 47 15 0 26 3.5M 876 0 0% | 99.9 99.9 30 23 ␣
˓→100k 49 0 0% 0.0
lte 1 47 15 0 26 3.5M 878 0 0% | 99.9 99.9 30 23 ␣
˓→98k 48 0 0% 0.0
lte 1 47 15 0 26 3.5M 874 0 0% | 99.9 99.9 30 22 ␣
˓→110k 56 0 0% 0.0
lte 1 47 15 0 26 3.5M 877 0 0% | 99.9 99.9 30 23 ␣
˓→100k 49 0 0% 0.0
5G NR Output:
-----------------DL----------------|-------------------------UL-----
˓→ --------------------
rat rnti cqi ri mcs brate ok nok (%) | pusch pucch phr mcs brate ␣
˓→ ok nok (%) bsr
lte 46 15 0 0 0 0 0 0% | n/a n/a 0 0 0 ␣
˓→ 0 0 0% 0.0 (continues on next page)


nr 4601 n/a 0 27 6.9M 124 0 0% | n/a n/a 0 0 6.1M ␣
˓→ 95 0 0% 0.0
lte 46 15 0 0 0 0 0 0% | n/a n/a 0 0 0 ␣
˓→ 0 0 0% 0.0
nr 4601 n/a 0 27 4.4M 92 0 0% | n/a n/a 0 0 4.2M ␣
˓→ 76 0 0% 0.0
Metrics are generated once per second by default. This can be configured using the ex-
pert.metrics_period_secs parameter in enb.conf.
Metrics are provided on a per-UE basis for the downlink (DL) and uplink (UL) respectively. The follow-
ing metrics are provided:
rat The RAT being used, either NR or LTE
pci Physical Cell Identifier
rnti Radio Network Temporary Identifier (UE identifier)
cqi Channel Quality Indicator reported by the UE (1-15)
ri Rank Indicator reported by the UE (dB)
mcs Modulation and coding scheme (0-28)
brate Bitrate (bits/sec)
ok Number of packets successfully sent
nok Number of packets dropped
(%) % of packets dropped
pusch PUSCH SNIR (Signal-to-Interference-plus-Noise Ratio)
pucch PUCCH SNIR
phr Power Headroom (dB)
bsr Buffer Status Report - data waiting to be transmitted as reported by the UE (bytes)

CHAPTER
ELEVEN
EPC USER MANUAL
11.1 Introduction
11.1.1 Overview
srsEPC is a lightweight implementation of a complete LTE core network (EPC). The srsEPC application
runs as a single binary but provides the key EPC components of Home Subscriber Service (HSS), Mobil-
ity Management Entity (MME), Service Gateway (S-GW) and Packet Data Network Gateway (P-GW).
Fig. 1: EPC overall architecture
The figure above illustrates the main components of the EPC, along with the main interfaces between
them.
• HSS: The Home Subscriber Service (HSS) is the user database. It stores information such as the
user’s id, key, usage limits, etc. It is responsible for authenticating an authorizing the user’s access
to the network.
• MME: Mobility Managment Entity (MME) is the main control element in the network. It handles
mobility and attach control messages. It is also responsible for paging UEs in idle mode.
53
• S-GW : The S-GW is the main dataplane gateway for the users, as it provides the mobility anchor
for the UEs. It works as an IP router and helps setting up GTP sessions between the eNB and the
P-GW.
• P-GW : The Packet Gateway (P-GW) is the point of contact with external networks. It enforces the
QoS parameters for subscriber sessions.
To provide a complete end-to-end LTE network, use srsEPC with srsENB and srsUE.
This User Guide provides all the information needed to get up and running with the srsEPC application,
extending or modifying the srsEPC source code, please see the srsEPC Developers Guide.
11.1.2 Features
The srsEPC LTE core network includes the implementation of the MME, HSS and SPGW entities. The
features of each of these entities is further described below.
MME Features
The srsEPC MME entity provides support for standard compliant NAS and S1AP protocols to provide
control plane communication between the EPC and the UEs and eNBs.
At the NAS level, this includes:
• Attach procedure, detach procedure, service request procedure
• NAS Security Mode Command, Identity request/response, authentication
• Support for the setup of integrity protection (EIA1 and EIA2) and ciphering (EEA0, EEA1 and
EEA2)
At the S1AP level, this includes:
• S1-MME Setup/Tear-down
• Transport of NAS messages
• Context setup/release procedures
• Paging procedures
HSS Features
The srsEPC HSS entity provides support for configuring UE’s authentication parameters and other pa-
rameters that can be configured on a per-UE basis. The HSS entity includes the following features:
• Simple CSV based database
• XOR and MILENAGE authentication algorithms, specified per UE.
• QCI information
• Dynamic or static IP configuration of UEs
54 Chapter 11. EPC User Manual

SPGW Features
The srsEPC SPGW entity provides support for to user plane communication between the EPC and the
and eNBs, using S1-U and SGi interfaces.
The SPGW supports the following features:
• SGi interface exposed as a virtual network interface (TUN device)
• SGi < > S1-U Forwarding using standard compliant GTP-U protocol
• Support of GTP-C procedures to setup/teardown GTP-U tunnels
• Support for Downlink Data Notification procedures
11.2 Getting Started
To get started with srsEPC you will require a PC with a GNU/Linux based operating system. This can
be a distribution of your preference, such as Ubuntu, Debian, Fedora, etc.
If you are using Ubuntu, you can install from the binary packages provided:

sudo apt-get update
sudo apt-get install srsepc
To run srsEPC with default parameters, run sudo srsepc on the command line. srsEPC needs to run
with sudo admin privileges in order to create a TUN device. This will start the EPC and it will wait for
eNBs and UEs to connect to it.
srsEPC will start a TUN interface srs_spgw_sgi that will allow user-plane packets to reach the UEs.
The EPC can be configured through two configuration files: epc.conf and user_db.csv. The epc.
conf will hold general configuration parameters of the MME, SPGW and the HSS. This includes PLMN
value, integrity/ciphering algorithms, APN, SGi IP address, GTP-U bind address, etc.
The user_db.csv is used to keep UE specific parameters for the HSS. This will include IMSI, authen-
tication algorithms, K, OP or OPc, etc.
In the following subsections, we will cover a few common configuration cases with srsEPC: adding a
new UE to the HSS database, running the eNB and EPC on separate machines, and setting up network
routing to enable UEs to connect to the Internet.

Adding an UE to HSS database
When adding a UE to be able to the user_db.csv database that the HSS will use, you must make sure
that that parameters in that file match the parameters stored in the UE’s USIM card.
Of particular relevance are the IMSI, authentication algorithm, K and OP or OPc (if using the MILE-
NAGE algorithm). The IMSI is the unique identifier of the SIM card, the K the secret key that the HSS
and the UE use to authenticate each other.
The usual authentication algorithm used by SIM cards is MILENAGE, but there are also test SIMs that
use XOR authentication. If you are using the MILENAGE algorithm, you must also know whether you
are using OP or OPc and the corresponding value of this parameter.
Once you know these parameters you can replace then in the user_db.csv which has the following format:
(ue_name),(algo),(imsi),(K),(OP/OPc_type),(OP/OPc_value),(AMF),(SQN),(QCI),
˓→(IP_alloc)
So, if you have a SIM card with the following parameters:

• MILENAGE algorithm
• IMSI = 999700000000001
• K = 00112233445566778899aabbccddeeff
• Using OPc
• OPc = 63bfa50ee6523365ff14c1f45f88737d
You can configure the user_db.csv like this:
ue1,mil,999700000000001,00112233445566778899aabbccddeeff,opc,
˓→63bfa50ee6523365ff14c1f45f88737d,9000,000000000000,9,dynamic
eNBs and srsEPC on separate machines
By default, srsEPC is configured to run with srsENB on the same machine. When running srsEPC
with an eNB on a separate machine, all that is necessary to configure is the mme_bind_addr and the
gtpu_bind_addr.
The MME bind address will specify where the MME will listen for eNB S1AP connections. The GTP-U
bind address should be the same as the MME bind address, unless you want to run the user-plane on a
different sub-net then the S1AP connection.
So if you want to listen to eNB on the interface with IP 10.0.1.10, you can do:
sudo srsepc --mme.mme_bind_addr 10.0.1.10 --spgw.gtpu_bind_addr 10.0.1.10

Connecting UEs to the Internet
To allow UEs to connect to the Internet, it is necessary to perform IP masquerading. Without masquerad-
ing, the Linux kernel will not do packet forwarding from one subnet to another.
To enable this, you can run a convenience script sudo srsepc_if_masq <out_interface>, where
out_interface is the interface that connects the PC to the Internet.
Warning: out_interface is NOT the srs_spgw_sgi interface, but the Ethernet or WiFi ethernet that
connects the PC to the Internet.
By default, log files are stored in /tmp/epc.log. This file can be inspected to troubleshoot any issues
related to srsEPC. Log files can have multiple verbosity levels, which can be configured in the epc.conf
or through the command line. They can also be enabled on a per-layer capacity, which is useful when
troubleshooting a specific layer.
This section describes some of the most common issues with srsEPC and how to troubleshoot them.
11.3.1 UE did not attach
If the UE could not attach it is important to see at what point the attach procedure broke down. The easiest
way to do this is to inspect the NAS messages on the EPC PCAP. See the Observing results section for
instructions on how to obtain a PCAP from srsEPC.
The most common reasons for an attach failure are either an Authentication failure or a Mismatched APN.
Some instructions on addressing these issues can be found on the subsections below.
Authentication failure
The most common case of attach failure is authentication failure. In LTE, not only the network must
authenticate the UE, but the UE must also authenticate the network. For that reason, there is an authen-
tication procedure within the attach procedure.
An simplified illustration of the messages involved in the authentication procedure can be found bellow:
If when the MME compares the RES and XRES and these values do not match, that means that the keys
used to generate those values are different and authentication fails.
For authentication, there are four important parameters that must be configured correctly both at the UE
and the HSS: the IMSI, the authentication algorithm, the UE key and OP/OPc. If you misconfigure your
IMSI, you will see an User not found. IMSI <Your_IMSI> message in the epc.log. If you misconfigure
the other parameters, you will see a “NAS Authentication Failure” message in the epc.pcap, with the
failure code “MAC Code Failure.”
Instructions on how to configure these parameters can be found in the Adding an UE to HSS database
section.

Mismatched APN
Within the attach procedure, the UEs sends an APN setting, either in the “PDN connectivity request”
message or in the “ESM information transfer” message. It is necessary that the configuration of the APN
in the UE and the EPC match. Important parameters to check are the APN name, the PDN type (must be
IPv4), and that no PAP/CHAP authentication is being used.
In srsUE you can configure these parameters in the NAS section of the ue.conf. If using a COTS UE, go
to your APN settings and make sure that the APN configured in the UE matches the one configured in
the EPC.
11.3.2 I cannot access the Internet
If the UE attached successfully and can ping the SPGW, that means that the attach procedure went well
and that the UE was able to obtain the IP.
That means that not being able to access the Internet is a problem not with srsRAN 4G, but with the
network configuration of the system. The most likely issue is that, by default, Linux will not forward
packets from one subnet to another. See the Connecting UEs to the Internet section on how to enable IP
packet forwarding in Linux.
The srsEPC example configuration file contains detailed descriptions of all EPC configuration parame-
ters.
In addition to the top-level configuration file, srsEPC uses a separate file user_db.csv to store user details
in the HSS. This user database file uses CSV format.

CHAPTER
TWELVE
SRSRAN 4G WITH ZMQ VIRTUAL RADIOS
12.1 Introduction
srsRAN 4G is a 4G and 5g software radio suite. The 4G network consists of a core network, an eN-
odeB, and a UE implementation. Usually eNodeB and UE are used with physical radios for over-the-air
transmissions. However, the srsRAN 4G software suite also includes a virtual radio which uses the Ze-
roMQ networking library to transfer radio samples between applications. This approach is very useful
for development, testing, debugging, CI/CD or for teaching and demonstrating.
This application note shows how the srsRAN 4G virtual radio approach can be used to create an end-to-
end network.
12.2 ZeroMQ Installation
First thing is to install ZeroMQ and build srsRAN 4G. On Ubuntu, ZeroMQ development libraries can
be installed with:
sudo apt-get install libzmq3-dev
Alternatively, installing from sources can also be done.

First, one needs to install libzmq:
git clone https://github.com/zeromq/libzmq.git

cd libzmq
./autogen.sh
./configure
make
sudo make install
sudo ldconfig
Second, install czmq:
git clone https://github.com/zeromq/czmq.git

cd czmq
./autogen.sh
./configure
make
sudo make install
sudo ldconfig
60
Finally, you need to compile srsRAN 4G (assuming you have already installed all the required depen-
dencies). Note, if you have already built and installed srsRAN 4G prior to installing ZMQ and other
dependencies you will have to re-run the make command to ensure srsRAN 4G recognizes the addition
of ZMQ:

cd srsRAN_4G
mkdir build
cd build
cmake ../
make
Put extra attention in the cmake console output. Make sure you read the following line:
...
-- FINDING ZEROMQ.
-- Checking for module 'ZeroMQ'
-- No package 'ZeroMQ' found
-- Found libZEROMQ: /usr/local/include, /usr/local/lib/libzmq.so
...
12.3 Running a full end-to-end LTE network on a single computer
Before launching the LTE network components on a single machine we need to make sure that both
UE and EPC are in different network namespaces. This is because both EPC and UE will be sharing
the same network configuration, i.e. routing tables etc. Because the UE receives an IP address from the
EPC’s subnet, the Linux kernel would bypass the TUN interfaces when routing traffic between both ends.
Therefore, we create a separate network namespace (netns) that the UE uses to create its TUN interface
in.
We only require TUN interfaces for the UE and EPC as they are the only IP endpoints in the network and
need to communicate over the TCP/IP stack.
We will run each srsRAN 4G application in a seperate terminal instance. Applications such as ping and
iperf used to generate traffic will be run in separate terminals.
Note, the examples used here can be found in the following directory: `./srsRAN_4G/build/`. With
the UE, eNB and EPC then being called from their associated directory.
12.3.1 Network Namespace Creation
Let’s start with creating a new network namespace called “ue1” for the (first) UE:
sudo ip netns add ue1
To verify the new “ue1” netns exists, run:
sudo ip netns list
12.3. Running a full end-to-end LTE network on a single computer 61

12.3.2 Running the EPC
Now let’s start the EPC. This will create a TUN device in the default network namespace and therefore
needs root permissions.
sudo ./srsepc/src/srsepc
12.3.3 Running the eNodeB
Let’s now launch the eNodeB. We use the default configuration in this example and pass all parame-
ters that need to be tweaked for ZMQ through as command line arguments. If you want to make those
persistent just add them to your local enb.conf. The eNB can be launched without root permissions.
./srsenb/src/srsenb --rf.device_name=zmq --rf.device_args="fail_on_

˓→disconnect=true,tx_port=tcp://*:2000,rx_port=tcp://localhost:2001,id=enb,
˓→base_srate=23.04e6"
12.3.4 Running the UE
Lastly we can launch the UE, again with root permissions to create the TUN device.
sudo ./srsue/src/srsue --rf.device_name=zmq --rf.device_args="tx_port=tcp://

˓→*:2001,rx_port=tcp://localhost:2000,id=ue,base_srate=23.04e6" --gw.netns=ue1
The last command should start the UE and attach it to the core network. The UE will be assigned an IP
address in the configured range (e.g. 172.16.0.2).
12.3.5 Traffic Generation
To exchange traffic in the downlink direction, i.e. from the the EPC, just run ping or iperf as usual on the
command line, e.g.:
ping 172.16.0.2
In order to generate traffic in the uplink direction it is important to run the ping command in the UE’s
network namespace.
sudo ip netns exec ue1 ping 172.16.0.1
12.3.6 Namespace Deletion
After finishing, make sure to remove the netns again.
sudo ip netns delete ue1
62 Chapter 12. srsRAN 4G with ZMQ Virtual Radios

12.4 GNU-Radio Companion Integration
GNU-Radio Companion can be easily integrated with a ZMQ based instance of srsRAN 4G. This can
be used to manipulate, and/ or visualize baseband I/Q data as it is sent between the UE and eNB. It does
this by using the ZMQ-compatible blocks within GRC connected to the TCP ports used to transmit data
between the two network elements. Data going both from the UE to the eNB, and from the eNB to the
UE can be handled via a GRC Broker.
The following figure shows a basic GRC Broker:
The above figure shows how the broker acts as a man-in-the-middle between the UE and the eNB. The
blue boxes and arrows show the direction of data between the network elements. The following ports are
used in this example:
Table 1: Ports Used

Port Direction srsUE srsENB
TX 2001 2101
Rx 2000 2100
Building on this simple example, the I/Q data sent between elements can be processed, manipulated and/
or visualized as needed. This would lead to a GRC architecture similar to what is shown in the following
figure.
The signal processing clouds between elements here represent where any processing of the data would
take place.
When running an E2E Network with a Broker between elements the following steps must be taken when
spinning up the network:
1. Start up the EPC
2. Start the eNB using ZMQ
3. Start the UE using ZMQ
4. Run the GRC Flowgraph associated with the broker.
12.4. GNU-Radio Companion Integration 63

Note, the UE will not connect to the eNB until the broker has been started, as the UL and DL channels
are not directly connected between the UE and eNB. You will also need to restart the GRC Broker each
time the network is restarted.
12.5 Known issues
• For a clean tear down, the UE needs to be terminated first, then the eNB.
• eNB and UE can only run once, after the UE has been detached, the eNB needs to be restarted.
• We currently only support a single eNB and a single UE.
64 Chapter 12. srsRAN 4G with ZMQ Virtual Radios

CHAPTER
THIRTEEN
COTS UE
Warning: Please note, operating a private LTE network on cellular frequency bands may be tightly
regulated in your jurisdiction. Seek the approval of your telecommunications regulator before doing
so.
13.1 Introduction
This application note aims to demonstrate how to set up your own LTE network using srsENB, srsEPC
and a COTS UE. There are two options for network set-up when connecting a COTS UE: The network
can be left as is, and the UE can communicate locally within the network, or the EPC can be connected
to the internet through the P-GW, allowing the UE to access the internet for web-browsing, email etc.
13.1.1 Hardware Required
Creating a network and connecting a COTS UE requires the following:

• PC with a Linux based OS, with srsRAN 4G installed and built
• An RF-frontend capable of both Tx & Rx
• A COTS UE
• USIM/ SIM card (This must be a test card or a programmable card, with known keys)
The following diagram outlines the set-up:
For this implementation the following equipment was used:

• Razer Blade Stealth running Ubuntu 18.04
• B200 mini USRP
• Sony Xperia XA with a Sysmocom USIM
The following photo shows the real world implementation of the equipment for this use case:
65
Note, this is for illustrative purposes, this orientation of USRP and UE may not give the best stability &
throughput.
13.2 Driver & Conf. File Set-Up
Before instantiating the network and connecting the UE you need to first ensure you have the correct
drivers installed and that the configuration files are edited appropriately.
13.2.1 Drivers
Firstly, check that you have the appropriate drivers for your SDR installed. If not they must be downloaded
from the relevant source. If the drivers are already installed ensure they are up to date and are from a
stable release. This step can be skipped if you have the correct drivers and know them to be working.
• RF front-end drivers:
– UHD: https://github.com/EttusResearch/uhd
– SoapySDR: https://github.com/pothosware/SoapySDR
– BladeRF: https://github.com/Nuand/bladeRF
Note: This app note was tested using a b200-mini and UHD v4.0, but we recommend using UHD v3.15
where possible.
When the drivers have been installed/ updated you should connect your hardware and check that every-
thing is working correctly. To do this for a USRP using the UHD drivers run the following command:
uhd_usrp_probe
This should be done anytime you are using a USRP before carrying out any testing or implementation
to check a stable connection to the radio. Note, you should be using a USB 3.0 interface when using an
SDR for this use case.
66 Chapter 13. COTS UE

If you have had to install or update your drivers and everything is working as intended, then you will need
to rebuild srsRAN 4G to ensure it picks up on the new/ updated drivers.
To make a clean build execute the following commands in your terminal:
cd ./srsRAN_4G/build
rm CMakeCache.txt
make clean
cmake ..
make
Your hardware and drivers should now be working correctly and be ready to use for connecting a COTS
UE to srsRAN 4G.
13.2.2 Conf. Files
The base configuration files for srsRAN 4G can be installed by running the following command in the
build folder:
sudo srsran_4g_install_configs.sh <user/service>
You have the option to install the configurations files to the user directory or for all users. For this exam-
ple the configuration files have been installed for all users by running the following command sudo
srsran_4g_install_configs.sh service. The config files can then be found in the following
folder: ~./etc/srsran_4g
You will need to edit the following files before you can run a COTS UE over the network:
• epc.conf
• enb.conf
• user_db.csv
The eNB & EPC config files will need to be edited such that the MCC & MNC values are the same across
both files. The user DB file needs to be updated so that it contains the credentials associated with the
USIM card being used in the UE.
EPC:
The following snippet shows where to change the MCC & MNC values in the EPC config file:
22 | #####################################################################
23 | [mme]
24 | mme_code = 0x1a
25 | mme_group = 0x0001
26 | tac = 0x0007
27 | mcc = 901
28 | mnc = 70
29 | mme_bind_addr = 127.0.1.100
30 | apn = srsapn
31 | dns_addr = 8.8.8.8
32 | encryption_algo = EEA0
33 | integrity_algo = EIA1
13.2. Driver & Conf. File Set-Up 67


34 | paging_timer = 2
35 |
36 | #####################################################################
Line 27 and 28 must be changed, for Sysmocom USIMS these values are 901 & 70. These values will
be dependent on the USIM being used.
eNB:
The above changes must be mirrored in the eNB config. file. The following snippet shows this:
18 | #####################################################################
19 | [enb]
20 | enb_id = 0x19B
21 | mcc = 901
22 | mnc = 70
23 | mme_addr = 127.0.1.100
24 | gtp_bind_addr = 127.0.1.1
25 | s1c_bind_addr = 127.0.1.1
26 | n_prb = 50
27 | #tm = 4
28 | #nof_ports = 2
29 |
30 | #####################################################################
Here, the MCC and MNC values at lines 21 & 22 are changed to the values used in the EPC.
For both of the config files the rest of the values can be left at the default values. They may be changed as
needed, but further customization is not necessary to enable the successful connection of a COTS UE.
User DB:
The following list describes the fields contained in the user_db.csv file, found in the same folder as
the .conf files. As standard, this file will come with two dummy UEs entered into the CSV, these help to
provide an example of how the file should be filled in.
• Name: Any human readable value
• Auth: Authentication algorithm (xor/ mil)
• IMSI: UE’s IMSI value
• Key: UE’s key, hex value
• OP Type: Operator’s code type (OP/ OPc)
• OP: OP/ OPc code, hex value
• AMF: Authentication management field, hex value must be above 8000
• SQN: UE’s Sequence number for freshness of the authentication
• QCI: QoS Class Identifier for the UE’s default bearer
• IP Alloc: IP allocation strategy for the SPGW
The AMF, SQN, QCI and IP Alloc fields can be populated with the following values:
• 9000, 000000000000, 9, dynamic

This will result in a user_db.csv file that should look something like the following:
1 | #
2 | # .csv to store UE's information in HSS
3 | # Kept in the following format: "Name,Auth,IMSI,Key,OP_Type,OP,AMF,SQN,
˓→QCI,IP_alloc"
4 | #
5 | # Name: Human readable name to help distinguish UE's. Ignored by the␣
˓→HSS
6 | # IMSI: UE's IMSI value

7 | # Auth: Authentication algorithm used by the UE. Valid algorithms are␣
˓→XOR
8 | # (xor) and MILENAGE (mil)

9 | # Key: UE's key, where other keys are derived from. Stored in␣
˓→hexadecimal
10| # OP_Type: Operator's code type, either OP or OPc

11| # OP/OPc: Operator Code/Cyphered Operator Code, stored in hexadecimal
12| # AMF: Authentication management field, stored in hexadecimal
13| # SQN: UE's Sequence number for freshness of the authentication
14| # QCI: QoS Class Identifier for the UE's default bearer.
15| # IP_alloc: IP allocation stratagy for the SPGW.
16| # With 'dynamic' the SPGW will automatically allocate IPs
17| # With a valid IPv4 (e.g. '172.16.0.2') the UE will have a␣
˓→statically assigned IP.
18| #
19| # Note: Lines starting by '#' are ignored and will be overwritten
20| ue3,mil,901700000020936,4933f9c5a83e5718c52e54066dc78dcf,opc,
˓→fc632f97bd249ce0d16ba79e6505d300,9000,0000000060f8,9,dynamic
Line 20 shows the entry for the USIM being used in the COTS UE. The values assigned to the AMF,
SQN, QCI & IP Alloc are default values above, as outlined here in the EPC documentation. Ensure there
is no white space between the values in each entry, as this will cause the file to be read incorrectly.
13.2.3 Adding an APN
An APN is needed to allow the UE to access the internet. This is created from the UE and then a change
is made to the EPC config file to reflect this.
From the UE navigate to the Network settings for the SIM being used. From here an APN can be added,
usually under “Access point names”. Create a new APN with the name and APN “test123”, as shown in
the following figure.
13.2. Driver & Conf. File Set-Up 69

The addition of this APN must be reflected in the EPC config file, to do this add the APN to the config.
This is shown in the following snippet:
22 | #####################################################################
23 | [mme]
24 | mme_code = 0x1a
25 | mme_group = 0x0001
26 | tac = 0x0007
27 | mcc = 901
28 | mnc = 70
29 | mme_bind_addr = 127.0.1.100
30 | apn = test123
31 | dns_addr = 8.8.8.8
32 | encryption_algo = EEA0
33 | integrity_algo = EIA1
34 | paging_timer = 2
35 |
36 | #####################################################################
The APN has been added at line 30 above. This must match the APN on the UE to enable a successful
connection.

13.2.4 Run Masquerading Script
To allow UE to connect to the internet via the EPC, the pre-configured masquerading script must be run.
This can be found in srsRAN_4G//srsepc. The masquerading script enables IP forwarding and sets up
Network Address Translation to pass traffic between the srsRAN 4G network and the external network.
The script must be run each time the machine is re-booted, and can be done before or while the network
is running. The UE will not be able to communicate with the interet until this script has been run.
Before running the script it is important to identify the interface being used to connect your PC to the
internet. As the script requires this to be passed in as an argument. This can be done by running the
following command:
route
You will see an output similar to the following:
Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use ␣
˓→ Iface
default 192.168.1.1 0.0.0.0 UG 600 0 0 ␣
˓→ wlp2s0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 ␣
˓→ wlp2s0
192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 ␣
˓→ wlp2s0
The interface (Iface) associated with the default destination is one which must be passed into the masq.
script. In the above output that is the wlp2s0 interface.
The masq. script can now be run from the follow folder: srsRAN_4G/srsEPC:
sudo ./srsepc_if_masq.sh <interface>
If it has executed successfully you will see the following message:
Masquerading Interface <interface>
The configuration files, user DB and UE should now be set up appropriately to allow the COTS UE to
connect to the eNB and Core.
13.3 Connecting a COTS UE to srsRAN 4G
The final step in connecting a COTS UE to srsRAN 4G is to first spin up the network and then connect
to that network from the UE. The following sections will outline how this is achieved.
13.3. Connecting a COTS UE to srsRAN 4G 71

13.3.1 Running srsEPC & srsENB
First navigate to the srsRAN 4G folder. Then initialise the EPC by running:
sudo srsepc
The following output should be displayed on the console:
Built in Release mode using commit c892ae56b on branch master.
--- Software Radio Systems EPC ---
Reading configuration file /etc/srsran_4g/epc.conf...

HSS Initialized.
MME S11 Initialized
MME GTP-C Initialized
MME Initialized. MCC: 0xf901, MNC: 0xff70
SPGW GTP-U Initialized.
SPGW S11 Initialized.
SP-GW Initialized.
The eNB can then be brought online in a separate console by running:
sudo srsenb
The console should display the following:
Reading configuration file /etc/srsran_4g/enb.conf...
Opening 1 channels in RF device=UHD with args=default

[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; UHD_4.0.0.0-666-
˓→g676c3a37
[INFO] [LOGGING] Fastpath logging disabled at runtime.

Opening USRP channels=1, args: type=b200,master_clock_rate=23.04e6
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[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.
Setting frequency: DL=2685.0 Mhz, UL=2565.0 MHz for cc_idx=0

Type <t> to view trace
The EPC console should now print an update if the eNB has successfully connected to the core:

Received S1 Setup Request.

S1 Setup Request - eNB Name: srsenb01, eNB id: 0x19b
S1 Setup Request - MCC:901, MNC:70, PLMN: 651527
S1 Setup Request - TAC 0, B-PLMN 0
S1 Setup Request - Paging DRX v128
Sending S1 Setup Response
The network is now ready for the COTS UE to connect.
13.3.2 Connecting the UE
Connecting the UE to the network is a quick and easy process if the above steps have been completed
successfully.
You can now connect the UE to the network by taking the following steps:
• Open the Settings menu and navigate to the Sim & Network options
• Open this menu and proceed to the sub-menu associated with the USIM being used. It
should look something like the following:

• Under the Network Operators find the network which you have just instantiated using
srsRAN 4G
• Select the network that is a combination of your MMC & MNC values. For this exam-
ple it is the network labelled 90170 4G. The UE should then automatically connect to
the network.
The UE should now be connected to the network. To check for a successful connection use the logs
output to the console.

13.3.3 Confirming Connection
Once the UE has connected to the network, the console outputs of the srsENB and srsEPC can be used
to confirm a successful connection.
EPC Console:
The following output is shown for the EPC after a successful attach. First a confirmation message in the
form of UL NAS: Received Attach Complete will be displayed, secondly the EPS bearers will be given
out and the ID confirmed on the output, and lastly the Sending EMM Information Message output will
be shown. If all of these are displayed in the logs, then an attach is successful. These messages are seen
in the last five lines of the console output in the following console output:

HSS Initialized.
MME S11 Initialized
SP-GW Initialized.
Initial UE message: LIBLTE_MME_MSG_TYPE_ATTACH_REQUEST
Received Initial UE message -- Attach Request
Attach request -- IMSI: 901700000020936
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: 2
PDN Connectivity Request -- ESM Information Transfer requested: true
Downlink NAS: Sending Authentication Request
UL NAS: Authentication Failure
Authentication Failure -- Synchronization Failure
Downlink NAS: Sent Authentication Request
UL NAS: Received Authentication Response
Authentication Response -- IMSI 901700000020936
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: 901700000020936
Sending ESM information request
UL NAS: Received ESM Information Response
ESM Info: APN srsapn
ESM Info: 6 Protocol Configuration Options
Getting subscription information -- QCI 9
Sending Create Session Request.
Creating Session Response -- IMSI: 901700000020936
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 192.168.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 192.168.0.2 to IMSI 901700000020936
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 0x460003; eNB GTP-U Address 127.0.1.1
UL NAS: Received Attach Complete
Unpacked Attached Complete Message. IMSI 901700000020936
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
eNB Console:
The eNB console also display messages to confirm an attach. A RACH message should be seen followed
by a USER 0xX connected message. Where “0xX” is a hex ID representing the UE.
NOTE, you may see some other RACHs and Disconnecting rtni=0xX messages. This may be from other
devices trying to connect to the network, if you have seen a clear connection between the UE and network
these can be ignored.
The following shows an output from the eNB that indicates a successful attach:
Opening 1 channels in RF device=UHD with args=default

[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; UHD_4.0.0.0-666-
˓→g676c3a37




RACH: tti=521, preamble=44, offset=1, temp_crnti=0x46
User 0x46 connected
The UE is now connected to the network. and should now automatically connect to this network each time
it is powered on. You should keep the UE in airplane mode until you want to connect it to the network.
The UE should now also have access to the internet - as if connected to a commercial 4G network.
• If the phone has troubles finding the network or can’t stay connected it might be due to frequency
shifts and drifting of the eNB signal, caused by inaccurate clocks. We therefore always recommend
to use an external 10 MHz reference clock or a GPSDO-disciplined clock for the eNB.
• Some users may experience trouble connecting to the internet, even after running the masquerading
script. Ensure that IP forwarding is enabled, and check your network configuration as this may be
stopping the UE from connecting successfully.
• Users may also have trouble connecting to the network. Firstly check all information in the config-
uration and user DB files are correct. You may also need to adjust the gain parameters in the eNB
config. file - without high enough power (pmax threshold), the UE won’t PRACH.
• Note that some USIM cards may not be compatible in UEs that are “locked” to certain network
operators.
CHAPTER
FOURTEEN
INTRA-ENB & S1 HANDOVER
srsRAN 4G Release 20.10 or later is required to run the following applications
14.1 Introduction
This application note focuses on mobility and handover. Specifically, we show how to configure an
end-to-end network to support user-controlled handover. We address both intra-eNB and S1 handover
using srsRAN 4G with ZeroMQ-based RF emulation and we use the GNURadio Companion as a broker
for controlling cell gains to trigger handover. Creating an E2E network using ZMQ and adding GRC
functionality is demonstrated in our ZMQ App Note.
14.1.1 Hardware & Software Required
Both Intra-eNB and S1 handover have the following hardware and software requirements:
• A PC/ Laptop running a Linux based OS with the latest version of srsRAN 4G installed and built.
• ZMQ installed and working with srsRAN 4G.
• GNU-Radio Companion, which can be downloaded from this link.
• Fully up to date drivers & dependencies.
The following command will ensure the correct dependencies are installed (Ubuntu only):
sudo apt-get install cmake libfftw3-dev libmbedtls-dev libboost-program-

˓→options-dev libconfig++-dev libsctp-dev
For a full guide on installing srsRAN 4G see the installation guide. The ZMQ app note shows how to
correctly install and run ZMQ.
If you have had to install or update your drivers and/or dependencies without having re-built srsRAN 4G
then you will need to do so to ensure srsRAN 4G picks up on the new/ updated drivers.
To make a clean build execute the following commands in your terminal:
cd ./srsRAN_4G/build
rm CMakeCache.txt
make clean
cmake ..
make
78
Your hardware and drivers should now be working correctly and be ready to use correctly with srsRAN
4G.
14.2 Intra-eNB Handover
Intra-eNB Handover describes the handover between cells when a UE moves from one sector to another
sector which are managed by the same eNB. The following steps show how ZMQ and GRC can be used
with srsRAN 4G to demonstrate such a handover.
The following figure shows the overall architecture used:
This set-up will allow intra-frequency intra-enb handover.

Note, ZMQ elements have not been included here so as to simplify the diagram, although they do form
a key aspect of this implementation.
14.2.1 srsRAN 4G Set-Up
To enable the successful execution of intra-eNB handover the configuration files of the eNB, radio re-
sources and the UE must be modified.
eNB:
In the eNB the RF Device and Args should be set so that ZMQ is used and two Tx/Rx TCP port pairings
are created for the UL & DL of each cell.
The following example shows how this is done:
#####################################################################
[rf]
#dl_earfcn = 3350
tx_gain = 80
rx_gain = 40
# Example for ZMQ-based operation with TCP transport for I/Q samples
device_name = zmq
device_args = fail_on_disconnect=true,id=enb,tx_port0=tcp://*:2101,tx_
˓→port1=tcp://*:2201,rx_port0=tcp://localhost:2100,rx_port1=tcp://
˓→localhost:2200,id=enb,base_srate=23.04e6
#####################################################################
14.2. Intra-eNB Handover 79

The following table should make clear how the TCP ports are allocated across the cells:
Table 1: Cell Ports Used

Port Direction cell1 Port # cell2 Port #
Rx 2100 2200
Tx 2101 2201
The use of a clear labelling system for the ports is employed to allow for easier implementation of the
GRC broker. By having the least significant unit of each Rx port be 0 and Tx port be 1 the flowgraph
becomes easier to debug. The second most significant unit is used to indicate which cell the port belongs
to.
Radio Resource (RR):
The rr.conf is where the cells (sectors) are added to the eNB, this is also where the handover flags are
enabled. The following shows an example of the cell added to the existing rr.conf:
{
rf_port = 1;
cell_id = 0x02;
tac = 0x0007;
pci = 6;
root_seq_idx = 268;
dl_earfcn = 3350;
ho_active = true;
// Cells available for handover (in other eNB -- S1 handover)

meas_cell_list =
(
);
// Select measurement report configuration (all reports are combined␣

˓→ with all measurement objects)
meas_report_desc =
(
{
eventA = 3
a3_offset = 6;
hysteresis = 0;
time_to_trigger = 480;
trigger_quant = "RSRP";
max_report_cells = 1;
report_interv = 120;
report_amount = 1;
}
);
meas_quant_desc = {
// averaging filter coefficient
rsrq_config = 4;
rsrp_config = 4;
};
80 Chapter 14. Intra-eNB & S1 Handover


}
Note, the TAC of the cells must match that of the MME, and the EARFCN must be the same across both
cells and the UE. The PCI of each cell with the same EARFCN must be different, such that PCI%3 for
the cells is not equal. It is also important to remember that the ho_active flag must be set to true in the
default cell as well as the cell that has been added.
UE:
For the UE configuration, ZMQ must be set as the default device and the appropriate TCP ports set for
Tx & Rx and the network namespace (netns) set. As well as this, the EARFCN value must be checked
to ensure it is the same as that set for the cells in rr.conf. The following example shows how the ue.conf
file must be modified:
#####################################################################
[rf]
freq_offset = 0
tx_gain = 80
#rx_gain = 40
#srate = 11.52e6
device_name = zmq
device_args = tx_port=tcp://*:2001,rx_port=tcp://localhost:2000,id=ue,base_
˓→srate=23.04e6
#####################################################################
[rat.eutra]
dl_earfcn = 3350
#nof_carriers = 1
#####################################################################
[gw]
netns = ue1
The default USIM configuration can be used, as it is already present in the user_db.csv file used by the
EPC to authenticate the UE. If you want to use a custom USIM set up this will need to be added to
the relevant section in the ue.conf file and reflected in the user_db.csv to ensure the UE is authenticated
correctly.
Table 2: UE Ports Used

Port Direction Port #
Rx 2000
Tx 2001
Again for these ports the least significant unit is used to indicate whether the port is being used for Tx or
Rx.
In short, the EARFCN values must be the same across the eNB, both cells and the UE, handover must

be enabled in the RR config file and ZMQ made the default device for both the eNB and UE.
The full config files can be downloaded here:
• enb.conf
• rr.conf
• ue.conf
14.2.2 GNU-Radio Companion
The GRC file can be downloaded here. Download and/ or save the file as a .grc file. Run with GNU-
Radio Companion when needed.
The GRC Broker will be used to force handover between cells. This will be done by manually controlling
the gain of each cell using variables and a slider. ZMQ REQ Source and REP Sink blocks will be used
to link the flowgraph to the ZMQ instances of srsENB and srsUE. The following figure illustrated how
this is done:
The following table again shows the clear breakdown of how the ports are assigned to each of the network
elements:

Table 3: Ports Used

Port Direction cell1 Port # cell2 Port # UE Port #
Rx 2100 2200 2000
Tx 2101 2201 2001
The gain of cell2 is first set to 0, and cell1 to 1. These are then controlled via sliders and increased in
steps of 0.1 to force handover once a connection has been established. Handover should occur once the
gain of a cell is higher than the other, i.e. when the signal is stronger.
14.2.3 Running the Network
To instantiate the network correctly srsEPC is first run, then srsENB and finally srsUE. Once all three are
running the GRC Broker should be run from GNU-Radio. The UE should then connect to the network,
with the UL & DL passing through the broker. You should have already set up a network namespace for
the UE, as described in the ZMQ App Note.
EPC:
To initiate the EPC, simply run the following command:
sudo srsepc
The EPC should display the following:
Built in Release mode using commit 7e60d8aae on branch next.

HSS Initialized.
MME S11 Initialized
SP-GW Initialized.
eNB:
Once the EPC is running, the eNB can by run using this command:
sudo srsenb
You should then see the following in the console:


Opening 2 channels in RF device=zmq with args=fail_on_disconnect=true,id=enb,

˓→tx_port0=tcp://*:2101,tx_port1=tcp://*:2201,rx_port0=tcp://localhost:2100,
˓→rx_port1=tcp://localhost:2200,id=enb,base_srate=23.04e6
CHx base_srate=23.04e6
CHx id=enb
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://localhost:2100
CH0 tx_port=tcp://*:2101
CH0 fail_on_disconnect=true

The EPC console should then display a confirmation that the eNB cas connected:

S1 Setup Request - MCC:901, MNC:70
S1 Setup Request - TAC 7, B-PLMN 0x9f107
UE:
The UE now needs to be run, this can be done with the following command:
sudo srsue
The UE console should then display this:
Reading configuration file /etc/srsran_4g/ue.conf...
Opening 1 channels in RF device=zmq with args=tx_port=tcp://*:2001,rx_

˓→port=tcp://localhost:2000,id=ue,base_srate=23.04e6
CHx id=ue
Attaching UE...


GRC:
Once all three network elements have been successfully initiated, the Broker can be run. This is done
in the same way as any other GRC Flowgraph. Once successful, a pop up window should display the
interactive slider for controlling the gain of the two cells.
Once the broker has been run, a successful attach should be made and the network should be up and
running fully. To confirm this, check the appropriate messages are displayed in the console.
EPC Attach:
If the attach is successful the EPC should give the following readout:
Initial UE message: LIBLTE_MME_MSG_TYPE_ATTACH_REQUEST

Received Initial UE message -- Attach Request
Attach request -- M-TMSI: 0xd1006989
Attach request -- eNB-UE S1AP Id: 1
Attach request -- Attach type: 1
Attach Request -- UE Network Capabilities EEA: 11110000
Attach Request -- UE Network Capabilities EIA: 01110000
Attach Request -- MS Network Capabilities Present: false
PDN Connectivity Request -- EPS Bearer Identity requested: 0
PDN Connectivity Request -- Procedure Transaction Id: 1
PDN Connectivity Request -- ESM Information Transfer requested: false
UL NAS: Received Identity Response
ID Response -- IMSI: 901700123456789
Downlink NAS: Sent Authentication Request
UL NAS: Received Authentication Response
Authentication Response -- IMSI 901700123456789
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: 901700123456789
Getting subscription information -- QCI 7
Sending Create Session Request.
Creating Session Response -- IMSI: 901700123456789
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 901700123456789
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 901700123456789
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
eNB Attach:
You will see the RACH and connection message on the eNB:
RACH: tti=341, cc=0, preamble=14, offset=0, temp_crnti=0x46

User 0x46 connected
UE Attach:
The UE console will display the following:
Found Cell: Mode=FDD, PCI=1, PRB=50, Ports=1, CFO=-0.2 KHz

RRC Connected
Software Radio Systems LTE (srsRAN 4G) 21/10/2020 12:47:43 TZ:0
The network is now ready for handover to be initiated and tested. To keep the UE from entering idle, you
should send traffic between the UE and the eNB. This can be done with the following command:

14.2.5 Forcing Handover
Handover is simply forced by using the slider to change the gain variables within GRC. Once the handover
is successful a message should be displayed by the UE acknowledging a successful handover.
GRC:
The Following steps outline how handover can be forced with GRC. Aagain, this is done using the sliders
for the gain variables:
1. Set the gain of cell1 to 0.5
2. Slowly increase the gain of cell2 to above 0.5 and on to 1.
3. Wait for handover to be acknowledged.
4. Move the gain of cell1 to 0.
UE Console:
If handover is successful you should see the following read out in the UE console:
Received HO command to target PCell=6, NCC=0

HO successful
Handover can now be repeated as many times as needed by repeating the above steps.
14.3 S1 Handover
Note: srsEPC does not support handover via the S1 interface, as it is designed to be a lightweight core
for network-in-a-box type deployments. To support S1 handover, a third party EPC must be used. We
will use Open5GS for the purposes of this note, however any third-party EPC supporting S1 handover
can be used.
S1 handover takes place over the S1-interface as a UE transitions from the coverage of one eNB to the
next. This differs from intra-enb handover as the UE is leaving the coverage of all sectors in an eNBs
coverage, it is a handover to a new eNB. The following steps outline how this can be demonstrated using
srsUE, srsENB and a third-party open source core. In this case the EPC from Open5GS is used. Other
third party options would also work in this case, so long as they support S1 handover.
The following diagram outlines the network architecture:
14.3. S1 Handover 87
14.3.1 Open5GS EPC
The Open5GS EPC is an open source core network solution which is inter-operable with srsRA 4G. The
software can be installed from packages if using Ubuntu, as shown via the open5GS docs. The EPC, and
the rest of the Open5GS applications, run out of the box and only require minor configuration for use
with srsRAN 4G.
14.3.2 EPC Set-Up
The EPC needs to be configured for use with srsRAN 4G. The only changes required are to the MME
configuration and adding the UE to the user database.
MME Config:
In the file mme.yaml, the TAC must be changed to 7, this is the standard configuration for srsRAN 4G.
You could also leave these settings as they are and configure the srsRAN 4G elements instead.
The following shows the MME configuration used:
mme:
freeDiameter: /etc/freeDiameter/mme.conf
s1ap:
- addr: 127.0.0.2
gtpc:
- addr: 127.0.0.2
gummei:
plmn_id:
mcc: 901
mnc: 70
mme_gid: 2
mme_code: 1
tai:
plmn_id:
mcc: 901
mnc: 70
tac: 7
security:
integrity_order : [ EIA2, EIA1, EIA0 ]
ciphering_order : [ EEA0, EEA1, EEA2 ]
network_name:


full: Open5GS
mme_name: open5gs-mme0
For reference, this configuration can be found from line 204 to 226.
Subscriber List:
Adding subscribers to the network is done via the web-UI provided by open5GS. Their documentation
outlines how this is done here, under the section Register Subscriber Information.
First open the UI, found at http://localhost:3000, and enter the credentials found in the UE configuration
file (ue.conf). The following credentials are used:
Note, the first five digits (PLMN) in the IMSI to 90170, and OPc (Milenage Authentication) is being used.
This differs from the USIM configuration found in ue.conf, the changes made here will later be reflected
in the ue.conf file. The IMSI is edited to reflect the values used for the MCC and MNC. Milenage is used
here to show how the sim credentials can be changed to suit certain use-cases.
14.3.3 srsRAN 4G Set-Up
To ensure srsRAN 4G is correctly configured to implement S1 Handover, changes must be made to the
UE and eNB configurations.
UE:
As previously outlined, the USIM credentials in the configuration file must be modified. The following
sections taken from the config file show the sections that need to be modified:
#####################################################################
[rf]

freq_offset = 0
tx_gain = 80
#rx_gain = 40
#srate = 11.52e6
device_name = zmq
˓→srate=23.04e6
#####################################################################
[rat.eutra]
dl_earfcn = 3350
#nof_carriers = 1
#####################################################################
[gw]
netns = ue1
#####################################################################
[usim]
mode = soft
algo = milenage
opc = 63BFA50EE6523365FF14C1F45F88737D
k = 00112233445566778899aabbccddeeff
imsi = 901700123456789
imei = 353490069873319
#reader =
#pin = 1234
The downlink EARFCN is set to 3350 for this application, this is matched across the rest of the network.
This sets the LTE Band and carrier frequency for the UE and eNB(s), they must match so that a connection
can be successfully established and held. The changes made when adding the UE to the subscriber list
in the EPC are also shown here, the IMSI now leads with the correct PLMN code, and the authentication
algorithm is set to milenage; the opc is uncommented to enable this.
eNB:
For the eNB config the PLMN must be changed, the MME address must also be changed to that of the
MME associated with the Open5GS EPC. The following are the changes made to the enb.conf file:
[enb]
enb_id = 0x19B
mcc = 901
mnc = 70
mme_addr = 127.0.0.2
gtp_bind_addr = 127.0.1.1


s1c_bind_addr = 127.0.1.1
n_prb = 50
#tm = 4
#nof_ports = 2
eNB RR:
The rr.conf file must also be edited to allow for S1 Handover. To do this, two new rr.conf files are created,
named rr1.conf and rr2.conf. As there will be two eNBs, there is an rr.conf associated with each. It is
recommend that the existing rr.conf is simply copied into two new files, and only the cell_list changed
for each of the new filles. This should help to avoid misconfiguration.
rr1.conf:
After the rr.conf has been copied to a new file (in the same location as the existing configuration files),
the cell list must be edited. The following snippet shows this:
cell_list =
(
{
// rf_port = 0;
cell_id = 0x01;
tac = 0x0007;
pci = 1;
root_seq_idx = 204;
dl_earfcn = 3350;
//ul_earfcn = 21400;
ho_active = true;
//meas_gap_period = 0; // 0 (inactive), 40 or 80
//meas_gap_offset_subframe = [6, 12, 18, 24, 30];
// target_pusch_sinr = -1;
// target_pucch_sinr = -1;
// enable_phr_handling = false;
// min_phr_thres = 0;
// allowed_meas_bw = 6;
// t304 = 2000; // in msec. possible values: 50, 100, 150, 200, 500,␣
˓→1000, 2000
// CA cells
scell_list = (
// {cell_id = 0x02; cross_carrier_scheduling = false; scheduling_cell_
˓→id = 0x02; ul_allowed = true}
// Cells available for handover

meas_cell_list =
(
{
eci = 0x19B01;
dl_earfcn = 3350;
pci = 1;

//direct_forward_path_available = false;
//allowed_meas_bw = 6;
//cell_individual_offset = 0;
},
{
eci = 0x19C01;
dl_earfcn = 3350;
pci = 6;
}
);

˓→ with all measurement objects)
meas_report_desc =
(
{
eventA = 3
a3_offset = 6;
hysteresis = 0;
report_amount = 1;
}
);
meas_quant_desc = {
rsrq_config = 4;
rsrp_config = 4;
};
}
// Add here more cells
);
Here the TAC is set to 7, and the DL EARFCN is set to 3350. To ensure S1 Handover is successful the
cell(s) associated with the second eNB must be added to the meas_cell_list. This can be seen here where
a cell with eci = 0x19C01 is included, this is the cell associated with the second eNB. The cell with eci
= 0x19B01 is the cell active on the current eNB. The DL EARFCN is the same across both.
rr2.conf:
Similarly to rr1.conf, a file rr2.conf must be created where the other configuration files are found and the
cell_list updated:
cell_list =
(
{
// rf_port = 0;


cell_id = 0x01;
tac = 0x0007;
pci = 6;
root_seq_idx = 264;
dl_earfcn = 3350;
//ul_earfcn = 21400;
ho_active = true;
//meas_gap_period = 0; // 0 (inactive), 40 or 80
//meas_gap_offset_subframe = [6, 12, 18, 24, 30];
// target_pusch_sinr = -1;
// target_pucch_sinr = -1;
// enable_phr_handling = false;
// min_phr_thres = 0;
// allowed_meas_bw = 6;
// t304 = 2000; // in msec. possible values: 50, 100, 150, 200, 500,␣
˓→1000, 2000
// CA cells
scell_list = (
// {cell_id = 0x02; cross_carrier_scheduling = false; scheduling_cell_
˓→id = 0x02; ul_allowed = true}
// Cells available for handover

meas_cell_list =
(
{
eci = 0x19B01;
dl_earfcn = 3350;
pci = 1;
//direct_forward_path_available = false;
//allowed_meas_bw = 6;
//cell_individual_offset = 0;
},
{
eci = 0x19C01;
dl_earfcn = 3350;
pci = 6;
}
);

˓→with all measurement objects)
meas_report_desc =
(
{
eventA = 3
a3_offset = 6;
hysteresis = 0;

report_amount = 1;
}
);
meas_quant_desc = {
rsrq_config = 4;
rsrp_config = 4;
};
}
// Add here more cells
);
It is possible to enable both intra-eNB and S1 handover at the same time by combining the rr configuration
used for intra-enb HO with those shown above. Although, that will not be covered in this application note.
14.3.4 Using Scripts
To efficiently instantiate and run the network for S1 HO, Bash scripts will be employed. Scripts will
be used to run the two eNBs and the UE. The scripts should be created in the same folder as the other
configuration files to avoid any errors when passing file names and when running them.
eNB 1:
The first eNB will need to have ZMQ set as the RF device, and the ports assigned. As well as this, the
new rr1.conf file must be set as the radio resource configuration to be used:
#!/bin/bash
LOG_ARGS="--log.all_level=debug"
PORT_ARGS="tx_port=tcp://*:2101,rx_port=tcp://localhost:2100"
ZMQ_ARGS="--rf.device_name=zmq --rf.device_args=\"${PORT_ARGS},id=enb,base_
˓→srate=23.04e6\""
OTHER_ARGS="--enb_files.rr_config=rr1.conf"
sudo srsenb enb.conf ${LOG_ARGS} ${ZMQ_ARGS} ${OTHER_ARGS} $@
Note how the logging level is also set here using the script. Every argument in the configuration file can
be changed via the command line when the eNB is instantiated, this shows how it is done when using a
script with the logging as the example.
eNB 2:
For the second eNB we will need to set the ZMQ device, with the correct ports as above. The rr2.conf
file must also be given as the rr configuration file to be used. Additional steps must be taken with this

eNB so as to allow it to be instantiated correctly. The eNB ID must be changed, and the GTP and S1C
bind addresses must be modified. This is done with the following script:
#!/bin/bash
LOG_ARGS="--log.all_level=info"
ZMQ_ARGS="--rf.device_name=zmq --rf.device_args=\"${PORT_ARGS},id=enb,base_
˓→srate=23.04e6\""
OTHER_ARGS="--enb_files.rr_config=rr2.conf --enb.enb_id=0x19C --enb.gtp_bind_

˓→addr=127.0.1.2 --enb.s1c_bind_addr=127.0.1.2"
sudo srsenb enb.conf ${LOG_ARGS} ${ZMQ_ARGS} ${OTHER_ARGS} $@
UE:
The script for the UE will be used to set the ZMQ device and ports, while also being used to set-up the
network namespace used for the UE:
#!/bin/bash
LOG_PARAMS="--log.all_level=debug"
ZMQ_ARGS="--rf.device_name=zmq --rf.device_args=\"${PORT_ARGS},id=ue,base_
˓→srate=23.04e6\" --gw.netns=ue1"
## Create netns for UE

ip netns list | grep "ue1" > /dev/null
if [ $? -eq 1 ]; then
echo creating netspace ue1...
if [ $? -ne 0 ]; then
echo failed to create netns ue1
exit 1
fi
fi
sudo srsue ue.conf ${LOG_PARAMS} ${ZMQ_ARGS} --rat.eutra.dl_earfcn=3350 "$@"
The UE does not require any other parameters to be passed when it is instantiated.
14.3.5 GNU-Radio
The GRC file can be downloaded here. Download and/ or save the file as a .grc file. Run with GNU-
Radio Companion when needed.
The GRC Broker used here is the same as that used for intra-eNB HO. The following figure shows the
flowgraph used:
The following outlines which ports belong to which network element:
Table 4: Ports Used

Port Direction eNB 1 Port # eNB 2 Port # UE Port #
Rx 2100 2200 2000
Tx 2101 2201 2001

14.3.6 Running the Network
To run the network the following steps must be taken:

1. Run the scripts to start each of the network elements
2. Run the GRC Broker to connect the UE to the eNB(s)
The eNB that the UE connects to first is known as the Source eNB, in this case it will be eNB 1. The
Target eNB will be eNB 2, i.e. the eNB that the UE will be transferred to.
To confirm the initial connection has been successful look for the following readouts on the relevant
consoles.
Source eNB:
Reading configuration file enb.conf...
Opening 1 channels in RF device=zmq with args="tx_port=tcp://*:2101,rx_

˓→port=tcp://localhost:2100,id=enb,base_srate=23.04e6"
CHx base_srate=23.04e6"
CHx id=enb

User 0x46 connected
Target eNB:

˓→port=tcp://localhost:2200,id=enb,base_srate=23.04e6"
CHx id=enb


Note, you wont see anything on this eNB console until handover has successfully been made between the
eNBs.
UE:
Reading configuration file ue.conf...

˓→port=tcp://localhost:2000,id=ue,base_srate=23.04e6"
CHx id=ue
Attaching UE...
.
RRC Connected

nTp) 6/11/2020 15:36:1 TZ:0
You should now start to send traffic between the UE and the EPC, this is done via the following command:
This will stop the UE from timing out and keep the connection to the core open.

14.3.8 Forcing Handover
The network is now ready for handover to be forced, this is done in the same way as before using the
GRC Broker:
1. Set the gain of the Source eNB from 1 to 0.5
2. Slowly increase the gain of the Target eNB from 0, to above 0.5, and on to 1.
3. Wait for handover to be acknowledged.
4. Move the gain of the Source eNB to 0.
If HO is successful the following will be seen on the relevant console outputs:
Source eNB:
Starting S1 Handover of rnti=0x46 to cellid=0x19c01.

Encoded varShortMAC: cellId=0x19b01, PCI=1, rnti=0x46 (7 bytes)
Disconnecting rnti=0x46.
Target eNB:
Received S1 HO Request
Received S1 MMEStatusTransfer
Disconnecting rnti=0x47.
User 0x46 connected
UE:
Received HO command to target PCell=6, NCC=2

HO successful
This can be repeated as many times as needed by following the above steps.
14.4.1 Intra-eNB Handover
• If the gains of the cells are changed too abruptly the handover messages will not have enough time
to be exchanged successfully. Gradually moving the sliders between values is best practice when
changing the gain values.
14.4.2 S1 Handover
• Open5GS can also be installed from source, but it is easier to install from packages for this use-case.
• Ensure the PLMN, TAC and EARFCN are correct across all relevant network elements, as this can
cause the connection to fail or stop an attach occuring.

CHAPTER
FIFTEEN
CARRIER AGGREGATION
15.1 Introduction
Before getting hands-on we recommend reading about Carrier Aggregation.

The srsRAN 4G software suite supports 2-carrier aggregation in both srsENB and srsUE. To experiment
with carrier aggregation using srsRAN 4G over-the-air, you will need an RF device that can tune different
frequencies in different channels, for example the USRP X300 series from Ettus Research (NI). We’ve
tested with UHD 3.15 LTS and UHD 4.0.
Alternatively, experiment with carrier aggregation without SDR hardware using our ZeroMQ-based RF
layer emulation. See our ZeroMQ Application Note for more information about RF layer emulation.
15.2 Carrier Aggregation using SDR Hardware
15.2.1 eNodeB Configuration
To configure the eNodeB for carrier aggregation, we must first configure the RF front-end. We must then
configure srsENB for multiple cells and define the primary/secondary relationships between them.
If you’re using a real RF device such as the USRP X300 it’s advisable to use an external clock reference,
either using the 10 MHz/1 PPS input (clock=external) or the GPSDO (clock=gpsdo). For the X300,
especially for newer UHD versions, it’s also required to specific the sample rate upon radio initialization.
For example, if you’re planning to use 10 MHz cells (50 PRB) the sample rate of the radio will be 11.52
Msamples/s, hence a sampling_rate=11.52e6 shall be used. For 20 MHz cells (100 PRB) the sample
rate will be 23.04 Msamples/s, hence sampling_rate=23.04e6 shall be used.
[rf]
device_name = uhd
device_args = type=x300,clock=external,sampling_rate=23.04e6
The second step is to configure srsENB with two cells. For this, one needs to modify rr.conf:
cell_list =
(
{
rf_port = 0;
cell_id = 0x01;
tac = 0x0007;
101

pci = 1;
root_seq_idx = 204;
dl_earfcn = 2850;
// CA cells
scell_list = (
{cell_id = 0x02; cross_carrier_scheduling = false; scheduling_cell_id =␣
˓→0x01; ul_allowed = true}
)
},
{
rf_port = 1;
cell_id = 0x02;
tac = 0x0007;
pci = 4;
root_seq_idx = 268;
dl_earfcn = 3050;
// CA cells
scell_list = (
{cell_id = 0x01; cross_carrier_scheduling = false; scheduling_cell_id =␣
˓→0x02; ul_allowed = true}
)
}
)
With these changes, simply run srsENB as usual.
15.2.2 UE Configuration
In the UE, we must again set the RF configuration and configure the UE capabilities.
For the RF configuration, we need to set the list of EARFCNs according to the cells configured in the
eNodeB and set the number of carriers to 2:
[rf]
dl_earfcn = 2850,3050
nof_carriers = 2
Adding more EARFCNs in the list makes the UE scan these frequencies and the number of carriers makes
the UE use more RF channels.
For the UE capabilities, we need to report at least release 10 and category 7:
[rrc]
ue_category = 7
ue_category_dl = 10
release = 10
With these changes, simply run srsUE as usual.
102 Chapter 15. Carrier Aggregation

15.3 Carrier Aggregation using ZeroMQ RF emulation
To experiment with carrier aggregation using the ZeroMQ RF emulation instead of SDR hardware, we
simply need to configure srsENB and srsUE to use the zmq RF device.
15.3.1 eNodeB Configuration
For srsENB, configure the zmq RF device as follows:
[rf]
device_name = zmq
device_args = fail_on_disconnect=true,id=enb,tx_port0=tcp://*:2000,tx_
˓→port1=tcp://*:2002,rx_port0=tcp://localhost:2001,rx_port1=tcp://
˓→localhost:2003
15.3.2 UE Configuration
For srsUE, configure the zmq RF device as follows:
[rf]
device_name = zmq
device_args = tx_port0=tcp://*:2001,tx_port1=tcp://*:2003,rx_port0=tcp://
˓→localhost:2000,rx_port1=tcp://localhost:2002,id=ue,tx_freq0=2510e6,tx_
˓→freq1=2530e6,rx_freq0=2630e6,rx_freq1=2650e6
Since the ZMQ module is frequency agnostic, it is important that Tx and Rx frequencies are set in ZMQ
config. This makes internal carrier switching possible.
15.4 Known issues
• The eNodeB ignores UE’s band capabilities

• CPU hungry and real time errors for more than 10 MHz
15.3. Carrier Aggregation using ZeroMQ RF emulation 103

CHAPTER
SIXTEEN
C-V2X SIGNALLING
16.1 Introduction
Cellular-V2X (C-V2X), or Cellular Vehicle to Everything, is a 3GPP standard to facilitate automated and
(cooperative) intelligent transportation systems (C-ITS). With C-V2X, vehicles or other devices will be
able to directly communicate with each other without having to go through the cellular infrastructure.
This so called Sidelink communication, has a couple of advantages such as reducing communication
delay when peers are in close vicinity, but may also increase network capacity when communication re-
sources can be reused in different locations. The vehicular extensions have first been introduced in 3GPP
Release 14 but are in fact based on earlier attempts to support direct device to device (D2D) communi-
cation within cellular networks. Although C-V2X is considered a key enabler for future transportation
systems and the key market players, chip manufactures, operators and infrastructure providers, are heav-
ily pushing the technology, only few devices are available. But even if they are officially announced it is
extremely difficult to purchase them for developers or researchers, especially in small quantities.
As of version 20.04, srsRAN 4G includes a complete implementation of the 3GPP Sidelink physical
layer standardized in Release 14 licensed under AGPL v3. This includes all control and data channels
and signals for all transmission modes for both receive and transmit operation. This allows to build
complete and fully compatible C-V2X modems using software radios.
This application note shows how to use the receive-only example provided in srsRAN 4G 20.04 to decode
transmissions from a third-party commercial C-V2X device.
16.2 Requirements
The C-V2X example requires a radio that can process 10 or 20 MHz wide channels. Furthermore, the
device needs to be capable of deriving timing information from GNSS signals, e.g. a GPS signal. We
have tested with a Ettus Research B210 with GPSDO module.
16.3 Anatomy of a C-V2X Signal
Let’s first have a look at a typical signal as it will be transmitted and received by C-V2X devices. The
image below shows a signal captures from a commercial C-V2X modem. This signal has been captured
at 5.92 GHz (channel 184) with a sample rate of 11.52 MHz.
104
Two identical subframes are transmitted one after each other with a gap of three empty subframes. The
second transmission is a actually a retransmission of the first subframe. Retransmissions occur with a
fixed time offset but may occupy different frequency resources. Note that there are no acknowledgments
to provide the sender feedback as to whether the transmission has been received or not.
It’s also noteworthy to say that no dedicated synchronization signals are transmitted as timing is solely
derived from the GNSS signal.
For more information about the Sidelink signal structure have a look at this excellent (albeit not focusing
on C-V2X) white paper from Rohde+Schwarz.
16.4 Decoding C-V2X Signals
The COTS C-V2X device used in this app note by default uses channel 184 centered at 5.92 GHz for
transmission. Also it uses the default channel bandwidth of 10 MHz (or 50 PRB). In preparation for this,
make sure to turn the device on and assure it has good GPS reception. Then, enable the transmit example.
Make sure that you can observe the transmissions using a spectrum analyzer for example.
We have to options to decode the signal, we either capture the signal first and save it into a file and process
the file, or we capture a live and decode it real-time. Let’s start with the second option and decode the
live signal, which is also the default case for pssch_ue.
16.4.1 Capture and Decode in Real-time
For this, we can simply run the pssch_ue example. It uses 5.92 GHz by default, but the frequency can be
changed using the -f parameter. We have to make sure we use the device in GPS-sync mode via parameter
though.
$ ./lib/examples/pssch_ue -a clock=gpsdo
open file to write
Opening RF device...
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.14.1.1-release
Using GPSDO clock
[INFO] [B200] Detected Device: B210
[INFO] [B200] Detecting internal GPSDO....
[INFO] [GPS] Found an internal GPSDO: GPSTCXO , Firmware Rev 0.929a
16.4. Decoding C-V2X Signals 105


Setting USRP time to 1588858638s
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
Setting sampling rate 11.52 MHz
Set RX freq: 5920.00 MHz
Set RX gain: 50.0 dB
Using a SF len of 11520 samples
OOSCI1: riv=4, mcs=5, priority=2, res_rsrv=0, t_gap=3, rtx=1, txformat=0
SCI1: riv=1, mcs=5, priority=2, res_rsrv=0, t_gap=11, rtx=1, txformat=0
^CSIGINT received. Exiting...
num_decoded_sci=4 num_decoded_tb=4
Saving PCAP file to /tmp/pssch.pcap
If you’ve compiled srsRAN 4G with GUI support you should see something like this on your screen.
In this particular examples we can see the QPSK constellation of the control channel (PSCCH) and the
16-QAM constellation of the data channel (PSSCH).
You can stop the decoder with Ctrl+C. Upon exit, the application writes a PCAP file of the decoded signal
to /tmp/pssch.pcap. This file can be inspected with Wireshark. The screenshot below shows Wireshark
decoding the received signal. In this examples just random data is being transmitted but if you’re device
transmits actual ITS traffic, you should be able to see that there too.
106 Chapter 16. C-V2X Signalling

16.4.2 Capture Signal to File and Post-Process
As a second option, we can also capture the signal first, save it into file and then post-process the capture.
For example, the command below writes 200 subframes to /tmp/usrp.dat.
$ ./lib/examples/usrp_capture_sync -l 0 -f 5.92e9 -o /tmp/usrp.dat -a␣

˓→clock=gpsdo -p 50 -m -n 200
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.14.1.1-release
Using GPSDO clock
[INFO] [B200] Detected Device: B210
[INFO] [B200] Detecting internal GPSDO....
[INFO] [GPS] Found an internal GPSDO: GPSTCXO , Firmware Rev 0.929a
16.4. Decoding C-V2X Signals 107


Setting USRP time to 1588858960s
Writing to file 199 subframes...
Ok - wrote 200 subframes
Start of capture at 1588858963+0.010. TTI=108.6
Similar to the above shown example, those subframes can now be decoded with pssch_ue by specifying
the input file name with parameter -i.
$ ./lib/examples/pssch_ue -i /tmp/usrp.dat
...
We can also use the example to decode one of the test vectors:
$./lib/examples/pssch_ue -i ../lib/src/phy/phch/test/signal_sidelink_cmw500_
˓→f5.92e9_s11.52e6_50prb_0offset_1ms.dat
Using a SF len of 11520 samples

num_decoded_sci=1 num_decoded_tb=1
Saving PCAP file to /tmp/pssch.pcap
In this example, we can see that both PSCCH and PSSCH use QPSK as modulation scheme.
108 Chapter 16. C-V2X Signalling

CHAPTER
SEVENTEEN
EMBMS END-TO-END
17.1 Introduction
enhanced Multimedia Broadcast Multicast Services (eMBMS) is the broadcast mode of LTE. Using
eMBMS, an eNodeB can efficiently broadcast the same data to all users attached to the cell. srsRAN
4G supports eMBMS in the end-to-end system including srsUE, srsENB and srsEPC. In addition to
these, a new application is introduced - srsMBMS. srsMBMS is the SRS MBMS gateway, an additional
network component which receives multicast data on a TUN virtual network interface and provides it to
the eMBMS bearer in the eNodeB.
17.2 Setup
To run an end-to-end srsRAN 4G system with eMBMS, some additional configuration of the srsENB
and srsUE applications are required. In the sample configurations provided, it is assumed that srsmbms,
srsepc and srsenb run on the same physical machine.
17.2.1 srsENB configuration
At the eNodeB, additional configuration is required in order to support eMBMS transmission. First,
instead of using the default sib.conf.example, the alternative sib.conf.mbsfn.example should be
used. This version of the sib configuration adds eMBMS parameters to SIB2 and includes SIB 13 which
is specific to eMBMS. These SIB modifications define the following key eMBMS network parameters:
• eMBMS Subframe Allocation
• MCCH Scheduling Period
• MCCH Modulation Order
• Non-eMBMS Subframe Region Length
• eMBMS Area Id
• MCCH Subframe Allocation
• MCCH Repetition Period
In addition to using the eMBMS SIB configuration file, a number of further configurations must be
changed in the enb.conf:
109
[enb_files]
sib_config = sib.conf.mbsfn
[embms]
enable = true
[scheduler]
min_nof_ctrl_symbols = 2
max_nof_ctrl_symbols = 2
[expert]
nof_phy_threads = 2
Set m1u_if_addr to either a localhost address like 127.0.1.201 or to your local IP of the network in
which the srsMBMS binary is available. Once these setting adjustments have been made, the eNodeB
should be ready to run in eMBMS mode.
17.2.2 srsMBMS configuration
The eMBMS configuration only needs to be adjusted in case the eMBMS binary and the eNodeB are
running on different machines. The parameters must be set in the mbms.conf:
[mbms_gw]
m1u_multi_if = 127.0.1.200
Set m1u_if_addr to either a localhost address like 127.0.1.200 or to your local IP of the network in
which the eNodeB is available.
17.2.3 srsUE configuration
For the UE, the presence of an eMBMS transmission will be automatically detected from the SIBs and
the MCCH present in the downlink signal. To receive an active eMBMS service, the following parameter
must be set in ue.conf:
[rrc]
mbms_service_id = 0
Note this service id must match the service id in use by the network.
In addition, we recommend the following settings for best performance with eMBMS:
[phy]
interpolate_subframe_enabled = true
snr_estim_alg = empty
nof_phy_threads = 2
Once these configurations have been made, your UE should be ready to run eMBMS.
110 Chapter 17. eMBMS End-to-End

17.3 Usage
First, run srsMBMS (the MBMS gateway), srsEPC and srsENB on the same machine:
sudo ./srsmbms ~/.config/srsran_4g/mbms.conf
sudo ./srsepc ~/.config/srsran_4g/epc.conf
sudo ./srsenb ~/.config/srsran_4g/enb.conf
The MBMS gateway will create a TUN interface to which all traffic intended for multicast should be
written. It will then forward this traffic to the eNodeB via a seperate GTPU tunnel that is dedicated to
eMBMS traffic.
To test eMBMS with srsMBMS, srsEPC and srsENB, we can use Iperf. At the MBMS gateway, create a
route and start downlink traffic:
sudo route add -net 239.255.1.0 netmask 255.255.255.0 dev sgi_mb
iperf -u -c 239.255.1.1 -b 10M -T 64 -t 60
Next, we can run srsUE on a separate machine to receive the eMBMS data:
sudo ./srsue ~/.config/srsran_4g/ue.conf
Upon running srsUE with an eMBMS enabled eNodeB you should see the following output
at the terminal of the UE:
Searching cell in DL EARFCN=3400, f_dl=2685.0 MHz, f_ul=2565.0 MHz

RRC Connected
MBMS service started. Service id:0, port: 4321
Software Radio Systems LTE (srsRAN 4G)
the MBMS service started. Service id:0, port: 4321 indicates the eMBMS service has successfully
started.
To receive the multicast iperf data, add a route to the UE and start an iperf server:
sudo route add -net 239.255.1.0 netmask 255.255.255.0 dev tun_srsue
iperf -s -u -B 239.255.1.1 -i 1
17.3. Usage 111

CHAPTER
EIGHTEEN
NB-IOT SIGNALLING
18.1 Introduction
Narrowband Internet of Things (NB-IoT) is the 3GPP alternative to other Low Power Wide Area Network
(LPWAN) technologies, such as SigFox and LoRa. Technically it uses similar ideas and reuses some of
the components of LTE. But the bandwidth is significantly reduced to a single PRB (180 kHz) in order to
achieve the low-complexity, low-cost, long battery life requirements. It was first standardized in Release
13.
This application note shows how to spot and decode commercial NB-IoT transmissions in the first part.
The second part shows how to transmit and receive your own NB-IoT downlink signal.
18.2 Requirements
The NB-IoT examples require a radio that can sample at 1.92 Msps. Since the bandwidth of an NB-IoT
carrier is very small, even very cheaply available devices are sufficient to receive and decode the signal.
For example, popular RTL-SDR USB dongles available for around 15-20 Euro are fine for decoding the
signal.
The eNB transmitter example requires a radio with transmitting capabilities. For example, an Ettus
B200mini can be used as the eNB transmitter and an RTL-SDR as UE receiver. In principle, any device
supported by either UHD or SoapySDR should work.
The following application also supports srsGUI for real time visualization of data.
All of the examples used here can be found in the following directory: `./srsRAN/build/lib/
examples`
18.3 Spotting local NB-IoT deployments
Most NB-IoT deployments can be found in the sub-GHz bands. In Europe especially band 20 (Downlink
791-821 MHz). To run a NB-IoT cell search on band 20 one can simply run:
$ ./lib/examples/cell_search_nbiot -b 20
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; UHD_3.13.1.0-3build1
112
Fig. 1: Basic system architecture required to perform a cell search and decode transmissions.

[ 0/299]: EARFCN 6150, 791.00 MHz looking for NPSS.
...
[105/299]: EARFCN 6253, 801.30 MHz looking for NPSS.
NSSS with peak=95.885849, cell-id: 257, partial SFN: 0
Found CELL ID 257.
...
Found 1 cells
Found CELL 801.3 MHz, EARFCN=6253, PHYID=257, NPSS power=31.0 dBm
Bye
In this example, we’ve found a NB-IoT carrier at 801.3 MHz. We can now use the npdsch_ue example
(see next section) to decode the transmission.
It’s also possible to just have a look at the spectrum and check for an NB-IoT carrier there. Most of the
time the carrier is clearly visible, it’s close to a LTE carrier in most cases and usually even a bit stronger
than the LTE signal itself.
The example below, shows a 10 MHz Downlink LTE signal at 806 MHz. One can spot the NB-IoT carrier
on the left hand side (the guardband) of the LTE spectrum.
18.3. Spotting local NB-IoT deployments 113

The table below shows some examples of known NB-IoT deployments in Europe.
Country Operator EARFCN Frequency (MHz)

Spain Vodafone 6253 801.3
Spain Telefonica 6354 811.4
Spain Orange 6153 791.3
Germany Vodafone 6346 810.6
Ireland Vodafone 6354 811.4
18.4 Decoding the NB-IoT transmission
Once we’ve found the downlink frequency of an NB-IoT carrier, we can use the npdsch_ue example
to decode the signal. The application should synchronize on the carrier, detect the cell ID and start to
decode MIB, SIB and SIB2.
$ ./lib/examples/npdsch_ue -f 801.3e6
Soapy has found device #0: driver=rtlsdr, label=Generic RTL2832U OEM ::␣
˓→00000001, manufacturer=Realtek, product=RTL2838UHIDIR, serial=00000001,␣
˓→tuner=Rafael Micro R820T,
Selecting Soapy device: 0

..
*Found n_id_ncell: 257 DetectRatio= 0% PSR=10.57, Power=111.7 dBm
MIB received (CFO: -2,82 kHz) FrameCnt: 0, State: 10
SIB1 received
SIB2 received
CFO: -2,76 kHz, RSRP: 28,0 dBm SNR: 5,0 dB, RSRQ: -11,5 dB, NPDCCH␣
˓→detected: 0, NPDSCH-BLER: 0,00% (0 of total 2), NPDSCH-Rate: 0,10
..
If you’ve compiled srsRAN with GUI support you should see something like this on your screen.
114 Chapter 18. NB-IoT Signalling

You can stop the UE decoder with Ctrl+C. Upon exit, the application writes a PCAP file of the decoded
signal to /tmp/npdsch.pcap. This file can be inspected with Wireshark. The screenshot below shows
Wireshark decoding the received signal.
18.4. Decoding the NB-IoT transmission 115

18.5 Transmit and Receive Downlink Signal
Fig. 2: Basic system architecture required to transmit and recieve downlink signal.
In this part of the tutorial we will show how we can use the provided example applications to transmit
and receive our own NB-IoT signal. Please note that you should only do that in a cabled setup or Faraday
cage in order to comply with emission rules of your country.
Please check that the RF-frontend hardware you are using meets the requirements previously outlined.
To start the eNB example, simply execute the command shown below. This will launch the eNB which
by default picks the first available RF device and transmits the signal. With the -o option the signal can
also be written to file for offline processing.
$ ./lib/examples/npdsch_enodeb -f 868e6
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; UHD_3.13.1.0-3build1
[INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex..
˓→.

[INFO] [B200] Loading FPGA image: /usr/share/uhd/images/usrp_b200mini_fpga.
˓→bin...

Set TX gain: 70.0 dB
Set TX freq: 868.00 MHz
NB-IoT DL DCI:


- Format flag: 1
+ FormatN1 DCI: Downlink
- PDCCH Order: 0
- Scheduling delay: 0 (0 subframes)
- Resource assignment: 0
+ Number of subframes: 1
- Modulation and coding scheme index: 1
- Repetition number: 0
+ Number of repetitions: 1
- New data indicator: 0
- HARQ-ACK resource: 1
- DCI subframe repetition number: 0
DL grant config:
- Number of subframes: 1
- Number of repetitions: 1
- Total number of subframes: 1
- Starting SFN: 0
- Starting SF index: 6
- Modulation type: QPSK
- Transport block size: 24
The eNB example will transmit a standard-compliant downlink signal with MIB-NB and SIB1-NB. It
does not transmit SIB2 though. In all empty downlink subframes not used for MIB or SIB transmissions
it does transmit a NPDSCH signal for test purposes to RNTI 0x1234. One can modify the transport block
size of the test transmission by typing the MCS value (e.g. 20) on the eNB console and hitting Enter.
This test transmission can be decoded with the UE example. For this, we need to run the UE example by
telling it to decode RNTI 0x1234 and skip SIB2 decoding (because it’s not transmitted by eNB):
$ ./lib/examples/npdsch_ue -f 868e6 -r 0x1234 -s

Found Rafael Micro R820T tuner
Soapy has found device #0: driver=rtlsdr, label=Generic RTL2832U OEM ::␣
˓→00000001, manufacturer=Realtek, product=RTL2838UHIDIR, serial=00000001,␣
˓→tuner=Rafael Micro R820T,
Selecting Soapy device: 0

[INFO] Opening Generic RTL2832U OEM :: 00000001...
Found Rafael Micro R820T tuner
Setting up Rx stream with 1 channel(s)
[INFO] Using format CF32.
[R82XX] PLL not locked!
Available device sensors:
Available sensors for Rx channel 0:
State of gain elements for Rx channel 0 (AGC supported):
- TUNER: 0.00 dB
State of gain elements for Tx channel 0 (AGC supported):
- TUNER: 0.00 dB
Rx antenna set to RX
Tx antenna set to RX
18.5. Transmit and Receive Downlink Signal 117


*Found n_id_ncell: 0 DetectRatio= 0% PSR=8.66, Power=86.4 dBm
MIB received (CFO: -1,55 kHz) FrameCnt: 0, State: 10
SIB1 received
CFO: -1,41 kHz, RSRP: 12,0 dBm SNR: 19,0 dB, RSRQ: -3,7 dB, NPDCCH detected:␣
˓→510, NPDSCH-BLER: 0,20% (1 of total 511), NPDSCH-Rate: 10,36 kbit/s
The outlook should look similar except that no SIB2 is decoded. If you’ve compiled with GUI support
you should again see a similar application like above. Please note the constellation diagram is updated a
lot more frequently because now all NPDSCH transmissions to the test user are also received.
18.6 Known issues
• Cell ID detection isn’t reliable.

In some cases the cell ID detection using the NSSS signal isn’t working reliably. In case the
npdsch_ue application clearly synchronizes to the downlink signal (you see a strong correlation
peak in the middle graph in the GUI) but the MIB is never decoded, it is very likely that the cell
ID wasn’t detected correctly. In this case, try to restart the application again and see if the cell ID
can be detected. If the problem still persists, one can also try to set the cell ID manually with the -l
parameter. For this you need to first figure out the correct value, which sometimes can be done by
decoding the default LTE carrier with pdsch_ue and use the same cell ID for the NB-IoT carrier.

CHAPTER
NINETEEN
SRSRAN 4G ON RASPBERRY PI 4
19.1 Introduction
srsRAN 4G is a 4G and 5G software radio suite. The 4G LTE systems includes a core network and an
eNodeB. Most people in the srsRAN 4G community run the software on high performance computers,
however the eNodeB can also be run on the low power Raspberry Pi 4 with a variety of SDRs.
The concept of an ultra low cost, low power and open source SDR LTE femtocell has a lot of people
excited!
Note: While not impossible, running srsUE on a small embedded device is more difficult due to in-
creased processing requirements for synchronisation and blind signal decoding.
119
19.2 Pi4 eNodeB Hardware Requirements
The setup instructions provided below have been tested with a Raspberry Pi 4B /4GB rev 1.2. It has
not been tested with the rev 1.1 board, boards with 2GB of RAM or alternative operating systems. The
Ubuntu image can be downloaded from the official Ubuntu website. You can visually identify your Pi4
hardware revision – this doc from Cytron shows you how.
This setup has been tested with a USRP B210, a LimeSDR-USB and a LimeSDR-Mini.
Note: When using the USRP B210, you can create a 2x2 MIMO cell with srsenb. It is also possible to
run the srsEPC core network on the Pi too.
When using either of the LimeSDRs, you can only create a 1x1 SISO cell with srsenb. The core network
must be run on a separate device.
Due to the power requirements of the SDRs, you must use an external power source. This can be achieved
with a ‘Y’ cable, such as this:
19.3 Software Setup
At the time of writing this appnote, it has been tested with the srsLTE 19.12 release on top of a Ubuntu
Server 20.04 LTS aarch64 image. The following install instructions will apply to this configuration. At
the end of the document, there are some notes on how to install the latest srsRAN 4G release on top of
the latest Ubuntu Server 22.04 LTS aarch64 image.
First thing is to install the SDR drivers and build srsRAN 4G. UHD drivers are required for USRPs,
SoapySDR/LimeSuite are required for the LimeSDRs.
sudo apt update

sudo apt upgrade
sudo apt install cmake
UHD Drivers can be installed with:
120 Chapter 19. srsRAN 4G on Raspberry Pi 4

sudo apt install libuhd-dev libuhd3.15.0 uhd-host

sudo /usr/lib/uhd/utils/uhd_images_downloader.py
## Then test the connection by typing:

sudo uhd_usrp_probe
SoapySDR and LimeSuite can be installed with:
git clone https://github.com/pothosware/SoapySDR.git

cd SoapySDR
git checkout tags/soapy-sdr-0.7.2
mkdir build && cd build
cmake ..
make -j4
sudo make install
sudo ldconfig
sudo apt install libusb-1.0-0-dev

git clone https://github.com/myriadrf/LimeSuite.git
cd LimeSuite
git checkout tags/v20.01.0
mkdir builddir && cd builddir
cmake ../
make -j4
sudo make install
sudo ldconfig
cd ..
cd udev-rules
sudo ./install.sh
## Then test the connection by typing:

LimeUtil --find
LimeUtil --update
SoapySDRUtil --find
Next, srsRAN can be compiled:
sudo apt install libfftw3-dev libmbedtls-dev libboost-program-options-dev␣

˓→libconfig++-dev libsctp-dev

cd srsRAN_4G
git checkout tags/release_19_12
mkdir build && cd build
cmake ../
make -j4
sudo make install
sudo ldconfig
## copy configs to /root

sudo ./srsran_4g_install_configs.sh user
19.3. Software Setup 121

And finally, modify the Pi CPU scaling_governor to ensure it is running in performance mode:
sudo systemctl disable ondemand

sudo apt install linux-tools-raspi
sudo nano /etc/default/cpufrequtils

* insert:
* GOVERNOR="performance"
## reboot
sudo cpupower frequency-info

* should show that the CPU is running in performance mode, at maxiumum clock␣
˓→speed
19.4 Pi4 eNodeB Config
During testing, the following eNodeB config options have been shown to be stable for 24hr+ when running
with the USRP B210, and stable for 2hr+ when running with the LimeSDRs, so should be a good starting
point for you.
The Pi4 eNodeB has been tested with a 3MHz wide cell in LTE B3 (1800MHz band), DL=1878.40
UL=1783.40. This sits inside the UK’s new “1800MHz shared access band”, for which you can legally
obtain a low cost, low power shared access spectrum licence from Ofcom if you are working in the UK.
Changes to default enb.conf for USRP B210:
sudo nano /root/.config/srsran_4g/enb.conf
[enb]
mcc = <yourMCC>
mnc = <yourMNC>
mme_addr = 127.0.1.100 ## or IP for external MME, eg. 192.168.1.10
gtp_bind_addr = 127.0.1.1 ## or local interface IP for external S1-U, eg.␣
˓→192.168.1.3
s1c_bind_addr = 127.0.1.1 ## or local interface IP for external S1-MME, eg.␣

˓→192.168.1.3
n_prb = 15
tm = 2
nof_ports = 2
[rf]
dl_earfcn = 1934
tx_gain = 80 ## this power seems to work best
rx_gain = 40
device_name = UHD
device_args = auto ## does not work with anything other than 'auto'
Changes to default enb.conf for LimeSDR-USB or LimeSDR-Mini:

sudo nano /root/.config/srsran_4g/enb.conf
[enb]
mcc = <yourMCC>
mnc = <yourMNC>
mme_addr = <ipaddr> ## IP for external MME, eg. 192.168.1.10
gtp_bind_addr = <ipaddr> ## local interface IP for external S1-U, eg. 192.
˓→168.1.3
s1c_bind_addr = <ipaddr> ## local interface IP for external S1-MME, eg. 192.

˓→168.1.3
n_prb = 15
tm = 1
nof_ports = 1
[rf]
dl_earfcn = 1934
tx_gain = 60 ## this power seems to work best
rx_gain = 40
device_name = soapy
device_args = auto ## does not work with anything other than 'auto'
Changes to default configs for srsEPC core network:
sudo nano /root/.config/srsran_4g/epc.conf
[mme]
mcc = <yourMCC>
mnc = <yourMNC>
mme_bind_addr = 127.0.1.100 ## or local interface IP for external S1-MME, eg.
˓→ 192.168.1.10
sudo nano /root/.config/srsran_4g/user_db.csv
* add details of your SIM cards
Note: When running srsEPC on an external device (eg. another Pi), you must open incoming firewall
ports to allow the S1-MME and S1-U connections from srsENB.
S1-MME = sctp, port 36412 || S1-U = udp, port 2152
If using iptables,
sudo iptables -A INPUT -p sctp -m sctp --dport 36412 -j ACCEPT

sudo iptables -A INPUT -p udp -m udp --dport 2152 -j ACCEPT
19.4. Pi4 eNodeB Config 123

19.5 Running the Pi4 eNodeB
Launch the software in separate ssh windows or using screen. Remember to use an external power source
for your SDR. The first time you run the srsENB software, you will need to wait a few minutes for
it to finish setting up. After the first time it will start without delay.
Launch Pi4 eNodeB:
sudo srsenb /root/.config/srsran_4g/enb.conf
Note: Between runs when using the LimeSDR-USB, you sometimes need to physically unplug and
reconnect the SDR to power cycle it.
Launch core network (on separate device, or on the Pi4 eNodeB when using USRP B210):
sudo srsepc /root/.config/srsran_4g/epc.conf

sudo /usr/local/bin/srsepc_if_masq.sh eth0
The following htop screenshot shows the resource utilisation when running the software on the Pi 4B
/4GB RAM with x2 UEs attached to the USRP B210 cell. The srsRAN 4G software has been running
here for more than 18 hours without any problems. Only half of the RAM is used, and the CPU cores
are sitting at around 25%. There is a chance, therefore, that this software configuration will work with
the Pi 4B /2GB RAM version, and maybe also on other recent Arm based dev boards. If you can get a
working cell going with alternative hardware, let the srsran-users mailing list know!
19.6 Known issues
• For bandwidths above 6 PRB it is recommended to use srsRAN 4G 19.12 instead of the most recent
release 20.04. We have identified the issue in the PRACH handling mainly affecting low-power
devices. The fix will be included in the upcoming release.

19.7 Running on Ubuntu 22.04 LTS
As of version 22.10, srsRAN 4G can be compiled without modification on Ubuntu 22.04 LTS. However,
the new Ubuntu 22.04 LTS image differs slightly in terms of kernel config options. It also misses the
SCTP kernel module in the default configuration. The latter can be installed with:
sudo apt-get install linux-modules-extra-raspi
The second required change to pass all tests successfully is to increase the RLIMIT_MEMLOCK setting
in /etc/security/limits.conf. A detailed description of the underlying change is provided here
and information about RLIMIT_MEMLOCK can be found here. To lift the limit, add the following line to
/etc/security/limits.conf.
* - memlock unlimited
With those changes srsRAN 4G should compile and shoud pass all tests on a Ubuntu 22.04 LTS aarch64
system.
19.7. Running on Ubuntu 22.04 LTS 125

CHAPTER
TWENTY
HARDWARE OPTIONS
Note: This information is correct as of May 11th 2022
20.1 Introduction
This document aims to provide users with an overview of the suggested PC and SDR hardware combi-
nations that can be used to best explore the functionality of srsRAN. There are 100’s of possible com-
binations of PC, notebook, single board computer and SDR hardware that can demonstrate the uses of
srsRAN. This list aims to provide three possible hardware packages that can help to guide users when
choosing what to buy. These packages are grouped by price, with full set-ups costing ~$400, ~$3,300 and
finally ~$19,200. The three packages proposed here should provide any user with enough information to
create their ideal set-up, which easily meets their needs.
20.2 Choosing Hardware
When choosing these packages we compared each hardware option under the same metrics. With one
set for the computational hardware, and one for the SDR.
20.2.1 Compute Criteria
The following are the main specifications taken into account when selecting the compute platform for
each of these packages:
• Cost - Overall cost of the machine
• Number of cores - This will affect overall performance
• Processor frequency - CPUs running at lower frequencies may struggle under heavy computa-
tional loads
• Cache size - A good indication of speed. More cache memory means certain computations will
be faster.
• Number of threads - More threads will enable a processor to execute processes faster.
This is not an exhaustive list of criteria to look at when selecting a compute platform for SDR experimen-
tation and development. Intended use-case will dictate choice the most here, as well as other external
factors which can be subjective to either the user or overall use conditions.
126
Other useful things to take into account when choosing a compute platform for SDR research and exper-
imentation are:
• Processor Cinebench score - This gives a good indication of a processor’s ability to deal with
high computational load. Find out more here.
• Cooling ability - More cooling ability will ensure CPU performance does not drop off significantly
under heavy load
• Portability - Some use-cases may benefit from a PC that is portable
20.2.2 SDR Criteria
When selecting the SDR options to highlight we took the following into account:
• Cost - Cost per unit of the SDR
• Driver - Which driver the SDR uses (Soapy, UHD, etc)
• Frequency range - The frequency range(s) the SDR operates in
• Bandwidth - Maximum possible bandwidth available
• Clock - Clock rate
• Channels - The number of channels available (SISO, MIMO, etc)
• FPGA - The specifications of the onboard FPGA
Much like when choosing compute hardware, the metrics you may look at when choosing an SDR will
vary depending on use-case and other factors. This list is in no way exhaustive, but provides a good
platform by which to compare options.
20.3 Packages
Each package will contain a recommended SDR and compute hardware bundle. With some appropriate
use-cases for each. A full end-to-end system will require at least two SDRs and two Compute platforms.
As previously mentioned, these packages represent possible combinations, and are by no means a gold
standard of the types of hardware needed for SDR experimentation.
20.3.1 Package 1
SDR PC
Lime SDR mini 2.0 Raspberry Pi 4
Price: TBC Price: $34.87 - $75.90
Driver: SoapySDR # Cores: 4
Frequency Range: 10 Mhz – 3.5 GHz Frequency: 1.5 Ghz
RF Bandwidth: 40 Mhz Cache SIze: 1 MiB
Clock: 30.72 MHz onboard VCTCXO # Threads: 4
# Channels: 1x1
FPGA: Lattice ECP5
20.3. Packages 127

The original LimeSDR mini has been discontinued due to supply chain issues. The LimeSDR mini 2.0
has been announced as it’s replacement. It is not yet available, but will be soon.
This package is inspired by our R. pi4 app note.
Such a set-up would allow users to create a cheap end-to-end network, for under $400 without the need
for a main PC. To run a full end-to-end system using the above equipment a user would need 3 Raspberry
Pi4 units and 2 LimeSDR mini 2.0. A Pi4 is needed for the EPC, eNB and UE, and a front-end is needed
for both the eNB and UE. Due to the small size and portability of the system this setup is ideal for on-the-
fly demos and testing of networks and applications that don’t require high-powered compute hardware or
frontends.
Advantages
• Low cost
• Highly portable
Limitations
• Limited cell bandwidth (currently 5 MHz)

• Limited max bitrate in the UL
20.3.2 Package 2
SDR PC
BladeRF micro 2.0 xA4 HP Omen 16 Intel i5-12500H
Price: $540 Price: $1099.99
Driver: SoapySDR # Cores: 12
Frequency Range: 47 Mhz – 6 Ghz Frequency: 1.8 – 4.5 GHz
RF Bandwidth: 56 Mhz L3 Cache SIze: 18 MB
Clock: 38.4 MHz onboard VCTCXO # Threads: 16
# Channels: 2x2
FPGA: Altera Cyclone V (49 kLE)
This offers a step up from the previous package; in price and performance. The BladeRF micro 2.0 xA4
offers users a 2X2 MIMO configuration, higher max bandwidth, a larger frequency range, and a larger
FPGA. The HP Omen 16 is a gaming notebook, meaning it is built for high performance and high CPU
load for a sustained period of time. The intel i5 12500H is the main draw here, having scored highly in the
Cinebench r23 benchmarking test. This set-up is considerably more expensive and would cost roughly
$3300 for a full set up of 2 PCs and 2 frontends.
128 Chapter 20. Hardware Options

Advantages
• Easily portable, with improved performance

• Suits nearly any use-case
Limitations
• Single cell configuration but up to 20 MHz 2x2 MIMO

• Non-expandable Bandwidth and operating frequencies
20.3.3 Package 3
SDR PC
Ettus x310 Dell Precision 3460 Workstation Intel i7-12700
Price: $8065 Price: $1509.00
Driver: UHD # Cores: 12
Frequency Range: DC - 6GHz (w/ Daughter Frequency: 2.1 - 4.9 GHz
Cards)
RF Bandwidth: 160 MHz (w/ Daughter Cards) Cache SIze: 35 MB
Clock: Configurable # Threads: 20
# Channels: 2x2
FPGA: KINTEX7-410T
This system offers users the most potential in terms of RF-frontend capabilities on PC performance. The
Ettus x310 offers users the largest frequency range, from DC to 6 GHz with the use of the appropriate
daughter cards, a potential bandwidth of 160 MHz (requires the correct daughter cards), a multi-cell con-
figuration and a powerful Kintex7 FPGA. The 3460 workstation offers an intel i7-12700 which is capable
of high intensity computations without a significant drop off in performance over sustained periods of
time. The workstation offers 10 Gbps ethernet connection, which allows users full utilization of the 10
Gbps connection available on the x310. A full E2E system would cost a total of roughly $19200.
Advantages
• Carrier Aggregation
• Multi-cell configuration
Limitations
• Not all PCs will be able to interface via 10Gb ethernet. May have to use adapters.
20.3. Packages 129

20.4 ZMQ
srsRAN has been designed with support for Zero-MQ. This is a “fake RF” driver, which allows users to
set-up a virtual end-to-end network without the use of physical RF-hardware. This is a powerful tool for
experimentations and development for users that do not have access to hardware, or for those who cannot
purchase it.
ZMQ does not require large amounts of computational resources to run, meaning most PCs and notebooks
(including the R. Pi4) can run it without sacrificing performance. ZMQ replaces the radio link between
the eNB and UE, by creating a transmit and receive pipe for exchanging IQ samples TCP or IPC.
Our ZMQ app note clearly demonstrates how srsRAN can be used with ZMQ.
20.5 Choosing a USRP and RF Daughter Card
The Ettus Research Knowledge Base has a range of technical documentation, apps notes and other re-
sources that aid users in getting up to speed with USRP devices and their accessories.
To aid users in choosing a USRP, the KB contains an application note dedicated to exploring the USRP
family and comparing the devices. You can find it here.
Some USRPs will require the addition of an RF-daughterboard, specifically the N and X-series USRPs.
The KB also contains an application note which goes through all of the options and their ideal use-case(s).
You can take a look at this guide for more information.
130 Chapter 20. Hardware Options

CHAPTER
TWENTYONE
5G SA END-TO-END
Tip: The srsENB supports prototype 5G features for both NSA and SA modes of operation however,
these features are no longer under active development. Instead we recommend the srsRAN Project, our
ORAN-native 5G CU/DU solution.
srsRAN 4G 22.04 brings 5G SA support to both srsUE and srsENB. 5G SA features can be enabled via
the configuration files of both srsUE and srsENB. This application note demonstrates how to configure a
5G SA network using srsRAN 4G, a 3rd-party core (Open5GS) and ZeroMQ (ZMQ). Using ZMQ means
there is no need for physical RF-hardware.
21.1 Network & Hardware Overview
131
For this application note, the following hardware and software will be used:
• Dell XPS13 with Ubuntu 20.04.4
• srsRAN 4G 22.04 (or later)
• ZeroMQ
• Open5GS 5G Core
For information on installing ZMQ and using it with srsRAN 4G, see our ZMQ App Note.
21.1.1 Open5GS
Open5GS is a C-language Open Source implementation for 5G Core and EPC. The following links will
provide you with the information needed to download and set-up Open5GS so that it is ready to use with
srsRAN 4G:
• GitHub
• Quickstart Guide
To enable 5G SA features, changes need to be made to both the UE and eNB configuration files. This
section will outline these.
Example configs are attached here:
• ue.conf
• rr.conf
• enb.conf
• amf.yaml
• upf.yaml
Note: 22.04.1 brings changes to the rr.conf, coreset0_idx is now a required field under nr_nell_list.
If you are using an old config file with the latest update, you will need to add this to your config file.
These config files have been modified to remove certain options that are not essential to this use-case.
21.1.3 srsUE
The Following steps need to be taken to modify the srsUE config file to enable 5G SA features:
• Enable ZMQ
• Enable NR features
• Configure USIM credentials & APN
132 Chapter 21. 5G SA End-to-End

ZMQ
To enable ZMQ the following is added to the UE config file:
[rf]
freq_offset = 0
tx_gain = 80
srate = 11.52e6
device_name = zmq
˓→srate=11.52e6
Note: A fixed sample rate must be used for 5G SA
The network namespace must also be configured:
[gw]
netns = ue1
NR Features
Firstly disable the LTE carrier(s):
[rat.eutra]
dl_earfcn = 2850
nof_carriers = 0
Enable the NR band(s) and carrier(s):
[rat.nr]
bands = 3,78
nof_carriers = 1
Lastly, set the release to release-15:
[rrc]
release = 15
USIM Credentials & APN
The following USIM Credentials are used:
[usim]
mode = soft
algo = milenage
opc = 63BFA50EE6523365FF14C1F45F88737D
k = 00112233445566778899aabbccddeeff
21.1. Network & Hardware Overview 133


imsi = 901700123456780
imei = 353490069873319
The main change here is adjusting the IMSI, so that the correct PLMN is used.
The APN is enabled with the following configuration:
[nas]
apn = srsapn
apn_protocol = ipv4
21.1.4 Network Namespace
It is important to create to appropriate network namespace for the UE when using ZMQ.
To create the network namespace, use:
To verify the new “ue1” netns exists, run:
sudo ip netns list
More information on why this is needed can be found in the ZMQ App Note.
21.1.5 srsENB
The Following steps need to be taken to modify the srsENB config and associated config files to enable
5G SA features:
• enb.conf
– Set correct PLMN
– Change MME Address to match Open5GS GTPU and NGAP address’.
– Enable ZMQ
• rr.conf
– Add 5G cell to cell list, and remove LTE cells
enb.conf
PLMN & MME
Setting the PLMN (MCC & MNC) and MME address is done in the following way:
[enb]
enb_id = 0x19B
mcc = 901


mnc = 70
mme_addr = 127.0.0.2
s1c_bind_port = 0
n_prb = 50
The MMC and MNC are set to match the UE and Core. The MME address is configured to allow the
eNB to communicate correctly with the AMF and UPF. If this is not changed srsENB and the Core will
not connect.
ZMQ
ZMQ is enabled with the following changes to the config file:
[rf]
rx_gain = 40
tx_gain = 80
device_name = zmq
device_args = fail_on_disconnect=true,tx_port=tcp://*:2000,rx_port=tcp://
˓→localhost:2001,id=enb,base_srate=11.52e6
rr.conf
The 5G NR cell must be added to the rr.conf when operating in 5G SA mode, the existing LTE cells must
be removed. This can be done by either commenting them out, or deleting them entirely. In the attached
rr.conf file they have been commented out.
The following 5G NR cell configuration is used:
nr_cell_list =
(
{
rf_port = 0;
cell_id = 1;
root_seq_idx = 1;
tac = 7;
pci = 500;
dl_arfcn = 368500;
coreset0_idx = 6;
band = 3;
}
);
21.1. Network & Hardware Overview 135

21.1.6 Core
As highlighted above, the Open5GS Quickstart Guide provides a comprehensive overview of how to
configure Open5GS to run as a 5G Core.
The main modifications needed are:
• Change the TAC in the AMF config to 7
• Check that the NGAP, and GTPU addresses are all correct. This is done in the AMF and UPF
config files.
• It is also a good idea to make sure the PLMN values are consistent across all of the above files and
the UE config file.
The final step is to register the UE to the list of subscribers through the Open5GS WebUI. The values for
each field should match what is in the UE config file, under the [USIM] section.
Note: Make sure to correctly configure the APN, if this is not done correctly the UE will not connect to
the internet.
21.2 Set-up The Network
21.2.1 Core
Once the steps from the Open5GS Quickstart Guide are followed you do not need to do any more to bring
the core online. It will run in the background. Make sure to restart the relevant daemons after making
any changes to the config files.
21.2.2 eNB
First run srsENB. In this example srsENB is being run directly from the build folder, with the config files
also located there:
sudo ./srsenb enb.conf
If srsENB connects to the core successfully the following (or similar) will be displayed on the console:
Opening 1 channels in RF device=zmq with args=fail_on_disconnect=true,tx_

˓→port=tcp://*:2000,rx_port=tcp://localhost:2001,id=enb,base_srate=11.52e6
Supported RF device list: bladeRF zmq file

CHx id=enb
NG connection successful



Setting frequency: DL=1842.5 Mhz, UL=1747.5 MHz for cc_idx=0 nof_prb=52
The NG connection successful message confirms that srsENB has connected to the core.
21.2.3 UE
srsUE can now be run. This is also done directly from within the build folder, with the config file in the
same location:
sudo ./srsue ue.conf
If srsUE connects successfully to the network, the following (or similar) should be displayed on the
console:
Reading configuration file ue.conf...
Opening 1 channels in RF device=zmq with args=tx_port=tcp://*:2001,rx_

˓→port=tcp://localhost:2000,id=ue,base_srate=11.52e6
Supported RF device list: bladeRF zmq file

CHx id=ue
Waiting PHY to initialize... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0xf,␣

˓→tti=171

RRC Connected
RRC NR reconfiguration successful.
PDU Session Establishment successful. IP: 10.45.0.2
It is clear that the connection has been made successfully once the UE has been assigned an IP, this is
seen in PDU Session Establishment successful. IP: 10.45.0.2. The NR connection is then
confirmed with the RRC NR reconfiguration successful. message.
21.2. Set-up The Network 137

21.3 Testing the Network
21.3.1 PING
This is the simplest way to test the network. This will test whether or not the UE and core can successfully
communicate.
Uplink
To test the connection in the uplink direction, use the following:
Downlink
To run traffic in the downlink direction use:
ping 10.45.0.2
The IP for the UE can be taken from the UE console output. This will change each time a UE reconnects
to the network, so it is best practice to always double check the latest IP assigned by reading it from the
console before running the downlink traffic.
21.3.2 iPerf3
In this setup the client will run on the UE side with the server on the network side. UDP traffic will be
generated at 10Mbps for 60 seconds. When running the iPerf client, we use the UE network namespace
and specify the network-side IP address. It is important to start the server first, and then the client.
Network-side
Start the iPerf server:
iperf3 -s -i 1
This will then listen for traffic coming from the UE.
UE-side
With the network and the iPerf server up and running, the client can be run from the UE’s network
namespace with following command:
sudo ip netns exec ue1 iperf3 -c 10.45.0.1 -b 10M -i 1 -t 60
Traffic will now be sent from the UE to the eNB. This will be shown in both the server and client consoles,
and also in the trace for both the UE and the eNB.

Example Output
Example client iPerf output:
Connecting to host 10.45.0.1, port 5201

[ 5] local 10.45.0.3 port 34894 connected to 10.45.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 1.30 MBytes 10.9 Mbits/sec 0 90.5 KBytes
Example server iPerf output:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.45.0.3, port 34892
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.13 MBytes 9.44 Mbits/sec
21.3.3 UE Trace
The following example trace was taken from the srsUE console while running the above iPerf3 test:
---------Signal-----------|-----------------DL-----------------|-----------UL-
˓→----------
˓→brate bler
nr 500 29 0 -16u | 28 n/a 1.1 9.9M 0% 0.0 | 28 48k ␣
˓→9.5M 0%
nr 500 25 0 -18u | 27 70 1.1 13M 0% 0.0 | 28 61k ␣
˓→ 13M 0%
nr 500 28 0 -16u | 27 70 1.1 11M 0% 0.0 | 28 6.7k ␣
˓→ 12M 0%
nr 500 30 0 -14u | 28 70 1.1 9.2M 0% 0.0 | 28 48k ␣
˓→9.6M 0%
nr 500 26 0 -13u | 27 71 1.1 12M 0% 0.0 | 28 30k ␣
˓→ 12M 0%
nr 500 31 0 -17u | 27 n/a 1.1 8.8M 0% 0.0 | 28 43k ␣
˓→8.8M 0%
nr 500 29 0 -14u | 27 70 1.1 9.9M 0% 0.0 | 28 52k ␣
˓→ 10M 0% (continues on next page)
21.3. Testing the Network 139


nr 500 27 0 -7.0u | 27 70 1.1 11M 0% 0.0 | 28 47k ␣
˓→ 11M 0%
nr 500 26 0 -14u | 27 71 1.1 11M 0% 0.0 | 28 57k ␣
˓→ 12M 0%
nr 500 27 0 -16u | 27 70 1.1 11M 0% 0.0 | 28 49k ␣
˓→ 12M 0%
nr 500 28 0 -10u | 27 71 1.1 11M 0% 0.0 | 28 41k ␣
˓→ 11M 0%
21.3.4 eNB/ gNB Trace
The following example trace was taken from the srsENB console at the same time period as the srsUE
trace shown above:
-----------------DL----------------|-------------------------UL----
˓→---------------------
nr 0 4601 15 0 27 11M 296 0 0% | 66.2 99.9 0 28 ␣
˓→10M 268 0 0% 0.0
nr 0 4601 15 0 27 10M 289 0 0% | 65.7 99.9 0 28 ␣
˓→10M 264 0 0% 0.0
nr 0 4601 15 0 28 9.4M 262 0 0% | 65.0 99.9 0 28 ␣
˓→9.5M 242 0 0% 0.0
nr 0 4601 15 0 27 11M 305 0 0% | 66.3 99.9 0 28 ␣
˓→11M 278 0 0% 0.0
nr 0 4601 15 0 27 12M 339 0 0% | 66.4 99.9 0 28 ␣
˓→13M 340 0 0% 0.0
nr 0 4601 15 0 28 9.6M 265 0 0% | 66.0 99.9 0 28 ␣
˓→10M 263 0 0% 0.0
nr 0 4601 15 0 27 11M 310 0 0% | 65.6 99.9 0 28 ␣
˓→11M 278 0 0% 0.0
nr 0 4601 15 0 27 9.7M 272 0 0% | 65.9 99.9 0 28 ␣
˓→9.6M 245 0 0% 0.0
nr 0 4601 15 0 27 9.3M 260 0 0% | 65.8 99.9 0 28 ␣
˓→9.5M 243 0 0% 0.0
nr 0 4601 15 0 27 11M 322 0 0% | 66.1 99.9 0 28 ␣
˓→12M 302 0 0% 0.0
nr 0 4601 15 0 27 9.8M 274 0 0% | 65.8 99.9 0 28 ␣
˓→10M 267 0 0% 0.0

CHAPTER
TWENTYTWO
5G SA COTS UE
Warning: Operating a private 5G SA network on cellular frequency bands may be tightly regulated
in your jurisdiction. Seek the approval of your telecommunications regulator before doing so.
srsRAN 4G 22.04 brings 5G SA support to both srsUE and srsENB. 5G SA features can be enabled via
the configuration files of both srsUE and srsENB.
This application note demonstrates how to configure and connect a 5G capable COTS UE to a 5G SA
network using srsRAN 4G and a 3rd-party core (Open5GS in this example).
Setting up a 5G SA network and connecting a 5G COTS UE requires the following:

• PC with a Linux based OS, with srsRAN 4G 22.04 (or later) installed and built
• Third Party 5G Core
• A compatible SDR (USRP, LimeSDR, BladeRF, etc.), ideally connected to a 10 MHz reference
clock or GPSDO
• A 5G SA-capable UE
For this implementation the following equipment is used:
• Dell XPS13 with Ubuntu 20.04 LTS
• srsRAN 4G 22.04 & Open5GS
• B200-mini USRP running over USB3
• OnePlus Nord 5G with a Sysmocom USIM
141
22.1.1 UE Considerations
One of the current limitations of srsRAN 4G is that only 15 kHz sub-carrier spacing is supported. As a
result, only devices that are capable of operating in bands that support FDD (e.g. band 3) can be used.
Many commercial COTS UEs require 30 kHz SCS for TDD bands, which we do not currently support.
Besides the restrictions originating from the baseband hardware there are a few other pitfalls that may or
may not allow a phone to connect to a 5G network:
• On some handsets, when using a test USIM, you may need to activate 5G NR using *#*#4636#*#*.
• If your handset supports “Smart 5G”, disable this option as it may force the handset to 4G and
activate roaming.
• Many 5G handsets may contain a carrier policy file that may limit 5G capabilities of the phone
based on the PLMN of the USIM (first 6 digits of IMSI). Carrier policy files typically don’t include
test network PLMNs, so setting a test PLMN may result in 5G being disabled. If possible, using a
shielded box and configuring the network with a commercial carrier PLMN may avoid policy file
issues.
142 Chapter 22. 5G SA COTS UE

22.2 Dependencies
22.2.1 RF Driver
To check that your RF driver has been picked up when running cmake .. during the build process, you
can run:
grep <driver> srsRAN_4G/build/CMakeCache.txt
If you are using UHD as your driver, you should see the following output if srsRAN 4G has successfully
detected it when cmake .. was run:
$ grep UHD -m 4 CMakeCache.txt
//Enable UHD
ENABLE_UHD:BOOL=ON
UHD_INCLUDE_DIRS:PATH=/usr/local/include
UHD_LIBRARIES:FILEPATH=/usr/local/lib/libuhd.so
We’ve only tested SA mode with Ettus Research devices using UHD. For this appnote we use the USRP
B200-mini with UHD version v4.2.
can run:
//Enable UHD
ENABLE_UHD:BOOL=ON
22.2.2 srsRAN 4G
If you have not already done so, install the latest version of srsRAN 4G and all of its dependencies. This
is outlined in the installation guide.
Note: If you install or update your driver after installing srsRAN 4G, you will have to re-build srsRAN
4G.
22.2. Dependencies 143

22.2.3 3rd Party Core - Open5GS
For this example we are using Open5GS as the 5G Core.

Open5GS is a C-language Open Source implementation for 5G Core and EPC. The following links will
provide you with the information needed to download and set-up Open5GS so that it is ready to use with
srsRAN 4G:
• GitHub
• Quickstart Guide
srsENB will connect to the AMF and UPF via the mme_addr config option in the srsENB config file.
22.3 Preparing COTS UE
Most COTS UEs will have no issues connecting to srsRAN 4G, and should work out of the box. In the
case where you are having difficulties seeing, or connecting to the network, the following steps may need
to be followed:
• Correct configuration of the 5G USIM
• Rooting the UE
• Using Network Signal Guru to force the device to see the 5G cell
The following steps are not a requirement to run 5G SA, but may be necessary if you are having trouble
connecting to the network.
22.3.1 5G SIM
If you are using a 5G-enabled sysmcom-ISIM then you will need to modify the 5G-related fields of the
sim card. In particular you need to enable SUCI concealment. This can be done via a sim card reader
using the following command (First, you need to add your ADM pin to ./scripts/deactivate-5g.script):
./pySim-shell.py -p0 --script ./scripts/deactivate-5g.script
You can find more information on this in this guide, written by Merlin Chlosta.
22.3.2 Rooting COTS UE
Rooting will allow you to run the Network Signal Guru (NSG) application. It also lets you configure
system settings and grants access to additional features not allowed with standard use.
How this is done is dependent on the make and manufacturer of your device. XDA-Developers have a
useful article which outlines how to root various COTS UE devices, you can find it here.
Warning: Rooting a device may cause you to lose any information stored on the device. It is not
recommended to root your personal device. You should be careful to fully understand what you are
doing before undertaking the process.

22.3.3 Network Signal Guru
Note: For NSG to work and force the connection to the 5G SA cell, your device must have a Qualcomm
baseband processor and also be rooted.
You can download NSG from the Play Store at this link.
NSG will be used to force the COTS UE to use a specific RAT, in this case 5G SA. To do this take the
following steps:
• In the top right corner of the app, open the drop down menu by pressing the 3 dots.
• Now select Forcing Control.
• Under “Preferred Network Type” select only 5GNR.
• Under “NR5G” Mode select SA.
To activate LTE and NSA, take the following steps:
• Under “Preferred network type” select 5GNR and LTE
• Under “NR5G” Mode select NSA/SA
The rest of the settings should stay as they are, either not set or left in the default state. This is shown in
the following screenshots.
Once the network is up and running you should be able to select it from the application at select to. This
will then force the UE to attach to it.
22.3. Preparing COTS UE 145

22.4 Configuration
The following config files were modified for this app note:
• enb.conf
• rr.conf
• amf.yaml
• upf.yaml
Note: 22.04.1 brings changes to the rr.conf, coreset0_idx is now a required field under nr_nell_list.
If you are using an old config file with the latest update, you will need to add this to your config file.
Details of the modifications made will be outlined in following sections.
22.4.1 srsENB
To configure srsENB to connect to both the 5GC and COTS UE, changes need to be made to:
• enb.conf
• rr.conf
enb.conf
Firstly, the MCC and MNC need to be changed to match those being used by Open5GS, the mme_addr
also needs to be set to allow the RAN to connect to the AMF and UPF.
The following shows these modifications:
[enb]
enb_id = 0x19B
mcc = 901
mnc = 70
mme_addr = 127.0.0.2
s1c_bind_port = 0
n_prb = 50
#tm = 4
#nof_ports = 2
srsENB will automatically select the SDR that is connected, in this example it is the B200-mini USRP.
Further configuration with specific device arguments is possible. For this example the following config
was used:
[rf]
#dl_earfcn = 3350
tx_gain = 30
rx_gain = 40

device_name = auto
The tx and rx gain values can be adjusted here if the UE is unable to see or connect to the network. RF
signal strength is subjective to various physical conditions associated with each use case and set up. As a
result, the above config may not work perfectly for all users. Thus, their configuration should be modified
as needed.
rr.conf
The rr.conf file needs to be modified to add the NR Cell to the cell list. The default LTE cells also need to
be either commented out, or removed completely from the list. The NR Cell is configured in the following
way:
nr_cell_list =
(
{
rf_port = 0;
cell_id = 1;
root_seq_idx = 1;
tac = 7;
pci = 500;
dl_arfcn = 368500;
coreset0_idx = 6;
band = 3;
}
);
In the attached example config the LTE cell list has simply been commented out. Although the list can
also be removed, or left empty.
22.4.2 Core
As highlighted above, the Open5GS 5G Core Quickstart Guide provides a comprehensive overview of
how to configure Open5GS to run as a 5G Core.
The main modifications needed are:
• Change the TAC in the AMF config to 7
• Check that the NGAP, and GTPU addresses are all correct. This is done in the AMF and UPF
config files.
• It is also a good idea to make sure the PLMN values are consistent across all of the above files and
the UE config file.
The final step is to register the UE to the list of subscribers through the Open5GS WebUI. The values for
each field should match the values associated with the USIM being used. These are typically provided
by the USIM manufacturer.
22.4. Configuration 147

Note: Make sure to correctly configure the APN, if this is not done correctly the UE will not connect.
22.4.3 Add APN to COTS UE
An APN must be added to the COTS UE to allow it to connect to the internet. This APN must be the
same as is defined in the subscriber entry in the Core.
By default when a subscriber is registered with the Open5GS Core via the WebUI, it is given an APN
with the following details:
• APN: internet
• APN Protocol: IPv4
This is done from the Network Settings of the UE. Usually found via the following path (or similar):
• WiFi & Network > SIM & network settings > SIM > Access Point Names
An APN with the above credentials should then be added to the list.
22.5 Connecting to the Network
22.5.1 Core
Once the Core has been configured by following the above steps and the Open5Gs Quickstart Guide, it
is important to restart the AMF and UPF daemons. This should be done any time a modification is made
to either of the associated config files so that any changes made can take affect.
The core does not need to be started directly, as it will run in the background by default. srsENB will
automatically connect to it on start-up.
22.5.2 srsENB
First run srsENB. In this example srsENB is being run directly from the build folder, with the config files
also located there:
sudo ./srsenb enb.conf
If srsENB connects to the core successfully the following (or similar) will be displayed on the console:
Opening 1 channels in RF device=default with args=default

Supported RF device list: UHD bladeRF zmq file
Trying to open RF device 'UHD'
NG connection successful
[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.2.0.HEAD-0-
˓→g197cdc4f


[INFO] [UHD RF] RF UHD Generic instance constructed
RF device 'UHD' successfully opened

Setting frequency: DL=1842.5 Mhz, DL_SSB=1843.25 Mhz (SSB-ARFCN=368650),␣
˓→UL=1747.5 MHz for cc_idx=0 nof_prb=52
The NG connection successful message confirms that srsENB has connected to the core.
22.5.3 UE
You can now begin to search for the network from the UE. The option to do this is found via the following
(or similar) menu path:
• WiFi & Network > SIM & network settings > SIM > Network operators
The UE should then begin search for any available networks.
You should see an entry with the networks PLMN followed by 5G if the UE can successfully see the
network. You can then select this network from the list and the UE will automatically register and connect
to the network.
22.5.4 Confirming connection
If the UE successfully connects to the network, you should see an update to the srsENB console output.
This will look like the following:

Setting frequency: DL=1842.5 Mhz, DL_SSB=1843.25 Mhz (SSB-ARFCN=368650),␣
˓→UL=1747.5 MHz for cc_idx=0 nof_prb=52
RACH: slot=3051, cc=0, preamble=6, offset=10, temp_crnti=0x4601

User 0x46 connected
The attached is confirmed once the console displays User 0x46 connected.
22.5. Connecting to the Network 149

22.5.5 Internet Connectivity
The UE should now be able to send and receive data over the network. By default Open5GS is configured
to allow connected UEs access to the internet. If your connected device is unable to connect to the
internet, please follow the documentation found here.
22.6 srsENB Trace
The following example console output shows the srsENB trace of a COTS UE sending and receiving data
over the network:
-----------------DL----------------|-------------------------
˓→ UL-------------------------
nr 0 4601 15 0 25 1.2M 40 0 0% | 15.6 12.0 0 8 ␣
˓→81k 10 0 0% 0.0
nr 0 4601 12 0 25 25M 837 0 0% | 15.4 16.6 0 8 ␣
˓→548k 68 0 0% 0.0
nr 0 4601 11 0 25 27M 879 0 0% | 15.4 16.6 0 8 ␣
˓→202k 25 0 0% 0.0
nr 0 4601 9 0 25 27M 900 0 0% | 15.4 16.5 0 8 ␣
˓→202k 25 0 0% 0.0
nr 0 4601 10 0 25 25M 827 0 0% | 15.5 16.4 0 8 ␣
˓→194k 24 0 0% 0.0
nr 0 4601 10 0 25 26M 851 0 0% | 15.5 16.4 0 8 ␣
˓→202k 25 0 0% 0.0
nr 0 4601 10 0 25 27M 879 0 0% | 15.3 16.3 0 8 ␣
˓→202k 25 0 0% 0.0
nr 0 4601 11 0 25 27M 892 0 0% | 15.3 16.3 0 8 ␣
˓→202k 25 0 0% 0.0
nr 0 4601 12 0 25 27M 900 0 0% | 15.4 16.2 0 8 ␣
˓→202k 25 0 0% 0.0
nr 0 4601 10 0 25 27M 900 0 0% | 15.4 16.3 0 8 ␣
˓→202k 25 0 0% 0.0
nr 0 4601 11 0 25 25M 811 0 0% | 15.5 16.2 0 8 ␣
˓→202k 25 0 0% 0.0
22.7.1 MCS
One of the current limitations of the NR scheduler is missing dynamic MCS adaptation. Therefore, a
fixed MCS is used for both downlink (PDSCH) and uplink (PUSCH) transmissions. By default we use
the maximum value of MCS 28 for maximum rate. Depending on the RF conditions this, however, may
be too high. In this case, try to use a lower MCS, e.g.:

[scheduler]
nr_pdsch_mcs = 10
nr_pusch_mcs = 10
22.7.2 Reference clock
If you encounter issues with the phone not finding the cell and/or not being able to stay connected it
might be due to inaccurate clocks at the gNBs RF frontend. Try to use an external 10 MHz reference or
use a GPSDO-disciplined oscillator.
22.8 Limitations
22.8.1 Bandwidth
Currently srsENB only supports a bandwidth of 10 MHz when operating in 5G SA mode.
22.8.2 FDD Bands
Currently, srsRAN 4G only supports the use of FDD bands for 5G SA. This is due to srsRAN 4G only
supporting 15 kHz SCS. As of srsRAN 4G 22.04.1 the fixed CoreSet0 index has been removed and can
now be freely configured. However, not all combinations of ARFCNs and CoreSet0 index are valid
configurations. An config value checker will inform the use if an invalid combination has been provided.
If this happens, either change the ARFCN or the coreset0_idx value in the rr.conf.
22.9 Tested Devices
The following devices have been tested by users, and are known to connected srsENB when running a
5G SA network:
• OnePlus 10 Pro 5G
• OnePlus Nord 5G
• Samsung A22
• Hisense F50+
• Huawai P40 lite 5G
22.8. Limitations 151

CHAPTER
TWENTYTHREE
5G SA SRSUE
23.1 Introduction
The 22.04 release of srsRAN 4G brought 5G SA (Standalone) support to srsUE. This application note
shows how srsUE can be used with a third-party 5G SA network. In this example, we use the Amari
Callbox Classic from Amarisoft to provide the network.
23.2 Hardware Requirements
For this application note, the following components are used:

• Amari Callbox with 5G SA support as gNB and core
• AMD Ryzen5 3600X Linux PC as UE compute platform
• Ettus Research USRP X310 connected over 10GigE as UE RF front-end
The Amari Callbox is an LTE/NR SDR-based UE test solution from Amarisoft. It contains an EPC, a
5GC, an eNodeB, a gNodeB, an IMS server, an eMBMS server and an Intel i7 Linux PC with PCIe SDR
cards. The gNodeB is release 15 compliant and supports both NSA and SA modes. A further outline of
the specifications can be found in the data sheet. This test solution was chosen as it’s widely available,
easily configurable, and user-friendly.
23.3 Hardware Setup
Tests may be carried out over-the-air or using a cabled setup. For this example, we use a cabled setup
between the UE and the eNB/gNB (i.e from the X310 to the PCIe SDR cards on the Callbox). These
connections run through 30dB attenuators as shown in the figure above. The PPS inputs for the accurate
clocking of both the UE and Callbox are also shown. Both UE and Callbox require accurate clocks - in
our testing we provide PPS inputs to both.
152
23.4 Limitations
The current 5G SA UE application has a few feature limitations that require certain configuration settings
at both the gNB and the core network. The key feature limitations are as follows:
• Limited to 15 kHz Sub-Carrier Spacing (SCS), which means only FDD bands can be used.
• Limited to 10 MHz Bandwidth (BW)
23.5 Configuration
To set-up and run the 5G SA network and UE, the configuration files for both the Callbox and srsUE must
be changed.
All of the modified configuration files have been included as attachments to this App Note. It is recom-
mended you use these files to avoid errors while changing configs manually. Any configuration files not
included here do not require modification from the default settings.
UE files:
• UE config example
Callbox files:
• gNB SA config
23.5.1 srsUE
The following changes need to be made to the UE configuration file to allow it to connect to the Callbox
in SA mode.
Firstly the following parameters need to be changed under the [rf] options so that the X310 is configured
optimally:
[rf]
tx_gain = 3
freq_offset = 0
nof_antennas = 1
srate = 11.52e6
device_name = uhd
device_args = type=x300,serial=30B8658,clock=external,sampling_rate=23.04e6,
˓→lo_freq_offset_hz=23.04e6,None
The next set of changes need to be made to the [rat.eutra] options. The LTE carrier is disabled, to force
the UE to use a 5G NR carrier:
[rat.eutra]
dl_earfcn = 2850
nof_carriers = 0

Finally the [rat.nr] options need to be configured for 5G SA mode operation:
[rat.nr]
nof_carriers = 1
bands = 3
23.5.2 Callbox
The amarisoft_enb.cfg file is responsible for the configuration of the gNB needed for a 5G SA network.
The main changes to the default config are as follows:
• Enable NR support
• Enable NR cell and configure NR cell
• Modify the PRACH configuration
• Modify the PUCCH configuration
Enable NR Support
This is done on line 47. by setting the corresponding flag to true:
nr_support: true,
NR Cell
Firstly the Band and ARFCN must be set. This is done on lines 61 and 62:
nr_cell_list: [
{
rf_port: 0,
cell_id: 1,
band: 3,
dl_nr_arfcn: 368500,
},
],
The band and dl_nr_afcn are chosen based on the known limitations of srsRAN 4G.
Next, the SCS, BW and other configuration parameters can be changed from line 68:
nr_cell_default: {
subcarrier_spacing: 15, /* kHz */
ssb_subcarrier_spacing: 15, // only supported in FDD bands
bandwidth: 10, /* MHz */
n_antenna_dl: 1,
n_antenna_ul: 1,
154 Chapter 23. 5G SA srsUE

ssb_pos_bitmap: "1000",
ssb_period: 10, /* in ms */
n_id_cell: 500,
Here the subcarrier_spacing is set to 15 KHz and the bandwidth to 10 MHz, the n_antenna_dl is
set to 1 and the ssb_period is set to 10.
PRACH
For the PRACH config options (line 105) the following is used:
prach: {
prach_config_index: 0,
msg1_fdm: 1,
msg1_frequency_start: 1,
zero_correlation_zone_config: 0,
preamble_received_target_power: -110, /* in dBm */
preamble_trans_max: 7,
power_ramping_step: 4, /* in dB */
ra_response_window: 10, /* in slots */
restricted_set_config: "unrestricted_set",
ra_contention_resolution_timer: 64, /* in ms */
ssb_per_prach_occasion: 1,
cb_preambles_per_ssb: 8,
},
The changes made to the above include the setting of prach_config_index to 0, setting
msg1_frequency_start to 1 and setting ra_response_window to 10.
PUCCH
Lastly, the PUCCH config must be changed. This is done from line 353:
pucch: {
pucch_group_hopping: "neither",
hopping_id: -1, /* -1 = n_cell_id */
p0_nominal: -90,
pucch1: {
n_cs: 3,
n_occ: 3,
freq_hopping: false,
},
pucch2: {
n_symb: 2,
n_prb: 1,


simultaneous_harq_ack_csi: false,
max_code_rate: 0.25,
},
},
The only change here is that freq_hopping is set to false in both pucch1 and pucch2.
The gNB is now configured correctly. All other config files associated with the gNB and 5GC can be left
in their default states.
23.6 Running the Network
The following order should be used when running the network:

1. 5GC
2. gNB
3. UE
23.6.1 5GC
To run the 5GC the following command is used:
sudo ltemme mme.cfg
23.6.2 gNB
Next the eNB/ gNB should be instantiated, using the following command:
sudo lteenb gnb-nsa.cfg
Console output should be similar to:
Base Station version 2021-03-15, Copyright (C) 2012-2021 Amarisoft
RF0: sample_rate=61.440 MHz dl_freq=1836.740 MHz ul_freq=1741.740 MHz (band␣

˓→n3) dl_ant=1 ul_ant=1
23.6.3 UE
To run the UE, use the following command:
sudo srsue ue.conf
Once the UE has been initialized you should see the following:
Opening 1 channels in RF device=uhd with args=type=x300,serial=30B8658,

˓→clock=external,sampling_rate=23.04e6,lo_freq_offset_hz=23.04e6,None

This will be followed by some information regarding the USRP. Once the cell has been found successfully
you should see the following:

˓→tti=3851

RRC Connected
PDU Session Establishment successful. IP: 192.168.4.2
To confirm the UE successfully connected, you should see the following on the console output of the
gNB:
PRACH: cell=01 seq=0 ta=3 snr=29.1 dB
23.7 Console Trace
23.7.1 srsUE
The following is an example console trace output when running bi-direction traffic with iPerf3:
---------Signal-----------|-----------------DL-----------------|-----------UL-
˓→----------
˓→brate bler
nr 500 -3 0 2.0 | 27 28 2.0 23M 0% 0.0 | 27 59 ␣
˓→ 16M 0%
nr 500 -3 0 1.6 | 27 28 2.1 23M 0% 0.0 | 27 30k ␣
˓→ 16M 0%
nr 500 -3 0 2.0 | 27 28 2.1 23M 0% 0.0 | 27 44k ␣
˓→ 16M 0%
nr 500 -3 0 824m | 27 28 2.1 23M 0% 0.0 | 27 26k ␣
˓→ 16M 0%
nr 500 -3 0 1.1 | 27 28 2.1 23M 0% 0.0 | 27 10k ␣
˓→ 17M 0%
nr 500 -3 0 1.3 | 27 28 2.0 23M 0% 0.0 | 27 0.0 ␣
˓→ 16M 0%
nr 500 -3 0 106m | 27 28 2.0 23M 0% 0.0 | 27 118k ␣
˓→ 16M 0%
nr 500 -4 0 1.0 | 27 28 2.1 22M 0% 0.0 | 27 52k ␣
˓→ 21M 0%
nr 500 -4 0 1.9 | 27 28 2.0 22M 0% 0.0 | 27 57k ␣
˓→ 21M 0%
nr 500 -3 0 840m | 27 28 2.0 23M 0% 0.0 | 27 54k ␣
˓→ 19M 0%
nr 500 -3 0 160m | 27 28 2.0 23M 0% 0.0 | 27 20k ␣
˓→ 18M 0%
23.7. Console Trace 157

To read more about the UE console trace metrics, see the UE User Manual.
23.7.2 Amarisoft gNB
The following console output is shown on the gNB for the same period:
----DL----------------------- --UL-----------------------------
˓→-------------------
UE_ID CL RNTI C cqi ri mcs retx txok brate snr puc1 mcs rxko rxok brate ␣
˓→ #its phr pl ta
1 001 4601 1 15 1 27.9 0 1472 22.6M 39.5 - 27.9 0 1022 18.7M ␣
˓→1/1.9/3 - - 0.3
1 001 4601 1 15 1 27.9 0 1476 22.7M 39.3 - 27.9 0 987 17.8M ␣
˓→1/1.9/3 - - 0.3
1 001 4601 1 15 1 27.9 0 1512 23.1M 36.3 - 27.9 0 908 15.7M ␣
˓→1/1.9/3 - - 0.3
1 001 4601 1 15 1 27.9 0 1474 22.6M 38.0 - 27.9 0 977 17.1M ␣
˓→1/1.9/3 - - 0.3
1 001 4601 1 15 1 27.9 0 1488 22.8M 46.6 - 27.9 0 929 16.3M ␣
˓→1/1.9/3 - - 0.3
1 001 4601 1 15 1 27.9 28 1427 21.9M 38.0 - 27.9 0 1035 19.1M ␣
˓→1/1.9/3 - - 0.2
1 001 4601 1 15 1 27.9 5 1428 21.9M 39.8 - 28.0 0 1113 21.3M ␣
˓→1/1.9/3 - - 0.2
1 001 4601 1 15 1 27.9 3 1416 21.7M 38.2 - 28.0 0 1159 22.4M ␣
˓→1/1.9/3 - - 0.2
1 001 4601 1 15 1 27.9 0 1395 21.4M 38.7 - 28.0 0 1222 24.7M ␣
˓→1/2.0/3 - - 0.2
1 001 4601 1 15 1 27.9 0 1405 21.6M 39.0 - 28.0 0 1182 23.3M ␣
˓→1/2.0/3 - - 0.2

CHAPTER
TWENTYFOUR
5G NSA END-TO-END
The 21.10 release of srsRAN brings 5G NSA support to the SRS eNodeB application (srsENB). 5G NSA
features can be enabled via the srsENB configuration files. This application note shows how to create an
end-to-end 5G NSA Network using srsUE, srsENB and srsEPC. The ZMQ virtual radio is used in place
of physical RF hardware.
24.1 5G NSA Overview
5G Non-Standalone mode provides 5G support by building upon and using pre-existing 4G infrastructure.
A secondary 5G carrier is provided in addition to the primary 4G carrier. A 5G NSA UE connects first
to the 4G carrier before connecting to the secondary 5G carrier. The 4G anchor is used for control plane
signaling while the 5G carrier is used for high-speed data plane traffic.
This approach has been used for the majority of commercial 5G network deployments to date. It provides
improved data rates while leveraging existing 4G infrastructure. UEs must support 5G NSA to take
advantage of 5G NSA services, but existing 4G devices are not disrupted.
For this application note we will be using ZeroMQ in place of physical RF hardware. A detailed outline of
how to install and use ZMQ with srsRAN can be found here. This app note will assume prior knowledge
of use of ZMQ with srsRAN.
This set up requires the following:
• srsUE running in a seperate network namespace
• srsENB configured so that both an LTE eNB, and an NSA gNB cell are created at run time
• srsEPC with the UE included in the list of subscribers
159
Fig. 2: Simplified overview of the network architecture
160 Chapter 24. 5G NSA End-to-End

24.2.1 Using RF-Hardware
To create a physical end-to-end network using RF-hardware, the following is required:
Table 1: NSA Network Hardware Requirements

Network Element RF-Frontend Linux based PC
srsUE X3xx USRP X
srsENB & srsGNB X3xx USRP X
srsEPC X
Such a set-up requires two X3xx series USRPs and 2 Linux PCS.
It is recommended to use an X3xx series USRP with a UBX Daughterboard. Other RF hardware featuring
dual channel Tx and Rx with independent RF chains may also be supported.
24.3 Network Configuration
Changes need to be made to the configuration files of srsUE and srsENB. These changes enable the use
of ZMQ and also enable the 5G NSA carrier in srsENB. No srsEPC configuration changes are required.
Example config files used in this note are available for download. Only modified configs are included
here, default configs can be used elsewhere. All changes are outlined in the following sections.
• ue.conf
• enb.conf
• rr.conf
24.3.1 srsUE
For srsUE the relevant changes need to be made to ue.conf to enable ZMQ and 5G NR capabilities.
ZMQ
As per the description in the ZMQ app-note, to enable ZMQ the device_name and device_args must be
changed in the [rf] section:
device_name = zmq
device_args = tx_port0=tcp://*:2001,rx_port0=tcp://localhost:2000,tx_
˓→port1=tcp://*:2101,rx_port1=tcp://localhost:2100,id=ue,base_srate=23.04e6
Here we add two TX and two RX channels to support both the 4G primary and 5G secondary carriers,
as outlined in the network diagram.
To complete the ZMQ set-up, the network namespace netns must be set under the [gw] settings:
[gw]
netns = ue1
24.3. Network Configuration 161

NR RAT
The 5G NR capabilities of the UE must also be enabled in the config under the [rat.nr] section:
[rat.nr]
bands = 3,78
nof_carriers = 1
Here we enable bands 3 and 78, which are FDD and TDD frequency bands respectively. By including
both in the UE config, we can test each duplex mode simply by configuring the network.
The number of NR carriers needs to be set to 1, or else the UE will not be able to connect to the gNB. If
this was not set, it would result in the UE only having an LTE connection.
Release
As NSA Mode is part of 3GPP release 15, this must be reflected in the config. The default release used
is 8. Add the following entry under the [rrc] field:
[rrc]
release = 15
24.3.2 srsENB
Changes need to be made to both enb.conf and rr.conf to enable 5G NSA.
eNB Config
First the the changes required to enable ZMQ should be made. This involves changing the device_name
and device_args in the [rf] section:
device_name = zmq
device_args = fail_on_disconnect=true,tx_port0=tcp://*:2000,rx_port0=tcp://
˓→localhost:2001,tx_port1=tcp://*:2100,rx_port1=tcp://localhost:2101,id=enb,
˓→base_srate=23.04e6
Similarly to the UE there are two TX and two RX channels. These channels are mapped to the relevent
ports configured on the UE.
No other changes are needed in the enb.conf.

RRC Config
The main change to the rr.conf file is the addition of the NR cell to the cell list. This is added to the end
of the file:
nr_cell_list =
(
{
rf_port = 1;
cell_id = 0x02;
tac = 0x0007;
pci = 500;
root_seq_idx = 204;
// TDD:
//dl_arfcn = 634240;
//band = 78;
// FDD:
dl_arfcn = 368500;
band = 3;
}
);
Here we have added both the TDD and FDD configs. For this example we will be using the FDD con-
figuration, so the TDD configuration is commented out. The TDD and FDD configs can be swapped by
stopping srsENB, making the necessary changes to this file, and restarting srsENB.
24.4 Network Set-up
With the above configurations, the network can now be started. Run the EPC first, followed by the eNodeB
and the UE.
24.4.1 EPC
First run the EPC:
sudo srsepc
You should then see a similar output to the following:
HSS Initialized.
MME S11 Initialized
SP-GW Initialized.
24.4. Network Set-up 163

24.4.2 eNB
Next run the eNB/ gNB:
sudo srsenb
The following output, or similar, will be seen if srsENB as started correctly:
Opening 2 channels in RF device=zmq with args=fail_on_disconnect=true,tx_

˓→port0=tcp://*:2000,rx_port0=tcp://localhost:2001,tx_port1=tcp://*:2100,rx_
˓→port1=tcp://localhost:2101,id=enb,base_srate=23.04e6
CHx id=enb

Note how two cells have been created, with IDs 0 and 1. 0 is the LTE cell, and 1 is the NR cell.
If the eNB successfully attaches to the core, the console trace for the EPC should update.
24.4.3 UE
The UE should now be run using:
sudo srsue
If it runs and connects to the eNB/ gNB successfully, you should see something like the following:
Opening 2 channels in RF device=zmq with args=tx_port0=tcp://*:2001,rx_

˓→port0=tcp://localhost:2000,tx_port1=tcp://*:2101,rx_port1=tcp://
˓→localhost:2100,id=ue,base_srate=23.04e6
CHx id=ue


Attaching UE...
.
Found Cell: Mode=FDD, PCI=1, PRB=50, Ports=1, CP=Normal, CFO=-0.2 KHz
Random Access Transmission: seq=33, tti=981, ra-rnti=0x2
RRC Connected
Software Radio Systems RAN (srsRAN) 13/10/2021 15:29:9 TZ:0
˓→tti=1611
The following message RRC NR reconfiguration successful confirms that the UE has connected
to the NR cell. This will be used for the data link, while the LTE cell will be used for control messaging.
Updates will also be seen in the eNB and EPC consoles.
24.4.4 Testing the Network
Traffic can be sent through the network to test the connection. Using either ping or iperf3 allows traffic
to be sent from the UE to the gNB. An example of using ping can be found in the ZMQ app-note, so for
this example iperf3 will be used.
iPerf
In this setup the client will run on the UE side with the server on the network side. UDP traffic will be
generated at 10Mbps for 60 seconds. When running the iperf client, we use the UE network namespace
and specify the network-side IP address. It is important to start the server first, and then the client.
Network-side
Start the iPerf server:
iperf3 -s -i 1
This will then listen for traffic coming from the UE.

UE-side
With the network and the iPerf server up and running, the client can be run from the UE’s network
namespace with following command:
sudo ip netns exec ue1 iperf3 -c 172.16.0.1 -b 10M -i 1 -t 60
Traffic will now be sent from the UE to the eNB. This will be shown in both the server and client consoles,
and also in the trace for both the UE and the eNB. Example client iPerf output:
Connecting to host 172.16.0.1, port 5201

[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 954 KBytes 7.81 Mbits/sec 0 79.2 KBytes
[ 5] 1.00-2.00 sec 1.12 MBytes 9.44 Mbits/sec 0 126 KBytes
Example server iPerf output:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 172.16.0.2, port 52482
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 634 KBytes 5.19 Mbits/sec
UE Trace
The UE console trace can be enabled by entering t on the UE console. The trace is updated every second.
Note: The time interval between metrics reports can be changed in the UE config file under the
[general] field, by changing the value of metrics_period_secs.
If traffic is being successfully sent across the network, then the UE console trace should like something
like this:
---------Signal-----------|-----------------DL-----------------|-----------UL-
˓→----------
˓→brate bler


lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 1 0 23u | 27 70 1.0 8.5M 0% 0.0 | 28 36k ␣
˓→8.3M 0%
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 1 0 23u | 27 70 1.0 9.2M 0% 0.0 | 28 24k ␣
˓→8.1M 0%
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 2 0 23u | 27 69 1.0 4.6M 0% 0.0 | 28 19k ␣
˓→4.2M 0%
lte 1 -11 11 -1.3u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 2 0 23u | 27 69 1.0 5.0M 0% 0.0 | 28 26k ␣
˓→4.8M 0%
lte 1 -11 11 -1.4u | 0 142 0.0 0.0 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
nr 500 2 0 23u | 27 69 1.0 4.7M 0% 0.0 | 28 28k ␣
˓→4.7M 0%
The rat field reports if a metric is associated with the NSA 5G link (nr), or with the LTE link (lte).
eNB/ gNB Trace
The eNB/ gNB trace can also be enabled by entering t on the console. The metrics are reported every
second.
Note: This can also be changed in the eNB config file, under the [expert] heading, by changing the
value of metrics_period_secs.
The console trace should look like the following if traffic is being transmitted successfully:
-----------------DL----------------|-------------------------UL-----
˓→ --------------------
rat rnti cqi ri mcs brate ok nok (%) | pusch pucch phr mcs brate ␣
˓→ ok nok (%) bsr
lte 46 15 0 0 0 0 0 0% | n/a n/a 0 0 0 ␣
˓→ 0 0 0% 0.0
nr 4601 n/a 0 27 6.9M 124 0 0% | n/a n/a 0 0 6.1M ␣
˓→ 95 0 0% 0.0
lte 46 15 0 0 0 0 0 0% | n/a n/a 0 0 0 ␣
˓→ 0 0 0% 0.0
nr 4601 n/a 0 27 4.4M 92 0 0% | n/a n/a 0 0 4.2M ␣
˓→ 76 0 0% 0.0
lte 46 15 0 0 0 0 0 0% | n/a n/a 0 0 0 ␣
˓→ 0 0 0% 0.0
nr 4601 n/a 0 27 5.2M 113 0 0% | n/a n/a 0 0 5.0M ␣
˓→ 94 0 0% 0.0 (continues on next page)


lte 46 15 0 0 0 0 0 0% | n/a n/a 0 0 0 ␣
˓→ 0 0 0% 0.0
nr 4601 n/a 0 27 5.4M 118 0 0% | n/a n/a 0 0 5.3M ␣
˓→ 99 0 0% 0.0
lte 46 15 0 0 0 0 0 0% | n/a n/a 0 0 0 ␣
˓→ 0 0 0% 0.0
nr 4601 n/a 0 27 7.6M 156 0 0% | n/a n/a 0 0 7.2M ␣
˓→129 0 0% 0.0
Similarly to the UE console trace, the rat field denotes which link the metrics reported are associated
with.
24.5 GUI
srsGUI is also supported for use with the UE in NSA mode. An example of the plots produced can be
seen above.
To enable srsGUI, see here.
Note: If you have already built srsRAN without srsGUI support, you must re-do so after srsGUI has
been built.

CHAPTER
TWENTYFIVE
5G NSA COTS UE
Warning: Operating a private 5G NSA network on cellular frequency bands may be tightly regulated
in your jurisdiction. Seek the approval of your telecommunications regulator before doing so.
25.1 Introduction
This application note shows how to create your own 5G NSA network using srsENB, srsEPC and a 5G
capable COTS UE. There are two options for network setup when connecting a COTS UE: The network
can be left as is, and the UE can communicate locally within the network, or the EPC can be connected
to the internet through the P-GW, allowing the UE to access the internet for web-browsing, email etc.
Fig. 1: Simplified network architecture
169
Setting up a 5G NSA network and connecting a 5G COTS UE requires the following:

• PC with a Linux based OS, with srsRAN 4G installed and built
• A dual channel RF-frontend with independent RF chains
• A 5G NSA-capable UE
For this implementation the following equipment is used:
• Desktop computer (minimum 6th Gen i7 or similar) with 10GigE NIC
• X300 USRP
• OnePlus Nord 5G with a Sysmocom USIM
25.2.1 UE Considerations
One of the current limitations of srsRAN 4G is that both LTE and NR carrier have to use the same
subcarrier spacing (SCS) of 15 kHz. Unfortunately, this limits the band combinations that can be used
with COTS phones, as not all combinations are possible with every baseband chip.
For example, NR band n78 that is used in most European deployments to date (using 30 kHz SCS), in
theory, also supports 15 kHz SCS. However, all phones we’ve tried with cannot support 15 kHz on this
band. Check the supported band combinations for your handset using this webpage.
As a consequence, we suggest using FDD bands for both LTE and NR carrier, such as band 20 for LTE
and band n3 for NR. Both bands are supported by the OnePlus 5G Nord used in this appnote.
Besides the restrictions originating from the baseband hardware there are a few other pitfalls that may or
may not allow a phone to connect to a 5G network.
• Many 5G handsets may contain a carrier policy file that may limit 5G capabilities of the phone
based on the PLMN of the USIM (first 6 digits of IMSI). Carrier policy files typically don’t include
test network PLMNs, so setting a test PLMN may result in 5G being disabled. If possible, using a
shielded box and configuring the network with a commercial carrier PLMN may avoid policy file
issues.
• On some handsets, when using a test USIM, you may need to activate 5G NR using *#*#4636#*#*.
• If your handset supports “Smart 5G”, disable this option as it may force the handset to 4G and
activate roaming.
25.3 Dependencies
25.3.1 RF Driver
We’ve only tested NSA mode with Ettus Research devices using UHD. For this appnote we use the USRP
X310 with UHD version v3.15.
170 Chapter 25. 5G NSA COTS UE

25.3.2 srsRAN 4G
If you have not already done so, install the latest version of srsRAN 4G and dependencies. This is outlined
in the installation guide.
Note: If you install or update your driver after installing srsRAN 4G, you will have to re-build srsRAN
4G.
25.3.3 Checking Drivers
can run:
//Enable UHD
ENABLE_UHD:BOOL=ON
25.4 Configuration
The network will have to be configured to support the NSA network and to work with a COTS UE. The
following srsRAN 4G configuration files will need to be updated:
• enb.conf
• rr.conf
• epc.conf
• user_db.csv
The enb.conf and epc.conf files will need to be edited such that the MCC & MNC values match those of
the USIM. The rr.conf needs to be updated to add the NR cell. The user_db.csv file needs to be updated
so that it contains the credentials associated with the USIM card being used in the UE.
An APN will also need to be added to the COTS UE to allow it to access the internet. This is reflected
in the EPC config file.
The configuration files used for this example set-up are attached above for reference. Users may need to
edit the relevant fields so that their specific COTS UE will be supported by the network.

25.4.1 Add APN to COTS UE
To add an APN to the UE, navigate to the Network settings for the USIM being used. From here an
APN can be added, usually under Access point names. Create a new APN with the name and APN
test123, as shown below.
All other settings can be left on the default options. The name of the APN here does not actually matter,
as long as the naming is consistent between the UE and the EPC.
25.4.2 srsENB
enb.conf
The MCC & MNC codes must be updated in the enb.conf to reflect the values used by the sim. These can
be edited in the following section of the config file:
#####################################################################
[enb]
enb_id = 0x19B
mcc = 901
mnc = 70
mme_addr = 127.0.1.100


n_prb = 50
#tm = 4
#nof_ports = 2
#####################################################################
For the X310 we’ve seen acceptable results with the following device arguments:
[rf]
device_args=type=x300,clock=external,sampling_rate=11.52e6,lo_freq_offset_
˓→hz=11.52e6
The rest of the options can be left at the default values. They may be changed as needed, but further
modification is not necessary to enable the successful connection of a COTS UE.
rr.conf
The main change to the rr.conf file is the addition of the NR cell to the cell list. This is added to the end
of the file:
nr_cell_list =
(
{
rf_port = 1;
cell_id = 0x02;
tac = 0x0007;
pci = 500;
root_seq_idx = 204;
// TDD:
//dl_arfcn = 634240;
//band = 78;
// FDD:
dl_arfcn = 368500;
band = 3;
}
);
Here we have added both the TDD and FDD configs. For this example we will be using the FDD con-
figuration, so the TDD configuration is commented out. Check that the UE model supports the chosen
bands.

25.4.3 Core
epc.conf
The EPC config file must be modified to reflect the MCC & MNC, as well as the APN being used by the UE:
#####################################################################
[mme]
mme_code = 0x1a
mme_group = 0x0001
tac = 0x0007
mcc = 901
mnc = 70
mme_bind_addr = 127.0.1.100
apn = test123
dns_addr = 8.8.8.8
encryption_algo = EEA0
integrity_algo = EIA1
paging_timer = 2
#####################################################################
user_db.csv
The following list describes the fields contained in the user_db.csv file. As standard, this file will come
with two dummy UEs entered into the CSV, these help to provide an example of how the file should be
filled in.
• Name: Any human readable value
• Auth: Authentication algorithm (xor/ mil)
• IMSI: UE’s IMSI value
• Key: UE’s key, hex value
• OP Type: Operator’s code type (OP/ OPc)
• OP: OP/ OPc code, hex value
• AMF: Authentication management field, hex value must be above 8000
• SQN: UE’s Sequence number for freshness of the authentication
• QCI: QoS Class Identifier for the UE’s default bearer
• IP Alloc: IP allocation strategy for the SPGW
The AMF, SQN, QCI and IP Alloc fields can be populated with the following values for the COTS UE:
• 9000, 000000000000, 9, dynamic
This will result in a user_db.csv file that should look something like the following:
#
# .csv to store UE's information in HSS


# Kept in the following format: "Name,Auth,IMSI,Key,OP_Type,OP,AMF,SQN,QCI,IP_
˓→alloc"
#
# Name: Human readable name to help distinguish UE's. Ignored by the HSS
# IMSI: UE's IMSI value
# Auth: Authentication algorithm used by the UE. Valid algorithms are XOR
# (xor) and MILENAGE (mil)
# 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
COTS_UE,mil,901700000020936,4933f9c5a83e5718c52e54066dc78dcf,opc,
˓→fc632f97bd249ce0d16ba79e6505d300,9000,0000000060f8,9,dynamic
The auth, IMSI, key, OP Type and OP are values associated with the USIM being used. The values
assigned to the AMF, SQN, QCI & IP Alloc are the default values above, which is explained further here
in the EPC documentation. Ensure there is no white space between the values in each entry, as this will
cause the file to be read incorrectly.
25.4.4 Masquerading Script
To allow UE to connect to the internet via the EPC, the pre-configured masquerading script must be run.
This can be found in srsRAN_4G/srsepc.
The masquerading script enables IP forwarding and sets up Network Address Translation to pass traffic
between the srsRAN 4G network and the external network. The script must be run each time the machine
is re-booted, and can be done before or while the srsRAN 4G is running. The UE will not be able to
communicate with the wider internet until this script has been run.
Before running the script it is important to identify the interface being used to connect your PC to the
internet. The script requires this as an argument as shown below:
route
You will see an output similar to the following:
Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 100 0 0␣
˓→enxc03ebab05013
10.12.1.0 0.0.0.0 255.255.255.0 U 100 0 0␣

˓→enxc03ebab05013

The interface (Iface) associated with the default destination is one which must be passed into the masq.
script. In the above output that is the enxc03ebab05013 interface.
The masq. script can now be run from the follow folder: srsRAN_4G/srsEPC
sudo ./srsepc_if_masq.sh <interface>
If it has executed successfully you will see the following message:
Masquerading Interface <interface>
The configuration files, user DB and UE are now set up appropriately to allow the COTS UE to connect
to the eNB and Core.
25.5 Connecting to the Network
The final step in connecting a COTS UE to srsRAN 4G is to first run the EPC and eNB, and then connect
to that network from the UE. The following sections will outline how this is achieved.
25.5.1 Core
First run srsEPC:
sudo srsepc
The following output should be displayed on the console:
Reading configuration file /etc/srsran_4G/epc.conf...

HSS Initialized.
MME S11 Initialized
SP-GW Initialized.
25.5.2 srsENB
Now start srsENB:
sudo srsenb
The console should display the following or similar:

Opening 2 channels in RF device=uhd with args=type=x300,clock=external,

˓→sampling_rate=11.52e6,lo_freq_offset_hz=23.04e6,send_frame_size=8000,recv_
˓→frame_size=8000,num_send_frames=64,num_recv_frames=64,None
[INFO] [UHD] linux; GNU C++ version 9.3.1 20200408 (Red Hat 9.3.1-2); Boost_
˓→106900; UHD_3.15.0.0-62-g7a3f1516

Opening USRP channels=2, args: type=x300,lo_freq_offset_hz=23.04e6,send_frame_
˓→size=8000,recv_frame_size=8000,num_send_frames=64,num_recv_frames=64,None=,
˓→master_clock_rate=184.32e6
[INFO] [UHD RF] RF UHD Generic instance constructed

[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 184.32 MHz
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1315 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1307 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)

The EPC console should now print an update if the eNB has successfully connected to the core:

The network is now ready for the COTS UE to connect.
25.5. Connecting to the Network 177

25.5.3 UE
You can now connect the UE to the network by taking the following steps:
Open the Settings menu and navigate to the Sim & Network options
Open this menu and proceed to the sub-menu associated with the USIM being used. It should look
something like the following:

Under the Network Operators find the network which you have just instantiated using srsRAN 4G.
Select the network that is a combination of your MMC & MNC values. The UE should then automatically
connect to the network.
25.6 Confirming connection
Once the UE has connected to the network, the console outputs of the srsENB and srsEPC can be used
to confirm a successful connection.
25.6.1 srsENB
If a successful connection is made, a RACH message should be seen followed by a USER <ID>
connected message where “<ID>” is the RNTI assigned to the UE:

User 0x46 connected
RACH: slot=7691, cc=0, preamble=41, offset=1, temp_crnti=0x4602
25.6. Confirming connection 179

-----------------DL----------------|-------------------------UL-----
˓→ --------------------
lte 46 12 0 5 2.5k 4 0 0% | 25.7 9.4 23 23 17k ␣
˓→ 4 0 0% 0.0
nr 4601 n/a 0 0 0 0 0 0% | n/a n/a 0 0 38k ␣
˓→ 4 0 0% 0.0
lte 46 13 0 0 0 0 0 0% | n/a 6.2 0 0 0 ␣
˓→ 0 0 0% 0.0
nr 4601 n/a 0 0 0 0 0 0% | n/a n/a 0 0 0 ␣
˓→ 0 0 0% 0.0
lte 46 13 0 0 0 0 0 0% | n/a 6.2 0 0 0 ␣
˓→ 0 0 0% 0.0
The UE is now connected to the network and should now automatically connect to this network each time
it is powered on. The UE should now also have access to the internet - as if connected to a commercial
5G network.
25.7.1 UE not attaching to network
• Some UEs have issues detecting networks operating on a test PLMN such as 00101. Using the
MCC of your local country can increase the chance to find the network. When using a shielded
environment, better results may be seen when using the PLMN of a local commercial network.
Warning: To avoid causing interference to local commercial networks, carry out tests using a
shielded environment.
25.7.2 NR carrier has high error rate
One of the current limitation of the NR scheduler is missing dynamic MCS adaptation. Therefore, a
fixed MCS is used for both downlink (PDSCH) and uplink (PUSCH) transmissions. By default we use
the maximum value of MCS 28 for maximum rate. Depending on the RF condiditions this, however, may
be too high. In this case, try to use a lower MCS, e.g.:
[scheduler]
nr_pdsch_mcs = 10
nr_pusch_mcs = 10

25.7.3 Ettus Research USRP N310
The N310 is another device that can be used for NSA. However, a few changes need to be made to the
configuration files.
In the enb.conf we need to change the device arguments to pick the right RF subdevice (band 20 for LTE
and band n3 for NR are too far apart to use the default) and also use sample rates supported by the N310:
[rf]
device_args = type=n3xx,tx_subdev_spec=A:0 B:0,rx_subdev_spec=A:0 B:0
[expert]
lte_sample_rates = true
The tests have been made with the N310 using UHD 4.1.

CHAPTER
TWENTYSIX
5G NSA SRSUE
26.1 Introduction
The 21.04 release of srsRAN 4G brought 5G NSA (Non-Standalone) support to srsUE. This application
note shows how the UE can be used with a third-party 5G NSA network. In this example, we use the
Amari Callbox Classic from Amarisoft to provide the network.
26.2 5G NSA: What you need to know

5G Non-Standalone mode provides 5G support by building upon and using pre-existing 4G infrastructure.
A secondary 5G carrier is provided in addition to the primary 4G carrier. A 5G NSA UE connects first
182
to the 4G carrier before also connecting to the secondary 5G carrier. The 4G anchor carrier is used for
control plane signaling while the 5G carrier is used for high-speed data plane traffic.
This approach has been used for the majority of commercial 5G network deployments to date. It provides
improved data rates while leveraging existing 4G infrastructure. UEs must support 5G NSA to take
advantage of 5G NSA services, but existing 4G devices are not disrupted.
26.3 Limitations
The current 5G NSA UE application has a few feature limitations that require certain configuration set-
tings at both the gNB and the core network. The key feature limitations are as follows:
• 4G and NR carrier need to use the same subcarrier-spacing (i.e. 15 kHz) and bandwidth (we’ve
tested 10 and 20 MHz)
• Only DCI format 0_0 (for Uplink) and 1_0 (for Downlink) supported
• NR carrier needs to use RLC UM (NR RLC AM not yet supported)
• Support for sub-6Ghz (FR1) spectrum
26.4 Hardware Requirements
For this application note, the following components are used:

• Amari Callbox with 5G NSA support as eNB/gNB and core
• AMD Ryzen5 3600X Linux PC as UE compute platform
• Ettus Research USRP X310 connected over 10GigE as UE RF front-end
The Amari Callbox is an LTE/NR SDR-based UE test solution from Amarisoft. It contains an EPC/5GC,
an eNodeB, a gNodeB, an IMS server, an eMBMS server and an Intel i7 Linux PC with PCIe SDR cards.
The gNodeB is release 15 compliant and supports both NSA and SA modes. A further outline of the
specifications can be found in the data sheet. This test solution was chosen as it’s widely available, easily
configurable, and user-friendly.
26.5 Hardware Setup
Tests may be carried out over-the-air or using a cabled setup. For this example, we use a cabled setup
between the UE and the eNB/gNB (i.e from the X310 to the PCIe SDR cards on the Callbox). These
connections run through 30dB attenuators as shown in the figure above. The PPS inputs for the accurate

clocking of both the UE and Callbox are also shown. Both UE and Callbox require accurate clocks - in
our testing we provide PPS inputs to both.
26.6 Configuration
To set-up and run the 5G NSA network and UE, the configuration files for both the Callbox and srsUE
must be changed.
All of the modified configuration files have been included as attachments to this App Note. It is recom-
mended you use these files to avoid errors while changing configs manually. Any configuration files not
included here do not require modification from the default settings.
UE files:
• UE config example
Callbox files:
• MME config
• gNB NSA config
26.6.1 srsUE
The following changes need to be made to the UE configuration file to allow it to connect to the Callbox
in NSA mode.
Firstly the following parameters need to be changed under the [rf] options so that the X310 is configured
optimally:
[rf]
tx_gain = 10
nof_antennas = 1
device_name = uhd
device_args = type=x300,clock=external,sampling_rate=11.52e6,lo_freq_offset_
˓→hz=11.52e6
srate = 11.52e6
The next set of changes need to be made to the [rat.eutra] options. This make sure the anchor cell is
found by the UE:
[rat.eutra]
dl_earfcn = 300
Finally the [rat.nr] options need to be configured for 5G NSA mode operation:
[rat.nr]
#enable 5G data link
nof_carriers = 1
184 Chapter 26. 5G NSA srsUE

26.6.2 Callbox
To correctly configure the Callbox changes must be made to the following files: mme.cfg and gnb_nsa.cfg.
MME Configuration
The mme.cfg file must be changed to reflect the QoS Class Identifier (QCI) which will be used across the
network. We use QCI 7 as NR RLC UM is supported by the UE. The following change must be made to
the erabs: configurations:
qci: 7,
gNB NSA Configuration

gnb_nsa.cfg is responsible for the configuration of both the LTE and NR cells needed for NSA mode.
The LTE cell will mainly be used for the control plane, while the NR cell will be used for the data plane.
The number of Resource Blocks (RBs) and number of antennae used in the DL must first be modified:
#define N_RB_DL 50 // Values: 6 (1.4MHz), 25 (5MHz), 50 (10MHz),␣

˓→75 (15MHz), 100 (20MHz)
#define N_ANTENNA_DL 1 // Values: 1 (SISO), 2 (MIMO 2x2), 4 (MIMO␣

˓→4x4)
The NR cell bandwidth should also be set:
#define NR_BANDWIDTH 10 // NR cell bandwidth. With the PCIe SDR50␣

˓→board, up to 50 MHz is supported.
The TX gain, sampling rates for each cell and the UL & DL frequencies for the NR cell must be set. The
tx_gain is set for the rf_driver::
tx_gain: 70.0, /* TX gain (in dB) */
The sample rate is set for the LTE cell in the rf_ports: configuration:
/* RF port for the LTE cell */

sample_rate: 11.52,
The sample rate and DL/UL frequencies are set for the NR cell in the rf_ports: configuration:
/* RF port for the NR cell */

sample_rate: 23.04,
dl_freq: 3507.84, // Moves NR DL LO frequency -5.76 MHz
ul_freq: 3507.84, // Moves NR UL LO frequency -5.76 MHz
The NR absolute radio-frequency channel number (ARFCN) for the DL needs to be changed to match
the new DL frequency that has been set:
dl_nr_arfcn: 634240, /* 3507.84 MHz */
Next, the default settings of the NR cell must be adjusted. The subcarrier spacing(s) should be changed
in the nr_cell_default: configuration:

subcarrier_spacing: 15, /* kHz *

ssb_subcarrier_spacing: 30,
The timing offset should be set to 0:
n_timing_advance_offset: 0,
The TDD config options now need to be adjusted:
period: 10,
dl_slots: 6,
dl_symbols: 0,
ul_slots: 3,
ul_symbols: 0,
After this the PRACH configuration needs to be adjusted:
#if NR_TDD == 1
prach_config_index: 0,
msg1_frequency_start: 1,
zero_correlation_zone_config: 0,
ra_response_window: 10, /* in slots */
For the PDCCH configuration (starting at line 411), the following changes must be made:
pdcch: {
common_coreset: {
rb_start: -1, /* -1 to have the maximum bandwidth */
l_crb: -1, /* -1 means all the bandwidth */
duration: 1,
precoder_granularity: "sameAsREG_bundle",
//dmrs_scid: 0,
},
dedicated_coreset: {
rb_start: -1, /* -1 to have the maximum bandwidth */
l_crb: -1, /* -1 means all the bandwidth */
duration: 1,
precoder_granularity: "sameAsREG_bundle",
//dmrs_scid: 0,
},
css: {
n_candidates: [ 1, 1, 1, 0, 0 ],
},
rar_al_index: 2,
uss: {
n_candidates: [ 0, 2, 1, 0, 0 ],


dci_0_1_and_1_1: false,
force_dci_0_0: true, // Forces DCI format 0_0 for Uplink
force_dci_1_0: true, // Forces DCI format 1_0 for Downlink
},
al_index: 1,
},
For the PDSCH configuration the following change needs to be made:
k1: [ 8, 7, 6, 6, 5, 4],
QAM 64 must be selected for the Modulation Coding Scheme (MCS) table:
mcs_table: “qam64”,
In the PUCCH set-up frequency hopping needs to be turned off:
For the pucch2 entry, the following settings can be selected, while the entries for pucch3 and pucch4 can
be removed fully:
pucch2: {
n_symb: 2,
n_prb: 1,
simultaneous_harq_ack_csi: false,
max_code_rate: 0.25,
},
The final changes to the configuration file are made to pusch settings:
pusch: {
mapping_type: "typeA",
n_symb: 14,
dmrs_add_pos: 1,
dmrs_type: 1,
dmrs_max_len: 1,
tf_precoding: false,
mcs_table: "qam64", /* without transform precoding */
mcs_table_tp: "qam64", /* with transform precoding */
ldpc_max_its: 5,
k2: 4, /* delay in slots from DCI to PUSCH */
p0_nominal_with_grant: -90,
msg3_k2: 5,
msg3_mcs: 4,
msg3_delta_power: 0, /* in dB */
beta_offset_ack_index: 9,
/* hardcoded scheduling parameters */



n_dmrs_cdm_groups: 1,
n_layer: 1,
/* if defined, force the PUSCH MCS for all UEs. Otherwise it is
computed from the last received PUSCH. */
/* mcs: 16, */
},
The Callbox should now be correctly configured for 5G NSA testing with srsUE.
26.7 Usage
Following configuration, we can run the UE and Callbox. The following order should be used when
running the network:
1. MME
2. eNB/ gNB
3. UE
26.7.1 MME
To run the MME the following command is used:
sudo ltemme mme.cfg
26.7.2 eNB/ gNB
Next the eNB/ gNB should be instantiated, using the following command:
sudo lteenb gnb-nsa.cfg
Console output should be similar to:
LTE Base Station version 2021-03-15, Copyright (C) 2012-2021 Amarisoft

This software is licensed to Software Radio Systems (SRS).
Support and software update available until 2021-10-29.
˓→1) dl_ant=1 ul_ant=1

˓→n78) dl_ant=1 ul_ant=1

26.7.3 UE
To run the UE, use the following command:
sudo srsue ue.conf
Once the UE has been initialised you should see the following:
Opening 2 channels in RF device=uhd with args=type=x300,clock=external,

˓→sampling_rate=11.52e6,lo_freq_offset_hz=11.52e6,None
This will be followed by some information regarding the USRP. Once the cell has been found successfully
you should see the following:

Random Access Transmission: seq=17, tti=8494, ra-rnti=0x5
RRC Connected
Random Access Complete. c-rnti=0x3d, ta=3
Amarisoft Network (Amarisoft) 20/4/2021 23:32:40 TZ:105
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x7f,␣
˓→tti=8979

---------Signal----------|-----------------DL-----------------|-----------UL--
˓→---------
˓→brate bler
lte 1 -52 13 12 | 19 40 0.5 15k 0% 7.3 | 16 0.0 ␣
˓→10k 4%
nr 500 4 0 881m | 2 31 1.0 0.0 0% 0.0 | 17 0.0 ␣
˓→6.0k 0%
lte 1 -49 7 -4.8 | 28 40 0.5 1.4k 0% 7.3 | 0 0.0 ␣
˓→0.0 0%
nr 500 3 0 -5.9 | 27 35 1.0 1.3k 0% 0.0 | 28 0.0 ␣
˓→148k 0%
lte 1 -58 16 -3.7 | 28 40 0.5 1.4k 0% 7.3 | 0 0.0 ␣
˓→0.0 0%
nr 500 3 0 -7.7 | 27 35 1.0 1.3k 0% 0.0 | 28 0.0 ␣
˓→148k 0%
lte 1 -61 19 428m | 28 40 0.5 1.4k 0% 7.3 | 0 0.0 ␣
˓→0.0 0%
nr 500 4 0 2.2 | 27 30 1.4 67k 0% 0.0 | 28 28 ␣
˓→143k 0%
lte 1 -61 19 -507m | 28 40 0.5 1.4k 0% 7.3 | 0 0.0 ␣
˓→0.0 0%
nr 500 4 0 924m | 27 24 1.9 18M 0% 0.0 | 28 0.0 ␣
˓→3.7k 0%
lte 1 -61 19 3.8 | 28 40 0.5 1.4k 0% 7.3 | 0 0.0 ␣
˓→0.0 0%
26.7. Usage 189


nr 500 4 0 3.5 | 27 24 1.9 18M 0% 0.0 | 0 0.0 ␣
˓→ 0.0 0%
lte 1 -61 19 3.8 | 28 40 0.5 1.4k 0% 7.3 | 0 0.0 ␣
˓→0.0 0%
nr 500 4 0 3.1 | 27 24 1.9 18M 0% 0.0 | 0 0.0 ␣
˓→0.0 0%
To confirm the UE successfully connected, you should see the following on the console output of the
eNB:

----DL----------------------- --UL-----------------------------
˓→-------------------
UE_ID CL RNTI C cqi ri mcs retx txok brate snr puc1 mcs rxko rxok brate ␣
˓→ #its phr pl ta
1 000 003d 1 15 1 15.0 0 16 5.58k 15.4 34.7 18.8 3 13 5.27k ␣
˓→1/3.7/6 31 38 0.0
3 002 4601 1 15 1 27.0 0 1 320 36.2 - 27.7 0 87 64.0k ␣
˓→1/2.1/4 - - -0.3
1 000 003d 1 15 1 28.0 0 4 1.42k 16.2 34.8 20.0 1 1 420 ␣
˓→1/3.5/6 31 38 0.0
3 002 4601 1 15 1 27.0 0 4 1.28k 28.1 - 28.0 0 200 148k ␣
˓→2/2.1/3 - - -0.3
1 000 003d 1 15 1 28.0 0 4 1.42k 16.1 34.8 - 0 0 0 ␣
˓→ - 31 38 0.0
3 002 4601 1 15 1 27.9 0 1037 16.8M 29.9 - 27.9 1 21 16.1k ␣
˓→1/2.3/5 - - -0.3
1 000 003d 1 15 1 28.0 0 4 1.42k 16.3 35.2 - 0 0 0 ␣
˓→ - 31 38 0.0
3 002 4601 1 15 1 27.9 5 1120 18.3M 29.9 - - 0 0 0 ␣
˓→ - - - -
1 000 003d 1 15 1 28.0 0 4 1.42k 16.0 34.8 - 0 0 0 ␣
˓→ - 31 38 0.0
3 002 4601 1 15 1 27.9 0 1125 18.4M 29.9 - - 0 0 0 ␣
˓→ - - - -

26.7.4 srsGUI Support
srsGUI is also supported for use with the UE in NSA mode. An example of the plots produced can be
seen above.
To enable srsGUI, see here.
Note: If you have already built srsRAN 4G without srsGUI support, you must re-do so after srsGUI has
been built.
26.7.5 Understanding the console Trace
The console trace output from the UE contains useful metrics by which the state and performance of the
UE can be measured. The traces can be activated by pressing t+Enter after UE has started. The following
metrics are given in the console trace:
---------Signal----------|-----------------DL-----------------|-----------UL--
˓→---------
˓→brate bler
The following gives a brief description of which each column represents:

• RAT: This is a NSA specific column. It indicates the carrier for which the information is displayed.
• PCI: Physcial Cell ID
• RSRP: Reference Signal Receive Power (dBm)
• PL: Pathloss (dB)
• CFO: Carrier Frequency Offset (Hz)
• MCS: Modulation and coding scheme (0-28)
• SNR: Signal-to-Noise Ratio (dB)
• ITER: Average number of turbo decoder (LTE) or LDPC (NR) iterations
• BRATE: Bitrate (bits/sec)
26.7. Usage 191

• BLER: Block error rate

• TA_US: Timing advance (us)
• BUFF: Uplink buffer status - data waiting to be transmitted (bytes)
The UE currently doesn’t support NR cell search and cell measurements. It therefore uses a pre-
configured physical cell id (PCI) to send artificial NR cell measurements to the eNB. The reported PCI
in those measurements is 500 by default (default value in Amarisoft configurations). If the selected PCI
for the cell of interest is different, the value can we overwritten with:
$ ./srsue/src/srsue --rrc.nr_measurement_pci=140
Or by updating the [rrc] options in the config file:
[rrc]
nr_measurement_pci = 140

Srslte Docs

Uploaded by

Copyright:

Available Formats

Srslte Docs

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Srslte Docs

Uploaded by

Copyright:

Available Formats

srsRAN 4G Documentation

[’Software Radio Systems’]

Feb 22, 2023

8 LTE Setup Guide 21

10 eNodeB User Manual 39

11 EPC User Manual 53

12 srsRAN 4G with ZMQ Virtual Radios 60

14 Intra-eNB & S1 Handover 78

15 Carrier Aggregation 101

16 C-V2X Signalling 104

17 eMBMS End-to-End 109

18 NB-IoT Signalling 112

19 srsRAN 4G on Raspberry Pi 4 119

20 Hardware Options 126

24 5G NSA End-to-End 159

25 5G NSA COTS UE 169

26 5G NSA srsUE 182

srsRAN 4G is an open-source 4G software radio suite from SRS.

Get srsRAN 4G installed on your computer:

Get a network up and running:

Read the user manuals:

Read the srsRAN 4G Application Notes:

Take a look at the source code:

Learn about the team behind srsRAN 4G:

Join our mailing list for news and user support:

• 36 Mbps DL in 10 MHz SISO configuration

The srsENB LTE eNodeB includes the following features:

4 Chapter 2. srsRAN 4G Features

4.1 Which Installation Should I Use?

4.2 Package Installation

The srsRAN 4G software suite can be installed using packages on Ubuntu:

sudo add-apt-repository ppa:softwareradiosystems/srsran_4g

Package installs are also available for other distributions.

4.3 Installation from Source

8 Chapter 4. Installation Guide

sudo apt-get install build-essential cmake libfftw3-dev libmbedtls-dev␣

dnf install cmake fftw3-devel mbedtls-devel lksctp-tools-devel libconfig-

Download and build srsRAN 4G:

git clone https://github.com/srsRAN/srsRAN_4G.git

Install srsRAN 4G:

sudo make install

4.3. Installation from Source 9

4.4 Getting Support

10 Chapter 4. Installation Guide

– Improved interoperability of srsUE in NSA mode

12 Chapter 5. Release Notes

– EVM and EPRE measurements

– Carrier Aggregation support for srsUE

14 Chapter 5. Release Notes

∗ Changed and cleaned DCI blind search API

16 Chapter 5. Release Notes

6.1.2 2. How do I complete and submit the CLA?

6.1.3 3. How will my contributions to srsRAN 4G be used?

7.1 Building with Debug Symbols

git clone https://github.com/srsran/srsran_4g.git

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ../

7.2 Examining PCAPs with Wireshark

LTE SETUP GUIDE

8.1 Baseline Hardware Requirements