maki/openairinterface5g
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/update-split-doc-runmodem' into integration_2026_w14 (!3948)

Browse Source 
Update doc: split RUNMODEM.md, clarify USRP-specific workarounds

This reworks the documentation:
- split up RUNMODEM.md into separate documents for gNB, UE, NTN
- explains USRP workaround and patches
- makes a standalone UE doc file that explains UE-specific configuration
  & modes
- better explains physical simulators
- adds a document on tracy
- cleanup
This commit is contained in:
Jaroslava Fiedlerova
2026-04-01 20:57:16 +02:00
parent fcd3e62a33 40a1afda05
commit 8f5148ab2a
12 changed files with 1050 additions and 661 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/BUILD.md
+82 -57
View File
@@ -2,9 +2,9 @@
# OAI Build Procedures
[[_TOC_]]
This page describes how to build OAI.
This page is valid on tags starting from **`2019.w09`**.
[[_TOC_]]
## Overview
@@ -12,7 +12,11 @@ The [OAI EPC](https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/do
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 historically convential way to build OAI is
[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, and is a wrapper on top of `cmake`.
The main oai binaries, which are tested by the Continuous Integration process are:
@@ -39,6 +43,81 @@ The oai softmodem supports many use cases, and new ones are regularly added. Mos
- s1, noS1
- all simulators as the rfsimulator, the L2 simulator, with exception of PHY simulators, which are distinct executables.
## Dependencies
TODO.
## Running `cmake` directly
As mentioned, `build_oai` is a wrapper on top of `cmake`. It is therefore
possible, and now recommended, to run `cmake` directly. To build all of OAI in
a default install:
```
cd openairinterface5g
mkdir build
cd build
cmake .. -GNinja
ninja
```
Alternatively, let cmake generate the directory:
```
cd openairinterface5g
cmake -B build -G Ninja
cmake --build build
```
To build additional libraries, e.g., telnetsrv, do the following:
```bash
cmake .. -GNinja -DENABLE_TELNETSRV=ON
ninja telnetsrv
```
A list of all libraries can be seen using `ccmake ..` or `cmake-gui ..`.
The default target directory of `build_oai` is the following, for historical
reasons:
```bash
cd openairinterface5g/cmake_targets/ran_build/build
cmake ../../.. -GNinja
ccmake ../../..
cmake-gui ../../..
```
You can of course use all standard cmake/ninja/make commands in this directory,
assuming you already build with `build_oai`. For instance, to compile sources
after modifying the code, do
```
cd cmake_targets/ran_build/build
ninja
```
### cmake presets
CMake presets are common project configure options. See [here](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html).
Configure presets:
- `default`: Configure compilation with default options
- `tests`: Same as above but `ENABLE_TESTS` and `SANITIZE_ADDRESS` is ON
Build presets:
- `5gdefault`: Build the software for NR rfsimulator test
- `default`: same as 5gdefault
- `4gdefault`: Build the software for LTE rfsimulator test
- `tests`: build all unit tests
To configure using configuration preset:
cmake --preset <preset_name>
To build using a build preset:
cmake --build --preset <preset_name>
## Running `build_oai`
### List of options
@@ -176,60 +255,6 @@ Some libraries have further dependencies and might not build on every system:
- `websrv`: npm and others
- `ldpc_aal`: DPDK with patch
## Running `cmake` directly
`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:
```
cd openairinterface5g
mkdir build && cd build
cmake .. -GNinja && ninja nr-softmodem nr-uesoftmodem nr-cuup params_libconfig coding rfsimulator ldpc
```
To build additional libraries, e.g., telnetsrv, do the following:
```bash
cmake .. -GNinja -DENABLE_TELNETSRV=ON && ninja telnetsrv
```
A list of all libraries can be seen using `ccmake ..` or `cmake-gui ..`.
It is currently not possible to build all targets in the form of `cmake ..
-GNinja && ninja`: currently, SDRs are always exposed, even if you don't have
the dependencies, and some targets are simply broken. Again, `build_oai` list
all targets that it builds, and you can use them with `ninja`
The default target directory of `build_oai` is the following, for historical reasons:
```bash
cd openairinterface5g/cmake_targets/ran_build/build
cmake ../../.. -GNinja
ccmake ../../..
cmake-gui ../../..
```
You can of course use all standard cmake/ninja/make commands in this directory.
### cmake presets
CMake presets are common project configure options. See [here](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html).
Configure presets:
- `default`: Configure compilation with default options
- `tests`: Same as above but ENABLE_TESTS and SANITIZE_ADDRESS is ON
Build presets:
- `5gdefault`: Build the software for NR rfsimulator test
- `default`: same as 5gdefault
- `4gdefault`: Build the software for LTE rfsimulator test
- `tests`: build all unit tests
To configure using configuration preset:
cmake --preset <preset_name>
To build using a build preset:
cmake --build --preset <preset_name>
## Cross Compile
If you want to use cross-compiler on x86 platform for aarch64 version, please refer the [cross-compile.md](./cross-compile.md) for more information.
doc/NR_SA_Tutorial_COTS_UE.md
+1 -1
View File
@@ -201,7 +201,7 @@ With devices like the USRP N300 and especially the X300, there is noise in the D
There are two possible solution that can be enabled in OAI:
* `--tune-offset`: it consists in shifting away the operational bandwidth to avoid the center frequency
* `ul_prbblacklist`: can be used to define specific PRBs that should not be used for uplink scheduling
* `gNBs.[0].ul_prbblacklist`: can be used to define specific PRBs that should not be used for uplink scheduling
A spectrum clean from the noisy PRBs will eventually result in an enhanced UL throughput.
doc/NR_SA_Tutorial_OAI_nrUE.md
+11 -27
View File
@@ -179,39 +179,23 @@ uicc0 = {
}
```
| **Parameter** | **Description** | **Default Value** |
|---------------|-----------------|-------------------|
| **IMSI** | Unique identifier for the UE within the mobile network. Used by the network to identify the UE during authentication. It ensures that the UE is correctly identified by the network. | 001010000000001 |
| **key** | Cryptographic key shared between the UE and the network, used for encryption during the authentication process. | `fec86ba6eb707ed08905757b1bb44b8f` |
| **OPC** | Operator key for the Milenage Authentication and Key Agreement algorithm used for encryption during the authentication process. | Ensures secure communication between the UE and the network by matching the encryption keys. | `C42449363BBAD02B66D16BC975D77CC1` |
| **DNN** | _Deprecated_: Specifies the name of the data network the UE wishes to connect to, similar to an APN in 4G networks. | `oai` |
| **NSSAI** | _Deprecated_: Allows the UE to select the appropriate network slice, which provides different QoS. | `1` |
| **pdu_sessions** | list of PDU sessions to request | empty array (no PDU session) |
Further information about the meaning of these parameters is described in the
[dedicated nrUE configuration page](./runmodem-nrue.md).
Note that DNN and NSSAI parameters are deprecated, and `pdu_sessions` should be
used. If the `pdu_sessions` array is present, DNN and NSSAI are ignored.
Each element within the `pdu_sessions` array takes the following parameters.
Multiple PDU sessions can be requested.
| **Parameter** | **Description** | **Default Value** |
|---------------|-----------------|-------------------|
| `id` | ID of the PDU session to request | index of the current element (1..16) |
| `type` | Type of the PDU session to request (allowed: `IPv4`, `IPv6`, `IPv4v6`, `Ethernet` | `IPv4` |
| `dnn` | Specifies the name of the data network the UE wishes to connect to | `oai` |
| `nssai_sst` | Slice Service Type to request (1=eMBB, 2=URLLC, 3=mMTC) | `1` |
| `nssai_sd` | Slice Differentiator to request | `0xffffff` (meaning "no SD") |
The UE configuration must match the one of the network's AMF. The nrUE can connect by default to OAI CN5G with no need to provide the configuration file.
When running the `nr-uesoftmodem`, one can specify the nrUE configuration file using the `-O` option. E.g.:
The UE configuration must match the one of the network's AMF. When running the
`nr-uesoftmodem`, one can specify the nrUE configuration file using the `-O`
option. E.g.:
```bash
sudo ./nr-uesoftmodem --rfsim --rfsimulator.[0].serveraddr 127.0.0.1 -r 106 --numerology 1 --band 78 -C 3619200000 -O ~/nrue.uicc.conf
```
The CL option `--uicc0.imsi` can override the IMSI value in the configuration file if necessary (e.g. when running multiple UEs): `--uicc0.imsi 001010000000001`.
More details available at [ci-scripts/yaml_files/5g_rfsimulator/README.md](../ci-scripts/yaml_files/5g_rfsimulator/README.md).
The command line option `--uicc0.imsi` can override the IMSI value in the
configuration file if necessary (e.g. when running multiple UEs): `--uicc0.imsi
001010000000001`.
More details can also be found at
[ci-scripts/yaml_files/5g_rfsimulator/README.md](../ci-scripts/yaml_files/5g_rfsimulator/README.md).
**Note:** From tag `2024.w45`, OAI nrUE runs by default in standalone (SA) mode.
In earlier versions the default mode was non-standalone (NSA).
doc/README.md
+10 -7
View File
@@ -18,10 +18,6 @@ Beware if you previously pulled the `develop` branch that your repository may be
- [FEATURE_SET.md](./FEATURE_SET.md): lists supported features
- [GET_SOURCES.md](./GET_SOURCES.md): how to download the sources
- [BUILD.md](./BUILD.md): how to build the sources
- [code-style-contrib.md](./code-style-contrib.md): overall working practices, code style, and review process
- [cross-compile.md](./cross-compile.md): how to cross-compile OAI for ARM
- [clang-format.md](./clang-format.md): how to format the code
- [sanitizers.md](./dev_tools/sanitizers.md): how to run with ASan/UBSan/MemSAN/TSan
- [environment-variables.md](./environment-variables.md): the environment variables used by OAI
- [tuning_and_security.md](./tuning_and_security.md): performance and security considerations
@@ -34,20 +30,21 @@ There is some general information in the [OpenAirInterface Gitlab Wiki](https://
* [OAI gNB with COTS UE](./NR_SA_Tutorial_COTS_UE.md)
* [OAI NR-UE](./NR_SA_Tutorial_OAI_nrUE.md)
* [Multiple OAI NR-UE with RFsimulator](./NR_SA_Tutorial_OAI_multi_UE.md)
- [RUNMODEM.md](./RUNMODEM.md): Generic information on how to
- [RUNMODEM.md](./RUNMODEM.md): Information on how to run the gNB
* Run simulators
* Run with hardware
* Specific OAI modes (phy-test, do-ra, noS1)
* (5G) Using SDAP and custom DRBs
* IF setups and arbitrary frequencies
* MIMO
- [nrUE-specific configuration and modes](./runmodem-nrue.md)
* Specific OAI modes (phy-test, do-ra, noS1)
- [How to run OAI with O-RAN 7.2 FHI](./ORAN_FHI7.2_Tutorial.md)
- [How to run a 5G-NSA setup](./TESTING_OAI_NSA_COTS_UE.md)
- [How to run a 4G setup using L1 simulator](./L1SIM.md) _Note: we recommend the RFsimulator_
- [How to use the L2 simulator](./L2NFAPI.md)
- [How to use the OAI channel simulator](../openair1/SIMULATION/TOOLS/DOC/channel_simulation.md)
- [How to run an NTN setup](./ntn-configuration.md)
- [How to use GPU-accelerated channel simulation](../openair1/SIMULATION/TOOLS/DOC/gpu_acceleration.md)
- [How to use multiple BWPs](./RUN_NR_multiple_BWPs.md)
- [How to run OAI-VNF and OAI-PNF](./nfapi.md): how to run the FAPI/nFAPI split,
including some general remarks on FAPI/nFAPI.
- [How to use the positioning reference signal (PRS)](./RUN_NR_PRS.md)
@@ -133,7 +130,13 @@ The other SDRs (AW2S, LimeSDR, ...) have no READMEs.
## Developer tools
- [code-style-contrib.md](./code-style-contrib.md): overall working practices, code style, and review process
- [cross-compile.md](./cross-compile.md): how to cross-compile OAI for ARM
- [clang-format.md](./clang-format.md): how to format the code. See also the
next entry for an error detection tool.
- [formatting](../tools/formatting/README.md) is a clang-format error detection tool
- [sanitizers.md](./dev_tools/sanitizers.md): how to run with ASan/UBSan/MemSAN/TSan
- [iwyu](../tools/iwyu/README.md) is a tool to detect `#include` errors
- [docker-dev-env](../tools/docker-dev-env/README.md) is a ubuntu24 docker development environment
- [performance analysis with tracy](./dev_tools/tracy.md)
- [doc_best_practices.md](./doc_best_practices.md): overall best practices for writing documentations
doc/RUNMODEM.md
+234 -565
View File
@@ -1,596 +1,249 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
# Running OAI 5G Softmodems
# Running the OAI 5G gNB (nr-softmodem)
This document is a general overview of running `nr-softmodem`, the OAI 5G
gNodeB executable. For build instructions see [BUILD.md](BUILD.md). For UE
documentation see [runmodem-nrue.md](runmodem-nrue.md).
This document explains some options for running 5G executables.
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.
[[_TOC_]]
## Simulators
## Modes of operation
`nr-softmodem` supports several deployment modes. The default is "standalone"
mode.
| Option | Mode | Description |
|----------|------------|-------------|
| _none_ | standalone | Run gNB in SA mode (no flag). |
| `--nsa` | NSA | Non-standalone mode, requires an LTE eNB, see [NSA documentation](TESTING_OAI_NSA_COTS_UE.md). |
| phy-test | `--phy-test` | Test modes without random access, see [nrUE page](runmodem-nrue.md). |
| do-ra | `--do-ra` | Test mode without a core network or RRC connection, see [nrUE page](runmodem-nrue.md). |
| noS1 | `--noS1` | Manually inject traffic, suitable for phy-test/do-ra without core network. |
## Basic invocation
From the build directory (with `build_oai`, by default `cmake_targets/ran_build/build/`):
```bash
sudo ./nr-softmodem -O <config_file> [options]
```
Example with a USRP B210:
```bash
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf -E --continuous-tx
```
CI-tested sample configuration files are in `ci-scripts/conf_files/`. Sample
configuration files for various hardware can be found under
`targets/PROJECTS/GENERIC-NR-5GC/CONF/`.
## Configuration file
The configuration file can use either libconfig (`.conf`) or YAML (`.yaml`)
syntax, based on the file ending. The main sections are:
- `gNBs`: cell identity, PLMN, physical cell parameters, AMF address
- `MACRLCs`: MAC/RLC layer settings
- `L1s`: L1 layer settings and thread pinning
- `RUs`: radio unit configuration (device selection, antennas, gains)
- `security`: ciphering and integrity algorithm preferences
- `log_config`: per-module log levels
Individual parameters can be overridden on the command line using the
`--Section.[index].param value` syntax, e.g.
`--gNBs.[0].min_rxtxtime 6`.
### Core network connectivity
In the `gNBs` section, set the following to connect to a 5G core (AMF):
```
gNBs = (
{
tracking_area_code = 1;
plmn_list = ({ mcc = 001; mnc = 01; mnc_length = 2; snssaiList = ({ sst = 1; sd = 0xffffff; }) });
nr_cellid = 12345678L;
amf_ip_address = ({ ipv4 = "192.168.70.132"; });
NETWORK_INTERFACES :
{
GNB_IPV4_ADDRESS_FOR_NG_AMF = "192.168.70.129"; // N2 interface
GNB_IPV4_ADDRESS_FOR_NGU = "192.168.70.129"; // N3 interface
GNB_PORT_FOR_S1U = 2152;
};
});
```
- `plmn_list` must match the PLMN configured in the AMF.
- `amf_ip_address` is the IP address of the AMF.
- `GNB_IPV4_ADDRESS_FOR_NG_AMF` is the local IP address of the gNB's N2 interface.
- `GNB_IPV4_ADDRESS_FOR_NGU` is the local IP address of the gNB's N3 interface.
### MAC configuration
In the `MACRLCs` section, configure MAC parameters. See the [MAC user
documentation](MAC/mac-usage.md) for more information.
### L1 configuration
The `L1s` section configures the L1 (physical layer) processing pipeline.
- `tr_n_preference`: transport to the MAC layer. Normally `local_mac` (shared
memory). Set to `nfapi` for a networked L1/MAC split; see [nFAPI docs](nfapi.md).
- `prach_dtx_threshold`: energy threshold (in dB x10) for PRACH preamble detection. Lower
values increase sensitivity but may cause false detections. Typical range:
60–200.
- `pucch0_dtx_threshold`: energy threshold for PUCCH format 0 (SR/HARQ-ACK)
detection. Similar trade-off as `prach_dtx_threshold`. Typical range: 10–100.
- `pusch_dtx_threshold`: energy threshold for PUSCH detection. Similar
trade-off as `prach_dtx_threshold`. Typical range: 10–100.
- `ofdm_offset_divisor`: controls a small timing advance applied to the OFDM
signal to ensure samples arrive before the processing deadline. Set to
`UINT_MAX` (i.e., `4294967295`) for zero offset; a value of `8` gives an
offset of `frame_length / 8`. The default value of `8` works well in most
cases.
- `max_ldpc_iterations`: maximum number of LDPC decoder iterations. Fewer
iterations reduce CPU load at the cost of UL error rate. Default is 8, but
might be as high as 20 or more..
- `L1_rx_thread_core` / `L1_tx_thread_core`: pin the L1 RX and TX threads to
specific isolated CPU cores. Recommended for real-time performance, especially
with O-RAN 7.2 fronthaul.
- `phase_compensation` (FHI 7.2 only): set to `0` if phase compensation is done
in the O-RU, `1` if it should be done in the DU (software). Must match the
O-RU configuration.
- `tx_amp_backoff_dB` (FHI 7.2 only): output amplitude backoff in dB relative
to full scale. Must be set according to the O-RU vendor documentation to avoid
exceeding the RU's power limits.
### RU configuration
The `RUs` section describes the radio unit, i.e., either an integrated RF device
(split 8 radio) or a remote RU connected via a fronthaul interface (e.g., O-RU).
- `local_rf`: `"yes"` for a locally attached RF device (USRP, etc.), `"no"`
for a remote RU (e.g., O-RAN 7.2 fronthaul).
- `nb_tx` / `nb_rx`: number of TX and RX antenna ports. Must be consistent with
the antenna port configuration in `gNBs` (see [MIMO section](#5g-gnb-mimo-configuration)).
- `att_tx` / `att_rx`: software attenuation applied to TX/RX samples in dB.
Used to reduce signal levels in software before they reach the RF device.
- `bands`: list of NR band numbers this RU operates on, e.g. `[78]`.
- `max_pdschReferenceSignalPower`: maximum PDSCH reference signal power in dBm.
Used by the UE for path loss estimation. Should match the actual transmit
power level.
- `max_rxgain`: maximum RX gain of the RF device in dB. This is the hardware
gain limit; the actual gain used may be lower.
- `clock_src`: clock reference source. `"internal"` uses the device's own
oscillator; `"external"` expects an external 10 MHz reference; `"gpsdo"`
uses a GPS-disciplined oscillator. Applicable only for USRP.
- `sdr_addrs`: device address string passed to the RF driver. Used notably with
USRP and BladeRF devices.
- `ru_thread_core`: CPU core for the RU fronthaul thread. Should
be an isolated core (FHI 7.2 only).
### Frequency and cell configuration
Key parameters in `servingCellConfigCommon`:
- `absoluteFrequencySSB` / `dl_absoluteFrequencyPointA`: DL frequency in NR-ARFCN for SSB and PointA
- `dl_frequencyBand` / `ul_frequencyBand`: NR band number
- `dl_carrierBandwidth` / `ul_carrierBandwidth`: bandwidth in PRBs
- `dl_subcarrierSpacing`: subcarrier spacing (0=15 kHz, 1=30 kHz, 2=60 kHz, 3=120 kHz)
- `ssPBCH_BlockPower`: SSB transmit power in dBm (EPRE of SSB resource elements)
- `prach_ConfigurationIndex`, `prach_msg1_FrequencyStart`: PRACH configuration
For a reference of frequency parameters and band configurations see
[gNB frequency setup](gNB_frequency_setup.md).
### Security
The `security` section controls NAS/AS security algorithm selection:
```
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";
};
```
## Common radio devices
### RFsimulator
The RFsimulator 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 RFsimulator has some preliminary support for channel modeling.
The RFsimulator replaces the radio device with a virtual radio, allowing
gNB and UE to run without hardware. Built by default. Ideal for testing,
debugging, and development. Add `--rfsim` to the command line.
It is planned to enhance this simulator with the following functionalities:
See the [RFsimulator documentation](../radio/rfsimulator/README.md).
- Support for multiple eNodeB's or gNodeB's for hand-over tests
### USRP (B2xx, N3xx, X3xx, x4xx)
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.
Build with `build_oai -w USRP`/`cmake -DOAI_USRP=ON`. The device is selected
automatically. Common per-device recommendations:
### L2 nFAPI Simulator
- B210: use `-E --continuous-tx`; limited to ~40 MHz bandwidth
- N3xx/X3xx: use `--usrp-tx-thread-config 1`; consider `--tune-offset` or
`ul_prbblacklist` for DC noise at high bandwidth
This simulator connects an eNodeB and UEs through an 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).
For network tuning of 10G USRP devices (N300, X300):
```bash
sudo ethtool -G <ifname> tx 4096 rx 4096
sudo sysctl -w net.core.wmem_max=62500000
sudo sysctl -w net.core.rmem_max=62500000
```
As for the RFsimulator, no specific hardware is required. The [L2 nfapi
simulator page](./L2NFAPI.md) contains the detailed documentation.
See also the [COTS UE tutorial](NR_SA_Tutorial_COTS_UE.md) and
[performance tuning guide](tuning_and_security.md).
## Running with a true radio head
### O-RAN 7.2 Fronthaul (FHI)
OAI supports different radio heads, the following are tested in the CI:
For O-RAN split 7.2 with an O-RU, build with `build_oai -t
oran_fhlib_5g`/`cmake -DOAI_FHI72=ON`. Configuration requires a `fhi_72`
section and DPDK setup. See the [O-RAN FHI 7.2 tutorial](ORAN_FHI7.2_Tutorial.md).
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)
## Higher-layer splits
### CU/DU (F1) and CU-CP/CU-UP (E1) splits
## 5G NR
F1 splits the gNB into a CU (RRC/PDCP/SDAP) and one or more DUs (RLC/MAC/L1).
See [F1AP docs](F1AP/F1-design.md). The CU and DU connect via F1AP over SCTP.
The DU configuration specifies the CU IP address.
### 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 `--nsa` flag must be used to run gNB in non-standalone mode.
#### Launch eNB
To run a split gNB, start a CU and one or more DUs separately:
```bash
sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.50prb.usrpb210.conf
# CU
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/cu_gnb.conf
# DU
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/du_gnb.conf
```
#### Launch gNB
E1 splits the CU into a CU-CP (RRC) and one or more CU-UPs (PDCP/SDAP) (and
therefore also requires F1). See [E1AP docs](E1AP/E1-design.md).
```bash
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --nsa
```
### FAPI/nFAPI splits
You should see the X2 messages in Wireshark and at the eNB.
### SA setup with OAI NR-UE
The standalone mode is the default mode.
Before tag `2024.w45`, the default mode was NSA. Thus, in the past, to run
either the gNB or the UE in standalone mode, it was necessary to provide the
`--sa` flag in the command line. This is not the case anymore. If provided
the softmodem exits reporting that it does not know this option.
The default (SA) mode does the following:
- At the gNB:
* The RRC encodes SIB1 according to the configuration file and transmits it through NR-BCCH-DL-SCH.
- At the UE:
* 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 standalone 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 516)
To simplify the configuration for the user testing OAI UE with OAI gNB, the latter prints the following LOG that guides the user to correctly set some of the UE command line parameters:
```shell
[PHY] Command line parameters for OAI UE: -C 3319680000 -r 106 --numerology 1 --ssb 516
```
You can run this, using USRPs, on two separate machines:
```shell
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --gNBs.[0].min_rxtxtime 6
sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --ssb 516
```
With the **RFsimulator** (on the same machine), just add the option `--rfsim` to both gNB and NR UE command lines.
UE capabilities can be passed according to the [UE Capabilities](#UE-Capabilities) section.
A detailed tutorial is provided at this page [NR_SA_Tutorial_OAI_nrUE.md](./NR_SA_Tutorial_OAI_nrUE.md).
### Optional NR-UE command line options
Here are some useful command line options for the NR UE:
| Parameter | Description |
|--------------------------|---------------------------------------------------------------------------------------------------------------|
| `--ue-scan-carrier` | Scan for cells in current bandwidth. This option can be used if the SSB position of the gNB is unknown. If multiple cells are detected, the UE will try to connect to the first cell. By default, this option is disabled and the UE attempts to only decode SSB given by `--ssb`. |
| `--ue-fo-compensation` | Enables the initial frequency offset compensation at the UE. Useful when running over the air and/or without an external clock/time source. |
| `--cont-fo-comp` | Enables the continuous frequency offset (FO) estimation and compensation. Parameter value `1` specifies that the main FO contribution comes from the local oscillator's (LO) accuracy. Parameter value `2` specifies that the main FO contribution comes from Doppler shift. Parameter value `3` specifies that no measured residual DL FO is considered for UL FO pre-compensation. |
| `--initial-fo` | Sets the known initial frequency offset. Useful especially with large Doppler frequency, e.g. LEO satellite. |
| `--freq-sync-P` | Sets the coefficient for the Proportional part of the PI-controller for the continuous frequency offset compensation. Default value 0.01. |
| `--freq-sync-I` | Sets the coefficient for the Integrating part of the PI-controller for the continuous frequency offset compensation. Default value 0.001. |
| `--ntn-initial-time-drift` | Sets the initial NTN DL time drift (feeder link and service link), given in µs/s. |
| `--autonomous-ta` | Enables the autonomous TA update, based on DL drift (useful if main contribution to DL drift is movement, e.g. LEO satellite). |
| `--time-sync-P` | Sets the coefficient for the Proportional part of the PI-controller for the time synchronization. Default value 0.5. |
| `--time-sync-I` | Sets the coefficient for the Integrating part of the PI-controller for the time synchronization. Default value 0.0. |
| `--usrp-args` | Equivalent to the `sdr_addrs` field in the gNB config file. Used to identify the USRP and set some basic parameters (like the clock source). |
| `--clock-source` | Sets the clock source (internal or external). |
| `--time-source` | Sets the time source (internal or external). |
You can view all available options by typing:
```shell
./nr-uesoftmodem --help
```
### NR UE: Configure multiple RF-frontends (RUs)
Multiple RF-frontends (also called RUs) can be defined for the nr-uesoftmodem.
Therefore, two sections in the NR UE configuration file are used:
- `RUs`
- `cells`
The `RUs` section in the NR UE configuration file contains an array of elements, where each element has these properies:
| Property name | Type | Default value | Description |
| ---------------- | -------------- | ------------- | ------------------------------------ |
| nb_tx | integer | 1 | Number of TX Antennas |
| nb_rx | integer | 1 | Number of RX Antennas |
| att_tx | integer | 0 | TX Attenuation in dB |
| att_rx | integer | 0 | RX Attenuation in dB |
| max_rxgain | integer | 120 | Maximum RX Gain at 0 dB Attenuation |
| sdr_addrs | string | type=b200 | SDR Parameter String |
| tx_subdev | string | | SDR TX Subdevice |
| rx_subdev | string | | SDR RX Subdevice |
| clock_src | string | internal | SDR Clock Source |
| time_src | string | internal | SDR Time Source |
| tune_offset | floating point | 0.0 | SDR Tune Offset in Hz |
| if_freq | integer | 0 | DL Intermediate Frequency in Hz |
| if_offset | integer | 0 | UL Intermediate Frequency Offset in Hz |
The `cells` section in the NR UE configuration file contains an array of elements, where each element has these properies:
| Property name | Type | Default value | Description |
| ---------------- | ------- | ------------- | ---------------------------------------- |
| ru_id | integer | 0 | ID of the associated RU from the `RUs` section |
| band | integer | 78 | 5G NR Band |
| rf_freq | integer | 0 | DL Carrier Centre Frequency in Hz |
| rf_offset | integer | 0 | DL Carrier Centre Frequency Offset in Hz |
| numerology | integer | 1 | 5G NR Numerology (µ) |
| N_RB_DL | integer | 106 | Number of DL Carrier Ressource Blocks |
| ssb_start | integer | 516 | Ressource Element where the SSB Starts |
There are different scenarios where multiple RF-frontends (also called RUs) are beneficial for the NR UE:
1. RF-Simulator Inter-Frequency Handover between multiple cells
2. Multiple UEs in one instance, each using their own RF-frontend (RF-Simulator connection)
3. Different Antennas connected to different RF-ports
4. Concurrent connection to multiple carriers (carrier aggregation CA)
This would be and example configuration for the 1. scenario:
```
rfsimulator = (
{
serveraddr = "127.0.0.2";
serverport = 4043;
}, {
serveraddr = "127.0.0.3";
serverport = 4044;
}
);
RUs = (
{
nb_tx = 1;
nb_rx = 1;
}, {
nb_tx = 1;
nb_rx = 1;
}
);
cells = (
{
ru_id = 0;
band = 78;
rf_freq = 3619200000L;
numerology = 1;
N_RB_DL = 106;
ssb_start = 516;
}, {
ru_id = 1;
band = 78;
rf_freq = 3649440000L;
numerology = 1;
N_RB_DL = 106;
ssb_start = 516;
}
);
```
An example for the 2. scenario can be found in the file [ci-scripts/yaml_files/5g_rfsimulator_multiue/nrue.uicc.conf](../ci-scripts/yaml_files/5g_rfsimulator_multiue/nrue.uicc.conf).
The 3. scenario is similar to 1., but instead of providing RF-Simulator parameters, actual SDR parameters have to be provided.
The 4. scenario is not supported, as the NR UE does not implement CA, yet.
Current Limitations:
- Each RU can be used by only one cell.
- Each RU and cell can be used by only one UE (no RU sharing implemented, yet).
- The sampling rates of all RUs must be the same.
### Common gNB and NR UE command line options
#### Three-quarter sampling
The command line option `-E` can be used to enable three-quarter sampling for split 8 sample rate. Required for certain radios (e.g., 40MHz with B210). If used on the gNB, it is a good idea to use for the UE as well (and vice versa).
#### UE Capabilities
The `--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` for 1 layer or e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap_ports2.xml` for 2 layers.
This option is available for the following combinations of operation modes and gNB/nrUE softmodems:
| Mode | Executable | Description |
|------------|----------------|-----------------------------------------------------|
| SA | nr-uesoftmodem | Send UE capabilities from the UE to the gNB via RRC |
| phy-test | nr-softmodem | Mimic the reception of UE capabilities by the gNB |
| do-ra | nr-softmodem | Mimic the reception of UE capabilities by the gNB |
e.g.
```shell
sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3319680000 --ue-nb-ant-tx 2 --ue-nb-ant-rx 2 --uecap_file /opt/oai-nr-ue/etc/uecap.xml
```
### How to run a NTN configuration
#### NTN channel
A 5G NR NTN configuration only works in a non-terrestrial setup.
Therefore either SDR boards and a dedicated NTN channel emulator are required, or RFsimulator has to be configured to simulate a NTN channel.
As shown on the [rfsimulator page](../radio/rfsimulator/README.md), RFsimulator provides different possibilities.
E.g. to perform a simple simulation of a satellite in geostationary orbit (GEO), these parameters should be added to both gNB and UE command lines:
```
--rfsimulator.[0].prop_delay 238.74
```
For simulation of a satellite in low earth orbit (LEO), two channel models have been added to rfsimulator:
- `SAT_LEO_TRANS`: transparent LEO satellite with gNB on ground
- `SAT_LEO_REGEN`: regenerative LEO satellite with gNB on board
Both channel models simulate the delay and Doppler for a circular orbit at 600 km height according to the Matlab function [dopplerShiftCircularOrbit](https://de.mathworks.com/help/satcom/ref/dopplershiftcircularorbit.html).
An example configuration to simulate a transparent LEO satellite with rfsimulator would be:
```
channelmod = {
max_chan=10;
modellist="modellist_rfsimu_1";
modellist_rfsimu_1 = (
{
model_name = "rfsimu_channel_enB0"
type = "SAT_LEO_TRANS";
noise_power_dB = -100;
},
{
model_name = "rfsimu_channel_ue0"
type = "SAT_LEO_TRANS";
noise_power_dB = -100;
}
);
};
```
This configuration is also provided in the file `targets/PROJECTS/GENERIC-NR-5GC/CONF/channelmod_rfsimu_LEO_satellite.conf`.
Additionally, rfsimulator has to be configured to apply the channel model.
This can be done by either providing this line in the conf file in section `rfsimulator`:
```
options = ("chanmod");
```
Or by providing this the the command line parameters:
```
--rfsimulator.[0].options chanmod
```
#### gNB
The main parameters to cope with the large NTN propagation delay are cellSpecificKoffset, ta-Common, ta-CommonDrift and the ephemeris data (satellite position and velocity vectors).
The parameter `ntn-UlSyncValidityDuration-r17` indicates the maximum time duration from epochtime during which the UE can apply assistance information without having acquired new assistance information. i.e this enables UE to re-read SIB19 before timer with value ulSyncValidityDuration expires. The unit of the field is in seconds. Example values for GEO: 240s, MEO: 20s, LEO: 5s.
As epochtime is not implemented yet, UE starts the timer from the TTI where SIB19 is received with ntn-UlSyncValidityDuration-r17 IE.
The parameter `cellSpecificKoffset_r17` is the scheduling offset used for the timing relationships that are modified for NTN (see TS 38.213).
The unit of the field Koffset is number of slots for a given subcarrier spacing of 15 kHz.
The parameter `ta-Common-r17` is used to provide the propagation delay between the reference point (at the gNB) and the satellite.
The granularity of ta-Common is 4.072 × 10^(-3) µs. Values are given in unit of corresponding granularity.
The parameter `ta-CommonDrift-r17` indicates the drift rate of the common TA.
The granularity of ta-CommonDrift is 0.2 × 10^(-3) µs/s. Values are given in unit of corresponding granularity.
The satellite position and velocity vartors are provided using the following parameters:
`positionX-r17`, `positionY-r17`, `positionZ-r17`:
X, Y, Z coordinate of satellite position state vector in ECEF. Unit is meter.
Step of 1.3 m. Actual value = field value * 1.3.
`velocityVX-r17`, `velocityVY-r17`, `velocityVZ-r17`:
X, Y, Z coordinate of satellite velocity state vector in ECEF. Unit is meter/second.
Step of 0.06 m/s. Actual value = field value * 0.06.
These parameters can be provided to the gNB in the conf file in the section `servingCellConfigCommon`:
```
...
# GEO satellite
cellSpecificKoffset_r17 = 478;
ta-Common-r17 = 58629666; # 238.74 ms
positionX-r17 = 0;
positionY-r17 = 0;
positionZ-r17 = 32433846;
velocityVX-r17 = 0;
velocityVY-r17 = 0;
velocityVZ-r17 = 0;
# LEO satellite
# cellSpecificKoffset_r17 = 40;
# ta-Common-r17 = 4634000; # 18.87 ms
# ta-CommonDrift-r17 = -230000; # -46 µs/s
# positionX-r17 = 0;
# positionY-r17 = -2166908; # -2816980.4 m
# positionZ-r17 = 4910784; # 6384019.2 m
# velocityVX-r17 = 0;
# velocityVY-r17 = 115246; # 6914.76 m/s
# velocityVZ-r17 = 50853; # 3051.18 m/s
...
```
Besides this, some timers, e.g. `sr_ProhibitTimer_v1700`, `t300`, `t301` and `t319`, in the conf file section `gNBs.[0].TIMERS` might need to be extended for GEO satellites.
```
...
TIMERS :
{
sr_ProhibitTimer = 0;
sr_TransMax = 64;
sr_ProhibitTimer_v1700 = 512;
t300 = 2000;
t301 = 2000;
t319 = 2000;
};
...
```
To improve the achievable UL and DL throughput in conditions with large RTT (esp. GEO satellites), there is a feature defined in REL17 to disable HARQ feedback.
This allows to reuse HARQ processes immediately, but it breaks compatibility with UEs not supporting this REL17 feature.
To enable this feature, the `disable_harq` flag has to be added to the gNB conf file in the section `gNBs.[0]`
```
...
min_rxtxtime = 6;
disable_harq = 1; // <--
servingCellConfigCommon = (
{
...
```
The settings for a transparent GEO satellite scenario are already provided in the file `ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn.conf`.
Using this conf file, an example gNB command for FDD, 5 MHz BW, 15 kHz SCS, transparent GEO satellite 5G NR NTN is this:
```
cd cmake_targets
sudo ./ran_build/build/nr-softmodem -O ../ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn.conf --rfsim
```
To configure NTN gNB with 32 HARQ processes in downlink and uplink, add these settings in conf files under section `gNBs.[0]`
```
...
num_dlharq = 32;
num_ulharq = 32;
...
```
To simulate a LEO satellite channel model with rfsimulator in UL (DL is simulated at the UE side) either the `channelmod` section as shown before has to be added to the gNB conf file, or a channelmod conf file has to be included like this:
```
@include "channelmod_rfsimu_LEO_satellite.conf"
```
The settings for a transparent LEO satellite scenario are already provided in the file `ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn-leo.conf`.
Using this conf file, an example gNB command for FDD, 5 MHz BW, 15 kHz SCS, trasparent LEO satellite 5G NR NTN is this:
```
cd cmake_targets
sudo ./ran_build/build/nr-softmodem -O ../ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn-leo.conf --rfsim
```
#### NR UE
At UE side, only few parameters have to be provided, as the UE receives most relevant parameters via SIB19 from the gNB.
But to calculate the UE specific TA, the UE position has to be provided in the `ue.conf` file.
Also the LEO channel model has to be configured, e.g. by using an `@include` statement, just like on the gNB side:
```
...
position0 = {
x = 0.0;
y = 0.0;
z = 6377900.0;
}
@include "channelmod_rfsimu_LEO_satellite.conf"
```
So an example NR UE command for FDD, 5MHz BW, 15 kHz SCS, transparent GEO satellite 5G NR NTN is this:
```
cd cmake_targets
sudo ./ran_build/build/nr-uesoftmodem -O ../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf --band 254 -C 2488400000 --CO -873500000 -r 25 --numerology 0 --ssb 60 --rfsim --rfsimulator.[0].prop_delay 238.74
```
For LEO satellite scenarios, the parameter `--ntn-initial-time-drift` must be provided via command line, as the UE needs this value to compensate for the time drift during initial sync, before SIB19 was received.
This parameter provides the drift rate of the complete DL timing (incl. feeder link and service link) in µs/s.
To perform an autonomous TA update based on the DL drift, the boolean parameter `--autonomous-ta` can be added.
If that parameter is omitted, the TA is continuously computed based on the SIB19 information.
For LEO satellite scenario we assume the LO to be very accurate and the main FO contribution comes from Doppler shift.
Therefore, we use the command line parameter `--cont-fo-comp 2` to continuously compensate the DL Doppler and pre-compensate the UL Doppler.
The initial Doppler frequency offset must be provided via command line with the parameter `--initial-fo`.
For other information on optional NR UE command line options, please refer [here](#optional-nr-ue-command-line-options).
So an example NR UE command for FDD, 5MHz BW, 15 kHz SCS, transparent LEO satellite 5G NR NTN is this:
```
cd cmake_targets
sudo ./ran_build/build/nr-uesoftmodem -O ../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf --band 254 -C 2488400000 --CO -873500000 -r 25 --numerology 0 --ssb 60 --rfsim --rfsimulator.[0].prop_delay 20 --rfsimulator.[0].options chanmod --time-sync-I 0.1 --ntn-initial-time-drift -46 --initial-fo 57340 --cont-fo-comp 2
```
## Specific OAI modes
### 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 and circumventing random access. 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` in the current directory
- the MAC uses a pre-configured allocation of PDSCH and PUSCH with randomly generated payload instead of the standard scheduler. The options `-m`, `-l`, `-t`, `-M`, `-T`, `-D`, and `-U` can be used to configure this scheduler.
- Options `-Dmod`, and `-Umod` were introduced to enable scheduling PDSCH/PUSCH on slots >= 64 in phy-test mode. (in case of >= 120Khz subcarrier spacing and FDD)
- For ex: `-Dmod 2' / '-Umod 2` allocates every 2nd slot for PDSCH or PUSCH respectively.
- See `./nr-softmodem -h` for more information.
At the UE, the `--phy-test` flag will read the binary files `rbconfig.raw` and `reconfig.raw` from the current directory and process them. If you wish to provide a different path for these files, please use the options `--reconfig-file` and `--rbconfig-file`.
```bash
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --phy-test
```
```bash
sudo ./nr-uesoftmodem --phy-test [--reconfig-file ../../../ci-scripts/rrc-files/reconfig.raw --rbconfig-file ../../../ci-scripts/rrc-files/rbconfig.raw]
```
In summary:
- If you are running on the same machine and launched the 2 executables (`nr-softmodem` and `nr-uesoftmodem`) from the same directory, nothing has to be done.
- If you launched the 2 executables from 2 different folders, just point to the location where you launched the `nr-softmodem`:
* `sudo ./nr-uesoftmodem --rfsim --phy-test --reconfig-file /the/path/where/you/launched/nr-softmodem/reconfig-file --rbconfig-file /the/path/where/you/launched/nr-softmodem/rbconfig-file --rfsimulator.[0].serveraddr <TARGET_GNB_INTERFACE_ADDRESS>`
- If you are not running on the same machine, you need to **COPY** the two raw files
* `scp usera@machineA:/the/path/where/you/launched/nr-softmodem/r*config.raw userb@machineB:/the/path/where/you/will/launch/nr-uesoftmodem/`
* Obviously this operation should be done before launching the `nr-uesoftmodem` executable.
In phy-test mode it is possible to mimic the reception of UE Capabilities at gNB through the command line parameter `--uecap_file`. Refer to the [UE Capabilities](#UE-Capabilities) section for more details.
### 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.
The noS1 mode is applicable to both gNB/UE, and enabled by passing `--noS1` as
an option. The gNB/UE will open a TUN interface which the interface names and
IP addresses `oaitun_enb1`/10.0.1.1, and `oaitun_ue1`/10.0.1.2, respectively.
You can then use these interfaces to send traffic, e.g.,
```bash
iperf -sui1 -B 10.0.1.2
```
to open an iperf server on the UE side, and
```bash
iperf -uc 10.0.1.2 -B 10.0.1.1 -i1 -t10 -b1M
```
to send data from the gNB down to the UE.
> Note that this does not work if both interfaces are on the same host. We
recommend to use two different hosts, or at least network namespaces, to route
traffic through the gNB/UE tunnel.
This option is only really helpful for phy-test/do-ra (see below) modes, in
which the UE does not connect to a core network. If the UE connects to a core
network, it receives an IP address for which it automatically opens a network
interface.
### 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 `--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 through the command line parameter `--uecap_file`. Refer to the [UE Capabilities](#UE-Capabilities) section for more details.
To run using the RFsimulator:
```bash
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --do-ra --rfsim
sudo ./nr-uesoftmodem --do-ra --rfsim --rfsimulator.[0].serveraddr 127.0.0.1
```
Using USRPs:
```bash
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --do-ra
```
On a separate machine:
```bash
sudo ./nr-uesoftmodem --do-ra
```
#### Run OAI with SDAP & Custom DRBs
SDAP is enabled by default. To disable SDAP, include `--gNBs.[0].enable_sdap 0` to the binary's arguments.
The DRB creation is dependent on the 5QI.
If the 5QI corresponds to a GBR Flow it assigns a dedicated data radio bearer.
The Non-GBR flows use a shared data radio bearer.
To hardcode the DRBs for testing purposes, simply add `--gNBs.[0].drbs x` to the binary's arguements, where `x` is the number of DRBs, along with SDAP.
The hardcoded DRBs will be treated like GBR Flows. Due to code limitations at this point the max. number of DRBs is 4.
### IF setup with OAI
OAI is also compatible with Intermediate Frequency (IF) equipment, allowing the
use of RF front-ends operating on arbitrary frequency bands that do not conform
to the standardized 3GPP NR bands.
### OAIUE configuration
To configure IF frequencies on the UE side, provide the following command-line
options:
- `if_freq`: DL frequency in Hz
- `if_freq_off`: UL frequency offset in Hz
### gNB configuration
On the gNB side, the corresponding parameters must be set in the RUs section of
the configuration file:
- `if_freq`: DL frequency in Hz
- `if_offset`: UL frequency offset in Hz
> Note: When using a libconfig-based configuration file for the gNB, ensure that
> `if_freq` numeric value is suffixed with "L" so it is correctly parsed as
> 64-bit integer.
#### 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.
On two separate machines with USRPs, run:
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band66.tm1.106PRB.usrpx300.conf
sudo ./nr-uesoftmodem --if_freq 2169080000 --if_freq_off -400000000
```
FAPI splits the L1 and MAC. It is used internally by the monolithic gNB. It is
possible to separate L1 and L2 into separate processes and use shared memory
between both. It is further possible use networked FAPI (nFAPI) to separate L1
and L2 into separate processes on different hosts and use socket-based
communication. See the [FAPI/nFAPI documentation](nfapi.md)
## 5G gNB MIMO configuration
@@ -611,3 +264,19 @@ Finally the number of TX physical antenna in the RU part of the configuration fi
It is possible to limit the number supported DL MIMO layers via RRC configuration, e.g. to a value lower than the number of logical antenna ports configured, by using the configuration file parameter `maxMIMO_layers`.
[Example of configuration file with parameters for 2-layer MIMO](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.fr1.273PRB.2x2.usrpn300.conf)
## IF (Intermediate Frequency) equipment
OAI supports RF front-ends operating on arbitrary frequencies outside standard
3GPP NR bands. Configure in the `RUs` section of the gNB config file:
- `if_freq`: DL frequency in Hz (suffix with `L` in libconfig, e.g. `2169080000L`)
- `if_offset`: UL frequency offset in Hz
## Related documentation
Further documentation not referenced above:
- [Build instructions](BUILD.md)
- [NR SA tutorial with OAI nrUE](NR_SA_Tutorial_OAI_nrUE.md)
- [NTN configuration](ntn-configuration.md)
doc/TESTING_OAI_NSA_COTS_UE.md
+4 -2
View File
@@ -1,8 +1,9 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
STATUS 2020/10/15 : added External Resources section and links
# How to run an NSA setup with eNB/gNB
**Table of Contents**
This page details how to run an non-standalone (NSA) setup, using an eNB and
gNB (both OAI). It might be outdated, but still contains valuable information.
[[_TOC_]]
@@ -227,6 +228,7 @@ Execute:
```
You should see the X2 messages in Wireshark and at the eNB.
## Test Case
doc/dev_tools/tracy.md
+58
View File
@@ -0,0 +1,58 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
# Performance analysis with the Tracy profiler
[[_TOC_]]
## Overview
From the Tracy manual:
> Tracy is a real-time, nanosecond resolution hybrid frame and sampling
> profiler that you can use for remote or embedded telemetry of games and other
> applications. It can profile CPU, GPU, memory allocations, locks, context
> switches, [...]
- Sources are on [Github](https://github.com/wolfpld/tracy)
- There is a [web demo](https://tracy.nereid.pl/)
- You can [watch an intro video](https://youtu.be/ghXk3Bk5F2U?t=37)
- You can [read the manual](https://github.com/wolfpld/tracy/releases/download/v0.13.1/tracy.pdf)
## OAI Integration
To enable Tracy, compile `-DTRACY_ENABLE=ON` in cmake. Note that `build_oai`
has no native switch, but you can use `--cmake-opt -DTRACY_ENABLE=ON` instead.
Furthermore, you will need the Tracy profiler:
- Windows hosts: There is a precompiled `tracy-profiler.exe` on Github
- Linux hosts: Compile tracy-profiler from source as described in the manual.
Start the OAI executable you want to profile. Then, open the profiler, and
click on connect to connect to the executable.
It is also possible to collect data from within docker containers:
- Open port 8086.
- To collect CPU data, make sure that you run docker with `--privileged --mount
"type=bind,source=/sys/kernel/debug,target=/sys/kernel/debug,readonly" --user
0:0 --pid=host` or provide the corresponding options in docker-compose.
## Instrumentation
Instrumentation is done via the header `common/instrumentation.h`. A couple of
places in OAI have been instrumented already, search for the macros mentioned
in `common/instrumentation.h`.
In short, main features already in use:
- Measure specific code regions by surrounding them with `TracyCZone(ctx, true);`
and `TracyCZoneEnd(ctx);`.
- Record individual "Tracy frames" (in the OAI context, that's likely one 4G/5G
slot) with `TracyCFrameMark;`
- Plot values using `TracyCPlot(name, val);`
More information about these macros can be found in the manual.
Make sure to link `utils` into the static library you are modifying to get
tracy header definitions.
doc/ntn-configuration.md
+204
View File
@@ -0,0 +1,204 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
# How to run a NTN configuration
This tutorial explains how to run non-terrestrial network (NTN) setup for both
low-earth orbit (LEO) and geostationary orbit (GEO) scenarios.
It assumes you have a working terrestrial network (TN) setup, include core
network.
[[_TOC_]]
## NTN channel
A 5G NR NTN configuration only works in a non-terrestrial setup.
Therefore either SDR boards and a dedicated NTN channel emulator are required, or RFsimulator has to be configured to simulate a NTN channel.
As shown on the [rfsimulator page](../radio/rfsimulator/README.md), RFsimulator provides different possibilities.
E.g. to perform a simple simulation of a satellite in geostationary orbit (GEO), these parameters should be added to both gNB and UE command lines:
```
--rfsimulator.[0].prop_delay 238.74
```
For simulation of a satellite in low earth orbit (LEO), two channel models have been added to rfsimulator:
- `SAT_LEO_TRANS`: transparent LEO satellite with gNB on ground
- `SAT_LEO_REGEN`: regenerative LEO satellite with gNB on board
Both channel models simulate the delay and Doppler for a circular orbit at 600 km height according to the Matlab function [dopplerShiftCircularOrbit](https://de.mathworks.com/help/satcom/ref/dopplershiftcircularorbit.html).
An example configuration to simulate a transparent LEO satellite with rfsimulator would be:
```
channelmod = {
max_chan=10;
modellist="modellist_rfsimu_1";
modellist_rfsimu_1 = (
{
model_name = "rfsimu_channel_enB0"
type = "SAT_LEO_TRANS";
noise_power_dB = -100;
},
{
model_name = "rfsimu_channel_ue0"
type = "SAT_LEO_TRANS";
noise_power_dB = -100;
}
);
};
```
This configuration is also provided in the file `targets/PROJECTS/GENERIC-NR-5GC/CONF/channelmod_rfsimu_LEO_satellite.conf`.
Additionally, rfsimulator has to be configured to apply the channel model.
This can be done by either providing this line in the conf file in section `rfsimulator`:
```
options = ("chanmod");
```
Or by providing this the the command line parameters:
```
--rfsimulator.[0].options chanmod
```
## gNB
The main parameters to cope with the large NTN propagation delay are cellSpecificKoffset, ta-Common, ta-CommonDrift and the ephemeris data (satellite position and velocity vectors).
The parameter `ntn-UlSyncValidityDuration-r17` indicates the maximum time duration from epochtime during which the UE can apply assistance information without having acquired new assistance information. i.e this enables UE to re-read SIB19 before timer with value ulSyncValidityDuration expires. The unit of the field is in seconds. Example values for GEO: 240s, MEO: 20s, LEO: 5s.
As epochtime is not implemented yet, UE starts the timer from the TTI where SIB19 is received with ntn-UlSyncValidityDuration-r17 IE.
The parameter `cellSpecificKoffset_r17` is the scheduling offset used for the timing relationships that are modified for NTN (see TS 38.213).
The unit of the field Koffset is number of slots for a given subcarrier spacing of 15 kHz.
The parameter `ta-Common-r17` is used to provide the propagation delay between the reference point (at the gNB) and the satellite.
The granularity of ta-Common is 4.072 × 10^(-3) µs. Values are given in unit of corresponding granularity.
The parameter `ta-CommonDrift-r17` indicates the drift rate of the common TA.
The granularity of ta-CommonDrift is 0.2 × 10^(-3) µs/s. Values are given in unit of corresponding granularity.
The satellite position and velocity vartors are provided using the following parameters:
`positionX-r17`, `positionY-r17`, `positionZ-r17`:
X, Y, Z coordinate of satellite position state vector in ECEF. Unit is meter.
Step of 1.3 m. Actual value = field value * 1.3.
`velocityVX-r17`, `velocityVY-r17`, `velocityVZ-r17`:
X, Y, Z coordinate of satellite velocity state vector in ECEF. Unit is meter/second.
Step of 0.06 m/s. Actual value = field value * 0.06.
These parameters can be provided to the gNB in the conf file in the section `servingCellConfigCommon`:
```
...
# GEO satellite
cellSpecificKoffset_r17 = 478;
ta-Common-r17 = 58629666; # 238.74 ms
positionX-r17 = 0;
positionY-r17 = 0;
positionZ-r17 = 32433846;
velocityVX-r17 = 0;
velocityVY-r17 = 0;
velocityVZ-r17 = 0;
# LEO satellite
# cellSpecificKoffset_r17 = 40;
# ta-Common-r17 = 4634000; # 18.87 ms
# ta-CommonDrift-r17 = -230000; # -46 µs/s
# positionX-r17 = 0;
# positionY-r17 = -2166908; # -2816980.4 m
# positionZ-r17 = 4910784; # 6384019.2 m
# velocityVX-r17 = 0;
# velocityVY-r17 = 115246; # 6914.76 m/s
# velocityVZ-r17 = 50853; # 3051.18 m/s
...
```
Besides this, some timers, e.g. `sr_ProhibitTimer_v1700`, `t300`, `t301` and `t319`, in the conf file section `gNBs.[0].TIMERS` might need to be extended for GEO satellites.
```
...
TIMERS :
{
sr_ProhibitTimer = 0;
sr_TransMax = 64;
sr_ProhibitTimer_v1700 = 512;
t300 = 2000;
t301 = 2000;
t319 = 2000;
};
...
```
To improve the achievable UL and DL throughput in conditions with large RTT (esp. GEO satellites), there is a feature defined in REL17 to disable HARQ feedback.
This allows to reuse HARQ processes immediately, but it breaks compatibility with UEs not supporting this REL17 feature.
To enable this feature, the `disable_harq` flag has to be added to the gNB conf file in the section `gNBs.[0]`
```
...
min_rxtxtime = 6;
disable_harq = 1; // <--
servingCellConfigCommon = (
{
...
```
The settings for a transparent GEO satellite scenario are already provided in the file `ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn.conf`.
Using this conf file, an example gNB command for FDD, 5 MHz BW, 15 kHz SCS, transparent GEO satellite 5G NR NTN is this:
```
cd cmake_targets
sudo ./ran_build/build/nr-softmodem -O ../ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn.conf --rfsim
```
To configure NTN gNB with 32 HARQ processes in downlink and uplink, add these settings in conf files under section `gNBs.[0]`
```
...
num_dlharq = 32;
num_ulharq = 32;
...
```
To simulate a LEO satellite channel model with rfsimulator in UL (DL is simulated at the UE side) either the `channelmod` section as shown before has to be added to the gNB conf file, or a channelmod conf file has to be included like this:
```
@include "channelmod_rfsimu_LEO_satellite.conf"
```
The settings for a transparent LEO satellite scenario are already provided in the file `ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn-leo.conf`.
Using this conf file, an example gNB command for FDD, 5 MHz BW, 15 kHz SCS, trasparent LEO satellite 5G NR NTN is this:
```
cd cmake_targets
sudo ./ran_build/build/nr-softmodem -O ../ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn-leo.conf --rfsim
```
## NR UE
At UE side, only few parameters have to be provided, as the UE receives most relevant parameters via SIB19 from the gNB.
But to calculate the UE specific TA, the UE position has to be provided in the `ue.conf` file.
Also the LEO channel model has to be configured, e.g. by using an `@include` statement, just like on the gNB side:
```
...
position0 = {
x = 0.0;
y = 0.0;
z = 6377900.0;
}
@include "channelmod_rfsimu_LEO_satellite.conf"
```
So an example NR UE command for FDD, 5MHz BW, 15 kHz SCS, transparent GEO satellite 5G NR NTN is this:
```
cd cmake_targets
sudo ./ran_build/build/nr-uesoftmodem -O ../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf --band 254 -C 2488400000 --CO -873500000 -r 25 --numerology 0 --ssb 60 --rfsim --rfsimulator.[0].prop_delay 238.74
```
For LEO satellite scenarios, the parameter `--ntn-initial-time-drift` must be provided via command line, as the UE needs this value to compensate for the time drift during initial sync, before SIB19 was received.
This parameter provides the drift rate of the complete DL timing (incl. feeder link and service link) in µs/s.
To perform an autonomous TA update based on the DL drift, the boolean parameter `--autonomous-ta` can be added.
If that parameter is omitted, the TA is continuously computed based on the SIB19 information.
For LEO satellite scenario we assume the LO to be very accurate and the main FO contribution comes from Doppler shift.
Therefore, we use the command line parameter `--cont-fo-comp 2` to continuously compensate the DL Doppler and pre-compensate the UL Doppler.
The initial Doppler frequency offset must be provided via command line with the parameter `--initial-fo`.
For other information on optional NR UE command line options, please refer [here](#optional-nr-ue-command-line-options).
So an example NR UE command for FDD, 5MHz BW, 15 kHz SCS, transparent LEO satellite 5G NR NTN is this:
```
cd cmake_targets
sudo ./ran_build/build/nr-uesoftmodem -O ../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf --band 254 -C 2488400000 --CO -873500000 -r 25 --numerology 0 --ssb 60 --rfsim --rfsimulator.[0].prop_delay 20 --rfsimulator.[0].options chanmod --time-sync-I 0.1 --ntn-initial-time-drift -46 --initial-fo 57340 --cont-fo-comp 2
```
doc/physical-simulators.md
+63 -1
View File
@@ -19,6 +19,7 @@ Physims are essential for:
* Debugging and evaluating new PHY code in isolation
* Regression testing
* Ensuring correctness before merging new contributions into the repository
* Performance measurements
These tests are run automatically as part of the following
pipelines:
@@ -54,9 +55,11 @@ Example:
openair1/SIMULATION/NR_PHY/dlsim.c
```
The actual tests are defined in `openair1/SIMULATION/tests/CMakeLists.txt`.
## How to Run Simulators Using `ctest`
### Option 1: Using CMake
### Option 1: Using CMake (Recommended)
Build the simulators and tests using the dedicated cmake option, then run
`ctest` which will run all registered tests.
@@ -102,6 +105,65 @@ parallel, type
ctest -L nr_ulschsim -j 4
Or you run all 5G tests that `-R` pattern-match on a `dl` pattern:
ctest -R nr_dl
Or you can see the test parameters that would be run for `nr_ulsim` without
actually running the tests
ctest -R nr_ulsim -N -V
Note that the lines `Test command:` show the actual shell code that will be
executed. For increased flexibility, tests are run indirectly through a cmake
script `openair1/SIMULATION/tests/RunTimedTest.cmake` that not only runs the
test, but can also analyze its output. The actual command is passed via a
variable `TEST_CMD` that lists the executable and parameters as a semicolon
(`;`) delimited list. See further below for an example of how to read this.
## Performance evaluation
Some simulators, notably `nr_dlsim` and `nr_ulsim`, provide the possibility to
show performance metrics via option `-P`.
To discover predefined tests, you can search for test cases that define `-P`
like so (note the leading `;` to limit to the test case executable command line
as `-P` is also used by the cmake scripts themselves):
$ ctest -N -V | grep Test\ command: | grep -- ';-P' | tail -n1
213: Test command: /usr/bin/cmake "-DTEST_CMD=/home/richie/oai/build/nr_ulsim;-P;-n300;-b14;-I15;-i;0,1;-g;C,l;-t70;-u;1;-m16;-R106;-r106;-U;1,1,1,2;-W2;-y2;-z4;-s11.2;-S11.2" "-DCHECK_SCRIPT=/home/richie/oai/openair1/SIMULATION/tests/analyze-timing.sh" "-P" "/home/richie/oai/openair1/SIMULATION/tests/RunTimedTest.cmake"
From this, we see that the tests can be run like so, in the same directory as
cmake:
./nr_ulsim -P -n300 -b14 -I15 -i 0,1 -g C,l -t70 -u 1 -m16 -R106 -r106 -U 1,1,1,2 -W2 -y2 -z4 -s11.2 -S11.2
After invoking the tests, you should see processing times for UE TX and gNB RX:
```
UE TX
|__ PHY_PROC_TX 246.01 us (300 trials) ( 73.80 total [ms])
[...]
gNB RX
Total PHY proc rx 2587.88 us (300 trials)
Statistics std=301.10, median=0.00, q1=0.00, q3=0.00 µs (on 0 trials)
|__ RX PUSCH time 875.68 us (300 trials) (262.70 total [ms])
```
You can see average per-trial processing time in micro-seconds, and the total
test times for the 300 trials (`-n`) in milliseconds.
Use `grep` to find the places where these stats are printed, and to see which
variable in the stacks traces the measurement. For `RX PUSCH time`, we can
identify the variable `rx_pusch_stats`:
```
$ git grep -n 'RX PUSCH time' ../
../openair1/SIMULATION/NR_PHY/ulsim.c:1714: printStatIndent(&gNB->rx_pusch_stats, "RX PUSCH time");
```
## Adding a New Physim Test
To define a new test or modify existing ones, update the following file:
doc/runmodem-nrue.md
+328
View File
@@ -0,0 +1,328 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
# General information for nrUE and configuration
This page describes the configuration of the nrUE (applicable for use with any
gNB) as well as OAI-specific modes.
[[_TOC_]]
## General configuration
Command line parameters for UE in standalone 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 516)
To simplify the configuration for the user testing OAI UE with OAI gNB, the latter prints the following LOG that guides the user to correctly set some of the UE command line parameters:
```shell
[PHY] Command line parameters for OAI UE: -C 3319680000 -r 106 --numerology 1 --ssb 516
```
You can run this, using USRPs, on two separate machines:
```shell
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --gNBs.[0].min_rxtxtime 6
sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --ssb 516
```
With the **RFsimulator** (on the same machine), just add the option `--rfsim` to both gNB and NR UE command lines.
UE capabilities can be passed according to the [UE Capabilities](#UE-Capabilities) section.
## Configuration file
The UE can be provided a configuration file on the command line using `-O
<config>`. At the very least, the configuration file should always contain
information on IMSI, key, and PDU session to use for the information:
```shell
uicc0 = {
imsi = "001010000000001";
key = "fec86ba6eb707ed08905757b1bb44b8f";
opc = "C42449363BBAD02B66D16BC975D77CC1";
pdu_sessions = ({ dnn = "oai"; nssai_sst = 1; });
}
```
| **Parameter** | **Description** | **Default Value** |
|---------------|-----------------|-------------------|
| **IMSI** | Unique identifier for the UE within the mobile network. Used by the network to identify the UE during authentication. It ensures that the UE is correctly identified by the network. | 001010000000001 |
| **key** | Cryptographic key shared between the UE and the network, used for encryption during the authentication process. | `fec86ba6eb707ed08905757b1bb44b8f` |
| **OPC** | Operator key for the Milenage Authentication and Key Agreement algorithm used for encryption during the authentication process. | Ensures secure communication between the UE and the network by matching the encryption keys. | `C42449363BBAD02B66D16BC975D77CC1` |
| **DNN** | _Deprecated_: Specifies the name of the data network the UE wishes to connect to, similar to an APN in 4G networks. Use `pdu_sessions` instead. | `oai` |
| **NSSAI** | _Deprecated_: Allows the UE to select the appropriate network slice, which provides different QoS. Use `pdu_sessions` instead. | `1` |
| **pdu_sessions** | list of PDU sessions to request | empty array (no PDU session) |
Note that DNN and NSSAI parameters are deprecated, and `pdu_sessions` should be
used. If the `pdu_sessions` array is present, DNN and NSSAI are ignored.
Each element within the `pdu_sessions` array takes the following parameters.
Multiple PDU sessions can be requested.
| **Parameter** | **Description** | **Default Value** |
|---------------|-----------------|-------------------|
| `id` | ID of the PDU session to request | index of the current element (1..16) |
| `type` | Type of the PDU session to request (allowed: `IPv4`, `IPv6`, `IPv4v6`, `Ethernet` | `IPv4` |
| `dnn` | Specifies the name of the data network the UE wishes to connect to | `oai` |
| `nssai_sst` | Slice Service Type to request (1=eMBB, 2=URLLC, 3=mMTC) | `1` |
| `nssai_sd` | Slice Differentiator to request | `0xffffff` (meaning "no SD") |
For instance, to request two PDU sessions with user-defined IDs, you could
use.
```
uicc0 = {
# ...
pdu_sessions = (
{ id=1; dnn = "oai.ipv4"; type = "IPv4", nssai_sst = 1; },
{ id=2; dnn = "oai.ipv6"; type = "IPv6", nssai_sst = 1; },
);
}
```
### Optional NR-UE command line options
Here are some useful command line options for the NR UE:
| Parameter | Description |
|--------------------------|---------------------------------------------------------------------------------------------------------------|
| `--ue-scan-carrier` | Scan for cells in current bandwidth. This option can be used if the SSB position of the gNB is unknown. If multiple cells are detected, the UE will try to connect to the first cell. By default, this option is disabled and the UE attempts to only decode SSB given by `--ssb`. |
| `--ue-fo-compensation` | Enables the initial frequency offset compensation at the UE. Useful when running over the air and/or without an external clock/time source. |
| `--cont-fo-comp` | Enables the continuous frequency offset (FO) estimation and compensation. Parameter value `1` specifies that the main FO contribution comes from the local oscillator's (LO) accuracy. Parameter value `2` specifies that the main FO contribution comes from Doppler shift. Parameter value `3` specifies that no measured residual DL FO is considered for UL FO pre-compensation. |
| `--initial-fo` | Sets the known initial frequency offset. Useful especially with large Doppler frequency, e.g. LEO satellite. |
| `--freq-sync-P` | Sets the coefficient for the Proportional part of the PI-controller for the continuous frequency offset compensation. Default value 0.01. |
| `--freq-sync-I` | Sets the coefficient for the Integrating part of the PI-controller for the continuous frequency offset compensation. Default value 0.001. |
| `--num-ues` | Run multiple UEs in one process |
| `--ntn-initial-time-drift` | Sets the initial NTN DL time drift (feeder link and service link), given in µs/s. |
| `--autonomous-ta` | Enables the autonomous TA update, based on DL drift (useful if main contribution to DL drift is movement, e.g. LEO satellite). |
| `--time-sync-P` | Sets the coefficient for the Proportional part of the PI-controller for the time synchronization. Default value 0.5. |
| `--time-sync-I` | Sets the coefficient for the Integrating part of the PI-controller for the time synchronization. Default value 0.0. |
| `--usrp-args` | Equivalent to the `sdr_addrs` field in the gNB config file. Used to identify the USRP and set some basic parameters (like the clock source). |
| `--clock-source` | Sets the clock source (internal or external). |
| `--time-source` | Sets the time source (internal or external). |
You can view all available options by typing:
```shell
./nr-uesoftmodem --help
```
### UE Capabilities
The `--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` for 1 layer or e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap_ports2.xml` for 2 layers.
This option is available for the following combinations of operation modes and gNB/nrUE softmodems:
| Mode | Executable | Description |
|------------|----------------|-----------------------------------------------------|
| SA | nr-uesoftmodem | Send UE capabilities from the UE to the gNB via RRC |
| phy-test | nr-softmodem | Mimic the reception of UE capabilities by the gNB |
| do-ra | nr-softmodem | Mimic the reception of UE capabilities by the gNB |
e.g.
```shell
sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3319680000 --ue-nb-ant-tx 2 --ue-nb-ant-rx 2 --uecap_file /opt/oai-nr-ue/etc/uecap.xml
```
## NR UE: Configure multiple RF-frontends (RUs) and UEs in one process
Multiple RF-frontends (also called RUs) can be defined for the nr-uesoftmodem.
Therefore, two sections in the NR UE configuration file are used:
- `RUs`
- `cells`
The `RUs` section in the NR UE configuration file contains an array of elements, where each element has these properies:
| Property name | Type | Default value | Description |
| ---------------- | -------------- | ------------- | ------------------------------------ |
| nb_tx | integer | 1 | Number of TX Antennas |
| nb_rx | integer | 1 | Number of RX Antennas |
| att_tx | integer | 0 | TX Attenuation in dB |
| att_rx | integer | 0 | RX Attenuation in dB |
| max_rxgain | integer | 120 | Maximum RX Gain at 0 dB Attenuation |
| sdr_addrs | string | type=b200 | SDR Parameter String |
| tx_subdev | string | | SDR TX Subdevice |
| rx_subdev | string | | SDR RX Subdevice |
| clock_src | string | internal | SDR Clock Source |
| time_src | string | internal | SDR Time Source |
| tune_offset | floating point | 0.0 | SDR Tune Offset in Hz |
| if_freq | integer | 0 | DL Intermediate Frequency in Hz |
| if_offset | integer | 0 | UL Intermediate Frequency Offset in Hz |
The `cells` section in the NR UE configuration file contains an array of elements, where each element has these properies:
| Property name | Type | Default value | Description |
| ---------------- | ------- | ------------- | ---------------------------------------- |
| ru_id | integer | 0 | ID of the associated RU from the `RUs` section |
| band | integer | 78 | 5G NR Band |
| rf_freq | integer | 0 | DL Carrier Centre Frequency in Hz |
| rf_offset | integer | 0 | DL Carrier Centre Frequency Offset in Hz |
| numerology | integer | 1 | 5G NR Numerology (µ) |
| N_RB_DL | integer | 106 | Number of DL Carrier Ressource Blocks |
| ssb_start | integer | 516 | Ressource Element where the SSB Starts |
There are different scenarios where multiple RF-frontends (also called RUs) are beneficial for the NR UE:
1. RF-Simulator Inter-Frequency Handover between multiple cells
2. Multiple UEs in one instance, each using their own RF-frontend (RF-Simulator connection)
3. Different Antennas connected to different RF-ports
4. Concurrent connection to multiple carriers (carrier aggregation CA)
This would be and example configuration for the 1. scenario:
```
rfsimulator = (
{
serveraddr = "127.0.0.2";
serverport = 4043;
}, {
serveraddr = "127.0.0.3";
serverport = 4044;
}
);
RUs = (
{
nb_tx = 1;
nb_rx = 1;
}, {
nb_tx = 1;
nb_rx = 1;
}
);
cells = (
{
ru_id = 0;
band = 78;
rf_freq = 3619200000L;
numerology = 1;
N_RB_DL = 106;
ssb_start = 516;
}, {
ru_id = 1;
band = 78;
rf_freq = 3649440000L;
numerology = 1;
N_RB_DL = 106;
ssb_start = 516;
}
);
```
An example for the 2. scenario can be found in the file
[ci-scripts/yaml_files/5g_rfsimulator_multiue/nrue.uicc.conf](../ci-scripts/yaml_files/5g_rfsimulator_multiue/nrue.uicc.conf).
Multiple UEs run in one process, and since no RU sharing is implemented (see
below), each UE runs its own RF device, e.g., an RFsimulator connection.
The number of UE instances is controlled by `--num-ues N`. This creates N
independent UE protocol stacks (PHY, MAC, NAS). UE instance `i` reads its
credentials from the `uicc{i}` config section and is assigned `cells[i]` in
order. The config must therefore have at least N `uicc`, `cells`, and `RUs`
entries. Note that **all RUs defined in the `RUs` section are opened and
initialized regardless of `--num-ues`**; extra entries consume resources
without being used by any UE instance.
The 3. scenario is similar to 1., but instead of providing RF-Simulator parameters, actual SDR parameters have to be provided.
The 4. scenario is not supported, as the NR UE does not implement CA, yet.
Current Limitations:
- Each RU can be used by only one cell.
- Each RU and cell can be used by only one UE (no RU sharing implemented, yet).
- The sampling rates of all RUs must be the same.
## Specific OAI modes
These modes are applicable when running both OAI UE and OAI gNB together.
### 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 and circumventing random access. 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` in the current directory
- the MAC uses a pre-configured allocation of PDSCH and PUSCH with randomly generated payload instead of the standard scheduler. The options `-m`, `-l`, `-t`, `-M`, `-T`, `-D`, and `-U` can be used to configure this scheduler.
- Options `-Dmod`, and `-Umod` were introduced to enable scheduling PDSCH/PUSCH on slots >= 64 in phy-test mode. (in case of >= 120Khz subcarrier spacing and FDD)
- For ex: `-Dmod 2' / '-Umod 2` allocates every 2nd slot for PDSCH or PUSCH respectively.
- See `./nr-softmodem -h` for more information.
At the UE, the `--phy-test` flag will read the binary files `rbconfig.raw` and `reconfig.raw` from the current directory and process them. If you wish to provide a different path for these files, please use the options `--reconfig-file` and `--rbconfig-file`.
```bash
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --phy-test
```
```bash
sudo ./nr-uesoftmodem --phy-test [--reconfig-file ../../../ci-scripts/rrc-files/reconfig.raw --rbconfig-file ../../../ci-scripts/rrc-files/rbconfig.raw]
```
In summary:
- If you are running on the same machine and launched the 2 executables (`nr-softmodem` and `nr-uesoftmodem`) from the same directory, nothing has to be done.
- If you launched the 2 executables from 2 different folders, just point to the location where you launched the `nr-softmodem`:
* `sudo ./nr-uesoftmodem --rfsim --phy-test --reconfig-file /the/path/where/you/launched/nr-softmodem/reconfig-file --rbconfig-file /the/path/where/you/launched/nr-softmodem/rbconfig-file --rfsimulator.[0].serveraddr <TARGET_GNB_INTERFACE_ADDRESS>`
- If you are not running on the same machine, you need to **COPY** the two raw files
* `scp usera@machineA:/the/path/where/you/launched/nr-softmodem/r*config.raw userb@machineB:/the/path/where/you/will/launch/nr-uesoftmodem/`
* Obviously this operation should be done before launching the `nr-uesoftmodem` executable.
In phy-test mode it is possible to mimic the reception of UE Capabilities at gNB through the command line parameter `--uecap_file`. Refer to the [UE Capabilities](#UE-Capabilities) section for more details.
### 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.
The noS1 mode is applicable to both gNB/UE, and enabled by passing `--noS1` as
an option. The gNB/UE will open a TUN interface which the interface names and
IP addresses `oaitun_enb1`/10.0.1.1, and `oaitun_ue1`/10.0.1.2, respectively.
You can then use these interfaces to send traffic, e.g.,
```bash
iperf -sui1 -B 10.0.1.2
```
to open an iperf server on the UE side, and
```bash
iperf -uc 10.0.1.2 -B 10.0.1.1 -i1 -t10 -b1M
```
to send data from the gNB down to the UE.
> Note that this does not work if both interfaces are on the same host. We
recommend to use two different hosts, or at least network namespaces, to route
traffic through the gNB/UE tunnel.
This option is only really helpful for phy-test/do-ra (see below) modes, in
which the UE does not connect to a core network. If the UE connects to a core
network, it receives an IP address for which it automatically opens a network
interface.
### 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 `--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 through the command line parameter `--uecap_file`. Refer to the [UE Capabilities](#UE-Capabilities) section for more details.
To run using the RFsimulator:
```bash
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --do-ra --rfsim
sudo ./nr-uesoftmodem --do-ra --rfsim --rfsimulator.[0].serveraddr 127.0.0.1
```
Using USRPs:
```bash
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --do-ra
```
On a separate machine:
```bash
sudo ./nr-uesoftmodem --do-ra
```
openair1/SIMULATION/tests/CMakeLists.txt
+1
View File
@@ -42,6 +42,7 @@ function(add_physim_test test_name test_description test_exec)
ENVIRONMENT "LD_LIBRARY_PATH=.;TEST_DESCRIPTION=${test_description}"
)
set_tests_properties(${test_name} PROPERTIES CHECK_COUNT 0)
add_dependencies(tests ${test_exec})
endfunction()
function(check_threshold testname threshold condition)
radio/USRP/README.md
+54 -1
View File
@@ -15,6 +15,20 @@ Example files can be found in the `ci-scripts/conf_files/` directory with a
`usrp` in the name, for instance
[`gnb.sa.band78.106prb.usrpn310.ddsuu-2x2.conf`](../../ci-scripts/conf_files/gnb.sa.band78.106prb.usrpn310.ddsuu-2x2.conf).
## Build
The OAI USRP driver in leverages the [USRP Hardware
Driver](https://github.com/EttusResearch/uhd) to interface with a USRP.
`build_oai` has support for installing UHD from package manager (Ubuntu) or from
source (other distributions or on request). See [`BUILD.md`](./BUILD.md) for
more information.
Note that OAI comes with a patch for UHD as found in `cmake_targets/tools/`.
This patch is automatically applied when building UHD from source with
`build_oai`, and improves the TX/RX switching times of UHD. If you cannot apply
this patch, the `--continuous-tx` option can be an alternative as described
further below.
## Configuration
The USRP can be configured in the RU section of the config file. The field
@@ -95,6 +109,45 @@ RUs = (
Hint: You cannot see TX/RX spread over multiple USRPs, if you use `internal` as a refrence of the clock and time source.
Furthur information about synchronization on the USRP N3xx devices can be found here: https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
Furthur information about synchronization on the USRP N3xx devices can be found
[in the knowledge base article "Using Ethernet-Based
Synchronization"](https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices).
When combining this with the multi USRP feature you can create a distributed antenna array with only 1 channel used at each USRP.
## Further considerations
### TX/RX switching times
When using TDD (e.g., in 5G/NR band n78), the USRP has to frequently switch
between TX and RX directions. Certain USRPs, e.g., B210, might be too slow for
this, which can result in degraded radio link performance, especially in 5G/NR
operation. In order to get a good performance, there are two workarounds:
1. At runtime: you can use the `--continuous-tx` options at gNB/nrUE. This will
continuously send TX samples, also when the current link direction is to
receive, and we found this to improve the radio link.
2. At compile/build time: apply the UHD patch described further above, which
obliveates the need for `--continuous-tx`.
### Three-quarter sampling
Not all sampling rates can be used with (a) given master sampling rate(s) of a
USRP. Depending on the bandwidth, you might employ (or not) three-quarter
sampling using option `-E`. As a basic rule of thump, 40MHz on B210 needs `-E`,
whereas most other bandwidths on USRPs do not (bu there are exceptions).
### Noise on DC carrier
Some USRPs have noise on the DC carrier, which can degrade the radio signal.
There are two workarounds:
1. Use the `--tune-offset` parameter, which shifts the operating frequency of
the USRP to avoid the use of the DC carrier.
2. `--tune-offset` has a maximum shift frequency. If half the bandwidth is
larger than `--tune-offset`, the DC carrier will still lie within the
carrier. In this case, you can also mask these RBs by using
`gNBs.[0].ul_prbblacklist` in the configuration file.
You can also find more information on this in the [5G/NR gNB with COTS UE
tutorial](./NR_SA_Tutorial_COTS_UE.md).