Which Installation Should I Use?¶
srsLTE 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 srsLTE applications with USRP front-ends should use the package installation. Users who wish to modify srsLTE and/or use alternative RF front-ends such as limeSDR and BladeRF should install from source.
The srsLTE software suite can be installed using packages on Ubuntu:
sudo add-apt-repository ppa:srslte/releases sudo apt-get update sudo apt-get install srslte -y
Package installs are also available for other distributions.
Note, only the Launchpad packages for Ubuntu are maintained by SRS. Different distributions will maintain their own packages for srsLTE, which may or may not be up to date. Check the available version before installing to ensure you are using the desired version of srsLTE.
Fedora does not yet have support for a package installation of srsLTE.
Installation from Source¶
For example, on Ubuntu 18.04, one can install the required libraries with:
sudo apt-get install cmake libfftw3-dev libmbedtls-dev libboost-program-options-dev libconfig++-dev libsctp-dev
or on Fedora:
dnf install cmake fftw3-devel polarssl-devel lksctp-tools-devel libconfig-devel boost-devel
Note that depending on your flavor and version of Linux, the actual package names may be different.
RF front-end driver:
Download and build srsLTE:
git clone https://github.com/srsLTE/srsLTE.git cd srsLTE mkdir build cd build cmake ../ make make test
sudo make install sudo srslte_install_configs.sh user
This installs srsLTE and also copies the default srsLTE config files to the user’s home directory (~/.srs).
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 srsLTE without RF-hardware please see the ZeroMQ application note.
Baseline Hardware Requirements¶
The overall system requires 2 x RF-frontends and 2 x PCs with a Linux based OS. This can be broken down as follows:
Linux based PC
The UE will be instatiated 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 insantiated 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.
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.
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
you may just start all applications with their default parameters.
On machine 1, run srsEPC as follows:
Using the default configuration, this creates a virtual network interface named “srs_spgw_sgi” on machine 1 with IP 172.16.0.1. All connected UEs will be assigned an IP in this network.
Also on machine 1, but in another console, run srsENB as follows:
On machine 2, run srsUE as follows:
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:
If srsLTE is build from source, then preconfigured example use-cases can be found in the following folder:
The following list outlines some of the use-cases covered:
NB-IoT Cell Search
A UE capable of decoding PDSCH packets
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.