Commit 7dd91db2 authored by Raphael Defosseux's avatar Raphael Defosseux

Merge remote-tracking branch 'origin/issue414_doc' into develop_integration_2019_w13

parents cce291c5 c7d7f88d
# OAI build procedures
## soft modem Build script
oai EPC is developed in a distinct project with it's own [documentation](https://github.com/OPENAIRINTERFACE/openair-cn/wiki) , it is not described here. OAI UE and eNodeB sources can be downloaded from the Eurecom [gitlab repository](./GET_SOURCES.md). Sources come with a build script [build_oai](../cmake_targets/build_oai) located at the root of the `openairinterface5g/cmake_targets` directory. This script is developed to build the oai binaries (executables,shared libraries) for different hardware platforms, and use cases.
the main oai binaries, which are tested by the Continuous Integration process are:
- The LTE UE: `lte-uesoftmodem`
- The LTE eNodeB: `lte-softmodem`
- The PHY simulators: `dlsim` and `ulsim`
The build system for OAI uses [cmake](https://cmake.org/) which is a tool to generate makefiles. The `build_oai` script is a wrapper using cmake, make and standard linux shell commands to ease the oai build and use . The file describing how to build the executables from source files is the [CMakeLists.txt](../cmake_targets/CMakeLists.txt), it is used as input by cmake to generate the makefiles.
The oai softmodem supports many use cases, and new ones are regularly added. Most of them are accessible using the configuration file or the command line options and continuous effort is done to avoid introducing build options as it makes tests and usage more complicated than run-time options. The following functionalities, originally requiring a specific build are now accessible by configuration or command line options:
- s1, noS1
- all simulators, with exception of PHY simulators, which are distinct executables.
Calling the `build_oai` script with the -h option gives the list of all available options, but a process to simplify and check the requirements of all these options is on-going. Check the
[table]: BUILD.md "`build_oai` options"
at the end of this page to know the status of `buid_oai` options which are not described hereafter.
## building PHY simulators
detailed information about these simulators can be found [in this dedicated page](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/OpenAirLTEPhySimul
## building UE and eNodeB executables
After downloading the source files, a single build command can be used to get the binaries supporting all the oai softmodem use cases (UE and eNodeB):
```
cd <your oai installation directory>/openairinterface5g/
source oaienv
cd ../cmake_targets/
./build_oai -I -w USRP --eNB --UE
```
- The -I option is to install pre-requisites, you only need it the first time you build the softmodem or when some oai dependencies have changed.
- The -w option is to select the radio head support you want to include in your build. Radio head support is provided via a shared library, which is called the "oai device" The build script creates a soft link from `liboai_device.so` to the true device which will be used at run-time (here the USRP one,`liboai_usrpdevif.so` . USRP is the only hardware tested today in the Continuous Integration process.
- --eNB is to build the `lte-softmodem` executable and all required shared libraries
- --UE is to build the `lte-uesoftmodem` executable and all required shared libraries
You can build the eNodeB and the UE separately, you may not need both of them depending on your oai usage.
After completing the build, the binaries are available in the `cmake_targets/lte_build_oai/build` directory. A copy is also available in the `target/bin` directory, with all binaries suffixed by the 3GPP release number, today .Rel14 by default. It must be noticed that the option for building for a specific 3GPP release number is not tested by the CI and may be removed in the future.
## building optional binaries
### Telnet server
​ The telnet server can be built with the --build-telnet option, after building the softmodem or while building it.
`./build_oai -I -w USRP --eNB --UE --build-telnetsrv`
​ or
`./build_oai --build-telnetsrv`
### USRP record player
​ The USRP record player today needs a specific build. Work to make it available as a run time option is under consideration
## `build_oai` options
| Option | Status | Description |
| ----------------------------------------------------------- | ------------------------------------------- | :----------------------------------------------------------- |
| -h | maintained | get help |
| -c | maintained | erase all previously built files for this target before starting the new build. |
| -C | maintained, needs improvement | erase all previously built files for any target before starting the new build. |
| --verbose-compile | maintained | |
| --cflags_processor | maintained | used to pass options to the compiler |
| --clean-kernel | unknown | no code in the script corresponding to this option |
| --install-system-files | maintained | install oai built binaries in linux system files repositories |
| -w | maintained and tested in CI for USRP device | build corresponding oai device and create the soft link to enforce this device usage at run-time |
| -t | maintained | build the specified transport library, which is used in some simulators and in non monolithic eNodeB deployments. Now of little interest as transport library build is enforced when building the eNodeB. |
| --phy_simulators | maintained, tested in CI | build all PHY simulators, a set of executables allowing unitary tests of LTE channel implementation within oai. |
| --core_simulators | | |
| -s | | |
| --run-group | | |
| -I | maintained, tested in CI | install external dependencies before starting the build |
| --install-optional-packages | maintained | install optional packages, useful for developing and testing. look at the |
| | | check_install_additional_tools function in cmake_targets/tools/build_helper script to get the list |
| -g | maintained | build binaries with gdb support. |
| --eNB | maintained and tested in CI | build `lte-softmodem` the LTE eNodeB |
| --UE | maintained and tested in CI | build `lte-uesoftmodem` the LTE UE |
| --usrp-recplay | maintained | build with support for the record player. Implementation will be soon reviewed to switch to a run-time option. |
| --build-telnet | maintained | build the telnet server shared library, which can then be loaded at run time via the --telnetsrv command line option. |
| --build-msc | unknown | build the msc shared library, which can then be loaded at run time via the --msc command line option. msc is a tracing utility which status is unknown. |
| --UE-conf-nvram | | |
| --UE-gen-nvram | | |
| -r | unknown, to be removed | specifies which 3GPP release to build for. Only the default (today rel14) is tested in CI and it is likely that future oai release will remove this option |
| -V | deprecated | Used to build with support for synchronization diagram utility. This is now available via the T-Tracer and is included if T-Tracer is not disabled. |
| -x | deprecated | Used to build with support for embedded signal analyzer. This is now available via the T-Tracer and is included if T-Tracer is not disabled. |
| --noS1 | deprecated, to be removed | build noS1 version of oai softmodem binaries. noS1 allows running oai eNodeB and UE without an LTE core network (EPC). This functionality is now available via a run-time option. |
| --build-doxygen | unknown | build doxygen documentation, many oai source files do not include doxygen comments |
| --disable-deadline --enable-deadline --disable-cpu-affinity | deprecated | These options were used to activate or de-activate specific code depending on the choice of a specific linux scheduling mode. This has not been tested for a while and should be implemented as configuration options |
| --disable-T-Tracer | maintained, to be tested | Remove T_Tracer and console LOG messages except error messages. |
| --disable-hardware-dependency | | |
| --ue-autotest-trace --ue-timing --ue-trace | deprecated | Were used to enable conditional code implementing debugging messages or debugging statistics. These functionalities are now either available from run-time options or not maintained. |
| --disable-log | deprecated, to be removed | Was used to disable LOG messages, replaced by `--disable-T-Tracer` build option to remove tracing code from the build or `--T-stdout 0` run time option to redirect LOG messages to T-Tracer client interface. |
| --ue-nas-use-tun | deprecated to be removed | Usage of tun in place of specific kernel modules is now a run time option. `--nokrnmod 0` option disable the default behavior which is to use tun to send or receive ip packets to/from the linux ip stack. |
| --build-eclipse | unknown | |
| --basic-simulator | deprecated tested in CI | builds the basic simulator device. Now of little interest as this device build is enforced when building the eNodeB and it can be used at run time with the `--basicsim` option. More over the rf simulator is an enhanced basic simulator. |
| --rfsimulator | maintained | builds the rf simulator device. Now of little interest as this device build is enforced when building the eNodeB and it can be used at run time with the `--rfsim` option. |
| | | |
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[running the oai softmodem ](RUNMODEM.md)
......@@ -195,3 +195,10 @@ The NAS layer is based on **3GPP 24.301** and implements the following functions
- EMM attach/detach, authentication, tracking area update, and more
- ESM default/dedicated bearer, PDN connectivity, and more
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem build procedure](BUILD.md)
[running the oai softmodem ](RUNMODEM.md)
# The OpenAirInterface repository
The OpenAirInterface software can be obtained from our gitLab
server. You will need a git client to get the sources. The repository
is currently used for main developments.
## Prerequisite
You need to install the subversion/git using the following commands:
```shell
sudo apt-get update
sudo apt-get install subversion git
```
## Using EURECOM Gitlab
The [openairinterface5g repository](https://gitlab.eurecom.fr/oai/openairinterface5g.git)
holds the source code for (eNB RAN + UE RAN).
For legal issues (licenses), the core network (EPC) source code is now moved away from
the above openairinterface5g git repository. This EPC code is now splitted into two git
projects ([openair-cn](https://gitlab.eurecom.fr/oai/openair-cn.git) with apache license
and [xtables-addons-oai](https://gitlab.eurecom.fr/oai/xtables-addons-oai.git) with GPL license).
Configure git with your name/email address (only important if you are developer and want to checkin code to Git):
```shell
git config --global user.name "Your Name"
git config --global user.email "Your email address"
```
- Add a certificate from gitlab.eurecom.fr to your Ubuntu 14.04 installation:
```shell
echo -n | openssl s_client -showcerts -connect gitlab.eurecom.fr:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt
```
- Disable certificate check completely if you do not have root access to /etc/ssl directory
```shell
git config --global http.sslverify false
```
### In order to checkout the Git repository (for OAI Users without login to gitlab server)
Checkout RAN repository (eNB RAN + UE RAN):
```shell
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
```
Checkout EPC (Core Network) repository:
```shell
git clone https://gitlab.eurecom.fr/oai/openair-cn.git
```
Optionally (openair-cn build script can install it for you):
```shell
git clone https://gitlab.eurecom.fr/oai/xtables-addons-oai.git
```
### In order to checkout the Git repository (for OAI Developers/admins with login to gitlab server)
Please send email to {openair_tech (AT) eurecom (DOT) fr} to be added to the repository
as a developer (only important for users who want to commit code to the repository). If
you do not have account on gitlab.eurecom.fr, please register yourself to gitlab.eurecom.fr.
* Checkout with using ssh keys:
* You will need to put your ssh keys in https://gitlab.eurecom.fr/profile/keys
to access to the git repo. Once that is done, checkout the git repository using:
* `git clone git@gitlab.eurecom.fr:oai/openairinterface5g.git`
* Checkout with user name/password prompt:
* `git clone https://YOUR_USERNAME@gitlab.eurecom.fr/oai/openairinterface5g.git`
* `git clone https://YOUR_USERNAME@gitlab.eurecom.fr/oai/openair-cn.git`
* `git clone https://YOUR_USERNAME@gitlab.eurecom.fr/oai/xtables-addons-oai.git` (optional, openair-cn build script can do it for you)
## Which branch to checkout?
On the RAN side:
* **master**: This branch is targeted for the user community. Since January 2019, it is also subject to a Continuous Integration process. The update frequency is about once every 2-3 months. We are also performing bug fixes on this branch.
* **develop**: This branch contains recent commits that are tested on our CI test bench. The update frequency is about once a week.
Please see the work flow and policies page :
https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/oai-policies-home
you can find the latest stable tag release here :
https://gitlab.eurecom.fr/oai/openairinterface5g/tags
The tag naming conventions are :
- On `master` branch: **v1.`x`.`y`** where
* `x` is the minor release number, incremented every 2-3 months when we are merging `develop` into `master` branch.
* `y` is the maintenance number, starting at 0 when we do a minor release and being incremented when a bug fix is incorporated into `master` branch.
- On `develop` branch **`yyyy`.w`xx`**
* `yyyy` is the calendar year
* `xx` the week number within the year
<table style="border-collapse: collapse; border: none;">
<tr style="border-collapse: collapse; border: none;">
<td style="border-collapse: collapse; border: none;">
<a href="http://www.openairinterface.org/">
<img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
</img>
</a>
</td>
<td style="border-collapse: collapse; border: none; vertical-align: center;">
<b><font size = "5">Open Air LTE Emulation</font></b>
</td>
</tr>
</table>
This page is valid for the develop branch
# Table of Contents: #
* [How to build the eNB and the UE](#build)
* [How to run an eNB built with the noS1 option](#run-noS1-eNB)
* [How to run a UE built with the noS1 option](#run-noS1-UE)
* [Continuous Integration notes](#CInote)
* [How to ping an eNB from a UE and vice versa (with the noS1 option)](#noS1-pinging)
The old oaisim is dead! Long live oaisim! :)
If you are looking for a description of the old oaisim (which is still available in some branches/tags), please see [here](OpenAirLTEEmulation) and [here](how-to-run-oaisim-with-multiple-ue).
oaisim has been scraped and replaced by the same programs that are used for the real-time operation, `lte-softmodem` and `lte-uesoftmodem`. The latter also now includes an optional channel model, just like oaisim did.
# <a name="build">[How to build the eNB and the UE](BUILD.md)</a>
The following paragraph explains how to run the L1 simulator in noS1 mode and using the oai kernel modules.
# <a name="run-noS1-eNB">How to run an eNB with the noS1 option</a>
Modify the configuration file for IF4p5 fronthaul, `/openairinterface5g/ci-scripts/conf_files/rcc.band7.nos1.simulator.conf`, and replace the loopback interface with a physical ethernet interface and the IP addresses to work on your network. Copy your modifications to a new file, let's call YYY.conf the resulting configuration file.
Run lte-softmodem as usual with this configuration.
```bash
$ source oaienv
$ cd cmake_targets/tools
$ sudo -E ./init_nas_nos1 eNB
$ cd ../lte_build_oai/build
$ sudo -E ./lte-softmodem -O YYY.conf --noS1 --nokrnmod 0
```
# <a name="run-noS1-UE">How to run a UE with the noS1 option</a>
Similarly modify the example configuration file in `/openairinterface5g/ci-scripts/conf_files/rru.band7.nos1.simulator.conf` and replace loopback interface and IP addresses. Copy your modifications to a new file, let's call XXX.conf the resulting configuration file.
Run it like:
```bash
$ source oaienv
$ cd cmake_targets/tools
$ sudo -E ./init_nas_nos1 UE
$ cd ../lte_build_oai/build
$ sudo ./lte-uesoftmodem -O XXX.conf -r 25 --siml1 --noS1 --nokrnmod 0
```
That should give you equivalent functionality to what you had with oaisim including noise and RF channel emulation (path loss / fading, etc.). You should also be able to run multiple UEs.
# <a name="CInote">Continuous Integration notes</a>
The CI currently tests the noS1 build option with one eNB and one UE in the following scenarios:
* pinging one UE from one eNB
* pinging one eNB from one UE
* iperf download between one eNB and one UE
* iperf upload between one eNB and one UE
* all the above tests are done in FDD 5Mhz mode.
# <a name="noS1-pinging">How to ping an eNB from a UE and vice versa (with the noS1 option)</a>
Once your eNB and UE (built with the noS1 option) are running and synchronised, you can ping the eNB from the UE with the following command:
```bash
ping -I oai0 -c 20 $eNB_ip_addr
```
where $eNB_ip_addr is the IP address of your eNB.
Similarly, you can ping the UE from the eNB.
The IP adresses of the eNB and the UE are set up by the init_nas_nos1 program and should have the following values:
* eNB_ip_addr set to 20 10.0.1.1
* ue_ip_addr set to 20 10.0.1.2
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
<table style="border-collapse: collapse; border: none;">
<tr style="border-collapse: collapse; border: none;">
<td style="border-collapse: collapse; border: none;">
<a href="http://www.openairinterface.org/">
<img src="../images/oai_final_logo.png" alt="" border=3 height=50 width=150>
</img>
</a>
</td>
<td style="border-collapse: collapse; border: none; vertical-align: center;">
<b><font size = "5">L2 nFAPI Simulator Usage</font></b>
</td>
</tr>
</table>
This simulator allows to test L2 and above Layers using the nFAPI interface.
**This simulator is available starting the `v1.0.0` release on the `master` branch.**
Currently the only validated deployment by CI and developers is *with S1 interface and eNB / UEs are on the same machine*.
Others deployments will be supported later after bug fixes and validation in the CI process.
1. [With S1 -- eNB and UE on same machine](L2NFAPI_S1.md)
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
<table style="border-collapse: collapse; border: none;">
<tr style="border-collapse: collapse; border: none;">
<td style="border-collapse: collapse; border: none;">
<a href="http://www.openairinterface.org/">
<img src="../images/oai_final_logo.png" alt="" border=3 height=50 width=150>
</img>
</a>
</td>
<td style="border-collapse: collapse; border: none; vertical-align: center;">
<b><font size = "5">L2 nFAPI Simulator (with S1 / same machine deployment)</font></b>
</td>
</tr>
</table>
## Table of Contents ##
1. [Environment](#1-environment)
2. [Prepare the EPC](#2-prepare-the-epc)
3. [Retrieve the OAI eNB-UE source code](#3-retrieve-the-oai-enb-ue-source-code)
4. [Setup of the USIM information in UE folder](#4-setup-of-the-usim-information-in-ue-folder)
5. [Setup of the Configuration files](#5-setup-of-the-configuration-files)
1. [The eNB Configuration file](#51-the-enb-configuration-file)
2. [The UE Configuration file](#52-the-ue-configuration-file)
6. [Bring Up a second loopback interface](#6-bring-up-a-second-loopback-interface)
7. [Build the eNB](#7-build-the-enb)
8. [Build the UE](#8-build-the-ue)
9. [Initialize the NAS UE Layer](#9-initialize-the-nas-ue-layer)
10. [Start the eNB](#10-start-the-enb)
11. [Start the UE](#11-start-the-ue)
12. [Test with ping](#12-test-with-ping)
13. [Limitations](#13-limitations)
# 1. Environment #
2 servers are used in this deployment. You can use Virtual Machines instead of each server; like it is done in the CI process.
* Machine A contains the EPC.
* Machine B contains the OAI eNB and the OAI UE(s)
Example of L2 nFAPI Simulator testing environment:
<img src="../l2-nfapi-simulator/L2-sim-single-server-deployment.png" alt="" border=3>
Note that the IP addresses are indicative and need to be adapted to your environment.
# 2. Prepare the EPC #
Create the environment for the EPC and register all **USIM** information into the **HSS** database.
If you are using OAI-EPC ([see on GitHub](https://github.com/OPENAIRINTERFACE/openair-cn)), build **HSS/MME/SPGW** and create config files.
# 3. Retrieve the OAI eNB-UE source code #
The eNB and the UE executables will compiled into 2 separate folders on the same machine `B`.
```bash
$ ssh sudousername@machineB
$ git clone https://gitlab.eurecom.fr/oai/openairinterface5g/ enb_folder
$ cd enb_folder
$ git checkout -f v1.0.0
$ cd ..
$ cp -Rf enb_folder ue_folder
```
# 4. Setup of the USIM information in UE folder #
```bash
$ ssh sudousername@machineB
$ cd ue_folder
# Edit openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf with your preferred editor
```
Edit the USIM information within this file in order to match the HSS database. They **HAVE TO** match:
* PLMN+MSIN and IMSI of users table of HSS database **SHALL** be the same.
* OPC of this file and OPC of users table of HSS database **SHALL** be the same.
* USIM_API_K of this file and the key of users table of HSS database **SHALL** be the same.
When testing multiple UEs, it is necessary to add other UEs information like described below for 2 Users. Only UE0 (first UE) information is written in the original file.
```
UE0:
{
USER: {
IMEI="356113022094149";
MANUFACTURER="EURECOM";
MODEL="LTE Android PC";
PIN="0000";
};
SIM: {
MSIN="0000000001"; // <-- Modify here
USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";
OPC="e734f8734007d6c5ce7a0508809e7e9c";
MSISDN="33611123456";
};
...
};
// Copy the UE0 and edit
UE1: // <- Edit here
{
USER: {
IMEI="356113022094149";
MANUFACTURER="EURECOM";
MODEL="LTE Android PC";
PIN="0000";
};
SIM: {
MSIN="0000000002"; // <-- Modify here
USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";
OPC="e734f8734007d6c5ce7a0508809e7e9c";
MSISDN="33611123456";
};
...
};
```
You can repeat the operation for as many users you want to test with.
# 5. Setup of the Configuration files #
**CAUTION: both proposed configuration files resides in the ci-scripts realm. You can copy them but you CANNOT push any modification on these 2 files as part of an MR without informing the CI team.**
## 5.1. The eNB Configuration file ##
```bash
$ ssh sudousername@machineB
$ cd enb_folder
# Edit ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf with your preferred editor
```
First verify the nFAPI interface setup on the 2nd loopback interface.
```
MACRLCs = (
{
num_cc = 1;
local_s_if_name = "lo:"; // <-- HERE
remote_s_address = "127.0.0.1"; // <-- HERE
local_s_address = "127.0.0.2"; // <-- HERE
local_s_portc = 50001;
remote_s_portc = 50000;
local_s_portd = 50011;
remote_s_portd = 50010;
tr_s_preference = "nfapi";
tr_n_preference = "local_RRC";
}
);
```
If you are testing more than 16 UEs, a proper setting on the RUs is necessary. **Note that this part is NOT present in the original configuration file**.
```
RUs = (
{
local_rf = "yes"
nb_tx = 1
nb_rx = 1
att_tx = 20
att_rx = 0;
bands = [38];
max_pdschReferenceSignalPower = -23;
max_rxgain = 116;
eNB_instances = [0];
}
);
```
Last, the S1 interface shall be properly set.
```
////////// MME parameters:
mme_ip_address = ( { ipv4 = "CI_MME_IP_ADDR"; // replace with 192.168.10.20
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
NETWORK_INTERFACES :
{
ENB_INTERFACE_NAME_FOR_S1_MME = "ens3"; // replace with the proper interface name
ENB_IPV4_ADDRESS_FOR_S1_MME = "CI_ENB_IP_ADDR"; // replace with 192.168.10.10
ENB_INTERFACE_NAME_FOR_S1U = "ens3"; // replace with the proper interface name
ENB_IPV4_ADDRESS_FOR_S1U = "CI_ENB_IP_ADDR"; // replace with 192.168.10.10
ENB_PORT_FOR_S1U = 2152; # Spec 2152
ENB_IPV4_ADDRESS_FOR_X2C = "CI_ENB_IP_ADDR"; // replace with 192.168.10.10
ENB_PORT_FOR_X2C = 36422; # Spec 36422
};
```
## 5.2. The UE Configuration file ##
```bash
$ ssh sudousername@machineB
$ cd ue_folder
# Edit ci-scripts/conf_files/ue.nfapi.conf with your preferred editor
```
Verify the nFAPI interface setup on the loopback interface.
```
L1s = (
{
num_cc = 1;
tr_n_preference = "nfapi";
local_n_if_name = "lo"; // <- HERE
remote_n_address = "127.0.0.2"; // <- HERE
local_n_address = "127.0.0.1"; // <- HERE
local_n_portc = 50000;
remote_n_portc = 50001;
local_n_portd = 50010;
remote_n_portd = 50011;
}
);
```
# 6. Bring Up a second loopback interface #
A second loopback interface is used to connect the eNB and the UEs.
```bash
$ ssh sudousername@machineB
$ sudo ifconfig lo: 127.0.0.2 netmask 255.0.0.0 up
```
# 7. [Build OAI UE and eNodeB](BUILD.md) #
# 8. Initialize the NAS UE Layer #
Start the EPC on machine `A`.
```bash
$ ssh sudousername@machineA
# Start the EPC
```
# 9. Start the eNB #
In the first terminal (the one you used to build the eNB):
```bash
$ ssh sudousername@machineB
$ cd enb_folder/cmake_targets
$ sudo -E ./lte_build_oai/build/lte-softmodem -O ../ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf > enb.log 2>&1
```
If you don't use redirection, you can test but many logs are printed on the console and this may affect performance of the L2-nFAPI simulator.
We do recommend the redirection in steady mode once your setup is correct.
# 10. Start the UE #
In the second terminal (the one you used to build the UE):
```bash
$ ssh sudousername@machineB
$ cd ue_folder/cmake_targets
# Test 64 UEs, 64 threads in FDD mode
$ sudo -E ./lte_build_oai/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums-ue-thread 64 > ue.log 2>&1
# Test 64 UEs, 64 threads in TDD mode
$ sudo -E ./lte_build_oai/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums-ue-thread 64 -T 1 > ue.log 2>&1
# The "-T 1" option means TDD config
```
- The number of UEs can set by using `--num-ues` option and the maximum UE number is 255 (with the `--mu*` options, otherwise 16).
- The umber of threads can set with the `--nums-ue-thread`. This number **SHALL NOT** be greater than the number of UEs.
- How many UE that can be tested depends on hardware (server , PC, etc) performance in your environment.
# 11. Test with ping #
In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB:
```bash
$ ssh sudousername@machineA
# Ping UE0 IP address based on the EPC pool used: in this example:
$ ping -c 20 192.168.200.2
# Ping UE1 IP address based on the EPC pool used: in this example:
$ ping -c 20 192.168.200.4
```
# 12. Limitations #
Testing on the CI process is currently limited at time of writing. Improvements will be made soon.
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
[L2 nfapi simulator](L2NFAPI.md)
\ No newline at end of file
# Running OAI softmodem
After you have [built the softmodem executables](BUILD.md) you can set your default directory to the build directory `cmake_targets/lte_build_oai/build/` and start testing some use cases. Below, the description of the different oai functionalities should help you choose the oai configuration that suits your need.
## rf simulator
The rf simulator is a oai device replacing the radio heads (for example the USRP device). It allows connecting the oai UE and the oai eNodeB through a network interface carrying the time-domain samples, getting rid of over the air unpredictable perturbations. This is the ideal tool to check signal processing algorithms and protocols implementation.
It is planned to enhance this simulator with the following functionalities:
- Support for multiple UE connections,each UE being a `lte-uesoftmodem` instance.
- Support for multiple eNodeB for hand-over tests
- Support for channel modeling
This is an easy use-case to setup and test, as no specific hardware is required. The [rfsimulator page](../targets/ARCH/rfsimulator/README.md ) contains the detailed documentation.
## l2 nfapi simulator
This simulator connects a eNodeB and UEs through a nfapi interface, short-cutting the L1 layer. The objective of this simulator is to allow multi UEs simulation, with a large number of UEs (ideally up to 255 ) .Here to ease the platform setup, UEs are simulated via a single `lte-uesoftmodem` instance. Today the CI tests just with one UE and architecture has to be reviewed to allow a number of UE above about 16. This work is on-going.
As for the rf simulator, no specific hardware is required. The [L2 nfapi simlator page](L2NFAPI.md) contains the detailed documentation.
## l1 simulator
The l1 simulator is using the ethernet fronthaul protocol, as used to connect a RRU and a RAU to connect UEs and a eNodeB. UEs are simulated in a single `lte-uesoftmodem` process, as for the nfapi simulator.
The [L1 simulator page](L1SIM.md) contains the detailed documentation.
## noS1 mode
The noS1 mode is now available via the `--noS1`command line option. It can be used with simulators, described above, or when using oai with true RF boards. Only the oai UE can be connected to the oai eNodeB in noS1 mode.
By default the noS1 mode is using linux tun interfaces to send or receive ip packets to/from the linux ip stack. using the `--nokrnmod 0`option you can enforce kernel modules instead of tun.
noS1 code has been revisited, it has been tested with the rf simulator, and tun interfaces. More tests are on going and CI will soon include noS1 tests.
## Running with a true radio head
oai supports [number of deployment](FEATURE_SET.md) model, the following are tested in the CI:
1. [Monolithic eNodeB](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/HowToConnectCOTSUEwithOAIeNBNew) where the whole signal processing is performed in a single process
2. if4p5 mode, where frequency domain samples are carried over ethernet, from the RRU which implement part of L1(FFT,IFFT,part of PRACH), to a RAU
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
#General
## General
This is a RF simulator that allows to test OAI without a RF board.
It replaces a actual RF board driver.
As much as possible, it works like a RF board, but not in realtime: it can run faster than realtime if there is enough CPU or slower (it is CPU bound instead of real time RF sampling bound)
#build
## From build_oai
You can build it the same way, and together with actual RF driver
## build
Example:
```bash
./build_oai --ue-nas-use-tun --UE --eNB -w SIMU
```
It is also possible to build actual RF and use choose on each run:
```bash
./build_oai --ue-nas-use-tun --UE --eNB -w USRP --rfsimulator
```
Will build both the eNB (lte-softmodem) and the UE (lte-uesoftmodem)
We recommend to use the option --ue-nas-use-tun that is much simpler to use than the OAI kernel driver.
No specific build is required, use the [oai softmodem build procedure](../../../doc/BUILD.md)
## Add the rfsimulator after initial build
After any regular build, you can compile the driver
```bash
cd <the_compilation_dir_from_bouild_oai_script>/build
......@@ -35,16 +23,30 @@ It should the set to "enb" in the eNB
## 4G case
For the UE, it should be set to the IP address of the eNB
example:
```bash
sudo RFSIMULATOR=192.168.2.200 ./lte-uesoftmodem -C 2685000000 -r 50
sudo RFSIMULATOR=192.168.2.200 ./lte-uesoftmodem -C 2685000000 -r 50 --rfsim
```
For the eNodeB, use a valid configuration file setup for USRP board tests and start the softmodem as usual, but adding the `--rfsim` option.
```bash
sudo RFSIMULATOR=enb ./lte-softmodem -O <config file> --rfsim
```
Except this, the UE and the eNB can be used as it the RF is real
If you reach 'RA not active' on UE, be careful to generate a valid SIM
```bash
$OPENAIR_DIR/targets/bin/conf2uedata -c $OPENAIR_DIR/openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf -o .
```
This simulator can also be used with the `--noS1` option, in this case you must run the eNodeB and the UE on different PCs.
## 5G case
After regular build, add the simulation driver
(don't use ./build_oai -w SIMU until we merge 4G and 5G branches)
```bash
......@@ -62,7 +64,8 @@ sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem --numerology 1 -r 106 -C 3510000000
Of course, set the gNB machine IP address if the UE and the gNB are not on the same machine
In UE, you can add "-d" to get the softscope
#Caveacts
## Caveacts
Still issues in power control: txgain, rxgain are not used
no S1 mode is currently broken, so we were not able to test the simulator in noS1 mode
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment