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

Merge branch 'develop' into NR_RRC_PRACH_procedures

Browse Source 
Conflicts:
	executables/nr-ue.c
	openair1/PHY/NR_TRANSPORT/nr_dci_tools.c
	openair1/PHY/NR_UE_TRANSPORT/nr_prach.c
	openair1/PHY/defs_RU.h
	openair1/SCHED_NR_UE/phy_procedures_nr_ue.c
	openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_primitives.c
	openair2/RRC/NR/rrc_gNB_nsa.c
	openair2/X2AP/x2ap_eNB_handler.c
This commit is contained in:
Thomas Schlichter
2020-04-30 18:54:37 +02:00
parent fcf6439040 cd82d94cb2
commit 79471f2f6d
243 changed files with 16121 additions and 6036 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/L2NFAPI.md
+12 -7
View File
@@ -14,19 +14,24 @@
This simulator allows to test L2 and above Layers using the nFAPI interface.
The UE executable is able to "simulate" multiple UEs in order to stimulate the scheduler in the eNB.
**This simulator is available starting the `v1.0.0` release on the `master` branch.**
Currently the only validated deployment by CI and developers is *with S1 interface and eNB / UEs are on the same machine*.
Others deployments will be supported later after bug fixes and validation in the CI process.
1. [With S1 -- eNB and UE on same machine](L2NFAPI_S1.md)
Currently the Continuous Integration process is validating this simulator the following way:
* the LTE modem executable is run on one host (in our CI deployment it is a **Xenial Virtual Machine**)
* the UE(s) modem executable is run on another host (in our CI deployment it is also a **Xenial Virtual Machine**)
* We are testing:
* in S1 mode (ie we are connected to a 3rd-party EPC)
* in noS1 mode (no need for an EPC)
Normally it should be fine to run both executables on the same host using the `loopback` interface to communicate. **But we are not guaranting it**
1. [With S1 -- eNB and UE on 2 hosts](L2NFAPI_S1.md)
2. [No S1 -- eNB and UE on 2 hosts](L2NFAPI_NOS1.md)
----
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
doc/L2NFAPI_NOS1.md
+349
View File
@@ -0,0 +1,349 @@
<table style="border-collapse: collapse; border: none;">
<tr style="border-collapse: collapse; border: none;">
<td style="border-collapse: collapse; border: none;">
<a href="http://www.openairinterface.org/">
<img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
</img>
</a>
</td>
<td style="border-collapse: collapse; border: none; vertical-align: center;">
<b><font size = "5">L2 nFAPI Simulator (no S1 Mode / 2-host deployment)</font></b>
</td>
</tr>
</table>
## Table of Contents ##
1. [Environment](#1-environment)
2. [Retrieve the OAI eNB-UE source code](#2-retrieve-the-oai-enb-ue-source-code)
3. [Setup of the USIM information in UE folder](#3-setup-of-the-usim-information-in-ue-folder)
4. [Setup of the Configuration files](#4-setup-of-the-configuration-files)
1. [The eNB Configuration file](#41-the-enb-configuration-file)
2. [The UE Configuration file](#42-the-ue-configuration-file)
5. [Build OAI UE and eNodeB](#5-build-oai-ue-and-enodeb)
6. [Start the eNB](#6-start-the-enb)
7. [Start the UE](#7-start-the-ue)
8. [Test with ping](#8-test-with-ping)
9. [Limitations](#9-limitations)
# 1. Environment #
You may not have access to an EPC or you don't want to hassle to deploy one.
2 servers are used in this deployment. You can use Virtual Machines instead of each server; like it is done in the CI process.
* Machine B contains the OAI eNB executable (`lte-softmodem`)
* Machine C contains the OAI UE(s) executable (`lte-uesoftmodem`)
Example of L2 nFAPI Simulator testing environment:
<img src="./images/L2-sim-noS1-2-host-deployment.png" alt="" border=3>
Note that the IP addresses are indicative and need to be adapted to your environment.
# 2. Retrieve the OAI eNB-UE source code #
At the time of writing, the tag used in the `develop` branch to do this documentation was `2020.w16`.
The tutorial should be valid for the `master` branch tags such as `v1.2.0` or `v1.2.1`. But you may face issues that could be fixed in newer `develop` tags.
Please try to use the same commit ID on both eNB/UE hosts.
```bash
$ ssh sudousername@machineB
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git enb_folder
cd enb_folder
git checkout develop
```
```bash
$ ssh sudousername@machineC
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ue_folder
cd ue_folder
git checkout develop
```
# 3. Setup of the USIM information in UE folder #
```bash
$ ssh sudousername@machineC
cd ue_folder
# Edit openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf with your preferred editor
```
Edit the USIM information within this file in order to match the HSS database. They **HAVE TO** match:
* PLMN+MSIN and IMSI of users table of HSS database **SHALL** be the same.
* OPC of this file and OPC of users table of HSS database **SHALL** be the same.
* USIM_API_K of this file and the key of users table of HSS database **SHALL** be the same.
When testing multiple UEs, it is necessary to add other UEs information like described below for 2 Users. Only UE0 (first UE) information is written in the original file.
```
UE0:
{
USER: {
IMEI="356113022094149";
MANUFACTURER="EURECOM";
MODEL="LTE Android PC";
PIN="0000";
};
SIM: {
MSIN="0000000001"; // <-- Modify here
USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";
OPC="e734f8734007d6c5ce7a0508809e7e9c";
MSISDN="33611123456";
};
...
};
// Copy the UE0 and edit
UE1: // <- Edit here
{
USER: {
IMEI="356113022094149";
MANUFACTURER="EURECOM";
MODEL="LTE Android PC";
PIN="0000";
};
SIM: {
MSIN="0000000002"; // <-- Modify here
USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";
OPC="e734f8734007d6c5ce7a0508809e7e9c";
MSISDN="33611123456";
};
...
};
```
You can repeat the operation for as many users you want to test with.
# 4. Setup of the Configuration files #
**CAUTION: both proposed configuration files resides in the ci-scripts realm. You can copy them but you CANNOT push any modification on these 2 files as part of an MR without informing the CI team.**
## 4.1. The eNB Configuration file ##
```bash
$ ssh sudousername@machineB
cd enb_folder
# Edit ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf with your preferred editor
```
First verify the nFAPI interface setup on the physical ethernet interface of machineB and put the proper IP addresses for both hosts.
```
MACRLCs = (
{
num_cc = 1;
local_s_if_name = "ens3"; // <-- HERE
remote_s_address = "192.168.122.169"; // <-- HERE
local_s_address = "192.168.122.31"; // <-- HERE
local_s_portc = 50001;
remote_s_portc = 50000;
local_s_portd = 50011;
remote_s_portd = 50010;
tr_s_preference = "nfapi";
tr_n_preference = "local_RRC";
}
);
```
If you are testing more than 16 UEs, a proper setting on the RUs is necessary. **Note that this part is NOT present in the original configuration file**.
```
RUs = (
{
local_rf = "yes"
nb_tx = 1
nb_rx = 1
att_tx = 20
att_rx = 0;
bands = [38];
max_pdschReferenceSignalPower = -23;
max_rxgain = 116;
eNB_instances = [0];
}
);
```
Last, the S1 interface shall be properly set.
```
////////// MME parameters:
mme_ip_address = ( { ipv4 = "CI_MME_IP_ADDR"; // replace with 192.168.122.195
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
NETWORK_INTERFACES :
{
ENB_INTERFACE_NAME_FOR_S1_MME = "ens3"; // replace with the proper interface name
ENB_IPV4_ADDRESS_FOR_S1_MME = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
ENB_INTERFACE_NAME_FOR_S1U = "ens3"; // replace with the proper interface name
ENB_IPV4_ADDRESS_FOR_S1U = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
ENB_PORT_FOR_S1U = 2152; # Spec 2152
ENB_IPV4_ADDRESS_FOR_X2C = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
ENB_PORT_FOR_X2C = 36422; # Spec 36422
};
```
## 4.2. The UE Configuration file ##
```bash
$ ssh sudousername@machineB
cd ue_folder
# Edit ci-scripts/conf_files/ue.nfapi.conf with your preferred editor
```
Verify the nFAPI interface setup on the loopback interface.
```
L1s = (
{
num_cc = 1;
tr_n_preference = "nfapi";
local_n_if_name = "ens3"; // <- HERE
remote_n_address = "192.168.122.31"; // <- HERE
local_n_address = "192.168.122.169"; // <- HERE
local_n_portc = 50000;
remote_n_portc = 50001;
local_n_portd = 50010;
remote_n_portd = 50011;
}
);
```
# 5. Build OAI UE and eNodeB #
See [Build documentation](./BUILD.md).
# 6. Start the eNB #
In the first terminal (the one you used to build the eNB):
```bash
$ ssh sudousername@machineB
cd enb_folder/cmake_targets
sudo -E ./ran_build/build/lte-softmodem -O ../ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf --noS1 > enb.log 2>&1
sleep 10
ifconfig
ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.122.31 Bcast:192.168.122.255 Mask:255.255.255.0
....
oaitun_enb1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.1 P-t-P:192.172.0.2 Mask:255.255.255.0
....
```
If you don't use redirection, you can test but many logs are printed on the console and this may affect performance of the L2-nFAPI simulator.
We do recommend the redirection in steady mode once your setup is correct.
# 7. Start the UE #
In the second terminal (the one you used to build the UE):
```bash
$ ssh sudousername@machineC
cd ue_folder/cmake_targets
# Test 64 UEs, 1 thread in FDD mode
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
# Test 64 UEs, 1 thread in TDD mode
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 -T 1 > ue.log 2>&1
# The "-T 1" option means TDD config
```
- The number of UEs can set by using `--num-ues` option and the maximum UE number is 255 (with the `--mu*` options, otherwise 16).
- The number of threads can set with the `--nums-ue-thread`. This number **SHALL NOT** be greater than the number of UEs.
* At the time of writing, it seems to be enough to run on a single thread.
- The `--nokrnmod 1` option makes use of the preferred and supported tunnel interface.
- How many UE that can be tested depends on hardware (server , PC, etc) performance in your environment.
For example, running with 4 UEs:
```bash
$ ssh sudousername@machineC
cd ue_folder/cmake_targets
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
sleep 10
ifconfig
ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.122.169 Bcast:192.168.122.255 Mask:255.255.255.0
....
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.2 P-t-P:192.172.0.2 Mask:255.255.255.0
....
oaitun_ue2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.3 P-t-P:192.172.0.3 Mask:255.255.255.0
....
oaitun_ue3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.4 P-t-P:192.172.0.4 Mask:255.255.255.0
....
oaitun_ue4 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.5 P-t-P:192.172.0.5 Mask:255.255.255.0
....
oaitun_uem1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.2.2 P-t-P:10.0.2.2 Mask:255.255.255.0
....
....
```
Having the 4 oaitun_ue tunnel interfaces up and with an allocated address means the connection with EPC went alright.
# 8. Test with ping #
In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB: Check with ifconfig
```bash
$ ssh sudousername@machineB
# Ping UE1 IP address based on the EPC pool used: in this example:
ping -I oaitun_enb1 -c 20 10.0.1.2
# Ping UE4 IP address based on the EPC pool used: in this example:
ping -I oaitun_enb1 -c 20 10.0.1.5
```
Ping from the UE side:
```bash
$ ssh sudousername@machineC
ping -I oaitun_ue1 -c 20 10.0.1.1
ping -I oaitun_ue3 -c 20 10.0.1.1
```
iperf operations can also be performed.
DL traffic:
```bash
$ ssh sudousername@machineC
iperf -B 10.0.1.2 -u -s -i 1 -fm -p 5002
$ ssh sudousername@machineB
iperf -c 10.0.1.2 -u -t 30 -b 3M -i 1 -fm -B 10.0.1.1 -p 5002
```
UL traffic:
```bash
$ ssh sudousername@machineB
iperf -B 10.0.1.1 -u -s -i 1 -fm -p 5002
$ ssh sudousername@machineC
iperf -c 10.0.1.1 -u -t 30 -b 2M -i 1 -fm -B 10.0.1.2 -p 5002
```
# 9. Limitations #
----
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
[L2 nfapi simulator](L2NFAPI.md)
doc/L2NFAPI_S1.md
+97 -70
View File
@@ -7,7 +7,7 @@
</a>
</td>
<td style="border-collapse: collapse; border: none; vertical-align: center;">
<b><font size = "5">L2 nFAPI Simulator (with S1 / same machine deployment)</font></b>
<b><font size = "5">L2 nFAPI Simulator (with S1 / 2-host deployment)</font></b>
</td>
</tr>
</table>
@@ -21,25 +21,24 @@
5. [Setup of the Configuration files](#5-setup-of-the-configuration-files)
1. [The eNB Configuration file](#51-the-enb-configuration-file)
2. [The UE Configuration file](#52-the-ue-configuration-file)
6. [Bring Up a second loopback interface](#6-bring-up-a-second-loopback-interface)
7. [Build the eNB](#7-build-the-enb)
8. [Build the UE](#8-build-the-ue)
9. [Initialize the NAS UE Layer](#9-initialize-the-nas-ue-layer)
10. [Start the eNB](#10-start-the-enb)
11. [Start the UE](#11-start-the-ue)
12. [Test with ping](#12-test-with-ping)
13. [Limitations](#13-limitations)
6. [Build OAI UE and eNodeB](#6-build-oai-ue-and-enodeb)
7. [Start EPC](#7-start-epc)
8. [Start the eNB](#8-start-the-enb)
9. [Start the UE](#9-start-the-ue)
10. [Test with ping](#10-test-with-ping)
11. [Limitations](#11-limitations)
# 1. Environment #
2 servers are used in this deployment. You can use Virtual Machines instead of each server; like it is done in the CI process.
3 servers are used in this deployment. You can use Virtual Machines instead of each server; like it is done in the CI process.
* Machine A contains the EPC.
* Machine B contains the OAI eNB and the OAI UE(s)
* Machine B contains the OAI eNB executable (`lte-softmodem`)
* Machine C contains the OAI UE(s) executable (`lte-uesoftmodem`)
Example of L2 nFAPI Simulator testing environment:
<img src="../l2-nfapi-simulator/L2-sim-single-server-deployment.png" alt="" border=3>
<img src="./images/L2-sim-S1-3-host-deployment.png" alt="" border=3>
Note that the IP addresses are indicative and need to be adapted to your environment.
@@ -47,26 +46,35 @@ Note that the IP addresses are indicative and need to be adapted to your environ
Create the environment for the EPC and register all **USIM** information into the **HSS** database.
If you are using OAI-EPC ([see on GitHub](https://github.com/OPENAIRINTERFACE/openair-cn)), build **HSS/MME/SPGW** and create config files.
If you are using OAI-EPC ([see on GitHub](https://github.com/OPENAIRINTERFACE/openair-epc-fed)), build **HSS/MME/SPGW** and create config files.
# 3. Retrieve the OAI eNB-UE source code #
The eNB and the UE executables will compiled into 2 separate folders on the same machine `B`.
At the time of writing, the tag used in the `develop` branch to do this documentation was `2020.w16`.
The tutorial should be valid for the `master` branch tags such as `v1.2.0` or `v1.2.1`. But you may face issues that could be fixed in newer `develop` tags.
Please try to use the same commit ID on both eNB/UE hosts.
```bash
$ ssh sudousername@machineB
$ git clone https://gitlab.eurecom.fr/oai/openairinterface5g/ enb_folder
$ cd enb_folder
$ git checkout -f v1.0.0
$ cd ..
$ cp -Rf enb_folder ue_folder
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git enb_folder
cd enb_folder
git checkout develop
```
```bash
$ ssh sudousername@machineC
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ue_folder
cd ue_folder
git checkout develop
```
# 4. Setup of the USIM information in UE folder #
```bash
$ ssh sudousername@machineB
$ cd ue_folder
$ ssh sudousername@machineC
cd ue_folder
# Edit openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf with your preferred editor
```
@@ -126,19 +134,19 @@ You can repeat the operation for as many users you want to test with.
```bash
$ ssh sudousername@machineB
$ cd enb_folder
cd enb_folder
# Edit ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf with your preferred editor
```
First verify the nFAPI interface setup on the 2nd loopback interface.
First verify the nFAPI interface setup on the physical ethernet interface of machineB and put the proper IP addresses for both hosts.
```
MACRLCs = (
{
num_cc = 1;
local_s_if_name = "lo:"; // <-- HERE
remote_s_address = "127.0.0.1"; // <-- HERE
local_s_address = "127.0.0.2"; // <-- HERE
local_s_if_name = "ens3"; // <-- HERE
remote_s_address = "192.168.122.169"; // <-- HERE
local_s_address = "192.168.122.31"; // <-- HERE
local_s_portc = 50001;
remote_s_portc = 50000;
local_s_portd = 50011;
@@ -171,7 +179,7 @@ Last, the S1 interface shall be properly set.
```
////////// MME parameters:
mme_ip_address = ( { ipv4 = "CI_MME_IP_ADDR"; // replace with 192.168.10.20
mme_ip_address = ( { ipv4 = "CI_MME_IP_ADDR"; // replace with 192.168.122.195
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
@@ -181,11 +189,11 @@ Last, the S1 interface shall be properly set.
NETWORK_INTERFACES :
{
ENB_INTERFACE_NAME_FOR_S1_MME = "ens3"; // replace with the proper interface name
ENB_IPV4_ADDRESS_FOR_S1_MME = "CI_ENB_IP_ADDR"; // replace with 192.168.10.10
ENB_IPV4_ADDRESS_FOR_S1_MME = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
ENB_INTERFACE_NAME_FOR_S1U = "ens3"; // replace with the proper interface name
ENB_IPV4_ADDRESS_FOR_S1U = "CI_ENB_IP_ADDR"; // replace with 192.168.10.10
ENB_IPV4_ADDRESS_FOR_S1U = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
ENB_PORT_FOR_S1U = 2152; # Spec 2152
ENB_IPV4_ADDRESS_FOR_X2C = "CI_ENB_IP_ADDR"; // replace with 192.168.10.10
ENB_IPV4_ADDRESS_FOR_X2C = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
ENB_PORT_FOR_X2C = 36422; # Spec 36422
};
@@ -195,7 +203,7 @@ Last, the S1 interface shall be properly set.
```bash
$ ssh sudousername@machineB
$ cd ue_folder
cd ue_folder
# Edit ci-scripts/conf_files/ue.nfapi.conf with your preferred editor
```
@@ -206,9 +214,9 @@ L1s = (
{
num_cc = 1;
tr_n_preference = "nfapi";
local_n_if_name = "lo"; // <- HERE
remote_n_address = "127.0.0.2"; // <- HERE
local_n_address = "127.0.0.1"; // <- HERE
local_n_if_name = "ens3"; // <- HERE
remote_n_address = "192.168.122.31"; // <- HERE
local_n_address = "192.168.122.169"; // <- HERE
local_n_portc = 50000;
remote_n_portc = 50001;
local_n_portd = 50010;
@@ -217,20 +225,11 @@ L1s = (
);
```
# 6. Bring Up a second loopback interface #
# 6. Build OAI UE and eNodeB #
A second loopback interface is used to connect the eNB and the UEs.
See [Build documentation](./BUILD.md).
```bash
$ ssh sudousername@machineB
$ sudo ifconfig lo: 127.0.0.2 netmask 255.0.0.0 up
```
# 7. [Build OAI UE and eNodeB](BUILD.md) #
# 8. Initialize the NAS UE Layer #
# 7. Start EPC #
Start the EPC on machine `A`.
@@ -239,61 +238,89 @@ $ ssh sudousername@machineA
# Start the EPC
```
# 9. Start the eNB #
# 8. Start the eNB #
In the first terminal (the one you used to build the eNB):
```bash
$ ssh sudousername@machineB
$ cd enb_folder/cmake_targets
$ sudo -E ./ran_build/build/lte-softmodem -O ../ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf > enb.log 2>&1
cd enb_folder/cmake_targets
sudo -E ./ran_build/build/lte-softmodem -O ../ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf > enb.log 2>&1
```
If you don't use redirection, you can test but many logs are printed on the console and this may affect performance of the L2-nFAPI simulator.
We do recommend the redirection in steady mode once your setup is correct.
# 10. Start the UE #
# 9. Start the UE #
In the second terminal (the one you used to build the UE):
```bash
$ ssh sudousername@machineB
$ cd ue_folder/cmake_targets
# Test 64 UEs, 64 threads in FDD mode
$ sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums-ue-thread 64 > ue.log 2>&1
# Test 64 UEs, 64 threads in TDD mode
$ sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums-ue-thread 64 -T 1 > ue.log 2>&1
$ ssh sudousername@machineC
cd ue_folder/cmake_targets
# Test 64 UEs, 1 thread in FDD mode
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
# Test 64 UEs, 1 thread in TDD mode
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 -T 1 > ue.log 2>&1
# The "-T 1" option means TDD config
```
- The number of UEs can set by using `--num-ues` option and the maximum UE number is 255 (with the `--mu*` options, otherwise 16).
- The umber of threads can set with the `--nums-ue-thread`. This number **SHALL NOT** be greater than the number of UEs.
- The number of threads can set with the `--nums-ue-thread`. This number **SHALL NOT** be greater than the number of UEs.
* At the time of writing, it seems to be enough to run on a single thread.
- The `--nokrnmod 1` option makes use of the preferred and supported tunnel interface.
- How many UE that can be tested depends on hardware (server , PC, etc) performance in your environment.
# 11. Test with ping #
For example, running with 4 UEs:
In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB:
```bash
$ ssh sudousername@machineC
cd ue_folder/cmake_targets
sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
sleep 10
ifconfig
ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.122.169 Bcast:192.168.122.255 Mask:255.255.255.0
....
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.2 P-t-P:192.172.0.2 Mask:255.255.255.0
....
oaitun_ue2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.3 P-t-P:192.172.0.3 Mask:255.255.255.0
....
oaitun_ue3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.4 P-t-P:192.172.0.4 Mask:255.255.255.0
....
oaitun_ue4 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.5 P-t-P:192.172.0.5 Mask:255.255.255.0
....
oaitun_uem1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.2.2 P-t-P:10.0.2.2 Mask:255.255.255.0
....
....
```
Having the 4 oaitun_ue tunnel interfaces up and with an allocated address means the connection with EPC went alright.
# 10. Test with ping #
In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB: Check with ifconfig
```bash
$ ssh sudousername@machineA
# Ping UE0 IP address based on the EPC pool used: in this example:
$ ping -c 20 192.168.200.2
# Ping UE1 IP address based on the EPC pool used: in this example:
$ ping -c 20 192.168.200.4
$ ping -c 20 192.172.0.2
# Ping UE4 IP address based on the EPC pool used: in this example:
$ ping -c 20 192.172.0.5
```
# 12. Limitations #
Testing on the CI process is currently limited at time of writing. Improvements will be made soon.
iperf operations can also be performed.
# 11. Limitations #
----
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
doc/SystemX-tutorial-design.md
+336
View File
@@ -0,0 +1,336 @@
# OpenAirInterface for SystemX
# Terminology
****This document use the 5G terminology****
**Central Unit (CU):** It is a logical node that includes the gNB
functions like Transfer of user data, Mobility control, Radio access
network sharing, Positioning, Session Management etc., except those
functions allocated exclusively to the DU. CU controls the operation of
DUs over front-haul (Fs) interface. A central unit (CU) may also be
known as BBU/REC/RCC/C-RAN/V-RAN/VNF
**Distributed Unit (DU):** This logical node includes a subset of the
gNB functions, depending on the functional split option. Its operation
is controlled by the CU. Distributed Unit (DU) also known with other
names like RRH/RRU/RE/RU/PNF.
In OpenAir code, the terminology is often RU and BBU.
# OpenAirUsage
## EPC and general environment
### OAI EPC
Use the stable OAI EPC, that can run in one machine (VM or standalone)
Draft description:
<https://open-cells.com/index.php/2017/08/22/all-in-one-openairinterface-august-22nd/>
## Standalone 4G
EPC+eNB on one machine, the UE can be commercial or OAI UE.
### USRP B210
Main current issue: traffic is good only on coaxial link between UE and
eNB (probably power management issue).
### Simulated RF
Running eNB+UE both OAI can be done over a virtual RF link.
The UE current status is that threads synchronization is implicit in
some cases. As the RF simulator is very quick, a “sleep()” is required
in the UE main loop
(line 1744, targets/RT/USER/lte-ue.c).
Running also the UE in the same machine is possible with simulated RF.
Running in same machine is simpler, offers about infinite speed for
virtual RF samples transmission.
A specific configuration is required because the EPC Sgi interface has
the same IP tunnel end point as the UE.
So, we have to create a network namespace for the UE and to route data
in/out of the namespace.
```bash
ip netns delete aNameSpace 2&gt; /dev/null
ip link delete v-eth1 2&gt; /dev/null
ip netns add aNameSpace
ip link add v-eth1 type veth peer name v-peer1
ip link set v-peer1 netns aNameSpace
ip addr add 10.200.1.1/24 dev v-eth1
ip link set v-eth1 up
iptables -t nat -A POSTROUTING -s 10.200.1.0/255.255.255.0 -o enp0s31f6 \
-j MASQUERADE
iptables -A FORWARD -i enp0s31f6 -o v-eth1 -j ACCEPT
iptables -A FORWARD -o enp0s31f6 -i v-eth1 -j ACCEPT
ip netns exec aNameSpace ip link set dev lo up
ip netns exec aNameSpace ip addr add 10.200.1.2/24 dev v-peer1
ip netns exec aNameSpace ip link set v-peer1 up
ip netns exec aNameSpace bash
```
After the last command, the Linux shell is in the new namespace, ready
to run the UE.
To make user plan traffic, the traffic generator has to run in the same
namespace
```bash
ip netns exec aNameSpace bash
```
The traffic genenrator has to specify the interface:
```bash
route add default oaitun_ue1
```
or specify the outgoing route in the traffic generator (like option “-I”
in ping command).
## Split 6 DL 4G
The contract describes to reuse the uplink existing if4p5 and to develop
is this work the downlink “functional split 6”.
The customer required after signature to develop also the uplink
functional split 6. This is accepted, as long as the whole work is
research with no delivery completeness warranty.
### Simulation
To be able to verify the new features and to help in all future
developments, Open Cells added and improved the Rf board simulator
during this contract.
We added the channel modeling simulation, that offer to simulate various
3GPP defined channels.
### Main loop
The main log is in RF simulator is in
`targets/RT/USER/lte-ru.c and targets/RT/USER/lte-enb.c`
As this piece of SW is very complex and doesn’t meet our goals
(functional split 6), a cleaned version replaces these 2 files in
executables/ocp-main.c (openair1/SCHED/prach\_procedures.c is also
replaced by this new file as it only launching the RACH actual work in a
way not compatible with our FS6).
The main loop cadences the I/Q samples reception, signal processing and
I/Q samples sending.
The main loop uses extensively function pointers to call the right
processing function depending on the split case.
A lot of OAI reduntant global variables contains the same semantic data: time,frame, subframe.
The reworked main loop take care of a uniq variable that comes directly from harware: RF board sampling number.
To use OAI, we need to set all OAI variables that derivates from this timestamp value. The function setAllfromTS() implements this.
### Splitted main level
When FS6 is actived, a main loop for DU (du_fs6()) a main loop for CU case replaces the uniq eNB main loop.
Each of these main loops calls initialization of OAI LTE data and the FS6 transport layer initialization.
Then, it runs a infinite loop on: set time, call UL and DL. The time comes from the RF board, so the DU sends the time to the CU.
This is enough for RF board dialog, but the FS6 is higher in SW layers,
we need to cut higher functions inside downlink and uplink procedures.
As much as possible, the FS6 code is in the directory OPENAIR_DIR/executables. When a given OAI piece of code is small or need complex changes, it is reworked in the file fs6-main.c. The functions naming keeps the OAI function name, adding suffix _fromsplit() or _tosplit().
When this organization would lead to large code copy, it is better to insert modifications in OAI code. This is done in two files:
- openair1/SCHED/phy_procedures_lte_eNb.c: to send signaling channels computation results
- the function sendFs6Ulharq() centralizes all signaling channels forwarding to CU
- openair1/PHY/LTE_TRANSPORT/ulsch_decoding.c: to deal with FS6 user plane split
- sendFs6Ul() is used once to forward user plane to CU
### DownLink
The main procedure is phy\_procedures\_eNB\_TX()
This is building the common channels (beacon, multi-UE signaling).
The FS6 split breaks this function into pieces:
* The multi-UE signals, built by common\_signal\_procedures(),
subframe2harq\_pid(), generate\_dci\_top(), subframe2harq\_pid()
* These functions run in the DU, nevertheless all context has to be sent
(it is also needed partially for UL spitting)
* Run in the DU also to meet the requirement of pushing
in DU the data encoded with large redundancy (&gt;3 redundancy)
* the per UE data: pdsch\_procedures() needs further splitting:
* dlsch\_encoding\_all() that makes the encoding: turbo code
and lte\_rate\_matching\_turbo() that will be in the DU (some
unlikely cases can reach redundancy up to x3, when MCS is very
low (negative SINR cases)).
* dlsch\_encoding() output needs to be transmitted between the
DU and the CU for functional split 6.
* dlsch\_scrambling() that will go in the DU
* dlsch\_modulation() that will go in the DU
The du user plane data is made of expanded bit in OAI at FS6 split level. 1 pair of functions compact back these bits into 8bits/byte before sending data and expand it again in the DU data reception (functions: fs6Dl(un)pack()).
### Uplink
The uplink require configuration that is part of the DL transmission.
It interprets the signalling to extract the RACH and the per UE data
channels.
Ocp-main.c:rxtx() calls directly the entry procedure
phy\_procedures\_eNB\_uespec\_RX() calls:
* rx\_ulsch() that demodulate and extract soft bits per UE.
* This function runs in the DU
* the output data will be processes in the DU, so it needs to be
transmitted to the DU
* ulsch\_decoding() that do lte\_rate\_matching\_turbo\_rx()
sub\_block\_deinterleaving\_turbo()
then turbo decode that is in the CU
* fill\_ulsch\_cqi\_indication() fill\_crc\_indication() , fill\_rx\_indication()
* DU performs the signal processing of each channel data, prepare and sent to the CU the computed result
* Random access channel detection runs in the DU
* the DU reports to the CU only the detected temprary identifier for RACH response
### signaling data in each direction (UL and DL)
* each LTE channel needs to be propagated between CU and DU
* the simplest are the almost static data such as PSS/SSS, that need only static eNB parameters and primary information (frame numbering)
* all the other channels require data transmission CU to DU and DU to CU
* the general design push all the low level processing for these channels in the DU
* the CU interface transports only signal processing results (UL) or configuration to create the RF signal (DL case)
* HARQ is detected in the DU, then only the ACK or NACK is reported to CU
* the CU have to control the power and MCS (modulation and coding scheme)
* the DU performs the signal processing and report only the decoded data like the CQI
* as the DU performas the modulation, scrambling and puncturing, each data packet is associated with the LTE parameters required for these features
* in DL, the CU associates the control parameters and the user plane data
* in UL, the CU sends upfront the scheduled UL data to the DU. So, the DU have the required knowledge to decode the next subframes in time.
### UDP transport layer
A general UDP transport layer is in executables/transport\_split.c
Linux offers a UDP socket builtin timeout, that we use.
In and out buffers are memory zones that contains compacted
(concatenated) UDP chunks.
For output, sendSubFrame() sends each UDP chunk
For input, receiveSubFrame() collects all UDP chunks for a group (a
subframe in OAI LTE case). It returns in the following cases:
- all chunks are received
- a timeout expired
- a chunk from the next subframe already arrived
### Functional split 6 usage
The ocp cleaned main hale to be used: run ocp-softmodem instead of
lte-softmodem.
The functionality and parameters is the same, enhanced with FS6 mode.
The end line option “--split73” enables the fs6 (also called split 7.3) mode and decided to be cu or du.
Example:
```bash
./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 cu:127.0.0.1
```
Run the CU init of the split 6 eNB, that will call du on 127.0.0.1 address
```bash
./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 du:127.0.0.1
```
will run the du, calling the cu on 127.0.0.1
If the CU and the DU are not on the same machine, the remote address of each side need to be specified as per this example
```bash
./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 du:192.168.1.55
```
runs the functional split 6 DU
```bash
./lte-uesoftmodem -C 2685000000 -r 50 --rfsim --rfsimulator.serveraddr 192.168.1.1 -d
```
Runs the UE (to have the UE signal scope, compile it with make uescope)
CU+DU+UE can run with option `--noS1` to avoid to use a EPC and/or with `--rfsim` to simulate RF board
## 5G and F1
Today 5G achievement is limited to physical layer.
The available modulation is 40MHz, that require one X310 or N300 for the
gNB and a X310 or N300 for the nrUE.
### Usage with X310
Linux configuration:
<https://files.ettus.com/manual/page_usrp_x3x0_config.html>
We included most of this configuration included in OAI source code.
Remain to set the NIC (network interface card) MTU to 9000 (jumbo
frames).
### Running 5G
Usage with RFsimulator:
**gNB**
```bash
sudo RFSIMULATOR=server ./nr-softmodem -O \
../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf \
--parallel-config PARALLEL\_SINGLE\_THREAD
```
**nrUE**
```bash
sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem --numerology 1 -r 106 -C \
3510000000 -d
```
doc/images/L2-sim-S1-3-host-deployment.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 87 KiB

doc/images/L2-sim-noS1-2-host-deployment.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 56 KiB