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

merge latest develop

Browse Source
This commit is contained in:
Laurent OpenCells
2021-07-26 15:03:47 +02:00
parent 39e637b60e d7839d8a60
commit a03ee3548f
576 changed files with 18589 additions and 10859 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/FEATURE_SET.md
+30 -14
View File
@@ -257,7 +257,7 @@ The following features are valid for the gNB and the 5G-NR UE.
* FDD
* Normal CP
* 30 kHz subcarrier spacing
* Bandwidths up to 80MHz (217 Physical Resource Blocks)
* Bandwidths: 10, 20, 40, 80, 100MHz (273 Physical Resource Blocks)
* Intermediate downlink and uplink frequencies to interface with IF equipment
* Single antenna port (single beam)
* Slot format: 14 OFDM symbols in UL or DL
@@ -277,10 +277,20 @@ The following features are valid for the gNB and the 5G-NR UE.
- user-specific search space configured by RRC
- DCI formats: 00, 10 (01 and 11 **under integration**)
* Generation of NR-PDSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
- Single symbol DMRS, DMRS-TypeA-Position Pos2, DMRS configuration type 1
- PDSCH mapping type A
- PDSCH mapping type A and B
- DMRS configuration type 1 and 2
- Single and multiple DMRS symbols
- PTRS support
- Support for 1, 2 and 4 TX antennas
- Support for up to 2 layers (currently limited to DMRS configuration type 2)
* NR-CSI Generation of sequence at PHY (**under integration**)
* NR-PUSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
- PUSCH mapping type A and B
- DMRS configuration type 1 and 2
- Single and multiple DMRS symbols
- PTRS support
- Support for 1 RX antenna
- Support for 1 layer
* NR-PUCCH
- Format 0 (2 bits, mainly for ACK/NACK)
- Format 2 (up to 64 bits, mainly for CSI feedback)
@@ -320,27 +330,33 @@ The following features are valid for the gNB and the 5G-NR UE.
- Creates TUN interface to PDCP to inject and receive user-place traffic
- Will only work with OAI gNB configured in the same mode
## UE PHY Layer ##
## NR UE PHY Layer ##
* Initial synchronization
* Time tracking based on PBCH DMRS
* Time tracking based on PBCH DMRS
* Frequency offset estimation
* PBCH RX
* PDCCH RX
* PDSCH RX, including a first version of dual stream receiver for PDSCH
* 30KHz SCS for FR1 and 120 KHz SCS for FR2
* Generation of NR-PSS/NR-SSS
* Reception of NR-PSS/NR-SSS
* NR-PBCH supports multiple SSBs and flexible periodicity
* Generation of NR-PDCCH for SIB1 (including generation of DCI, polar encoding, scrambling, modulation, RB mapping, etc)
* Reception of NR-PDCCH for SIB1 (including reception of DCI, polar decoding, de-scrambling, de-modulation, RB de-mapping, etc)
- common search space configured by MIB
- user-specific search space configured by RRC
- DCI formats: 00, 10 (01 and 11 **under integration**)
* Generation of NR-PDSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
- Single symbol DMRS, DMRS-TypeA-Position Pos2, DMRS configuration type 1
- PDSCH mapping type A
* Reception of NR-PDSCH (including Segmentation, LDPC decoding, rate de-matching, de-scrambling, de-modulation, RB de-mapping, etc).
- PDSCH mapping type A and B
- DMRS configuration type 1 and 2
- Single and multiple DMRS symbols
- PTRS support
- Support for 1, 2 and 4 RX antennas
- Support for up to 2 layers (currently limited to DMRS configuration type 2)
* NR-CSI Generation of sequence at PHY (**under integration**)
* NR-PUSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
- PUSCH mapping type A and B
- DMRS configuration type 1 and 2
- Single and multiple DMRS symbols
- PTRS support
- Support for 1 TX antenna
- Support for 1 layer
* NR-PUCCH
- Format 0 (2 bits, mainly for ACK/NACK)
- Format 2 (up to 64 bits, mainly for CSI feedback)
@@ -351,7 +367,7 @@ The following features are valid for the gNB and the 5G-NR UE.
* Encoder and decoder for short block
## UE Higher Layers ##
## NR UE Higher Layers ##
**UE MAC**
* Minimum system information (MSI)
doc/RUNMODEM.md
+14 -12
View File
@@ -134,22 +134,24 @@ With the RF simulator (on the same machine):
## SA setup with OAI
The sa flag is used to run gNB in standalone mode. Currently OAI in NR standalone mode transmits and receives SIB1 and triggers the RA procedure for initial access.
The sa flag is used to run gNB in standalone mode.
In order to run gNB in standalone mode, the following flag is needed at gNB:
In order to run gNB and UE in standalone mode, the following flag is needed:
`--sa`
### Run OAI in sa mode
At the gNB the --sa flag does the following
- it reads the RRC configuration from the configuration file
- it encodes the RRCConfiguration and the RBconfig message and stores them in the binary files rbconfig.raw and reconfig.raw
- the RRC encodes SIB1 according the configuration file and transmits it through PDSCH
At the gNB the --sa flag does the following:
- The RRC encodes SIB1 according to the configuration file and transmits it through NR-BCCH-DL-SCH.
At the UE the --sa flag will:
- Read the binary files rbconfig.raw and reconfig.raw from the current directory (a different directory can be specified with the flag --rrc_config_path) and process them
- After the successful decoding of a SIB1 at RRC, the UE will start the 5G NR Initial Access Procedure by triggering the RA procedure.
- 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
### Run OAI in SA mode
From the `cmake_targets/ran_build/build` folder:
@@ -159,13 +161,13 @@ gNB on machine 1:
UE on machine 2:
`sudo ./nr-uesoftmodem --rrc_config_path . --sa`
`sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --sa`
With the RF simulator (on the same machine):
`sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --rfsim --sa`
`sudo ./nr-uesoftmodem --rrc_config_path . --rfsim --sa`
`sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --rfsim --sa`
## IF setup with OAI
doc/SW_archi.md
+38 -32
View File
@@ -171,24 +171,31 @@ NR_sched_pusch_t (for values changing every TTI, e.g., frequency domain
allocation) and NR_sched_pusch_save_t (for values changing less frequently, at
least in FR1 [to my understanding], e.g., DMRS fields when the time domain
allocation stays between TTIs) structures. Furthermore, the preprocessor is an
exchangeable module that might schedule differently, e.g., one user for
phytest, multiple users in FR1, or maybe FR2: phytest is in
nr_ul_preprocessor_phytest(), for FR1 is nr_simple_ulsch_preprocessor() [under
development], for FR2 does not exist yet.
exchangeable module that schedules differently based on a particular
use-case/deployment type, e.g., one user for phytest [in
nr_ul_preprocessor_phytest()], multiple users in FR1
[nr_fr1_ulsch_preprocessor()], or maybe FR2 [does not exist yet]:
* calls preprocessor via pre_processor_ul(): the preprocessor is responsible
for allocating CCEs (using allocate_nr_CCEs()). Note that we do not yet have
scheduling requests or buffer status reports, and only one UE. E.g.,
nr_simple_ulsch_preprocessor():
for allocating CCEs (using allocate_nr_CCEs()) and deciding on resource
allocation for the UEs including TB size. Note that we do not yet have
scheduling requests. What it typically does:
1) check whether the current frame/slot plus K2 is an UL slot, and return if
not.
2) Find first free start RB in vrb_map_UL, and as many free consecutive RBs
as possible.
3) allocate a CCE for the UE (and return if it is not possible)
4) Calculate DMRS stuff (nr_save_pusch_fields()) and the TBS.
5) Mark used resources in vrb_map_UL.
* loop through all users: get a free HARQ PID and
update statistics. Fill nFAPI structures directly for PUSCH, and call
config_uldci() and fill_dci_pdu_rel15() for DCI filling and PDCCH messages.
3) Either set up resource allocation directly (e.g., for a single UE,
phytest), or call into a function to perform actual resource allocation.
Currently, this is done using pf_ul() which implements a basic
proportional fair scheduler:
* for every UE, check for retransmission and allocate as necessary
* Calculate DMRS stuff (nr_set_pusch_semi_static())
* Calculate the PF coefficient and put eligible UEs into a list
* Allocate resources to the UE(s) with the highest coefficient
4) Mark used resources in vrb_map_UL.
* loop through all users: get a HARQ process as indicated through the
preprocessor, update statistics, fill nFAPI structures directly for PUSCH,
and call config_uldci() and fill_dci_pdu_rel15() for DCI filling and PDCCH
messages.
Calls nr_schedule_ue_spec(). It is divided into the "preprocessor" and the
"postprocessor": the first makes the scheduling decisions, the second fills
@@ -196,29 +203,28 @@ nFAPI structures to indicate to the PHY what it is supposed to do. To signal
which users have how many resources, the preprocessor populates the
NR_UE_sched_ctrl_t structure of affected users. In particular, the field rbSize
decides whether a user is to be allocated. Furthermore, the preprocessor is an
exchangeable module that might schedule differently, e.g., one user for
phytest, multiple users in FR1, or maybe FR2: phytest is in
nr_preprocessor_phytest(), for FR1 is nr_simple_dlsch_preprocessor() [under
development], for FR2 does not exist yet.
exchangeable module that schedules differently based on a particular
use-case/deployment type, e.g., one user for phytest [in
nr_preprocessor_phytest()], multiple users in FR1
[nr_fr1_dlsch_preprocessor()], or maybe FR2 [does not exist yet].
* calls preprocessor via pre_processor_dl(): the preprocessor is responsible
for allocating CCEs and PUCCH (using allocate_nr_CCEs() and
nr_acknack_scheduling()) and deciding on the frequency/time domain
allocation. E.g., nr_simple_dlsch_preprocessor():
1) mac_rlc_status_ind() locks and checks directly inside rlc data the
quantity of waiting data.
2) return from the preprocessor if there is no data and no timing advance to
send,
3) otherwise, allocate a CCE for the UE (and return if it is not possible)
4) find a PUCCH occasion for HARQ
5a) check if there is a retransmission: if yes, find free resources to
transmit using the same resources, else
5b) calculate the necessary RBs needed to get a TBS large enough to hold all
data, or until no more resources are available
6) Mark taken resources in the vrb_map
allocation including the TB size. What it typically does:
1) Check available resources in the vrb_map
2) Checks the quantity of waiting data in RLC
3) Either set up resource allocation directly (e.g., for a single UE,
phytest), or call into a function to perform actual resource allocation.
Currently, this is done using pf_dl() which implements a basic
proportional fair scheduler:
* for every UE, check for retransmission and allocate as necessary
* Calculate the PF coefficient and put eligible UEs into a list
* Allocate resources to the UE(s) with the highest coefficient
4) Mark taken resources in the vrb_map
* loop through all users: check if a new TA is necessary. Then, if a user has
allocated resources, compute its TBS, and fill nFAPI structures
(nr_fill_nfapi_dl_pdu() to populate what should be done by the lower layers
to make the Tx subframe). Update statistics (round, sent bytes).
allocated resources, update statistics (round, sent bytes), update HARQ
process information, and fill nFAPI structures (allocate a DCI and PDCCH
messages, TX_req, ...)
# RRC
RRC is a regular thread with itti loop on queue: TASK_RRC_GNB
doc/TESTING_5GSA_setup.md
+162
View File
@@ -0,0 +1,162 @@
# OAI 5G SA tutorial [Under construction]
In the following tutorial we describe how to deploy configure and test the two SA OAI setups:
- SA setup with OAI gNB and COTS UE
- SA setup with OAI gNB and OAI UE
The operating system and hardware requirements to support OAI 5G NR are described [here](https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/5g-nr-development-and-setup).
# 1. SA setup with COTS UE
At the moment of writing this document interoperability with the following COTS UE devices is being tested:
- [Quectel RM500Q-GL](https://www.quectel.com/product/5g-rm500q-gl/)
- [Simcom SIMCOM8200EA](https://www.simcom.com/product/SIM8200G.html)
- Huawei Mate 30 Pro
End-to-end control plane signaling to achieve a 5G SA connection, UE registration and PDU session establishment with the CN, as well as some basic user-plane traffic tests have been validated so far using the Quectel module and Huawei Mate 30 pro and partially validated with SIMCOM module. In terms of interoperability with different 5G Core Networks, so far this setup has been tested with:
- [OAI CN](https://openairinterface.org/oai-5g-core-network-project/)
- Nokia SA Box
- [Free CN](https://www.free5gc.org/)
## 1.1 gNB build and configuration
At the moment of writing this document, most of the code to support the SA setup is not merged into develop branch yet, but it is accessible through the following branches:
- NR_SA_F1AP_5GRECORDS
- develop-NR_SA_F1AP_5GRECORDS (up-to-date with latest develop branch)
To build the gNB executable:
```bash
cd cmake_targets
./build_oai -I -w USRP #For OAI first time installation only to install software dependencies
./build_oai --gNB -w USRP
```
A reference configuration file for the gNB is provided [here](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop-NR_SA_F1AP_5GRECORDS/targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf).
In the following, we highlight the fields of the file that have to be configured according to the configuration and interfaces of the Core Network. First, the PLMN section has to be filled with the proper values that match the configuration of the AMF and the UE USIM.
```bash
// Tracking area code, 0x0000 and 0xfffe are reserved values
tracking_area_code = 1;
plmn_list = ({
mcc = 208;
mnc = 99;
mnc_length = 2;
snssaiList = (
{
sst = 1;
sd = 0x1; // 0 false, else true
},
{
sst = 1;
sd = 0x112233; // 0 false, else true
}
);
});
```
Then, the source and destination IP interfaces for the communication with
the Core Network also need to be set as shown below.
```bash
////////// MME parameters:
amf_ip_address = ( { ipv4 = "192.168.70.132";
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
NETWORK_INTERFACES :
{
GNB_INTERFACE_NAME_FOR_NG_AMF = "demo-oai";
GNB_IPV4_ADDRESS_FOR_NG_AMF = "192.168.70.129/24";
GNB_INTERFACE_NAME_FOR_NGU = "demo-oai";
GNB_IPV4_ADDRESS_FOR_NGU = "192.168.70.129/24";
GNB_PORT_FOR_S1U = 2152; # Spec 2152
};
```
In the first part (*amf_ip_address*) we specify the IP of the AMF and in the second part (*NETWORK_INTERFACES*) we specify the gNB local interface with AMF (N2 interface) and the UPF (N3 interface).
### **gNB configuration in CU/DU split mode**
For the configuration of the gNB in CU and DU blocks the following sample configuration files are provided for the CU and DU entities respectively.
......
At the point of writing this document the control-plane exchanges between the CU and the DU over *F1-C* interface have been validated. The integration of *F1-U* over gtp-u for the support of data plane traffic is ongoing.
## 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). Below are some complementary instructions which can be useful for the deployment.
## 1.3 Execution of SA scenario
After having configured the gNB, we can start the individual components in the following sequence:
- Launch Core Network
- Launch gNB
- Launch COTS UE (disable airplane mode)
The execution command to start the gNB (in monolithic mode) is the following:
```bash
cd cmake_targets/ran_build/build
sudo ./nr-softmodem -E --sa -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf
```
# 2. SA Setup with OAI UE
The SA setup with OAI UE has been validated with RFSIMULATOR for the moment. The control plane for the successful UE registration and PDU Session establishment has been verified with OAI and Nokia SA Box CNs. User-plane traffic validation after the establishment of the 5G connection is still pending for this setup.
In the following, we provide the instructions on how to build, configure and execute this SA setup.
## 2.1 Build and configuration
To build the gNB and OAI UE executables:
```bash
cd cmake_targets
./build_oai -I #For OAI first time installation only to install software dependencies
./build_oai --gNB --nrUE -w SIMU
```
The gNB configuration can be performed according to what is described in section 1.1, using the same reference configuration file as with the RF scenario.
### NAS configuration for the OAI UE
At the moment, the NAS configuration parameters of the OAI UE are hardcoded in ***openair3/NAS/NR_UE/nr_nas_msg_sim.c***. More specifically:
- The SUCI (*Subscription Concealed Identifier*) corresponding to default IMSI 2089900007487 is hardcoded in functions *generateRegistrationRequest()* and *generateIdentityResponse()* through the following lines:
```bash
mm_msg->registration_request.fgsmobileidentity.suci.typeofidentity = FGS_MOBILE_IDENTITY_SUCI;
mm_msg->registration_request.fgsmobileidentity.suci.mncdigit1 = 9;
mm_msg->registration_request.fgsmobileidentity.suci.mncdigit2 = 9;
mm_msg->registration_request.fgsmobileidentity.suci.mncdigit3 = 0xf;
mm_msg->registration_request.fgsmobileidentity.suci.mccdigit1 = 2;
mm_msg->registration_request.fgsmobileidentity.suci.mccdigit2 = 0;
mm_msg->registration_request.fgsmobileidentity.suci.mccdigit3 = 8;
mm_msg->registration_request.fgsmobileidentity.suci.schemeoutput = 0x4778;
```
- USIM_API_K and OPc keys are hardcoded at the beginning of the file:
```bash
// USIM_API_K: fe c8 6b a6 eb 70 7e d0 89 05 75 7b 1b b4 4b 8f
uint8_t k[16] = {0xfe, 0xc8, 0x6b, 0xa6, 0xeb, 0x70, 0x7e, 0xd0, 0x89, 0x05, 0x75, 0x7b, 0x1b, 0xb4, 0x4b, 0x8f};
// OPC: c4 24 49 36 3b ba d0 2b 66 d1 6b c9 75 d7 7c c1
const uint8_t opc[16] = {0xc4, 0x24, 0x49, 0x36, 0x3b, 0xba, 0xd0, 0x2b, 0x66, 0xd1, 0x6b, 0xc9, 0x75, 0xd7, 0x7c, 0xc1};
```
- The NSSAI (*Network Slice Assistance Information*) and DNN (*Data Network Name*) are hardcoded in function *generatePduSessionEstablishRequest()*
```bash
uint8_t nssai[]={1,0,0,1}; //Corresponding to SST:1, SD:1
uint8_t dnn[4]={0x4,0x6f,0x61,0x69}; //Corresponding to dnn:"oai"
```
For interoperability with OAI or other CNs, it should be ensured that the configuration of the aforementioned parameters match the configuration of the corresponding subscribed user at the core network.
Hardcoding of the USIM information will soon be substituted with parsing those parameters from a configuration file.
## 2.2 Execution of SA scenario
The order of starting the different components should be the same as the one described in section 1.3.
- To launch the gNB:
```bash
sudo RFSIMULATOR=server ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --rfsim --sa
```
- To launch the OAI UE:
```bash
sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --rfsim --sa --nokrnmod
```
The IP address at the execution command of the OAI UE corresponds to the target IP of the gNB host that the RFSIMULATOR at the UE will connect to. In the above example, we assume that the gNB and UE are running on the same host so the specified address (127.0.0.1) is the one of the loopback interface.
doc/TESTING_GNB_W_COTS_UE.md
+1
View File
@@ -44,6 +44,7 @@ Our code might not work with all 5G phones yet, but we are constantly improving
* Oppo Reno 5G
* Samsung A90 5G
* Samsung A42 5G
* Google Pixel 5G (note1)
* Simcom SIMCOM8200EA
* Quectel RM500Q-GL
doc/testing_gnb_w_cots_ue_resources/enb.conf
+1 -1
View File
@@ -238,7 +238,7 @@ MACRLCs = (
THREAD_STRUCT = (
{
parallel_config = "PARALLEL_RU_L1_TRX_SPLITaaaaaa";
worker_config = "ENABLE";
worker_config = "WORKER_ENABLE";
}
);