<ahref="https://releases.ubuntu.com/18.04/"><imgsrc="https://img.shields.io/badge/OS-Ubuntu18-Green"alt="Supported OS Ubuntu 18"></a>
<ahref="https://releases.ubuntu.com/20.04/"><imgsrc="https://img.shields.io/badge/OS-Ubuntu20-Green"alt="Supported OS Ubuntu 20"></a>
<ahref="https://releases.ubuntu.com/22.04/"><imgsrc="https://img.shields.io/badge/OS-Ubuntu22-Green"alt="Supported OS Ubuntu 22"></a>
<ahref="https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux"><imgsrc="https://img.shields.io/badge/OS-RHEL8-Green"alt="Supported OS RHEL8"></a>
<ahref="https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux"><imgsrc="https://img.shields.io/badge/OS-RHEL9-Green"alt="Supported OS RELH9"></a>
<ahref="https://getfedora.org/en/workstation/"><imgsrc="https://img.shields.io/badge/OS-Fedore37-Green"alt="Supported OS Fedora 37"></a>
├── nfapi : Contains the NFAPI code. A local Readme file provides more details.
├── nfapi : (n)FAPI code for MAC-PHY interface
├── openair1 : 3GPP LTE Rel-10/12 PHY layer / 3GPP NR Rel-15 layer. A local Readme file provides more details.
│ ├── PHY
│ ├── SCHED
│ ├── SCHED_NBIOT
│ ├── SCHED_NR
│ ├── SCHED_NR_UE
│ ├── SCHED_UE
│ └── SIMULATION : PHY RF simulation.
├── openair2 : 3GPP LTE Rel-10 RLC/MAC/PDCP/RRC/X2AP + LTE Rel-14 M2AP implementation. Also 3GPP NR Rel-15 RLC/MAC/PDCP/RRC/X2AP.
│ ├── COMMON
│ ├── DOCS
│ ├── ENB_APP
│ ├── F1AP
│ ├── GNB_APP
│ ├── LAYER2/RLC/ : with the following subdirectories: UM_v9.3.0, TM_v9.3.0, and AM_v9.3.0.
│ ├── LAYER2/PDCP/PDCP_v10.1.0
│ ├── M2AP
│ ├── MCE_APP
│ ├── NETWORK_DRIVER
│ ├── NR_PHY_INTERFACE
│ ├── NR_UE_PHY_INTERFACE
│ ├── PHY_INTERFACE
│ ├── RRC
│ ├── UTIL
│ └── X2AP
├── openair3 : 3GPP LTE Rel10 for S1AP, NAS GTPV1-U for both ENB and UE.
│ ├── COMMON
│ ├── DOCS
│ ├── GTPV1-U
│ ├── M3AP
│ ├── MME_APP
│ ├── NAS
│ ├── S1AP
│ ├── SCTP
│ ├── SECU
│ ├── TEST
│ ├── UDP
│ └── UTILS
├── radio : drivers for various radios such as USRP, AW2S, RFsim, ...
└── targets : Top-level wrappers for unitary simulation for PHY channels, system-level emulation (eNB-UE with and without S1), and realtime eNB and UE and RRH GW.
├── openshift : OpenShift helm charts for some deployment options of OAI
├── radio : Drivers for various radios such as USRP, AW2S, RFsim, ...
└── targets : Some configuration files; only historical relevance, and might be deleted in the future
This page is valid on tags starting from **`2019.w09`**.
# Soft Modem Build Script
# Overview
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.
The [OAI EPC](https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME_MAGMA_MME.md) and [OAI 5GC](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/docs/DEPLOY_HOME.md) are developed in distinct projects with their own documentation and are not further 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.
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:
...
...
@@ -28,36 +28,57 @@ The main oai binaries, which are tested by the Continuous Integration process ar
- The 5G UE: `nr-uesoftmodem`
- The LTE eNodeB: `lte-softmodem`
- The 5G gNodeB: `nr-softmodem`
- The 5G CU-UP: `nr-cuup`
- 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`
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) .
-`conf2uedata`: a binary used to build the (4G) UE data from a configuration file. The created file emulates the sim card of a 3GPP compliant phone.
-`nvram`: a binary used to build (4G) UE (IMEI...) and EMM (IMSI, registered PLMN) non volatile data.
-`rb_tool`: radio bearer utility for (4G) UE
-`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](../CMakeLists.txt), it is used as input by cmake to generate the makefiles.
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` and `make`/`ninja` to ease the oai build and use. It logs the `cmake` and `ninja`/`make` commands it executes. The file describing how to build the executables from source files is the [CMakeLists.txt](../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.
# Running `build_oai`
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.
## List of options
# Building PHY Simulators
Calling the `build_oai` script with the `-h` option gives the list of all available options. A number of important ones:
The PHY layer simulators (LTE and NR) can be built as follows:
- The `-I` option is to install pre-requisites, you only need it the first time you build the softmodem or when some oai dependencies have changed.
- The `-w` option is to select the radio head support you want to include in your build. Radio head support is provided via a shared library, which is called the "oai device" The build script creates a soft link from `liboai_device.so` to the true device which will be used at run-time (here the USRP one, `liboai_usrpdevif.so`). The RF simulator[RF simulator](../radio/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` and `nr-cuup` executables 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
-`--ninja` is to use the `ninja` build tool, which speeds up compilation.
-`-c` is to clean the workspace and force a complete rebuild.
## Installing dependencies
Install all dependencies by issuing the `-I` option. To install furthermore libraries for optional libraries, use the `--install-optional-packages` option. The `-I` option will also install dependencies for an SDR when paired with `-w`. For instance, in order to install all dependencies and the ones for USRP, run:
```bash
cd openairinterface5g/cmake_targets/
./build_oai -I--install-optional-packages-w USRP
```
cd <your oai installation directory>/openairinterface5g/
source oaienv
cd cmake_targets/
./build_oai -I --phy_simulators
Note the section on installing UHD further down for more information.
## Building PHY Simulators
The PHY layer simulators (LTE and NR) can be built as follows:
```bash
cd openairinterface5g/cmake_targets/
./build_oai --phy_simulators
```
After completing the build, the binaries are available in the `cmake_targets/ran_build/build` directory.
...
...
@@ -68,20 +89,11 @@ Detailed information about these simulators can be found [in this dedicated page
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
```bash
cd openairinterface5g/cmake_targets/
./build_oai -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.
- 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](../radio/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.
...
...
@@ -118,35 +130,56 @@ See:
*`cmake_targets/tools/uhd-4.x-tdd-patch.diff`
*`cmake_targets/tools/build_helper` --> function `install_usrp_uhd_driver_from_source`
# 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.
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.
The following libraries are build in CI and should always work: `telnet`,
`enbscope`, `uescope`, `nrscope`, `nrqtscope`.
`./build_oai --build-lib all` will build all available optional libraries.
Some libraries have further dependencies and might not build on every system:
-`enbscope`, `uescope`, `nrscope`: libforms/X
-`nrqtscope`: Qt5
-`ldpc_cuda`: CUDA
-`ldpc_t1`: DPDK and VVDN T1
-`websrv`: npm and others
# `build_oai` options
# Running `cmake` directly
Please run `./build_oai -h` to get a list of available options.
`build_oai` is a wrapper on top of `cmake`. It is therefore possible to run `cmake` directly. An example using `ninja`: to build all "main targets" for 5G, excluding additional libraries:
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.
you do not have account on gitlab.eurecom.fr, please register yourself to gitlab.eurecom.fr and provide the login name in the email.
# 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.
More information can be found in [a separate page](../CONTRIBUTING.md).
`develop`: contains recent commits that are tested on our CI test bench. The update frequency is about once a week. 5G is only in this branch. It is the recommended and default branch.
`master`: contains a stable version of 4G, and will be updated in the future with 5G.
you can find the latest stable tag release here:
Please see the work flow and policies page: https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/oai-policies-home
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.
# RF Simulator
[[_TOC_]]
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.
# Simulators
## RFsimulator
The RF simulator is an 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](../radio/rfsimulator/README.md) contains the detailed documentation.
This is an easy use-case to setup and test, as no specific hardware is required. The [rfsimulator page](../radio/rfsimulator/README.md) contains the detailed documentation.
# L2 nFAPI Simulator
## 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
## L1 Simulator
**This information might be outdated. We recommend to use the RFsimulator as
shown above.**
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:
OAI supports different radio heads, 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
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
3. Monolithic gNodeB: see next section, or the [standalone tutorial](NR_SA_Tutorial_COTS_UE.md)
# 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.
# 5G NR
## 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).
The sa flag is used to run gNB in standalone mode.
In order to run gNB and UE in standalone mode, the `--sa` flag is needed.
## phy-test setup with OAI UE
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.
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 --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
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.
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)
-`--ssb` : SSB start subcarrier (default value 512)
You can run this, using USRPs, on two separate machines:
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_ports1.xml`
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_ports1.xml`
@@ -98,88 +122,66 @@ Some other useful paramters of the UE are
- --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](../radio/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:
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_ports1.xml`
UE on machine 2:
`sudo ./nr-uesoftmodem --do-ra`
## phy-test setup with OAI UE
With the RF simulator (on the same machine):
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
- 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.
The sa flag is used to run gNB in standalone mode.
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_ports1.xml` (1 layer) or `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap_ports2.xml` (2 layers).
In order to run gNB and UE in standalone mode, the following flag is needed:
You need to provide `--rrc_config_path` if you don't start the UE after the gNB
in the same directory.
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.
## noS1 setup with OAI UE
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
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.
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)
This setup is described in the [rfsimulator page](../radio/rfsimulator/README.md#5g-case). In theory this should also work with the real hardware target although this has yet to be tested.
### Run OAI in SA mode
## do-ra setup with OAI
From the `cmake_targets/ran_build/build` folder:
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.
gNB on machine 1:
In order to run the RA, the `--do-ra` flag is needed for both the gNB and the UE.
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_ports1.xml`
where `-r` sets the transmission bandwidth configuration in terms of RBs, `-C` sets the downlink carrier frequency and `--ssb` sets the SSB start subcarrier.
```bash
sudo ./nr-uesoftmodem --do-ra
```
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_ports1.xml`
### Run OAI with SDAP & Custom DRBs
...
...
@@ -208,17 +210,14 @@ Accordingly, the following parameters must be configured in the RUs section of t
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.
In order to enable DL-MIMO in OAI 5G softmodem, the prerequisite is to have `do_CSIRS = 1` in the configuration file. This allows the gNB to schedule CSI reference signal and to acquire from the UE CSI measurements to be able to schedule DLSCH with MIMO.
...
...
@@ -246,10 +245,3 @@ Finally the number of TX physical antenna in the RU part of the configuration fi
# Additional links
[Selecting an alternative ldpc implementation at run time](../openair1/PHY/CODING/DOC/LDPCImplementation.md)
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[PDF version](testbenches_doc_resources/5g-ota-bench.pdf) | [LaTeX/TikZ version](testbenches_doc_resources/5g-ota-bench.tex) if you want to modify to reflect your setup
### 5G NSA/Faraday Cage Testbench
**Purpose**: Faraday cage 5G tests
### 5G NSA/Faraday Cage Testbench
Note: obelix and porcepix are both used in the OTA testbench and the 5G
[PDF version](testbenches_doc_resources/5g-nsa-faraday-bench.pdf) | [LaTeX/TikZ version](testbenches_doc_resources/5g-nsa-faraday-bench.tex) if you want to modify to reflect your setup
[PDF version](testbenches_doc_resources/4g-faraday-bench.pdf) | [LaTeX/TikZ version](testbenches_doc_resources/4g-faraday-bench.tex) if you want to modify to reflect your setup
- Note: like [RAN-NSA-B200-Module-LTEBOX-Container](https://jenkins-oai.eurecom.fr/job/RAN-NSA-B200-Module-LTEBOX-Container/) above, but compiled/run from source
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.
