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

Merge remote-tracking branch 'origin/develop' into NR_handling_PMI_report

Browse Source
This commit is contained in:
francescomani
2022-04-03 16:38:32 +02:00
parent 4d289b92cc db00707e66
commit 7901ff998d
405 changed files with 7087 additions and 37644 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/5Gnas.md
-1
View File
@@ -23,7 +23,6 @@ This tuto for 5G gNB NAS design
# source files
executables/ocp-gnb.c: a main loop to create a debuggable gNB, see document SW_archi.md
openair2/RRC/NR/nr_ngap_gNB.c: skeleton for interface with NGAP
openair3/NAS/COMMON/milenage.h: a simple milenage implementation, depend only on crypto library
openair3/NAS/COMMON/NR_NAS_defs.h: messages defined for NAS implemented in C: C struct, C enums and automatic conversion to labels for debug messages
doc/BASIC_SIM.md
-191
View File
@@ -1,191 +0,0 @@
<table style="border-collapse: collapse; border: none;">
<tr style="border-collapse: collapse; border: none;">
<td style="border-collapse: collapse; border: none;">
<a href="http://www.openairinterface.org/">
<img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
</img>
</a>
</td>
<td style="border-collapse: collapse; border: none; vertical-align: center;">
<b><font size = "5">Running OAI Basic Simulator</font></b>
</td>
</tr>
</table>
This page is valid on the following branches:
- `master` starting from tag `v1.1.0`
- `develop` starting from tag `2019.w11`
# 1. Building the basic-simulator.
After the build simplification, the basic simulator is available directly from the standard build.
```bash
$ source oaienv
$ cd cmake_targets
$ ./build_oai --eNB --UE
```
Both eNB (lte-softmodem) and UE (lte-uesoftmodem) are present on `cmake_targets/ran_build/build` folder.
More details are available on the [build page](BUILD.md).
# 2. Running the basic simulator.
The basic simulator is a oai device replacing the radio heads (for example the USRP device). It allows connecting the oai UE and the oai eNodeB through a network interface carrying the time-domain samples, getting rid of over the air unpredictable perturbations.
This is the ideal tool to check signal processing algorithms and protocols implementation and having debug sessions without any HW radio equipment.
The main limitations are:
- A single OAI UE will connect to the OAI eNB
- No channel noise
## 2.1. Starting eNB
The basic simulator is able to run with a connected EPC or without any (the so-called "noS1" mode).
Example 1: running in FDD mode with EPC.
```bash
$ source oaienv
$ cd cmake_targets/ran_build/build
$ ENODEB=1 sudo -E ./lte-softmodem -O $OPENAIR_HOME/ci-scripts/conf_files/lte-fdd-basic-sim.conf --basicsim
```
Edit previously the `ci-scripts/conf_files/lte-fdd-basic-sim.conf` file to modify:
- `N_RB_DL` field to change the Bandwidth (25, 50, 100)
- `CI_MME_IP_ADDR` with the EPC IP address
- `CI_ENB_IP_ADDR` with the container (physical server, virtual machine, ...) on which you are executing the eNB soft-modem
Example 2: running in TDD mode without any EPC.
```bash
$ source oaienv
$ cd cmake_targets/ran_build/build
$ ENODEB=1 sudo -E ./lte-softmodem -O $OPENAIR_HOME/ci-scripts/conf_files/lte-tdd-basic-sim.conf --basicsim --noS1
```
## 2.2. Starting UE
Before starting the UE, you may need to edit the SIM parameters to adapt to your eNB configuration and HSS database.
The <conf> file to use for conf2uedate is `openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf`
You need to set the correct OPC, USIM_API_K, MSIN (this is the end par of the IMSI), HPLMN (the front part of IMSI) to match values from HSS.
```bash
$ source oaienv
# Edit openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf
$ cd cmake_targets/ran_build/build
$ ../../nas_sim_tools/build/conf2uedata -c $OPENAIR_HOME/openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf -o .
$ sudo -E ./lte-uesoftmodem -C 2625000000 -r 25 --ue-rxgain 140 --basicsim [--noS1]
```
The `-r 25` is to use if in the conf file of the eNB you use N_RB_DL=25. Use 50 if you have N_RB_DL=50 and 100 if you have N_RB_DL=100.
The `-C 2625000000` is the downlink frequency. Use the same value as `downlink_frequency` in the eNB configuration file.
The `--noS1` is mandatory if you started the eNB in that mode.
# 3. Testing the data plane
# 3.1. In S1 mode
First we need to retrieve the IP address allocated to the OAI UE.
On the server that runs the UE:
```bash
$ ifconfig oaitun_ue1
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.2 P-t-P:192.172.0.2 Mask:255.255.255.0
...
```
`192.172.0.2` is the IP address that has been allocated by the SPGW in the EPC.
On the server that runs the EPC:
```bash
$ ping -c 20 192.172.0.2
--- 192.172.0.2 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19020ms
rtt min/avg/max/mdev = 13.241/18.999/24.208/2.840 ms
```
You can ping the EPC from the UE:
```bash
$ ping -I oaitun_ue1 -c 20 192.172.0.1
--- 192.172.0.1 ping statistics ---
...
20 packets transmitted, 20 received, 0% packet loss, time 19019ms
rtt min/avg/max/mdev = 13.015/18.674/23.738/2.917 ms
```
For DL iperf testing:
On the server that runs the UE.
```bash
$ iperf -B 192.172.0.2 -u -s -i 1 -fm -p 5001
```
On the server that runs the EPC.
```bash
$ iperf -c 192.172.0.2 -u -t 30 -b 10M -i 1 -fm -B 192.172.0.1 -p 5001
```
For UL iperf testing:
On the server that runs the EPC.
```bash
$ iperf -B 192.172.0.1 -u -s -i 1 -fm -p 5001
```
On the server that runs the UE.
```bash
$ iperf -c 192.172.0.1 -u -t 30 -b 2M -i 1 -fm -B 192.172.0.2 -p 5001
```
# 3.2. In noS1 mode
The IP addresses are fixed. But we can still retrieve them programmatically.
For the UE it is quite the same:
```bash
$ ifconfig oaitun_ue1
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.2 P-t-P:10.0.1.2 Mask:255.255.255.0
...
```
For the eNB:
```bash
$ ifconfig oaitun_enb1
oaitun_enb1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.1 P-t-P:10.0.1.1 Mask:255.255.255.0
...
```
Pinging like this:
```bash
$ ping -I oaitun_ue1 -c 20 10.0.1.1
$ ping -I oaitun_enb1 -c 20 10.0.1.2
```
And the same for iperf:
```bash
$ iperf -B 10.0.1.2 -u -s -i 1 -fm
$ iperf -c 10.0.1.2 -u -b 1.00M -t 30 -i 1 -fm -B 10.0.1.1
```
doc/L2NFAPI.md
+15
View File
@@ -18,6 +18,10 @@ The UE executable is able to "simulate" multiple UEs in order to stimulate the s
**This simulator is available starting the `v1.0.0` release on the `master` branch.**
**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
Currently the Continuous Integration process is validating this simulator the following way:
* the LTE modem executable is run on one host (in our CI deployment it is a **Xenial Virtual Machine**)
@@ -31,6 +35,17 @@ Normally it should be fine to run both executables on the same host using the `l
1. [With S1 -- eNB and UE on 2 hosts](L2NFAPI_S1.md)
2. [No S1 -- eNB and UE on 2 hosts](L2NFAPI_NOS1.md)
**2022/03/08: Starting the `2022.w01` tag on the `develop` branch, the L2 nFAPI simulation is using a proxy.**
A tutorial is available on the [EpiSci GitHub Repository](https://github.com/EpiSci/oai-lte-5g-multi-ue-proxy#readme).
This proxy allows to perform L2 nFAPI simulator for:
* LTE
* 5G-NSA
* 5G-SA
----
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
doc/L2NFAPI_NOS1.md
+4
View File
@@ -12,6 +12,10 @@
</tr>
</table>
**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
## Table of Contents ##
1. [Environment](#1-environment)
doc/L2NFAPI_S1.md
+4
View File
@@ -12,6 +12,10 @@
</tr>
</table>
**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
## Table of Contents ##
1. [Environment](#1-environment)
doc/RUNMODEM.md
+1 -5
View File
@@ -14,10 +14,6 @@
After you have [built the softmodem executables](BUILD.md) you can set your default directory to the build directory `cmake_targets/ran_build/build/` and start testing some use cases. Below, the description of the different oai functionalities should help you choose the oai configuration that suits your need.
# Basic Simulator
See the [dedicated page](BASIC_SIM.md).
# RF Simulator
The rf simulator is a oai device replacing the radio heads (for example the USRP device). It allows connecting the oai UE (LTE or 5G) and respectively the oai eNodeB or gNodeB through a network interface carrying the time-domain samples, getting rid of over the air unpredictable perturbations. This is the ideal tool to check signal processing algorithms and protocols implementation. The rf simulator has some preliminary support for channel modeling.
@@ -33,7 +29,7 @@ It is planned to enhance this simulator with the following functionalities:
This simulator connects a eNodeB and UEs through a nfapi interface, short-cutting the L1 layer. The objective of this simulator is to allow multi UEs simulation, with a large number of UEs (ideally up to 255 ) .Here to ease the platform setup, UEs are simulated via a single `lte-uesoftmodem` instance. Today the CI tests just with one UE and architecture has to be reviewed to allow a number of UE above about 16. This work is on-going.
As for the rf simulator, no specific hardware is required. The [L2 nfapi simlator page](L2NFAPI.md) contains the detailed documentation.
As for the rf simulator, no specific hardware is required. The [L2 nfapi simulator page](L2NFAPI.md) contains the detailed documentation.
# L1 Simulator
doc/SW_archi.md
-4
View File
@@ -85,10 +85,6 @@ end
This tuto for 5G gNB design, with Open Cells main
{: .text-center}
# Top file: executables/ocp-gnb.c
the function main() initializes the data from configuration file
# The main thread is in ru_thread()
The infinite loop:
## rx_rf()
doc/TESTING_5GSA_setup.md
+3 -4
View File
@@ -169,8 +169,7 @@ MACRLCs = (
At the point of writing this document the control-plane exchanges between the CU and the DU over *F1-C* interface, as well as some IP traffic tests over *F1-U* have been validated using the OAI gNB/nrUE in RFSIMULATOR mode.
*These extensions are not yet fully integrated into develop branch, as they are under merge request. Until they get fully integrated, the CU/DU functionalities can be tested in [NR_F1C_F1U_extensions](https://gitlab.eurecom.fr/oai/openairinterface5g/-/tree/NR_F1C_F1U_extensions) branch.*
## 1.2 OAI 5G Core Network installation and configuration
The instructions for the installation of OAI CN components (AMF, SMF, NRF, UPF) using `docker-compose` can be found [here](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/README.md).
@@ -264,12 +263,12 @@ the gNB can be launched in 2 modes:
1. Launch the CU component:
```bash
sudo RFSIMULATOR=server ./nr-softmodem --rfsim --sa \
-O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/cu_gnb.conf
-O ../../../ci-scripts/conf_files/gNB_SA_CU.conf
```
2. Launch the DU component:
```bash
sudo RFSIMULATOR=server ./nr-softmodem --rfsim --sa \
-O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/du_gnb.conf
-O ../../../ci-scripts/conf_files/gNB_SA_DU.conf
```
- To launch the OAI UE (valid in `monolithic` gNB and `CU/DU split` gNB):