Skip to content

O
OpenXG UE
Commit 4e9e33d2 authored by Luhan Wang's avatar Luhan Wang
Browse files
Options

rm unnecessary files

parent bbee4d98
Hide whitespace changes
Inline Side-by-side
Showing with 0 additions and 537515 deletions
doc/5Gnas.md deleted 100644 → 0
View file @ bbee4d98
<style type="text/css" rel="stylesheet">
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
font-size: 13px;
line-height: 18px;
color: #fff;
background-color: #110F14;
}
h2 { margin-left: 20px; }
h3 { margin-left: 40px; }
h4 { margin-left: 60px; }
.func2 { margin-left: 20px; }
.func3 { margin-left: 40px; }
.func4 { margin-left: 60px; }
</style>
This tuto for 5G gNB NAS design
{: .text-center}
# source files
RRC/NR/nr_ngap_gNB.c: skeleton for interface with NGAP
NAS/COMMON/milenage.h: a simple milenage implementation, depend only on crypto library
NAS/COMMON/NR_NAS_defs.h: messages defined for NAS implemented in C: C struct, C enums and automatic conversion to labels for debug messages
NAS/COMMON/nr_common.c: 5G NAS common code between gNB and UE
UICC/usim_interface.c: UICC simulation for USIM messages
NAS/NR_UE/ue_process_nas.c: NAS code for UE
NAS/gNB/network_process_nas.c: NAS code for gNB running without 5GC
TEST/test5Gnas.c: unitary testing of NAS messages: encodes+decode a standard network entry, mixing code from UE and 5GC (or gNB in noCore)
# USIM simulation
A new USIM simulation, that parameters are in regular OAI config files
## To open the USIM
init_uicc() takes a parameter: the name of the block in the config file
In case we run several UEs in one process, the variable section name allows to make several UEs configurations in one config file.
The NAS implementation uses this possibility.
# UE side
UEprocessNAS() is the entry for all messages.
It decodes the message type and call the specific function for each messgae
## Identityrequest + IdentityResponse
When the UE receives the request, it stores the 5GC request parameters in the UE context ( UE->uicc pointer)
It calls "scheduleNAS", that would trigger a answer (seeing general archtecture, it will probly be a itti message to future RRC or NGAP thread).
When the scheduler wants to encode the answer, it calls identityResponse()
The UE search for a section in the config file called "uicc"
it encodes the NAS answer with the IMSI, as a 4G compatible authentication.
A future release would encode 5G SUPI as native 5G UICC.
## Authenticationrequest + authenticationResponse
When the UE receives the request, it stores the 5GC request parameters in the UE context ( UE->uicc pointer)
It calls "scheduleNAS", that would trigger a answer (seeing general archtecture, it will probly be a itti message to future RRC or NGAP thread).
When the scheduler wants to encode the answer, it calls authenticationResponse()
The UE search for a section in the config file called "uicc"
It uses the Milenage parameters of this section to encode a milenage response
A future release would encode 5G new authentication cyphering functions.
## SecurityModeCommand + securityModeComplete
When the UE receives the request it will:
Selected NAS security algorithms: store it for future encoding
Replayed UE security capabilities: check if it is equal to UE capabilities it sent to the 5GC
IMEISV request: to implement
ngKSI: Key set Indicator, similator to 4G to select a ciphering keys set
When the scheduler wants to encode the answer, it calls registrationComplete()
## registrationComplete
To be defined in UE, this NAS message is done after RRC sequence completes
# gNB side
gNB NGAP thread receives the NAS message from PHY layers
In normal mode, it send it to the core network with no decoding.
Here after, the gNB mode "noCore" processing in gNB: NGAP calls the entry function: processNAS() instead of forwarding the packet to the 5GC
## RRCModeComplete + Identityrequest
When the gNB completes RRC attach, it sends a first message to NGAP thread.
Normal processing sends NGAP initial UE message, in noCore mode, it should call: identityRequest() that encode the NAS identity request inside the gNB.
The gNB NGAP thread then should call the piece of code that forward the message to the UE as when it receives a NAS message from 5GC.
## All NAS coming from UE
When NGAP thread receives a NAS message from lower layers, it encapsulates it to forward it to the 5GC. In "noCore" mode it calls processNAS().
This function stores in the gNB the NAS data, then it should encode the next message (identity, authentication, security mode) or do nothing (registration complete).
<div class="panel panel-info">
**Note**
{: .panel-heading}
<div class="panel-body">
</div>
</div>
doc/BASIC_SIM.md deleted 100644 → 0
View file @ bbee4d98
<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">Running OAI Basic Simulator</font></b>
</td>
</tr>
</table>
This page is valid on the following branches:
- `master` starting from tag `v1.1.0`
- `develop` starting from tag `2019.w11`
# 1. Building the basic-simulator.
After the build simplification, the basic simulator is available directly from the standard build.
```bash
$ source oaienv
$ cd cmake_targets
$ ./build_oai --eNB --UE
```
Both eNB (lte-softmodem) and UE (lte-uesoftmodem) are present on `cmake_targets/ran_build/build` folder.
More details are available on the [build page](BUILD.md).
# 2. Running the basic simulator.
The basic 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 and having debug sessions without any HW radio equipment.
The main limitations are:
- A single OAI UE will connect to the OAI eNB
- No channel noise
## 2.1. Starting eNB
The basic simulator is able to run with a connected EPC or without any (the so-called "noS1" mode).
Example 1: running in FDD mode with EPC.
```bash
$ source oaienv
$ cd cmake_targets/ran_build/build
$ ENODEB=1 sudo -E ./lte-softmodem -O $OPENAIR_HOME/ci-scripts/conf_files/lte-fdd-basic-sim.conf --basicsim
```
Edit previously the `ci-scripts/conf_files/lte-fdd-basic-sim.conf` file to modify:
- `N_RB_DL` field to change the Bandwidth (25, 50, 100)
- `CI_MME_IP_ADDR` with the EPC IP address
- `CI_ENB_IP_ADDR` with the container (physical server, virtual machine, ...) on which you are executing the eNB soft-modem
Example 2: running in TDD mode without any EPC.
```bash
$ source oaienv
$ cd cmake_targets/ran_build/build
$ ENODEB=1 sudo -E ./lte-softmodem -O $OPENAIR_HOME/ci-scripts/conf_files/lte-tdd-basic-sim.conf --basicsim --noS1
```
## 2.2. Starting UE
Before starting the UE, you may need to edit the SIM parameters to adapt to your eNB configuration and HSS database.
The <conf> file to use for conf2uedate is `NAS/TOOLS/ue_eurecom_test_sfr.conf`
You need to set the correct OPC, USIM_API_K, MSIN (this is the end par of the IMSI), HPLMN (the front part of IMSI) to match values from HSS.
```bash
$ source oaienv
# Edit NAS/TOOLS/ue_eurecom_test_sfr.conf
$ cd cmake_targets/ran_build/build
$ ../../nas_sim_tools/build/conf2uedata -c $OPENAIR_HOME/NAS/TOOLS/ue_eurecom_test_sfr.conf -o .
$ sudo -E ./lte-uesoftmodem -C 2625000000 -r 25 --ue-rxgain 140 --basicsim [--noS1]
```
The `-r 25` is to use if in the conf file of the eNB you use N_RB_DL=25. Use 50 if you have N_RB_DL=50 and 100 if you have N_RB_DL=100.
The `-C 2625000000` is the downlink frequency. Use the same value as `downlink_frequency` in the eNB configuration file.
The `--noS1` is mandatory if you started the eNB in that mode.
# 3. Testing the data plane
# 3.1. In S1 mode
First we need to retrieve the IP address allocated to the OAI UE.
On the server that runs the UE:
```bash
$ ifconfig oaitun_ue1
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.2 P-t-P:192.172.0.2 Mask:255.255.255.0
...
```
`192.172.0.2` is the IP address that has been allocated by the SPGW in the EPC.
On the server that runs the EPC:
```bash
$ ping -c 20 192.172.0.2
--- 192.172.0.2 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19020ms
rtt min/avg/max/mdev = 13.241/18.999/24.208/2.840 ms
```
You can ping the EPC from the UE:
```bash
$ ping -I oaitun_ue1 -c 20 192.172.0.1
--- 192.172.0.1 ping statistics ---
...
20 packets transmitted, 20 received, 0% packet loss, time 19019ms
rtt min/avg/max/mdev = 13.015/18.674/23.738/2.917 ms
```
For DL iperf testing:
On the server that runs the UE.
```bash
$ iperf -B 192.172.0.2 -u -s -i 1 -fm -p 5001
```
On the server that runs the EPC.
```bash
$ iperf -c 192.172.0.2 -u -t 30 -b 10M -i 1 -fm -B 192.172.0.1 -p 5001
```
For UL iperf testing:
On the server that runs the EPC.
```bash
$ iperf -B 192.172.0.1 -u -s -i 1 -fm -p 5001
```
On the server that runs the UE.
```bash
$ iperf -c 192.172.0.1 -u -t 30 -b 2M -i 1 -fm -B 192.172.0.2 -p 5001
```
# 3.2. In noS1 mode
The IP addresses are fixed. But we can still retrieve them programmatically.
For the UE it is quite the same:
```bash
$ ifconfig oaitun_ue1
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.2 P-t-P:10.0.1.2 Mask:255.255.255.0
...
```
For the eNB:
```bash
$ ifconfig oaitun_enb1
oaitun_enb1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.1 P-t-P:10.0.1.1 Mask:255.255.255.0
...
```
Pinging like this:
```bash
$ ping -I oaitun_ue1 -c 20 10.0.1.1
$ ping -I oaitun_enb1 -c 20 10.0.1.2
```
And the same for iperf:
```bash
$ iperf -B 10.0.1.2 -u -s -i 1 -fm
$ iperf -c 10.0.1.2 -u -b 1.00M -t 30 -i 1 -fm -B 10.0.1.1
```
doc/BUILD.md deleted 100644 → 0
View file @ bbee4d98
<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">OAI Build Procedures</font></b>
</td>
</tr>
</table>
This page is valid on tags starting from **`2019.w09`**.
# Soft Modem Build Script
The OAI EPC is developed in a distinct project with it's own [documentation](https://github.com/OPENAIRINTERFACE/openair-epc-fed/wiki) , it is not described here.
OAI softmodem sources, which aim to implement 3GPP compliant UEs, eNodeB and gNodeB 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 5G UE: `nr-uesoftmodem`
- The LTE eNodeB: `lte-softmodem`
- The 5G gNodeB: `nr-softmodem`
- The LTE PHY simulators: `dlsim` and `ulsim`
- The 5G PHY simulators: `nr_dlschsim` `nr_dlsim` `nr_pbchsim` `nr_pucchsim` `nr_ulschsim` `nr_ulsim` `polartest` `smallblocktest`
`ulsim` `ldpctest`
Running the [build_oai](../cmake_targets/build_oai) script also generates some utilities required to build and/or run the oai softmodem binaries:
- `conf2uedata`: a binary used to build the UE data from a configuration file. The created file emulates the sim card of a 3GPP compliant phone.
- `nvram`: a binary used to build UE (IMEI...) and EMM (IMSI, registered PLMN) non volatile data.
- `rb_tool`: radio bearer utility
- `genids` T Tracer utility, used at build time to generate T_IDs.h include file. This binary is located in the [T Tracer source file directory](../common/utils/T) .
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 as the rfsimulator, the L2 simulator, 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
The PHY layer simulators (LTE and NR) can be built as follows:
```
cd <your oai installation directory>/openairinterface5g/
source oaienv
cd cmake_targets/
./build_oai -I --phy_simulators
```
After completing the build, the binaries are available in the cmake_targets/ran_build/build directory.
A copy is also available in the target/bin directory, with all binaries suffixed by the 3GPP release number, today **.Rel15**.
Detailed information about these simulators can be found [in this dedicated page](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/OpenAirLTEPhySimul)
# Building UEs, eNodeB and gNodeB 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 [eg]NodeB):
```
cd <your oai installation directory>/openairinterface5g/
source oaienv
cd cmake_targets/
./build_oai -I -w USRP --eNB --UE --nrUE --gNB
```
- 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. Note: for Ubuntu 20 use cmake_targets/install_external_packages.ubuntu20 instead!
- 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. The RF simulator[RF simulator](../targets/ARCH/rfsimulator/README.md) is implemented as a specific device replacing RF hardware, it can be specifically built using `-w SIMU` option, but is also built during any softmodem build.
- `--eNB` is to build the `lte-softmodem` executable and all required shared libraries
- `--gNB` is to build the `nr-softmodem` executable and all required shared libraries
- `--UE` is to build the `lte-uesoftmodem` executable and all required shared libraries
- `--nrUE` is to build the `nr-uesoftmodem` executable and all required shared libraries
You can build any oai softmodem executable separately, you may not need all of them depending on your oai usage.
After completing the build, the binaries are available in the `cmake_targets/ran_build/build` directory. A copy is also available in the `target/bin` directory, with all binaries suffixed by the 3GPP release number, today .Rel15.
When installing the pre-requisites, especially the `UHD` driver, you can now specify if you want to install from source or not.
- For `fedora`-based OS, it was already the case all the time. But now you can specify which version to install.
- For `ubuntu` OS, the Ettus PPA currently installs the following versions:
* `Ubuntu16.04`: --> version `3.15.0.0`
* `Ubuntu18.04`: --> version `4.1.0.0`
```bash
export BUILD_UHD_FROM_SOURCE=True
export UHD_VERSION=3.15.0.0
./build_oai -I -w USRP
```
The `UHD_VERSION` env variable `SHALL` be a valid tag (minus `v`) from the `https://github.com/EttusResearch/uhd.git` repository.
## Issue when building `nasmeh` module ##
A lot of users and contributors have faced the issue: `nasmesh` module does not build.
The reason is that the linux headers are not properly installed. For example:
```bash
$ uname -r
4.4.0-145-lowlatency
$ dpkg --list | grep 4.4.0-145-lowlatency | grep headers
ii linux-headers-4.4.0-145-lowlatency 4.4.0-145.171
```
In my example it is properly installed.
Check on your environment:
```bash
$ uname -r
your-version
$ dpkg --list | grep your-version | grep headers
$
```
Install it:
```bash
$ sudo apt-get install --yes linux-headers-your-version
```
On CentOS or RedHat Entreprise Linux:
```bash
$ uname -r
3.10.0-1062.9.1.rt56.1033.el7.x86_64
$ yum list installed | grep kernel | grep devel
kernel-devel.x86_64 3.10.0-1062.9.1.el7 @rhel-7-server-rpms
kernel-rt-devel.x86_64 3.10.0-1062.9.1.rt56.1033.el7
```
If your kernel is generic, install `kernel-devel` package: `sudo yum install kernel-devel`
In most case, your kernel is real-time. Install `kernel-rt-devel` package: `sudo yum install kernel-rt-devel`
# Building Optional Binaries
## Telnet Server
The telnet server can be built with the `--build-lib telnetsrv` option, after building the softmodem or while building it.
`./build_oai -I -w USRP --eNB --UE --build-lib telnetsrv`
or
`./build_oai --build-lib telnetsrv`
You can get documentation about the telnet server [here](common/utils/telnetsrv/DOC/telnetsrv.md)
## Other optional libraries
Using the help option of the build script you can get the list of available optional libraries. Those which haven't been mentioned above are known to need more tests and documentation.
`./build_oai --build-lib all` will build all available optional libraries.
# `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 | get compilation messages, as when running `make` or `gcc` directly. |
| --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 |
| --phy_simulators | maintained, tested in CI | build all PHY simulators, a set of executables allowing unitary tests of LTE and 5G 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 | Specifies the level of debugging options used to build the binaries. Available levels are `Release`, `RelWithDebInfo`, `MinSizeRe` and `Debug`. If -g is not specified, `Release` is used, if -g is used without any level, `Debug` is used. |
| -G | maintained | Display Cmake debugging messages |
| --eNB | maintained and tested in CI | build `lte-softmodem` the LTE eNodeB |
| --UE | maintained and tested in CI | build `lte-uesoftmodem` the LTE UE |
| --gNB | maintained and tested in CI | build `nr-softmodem` the 5G gNodeB |
| --nrUE | maintained and tested in CI | build `nr-uesoftmodem` the 5G UE |
| --usrp-recplay | deprecated | use the USRP configuration parameters to use the record player. |
| --build-lib | maintained | build optional shared library(ies), which can then be loaded at run time via command line option. Use the --help option to get the list of supported optional libraries. `all` can be used to build all available optional libraries. |
| --UE-conf-nvram | maintained | Specifies the path to the input file used by the conf2uedata utility. defaults to [NAS/TOOLS/ue_eurecom_test_sfr.conf](../NAS/TOOLS/ue_eurecom_test_sfr.conf) |
| --UE-gen-nvram | maintained | Specifies the path where the output file created by the conf2uedata utility will be placed. Defaults to `target/bin` |
| -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. |
| --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. |
| --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. |
| --build-eclipse | unknown | |
| | | |
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[running the oai softmodem ](RUNMODEM.md)
doc/F1-design.md deleted 100644 → 0
View file @ bbee4d98
<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">F1 split design</font></b>
</td>
</tr>
</table>
# 1. Introduction
We use OpenAirInterface source code, and it's regular deployment scheme.
F1 specification is in 3GPP documents: TS 38.470 header document and all documents listed in chapter 2 References of TS 38.470.
This document explains how the source code works.
Offered features and deployment instructions are described in:
https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/f1-interface
# 2. Common multi-threading architecture #
The CU and DU interfaces are based on ITTI threads (see oai/common/utils/ocp_itti/itti.md)
All OAI upper layers use the ITTI framework to run isolated threads dedicated to one feature.
The lower layers adopt case by case specific software architecture.
```mermaid
graph TD
Linux[configuration file] --> APP[gNB_app_task]
Socks[Linux UDP] --> GTP[nr_gtpv1u_gNB_task]
APP --> CU
APP --> DU
A[Linux SCTP] -->|sockets| SCTP(OAI itti thread TASK_SCTP)
SCTP-->|TASK_NGAP| NG[ngap_gNB_task]
NG-->|TASK_SCTP| SCTP
SCTP-->|TASK_DU_F1| DU[F1AP_DU_task]
SCTP-->|TASK_CU_F1| CU[F1AP_CU_task]
CU-->|TASK_RRC_GNB| RRC
RRC -->|non ITTI| PHY[OAI L1+L2]
RRC -->|API calls to create tunnels| GTP
PHY --> |user plane| GTP
CU --> |TASK_GTPV1_U| GTP
DU --> |TASK_GTPV1_U| GTP
```
A "task" is a Linux thread running infinite waiting loop on one ITTI queue
app task manages the initial configuration
sctp task mamanges the SCTP Linux sockets
CU code runs in the task F1AP_CU_task. It stores it's private data context in a static variable. No mutex is used, as the single interface to CU ITTI tast in incoming ITTI messages. CU task is a single ITTI queue, but multiple CU could exist in one Linux process, using the "instance id" (called "module id" also) to create separate contextual information for each CU instance.
DU code runs in the task F1AP_DU_task. The design is similar to CU task
All GTP-U tunnels are managed in a Linux Thread, that have partially ITTI design:
1. tunnel creation/deletion is by C API functions direct calls (a mutex protects it)
2. outgoing packets are pushed in a ITTI queue to the gtp thread
3. incoming packets are sent to the tunnel creator using a C callback (the callback function is given in tunnel creation order). The callback should not block
# 3. CU F1AP messages #
## startup
CU thread starts when the CU starts. It opens listening socket on F1AP_PORT_NUMBER by sending the appropriate message to TASK_SCTP.
It will accept the first incoming connection on this port
## F1 SETUP
DU has connected, and sent this message.
The CU receives, decode it and send relevant information to RRC thread by message F1AP_SETUP_REQ
## F1 SETUP response
RRC sends two messages to CU F1 task: the information to encode the F1 setup response and a second message to encode F1AP_GNB_CU_CONFIGURATION_UPDATE
Upon reception of these two messages the CU task encodes and sends the messages to the DU
## UE entry
When CCH channel decoding finds a new UE identity, it call rrc_gNB_generate_RRCSetup() that will send F1AP_DL_RRC_MESSAGE to the CU task.
The CU encodes and sends to DU DLRRCMessageTransfer
## UE attach/detach
When rrc_gNB_process_RRCReconfigurationComplete() occurs, the RRC sends to CU task the message F1AP_UE_CONTEXT_SETUP_REQ. The CU task encodes the F1 message UEContextSetup and send it to the DU over F1AP.
This function rrc_gNB_process_RRCReconfigurationComplete() also creates the GTP-U user plane bearers.
## F1AP incoming messages
SCTP tasks sends a ITTI message SCTP_DATA_IND to the CU task.
A array of functions pointers and the F1AP standard identifier "procedureCode", the CU calls the appropriate function
Hereafter the most significant messages processing
### CU_handle_F1_SETUP_REQUEST
Transcodes information to the same message toward RRC (F1AP_SETUP_REQ)
### CU_handle_INITIAL_UL_RRC_MESSAGE_TRANSFER
Transcodes information to the same message toward RRC (NR_RRC_MAC_CCCH_DATA_IND)
### CU_handle_UL_RRC_MESSAGE_TRANSFER
Encode and send data to PDCP (calling pdcp_data_ind ()) for processing UL data.
# DU F1 Messages
## Startup
The task "gNB app" after rzading the configuration file, sends a first message F1AP_SETUP_REQ to DU task
Using this message, the uniq DU task (Linux Thread) creates a DU instance context memory space, calls SCTP task to create a socket to the CU.
When it receives from the SCTP task the socket creation success, the DU task encodes+sends the F1 setup message to the CU.
## F1AP_INITIAL_UL_RRC_MESSAGE
When MAC layer push UL data to DU task, the DU sends to CU the message InitialULRRCMessageTransfer
## F1AP_UL_RRC_MESSAGE
In case of SRB bearer, the RLC layer use this message to push rlc bearer payload to DU task, that forward to CU
## pdcp_data_ind
This function call in RLC, when it is a DRB will be replaced by F1-U transport to CU
## F1AP incoming messages
SCTP tasks sends a ITTI message SCTP_DATA_IND to the DU task.
A array of functions pointers and the F1AP standard identifier "procedureCode", the DU calls the appropriate function
Hereafter the most significant messages processing
### DU_send_F1_SETUP_RESPONSE
Decode the CU message, then encode a message to TASK_GNB_APP. The thread "APP" extracts the system information block and reconfigure the DU with: du_extract_and_decode_SI(), configure_gnb_du_mac()
### DU_handle_gNB_CU_CONFIGURATION_UPDATE
No developped
### DU_handle_UE_CONTEXT_SETUP_REQUEST
Push data to RLC layer for transmisstion in DL (to the UE) by calling enqueue_rlc_data_req()
### DU_handle_DL_RRC_MESSAGE_TRANSFER
Depending on the content, adds UE context in DU low layers and/or send data to the UE with rlc_data_req()
# F1-U messages
The data path by itself doesn't make any difficulty:
1. for UL, rlc calls pdcp_data_ind (DRB) or sends a message to RRC (SRB). So, we can replace pdcp_data_ind() by du_pdcp_data_ind() that will push the message in the GTP tunnel. In CU, assuming the tunnel is in place, the right call back decapsulate the transport (cu_ul_recv()), then calls pdcp_data_ind() in CU
The SRB are sent in DU RRC tasks via itti F1AP_UL_RRC_MESSAGE (see above the processing)
2. For DL, pdcp (in CU for DRBs) calls rlc_data_req (by a decoupling queue and thread rlc_data_req_thread, so function du_rlc_data_req() or enqueue_rlc_data_req()). in DU, assuming the gtp-u tunnel exists, a reception call back (du_dl_recv()) decapsulate the gtp-u packet and calls du_rlc_data_req()
Hereafter the processing design, that doesn't require to setup a new context storage, as we can use the GTP-U internal tables: rnti+rb=>teid for outgoing gtp-u packets and teid=>rnti+rb for incoming gtp-u packets
In CU case, the DRB tunnel to DU and the tunnel on N3 have the same key (rnti, rb id), but they run in two different GTP-U instances.
Each instance binds on diffrent sockets.
For F1-U, both DU and CU binds on the full quadruplet (IP source, port source, IP destination, port destination) from the configuration file parameters:
local_s_address, remote_s_address,local_s_portd, remote_s_portd
These 4 values are in:
CU: at cell level (same level as nr_cellid parameter), they are read if tr_s_preference = "f1"; is set
DU: in block MACRLCs, if tr_n_preference = "f1"; is set in this block
## tunnels setup
In GTP-U, TS 29.281 specifies a option header (NR RAN Container This extension header may be transmitted in a G-PDU over the X2-U, Xn-U and F1-U user plane interfaces), but it is not mandatory optional header (as is the N3 one).
So, we can use this header a something reliable with other vendors implementation.
In DL, we need to associate the packet with: rnti, rb (radio bearer) and "mui" (a OAI internal id that is optional and may be removed soon) to call rlc_data_req()
In UL, we need also the RNTI, the rb
So, we need to create a gtp-u tunnel for each rb over F1, then manage in CU and DU the association between a uniq TEid and the pair(rnti, rb). This is already what we have in existing OAI GTP-U layer interface.
In F1AP, for each "DRB to Be Setup Item IEs", we have a field TNL (transport network layer) to set a specific GTP tunnel (@IP, TEid, udp port is always 2152). This is the same for each message related to DRBs. (F1AP carries the SRB payload inside F1AP).
So, For each F1AP containing DRB setup/modification/deletion, the related GTP-U tunnels will be modified one to one.
The exception is the intialisation of new tunnel: in the call to tunnel creation, we need to send the remote TEID, but we don't know yet if we are the initial source. In this case, we issue a dummy (0xFFFF) remote teid; when we receive the remote answer, we get the source teid, that we can inform GTP-U with (using update tunnel).
## processing on GTP-U incoming message
Du_dl_recv() or cu_ul_recv() are called because we have set this callbacks in creat/update tunnel calls to gtp-u. As gtp-u maintains a pair(rnti,rbid) associated to each tunnel, the functions can be very simple stateless callback that calls pdcp_data_ind() or rlc_data_req() to get back in normal processing path
## CU/DU outgoing
DU rlc north output goes to du_pdcp_data_ind() that push a outgoing packet request to gtp-u, using the rnti+rb as ids. GTP-U must have the tunnel existing, then it simply implement the same as in N3 for exemple.
CU pdcp south output calls cu_rlc_data_ind() that do the same symetric processing.
doc/FEATURE_SET.md deleted 100644 → 0
View file @ bbee4d98
**Table of Contents**
1. [Functional Split Architecture](#functional-split-architecture)
2. [OpenAirInterface Block Diagram](#openairinterface-block-diagram)
2. [OpenAirInterface 4G-LTE eNB Feature Set](#openairinterface-4g-lte-enb-feature-set)
1. [eNB PHY Layer](#enb-phy-layer)
2. [eNB MAC Layer](#enb-mac-layer)
3. [eNB RLC Layer](#enb-rlc-layer)
4. [eNB PDCP Layer](#enb-pdcp-layer)
5. [eNB RRC Layer](#enb-rrc-layer)
6. [eNB X2AP](#enb-x2ap)
7. [eNB/MCE M2AP](#enbmce-m2ap)
8. [MCE/MME M3AP](#mcemme-m3ap)
3. [OpenAirInterface 4G-LTE UE Feature Set](#openairinterface-4g-lte-ue-feature-set)
1. [LTE UE PHY Layer](#lte-ue-phy-layer)
2. [LTE UE MAC Layer](#lte-ue-mac-layer)
3. [LTE UE RLC Layer](#lte-ue-rlc-layer)
4. [LTE UE PDCP Layer](#lte-ue-pdcp-layer)
5. [LTE UE RRC Layer](#lte-ue-rrc-layer)
4. [OpenAirInterface 5G-NR gNB Feature Set](#openairinterface-5g-nr-feature-set)
1. [General Parameters](#general-parameters)
2. [gNB Physical Layer](#gnb-phy-layer)
3. [gNB Higher Layers](#gnb-higher-layers)
5. [OpenAirInterface 5G-NR UE Feature Set](#openairinterface-5g-nr-ue-feature-set)
1. [UE Physical Layer](#ue-phy-layer)
2. [UE Higher Layers](#ue-higher-layers)
# Functional Split Architecture #
- RCC: Radio-Cloud Center
- RAU: Radio-Access Unit
- RRU: Remote Radio-Unit
- IF4.5 / IF5 : similar to IEEE P1914.1
- FAPI (IF2) : specified by Small Cell Forum (open-nFAPI implementation)
- IF1 : F1 in 3GPP Release 15
![Functional Split Architecture](./oai_enb_func_split_arch.png)
# OpenAirInterface Block Diagram #
![Block Diagram](./oai_enb_block_diagram.png)
# OpenAirInterface 4G LTE eNB Feature Set #
## eNB PHY Layer ##
The Physical layer implements **3GPP 36.211**, **36.212**, **36.213** and provides the following features:
- LTE release 8.6 compliant, and implements a subset of release 10
- FDD and TDD configurations: 1 (experimental) and 3
- Bandwidth: 5, 10, and 20 MHz
- Transmission modes: 1, 2 (stable), 3, 4, 5, 6, 7 (experimental)
- Max number of antennas: 2
- CQI/PMI reporting: aperiodic, feedback mode 3 - 0 and 3 - 1
- PRACH preamble format 0
- Downlink (DL) channels are supported: PSS, SSS, PBCH, PCFICH, PHICH, PDCCH, PDSCH, PMCH, MPDCCH
- Uplink (UL) channels are supported: PRACH, PUSCH, PUCCH (format 1/1a/1b), SRS, DRS
- HARQ support (UL and DL)
- Highly optimized base band processing (including turbo decoder)
- Multi-RRU support: over the air synchro b/ multi RRU in TDD mode
- Support for CE-modeA for LTE-M. Limited support for repeatition, single-LTE-M connection, legacy-LTE UE attach is disabled.
### Performances ###
**Transmission Mode, Bandwidth** | **Expected Throughput** | **Measured Throughput** | **Measurement Conditions**
-------------------------------- | ----------------------- | ------------------------| ----------------:
FDD DL: 5 MHz, 25 PRBS/ MCS 28 | 16 - 17 Mbit/s | TM1: 17.0 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
FDD DL: 10 MHz, 50 PRBS/ MCS 28 | 34 - 35 Mbit/s | TM1: 34.0 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
FDD DL: 20 MHz, 100 PRBS/ MCS 28 | 70 Mbit/s | TM1: 69.9 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
| | |
FDD UL: 5 MHz, 25 PRBS/ MCS 20 | 9 Mbit/s | TM1: 8.28 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
FDD UL: 10 MHz, 50 PRBS/ MCS 20 | 17 Mbit/s | TM1: 18.3 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
FDD UL: 20 MHz, 100 PRBS/ MCS 20 | 35 Mbit/s | TM1: 18.6 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
| |
TDD DL: 5 MHz, 25 PRBS/ MCS **XX** | 6.5 Mbit/s | TM1: 6.71 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
TDD DL: 10 MHz, 50 PRBS/ MCS **XX** | 13.5 Mbit/s | TM1: 13.6 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
TDD DL: 20 MHz, 100 PRBS/ MCS **XX** | 28.0 Mbit/s | TM1: 27.2 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
| | |
TDD UL: 5 MHz, 25 PRBS/ MCS **XX** | 2.0 Mbit/s | TM1: 3.31 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
TDD UL: 10 MHz, 50 PRBS/ MCS **XX** | 2.0 Mbit/s | TM1: 7.25 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
TDD UL: 20 MHz, 100 PRBS/ MCS **XX** | 3.0 Mbit/s | TM1: 4.21 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
### Number of supported UEs ###
* 16 by default
* up to 256 when compiling with dedicated compile flag
* was tested with 40 COTS-UE
## eNB MAC Layer ##
The MAC layer implements a subset of the **3GPP 36.321** release v8.6 in support of BCH, DLSCH, RACH, and ULSCH channels.
- RRC interface for CCCH, DCCH, and DTCH
- Proportional fair scheduler (round robin scheduler soon), with the following improvements:
- Up to 30 users tested in the L2 simulator, CCE allocation in the preprocessor ; the scheduler was also simplified and made more modular
- Adaptative UL-HARQ
- Remove out-of-sync UEs
- No use of the `first_rb` in the UL scheduler ; respects `vrb_map_UL` and `vrb_map` in the DL
- DCI generation
- HARQ Support
- RA procedures and RNTI management
- RLC interface (AM, UM)
- UL power control
- Link adaptation
- Connected DRX (CDRX) support for FDD LTE UE. Compatible with R13 from 3GPP. Support for Cat-M1 UE comming soon.
## eNB RLC Layer ##
The RLC layer implements a full specification of the 3GPP 36.322 release v9.3.
- RLC TM (mainly used for BCCH and CCCH)
* Neither segment nor concatenate RLC SDUs
* Do not include a RLC header in the RLC PDU
* Delivery of received RLC PDUs to upper layers
- RLC UM (mainly used for DTCH)
* Segment or concatenate RLC SDUs according to the TB size selected by MAC
* Include a RLC header in the RLC PDU
* Duplication detection
* PDU reordering and reassembly
- RLC AM, compatible with 9.3
* Segmentation, re-segmentation, concatenation, and reassembly
* Padding
* Data transfer to the user
* RLC PDU retransmission in support of error control and correction
* Generation of data/control PDUs
## eNB PDCP Layer ##
The current PDCP layer is header compliant with **3GPP 36.323** Rel 10.1.0 and implements the following functions:
- User and control data transfer
- Sequence number management
- RB association with PDCP entity
- PDCP entity association with one or two RLC entities
- Integrity check and encryption using the AES and Snow3G algorithms
## eNB RRC Layer ##
The RRC layer is based on **3GPP 36.331** v15.6 and implements the following functions:
- System Information broadcast (SIB 1, 2, 3, and 13)
* SIB1: Up to 6 PLMN IDs broadcast
- RRC connection establishment
- RRC connection reconfiguration (addition and removal of radio bearers, connection release)
- RRC connection release
- RRC connection re-establishment
- Inter-frequency measurement collection and reporting (experimental)
- eMBMS for multicast and broadcast (experimental)
- Handover (experimental)
- Paging (soon)
- RRC inactivity timer (release of UE after a period of data inactivity)
## eNB X2AP ##
The X2AP layer is based on **3GPP 36.423** v14.6.0 and implements the following functions:
- X2 Setup Request
- X2 Setup Response
- X2 Setup Failure
- Handover Request
- Handover Request Acknowledge
- UE Context Release
- X2 timers (t_reloc_prep, tx2_reloc_overall)
- Handover Cancel
- X2-U interface implemented
- EN-DC is implemented
- X2AP : Handling of SgNB Addition Request / Addition Request Acknowledge / Reconfiguration Complete
- RRC : Handling of RRC Connection Reconfiguration with 5G cell info, configuration of 5G-NR measurements
- S1AP : Handling of E-RAB Modification Indication / Confirmation
## eNB/MCE M2AP ##
The M2AP layer is based on **3GPP 36.443** v14.0.1:
- M2 Setup Request
- M2 Setup Response
- M2 Setup Failure
- M2 Scheduling Information
- M2 Scheduling Information Response
- M2 Session Start Request
- M2 Session Start Response
## MCE/MME M3AP ##
The M3AP layer is based on **3GPP 36.444** v14.0.1:
- M3 Setup Request
- M3 Setup Response
- M3 Setup Failure
- M3 Session Start Request
- M3 Session Start Response
# OpenAirInterface 4G LTE UE Feature Set #
## LTE UE PHY Layer ##
The Physical layer implements **3GPP 36.211**, **36.212**, **36.213** and provides the following features:
- LTE release 8.6 compliant, and implements a subset of release 10
- FDD and TDD configurations: 1 (experimental) and 3
- Bandwidth: 5, 10, and 20 MHz
- Transmission modes: 1, 2 (stable)
- Max number of antennas: 2
- CQI/PMI reporting: aperiodic, feedback mode 3 - 0 and 3 - 1
- PRACH preamble format 0
- All downlink (DL) channels are supported: PSS, SSS, PBCH, PCFICH, PHICH, PDCCH, PDSCH, PMCH
- All uplink (UL) channels are supported: PRACH, PUSCH, PUCCH (format 1/1a/1b), SRS, DRS
- LTE MBMS-dedicated cell (feMBMS) procedures subset for LTE release 14 (experimental)
- LTE non-MBSFN subframe (feMBMS) Carrier Adquistion Subframe-CAS procedures (PSS/SSS/PBCH/PDSH) (experimental)
- LTE MBSFN MBSFN subframe channel (feMBMS): PMCH (CS@1.25KHz) (channel estimation for 25MHz bandwidth) (experimental)
## LTE UE MAC Layer ##
The MAC layer implements a subset of the **3GPP 36.321** release v8.6 in support of BCH, DLSCH, RACH, and ULSCH channels.
- RRC interface for CCCH, DCCH, and DTCH
- HARQ Support
- RA procedures and RNTI management
- RLC interface (AM, UM)
- UL power control
- Link adaptation
- MBMS-dedicated cell (feMBMS) RRC interface for BCCH
- eMBMS and MBMS-dedicated cell (feMBMS) RRC interface for MCCH, MTCH
## LTE UE RLC Layer ##
The RLC layer implements a full specification of the 3GPP 36.322 release v9.3.
## LTE UE PDCP Layer ##
The current PDCP layer is header compliant with **3GPP 36.323** Rel 10.1.0.
## LTE UE RRC Layer ##
The RRC layer is based on **3GPP 36.331** v14.3.0 and implements the following functions:
- System Information decoding
- RRC connection establishment
- MBMS-dedicated cell (feMBMS) SI-MBMS/SIB1-MBMS management
## LTE UE NAS Layer ##
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
# OpenAirInterface 5G-NR Feature Set #
## General Parameters ##
The following features are valid for the gNB and the 5G-NR UE.
* Static TDD,
* FDD
* Normal CP
* 30 kHz subcarrier spacing
* Bandwidths: 10, 20, 40, 80, 100MHz (273 Physical Resource Blocks)
* Intermediate downlink and uplink frequencies to interface with IF equipment
* Single antenna port (single beam)
* Slot format: 14 OFDM symbols in UL or DL
* Highly efficient 3GPP compliant LDPC encoder and decoder (BG1 and BG2 supported)
* Highly efficient 3GPP compliant polar encoder and decoder
* Encoder and decoder for short blocks
* Support for UL transform precoding (SC-FDMA)
## gNB PHY Layer ##
* 30KHz SCS for FR1 and 120 KHz SCS for FR2
* Generation of NR-PSS/NR-SSS
* NR-PBCH supports multiple SSBs and flexible periodicity
* Generation of NR-PDCCH (including generation of DCI, polar encoding, scrambling, modulation, RB mapping, etc)
- common search space
- user-specific search space
- DCI formats: 00, 10, 01 and 11
* Generation of NR-PDSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
- PDSCH mapping type A and B
- DMRS configuration type 1 and 2
- Single and multiple DMRS symbols
- PTRS support
- Support for 1, 2 and 4 TX antennas
- Support for up to 2 layers (currently limited to DMRS configuration type 2)
* NR-CSIRS Generation of sequence at PHY
* NR-PUSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
- PUSCH mapping type A and B
- DMRS configuration type 1 and 2
- Single and multiple DMRS symbols
- PTRS support
- Support for 1 RX antenna
- Support for 1 layer
* NR-PUCCH
- Format 0 (2 bits, for ACK/NACK and SR)
- Format 2 (up to 11 bits, mainly for CSI feedback)
* NR-SRS
- SRS signal reception
- Channel estimation (with T tracer real time monitoring)
- Power noise estimation
* NR-PRACH
- Formats 0,1,2,3, A1-A3, B1-B3
* Highly efficient 3GPP compliant LDPC encoder and decoder (BG1 and BG2 are supported)
* Highly efficient 3GPP compliant polar encoder and decoder
* Encoder and decoder for short block
## gNB Higher Layers ##
**gNB MAC**
- MAC -> PHY configuration using NR FAPI P5 interface
- MAC <-> PHY data interface using FAPI P7 interface for BCH PDU, DCI PDU, PDSCH PDU
- Scheduler procedures for SIB1
- Scheduler procedures for RA
- Contention Free RA procedure
- Contention Based RA procedure
- Msg3 can transfer uplink CCCH, DTCH or DCCH messages
- CBRA can be performed using MAC CE or C-RNTI
- Scheduler procedures for CSI-RS
- MAC downlink scheduler
- phy-test scheduler (fixed allocation and usable also without UE)
- regular scheduler with dynamic allocation
- MCS adaptation from HARQ BLER
- MAC header generation (including timing advance)
- ACK / NACK handling and HARQ procedures for downlink
- MAC uplink scheduler
- phy-test scheduler (fixed allocation)
- regular scheduler with dynamic allocation
- HARQ procedures for uplink
- Scheduler procedures for SRS reception
- Periodic SRS reception
- MAC procedures to handle CSI measurement report
- evalution of RSRP report
- evaluation of CQI report
- MAC scheduling of SR reception
**gNB RLC**
- Send/Receive operations according to 38.322 Rel.16
- Segmentation and reassembly procedures
- RLC Acknowledged mode supporting PDU retransmissions
- RLC Unacknowledged mode
- DRBs and SRBs establishment/handling and association with RLC entities
- Timers implementation
- Interfaces with PDCP, MAC
- Interfaces with gtp-u (data Tx/Rx over F1-U at the DU)
**gNB PDCP**
- Send/Receive operations according to 38.323 Rel.16
- Integrity protection and ciphering procedures
- Sequence number management, SDU dicard and in-order delivery
- Radio bearer establishment/handling and association with PDCP entities
- Interfaces with RRC, RLC
- Interfaces with gtp-u (data Tx/Rx over N3 and F1-U interfaces)
**gNB RRC**
- NR RRC (38.331) Rel 16 messages using new asn1c
- LTE RRC (36.331) also updated to Rel 15
- Generation of CellGroupConfig (for eNB) and MIB
- Generation of system information block 1 (SIB1)
- Generation of system information block 2 (SIB2)
- Application to read configuration file and program gNB RRC
- RRC can configure PDCP, RLC, MAC
- Interface with gtp-u (tunnel creation/handling for S1-U (NSA), N3 (SA) interfaces)
- Integration of RRC messages and procedures supporting UE 5G SA connection
- RRCSetupRequest/RRCSetup/RRCSetupComplete
- RRC Uplink/Downlink Information transfer carrying NAS messages transparently
- RRC Reconfiguration/Reconfiguration complete
- Support for master cell group configuration
- Interface with NGAP for the interactions with the AMF
- Interface with F1AP for CU/DU split deployment option
**gNB X2AP**
- Integration of X2AP messages and procedures for the exchanges with the eNB over X2 interface supporting the NSA setup according to 36.423 Rel. 15
- X2 setup with eNB
- Handling of SgNB Addition Request / Addition Request Acknowledge / Reconfiguration Complete
**gNB NGAP**
- Integration of NGAP messages and procedures for the exchanges with the AMF over N2 interface according to 38.413 Rel. 15
- NGAP Setup request/response
- NGAP Initial UE message
- NGAP Initial context setup request/response
- NGAP Downlink/Uplink NAS transfer
- NGAP UE context release request/complete
- NGAP UE radio capability info indication
- NGAP PDU session resource setup request/response
- Interface with RRC
**gNB F1AP**
- Integration of F1AP messages and procedures for the control plane exchanges between the CU and DU entities according to 38.473 Rel. 16
- F1 Setup request/response
- F1 DL/UL RRC message transfer
- F1 Initial UL RRC message transfer
- F1 UE Context setup request/response
- F1 gNB CU configuration update
- Interface with RRC
- Interface with gtp-u (tunnel creation/handling for F1-U interface)
**gNB GTP-U**
- New gtp-u implementation supporting both N3 and F1-U interfaces according to 29.281 Rel.15
- Interfaces with RRC, F1AP for tunnel creation
- Interfaces with PDCP and RLC for data send/receive at the CU and DU respectively (F1-U interface)
# OpenAirInterface 5G-NR UE Feature Set #
* Supporting "noS1" mode (DL and UL):
- Creates TUN interface to PDCP to inject and receive user-place traffic
- No connection to the core network
* Supporting Standalone (SA) mode:
- UE can register with the 5G Core Network, establish a PDU Session and exchange user-plane traffic
## NR UE PHY Layer ##
* Initial synchronization
* Time tracking based on PBCH DMRS
* Frequency offset estimation
* 30KHz SCS for FR1 and 120 KHz SCS for FR2
* Reception of NR-PSS/NR-SSS
* NR-PBCH supports multiple SSBs and flexible periodicity
* Reception of NR-PDCCH (including reception of DCI, polar decoding, de-scrambling, de-modulation, RB de-mapping, etc)
- common search space configured by MIB
- user-specific search space configured by RRC
- DCI formats: 00, 10, 01 and 11
* Reception of NR-PDSCH (including Segmentation, LDPC decoding, rate de-matching, de-scrambling, de-modulation, RB de-mapping, etc).
- PDSCH mapping type A and B
- DMRS configuration type 1 and 2
- Single and multiple DMRS symbols
- PTRS support
- Support for 1, 2 and 4 RX antennas
- Support for up to 2 layers (currently limited to DMRS configuration type 2)
* NR-PUSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
- PUSCH mapping type A and B
- DMRS configuration type 1 and 2
- Single and multiple DMRS symbols
- PTRS support
- Support for 1 TX antenna
- Support for 1 layer
* NR-PUCCH
- Format 0 (2 bits for ACK/NACK and SR)
- Format 2 (up to 64 bits, mainly for CSI feedback)
- Format 1, 3 and 4 present but old code never dested (need restructuring before verification)
* NR-SRS
- Generation of sequence at PHY
- SRS signal transmission
* NR-PRACH
- Formats 0,1,2,3, A1-A3, B1-B3
* SS-RSRP
- RSRP measured on synchronization SSB (ok only for single SSB)
* Highly efficient 3GPP compliant LDPC encoder and decoder (BG1 and BG2 are supported)
* Highly efficient 3GPP compliant polar encoder and decoder
* Encoder and decoder for short block
## NR UE FAPI ##
* MAC -> PHY configuration via UE FAPI P5 interface
* Basic MAC to control PHY via UE FAPI P7 interface
* PHY -> MAC indication (needs some improvement)
## NR UE Higher Layers ##
**UE MAC**
* Minimum system information (MSI)
- MIB processing
- Scheduling of system information block 1 (SIB1) reception
* Random access procedure (needs improvement, there is still not a clear separation between MAC and PHY)
- Mapping SSBs to multiple ROs
- Scheduling of PRACH
- Processing of RAR
- Transmission and re-transmission of Msg3
- Msg4 and contention resolution
* DCI processing
- format 10 (RA-RNTI, C-RNTI, SI-RNTI, TC-RNTI)
- format 00 (C-RNTI, TC-RNTI)
- format 11 (C-RNTI)
- format 01 (C-RNTI)
* UCI processing
- ACK/NACK processing
- Triggering periodic SR
- CSI measurement reporting (SSB RSRP only)
* DLSH scheduler
- Configuration of fapi PDU according to DCI
- HARQ procedures
* ULSCH scheduler
- Configuration of fapi PDU according to DCI
* Scheduler procedures for SRS transmission
- Periodic SRS transmission
**UE RLC**
* Tx/Rx operations according to 38.322 Rel.16
- Segmentation and reassembly procedures
- RLC Acknowledged mode supporting PDU retransmissions
- RLC Unacknowledged mode
- DRBs and SRBs establishment and handling
- Timers implementation
- Interfaces with PDCP, MAC
**UE PDCP**
* Tx/Rx operations according to 38.323 Rel.16
- Integrity protection and ciphering procedures
- Sequence number management, SDU dicard and in-order delivery
- Radio bearer establishment/handling and association with PDCP entities
- Interfaces with RRC, RLC
**UE RRC**
* Integration of RRC messages and procedures supporting UE 5G SA connection according to 38.331 Rel.16
- RRCSetupRequest/RRCSetup/RRCSetupComplete
- RRC Uplink/Downlink Information transfer carrying NAS messages transparently
- RRC Reconfiguration/Reconfiguration complete
- Support for master cell group configuration
* Interface with PDCP: configuration, DCCH and CCCH message handling
* Interface with RLC and MAC for configuration
**UE NAS**
* Transfer of NAS messages between the AMF and the UE supporting the UE registration with the core network and the PDU session establishment according to 24.501 Rel.16
- Identity Request/Response
- Authentication Request/Response
- Security Mode Command/Complete
- Registration Request/Accept/Complete
- PDU Session Establishment Request/Accept
- NAS configuration and basic interfacing with RRC
[OAI wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[OAI softmodem build procedure](BUILD.md)
[Running the OAI softmodem ](RUNMODEM.md)
doc/GET_SOURCES.md deleted 100644 → 0
View file @ bbee4d98
<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">The OpenAirInterface repository: the sources</font></b>
</td>
</tr>
</table>
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.
# Prerequisites
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.
* A more recent version is available under our GitHub domain:
* [OAI GitHub openair-cn domain](https://github.com/OPENAIRINTERFACE)
* Check its wiki pages for more details
Configure git with your name/email address (only important if you are developer and want to contribute/push code to Git Repository):
```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 clone the Git repository (for OAI Users without login to gitlab server)
Cloning RAN repository (eNB RAN + UE RAN):
```shell
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
```
## In order to contribute to the Git RAN repository (for OAI Developers/admins with login to gitlab server)
Please send email to [contact@openairinterface.org](mailto:contact@openairinterface.org) 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 and provide the identifiant in the email.
* Clone 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, clone the git repository using:
* `git clone git@gitlab.eurecom.fr:oai/openairinterface5g.git`
* Clone with user name/password prompt:
* `git clone https://YOUR_USERNAME@gitlab.eurecom.fr/oai/openairinterface5g.git`
# 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
doc/ITTISIM.md deleted 100755 → 0
View file @ bbee4d98
<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">Running L3 ITTI simulator</font></b>
</td>
</tr>
</table>
This page is valid on the following branches:
- `develop` starting from tag `2020.w48`
# 1. Building the ITTI simulator.
The ITTI simulator is available directly from the standard build.
```bash
$ source oaienv
$ cd cmake_targets
$ sudo ./build_oai -x -w None -c -ittiSIM
```
# 2. Running the ITTI simulator.
The ITTI simulator establishes ITTI-threaded communication between the gNB RRC task and the UE RRC task.
This allows to test the sequence of NGAP/RRC/NAS messages.
The main limitations are:
- NAS is a simple stub that just sends and receives messages
- only initial Attach sequence
## 2.1. Starting the ITTI simulator
The ITTI simulator is able to run with a connected 5GC or without any.
The develop branch tag `2020.w48` only works RRC without 5GC connection.
```bash
$ sudo -E ./ran_build/build/nr-ittisim -O gnb.conf
```
doc/L1SIM.md deleted 100644 → 0
View file @ bbee4d98
<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 ../ran_build/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 ../ran_build/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)
doc/L2NFAPI.md deleted 100644 → 0
View file @ bbee4d98
<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.
The UE executable is able to "simulate" multiple UEs in order to stimulate the scheduler in the eNB.
**This simulator is available starting the `v1.0.0` release on the `master` branch.**
**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
Currently the Continuous Integration process is validating this simulator the following way:
* the LTE modem executable is run on one host (in our CI deployment it is a **Xenial Virtual Machine**)
* the UE(s) modem executable is run on another host (in our CI deployment it is also a **Xenial Virtual Machine**)
* We are testing:
* in S1 mode (ie we are connected to a 3rd-party EPC)
* in noS1 mode (no need for an EPC)
Normally it should be fine to run both executables on the same host using the `loopback` interface to communicate. **But we are not guaranting it**
1. [With S1 -- eNB and UE on 2 hosts](L2NFAPI_S1.md)
2. [No S1 -- eNB and UE on 2 hosts](L2NFAPI_NOS1.md)
**2022/03/08: Starting the `2022.w01` tag on the `develop` branch, the L2 nFAPI simulation is using a proxy.**
A tutorial is available on the [EpiSci GitHub Repository](https://github.com/EpiSci/oai-lte-5g-multi-ue-proxy#readme).
This proxy allows to perform L2 nFAPI simulator for:
* LTE
* 5G-NSA
* 5G-SA
----
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
doc/L2NFAPI_NOS1.md deleted 100644 → 0
View file @ bbee4d98
<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 (no S1 Mode / 2-host deployment)</font></b>
</td>
</tr>
</table>
**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
## Table of Contents ##
1. [Environment](#1-environment)
2. [Retrieve the OAI eNB-UE source code](#2-retrieve-the-oai-enb-ue-source-code)
3. [Setup of the USIM information in UE folder](#3-setup-of-the-usim-information-in-ue-folder)
4. [Setup of the Configuration files](#4-setup-of-the-configuration-files)
1. [The eNB Configuration file](#41-the-enb-configuration-file)
2. [The UE Configuration file](#42-the-ue-configuration-file)
5. [Build OAI UE and eNodeB](#5-build-oai-ue-and-enodeb)
6. [Start the eNB](#6-start-the-enb)
7. [Start the UE](#7-start-the-ue)
8. [Test with ping](#8-test-with-ping)
9. [Limitations](#9-limitations)
# 1. Environment #
You may not have access to an EPC or you don't want to hassle to deploy one.
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 B contains the OAI eNB executable (`lte-softmodem`)
* Machine C contains the OAI UE(s) executable (`lte-uesoftmodem`)
Example of L2 nFAPI Simulator testing environment:
<img src="./images/L2-sim-noS1-2-host-deployment.png" alt="" border=3>
Note that the IP addresses are indicative and need to be adapted to your environment.
# 2. Retrieve the OAI eNB-UE source code #
At the time of writing, the tag used in the `develop` branch to do this documentation was `2020.w16`.
The tutorial should be valid for the `master` branch tags such as `v1.2.0` or `v1.2.1`. But you may face issues that could be fixed in newer `develop` tags.
Please try to use the same commit ID on both eNB/UE hosts.
```bash
$ ssh sudousername@machineB
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git enb_folder
cd enb_folder
git checkout develop
```
```bash
$ ssh sudousername@machineC
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ue_folder
cd ue_folder
git checkout develop
```
# 3. Setup of the USIM information in UE folder #
```bash
$ ssh sudousername@machineC
cd ue_folder
# Edit 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.
# 4. 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.**
## 4.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 physical ethernet interface of machineB and put the proper IP addresses for both hosts.
```
MACRLCs = (
{
num_cc = 1;
local_s_if_name = "ens3"; // <-- HERE
remote_s_address = "192.168.122.169"; // <-- HERE
local_s_address = "192.168.122.31"; // <-- 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.122.195
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.122.31
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.122.31
ENB_PORT_FOR_S1U = 2152; # Spec 2152
ENB_IPV4_ADDRESS_FOR_X2C = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
ENB_PORT_FOR_X2C = 36422; # Spec 36422
};
```
## 4.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 = "ens3"; // <- HERE
remote_n_address = "192.168.122.31"; // <- HERE
local_n_address = "192.168.122.169"; // <- HERE
local_n_portc = 50000;
remote_n_portc = 50001;
local_n_portd = 50010;
remote_n_portd = 50011;
}
);
```
# 5. Build OAI UE and eNodeB #
See [Build documentation](./BUILD.md).
# 6. 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 ./ran_build/build/lte-softmodem -O ../ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf --noS1 > enb.log 2>&1
sleep 10
ifconfig
ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.122.31 Bcast:192.168.122.255 Mask:255.255.255.0
....
oaitun_enb1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.1 P-t-P:192.172.0.2 Mask:255.255.255.0
....
```
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.
# 7. Start the UE #
In the second terminal (the one you used to build the UE):
```bash
$ ssh sudousername@machineC
cd ue_folder/cmake_targets
# Test 64 UEs, 1 thread in FDD mode
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
# Test 64 UEs, 1 thread in TDD mode
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 -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 number of threads can set with the `--nums-ue-thread`. This number **SHALL NOT** be greater than the number of UEs.
* At the time of writing, it seems to be enough to run on a single thread.
- The `--nokrnmod 1` option makes use of the preferred and supported tunnel interface.
- How many UE that can be tested depends on hardware (server , PC, etc) performance in your environment.
For example, running with 4 UEs:
```bash
$ ssh sudousername@machineC
cd ue_folder/cmake_targets
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
sleep 10
ifconfig
ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.122.169 Bcast:192.168.122.255 Mask:255.255.255.0
....
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.2 P-t-P:192.172.0.2 Mask:255.255.255.0
....
oaitun_ue2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.3 P-t-P:192.172.0.3 Mask:255.255.255.0
....
oaitun_ue3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.4 P-t-P:192.172.0.4 Mask:255.255.255.0
....
oaitun_ue4 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.5 P-t-P:192.172.0.5 Mask:255.255.255.0
....
oaitun_uem1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.2.2 P-t-P:10.0.2.2 Mask:255.255.255.0
....
....
```
Having the 4 oaitun_ue tunnel interfaces up and with an allocated address means the connection with EPC went alright.
# 8. Test with ping #
In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB: Check with ifconfig
```bash
$ ssh sudousername@machineB
# Ping UE1 IP address based on the EPC pool used: in this example:
ping -I oaitun_enb1 -c 20 10.0.1.2
# Ping UE4 IP address based on the EPC pool used: in this example:
ping -I oaitun_enb1 -c 20 10.0.1.5
```
Ping from the UE side:
```bash
$ ssh sudousername@machineC
ping -I oaitun_ue1 -c 20 10.0.1.1
ping -I oaitun_ue3 -c 20 10.0.1.1
```
iperf operations can also be performed.
DL traffic:
```bash
$ ssh sudousername@machineC
iperf -B 10.0.1.2 -u -s -i 1 -fm -p 5002
$ ssh sudousername@machineB
iperf -c 10.0.1.2 -u -t 30 -b 3M -i 1 -fm -B 10.0.1.1 -p 5002
```
UL traffic:
```bash
$ ssh sudousername@machineB
iperf -B 10.0.1.1 -u -s -i 1 -fm -p 5002
$ ssh sudousername@machineC
iperf -c 10.0.1.1 -u -t 30 -b 2M -i 1 -fm -B 10.0.1.2 -p 5002
```
# 9. Limitations #
----
[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)
doc/L2NFAPI_S1.md deleted 100644 → 0
View file @ bbee4d98
<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 / 2-host deployment)</font></b>
</td>
</tr>
</table>
**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
## 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. [Build OAI UE and eNodeB](#6-build-oai-ue-and-enodeb)
7. [Start EPC](#7-start-epc)
8. [Start the eNB](#8-start-the-enb)
9. [Start the UE](#9-start-the-ue)
10. [Test with ping](#10-test-with-ping)
11. [Limitations](#11-limitations)
# 1. Environment #
3 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 executable (`lte-softmodem`)
* Machine C contains the OAI UE(s) executable (`lte-uesoftmodem`)
Example of L2 nFAPI Simulator testing environment:
<img src="./images/L2-sim-S1-3-host-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-epc-fed)), build **HSS/MME/SPGW** and create config files.
# 3. Retrieve the OAI eNB-UE source code #
At the time of writing, the tag used in the `develop` branch to do this documentation was `2020.w16`.
The tutorial should be valid for the `master` branch tags such as `v1.2.0` or `v1.2.1`. But you may face issues that could be fixed in newer `develop` tags.
Please try to use the same commit ID on both eNB/UE hosts.
```bash
$ ssh sudousername@machineB
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git enb_folder
cd enb_folder
git checkout develop
```
```bash
$ ssh sudousername@machineC
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ue_folder
cd ue_folder
git checkout develop
```
# 4. Setup of the USIM information in UE folder #
```bash
$ ssh sudousername@machineC
cd ue_folder
# Edit 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 physical ethernet interface of machineB and put the proper IP addresses for both hosts.
```
MACRLCs = (
{
num_cc = 1;
local_s_if_name = "ens3"; // <-- HERE
remote_s_address = "192.168.122.169"; // <-- HERE
local_s_address = "192.168.122.31"; // <-- 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.122.195
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.122.31
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.122.31
ENB_PORT_FOR_S1U = 2152; # Spec 2152
ENB_IPV4_ADDRESS_FOR_X2C = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
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 = "ens3"; // <- HERE
remote_n_address = "192.168.122.31"; // <- HERE
local_n_address = "192.168.122.169"; // <- HERE
local_n_portc = 50000;
remote_n_portc = 50001;
local_n_portd = 50010;
remote_n_portd = 50011;
}
);
```
# 6. Build OAI UE and eNodeB #
See [Build documentation](./BUILD.md).
# 7. Start EPC #
Start the EPC on machine `A`.
```bash
$ ssh sudousername@machineA
# Start the EPC
```
# 8. 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 ./ran_build/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.
# 9. Start the UE #
In the second terminal (the one you used to build the UE):
```bash
$ ssh sudousername@machineC
cd ue_folder/cmake_targets
# Test 64 UEs, 1 thread in FDD mode
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
# Test 64 UEs, 1 thread in TDD mode
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 -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 number of threads can set with the `--nums-ue-thread`. This number **SHALL NOT** be greater than the number of UEs.
* At the time of writing, it seems to be enough to run on a single thread.
- The `--nokrnmod 1` option makes use of the preferred and supported tunnel interface.
- How many UE that can be tested depends on hardware (server , PC, etc) performance in your environment.
For example, running with 4 UEs:
```bash
$ ssh sudousername@machineC
cd ue_folder/cmake_targets
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
sleep 10
ifconfig
ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.122.169 Bcast:192.168.122.255 Mask:255.255.255.0
....
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.2 P-t-P:192.172.0.2 Mask:255.255.255.0
....
oaitun_ue2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.3 P-t-P:192.172.0.3 Mask:255.255.255.0
....
oaitun_ue3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.4 P-t-P:192.172.0.4 Mask:255.255.255.0
....
oaitun_ue4 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.5 P-t-P:192.172.0.5 Mask:255.255.255.0
....
oaitun_uem1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.2.2 P-t-P:10.0.2.2 Mask:255.255.255.0
....
....
```
Having the 4 oaitun_ue tunnel interfaces up and with an allocated address means the connection with EPC went alright.
# 10. Test with ping #
In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB: Check with ifconfig
```bash
$ ssh sudousername@machineA
# Ping UE1 IP address based on the EPC pool used: in this example:
$ ping -c 20 192.172.0.2
# Ping UE4 IP address based on the EPC pool used: in this example:
$ ping -c 20 192.172.0.5
```
iperf operations can also be performed.
# 11. Limitations #
----
[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)
doc/NR_NFAPI_archi.md deleted 100644 → 0
View file @ bbee4d98
# global
xnf is pnf or vnf
The xnf starting functions are configure_nfapi_xnf()
The OAI code that read the configuration parameters call these functions that will create autonomous thread for xnf control part
These control threads create a SCTP socket by Linux API call (no use of OpenAir internal architecture with SCTP itti thread).
The main() function of softmodem has to create and start the other threads+loop on event for appropriate work: RF Rx in pnf, NGAP, GTP-U, X2, RLC, PDCP for vnf
NFAPI has it's own code directly on Linux+Posix, it doesn't reuse any piece of the OpenAir framework: SCTP thread, thread creation and management, ...
## signaling (P5) xnf main loop
nfapi_vnf_start() create the SCTP socket, then do event waiting in a infinite loop while(vnf->terminate == 0). It accepts the pnf connections, then process the messages on reception
nfapi_pnf_start() initiate connection to vnf until it has a link. Then it enter a similar infinite loop in pnf_message_pump()
After some checks, when a message is obtained, it calls pnf_handle_p5_message() or vnf_handle_p4_p5_message() that have a switch on each p5 message types: the enum nfapi_message_id_e
Each message type has it's own processing function in the switch, like
```
case NFAPI_START_RESPONSE:
vnf_handle_start_response(pRecvMsg, recvMsgLen, config, p5_idx);
break;
```
These loops are autonomous in their thread waiting incoming message.
## P7 xnf main loop
When the p5 interface receives appropriate message, it starts the p7 interface by launching a thread (see the calls to pthread_create() in nfapi/oai_integration/nfapi_xnf.c)
The p7 main loops starting is a bit simpler, thanks to UDP non connected protocol. The xnf_dispatch_p7_message() do p7 fragments re-assembly, then
calls xnf_dispatch_p7_message() that have the big switch on message type (as in p5 above description)
So, we have the logic for UL reception in vnf, and DL reception in pnf
## P7 UL transmission by PNF
RF samples are received, and decoding is done by the PNF using control data transmitted by the VNF to the PNF through downlink p7 messages (UL_TTI_req and UL_DCI_req).
After decoding, results are accumulated into the xNB->UL_INFO structure at the PNF.
The data in the UL_INFO struct is transmitted through a socket in the form of 'uplink indication functions' from the PNF to the VNF. Each uplink indication message is transmitted from their respective handle functions in NR_UL_indication(). For example,
```
void handle_nr_rach(NR_UL_IND_t *UL_info) {
if(NFAPI_MODE == NFAPI_MODE_PNF) {
if (UL_info->rach_ind.number_of_pdus>0) {
oai_nfapi_nr_rach_indication(&UL_info->rach_ind); //This function calls the routines required for packing + transmission through socket
UL_info->rach_ind.number_of_pdus = 0;
}
}
```
## P7 UL reception at VNF
Through the infinite loop [while(vnf_p7->terminate == 0)] running in nfapi_nr_vnf_p7_start(), the VNF receives and unpacks the uplink indication message received on its socket. Based on the unpacked messages, UL_INFO struct on the VNF side gets populated.
```
// have a p7 message
if(FD_ISSET(vnf_p7->socket, &rfds))
{
vnf_nr_p7_read_dispatch_message(vnf_p7);
}
```
vnf_nr_dispatch_p7_message() is the function that contains the switch on various message headers so that the appropriate unpack function is called.
## P7 DL Transmission by VNF
DL messages are scheduled at the VNF, through NR_UL_indication(). NR_UL_indication() is called when the SFN/slot in the UL_info structure changes (this acts as a trigger for next slot processing, instead of running a separate clock at the VNF). The SFN/slot at the VNF in UL_info is updated using the slot_indication uplink p7 message, which is sent at the beginning of every slot by the PNF. The slot_indication message contains SFN/slot of the TX_thread, so that the scheduler operates slot_ahead slots ahead of the RX thread. This ensures that UL_tti_req is received before RX slot processing at the PNF.
The function NR_schedule_response calls oai_nfapi_[DL P7 msg]_req(), which contains the routines for packing + transmission of scheduled messages through the socket to the PNF. For example, to send the 'TX_data_req' p7 message
```
if (Sched_INFO->TX_req->Number_of_PDUs > 0)
{
oai_nfapi_tx_data_req(Sched_INFO->TX_req);
}
```
```mermaid
graph TD
pselect[VNF socket pselect] -- timed out : end of slot --> call_sched[Call Scheduler NR_UL_indication] -- oai_nfapi_***_req sends the DL p7 msg--> slot_inc[Increment sfn/slot];
pselect[VNF socket pselect] -- UL p7 xyz msg recvd --> msg_recvd[Read message vnf_nr_p7_read_dispatch_message] --> header_unpack[Unpack Header] -- switch cases on header --> unpack_msg[Handle Message vnf_handle_nr_xyz] --> fill_ul_info[Fill UL info struct with fn pointer vnf_p7->_public.nr_rx_xyz];
fill_ul_info -- update pselect_timeout: next_slot_start - time_xyz_msg_recvd-->pselect;
slot_inc -- next slot --> pselect
```
Note that since DL P7 message reception and TX/RX processing are done on separate threads, there is the issue of the L1 processing threads trying to do their job before the required P7 message is received. In the case of RX processing, since the scheduler operates slot_ahead slots ahead of the RX thread, the required messages conveniently arrive earlier than they are required. However, in the case of TX processing, this cannot be ensured if the scheduler is exactly in sync with the TX thread.
Therefore, we operate the VNF vnf_slot_ahead (which is currently 2) slots ahead of the PNF. This is to ensure that the DL fapi structures for a particular TX slot are all received before TX processing for that slot.
## P7 DL Reception at PNF
Through the infinite loop [while(pnf_p7->terminate == 0)] running in pnf_nr_p7_message_pump(), the PNF receives and unpacks the downlink P7 message received on its socket. Based on the unpacked message, the appropriate message structures are filled in the PNF, and these are used further down the pipeline for processing.
While receiving the DL P7 message, we check whether the message was received within a timing window from which it was sent. The duration of the window can be set by the user (set as a parameter for xnf in the p5 messages). Note that the DL information must be received by the PNF within a timing window at least lesser than the duration of slot_ahead variable (timing_window <= slot_ahead * slot_duration).
```mermaid
graph TB
pselect[PNF socket pselect] -- timed out : end of slot --> slot_inc[Increment sfn/slot];
pselect[PNF socket pselect] -- DL p7 xyz msg recvd --> msg_recvd[Read message pnf_nr_nfapi_p7_read_dispatch_message] --> header_unpack[Unpack Header] -- switch cases on header --> unpack_msg[Unpack Message pnf_handle_nr_xyz] --> fill_pnf_p7[Fill pnf_p7 global structure pnf_handle_nr_xyz] --Data from pnf_p7 struct copied to fapi structures using pnf_phy_***_req. Called every slot from handle_nr_slot_ind-->pselect;
slot_inc -- next slot --> pselect
```
Once the messages are received, they are filled into slot buffers, and are stored until the processing of the slot that they were meant for.
doc/RUNMODEM.md deleted 100644 → 0
View file @ bbee4d98
<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">Running OAI Softmodem</font></b>
</td>
</tr>
</table>
After you have [built the softmodem executables](BUILD.md) you can set your default directory to the build directory `cmake_targets/ran_build/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.
# Basic Simulator
See the [dedicated page](BASIC_SIM.md).
# RF Simulator
The rf simulator is a oai device replacing the radio heads (for example the USRP device). It allows connecting the oai UE (LTE or 5G) and respectively the oai eNodeB or gNodeB 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. The rf simulator has some preliminary support for channel modeling.
It is planned to enhance this simulator with the following functionalities:
- Support for multiple UE connections,each UE being a `lte-uesoftmodem` or `nr_uesoftmodem` instance.
- Support for multiple eNodeB's or gNodeB's for hand-over tests
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 simulator 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
# 5G NR
As of February 2020, all 5G NR development is part of the develop branch (the branch develop-nr is no longer maintained). This also means that all new development will be merged into there once it passes all the CI.
## NSA setup with COTS UE
This setup requires an EPC, an OAI eNB and gNB, and a COTS Phone. A dedicated page describe the setup can be found [here](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home/gNB-COTS-UE-testing).
### Launch gNB
```bash sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf```
### Launch eNB
```bash sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.50PRB.usrpb210.conf```
## phy-test setup with OAI UE
The OAI UE can also be used in front of a OAI gNB without the support of eNB or EPC. In this case both gNB and eNB need to be run with the --phy-test flag. At the gNB this flag does the following
- it reads the RRC configuration from the configuration file
- it encodes the RRCConfiguration and the RBconfig message and stores them in the binary files rbconfig.raw and reconfig.raw
- the MAC uses a pre-configured allocation of PDSCH and PUSCH with randomly generated payload
At the UE the --phy-test flag will
- read the binary files rbconfig.raw and reconfig.raw from the current directory (a different directory can be specified with the flag --rrc_config_path) and process them.
### Launch gNB
```bash sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --phy-test```
In phy-test mode it is possible to mimic the reception of UE Capabilities at gNB by passing through the command line parameter `--uecap_file` the location and file name of the input UE Capability file, e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap.xml`
### Launch UE in another window
```bash sudo ./nr-uesoftmodem --phy-test [--rrc_config_path ../../../ci-scripts/rrc-files]```
Some other useful paramters of the UE are
- --ue-fo-compensation: enables the frequency offset compenstation at the UE. This is useful when running over the air and/or without an external clock/time source
- --usrp-args: this is the equivalend paramter of sdr_addrs field in the gNB config file and can be used to identify the USRP and set some basic paramters (like the clock source)
- --clock-source: sets the clock-source (internal or external).
- --time-source: sets the time-source (internal or external).
## noS1 setup with OAI UE
Instead of randomly generated payload, in the phy-test mode we can also inject/receive user-plane traffic over a TUN interface. This is the so-called noS1 mode.
This setup is described in the [rfsimulator page](../targets/ARCH/rfsimulator/README.md#5g-case). In theory this should also work with the real hardware target although this has yet to be tested.
## do-ra setup with OAI
The do-ra flag is used to ran the NR Random Access procedures in contention-free mode. Currently OAI implements the RACH process from Msg1 to Msg3.
In order to run the RA, the following flag is needed for both the gNB and the UE:
`--do-ra`
### Run OAI in do-ra mode
From the `cmake_targets/ran_build/build` folder:
gNB on machine 1:
`sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --do-ra`
In do-ra mode it is possible to mimic the reception of UE Capabilities at gNB by passing through the command line parameter `--uecap_file` the location and file name of the input UE Capability file, e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap.xml`
UE on machine 2:
`sudo ./nr-uesoftmodem --do-ra`
With the RF simulator (on the same machine):
`sudo RFSIMULATOR=gnb ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --do-ra --rfsim --parallel-config PARALLEL_SINGLE_THREAD`
`sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem --do-ra --rfsim --parallel-config PARALLEL_SINGLE_THREAD`
## SA setup with OAI
The sa flag is used to run gNB in standalone mode.
In order to run gNB and UE in standalone mode, the following flag is needed:
`--sa`
At the gNB the --sa flag does the following:
- The RRC encodes SIB1 according to the configuration file and transmits it through NR-BCCH-DL-SCH.
At the UE the --sa flag will:
- Decode SIB1 and starts the 5G NR Initial Access Procedure for SA:
1) 5G-NR RRC Connection Setup
2) NAS Authentication and Security
3) 5G-NR AS Security Procedure
4) 5G-NR RRC Reconfiguration
5) Start Downlink and Uplink Data Transfer
Command line parameters for UE in --sa mode:
- `C` : downlink carrier frequency in Hz (default value 0)
- `CO` : uplink frequency offset for FDD in Hz (default value 0)
- `numerology` : numerology index (default value 1)
- `r` : bandwidth in terms of RBs (default value 106)
- `band` : NR band number (default value 78)
- `s` : SSB start subcarrier (default value 512)
### Run OAI in SA mode
From the `cmake_targets/ran_build/build` folder:
gNB on machine 1:
`sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --sa`
UE on machine 2:
`sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 -s 516 --sa`
With the RF simulator (on the same machine):
`sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --rfsim --sa`
`sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 -s 516 --rfsim --sa`
where `-r` sets the transmission bandwidth configuration in terms of RBs, `-C` sets the downlink carrier frequency and `-s` sets the SSB start subcarrier.
Additionally, at UE side `--uecap_file` option can be used to pass the UE Capabilities input file (path location + filename), e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap.xml`
## IF setup with OAI
OAI is also compatible with Intermediate Frequency (IF) equipment. This allows to use RF front-end that with arbitrary frequencies bands that do not comply with the standardised 3GPP NR bands.
To configure the IF frequencies it is necessary to use two command-line options at UE side:
- `if_freq`, downlink frequency in Hz
- `if_freq_off`, uplink frequency offset in Hz
Accordingly, the following parameters must be configured in the RUs section of the gNB configuration file:
- `if_freq`
- `if_offset`
### Run OAI with custom DL/UL arbitrary frequencies
The following example uses DL frequency 2169.080 MHz and UL frequency offset -400 MHz, with a configuration file for band 66 (FDD) at gNB side.
From the `cmake_targets/ran_build/build` folder:
gNB on machine 1:
`sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band66.tm1.106PRB.usrpx300.conf`
UE on machine 2:
`sudo ./nr-uesoftmodem --if_freq 2169080000 --if_freq_off -400000000`
[Selecting an alternative ldpc implementation at run time](../PHY/PHY/CODING/DOC/LDPCImplementation.md)
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
doc/RUN_NR_NFAPI.md deleted 100644 → 0
View file @ bbee4d98
# Procedure to run nFAPI in 5G NR
## Contributed by 5G Testbed IISc
### Developers: Gokul S, Mahesh A, Aniq U R
## Procedure to Build gNB and UE
The regular commands to build gNB and UE can be used
```
sudo ./build_oai --gNB --nrUE
```
## Procedure to run NR nFAPI using RF-Simulator
### Bring up another loopback interface
If running for the first time on your computer, or you have restarted your computer, bring up another loopback interface with this command:
sudo ifconfig lo: 127.0.0.2 netmask 255.0.0.0 up
### VNF command
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/rcc.band78.tm1.106PRB.nfapi.conf --nfapi 2 --noS1 --phy-test
```
### PNF command
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/oaiL1.nfapi.usrpx300.conf --nfapi 1 --rfsim --phy-test --rfsimulator.serveraddr server
```
### UE command
```
sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem --rfsim --phy-test --rrc_config_path . -d
```
## Procedure to run NR nFAPI using Hardware (tested with USRP x310)
### VNF command
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/rcc.band78.tm1.106PRB.nfapi.conf --nfapi 2 --noS1 --phy-test
```
### PNF command
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/oaiL1.nfapi.usrpx300.conf --nfapi 1 --phy-test
```
### UE command
```
sudo ./nr-uesoftmodem --usrp-args "addr=*USRP_ADDRESS*,clock_source=external,time_source=external" --phy-test --rrc_config_path ../../../ci-scripts/rrc-files
```
doc/SW-archi-graph.md deleted 100644 → 0
View file @ bbee4d98
```mermaid
flowchart TB
A[ru_thread] --> RFin>block rx_rf] --> feprx
feprx --> half-slot --> end_feprx
feprx --> second-thread -- block_end_feprx --> end_feprx>feprx]
end_feprx --> rx_nr_prach_ru
rx_nr_prach_ru -- block_queue_singleton --> resp_L1>resp L1]
resp_L1 -- async launch --> rx_func
resp_L1 -- immediate return --> RFin
subgraph rxfunc
rx_func_implem[rx_func]
subgraph rxfuncbeg
handle_nr_slot_ind
--> rnti_to_remove-mgmt
--> L1_nr_prach_procedures
--> apply_nr_rotation_ul
end
subgraph phy_procedures_gNB_uespec_RX
fill_ul_rb_mask
--> pucch(decode each gNB->pucch)
-->nr_fill_ul_indication
--> nr_ulsch_procedures
--> nr_ulsch_decoding
--> segInParallel[[all segments decode in parallel]]
--> barrier_end_of_ulsch_decoding
end
subgraph NR_UL_indication
handle_nr_rach
--> handle_nr_uci
--> handle_nr_ulsch
subgraph gNB_dlsch_ulsch_scheduler
run_pdcp
--> nr_rrc_trigger
--> schedule_xxxx
end
handle_nr_ulsch --> gNB_dlsch_ulsch_scheduler
subgraph NR_Schedule_response
L1_tx_free3>L1_tx_free]
--> handle_nr_nfapi_xxx_pdu
--> sendTxFilled((L1_tx_filled))
--> nr_fill_ul_xxx
--> nr_fill_prach
end
gNB_dlsch_ulsch_scheduler --> NR_Schedule_response
end
rx_func_implem --> rxfuncbeg
rxfuncbeg --> phy_procedures_gNB_uespec_RX
phy_procedures_gNB_uespec_RX --> NR_UL_indication
-- block_queue_block_PNF_monolithic --> L1_tx_free2>L1 tx filled]
-- async launch --> tx_func
L1_tx_free2 -- send_msg --> rsp((resp_L1))
end
rx_func --> rxfunc
subgraph tx_func
direction LR
subgraph phy_procedures_gNB_TX
dcitop[nr_generate dci top]
--> nr_generate_csi_rs
--> apply_nr_rotation
-- send_msg --> end_tx_func((L1_tx_out))
end
subgraph tx_reorder_thread
L1_tx_out>L1_tx_out]
--> reorder{re order} --> reorder
reorder --> ru_tx_func
reorder --> L1_tx_free((L1_tx_free))
ru_tx_func --> feptx_prec
--> feptx_ofdm
end
end
```
doc/SW_archi.md deleted 100644 → 0
View file @ bbee4d98
<style type="text/css" rel="stylesheet">
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
font-size: 13px;
line-height: 18px;
color: #fff;
background-color: #110F14;
}
h2 { margin-left: 20px; }
h3 { margin-left: 40px; }
h4 { margin-left: 60px; }
.func2 { margin-left: 20px; }
.func3 { margin-left: 40px; }
.func4 { margin-left: 60px; }
</style>
```mermaid
flowchart TB
A[ru_thread] --> RFin>block rx_rf] --> feprx
feprx --> half-slot --> end_feprx
feprx --> second-thread -- block_end_feprx --> end_feprx>feprx]
end_feprx --> rx_nr_prach_ru
rx_nr_prach_ru -- block_queue --> resp_L1>resp L1]
resp_L1 -- async launch --> rx_func
resp_L1 -- immediate return --> RFin
subgraph rxfunc
rx_func_implem[rx_func]
subgraph rxfuncbeg
handle_nr_slot_ind
--> rnti_to_remove-mgmt
--> L1_nr_prach_procedures
--> apply_nr_rotation_ul
end
subgraph phy_procedures_gNB_uespec_RX
fill_ul_rb_mask
--> pucch(decode each gNB->pucch)
-->nr_fill_ul_indication
--> nr_ulsch_procedures
--> nr_ulsch_decoding
--> segInParallel[[all segments decode in parallel]]
--> barrier_end_of_ulsch_decoding
end
subgraph NR_UL_indication
handle_nr_rach
--> handle_nr_uci
--> handle_nr_ulsch
--> gNB_dlsch_ulsch_scheduler
--> NR_Schedule_response
end
rx_func_implem --> rxfuncbeg
rxfuncbeg --> phy_procedures_gNB_uespec_RX
phy_procedures_gNB_uespec_RX --> NR_UL_indication
-- block_queue --> L1_tx_free2>L1 tx free]
-- async launch --> tx_func
L1_tx_free2 -- send_msg --> rsp((resp_L1))
end
rx_func --> rxfunc
subgraph tx
direction LR
subgraph tx_func2
phy_procedures_gNB_TX
--> dcitop[nr_generate dci top]
--> nr_generate_csi_rs
--> apply_nr_rotation
-- send_msg --> end_tx_func((L1_tx_out))
end
subgraph tx_reorder_thread
L1_tx_out>L1_tx_out]
--> reorder{re order} --> reorder
reorder --> ru_tx_func
reorder --> L1_tx_free((L1_tx_free))
ru_tx_func --> feptx_prec
--> feptx_ofdm
end
tx_func2 --> tx_reorder_thread
end
```
This tuto for 5G gNB design, with Open Cells main
{: .text-center}
# The main thread is in ru_thread()
The infinite loop:
## rx_rf()
Collect radio signal samples from RF board
all SDR processing is triggered by I/Q sample reception and it's date (timestamp)
TX I/Q samples will have a date in the future, compared to RX timestamp
called for each 5G NR slot
it blocks until data is available
the internal time comes from the RF board sampling numbers
(each sample has a incremental number representing a very accurate timing)
raw incoming data is in buffer called "rxdata"
We derivate frame number, slot number, ... from the RX timestamp
{: .func2}
## nr_fep_full()
"front end processing" of uplink signal
performs DFT on the signal
same function (duplicates): phy_procedures_gNB_common_RX()
it computes the buffer rxdataF (for frequency) from rxdata (samples over time)
rxdataF is the rxdata in frequency domain, phase aligned
{: .func3}
## gNB_top()
only compute frame numbre, slot number, ...
{: .func3}
## ocp_rxtx()
main processing for both UL and DL
start by calling oai_subframe_ind() that trigger processing in pnf_p7_subframe_ind() purpose ???
all the context is in the passed structure UL_INFO
the context is not very clear: there is a mutex on it,
but not actual coherency (see below handle_nr_rach() assumes data is up-to-date)
The first part (in NR_UL_indication, uses the data computed by the lower part (phy_procedures_gNB_uespec_RX), but for the **previous** slot
Then, phy_procedures_gNB_uespec_RX will hereafter replace the data for the next run
This is very tricky and not thread safe at all.
{: .func3}
### NR_UL_indication()
This block processes data already decoded and stored in structures behind UL_INFO
{: .func4}
* handle_nr_rach()
process data from RACH primary detection
if the input is a UE RACH detection
{: .func4}
* nr_schedule_msg2()
{: .func4}
* handle_nr_uci()
handles uplink control information, i.e., for the moment HARQ feedback.
{: .func4}
* handle_nr_ulsch()
handles ulsch data prepared by nr_fill_indication()
{: .func4}
* gNB_dlsch_ulsch_scheduler ()
the **scheduler** is called here, see dedicated chapter
{: .func4}
* NR_Schedule_response()
process as per the scheduler decided
{: .func4}
### L1_nr_prach_procedures()
????
{: .func4}
### phy_procedures_gNB_uespec_RX()
* nr_decode_pucch0()
actual CCH channel decoding form rxdataF (rx data in frequency domain)
populates UL_INFO.uci_ind, actual uci data is in gNB->pucch
{: .func4}
* nr_rx_pusch()
{: .func4}
* extracts data from rxdataF (frequency transformed received data)
{: .func4}
* nr_pusch_channel_estimation()
{: .func4}
* nr_ulsch_extract_rbs_single()
{: .func4}
* nr_ulsch_scale_channel()
{: .func4}
* nr_ulsch_channel_level()
{: .func4}
* nr_ulsch_channel_compensation()
{: .func4}
* nr_ulsch_compute_llr()
this function creates the "likelyhood ratios"
{: .func4}
* nr_ulsch_procedures()
{: .func4}
* actual ULsch decoding
{: .func4}
* nr_ulsch_unscrambling()
{: .func4}
* nr_ulsch_decoding()
{: .func4}
* nr_fill_indication()
populate the data for the next call to "NR_UL_indication()"
it would be better to call **NR_UL_indication()** now instead of before (on previous slot)
{: .func4}
### phy_procedures_gNB_TX()
* nr_common_signal_procedures()
generate common signals
{: .func4}
* nr_generate_dci_top()
generate DCI: the scheduling informtion for each UE in both DL and UL
{: .func4}
* nr_generate_pdsch()
generate DL shared channel (user data)
{: .func4}
### nr_feptx_prec()
tx precoding
{: .func3}
### nr_feptx0
do the inverse DFT
{: .func3}
### tx_rf()
send radio signal samples to the RF board
the samples numbers are the future time for these samples emission on-air
{: .func3}
# Scheduler
The main scheduler function is called by the chain: nr_ul_indication()=>gNB_dlsch_ulsch_scheduler()
It calls sub functions to process each physical channel (rach, ...)
The scheduler uses and internal map of used RB: vrb_map and vrb_map_UL, so each specific channel scheduler can see the already filled RB in each subframe (the function gNB_dlsch_ulsch_scheduler() clears these two arrays when it starts)
The scheduler also calls "run_pdcp()", as this is not a autonomous thread, it needs to be called here to update traffic requests (DL) and to propagate waiting UL to upper layers
After calling run_pdcp, it updates "rlc" time data but it doesn't actually process rlc
it sends a iiti message to activate the thread for RRC, the answer will be asynchronous in ????
Calls schedule_nr_mib() that calls mac_rrc_nr_data_req() to fill MIB,
Calls schedule_nr_prach() which schedules the (fixed) PRACH region one frame in
advance.
Calls nr_csi_meas_reporting() to check when to schedule CSI in PUCCH.
Calls nr_schedule_RA(): checks RA process 0's state. Schedules Msg.2 via
nr_generate_Msg2() if an RA process is ongoing, and pre-allocates the Msg. 3
for PUSCH as well.
Calls nr_schedule_ulsch(): It is divided into the "preprocessor" and the
"postprocessor": the first makes the scheduling decisions, the second fills
nFAPI structures to indicate to the PHY what it is supposed to do. To signal
which users have how many resources, the preprocessor populates the
NR_sched_pusch_t (for values changing every TTI, e.g., frequency domain
allocation) and NR_sched_pusch_save_t (for values changing less frequently, at
least in FR1 [to my understanding], e.g., DMRS fields when the time domain
allocation stays between TTIs) structures. Furthermore, the preprocessor is an
exchangeable module that schedules differently based on a particular
use-case/deployment type, e.g., one user for phytest [in
nr_ul_preprocessor_phytest()], multiple users in FR1
[nr_fr1_ulsch_preprocessor()], or maybe FR2 [does not exist yet]:
* calls preprocessor via pre_processor_ul(): the preprocessor is responsible
for allocating CCEs (using allocate_nr_CCEs()) and deciding on resource
allocation for the UEs including TB size. Note that we do not yet have
scheduling requests. What it typically does:
1) check whether the current frame/slot plus K2 is an UL slot, and return if
not.
2) Find first free start RB in vrb_map_UL, and as many free consecutive RBs
as possible.
3) Either set up resource allocation directly (e.g., for a single UE,
phytest), or call into a function to perform actual resource allocation.
Currently, this is done using pf_ul() which implements a basic
proportional fair scheduler:
* for every UE, check for retransmission and allocate as necessary
* Calculate DMRS stuff (nr_set_pusch_semi_static())
* Calculate the PF coefficient and put eligible UEs into a list
* Allocate resources to the UE(s) with the highest coefficient
4) Mark used resources in vrb_map_UL.
* loop through all users: get a HARQ process as indicated through the
preprocessor, update statistics, fill nFAPI structures directly for PUSCH,
and call config_uldci() and fill_dci_pdu_rel15() for DCI filling and PDCCH
messages.
Calls nr_schedule_ue_spec(). It is divided into the "preprocessor" and the
"postprocessor": the first makes the scheduling decisions, the second fills
nFAPI structures to indicate to the PHY what it is supposed to do. To signal
which users have how many resources, the preprocessor populates the
NR_UE_sched_ctrl_t structure of affected users. In particular, the field rbSize
decides whether a user is to be allocated. Furthermore, the preprocessor is an
exchangeable module that schedules differently based on a particular
use-case/deployment type, e.g., one user for phytest [in
nr_preprocessor_phytest()], multiple users in FR1
[nr_fr1_dlsch_preprocessor()], or maybe FR2 [does not exist yet].
* calls preprocessor via pre_processor_dl(): the preprocessor is responsible
for allocating CCEs and PUCCH (using allocate_nr_CCEs() and
nr_acknack_scheduling()) and deciding on the frequency/time domain
allocation including the TB size. What it typically does:
1) Check available resources in the vrb_map
2) Checks the quantity of waiting data in RLC
3) Either set up resource allocation directly (e.g., for a single UE,
phytest), or call into a function to perform actual resource allocation.
Currently, this is done using pf_dl() which implements a basic
proportional fair scheduler:
* for every UE, check for retransmission and allocate as necessary
* Calculate the PF coefficient and put eligible UEs into a list
* Allocate resources to the UE(s) with the highest coefficient
4) Mark taken resources in the vrb_map
* loop through all users: check if a new TA is necessary. Then, if a user has
allocated resources, update statistics (round, sent bytes), update HARQ
process information, and fill nFAPI structures (allocate a DCI and PDCCH
messages, TX_req, ...)
# RRC
RRC is a regular thread with itti loop on queue: TASK_RRC_GNB
it receives it's configuration in message NRRRC_CONFIGURATION_REQ, then real time mesages for all events: S1/NGAP events, X2AP messages and RRC_SUBFRAME_PROCESS
RRC_SUBFRAME_PROCESS message is send each subframe
how does it communicate to scheduler ?
# RLC
RLC code is new implementation, not using OAI mechanisms: it is implemented directly on pthreads, ignoring OAI common functions.
It is a library, running in thread RRC but also in PHY layer threads and some bits in pdcp running thread or F1 interface threads.
RLC data is isolated and encapsulated.
It is stored under a global var: nr_rlc_ue_manager
The init function rlc_module_init() populates this global variable.
A small effort could lead us to return the pointer to the caller of rlc_module_init() (internal type: nr_rlc_ue_manager_internal_t)
but it returns void.
It could return the initialized pointer (as FILE* fopen() for example), then the RLC layer could have multiple instances in one process.
Even, a future evolution could remove this global rlc layer: rlc can be only a library that we create a instance for each UE because it doesn't shareany data between UEs.
For DL (respectively from UL in UE), the scheduler need to know the quantity of data waitin to be sent: it calls mac_rlc_status_ind()
That "peek" the size of the waiting data for a UE.
The scheduler then push orders to lower layers. The transport layer will actually pull data from RLC with: mac_rlc_data_req()
the low layer push data into rlc by: mac_rlc_data_ind()
Still on DL (gNB side), PDCP push incoming data into RLC by calling: rlc_data_req()
For UL, the low layer push data into rlc by: mac_rlc_data_ind()
Then, rlc push it to pdcp by calling pdcp_data_ind() from a complex rlc internal call back (deliver_sdu())
When adding a UE, external code have to call nr_rrc_rlc_config_asn1_req(), to remove it: rrc_rlc_remove_ue()
Inside UE, channels called drd or srb can be created: ??? and deleted: rrc_rlc_config_req()
nr_rlc_tick() must be called periodically to manage the internal timers
successful_delivery() and max_retx_reached(): in ??? trigger, the RLC sends a itti message to RRC: RLC_SDU_INDICATION (neutralized by #if 0 right now)
#PDCP
The PDCP implementation is also protected through a general mutex.
The design is very similar to rlc layer. The pdcp data is isolated and encapsulated.
pdcp_layer_init(): same as rlc init
we have to call a second init function: pdcp_module_init()
At Tx side (DL in gNB), pdcp_data_req() is the entry function that the upper layer calls.
The upper layer can be GTP or a PDCP internal thread enb_tun_read_thread() that read directly from Linux socket in case we skip 3GPP core implementation.
PDCP internals for pdcp_data_req() is thread safe: inside pdcp_data_req_drb(), the pdcp manager protects with the mutex the access to the SDU receiving function of PDCP (recv_sdu() callback, corresponding to nr_pdcp_entity_drb_am_recv_sdu() for DRBs). When it needs, the pdcp layer push this data to rlc by calling : rlc_data_req()
Also, incoming downlink sdu can comme from internal RRC: in this case, pdcp_run() reads a itti queue, for message RRC_DCCH_DATA_REQ, to0 only call 'pdcp_data_req()'
At Rx side, pdcp_data_ind() is the entry point that receives the data from RLC.
- Inside pdcp_data_ind(), the pdcp manager mutex protects the access to the PDU receiving function of PDCP (recv_pdu() callback corresponding to nr_pdcp_entity_drb_am_recv_pdu() for DRBs)
- Then deliver_sdu_drb() function sends the received data to GTP thread through an ITTI message (GTPV1U_ENB_TUNNEL_DATA_REQ).
pdcp_config_set_security(): not yet developped
nr_DRB_preconfiguration(): the mac layer calls this for ???
nr_rrc_pdcp_config_asn1_req() adds a UE in pdcp, pdcp_remove_UE() removes it
# GTP
Gtp + UDP are two twin threads performing the data plane interface to the core network
The design is hybrid: thread and inside other threads calls. It should at least be protected by a mutex.
## GTP thread
Gtp thread has a itti interface: queue TASK_GTPV1_U
The interface is about full definition: control messages (create/delet GTP tunnels) and data messages (user plane UL and DL).
PDCP layer push to the GTP queue (outside UDP thread that do almost nothing and work only with GTP thread) is to push a UL packet.
## GTP thread running code from other layers
gtp thread calls directly pdcp_data_req(), so it runs inside it's context internal pdcp structures updates
## inside other threads
gtpv1u_create_s1u_tunnel(), delete tunnel, ... functions are called inside the other threads, without mutex.
# New GTP
## initialization
gtpv1uTask(): this creates only the thread, doesn't configure anything
gtpv1Init(): creates a listening socket to Linux for a given reception and select a local IP address
## newGtpuCreateTunnel()
this function will replace the xxx_create_tunnel_xxx() for various cases
The parameters are:
1. outgoing TEid, associated with outpoing pair(rnti, id)
2. incoming packets callback, incoming pair(rnti,id) and a callback function for incoming data
## outgoing packets
Each call to newGtpuCreateTunnel() creates a outgoing context for a teid (given as function input), a pair(rnti,outgoing id).
Each outgoing packet received on GTP-U ITTI queue must match one pair(rnti,id), so the gtp-u thread can lookup the related TEid and use it to encode the outpoing GTP-U tunneled packet.
## incoming packets
newGtpuCreateTunnel() computes and return the incoming teid that will be used for incoming packets.
When a incoming packet arrives on this incoming teid, the GTP-U thread calls the defined callback, with the associated pair(rnti, incoming id).
stuff like enb_flag, mui and more important data are not given explicitly by any legacy function (gtpv1u_create_s1u_tunnel), but the legacy and the new interface to lower layer (like pdcp) require this data. We hardcode it in first version.
## remaining work
These teids and "instance", so in a Linux socket: same teid can co-exist for different sockets
Remain here a lack to fill: the information given in the legacy funtions is not enough to fullfil the data needed by the callback
Coexistance until full merge with legacy GTP
cmake new option: NEW_GTPU to use the new implementation (it changes for the entire executable)
It is possible to use both old and new GTP in same executable because the itti task and all functions names are different
Current status of new implementation: not tested, X2 not developped, 5G new GTP option not developped, remain issues on data coming from void: muid, enb_flag, ...
# NGAP
NGAP would be a itti thread as is S1AP (+twin thread SCTP that is almost void processing)?
About all messages are exchanged with RRC thread
<div class="panel panel-info">
**Note**
{: .panel-heading}
<div class="panel-body">
</div>
</div>
doc/SystemX-tutorial-design.md deleted 100644 → 0
View file @ bbee4d98
# OpenAirInterface for SystemX
# Terminology
****This document use the 5G terminology****
**Central Unit (CU):** It is a logical node that includes the gNB
functions like Transfer of user data, Mobility control, Radio access
network sharing, Positioning, Session Management etc., except those
functions allocated exclusively to the DU. CU controls the operation of
DUs over front-haul (Fs) interface. A central unit (CU) may also be
known as BBU/REC/RCC/C-RAN/V-RAN/VNF
**Distributed Unit (DU):** This logical node includes a subset of the
gNB functions, depending on the functional split option. Its operation
is controlled by the CU. Distributed Unit (DU) also known with other
names like RRH/RRU/RE/RU/PNF.
In OpenAir code, the terminology is often RU and BBU.
# OpenAirUsage
## EPC and general environment
### OAI EPC
Use the stable OAI EPC, that can run in one machine (VM or standalone)
Draft description:
<https://open-cells.com/index.php/2017/08/22/all-in-one-openairinterface-august-22nd/>
## Standalone 4G
EPC+eNB on one machine, the UE can be commercial or OAI UE.
### USRP B210
Main current issue: traffic is good only on coaxial link between UE and
eNB (probably power management issue).
### Simulated RF
Running eNB+UE both OAI can be done over a virtual RF link.
The UE current status is that threads synchronization is implicit in
some cases. As the RF simulator is very quick, a “sleep()” is required
in the UE main loop
(line 1744, targets/RT/USER/lte-ue.c).
Running also the UE in the same machine is possible with simulated RF.
Running in same machine is simpler, offers about infinite speed for
virtual RF samples transmission.
A specific configuration is required because the EPC Sgi interface has
the same IP tunnel end point as the UE.
So, we have to create a network namespace for the UE and to route data
in/out of the namespace.
```bash
ip netns delete aNameSpace 2&gt; /dev/null
ip link delete v-eth1 2&gt; /dev/null
ip netns add aNameSpace
ip link add v-eth1 type veth peer name v-peer1
ip link set v-peer1 netns aNameSpace
ip addr add 10.200.1.1/24 dev v-eth1
ip link set v-eth1 up
iptables -t nat -A POSTROUTING -s 10.200.1.0/255.255.255.0 -o enp0s31f6 \
-j MASQUERADE
iptables -A FORWARD -i enp0s31f6 -o v-eth1 -j ACCEPT
iptables -A FORWARD -o enp0s31f6 -i v-eth1 -j ACCEPT
ip netns exec aNameSpace ip link set dev lo up
ip netns exec aNameSpace ip addr add 10.200.1.2/24 dev v-peer1
ip netns exec aNameSpace ip link set v-peer1 up
ip netns exec aNameSpace bash
```
After the last command, the Linux shell is in the new namespace, ready
to run the UE.
To make user plan traffic, the traffic generator has to run in the same
namespace
```bash
ip netns exec aNameSpace bash
```
The traffic genenrator has to specify the interface:
```bash
route add default oaitun_ue1
```
or specify the outgoing route in the traffic generator (like option “-I”
in ping command).
## Split 6 DL 4G
The contract describes to reuse the uplink existing if4p5 and to develop
is this work the downlink “functional split 6”.
The customer required after signature to develop also the uplink
functional split 6. This is accepted, as long as the whole work is
research with no delivery completeness warranty.
### Simulation
To be able to verify the new features and to help in all future
developments, Open Cells added and improved the Rf board simulator
during this contract.
We added the channel modeling simulation, that offer to simulate various
3GPP defined channels.
### Main loop
The main log is in RF simulator is in
`targets/RT/USER/lte-ru.c and targets/RT/USER/lte-enb.c`
As this piece of SW is very complex and doesn’t meet our goals
(functional split 6), a cleaned version replaces these 2 files in
executables/ocp-main.c (PHY/SCHED/prach\_procedures.c is also
replaced by this new file as it only launching the RACH actual work in a
way not compatible with our FS6).
The main loop cadences the I/Q samples reception, signal processing and
I/Q samples sending.
The main loop uses extensively function pointers to call the right
processing function depending on the split case.
A lot of OAI reduntant global variables contains the same semantic data: time,frame, subframe.
The reworked main loop take care of a uniq variable that comes directly from harware: RF board sampling number.
To use OAI, we need to set all OAI variables that derivates from this timestamp value. The function setAllfromTS() implements this.
### Splitted main level
When FS6 is actived, a main loop for DU (du_fs6()) a main loop for CU case replaces the uniq eNB main loop.
Each of these main loops calls initialization of OAI LTE data and the FS6 transport layer initialization.
Then, it runs a infinite loop on: set time, call UL and DL. The time comes from the RF board, so the DU sends the time to the CU.
This is enough for RF board dialog, but the FS6 is higher in SW layers,
we need to cut higher functions inside downlink and uplink procedures.
As much as possible, the FS6 code is in the directory OPENAIR_DIR/executables. When a given OAI piece of code is small or need complex changes, it is reworked in the file fs6-main.c. The functions naming keeps the OAI function name, adding suffix _fromsplit() or _tosplit().
When this organization would lead to large code copy, it is better to insert modifications in OAI code. This is done in two files:
- PHY/SCHED/phy_procedures_lte_eNb.c: to send signaling channels computation results
- the function sendFs6Ulharq() centralizes all signaling channels forwarding to CU
- PHY/PHY/LTE_TRANSPORT/ulsch_decoding.c: to deal with FS6 user plane split
- sendFs6Ul() is used once to forward user plane to CU
### DownLink
The main procedure is phy\_procedures\_eNB\_TX()
This is building the common channels (beacon, multi-UE signaling).
The FS6 split breaks this function into pieces:
* The multi-UE signals, built by common\_signal\_procedures(),
subframe2harq\_pid(), generate\_dci\_top(), subframe2harq\_pid()
* These functions run in the DU, nevertheless all context has to be sent
(it is also needed partially for UL spitting)
* Run in the DU also to meet the requirement of pushing
in DU the data encoded with large redundancy (&gt;3 redundancy)
* the per UE data: pdsch\_procedures() needs further splitting:
* dlsch\_encoding\_all() that makes the encoding: turbo code
and lte\_rate\_matching\_turbo() that will be in the DU (some
unlikely cases can reach redundancy up to x3, when MCS is very
low (negative SINR cases)).
* dlsch\_encoding() output needs to be transmitted between the
DU and the CU for functional split 6.
* dlsch\_scrambling() that will go in the DU
* dlsch\_modulation() that will go in the DU
The du user plane data is made of expanded bit in OAI at FS6 split level. 1 pair of functions compact back these bits into 8bits/byte before sending data and expand it again in the DU data reception (functions: fs6Dl(un)pack()).
### Uplink
The uplink require configuration that is part of the DL transmission.
It interprets the signalling to extract the RACH and the per UE data
channels.
Ocp-main.c:rxtx() calls directly the entry procedure
phy\_procedures\_eNB\_uespec\_RX() calls:
* rx\_ulsch() that demodulate and extract soft bits per UE.
* This function runs in the DU
* the output data will be processes in the DU, so it needs to be
transmitted to the DU
* ulsch\_decoding() that do lte\_rate\_matching\_turbo\_rx()
sub\_block\_deinterleaving\_turbo()
then turbo decode that is in the CU
* fill\_ulsch\_cqi\_indication() fill\_crc\_indication() , fill\_rx\_indication()
* DU performs the signal processing of each channel data, prepare and sent to the CU the computed result
* Random access channel detection runs in the DU
* the DU reports to the CU only the detected temprary identifier for RACH response
### signaling data in each direction (UL and DL)
* each LTE channel needs to be propagated between CU and DU
* the simplest are the almost static data such as PSS/SSS, that need only static eNB parameters and primary information (frame numbering)
* all the other channels require data transmission CU to DU and DU to CU
* the general design push all the low level processing for these channels in the DU
* the CU interface transports only signal processing results (UL) or configuration to create the RF signal (DL case)
* HARQ is detected in the DU, then only the ACK or NACK is reported to CU
* the CU have to control the power and MCS (modulation and coding scheme)
* the DU performs the signal processing and report only the decoded data like the CQI
* as the DU performas the modulation, scrambling and puncturing, each data packet is associated with the LTE parameters required for these features
* in DL, the CU associates the control parameters and the user plane data
* in UL, the CU sends upfront the scheduled UL data to the DU. So, the DU have the required knowledge to decode the next subframes in time.
### UDP transport layer
A general UDP transport layer is in executables/transport\_split.c
Linux offers a UDP socket builtin timeout, that we use.
In and out buffers are memory zones that contains compacted
(concatenated) UDP chunks.
For output, sendSubFrame() sends each UDP chunk
For input, receiveSubFrame() collects all UDP chunks for a group (a
subframe in OAI LTE case). It returns in the following cases:
- all chunks are received
- a timeout expired
- a chunk from the next subframe already arrived
### Functional split 6 usage
The ocp cleaned main hale to be used: run ocp-softmodem instead of
lte-softmodem.
The functionality and parameters is the same, enhanced with FS6 mode.
The end line option “--split73” enables the fs6 (also called split 7.3) mode and decided to be cu or du.
Example:
```bash
./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 cu:127.0.0.1
```
Run the CU init of the split 6 eNB, that will call du on 127.0.0.1 address
```bash
./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 du:127.0.0.1
```
will run the du, calling the cu on 127.0.0.1
If the CU and the DU are not on the same machine, the remote address of each side need to be specified as per this example
```bash
./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 du:192.168.1.55
```
runs the functional split 6 DU
```bash
./lte-uesoftmodem -C 2685000000 -r 50 --rfsim --rfsimulator.serveraddr 192.168.1.1 -d
```
Runs the UE (to have the UE signal scope, compile it with make uescope)
CU+DU+UE can run with option `--noS1` to avoid to use a EPC and/or with `--rfsim` to simulate RF board
## 5G and F1
Today 5G achievement is limited to physical layer.
The available modulation is 40MHz, that require one X310 or N300 for the
gNB and a X310 or N300 for the nrUE.
### Usage with X310
Linux configuration:
<https://files.ettus.com/manual/page_usrp_x3x0_config.html>
We included most of this configuration included in OAI source code.
Remain to set the NIC (network interface card) MTU to 9000 (jumbo
frames).
### Running 5G
Usage with RFsimulator:
**gNB**
```bash
sudo RFSIMULATOR=server ./nr-softmodem -O \
../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf \
--parallel-config PARALLEL\_SINGLE\_THREAD
```
**nrUE**
```bash
sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem --numerology 1 -r 106 -C \
3510000000 -d
```
doc/TESTBenches.md deleted 100644 → 0
View file @ bbee4d98
## Table of Contents ##
1. [Legacy 1 Bench](#legacy-1-bench)
2. [Legacy 2 Bench](#legacy-2-bench)
3. [Next Bench for DEV](#next-bench-for-dev)
4. [Next Bench for CI](#next-bench-for-ci)
5. [Indoor Live Network Bench](#indoor-live-network-bench)
6. [Outdoor Live Network Bench](#outdoor-live-network-bench)
## Legacy 1 Bench
**Purpose** : FDD Band 7 and Band 13, LTE-M
**Note** : Legacy1 and Legacy2 are duplicated so that they can run in parallel, thus avoiding a CI bottleneck
**Note** : Faraday Cages 1 and 2 are physically the same cage
![image info](./testbenches_doc_resources/legacy1.jpg)
## Legacy 2 Bench
**Purpose** : TDD Band 40, TM2 2xTX 2xRX
**Note** : CN can run in a container, could also run on Massive
![image info](./testbenches_doc_resources/legacy2.jpg)
## Next Bench for DEV
**Note** : Benetel CI can also run on this bench at night
![image info](./testbenches_doc_resources/next_dev.jpg)
## Next Bench for CI
**Note** : The current test running on Caracal could run on this bench with a N300/N300 setup
![image info](./testbenches_doc_resources/next_ci.jpg)
## Indoor Live Network Bench
![image info](./testbenches_doc_resources/indoor_live.jpg)
## Outdoor Live Network Bench
![image info](./testbenches_doc_resources/outdoor_live.jpg)
doc/TESTING_5GSA_setup.md deleted 100644 → 0
View file @ bbee4d98
<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">OAI 5G SA tutorial</font></b>
</td>
</tr>
</table>
**TABLE OF CONTENTS**
1. [SA setup with COTS UE](#1--sa-setup-with-cots-ue)
1. [gNB build and configuration](#11--gnb-build-and-configuration)
2. [OAI 5G Core Network installation and configuration](#12--oai-5g-core-network-installation-and-configuration)
3. [Execution of SA scenario](#13--execution-of-sa-scenario)
2. [SA Setup with OAI NR UE Softmodem](#2-sa-setup-with-oai-nr-ue-softmodem)
1. [Build and configuration](#21-build-and-configuration)
2. [OAI 5G Core Network installation and configuration](#22--oai-5g-core-network-installation-and-configuration)
3. [Execution of SA scenario](#23-execution-of-sa-scenario)
In the following tutorial we describe how to deploy configure and test the two SA OAI setups:
- SA setup with OAI gNB and COTS UE
- SA setup with OAI gNB and OAI UE
The operating system and hardware requirements to support OAI 5G NR are described [here](https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/5g-nr-development-and-setup).
# 1. SA setup with COTS UE
At the moment of writing this document interoperability with the following COTS UE devices is being tested:
- [Quectel RM500Q-GL](https://www.quectel.com/product/5g-rm500q-gl/)
- [Simcom SIMCOM8200EA](https://www.simcom.com/product/SIM8200EA_M2.html)
- Huawei Mate 30 Pro
End-to-end control plane signaling to achieve a 5G SA connection, UE registration and PDU session establishment with the CN, as well as some basic user-plane traffic tests have been validated so far using SIMCOM/Quectel modules and Huawei Mate 30 pro. In terms of interoperability with different 5G Core Networks, so far this setup has been tested with:
- [OAI CN](https://openairinterface.org/oai-5g-core-network-project/)
- Nokia SA Box
- [Free CN](https://www.free5gc.org/)
## 1.1 gNB build and configuration
To get the code and build the gNB executable:
### Ubuntu 18.04
```bash
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
git checkout develop
cd openairinterface5g/
source oaienv
cd cmake_targets/
./build_oai -I -w USRP #For OAI first time installation only to install software dependencies
./build_oai --gNB -w USRP
```
### Ubuntu 20.04
```bash
# Build UHD from source
# https://files.ettus.com/manual/page_build_guide.html
sudo apt-get install libboost-all-dev libusb-1.0-0-dev doxygen python3-docutils python3-mako python3-numpy python3-requests python3-ruamel.yaml python3-setuptools cmake build-essential
git clone https://github.com/EttusResearch/uhd.git
cd uhd/host
mkdir build
cd build
cmake ../
make -j 4
make test # This step is optional
sudo make install
sudo ldconfig
sudo uhd_images_downloader
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
git checkout develop
# Install dependencies in Ubuntu 20.04
cd
cd openairinterface5g/
source oaienv
cd cmake_targets/
./install_external_packages.ubuntu20
# Build OAI gNB
cd
cd openairinterface5g/
source oaienv
cd cmake_targets/
./build_oai --gNB -w USRP
```
A reference configuration file for the **monolithic** gNB is provided [here](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf).
In the following, we highlight the fields of the file that have to be configured according to the configuration and interfaces of the Core Network. First, the PLMN section has to be filled with the proper values that match the configuration of the AMF and the UE USIM.
```bash
// Tracking area code, 0x0000 and 0xfffe are reserved values
tracking_area_code = 1;
plmn_list = ({
mcc = 208;
mnc = 99;
mnc_length = 2;
snssaiList = (
{
sst = 1;
sd = 0x1; // 0 false, else true
},
{
sst = 1;
sd = 0x112233; // 0 false, else true
}
);
});
```
Then, the source and destination IP interfaces for the communication with
the Core Network also need to be set as shown below.
```bash
////////// AMF parameters:
amf_ip_address = ( { ipv4 = "192.168.70.132";
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
NETWORK_INTERFACES :
{
GNB_INTERFACE_NAME_FOR_NG_AMF = "demo-oai";
GNB_IPV4_ADDRESS_FOR_NG_AMF = "192.168.70.129/24";
GNB_INTERFACE_NAME_FOR_NGU = "demo-oai";
GNB_IPV4_ADDRESS_FOR_NGU = "192.168.70.129/24";
GNB_PORT_FOR_S1U = 2152; # Spec 2152
};
```
In the first part (*amf_ip_address*) we specify the IP of the AMF and in the second part (*NETWORK_INTERFACES*) we specify the gNB local interface with AMF (N2 interface) and the UPF (N3 interface).
**CAUTION:** the `192.168.70.132` AMF IF address is the OAI-CN5G `AMF` Container IP address. You certainly will need to do some networking manipulations for the `gNB` server to be able to see this AMF container.
Please read [CN5G tutorial for more details](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/README.md).
### **gNB configuration in CU/DU split mode**
For the configuration of the gNB in CU and DU blocks, the following sample configuration files are provided for the [CU](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/targets/PROJECTS/GENERIC-NR-5GC/CONF/cu_gnb.conf) and the [DU](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/targets/PROJECTS/GENERIC-NR-5GC/CONF/du_gnb.conf) entities respectively. These configuration files have to be updated with the IP addresses of the CU and the DU over the F1 interface. For example, in the following section from the DU configuration file, *local_n_address* corresponds to the DU address and *remote_n_address* corresponds to the CU address:
```bash
MACRLCs = (
{
num_cc = 1;
tr_s_preference = "local_L1";
tr_n_preference = "f1";
local_n_if_name = "lo";
local_n_address = "127.0.0.3";
remote_n_address = "127.0.0.4";
local_n_portc = 601;
local_n_portd = 2152;
remote_n_portc = 600;
remote_n_portd = 2152;
}
);
```
At the point of writing this document the control-plane exchanges between the CU and the DU over *F1-C* interface, as well as some IP traffic tests over *F1-U* have been validated using the OAI gNB/nrUE in RFSIMULATOR mode.
## 1.2 OAI 5G Core Network installation and configuration
The instructions for the installation of OAI CN components (AMF, SMF, NRF, UPF) using `docker-compose` can be found [here](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/README.md).
## 1.3 Execution of SA scenario
After having configured the gNB, we can start the individual components in the following sequence:
- Launch 5G Core Network
- Launch gNB
- Launch COTS UE (disable airplane mode)
The execution command to start the gNB (in monolithic mode) is the following:
```bash
cd cmake_targets/ran_build/build
sudo ./nr-softmodem -E --sa -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf
```
# 2. SA Setup with OAI NR UE Softmodem
The SA setup with OAI UE has been validated with **RFSIMULATOR**. Both control plane and user plane for the successful UE registration and PDU Session establishment has been verified with OAI and Nokia SA Box CNs.
In the following, we provide the instructions on how to build, configure and execute this SA setup.
As another option, if you do not want to build anything and instead deploy the OAI RAN (RFSIMULATOR) and Core Network components directly using docker images and docker-compose, please have a look at [this tutorial](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/ci-scripts/yaml_files/5g_rfsimulator/README.md).
### NAS configuration for the OAI UE
The NAS configuration parameters of the OAI UE can be set as input parameters, configuration file or can be hardcoded. More specifically:
- SUCI (*Subscription Concealed Identifier*)
- USIM_API_K and OPc keys
- NSSAI (*Network Slice Assistance Information*)
- DNN (*Data Network Name*)
Below is a sample configuration file that can be parsed through the execution command ([section 2.3](#23-execution-of-sa-scenario)).
```bash
uicc0 = {
imsi = "208990000007487";
key = "fec86ba6eb707ed08905757b1bb44b8f";
opc= "C42449363BBAD02B66D16BC975D77CC1";
dnn= "oai";
nssai_sst=1;
nssai_sd=1;
}
```
Alternatively, the values can be hardcoded/edited in source file ***UICC/usim_interface.c*** through the following lines:
```bash
#define UICC_PARAMS_DESC {\
{"imsi", "USIM IMSI\n", 0, strptr:&(uicc->imsiStr), defstrval:"2089900007487", TYPE_STRING, 0 },\
{"nmc_size" "number of digits in NMC", 0, iptr:&(uicc->nmc_size), defintval:2, TYPE_INT, 0 },\
{"key", "USIM Ki\n", 0, strptr:&(uicc->keyStr), defstrval:"fec86ba6eb707ed08905757b1bb44b8f", TYPE_STRING, 0 },\
{"opc", "USIM OPc\n", 0, strptr:&(uicc->opcStr), defstrval:"c42449363bbad02b66d16bc975d77cc1", TYPE_STRING, 0 },\
{"amf", "USIM amf\n", 0, strptr:&(uicc->amfStr), defstrval:"8000", TYPE_STRING, 0 },\
{"sqn", "USIM sqn\n", 0, strptr:&(uicc->sqnStr), defstrval:"000000", TYPE_STRING, 0 },\
{"dnn", "UE dnn (apn)\n", 0, strptr:&(uicc->dnnStr), defstrval:"oai", TYPE_STRING, 0 },\
{"nssai_sst", "UE nssai\n", 0, iptr:&(uicc->nssai_sst), defintval:1, TYPE_INT, 0 }, \
{"nssai_sd", "UE nssai\n", 0, iptr:&(uicc->nssai_sd), defintval:1, TYPE_INT, 0 }, \
};
```
For interoperability with OAI or other CNs, it should be ensured that the configuration of the aforementioned parameters match the configuration of the corresponding subscribed user at the core network.
## 2.1 Build and configuration
To build the gNB and OAI UE executables:
```bash
cd cmake_targets
# Note: For OAI first time installation please install software dependencies as described in 1.1.
./build_oai --gNB --nrUE -w SIMU
```
The gNB configuration can be performed according to what is described in [section 1.1](#11--gnb-build-and-configuration), using the same reference configuration file as with the RF scenario.
## 2.2 OAI 5G Core Network installation and configuration
The instructions for the installation of OAI CN components (AMF, SMF, NRF, UPF) using `docker-compose` can be found [here](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/README.md).
## 2.3 Execution of SA scenario
The order of starting the different components should be the same as the one described in [section 1.3](#13--execution-of-sa-scenario).
the gNB can be launched in 2 modes:
- To launch the gNB in `monolithic` mode:
```bash
sudo RFSIMULATOR=server ./nr-softmodem --rfsim --sa \
-O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf
```
- To launch the gNB in `CU/DU split` mode:
1. Launch the CU component:
```bash
sudo RFSIMULATOR=server ./nr-softmodem --rfsim --sa \
-O ../../../ci-scripts/conf_files/gNB_SA_CU.conf
```
2. Launch the DU component:
```bash
sudo RFSIMULATOR=server ./nr-softmodem --rfsim --sa \
-O ../../../ci-scripts/conf_files/gNB_SA_DU.conf
```
- To launch the OAI UE (valid in `monolithic` gNB and `CU/DU split` gNB):
```bash
sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 \
--rfsim --sa --nokrnmod -O <PATH_TO_UE_CONF_FILE>
```
The IP address at the execution command of the OAI UE corresponds to the target IP of the gNB host that the RFSIMULATOR at the UE will connect to. In the above example, we assume that the gNB and UE are running on the same host so the specified address (127.0.0.1) is the one of the loopback interface.
doc/TESTING_GNB_W_COTS_UE.md deleted 100644 → 0
View file @ bbee4d98
STATUS 2020/10/15 : added External Resources section and links
## Table of Contents ##
1. [External Resources](#external-resources)
2. [Configuration Overview](#configuration-overview)
3. [SW Repository / Branch](#repository)
4. [Architecture Setup](#architecture-setup)
5. [Build / Install](#build-and-install)
6. [Run / Test](#run-and-test)
7. [Test case](#test-case)
8. [Log file monitoring](#log-file-monitoring)
9. [Required tools for debug](#required-tools-for-debug)
10. [Status of interoperability](#status-of-interoperability)
11. [CI integration](#ci-integration)
## External Resources
Additional Resources to this page can be found here (special mention to Walter Maguire <wmaguire@live.com>) :
https://docs.google.com/document/d/1pL8Szm0ocGxdl5ESVp12Ff71a4PbhCb9SpvbLZzwYbo/edit?usp=sharing
At time of writing, the openairinterface5G Commit Tag is 2020.w39
Faraday Cages can be found here :
http://www.saelig.com/MFR00066/ste2300.htm
## Configuration Overview
* Non Standalone (NSA) configuration : initial Control Plane established between UE and RAN eNB, then User Plane established between UE and gNB, Core network is 4G based supporting rel 15
* OAI Software Defined gNB and eNB
* eNB RF front end: USRP (ETTUS) B200 Mini or B210
* gNB RF front end: USRP (ETTUS) B200 Mini or B210 (N310 will be needed for MIMO and wider BW's)
* 5G TDD duplexing mode
* 5G FR1 Band n78 (3.5 GHz)
* BW: 40MHz
* Antenna scheme: SISO
## COTS UEs
Our code might not work with all 5G phones yet, but we are constantly improving it. Here is a list of COTS UEs that we know that work with OAI.
* Oppo Reno 5G
* Samsung A90 5G
* Samsung A42 5G
* Google Pixel 5G (note1)
* Simcom SIMCOM8200EA
* Quectel RM500Q-GL
Note1: In the version we have at Eurecom, you need to set the PLMN to 50501, and you also need to change the firmware to "11.0.0 (RD1A.201105.003.B1, Nov 2020, EU carriers)" (see https://developers.google.com/android/images)
## Repository
https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop
## Architecture Setup
The scheme below depicts our typical setup:
![image info](./testing_gnb_w_cots_ue_resources/oai_fr1_setup.jpg)
The photo depicts the FR1 setup part of the scheme above:
![image info](./testing_gnb_w_cots_ue_resources/oai_fr1_lab.jpg)
## Build and Install
General guidelines to build eNB and gNB :
See https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/doc/BUILD.md#building-ues-enodeb-and-gnodeb-executables
- **eNB**
```
cd <your oai installation directory>/openairinterface5g/
source oaienv
cd cmake_targets/
./build_oai -I -w USRP --eNB
```
- **gNB**
```
cd <your oai installation directory>/openairinterface5g/
source oaienv
cd cmake_targets/
./build_oai -I -w USRP --gNB
```
- **EPC**
for reference:
https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
## Configuration Files
Each component (EPC, eNB, gNB) has its own configuration file.
These config files are passed as arguments of the run command line, using the option -O \<conf file\>
The **REFERENCE** files for eNB and gNB, **used by the CI**, can be found here:
[enb conf file](../ci-scripts/conf_files/enb.band7.tm1.fr1.25PRB.usrpb210.conf)
[gnb conf file](../ci-scripts/conf_files/gnb.band78.tm1.fr1.106PRB.usrpb210.conf)
These files have to be updated manually to set the IP addresses and frequency.
**ATTENTION** : an **EXTERNAL** clock is used to sync the eNB and gNB,
whether the clock is internal or external is defined in the configuration files (!! details needed !!)
1- In the **eNB configuration file** :
- look for MME IP address, and update the **ipv4 field** with the IP address of the **EPC** server
```
////////// MME parameters:
mme_ip_address = ( { ipv4 = "**YOUR_EPC_IP_ADDR**";
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
```
- look for S1 IP address, and update the **3 fields below** with the IP address of the **eNB** server
```
NETWORK_INTERFACES :
{
ENB_INTERFACE_NAME_FOR_S1_MME = "eth0";
ENB_IPV4_ADDRESS_FOR_S1_MME = "**YOUR_ENB_IP_ADDR**";
ENB_INTERFACE_NAME_FOR_S1U = "eth0";
ENB_IPV4_ADDRESS_FOR_S1U = "**YOUR_ENB_IP_ADDR**";
ENB_PORT_FOR_S1U = 2152; # Spec 2152
ENB_IPV4_ADDRESS_FOR_X2C = "**YOUR_ENB_IP_ADDR**";
ENB_PORT_FOR_X2C = 36422; # Spec 36422
};
```
2- In the **gNB configuration file** :
- look for MME IP address, and update the **ipv4 field** with the IP address of the **EPC** server
```
////////// MME parameters:
mme_ip_address = ( { ipv4 = "**YOUR_EPC_IP_ADDR**";
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
```
- look for X2 IP address, and update the **4 fields** with the IP address of the **eNB** server / **gNB** server as below (notice : even if -in principle- S1 MME is not required for gNB setting)
```
///X2
enable_x2 = "yes";
t_reloc_prep = 1000; /* unit: millisecond */
tx2_reloc_overall = 2000; /* unit: millisecond */
target_enb_x2_ip_address = (
{ ipv4 = "**YOUR_ENB_IP_ADDR**";
ipv6 = "192:168:30::17";
preference = "ipv4";
}
);
NETWORK_INTERFACES :
{
GNB_INTERFACE_NAME_FOR_S1_MME = "eth0";
GNB_IPV4_ADDRESS_FOR_S1_MME = "**YOUR_GNB_IP_ADDR**";
GNB_INTERFACE_NAME_FOR_S1U = "eth0";
GNB_IPV4_ADDRESS_FOR_S1U = "**YOUR_GNB_IP_ADDR**";
GNB_PORT_FOR_S1U = 2152; # Spec 2152
GNB_IPV4_ADDRESS_FOR_X2C = "**YOUR_GNB_IP_ADDR**";
GNB_PORT_FOR_X2C = 36422; # Spec 36422
};
```
3- The frequency setting requires a manual update in the .C and in the gNB conf file:
In the C file **RRC/LTE/rrc_eNB.c:3217**
set the nrarfcn to the same value as absoluteFrequencySSB in the **gNB config file**, that is **641272** in the example below
C file :
```
MeasObj2->measObject.choice.measObjectNR_r15.carrierFreq_r15 =641272;
```
gNB config file :
```
# absoluteFrequencySSB is the central frequency of SSB
absoluteFrequencySSB = 641272;
dl_frequencyBand = 78;
# the carrier frequency is assumed to be in the middle of the carrier, i.e. dl_absoluteFrequencyPointA_kHz + dl_carrierBandwidth*12*SCS_kHz/2
dl_absoluteFrequencyPointA = 640000;
#scs-SpecificCarrierList
dl_offstToCarrier = 0;
# subcarrierSpacing
# 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
dl_subcarrierSpacing = 1;
dl_carrierBandwidth = 106;
```
## Run and Test
The order to run the different components is important:
1- first, CN
2- then, eNB
3- then, gNB
4- finally, switch UE from airplane mode ON to OFF (ie Radio from OFF to ON)
It is recommended to redirect the run commands to the same log file (fur further analysis and debug), using ```| tee **YOUR_LOG_FILE**``` especially for eNB and gNB.
It is not very useful for the CN.
The test takes typically a few seconds, max 10-15 seconds. If it takes more than 30 seconds, there is a problem.
- **EPC** (on EPC host):
for reference:
https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
- **eNB** (on the eNB host):
Execute:
```
~/openairinterface5g/cmake_targets/ran_build/build$ sudo ./lte-softmodem -O **YOUR_ENB_CONF_FILE** | tee **YOUR_LOG_FILE**
```
- **gNB** (on the gNB host)
**ATTENTION** : for the gNB execution,
The **-E** option is required to enable the tri-quarter sampling rate when using a B2xx serie USRP
The **-E** option is **NOT supported** when using a a N300 USRP
Execute:
```
~/openairinterface5g/cmake_targets/ran_build/build$ sudo ./nr-softmodem -O **YOUR_GNB_CONF_FILE** -E | tee **YOUR_LOG_FILE**
```
## Test Case
The test case corresponds to the UE attachement, that is the UE connection and its initial access in 5G, as depicted below:
**Source** : https://www.sharetechnote.com/html/5G/5G_LTE_Interworking.html
![image info](./testing_gnb_w_cots_ue_resources/attach_signaling_scheme.jpg)
The test reaches step **12. E-RAB modifcation confirmation** , eventhough not all the messages will appear in the log file.
## Log file monitoring
From the log file that is generated, we can monitor several important steps, to assess that the test was successful.
Log files examples can be found here:
[enb log file](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/rh_doc_update_3/doc/testing_gnb_w_cots_ue_resources/oai_enb.log)
[gnb log file](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/rh_doc_update_3/doc/testing_gnb_w_cots_ue_resources/oai_gnb.log)
- eNB receives UE capabilities information, including its NR capabilites, and triggers sGNB Addition Request message:
***eNBlog.1315 :***
```
[RRC] [FRAME 00000][eNB][MOD 00][RNTI 43eb] received ueCapabilityInformation on UL-DCCH 1 from UE
...
[RRC] [eNB 0] frame 0 subframe 0: UE rnti 43eb switching to NSA mode
...
<X2AP-PDU>
<initiatingMessage>
<procedureCode>27</procedureCode>
<criticality><reject/></criticality>
<value>
<SgNBAdditionRequest>
<protocolIEs>
<SgNBAdditionRequest-IEs>
<id>111</id>
<criticality><reject/></criticality>
<value>
<UE-X2AP-ID>0</UE-X2AP-ID>
</value>
</SgNBAdditionRequest-IEs>
```
- gNB receives sGNB Addition request, processes UE capabilities for the corresponding UE and triggers sGNB Addition Request ACK, carrying NR RRC Reconfiguration message:
***gNBlog.2291 :***
```
<X2AP-PDU>
<successfulOutcome>
<procedureCode>27</procedureCode>
<criticality><reject/></criticality>
<value>
<SgNBAdditionRequestAcknowledge>
<protocolIEs>
<SgNBAdditionRequestAcknowledge-IEs>
<id>111</id>
<criticality><reject/></criticality>
<value>
<UE-X2AP-ID>0</UE-X2AP-ID>
</value>
</SgNBAdditionRequestAcknowledge-IEs>
```
- Upon reception of the sGNB Addition Request ACK, the eNB sends a new RRCConnectionReconfiguration message containing the NR Reconfiguration.
The UE replies with a Reconfiguration Complete message:
***eNBlog.1686 :***
```
[RRC] [FRAME 00000][eNB][MOD 00][RNTI 43eb] UE State = RRC_RECONFIGURED (default DRB, xid 1)
```
- The Random Access procedure of the UE to the gNB takes place:
***gNBlog.2382 :***
```
[PHY] [gNB 0][RAPROC] Frame 751, slot 19 Initiating RA procedure with
preamble 63, energy 35.7 dB, delay 6
[0m [0m[MAC] [gNB 0][RAPROC] CC_id 0 Frame 751, Slot 19 Initiating RA
procedure for preamble index 63
[0m [0m[MAC] [gNB 0][RAPROC] CC_id 0 Frame 751 Activating Msg2
generation in frame 752, slot 7 using RA rnti 10b
[0m [0m[MAC] [gNB 0] [RAPROC] CC_id 0 Frame 752, slotP 7: Generating
RAR DCI, state 1
[0m [0m[MAC] [RAPROC] DCI type 1 payload: freq_alloc 120 (0,6,24),
time_alloc 3, vrb to prb 0, mcs 0 tb_scaling 0
[0m [0m[MAC] Frame 752: Subframe 7 : Adding common DL DCI for RA_RNTI 10b
[0m [0m[MAC] Frame 752, Subframe 7: Setting Msg3 reception for Frame
752 Subframe 17
[0m [0m[PHY] ULSCH received ok
```
- The eNB triggers the path switch procedure towards the MME, so that
the traffic can be routed now from the SGW towards the gNB on the S1-U
plane.
***eNBlog.1691 :***
```
<S1AP-PDU>
<initiatingMessage>
<procedureCode>50</procedureCode>
<criticality><reject/></criticality>
<value>
<E-RABModificationIndication>
<protocolIEs>
<E-RABModificationIndicationIEs>
<id>0</id>
<criticality><reject/></criticality>
<value>
<MME-UE-S1AP-ID>553648130</MME-UE-S1AP-ID>
</value>
</E-RABModificationIndicationIEs>
```
Eventually, step **12. E-RAB Modification Confirmation** is successfully reached
## Required tools for debug
- **Wireshark** to trace X2AP and S1AP protocols
- **Ttracer** for 5G messages
- **GDB debugger** to check function calls
## Status of interoperability
The following parts have been validated with FR1 COTS UE:
- Phone accepts the configurtion provided by OAI eNB:
this validates RRC and X2AP
- Successful Random Access Procedure:
PRACH is correctly decoded at gNB
Phone correctly receives and decodes msg2 (NR PDCCH Format 1_0 and NR PDSCH)
msg3 is transmitted to gNB according to the configuration sent in msg2, and received correctly at gNB
- Successful path switch of user plane traffic from 4G to 5G cell (E-RAB modification message):
this validates S1AP
- Downlink traffic:
PDCCH DCI format 1_1 and correponding PDSCH are decoded correctlyby the phone
ACK/NACK (PUCCH format 0) are successfully received at gNB
- **End-to end UL / DL traffic with HARQ procedures validated (ping, iperf)**
- Known limitations as of September 2020:
DL traffic : 3Mbps
UL traffic : 1Mbps
some packet losses might still occur even in ideal channel conditions
## CI integration
The automation scripts are available on ILIADE.
The end-to-end test is integrated in the CI flow in a semi-automated manner, comprising 3 steps:
- update a YAML file comprising the IT resources definition, branch and commit number the test has to run on
- run the python script that generates the test from the YAML file
```
python3 obj_build_from_yaml.py py_params_template.yaml fr1.sh
```
- run the test (fr1.sh)
At the date of writing, the test comprises the deployment of the components (epc, eNB, gNB, cots ue) and the execution of 2 pings procedures (20 pings in 20sec, then 5 pings in 1sec)
This automation is run for every integration branch to be merged into develop.
doc/d2d_emulator_setup.txt deleted 100644 → 0
View file @ bbee4d98
Scenario 1 : Off-network UE2UE link
SynchREF UE (UE1)
UE1(eth0 - 10.10.10.1)--------UE2(eno1 - 10.10.10.2)
Here's an example of /etc/network/interfaces configuration for UE1
auto eth0
iface eth0 inet static
address 10.10.10.1
netmask 255.255.255.0
gateway 10.10.10.1
Prepare the environment:
- git clone https://gitlab.eurecom.fr/matzakos/LTE-D2D.git #branch: master
This branch contains all the current development for DDPS
- UE MAC<-> UE MAC for Scenario 1
- eNB MAC<->UE MAC (NFAPI Transport)
- RRC Extensions for “on-network” cases
NFAPI configuration (required even for Scenario 1 target)
- git clone https://github.com/cisco/open-nFAPI.git
- cd open-nfapi
- patch -p1 --dry-run < $OPENAIR_HOME/open-nfapi.oai.patch
Validate that there are no errors
- patch -p1 < $OPENAIR_HOME/open-nfapi.oai.patch
OAI build/execute
- export NFAPI_DIR=XXX (place where NFAPI was installed)
- cd cmake_targets
- ./build_oai --UE
(if necessary, use ./build_oai -I --UE to install required packages)
- cd ran_build/build/
- cp ../../../targets/bin/.ue* .
- cp ../../../targets/bin/.usim* .
- sudo insmod ../../../targets/bin/ue_ip.ko
UE1:
- sudo ifconfig oip0 10.0.0.1
- sudo iptables -A POSTROUTING -t mangle -o oip0 -d 224.0.0.3 -j MARK --set-mark 3
- (if necessary) sudo route add default gw 10.10.10.1 eth0
UE2:
- sudo ifconfig oip0 10.0.0.2
- sudo iptables -A POSTROUTING -t mangle -o oip0 -d 224.0.0.3 -j MARK --set-mark 3
- (if necessary) sudo route add default gw 10.10.10.1 eno1
UE1 and UE2: Get and build vencore_app from d2d-l3-stub (branch: l3_stub)
- gcc -I . vencore_app.c -o vencore_app -lpthread
--------------------------------
TEST ONE-TO-MANY
Run UE1 then UE2, for example:
UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
Test with Ping
- Sender - UE1: ping -I oip0 224.0.0.3
- Receiver - UE2: using wireshark
Test with Iperf
- Sender - UE1: iperf -c 224.0.0.3 -u -b 0.1M --bind 10.0.0.1 -t 100
- Receiver - UE2: sudo ./mcreceive 224.0.0.3 5001
Filter the incomming packets according to GroupL2Id: receiver (one-to-many) can discard the packets if it doesn't belong to this group.
For the moment, both sender and receiver use the same set of Ids (hardcoded)
UE1 (sender)
- sudo ./lte-softmodem-stub -U --emul-iface eth0
- ./vencore_app #send the sourceL2Id, groupL2Id to OAI
- ping -I oip0 224.0.0.3
UE2(receiver)
- sudo ./lte-softmodem-stub -U --emul-iface eno1
#we can see the incomming packets from OAI log, however, cannot see from Wireshark -> they are discarded at MAC layer
- ./vencore_app #we can see the packets appearing in Wireshark
--------------------------------------
TEST PC5-S (UE1 -sender, UE2 - receiver) and PC5-U for ONE-TO-ONE scenario
Configure UE1/UE2
UE1:
- sudo ifconfig oip0 10.0.0.1
- sudo iptables -A POSTROUTING -t mangle -o oip0 -d 10.0.0.2 -j MARK --set-mark 3
- sudo route add default gw 10.10.10.1 eth0
UE2:
- sudo ifconfig oip0 10.0.0.2
- sudo iptables -A POSTROUTING -t mangle -o oip0 -d 10.0.0.1 -j MARK --set-mark 3
- sudo route add default gw 10.10.10.1 eno1
step 1:
- UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
step 2:
- UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
- UE2: ./vencore_app -r #listen to incomming message from PC5-S
step 3:
- UE1: ./vencore_app -s #send a message via PC5-S (e.g., DirectCommunicationRequest)
Generate unicast traffic
UE1: ping -I oip0 10.0.0.2
--------------------------------------
TEST PC5-D
step 1:
- UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
- UE1: ./vencore_app -d #send a PC5-Discovery-Announcement via PC5D
step 2:
- UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
- UE2: ./vencore_app -d #send a PC5-Discovery-Announcement via PC5D
doc/episys/lte_mode_l2_emulator/README.txt deleted 100644 → 0
View file @ bbee4d98
There are fundamental changes to the L2 emulation mechanism; these changes allow the
user to run multiple UEs in separate Linux processes/machines/VMs/etc. They use a separate
entity between the UE(s) and eNB. The UEs use nFAPI to communicate with the eNB. The
nFAPI interface allows us to run in an emulated layer 2 mode, meaning that we are bypassing
the layer 1 (PHY) functionality. Because we are bypassing the PHY layer,
channel modeling capabilties have been added in the LTE UE phy_stub_ue.c file. To understand
the interfaces between the different components associated with LTE mode, the image
functional_diagram_proxy_lte.png has been provided.
This functionality allows the user to plug in their own channel model and emulate the packet dropping procedure
in real time. The channel modeling has not been provided by EpiSci, but the OAI code
base already has some BLER curves available for use. The channel modeling functionality
that is included in the phy_stub_ue.c file only includes the downlink channel modeling.
Any uplink channel modeling must be conducted in some sort of proxy, which would sit
between the UEs and eNB. (A description of the downlink channel modeling is shown in the
Channel_Abstraction_UE_Handling_LTE.PNG image).
The updates to the OAI code base removed some latent bugs, added multi-UE scalability,
and were tested with a standard bypass proxy between the UE(s) and eNB. The bypass proxy is
publicly available on GitHub (https://github.com/EpiSci/oai-lte-multi-ue-proxy). With this package,
various multi-UE scenarios can be tested without the overhead of PHY-layer features
of underlying radios. The features added in the L2 Emulator Mode for LTE are:
- Ease of use of gprof and address sanitizer for debugging purposes
- Updated json files to allow for GDB, real-time debugging capabilities
- Updated logging features to minimally log only key connection milestones. This improves scalability of multiple UEs.
The logging mechanism described here is located in the log.c and log.h files. The LOG_MINIMAL
function allows us to remove most OAI logging and includes LOG_A(...) logs and above. The LOG_A
logs were chosen as analysis logs to meet EpiSci's internal testing procedure. The LOG_As
only include logs that are considered to be milestones in a given test. For example, a
log indicating that the RACH procedure has been completed for LTE. To select full logging,
set LOG_MINIMAL = 0 in the log.h file.
- Updated logging to include time stamp for timing analysis
- Updated memory allocation procedures to correct size requirements
- Added debugging features to handle signal terminations
- nfapi.c pullarray8 fix invalid pointer math
- Overlapping destination and source memory in memcpy, so updated to memmove to check for this bug
- Advanced error checking mechanisms in critical pack and unpack functions
- Created option for CPU assignment to UE to improve scalability
- Added EPC integration to allow multiple individual UE entities to each have their USIM information parsed by the executables
- Updated random value seeds to minimize probability of error in generation of random values
- Enables capability round robin scheduler if desired
- Enables capability real time scheduler if desired
- Added new standalone functions to the UE phy-layer (phy_stub_ue.c) to incorporate individual UE entities
- Updated sending and packing functions in UE (lte_ue.c) to incorporate new standalone changes
- Incorporated semaphores to control timing of incoming downlink packets
- Implemented new queuing system to handle message exchange from UE to eNB and vice versa
- Updated global value in nFAPI for size of subframe
- Updated global value to increase scalability in system
doc/episys/nsa_mode_l2_emulator/README.txt deleted 100644 → 0
View file @ bbee4d98
There are fundamental changes to the L2 emulation mechanism; these changes allow the
user to run multiple UEs in separate Linux processes/machines/VMs/etc. They use a separate
entity between the UE(s) and eNB/gNB. The UEs use nFAPI to communicate with the eNB/gNB. The
nFAPI interface allows us to run in an emulated L2 mode, meaning that we are bypassing
the layer 1 (PHY) layer functionality. Becasue we are bypassing the PHY layer, special
channel modeling capabilty has been added in the LTE UE phy_stub_ue.c file. To understand
the interfaces between the different components associated with NSA mode, the image
functional_diagram_proxy_nsa.png has been provided.
This functionality allows the user to plug in their own channel model and emulate the packet dropping procedure
in real time. The channel modeling has not been provided by EpiSci, but the OAI code
base already has some BLER curves available for use. The chanel modeling functionality
that is included in the phy_stub_ue.c file only includes the downlink channel modeling.
Any uplink channel modeling must be conducted in some sort of proxy, which would sit
between the UEs and eNB/gNB. (A description of the downlink channel modeling is shown in the
Channel_Abstraction_UE_Handling_LTE.PNG image).
The updates to the OAI code base removed some latent bugs, added multi-UE scalability,
and were tested with a standard bypass proxy between the UE(s) and eNB/gNB. The bypass proxy is
publicly available on GitHub (https://github.com/EpiSci/oai-lte-multi-ue-proxy). With this package,
various multi-UE scenarios can be tested without the overhead of PHY-layer features
of underlying radios. The added features to the OAI code base are listed below.
- Ease of use of gprof and address sanitizer for debugging purposes
- Updated json files to allow for GDB, real-time debugging capabilities
- Updated logging features to minimally log only key connection milestones. This improves scalability of multiple UEs.
The logging mechanism described here is located in the log.c and log.h files. The LOG_MINIMAL
function allows us to remove most logs and include LOG_A(...) logs and above. The LOG_A
logs were chosen as analysis logs to meet EpiSci's internal testing procedure. The LOG_As
only include logs that are considered to be milestones in a given test. For example, a
log indicating that the CFRA procedure has been completed for NSA mode. To revert to full logging,
set LOG_MINIMAL = 0 in the log.h file.
- Updated logging to include time stamp for timing analysis
- Updated memory allocation procedures to correct size requirements
- Added debugging features to handle signal terminations
- nfapi.c pullarray8 fix invalid pointer math
- Overlapping destination and source memory in memcpy, so updated to memmove to check for this bug
- Advanced error checking mechanisms in critical pack and unpack functions
- Created option for CPU assignment to UE to improve scalability
- Added EPC integration to allow multiple individual UE entities to each have their USIM information parsed by the executables
- Updated random value seeds to minimize probability of error in generation of random values
- Enables capability round robin scheduler if desired
- Enables capability real time scheduler if desired
- Added new standalone functions to the UE phy-layer (phy_stub_ue.c) to incorporate individual UE entities
- Updated sending and packing functions in UE (lte_ue.c) to incorporate new standalone changes
- Incorporated semaphores to control timing of incoming downlink packets
- Implemented new queuing system to handle message exchange from UE to eNB and vice versa
- Updated global value in nFAPI for size of subframe
- Updated global value to increase scalability in system
Additionally, NSA mode includes the establishment between an NR UE and the gNB via the LTE UE and eNB
connection. For NSA mode, the downlink channel abstraction has not been added to the feature set yet.
NSA mode has been tested and is fully functional with EpiSci's public version of the nFAPI proxy
located at https://github.com/EpiSci/oai-lte-multi-ue-proxy
NSA mode establishment includes the following steps:
- First UE capability enquiry is sent to NR UE
- NR UE updates and fills first capability enquiry
- eNB request for a measurement report
- Measurement request is sent to NR UE
- Measurement report is filled in NR UE
- Measurement report is received in eNB
- Request for second UE capability enquiry
- Send second enquiry to NR UE
- Second capability information is filled by NR UE
- Second capability information is sent to eNB
- NR UE capability information is received in gNB
- Periodic measurement report received in gNB
- RRCReconfigurationRequest is sent to NR UE
- RRCReconfigurationComplete is sent from NR UE
- RACH is received in the gNB
- RAR is received in NR UE
- Msg 3 is generated and sent to gNB
- CFRA procedure is complete
Please note, the current status is:
- A single NSA UE is able to ping an external source
- Up to 4 NSA UEs can complete the CFRA procedure with a single gNB
- UE-to-UE traffic is still in work (incomplete due to gNB crashing)
- The gNB is crashing regularly and is still in work
Test Setup:
For launching the multi-UE for NSA mode, there is a provided test script in the
public EpiSci GitHub multi-ue-proxy repository. However, a brief outline of the
test set up is included below.
If running multiple NSA UEs in a single machine, you will need to launch
multiple LTE and NR UE processes. For example, to launch a 2 NSA UE scenario
there will be a total of 7 processes running for this particular scenario.
These processes are LTE UE #1, LTE UE #2, NR UE #1, NR UE #2, eNB, gNB and the
proxy. A detailed description of the launch processes can be found at
https://github.com/EpiSci/oai-lte-multi-ue-proxy/blob/master/README.md
doc/testing_gnb_w_cots_ue_resources/enb.conf deleted 100755 → 0
View file @ bbee4d98
Active_eNBs = ( "eNB-Eurecom-LTEBox");
# Asn1_verbosity, choice in: none, info, annoying
Asn1_verbosity = "none";
eNBs =
(
{
# real_time choice in {hard, rt-preempt, no}
real_time = "no";
////////// Identification parameters:
eNB_ID = 0xe01;
cell_type = "CELL_MACRO_ENB";
eNB_name = "eNB-Eurecom-LTEBox";
// Tracking area code, 0x0000 and 0xfffe are reserved values
tracking_area_code = 1;
plmn_list = (
{ mcc = 222; mnc = 01; mnc_length = 2; }
);
tr_s_preference = "local_mac"
////////// Physical parameters:
component_carriers = (
{
node_function = "eNodeB_3GPP";
node_timing = "synch_to_ext_device";
node_synch_ref = 0;
nb_antenna_ports = 1;
ue_TransmissionMode = 1;
frame_type = "FDD";
tdd_config = 3;
tdd_config_s = 0;
prefix_type = "NORMAL";
eutra_band = 7;
downlink_frequency = 2680000000L; //2655000000L;
uplink_frequency_offset = -120000000;
Nid_cell = 0;
N_RB_DL = 25; //100;
Nid_cell_mbsfn = 0;
nb_antennas_tx = 1;
nb_antennas_rx = 1;
prach_root = 0;
tx_gain = 90;
rx_gain = 115;
pbch_repetition = "FALSE";
prach_config_index = 0;
prach_high_speed = "DISABLE";
prach_zero_correlation = 1;
prach_freq_offset = 2;
pucch_delta_shift = 1;
pucch_nRB_CQI = 0;
pucch_nCS_AN = 0;
pucch_n1_AN = 0;
pdsch_referenceSignalPower = -29;
pdsch_p_b = 0;
pusch_n_SB = 1;
pusch_enable64QAM = "DISABLE";
pusch_hoppingMode = "interSubFrame";
pusch_hoppingOffset = 0;
pusch_groupHoppingEnabled = "ENABLE";
pusch_groupAssignment = 0;
pusch_sequenceHoppingEnabled = "DISABLE";
pusch_nDMRS1 = 1;
phich_duration = "NORMAL";
phich_resource = "ONESIXTH";
srs_enable = "DISABLE";
/* srs_BandwidthConfig =;
srs_SubframeConfig =;
srs_ackNackST =;
srs_MaxUpPts =;*/
pusch_p0_Nominal = -96;
pusch_alpha = "AL1";
pucch_p0_Nominal = -96;
msg3_delta_Preamble = 6;
pucch_deltaF_Format1 = "deltaF2";
pucch_deltaF_Format1b = "deltaF3";
pucch_deltaF_Format2 = "deltaF0";
pucch_deltaF_Format2a = "deltaF0";
pucch_deltaF_Format2b = "deltaF0";
rach_numberOfRA_Preambles = 64;
rach_preamblesGroupAConfig = "DISABLE";
/*
rach_sizeOfRA_PreamblesGroupA = ;
rach_messageSizeGroupA = ;
rach_messagePowerOffsetGroupB = ;
*/
rach_powerRampingStep = 4;
rach_preambleInitialReceivedTargetPower = -108;
rach_preambleTransMax = 10;
rach_raResponseWindowSize = 10;
rach_macContentionResolutionTimer = 48;
rach_maxHARQ_Msg3Tx = 4;
pcch_default_PagingCycle = 128;
pcch_nB = "oneT";
bcch_modificationPeriodCoeff = 2;
ue_TimersAndConstants_t300 = 1000;
ue_TimersAndConstants_t301 = 1000;
ue_TimersAndConstants_t310 = 1000;
ue_TimersAndConstants_t311 = 10000;
ue_TimersAndConstants_n310 = 20;
ue_TimersAndConstants_n311 = 1;
//Parameters for SIB18
rxPool_sc_CP_Len = "normal";
rxPool_sc_Period = "sf40";
rxPool_data_CP_Len = "normal";
rxPool_ResourceConfig_prb_Num = 20;
rxPool_ResourceConfig_prb_Start = 5;
rxPool_ResourceConfig_prb_End = 44;
rxPool_ResourceConfig_offsetIndicator_present = "prSmall";
rxPool_ResourceConfig_offsetIndicator_choice = 0;
rxPool_ResourceConfig_subframeBitmap_present = "prBs40";
rxPool_ResourceConfig_subframeBitmap_choice_bs_buf = "00000000000000000000";
rxPool_ResourceConfig_subframeBitmap_choice_bs_size = 5;
rxPool_ResourceConfig_subframeBitmap_choice_bs_bits_unused = 0;
/* rxPool_dataHoppingConfig_hoppingParameter = 0;
rxPool_dataHoppingConfig_numSubbands = "ns1";
rxPool_dataHoppingConfig_rbOffset = 0;
rxPool_commTxResourceUC-ReqAllowed = "TRUE";
*/
// Parameters for SIB19
discRxPool_cp_Len = "normal"
discRxPool_discPeriod = "rf32"
discRxPool_numRetx = 1;
discRxPool_numRepetition = 2;
discRxPool_ResourceConfig_prb_Num = 5;
discRxPool_ResourceConfig_prb_Start = 3;
discRxPool_ResourceConfig_prb_End = 21;
discRxPool_ResourceConfig_offsetIndicator_present = "prSmall";
discRxPool_ResourceConfig_offsetIndicator_choice = 0;
discRxPool_ResourceConfig_subframeBitmap_present = "prBs40";
discRxPool_ResourceConfig_subframeBitmap_choice_bs_buf = "f0ffffffff";
discRxPool_ResourceConfig_subframeBitmap_choice_bs_size = 5;
discRxPool_ResourceConfig_subframeBitmap_choice_bs_bits_unused = 0;
}
);
srb1_parameters :
{
# timer_poll_retransmit = (ms) [5, 10, 15, 20,... 250, 300, 350, ... 500]
timer_poll_retransmit = 80;
# timer_reordering = (ms) [0,5, ... 100, 110, 120, ... ,200]
timer_reordering = 35;
# timer_reordering = (ms) [0,5, ... 250, 300, 350, ... ,500]
timer_status_prohibit = 0;
# poll_pdu = [4, 8, 16, 32 , 64, 128, 256, infinity(>10000)]
poll_pdu = 4;
# poll_byte = (kB) [25,50,75,100,125,250,375,500,750,1000,1250,1500,2000,3000,infinity(>10000)]
poll_byte = 99999;
# max_retx_threshold = [1, 2, 3, 4 , 6, 8, 16, 32]
max_retx_threshold = 4;
}
# ------- SCTP definitions
SCTP :
{
# Number of streams to use in input/output
SCTP_INSTREAMS = 2;
SCTP_OUTSTREAMS = 2;
};
enable_measurement_reports = "yes";
////////// MME parameters:
mme_ip_address = ( { ipv4 = "192.168.18.99";
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
///X2
enable_x2 = "yes";
t_reloc_prep = 1000; /* unit: millisecond */
tx2_reloc_overall = 2000; /* unit: millisecond */
t_dc_prep = 1000; /* unit: millisecond */
t_dc_overall = 2000; /* unit: millisecond */
NETWORK_INTERFACES :
{
ENB_INTERFACE_NAME_FOR_S1_MME = "eth1";
ENB_IPV4_ADDRESS_FOR_S1_MME = "192.168.18.199/24";
ENB_INTERFACE_NAME_FOR_S1U = "eth1";
ENB_IPV4_ADDRESS_FOR_S1U = "192.168.18.199/24";
ENB_PORT_FOR_S1U = 2152; # Spec 2152
ENB_IPV4_ADDRESS_FOR_X2C = "192.168.18.199/24";
ENB_PORT_FOR_X2C = 36422; # Spec 36422
};
log_config :
{
global_log_level ="info";
hw_log_level ="info";
phy_log_level ="info";
mac_log_level ="info";
rlc_log_level ="debug";
pdcp_log_level ="info";
rrc_log_level ="info";
};
}
);
MACRLCs = (
{
num_cc = 1;
tr_s_preference = "local_L1";
tr_n_preference = "local_RRC";
phy_test_mode = 0;
puSch10xSnr = 160;
puCch10xSnr = 160;
}
);
THREAD_STRUCT = (
{
parallel_config = "PARALLEL_RU_L1_TRX_SPLITaaaaaa";
worker_config = "WORKER_ENABLE";
}
);
L1s = (
{
num_cc = 1;
tr_n_preference = "local_mac";
}
);
RUs = (
{
local_rf = "yes"
nb_tx = 1
nb_rx = 1
att_tx = 0
att_rx = 0;
bands = [7];
max_pdschReferenceSignalPower = -27;
max_rxgain = 118;
eNB_instances = [0];
}
);
log_config :
{
global_log_level ="info";
hw_log_level ="info";
phy_log_level ="info";
mac_log_level ="info";
rlc_log_level ="info";
pdcp_log_level ="info";
rrc_log_level ="info";
};
doc/testing_gnb_w_cots_ue_resources/gnb.conf deleted 100755 → 0
View file @ bbee4d98
Active_gNBs = ( "gNB-Eurecom-5GNRBox");
# Asn1_verbosity, choice in: none, info, annoying
Asn1_verbosity = "none";
gNBs =
(
{
////////// Identification parameters:
gNB_ID = 0xe00;
cell_type = "CELL_MACRO_GNB";
gNB_name = "gNB-Eurecom-5GNRBox";
// Tracking area code, 0x0000 and 0xfffe are reserved values
tracking_area_code = 1;
plmn_list = ({mcc = 222; mnc = 01; mnc_length = 2;});
tr_s_preference = "local_mac"
////////// Physical parameters:
ssb_SubcarrierOffset = 31; //0;
pdsch_AntennaPorts = 1;
servingCellConfigCommon = (
{
#spCellConfigCommon
physCellId = 0;
# downlinkConfigCommon
#frequencyInfoDL
# this is 3600 MHz + 84 PRBs@30kHz SCS (same as initial BWP)
absoluteFrequencySSB = 641272; //641032; #641968; 641968=start of ssb at 3600MHz + 82 RBs 641032=center of SSB at center of cell
dl_frequencyBand = 78;
# this is 3600 MHz
dl_absoluteFrequencyPointA = 640000;
#scs-SpecificCarrierList
dl_offstToCarrier = 0;
# subcarrierSpacing
# 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
dl_subcarrierSpacing = 1;
dl_carrierBandwidth = 106;
#initialDownlinkBWP
#genericParameters
# this is RBstart=84,L=13 (275*(L-1))+RBstart
initialDLBWPlocationAndBandwidth = 6366; //28875; //6366; #6407; #3384;
# subcarrierSpacing
# 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
initialDLBWPsubcarrierSpacing = 1;
#pdcch-ConfigCommon
initialDLBWPcontrolResourceSetZero = 0;
initialDLBWPsearchSpaceZero = 0;
#uplinkConfigCommon
#frequencyInfoUL
ul_frequencyBand = 78;
#scs-SpecificCarrierList
ul_offstToCarrier = 0;
# subcarrierSpacing
# 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
ul_subcarrierSpacing = 1;
ul_carrierBandwidth = 106;
pMax = 20;
#initialUplinkBWP
#genericParameters
initialULBWPlocationAndBandwidth = 6366; //28875; //6366; #6407; #3384;
# subcarrierSpacing
# 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
initialULBWPsubcarrierSpacing = 1;
#rach-ConfigCommon
#rach-ConfigGeneric
prach_ConfigurationIndex = 98;
#prach_msg1_FDM
#0 = one, 1=two, 2=four, 3=eight
prach_msg1_FDM = 0;
prach_msg1_FrequencyStart = 0;
zeroCorrelationZoneConfig = 13;
preambleReceivedTargetPower = -118;
#preamblTransMax (0...10) = (3,4,5,6,7,8,10,20,50,100,200)
preambleTransMax = 6;
#powerRampingStep
# 0=dB0,1=dB2,2=dB4,3=dB6
powerRampingStep = 1;
#ra_ReponseWindow
#1,2,4,8,10,20,40,80
ra_ResponseWindow = 5;
#ssb_perRACH_OccasionAndCB_PreamblesPerSSB_PR
#1=oneeighth,2=onefourth,3=half,4=one,5=two,6=four,7=eight,8=sixteen
ssb_perRACH_OccasionAndCB_PreamblesPerSSB_PR = 4;
#oneHalf (0..15) 4,8,12,16,...60,64
ssb_perRACH_OccasionAndCB_PreamblesPerSSB = 14; //15;
#ra_ContentionResolutionTimer
#(0..7) 8,16,24,32,40,48,56,64
ra_ContentionResolutionTimer = 7;
rsrp_ThresholdSSB = 19;
#prach-RootSequenceIndex_PR
#1 = 839, 2 = 139
prach_RootSequenceIndex_PR = 2;
prach_RootSequenceIndex = 1;
# SCS for msg1, can only be 15 for 30 kHz < 6 GHz, takes precendence over the one derived from prach-ConfigIndex
#
msg1_SubcarrierSpacing = 1,
# restrictedSetConfig
# 0=unrestricted, 1=restricted type A, 2=restricted type B
restrictedSetConfig = 0,
msg3_DeltaPreamble = 1;
p0_NominalWithGrant =-90;
# pucch-ConfigCommon setup :
# pucchGroupHopping
# 0 = neither, 1= group hopping, 2=sequence hopping
pucchGroupHopping = 0;
hoppingId = 40;
p0_nominal = -90;
# ssb_PositionsInBurs_BitmapPR
# 1=short, 2=medium, 3=long
ssb_PositionsInBurst_PR = 2;
ssb_PositionsInBurst_Bitmap = 1; #0x80;
# ssb_periodicityServingCell
# 0 = ms5, 1=ms10, 2=ms20, 3=ms40, 4=ms80, 5=ms160, 6=spare2, 7=spare1
ssb_periodicityServingCell = 2;
# dmrs_TypeA_position
# 0 = pos2, 1 = pos3
dmrs_TypeA_Position = 0;
# subcarrierSpacing
# 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
subcarrierSpacing = 1;
#tdd-UL-DL-ConfigurationCommon
# subcarrierSpacing
# 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
referenceSubcarrierSpacing = 1;
# pattern1
# dl_UL_TransmissionPeriodicity
# 0=ms0p5, 1=ms0p625, 2=ms1, 3=ms1p25, 4=ms2, 5=ms2p5, 6=ms5, 7=ms10
dl_UL_TransmissionPeriodicity = 6;
nrofDownlinkSlots = 7; //8; //7;
nrofDownlinkSymbols = 6; //0; //6;
nrofUplinkSlots = 2;
nrofUplinkSymbols = 4; //0; //4;
ssPBCH_BlockPower = 10;
}
);
# ------- SCTP definitions
SCTP :
{
# Number of streams to use in input/output
SCTP_INSTREAMS = 2;
SCTP_OUTSTREAMS = 2;
};
////////// MME parameters:
mme_ip_address = ( { ipv4 = "192.168.18.99";
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
///X2
enable_x2 = "yes";
t_reloc_prep = 1000; /* unit: millisecond */
tx2_reloc_overall = 2000; /* unit: millisecond */
t_dc_prep = 1000; /* unit: millisecond */
t_dc_overall = 2000; /* unit: millisecond */
target_enb_x2_ip_address = (
{ ipv4 = "192.168.18.199";
ipv6 = "192:168:30::17";
preference = "ipv4";
}
);
NETWORK_INTERFACES :
{
GNB_INTERFACE_NAME_FOR_S1_MME = "eth0";
GNB_IPV4_ADDRESS_FOR_S1_MME = "192.168.18.198/24";
GNB_INTERFACE_NAME_FOR_S1U = "eth0";
GNB_IPV4_ADDRESS_FOR_S1U = "192.168.18.198/24";
GNB_PORT_FOR_S1U = 2152; # Spec 2152
GNB_IPV4_ADDRESS_FOR_X2C = "192.168.18.198/24";
GNB_PORT_FOR_X2C = 36422; # Spec 36422
};
}
);
MACRLCs = (
{
num_cc = 1;
tr_s_preference = "local_L1";
tr_n_preference = "local_RRC";
}
);
L1s = (
{
num_cc = 1;
tr_n_preference = "local_mac";
}
);
RUs = (
{
local_rf = "yes"
nb_tx = 1
nb_rx = 1
att_tx = 0
att_rx = 0;
bands = [7];
max_pdschReferenceSignalPower = -27;
max_rxgain = 114;
eNB_instances = [0];
clock_src = "internal";
}
);
THREAD_STRUCT = (
{
#three config for level of parallelism "PARALLEL_SINGLE_THREAD", "PARALLEL_RU_L1_SPLIT", or "PARALLEL_RU_L1_TRX_SPLIT"
//parallel_config = "PARALLEL_RU_L1_TRX_SPLIT";
parallel_config = "PARALLEL_SINGLE_THREAD";
#two option for worker "WORKER_DISABLE" or "WORKER_ENABLE"
worker_config = "WORKER_ENABLE";
}
);
security = {
# preferred ciphering algorithms
# the first one of the list that an UE supports in chosen
# valid values: nea0, nea1, nea2, nea3
ciphering_algorithms = ( "nea0" );
# preferred integrity algorithms
# the first one of the list that an UE supports in chosen
# valid values: nia0, nia1, nia2, nia3
integrity_algorithms = ( "nia2", "nia0" );
# setting 'drb_ciphering' to "no" disables ciphering for DRBs, no matter
# what 'ciphering_algorithms' configures; same thing for 'drb_integrity'
drb_ciphering = "yes";
drb_integrity = "no";
};
log_config :
{
global_log_level ="info";
hw_log_level ="info";
phy_log_level ="info";
mac_log_level ="info";
rlc_log_level ="info";
pdcp_log_level ="info";
rrc_log_level ="info";
};
doc/testing_gnb_w_cots_ue_resources/oai_enb.log deleted 100755 → 0
View file @ bbee4d98
This source diff could not be displayed because it is too large. You can view the blob instead.
doc/testing_gnb_w_cots_ue_resources/oai_gnb.log deleted 100755 → 0
View file @ bbee4d98
This source diff could not be displayed because it is too large. You can view the blob instead.
src/PHY/SIMULATION/NR_UE_PHY/unit_tests/build/reflogs/srs_test.txt deleted 100644 → 0
View file @ bbee4d98
This source diff could not be displayed because it is too large. You can view the blob instead.
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