Merged latest develop to nfapi
This commit is contained in:
Mahesh
+107
@@ -0,0 +1,107 @@
|
||||
<style type="text/css" rel="stylesheet">
|
||||
|
||||
body {
|
||||
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
|
||||
font-size: 13px;
|
||||
line-height: 18px;
|
||||
color: #fff;
|
||||
background-color: #110F14;
|
||||
}
|
||||
h2 { margin-left: 20px; }
|
||||
h3 { margin-left: 40px; }
|
||||
h4 { margin-left: 60px; }
|
||||
|
||||
.func2 { margin-left: 20px; }
|
||||
.func3 { margin-left: 40px; }
|
||||
.func4 { margin-left: 60px; }
|
||||
|
||||
</style>
|
||||
|
||||
|
||||
This tuto for 5G gNB NAS design
|
||||
{: .text-center}
|
||||
|
||||
# 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
|
||||
openair3/NAS/COMMON/nr_common.c: 5G NAS common code between gNB and UE
|
||||
openair3/UICC/usim_interface.c: UICC simulation for USIM messages
|
||||
|
||||
openair3/NAS/NR_UE/ue_process_nas.c: NAS code for UE
|
||||
|
||||
openair3/NAS/gNB/network_process_nas.c: NAS code for gNB running without 5GC
|
||||
|
||||
openair3/TEST/test5Gnas.c: unitary testing of NAS messages: encodes+decode a standard network entry, mixing code from UE and 5GC (or gNB in noCore)
|
||||
|
||||
# USIM simulation
|
||||
A new USIM simulation, that parameters are in regular OAI config files
|
||||
|
||||
## To open the USIM
|
||||
init_uicc() takes a parameter: the name of the block in the config file
|
||||
In case we run several UEs in one process, the variable section name allows to make several UEs configurations in one config file.
|
||||
|
||||
The NAS implementation uses this possibility.
|
||||
|
||||
# UE side
|
||||
UEprocessNAS() is the entry for all messages.
|
||||
It decodes the message type and call the specific function for each messgae
|
||||
|
||||
## Identityrequest + IdentityResponse
|
||||
When the UE receives the request, it stores the 5GC request parameters in the UE context ( UE->uicc pointer)
|
||||
It calls "scheduleNAS", that would trigger a answer (seeing general archtecture, it will probly be a itti message to future RRC or NGAP thread).
|
||||
|
||||
When the scheduler wants to encode the answer, it calls identityResponse()
|
||||
The UE search for a section in the config file called "uicc"
|
||||
it encodes the NAS answer with the IMSI, as a 4G compatible authentication.
|
||||
A future release would encode 5G SUPI as native 5G UICC.
|
||||
|
||||
## Authenticationrequest + authenticationResponse
|
||||
When the UE receives the request, it stores the 5GC request parameters in the UE context ( UE->uicc pointer)
|
||||
It calls "scheduleNAS", that would trigger a answer (seeing general archtecture, it will probly be a itti message to future RRC or NGAP thread).
|
||||
|
||||
When the scheduler wants to encode the answer, it calls authenticationResponse()
|
||||
The UE search for a section in the config file called "uicc"
|
||||
It uses the Milenage parameters of this section to encode a milenage response
|
||||
A future release would encode 5G new authentication cyphering functions.
|
||||
|
||||
## SecurityModeCommand + securityModeComplete
|
||||
When the UE receives the request it will:
|
||||
Selected NAS security algorithms: store it for future encoding
|
||||
Replayed UE security capabilities: check if it is equal to UE capabilities it sent to the 5GC
|
||||
IMEISV request: to implement
|
||||
ngKSI: Key set Indicator, similator to 4G to select a ciphering keys set
|
||||
|
||||
When the scheduler wants to encode the answer, it calls registrationComplete()
|
||||
|
||||
## registrationComplete
|
||||
To be defined in UE, this NAS message is done after RRC sequence completes
|
||||
|
||||
# gNB side
|
||||
gNB NGAP thread receives the NAS message from PHY layers
|
||||
In normal mode, it send it to the core network with no decoding.
|
||||
|
||||
Here after, the gNB mode "noCore" processing in gNB: NGAP calls the entry function: processNAS() instead of forwarding the packet to the 5GC
|
||||
|
||||
## RRCModeComplete + Identityrequest
|
||||
When the gNB completes RRC attach, it sends a first message to NGAP thread.
|
||||
Normal processing sends NGAP initial UE message, in noCore mode, it should call: identityRequest() that encode the NAS identity request inside the gNB.
|
||||
The gNB NGAP thread then should call the piece of code that forward the message to the UE as when it receives a NAS message from 5GC.
|
||||
|
||||
## All NAS coming from UE
|
||||
When NGAP thread receives a NAS message from lower layers, it encapsulates it to forward it to the 5GC. In "noCore" mode it calls processNAS().
|
||||
|
||||
This function stores in the gNB the NAS data, then it should encode the next message (identity, authentication, security mode) or do nothing (registration complete).
|
||||
|
||||
|
||||
<div class="panel panel-info">
|
||||
**Note**
|
||||
{: .panel-heading}
|
||||
<div class="panel-body">
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -16,6 +16,10 @@ This page is valid on tags starting from **`2019.w09`**.
|
||||
|
||||
# Soft Modem Build Script
|
||||
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
The OAI EPC is developed in a distinct project with it's own [documentation](https://github.com/OPENAIRINTERFACE/openair-epc-fed/wiki) , it is not described here.
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
OAI softmodem sources, which aim to implement 3GPP compliant UEs, eNodeB and gNodeB can be downloaded from the Eurecom [gitlab repository](./GET_SOURCES.md).
|
||||
|
||||
|
||||
@@ -254,9 +254,11 @@ The NAS layer is based on **3GPP 24.301** and implements the following functions
|
||||
The following features are valid for the gNB and the 5G-NR UE.
|
||||
|
||||
* Static TDD,
|
||||
* FDD
|
||||
* Normal CP
|
||||
* 30 kHz subcarrier spacing
|
||||
* Bandwidths up to 80MHz (217 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
|
||||
* Highly efficient 3GPP compliant LDPC encoder and decoder (BG1 and BG2 supported)
|
||||
|
||||
+1
-7
@@ -33,12 +33,8 @@ holds the source code for (eNB RAN + UE RAN).
|
||||
For legal issues (licenses), the core network (EPC) source code is now moved away from
|
||||
the above openairinterface5g git repository.
|
||||
|
||||
* A very old version of the EPC is located under the same GitLab Eurecom server (splitted into 2 Git repos):
|
||||
* [openair-cn](https://gitlab.eurecom.fr/oai/openair-cn.git) with apache license
|
||||
* [xtables-addons-oai](https://gitlab.eurecom.fr/oai/xtables-addons-oai.git) with GPL license
|
||||
* **These repositories are no more maintained.**
|
||||
* A more recent version is available under our GitHub domain:
|
||||
* [OAI GitHub openair-cn](https://github.com/OPENAIRINTERFACE/openair-cn)
|
||||
* [OAI GitHub openair-cn domain](https://github.com/OPENAIRINTERFACE)
|
||||
* Check its wiki pages for more details
|
||||
|
||||
Configure git with your name/email address (only important if you are developer and want to contribute/push code to Git Repository):
|
||||
@@ -80,8 +76,6 @@ you do not have account on gitlab.eurecom.fr, please register yourself to gitlab
|
||||
* `git clone git@gitlab.eurecom.fr:oai/openairinterface5g.git`
|
||||
* Clone with user name/password prompt:
|
||||
* `git clone https://YOUR_USERNAME@gitlab.eurecom.fr/oai/openairinterface5g.git`
|
||||
* `git clone https://YOUR_USERNAME@gitlab.eurecom.fr/oai/openair-cn.git`
|
||||
* `git clone https://YOUR_USERNAME@gitlab.eurecom.fr/oai/xtables-addons-oai.git` (optional, openair-cn build script can do it for you)
|
||||
|
||||
# Which branch to checkout?
|
||||
|
||||
|
||||
+109
@@ -57,6 +57,115 @@ oai supports [number of deployment](FEATURE_SET.md) model, the following are tes
|
||||
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
|
||||
|
||||
# 5G NR
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
|
||||
As of February 2020, all 5G NR development is part of the develop branch (the branch develop-nr is no longer maintained). This also means that all new development will be merged into there once it passes all the CI.
|
||||
|
||||
## 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).
|
||||
|
||||
### Launch gNB
|
||||
|
||||
```bash sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf```
|
||||
|
||||
### Launch eNB
|
||||
|
||||
```bash sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.50PRB.usrpb210.conf```
|
||||
|
||||
|
||||
|
||||
## 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. In this case both gNB and eNB need to be run with the --phy-test flag. At the gNB this flag does the following
|
||||
- it reads the RRC configuration from the configuration file
|
||||
- it encodes the RRCConfiguration and the RBconfig message and stores them in the binary files rbconfig.raw and reconfig.raw
|
||||
- the MAC uses a pre-configured allocation of PDSCH and PUSCH with randomly generated payload
|
||||
|
||||
At the UE the --phy-test flag will
|
||||
- read the binary files rbconfig.raw and reconfig.raw from the current directory (a different directory can be specified with the flag --rrc_config_path) and process them.
|
||||
|
||||
|
||||
### Launch gNB
|
||||
|
||||
```bash sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --phy-test```
|
||||
|
||||
### Launch UE in another window
|
||||
|
||||
```bash sudo ./nr-uesoftmodem --phy-test [--rrc_config_path ../../../ci-scripts/rrc-files]```
|
||||
|
||||
Some other useful paramters of the UE are
|
||||
|
||||
- --ue-fo-compensation: enables the frequency offset compenstation at the UE. This is useful when running over the air and/or without an external clock/time source
|
||||
- --usrp-args: this is the equivalend paramter of sdr_addrs field in the gNB config file and can be used to identify the USRP and set some basic paramters (like the clock source)
|
||||
- --clock-source: sets the clock-source (internal or external).
|
||||
- --time-source: sets the time-source (internal or external).
|
||||
|
||||
## noS1 setup with OAI UE
|
||||
|
||||
Instead of randomly generated payload, in the phy-test mode we can also inject/receive user-plane traffic over a TUN interface. This is the so-called noS1 mode.
|
||||
|
||||
This setup is described in the [rfsimulator page](../targets/ARCH/rfsimulator/README.md#5g-case). In theory this should also work with the real hardware target although this has yet to be tested.
|
||||
|
||||
## do-ra setup with OAI
|
||||
|
||||
The do-ra flag is used to ran the NR Random Access procedures in contention-free mode. Currently OAI implements the RACH process from Msg1 to Msg3.
|
||||
|
||||
In order to run the RA, the following flag is needed for both the gNB and the UE:
|
||||
|
||||
`--do-ra`
|
||||
|
||||
### Run OAI in do-ra mode
|
||||
|
||||
From the `cmake_targets/ran_build/build` folder:
|
||||
|
||||
gNB on machine 1:
|
||||
|
||||
`sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --do-ra`
|
||||
|
||||
UE on machine 2:
|
||||
|
||||
`sudo ./nr-uesoftmodem --do-ra`
|
||||
|
||||
With the RF simulator (on the same machine):
|
||||
|
||||
`sudo RFSIMULATOR=gnb ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --do-ra --rfsim --parallel-config PARALLEL_SINGLE_THREAD`
|
||||
|
||||
`sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem --do-ra --rfsim --parallel-config PARALLEL_SINGLE_THREAD`
|
||||
|
||||
## IF setup with OAI
|
||||
|
||||
The -C and -CO flags can be used together at UE side to set custom downlink and uplink FR1 intermediate frequencies for the IF equipment.
|
||||
|
||||
In order to run this setup, the following flags are needed at the UE side:
|
||||
|
||||
`-C`
|
||||
|
||||
`--CO`
|
||||
|
||||
and the following parameters must be configured in the RUs section of the gNB configuration file:
|
||||
|
||||
`if_freq`
|
||||
|
||||
`if_offset`
|
||||
|
||||
### Run OAI with custom DL/UL intermediate frequencies
|
||||
|
||||
The following example uses DL frequency 2169.080 MHz and UL frequency offset -400 MHz, with a configuration file for band 66 at gNB side.
|
||||
|
||||
From the `cmake_targets/ran_build/build` folder:
|
||||
|
||||
gNB on machine 1:
|
||||
|
||||
`sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band66.tm1.106PRB.usrpx300.conf`
|
||||
|
||||
UE on machine 2:
|
||||
|
||||
`sudo ./nr-uesoftmodem -C 2169080000 --CO -400000000`
|
||||
|
||||
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
As of February 2020, all 5G NR development is part of the develop branch (the branch develop-nr is no longer maintained). This also means that all new development will be merged into there once it passes all the CI.
|
||||
|
||||
|
||||
+212
@@ -0,0 +1,212 @@
|
||||
<style type="text/css" rel="stylesheet">
|
||||
|
||||
body {
|
||||
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
|
||||
font-size: 13px;
|
||||
line-height: 18px;
|
||||
color: #fff;
|
||||
background-color: #110F14;
|
||||
}
|
||||
h2 { margin-left: 20px; }
|
||||
h3 { margin-left: 40px; }
|
||||
h4 { margin-left: 60px; }
|
||||
|
||||
.func2 { margin-left: 20px; }
|
||||
.func3 { margin-left: 40px; }
|
||||
.func4 { margin-left: 60px; }
|
||||
|
||||
</style>
|
||||
|
||||
|
||||
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()
|
||||
Collect radio signal samples from RF board
|
||||
all SDR processing is triggered by I/Q sample reception and it's date (timestamp)
|
||||
TX I/Q samples will have a date in the future, compared to RX timestamp
|
||||
called for each 5G NR slot
|
||||
it blocks until data is available
|
||||
the internal time comes from the RF board sampling numbers
|
||||
(each sample has a incremental number representing a very accurate timing)
|
||||
raw incoming data is in buffer called "rxdata"
|
||||
We derivate frame number, slot number, ... from the RX timestamp
|
||||
{: .func2}
|
||||
## nr_fep_full()
|
||||
"front end processing" of uplink signal
|
||||
performs DFT on the signal
|
||||
same function (duplicates): phy_procedures_gNB_common_RX()
|
||||
it computes the buffer rxdataF (for frequency) from rxdata (samples over time)
|
||||
rxdataF is the rxdata in frequency domain, phase aligned
|
||||
{: .func3}
|
||||
## gNB_top()
|
||||
only compute frame numbre, slot number, ...
|
||||
{: .func3}
|
||||
## ocp_rxtx()
|
||||
main processing for both UL and DL
|
||||
start by calling oai_subframe_ind() that trigger processing in pnf_p7_subframe_ind() purpose ???
|
||||
all the context is in the passed structure UL_INFO
|
||||
the context is not very clear: there is a mutex on it,
|
||||
but not actual coherency (see below handle_nr_rach() assumes data is up-to-date)
|
||||
The first part (in NR_UL_indication, uses the data computed by the lower part (phy_procedures_gNB_uespec_RX), but for the **previous** slot
|
||||
Then, phy_procedures_gNB_uespec_RX will hereafter replace the data for the next run
|
||||
This is very tricky and not thread safe at all.
|
||||
{: .func3}
|
||||
|
||||
### NR_UL_indication()
|
||||
This block processes data already decoded and stored in structures behind UL_INFO
|
||||
{: .func4}
|
||||
|
||||
* handle_nr_rach()
|
||||
process data from RACH primary detection
|
||||
if the input is a UE RACH detection
|
||||
{: .func4}
|
||||
* nr_schedule_msg2()
|
||||
{: .func4}
|
||||
* handle_nr_uci()
|
||||
????
|
||||
{: .func4}
|
||||
* handle_nr_ulsch()
|
||||
handles ulsch data prepared by nr_fill_indication()
|
||||
{: .func4}
|
||||
* gNB_dlsch_ulsch_scheduler ()
|
||||
the **scheduler** is called here, see dedicated chapter
|
||||
{: .func4}
|
||||
* NR_Schedule_response()
|
||||
process as per the scheduler decided
|
||||
{: .func4}
|
||||
|
||||
### L1_nr_prach_procedures()
|
||||
????
|
||||
{: .func4}
|
||||
### phy_procedures_gNB_uespec_RX()
|
||||
* nr_decode_pucch0()
|
||||
actual CCH channel decoding form rxdataF (rx data in frequency domain)
|
||||
populates UL_INFO.uci_ind, actual uci data is in gNB->pucch
|
||||
{: .func4}
|
||||
* nr_rx_pusch()
|
||||
{: .func4}
|
||||
* extracts data from rxdataF (frequency transformed received data)
|
||||
{: .func4}
|
||||
* nr_pusch_channel_estimation()
|
||||
{: .func4}
|
||||
* nr_ulsch_extract_rbs_single()
|
||||
{: .func4}
|
||||
* nr_ulsch_scale_channel()
|
||||
{: .func4}
|
||||
* nr_ulsch_channel_level()
|
||||
{: .func4}
|
||||
* nr_ulsch_channel_compensation()
|
||||
{: .func4}
|
||||
* nr_ulsch_compute_llr()
|
||||
this function creates the "likelyhood ratios"
|
||||
{: .func4}
|
||||
* nr_ulsch_procedures()
|
||||
{: .func4}
|
||||
* actual ULsch decoding
|
||||
{: .func4}
|
||||
* nr_ulsch_unscrambling()
|
||||
{: .func4}
|
||||
* nr_ulsch_decoding()
|
||||
{: .func4}
|
||||
* nr_fill_indication()
|
||||
populate the data for the next call to "NR_UL_indication()"
|
||||
it would be better to call **NR_UL_indication()** now instead of before (on previous slot)
|
||||
{: .func4}
|
||||
|
||||
### phy_procedures_gNB_TX()
|
||||
* nr_common_signal_procedures()
|
||||
generate common signals
|
||||
{: .func4}
|
||||
* nr_generate_dci_top()
|
||||
generate DCI: the scheduling informtion for each UE in both DL and UL
|
||||
{: .func4}
|
||||
* nr_generate_pdsch()
|
||||
generate DL shared channel (user data)
|
||||
{: .func4}
|
||||
|
||||
### nr_feptx_prec()
|
||||
tx precoding
|
||||
{: .func3}
|
||||
### nr_feptx0
|
||||
do the inverse DFT
|
||||
{: .func3}
|
||||
### tx_rf()
|
||||
send radio signal samples to the RF board
|
||||
the samples numbers are the future time for these samples emission on-air
|
||||
{: .func3}
|
||||
|
||||
# Scheduler
|
||||
The scheduler is called by the chain: nr_ul_indication()=>gNB_dlsch_ulsch_scheduler()
|
||||
It calls sub functions to process each physical channel (rach, ...)
|
||||
The scheduler uses and internal map of used RB: vrb_map and vrb_map_UL, so each specific channel scheduler can see the already filled RB in each subframe (the function gNB_dlsch_ulsch_scheduler() clears these two arrays when it starts)
|
||||
|
||||
The scheduler also calls "run_pdcp()", as this is not a autonomous thread, it needs to be called here to update traffic requests (DL) and to propagate waiting UL to upper layers
|
||||
After calling run_pdcp, it updates "rlc" time data but it doesn't actually process rlc
|
||||
it sends a iiti message to activate the thread for RRC, the answer will be asynchronous in ????
|
||||
|
||||
Calls schedule_nr_mib() that calls mac_rrc_nr_data_req() to fill MIB,
|
||||
|
||||
Calls each channel allocation: schedule SI, schedule_ul, schedule_dl, ...
|
||||
this is a major entry for "phy-test" mode: in this mode, the allocation is fixed
|
||||
all these channels goes to mac_rrc_nr_data_req() to get the data to transmit
|
||||
|
||||
nr_schedule_ue_spec() is called
|
||||
* calls nr_simple_dlsch_preprocessor()=> mac_rlc_status_ind() mac_rlc_status_ind() locks and checks directly inside rlc data the quantity of waiting data. So, the scheduler can allocate RBs
|
||||
* calls nr_update_pucch_scheduling()
|
||||
* get_pdsch_to_harq_feedback() to schedule retransmission in DL
|
||||
|
||||
Calls nr_fill_nfapi_dl_pdu() to actually populate what should be done by the lower layers to make the Tx subframe
|
||||
|
||||
|
||||
|
||||
# RRC
|
||||
RRC is a regular thread with itti loop on queue: TASK_RRC_GNB
|
||||
it receives it's configuration in message NRRRC_CONFIGURATION_REQ, then real time mesages for all events: S1/NGAP events, X2AP messages and RRC_SUBFRAME_PROCESS
|
||||
|
||||
RRC_SUBFRAME_PROCESS message is send each subframe
|
||||
|
||||
how does it communicate to scheduler ?
|
||||
|
||||
|
||||
# RLC
|
||||
RLC code is new implementation, not using OAI mechanisms: it is implmented directly on pthreads, ignoring OAI common functions.
|
||||
It runs a thread waiting incoming data, but it is mainly running inside calling thread.
|
||||
It is a library, running in thread RRC (except on itti message: F1AP_UL_RRC_MESSAGE for F1).
|
||||
|
||||
# NGAP
|
||||
NGAP would be a itti thread as is S1AP (+twin thread SCTP that is almost void processing)?
|
||||
About all messages are exchanged with RRC thread
|
||||
|
||||
|
||||
# GTP
|
||||
Gtp + UDP are two twin threads performing the data plane interface to the core network
|
||||
The design is hybrid: thread and inside other threads calls. It should at least be protected by a mutex.
|
||||
## GTP thread
|
||||
Gtp thread has a itti interface: queue TASK_GTPV1_U
|
||||
The interface is about full definition: control messages (create/delet GTP tunnels) and data messages (user plane UL and DL).
|
||||
PDCP layer push to the GTP queue (outside UDP thread that do almost nothing and work only with GTP thread) is to push a UL packet.
|
||||
|
||||
|
||||
## GTP thread running code from other layers
|
||||
gtp thread calls directly pdcp_data_req(), so it runs inside it's context internal pdcp structures updates
|
||||
|
||||
## inside other threads
|
||||
gtpv1u_create_s1u_tunnel(), delete tunnel, ... functions are called inside the other threads, without mutex.
|
||||
|
||||
|
||||
<div class="panel panel-info">
|
||||
**Note**
|
||||
{: .panel-heading}
|
||||
<div class="panel-body">
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
## Table of Contents ##
|
||||
|
||||
1. [Legacy 1 Bench](#legacy-1-bench)
|
||||
2. [Legacy 2 Bench](#legacy-2-bench)
|
||||
3. [Next Bench for DEV](#next-bench-for-dev)
|
||||
4. [Next Bench for CI](#next-bench-for-ci)
|
||||
5. [Indoor Live Network Bench](#indoor-live-network-bench)
|
||||
6. [Outdoor Live Network Bench](#outdoor-live-network-bench)
|
||||
|
||||
|
||||
## Legacy 1 Bench
|
||||
|
||||
**Purpose** : FDD Band 7 and Band 13, LTE-M
|
||||
**Note** : Legacy1 and Legacy2 are duplicated so that they can run in parallel, thus avoiding a CI bottleneck
|
||||
**Note** : Faraday Cages 1 and 2 are physically the same cage
|
||||
|
||||
|
||||
|
||||
## Legacy 2 Bench
|
||||
|
||||
**Purpose** : TDD Band 40, TM2 2xTX 2xRX
|
||||
**Note** : CN can run in a container, could also run on Massive
|
||||
|
||||
|
||||
|
||||
## Next Bench for DEV
|
||||
|
||||
**Note** : Benetel CI can also run on this bench at night
|
||||
|
||||
|
||||
|
||||
|
||||
## Next Bench for CI
|
||||
|
||||
**Note** : The current test running on Caracal could run on this bench with a N300/N300 setup
|
||||
|
||||
|
||||
|
||||
## Indoor Live Network Bench
|
||||
|
||||
|
||||
|
||||
## Outdoor Live Network Bench
|
||||
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<<<<<<< HEAD
|
||||
STATUS 2020/07/30 : under continuous improvement ; updated the configuration files links with CI approved reference files
|
||||
=======
|
||||
STATUS 2020/10/15 : added External Resources section and links
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
|
||||
## Table of Contents ##
|
||||
|
||||
<<<<<<< HEAD
|
||||
1. [Configuration Overview](#configuration-overview)
|
||||
2. [SW Repository / Branch](#repository)
|
||||
3. [Architecture Setup](#architecture-setup)
|
||||
@@ -12,6 +17,31 @@ STATUS 2020/07/30 : under continuous improvement ; updated the configuration fil
|
||||
7. [Log file monitoring](#log-file-monitoring)
|
||||
6. [Required tools for debug](#required-tools-for-debug)
|
||||
7. [Status of interoperability](#status-of-interoperability)
|
||||
=======
|
||||
1. [External Resources](#external-resources)
|
||||
2. [Configuration Overview](#configuration-overview)
|
||||
3. [SW Repository / Branch](#repository)
|
||||
4. [Architecture Setup](#architecture-setup)
|
||||
5. [Build / Install](#build-and-install)
|
||||
6. [Run / Test](#run-and-test)
|
||||
7. [Test case](#test-case)
|
||||
8. [Log file monitoring](#log-file-monitoring)
|
||||
9. [Required tools for debug](#required-tools-for-debug)
|
||||
10. [Status of interoperability](#status-of-interoperability)
|
||||
11. [CI integration](#ci-integration)
|
||||
|
||||
|
||||
## External Resources
|
||||
|
||||
Additional Resources to this page can be found here (special mention to Walter Maguire <wmaguire@live.com>) :
|
||||
https://docs.google.com/document/d/1pL8Szm0ocGxdl5ESVp12Ff71a4PbhCb9SpvbLZzwYbo/edit?usp=sharing
|
||||
At time of writing, the openairinterface5G Commit Tag is 2020.w39
|
||||
|
||||
|
||||
Faraday Cages can be found here :
|
||||
http://www.saelig.com/MFR00066/ste2300.htm
|
||||
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
## Configuration Overview
|
||||
|
||||
@@ -70,7 +100,11 @@ cd cmake_targets/
|
||||
- **EPC**
|
||||
|
||||
for reference:
|
||||
<<<<<<< HEAD
|
||||
https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master-documentation/docs/DEPLOY_HOME.md
|
||||
=======
|
||||
https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
|
||||
|
||||
@@ -204,7 +238,11 @@ The test takes typically a few seconds, max 10-15 seconds. If it takes more than
|
||||
- **EPC** (on EPC host):
|
||||
|
||||
for reference:
|
||||
<<<<<<< HEAD
|
||||
https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master-documentation/docs/DEPLOY_HOME.md
|
||||
=======
|
||||
https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
|
||||
|
||||
@@ -220,17 +258,27 @@ Execute:
|
||||
- **gNB** (on the gNB host)
|
||||
|
||||
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
**ATTENTION** : for the gNB execution,
|
||||
The **-E** option is required to enable the tri-quarter sampling rate when using a B2xx serie USRP
|
||||
The **-E** option is **NOT supported** when using a a N300 USRP
|
||||
|
||||
>>>>>>> fork_develop_new
|
||||
Execute:
|
||||
```
|
||||
~/openairinterface5g/cmake_targets/ran_build/build$ sudo ./nr-softmodem -O **YOUR_GNB_CONF_FILE** -E | tee **YOUR_LOG_FILE**
|
||||
|
||||
```
|
||||
|
||||
<<<<<<< HEAD
|
||||
**ATTENTION** : for the gNB execution,
|
||||
The -E option is required to enable the tri-quarter sampling rate when using a B2xx serie USRP
|
||||
The -E opton is not needed when using a a N300 USRP
|
||||
|
||||
|
||||
=======
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
## Test Case
|
||||
|
||||
@@ -377,6 +425,7 @@ The following parts have been validated with FR1 COTS UE:
|
||||
PDCCH DCI format 1_1 and correponding PDSCH are decoded correctlyby the phone
|
||||
ACK/NACK (PUCCH format 0) are successfully received at gNB
|
||||
|
||||
<<<<<<< HEAD
|
||||
- On going:
|
||||
validation of HARQ procedures
|
||||
Integration with higher layers to replace dummy data with real traffic
|
||||
@@ -387,3 +436,26 @@ The following parts have been validated with FR1 COTS UE:
|
||||
no end-to-end traffic possible
|
||||
|
||||
|
||||
=======
|
||||
- **End-to end UL / DL traffic with HARQ procedures validated (ping, iperf)**
|
||||
|
||||
- Known limitations as of September 2020:
|
||||
DL traffic : 3Mbps
|
||||
UL traffic : 1Mbps
|
||||
some packet losses might still occur even in ideal channel conditions
|
||||
|
||||
|
||||
## CI integration
|
||||
The automation scripts are available on ILIADE.
|
||||
The end-to-end test is integrated in the CI flow in a semi-automated manner, comprising 3 steps:
|
||||
- update a YAML file comprising the IT resources definition, branch and commit number the test has to run on
|
||||
- run the python script that generates the test from the YAML file
|
||||
```
|
||||
python3 obj_build_from_yaml.py py_params_template.yaml fr1.sh
|
||||
```
|
||||
- run the test (fr1.sh)
|
||||
|
||||
At the date of writing, the test comprises the deployment of the components (epc, eNB, gNB, cots ue) and the execution of 2 pings procedures (20 pings in 20sec, then 5 pings in 1sec)
|
||||
|
||||
This automation is run for every integration branch to be merged into develop.
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
Executable
BIN
Binary file not shown.
BIN
Binary file not shown.
|
After Width: | Height: | Size: 248 KiB |
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 119 KiB |
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 154 KiB |
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 181 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 164 KiB |
@@ -187,6 +187,11 @@ eNBs =
|
||||
enable_x2 = "yes";
|
||||
t_reloc_prep = 1000; /* unit: millisecond */
|
||||
tx2_reloc_overall = 2000; /* unit: millisecond */
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
t_dc_prep = 1000; /* unit: millisecond */
|
||||
t_dc_overall = 2000; /* unit: millisecond */
|
||||
>>>>>>> fork_develop_new
|
||||
|
||||
NETWORK_INTERFACES :
|
||||
{
|
||||
|
||||
@@ -212,6 +212,11 @@ gNBs =
|
||||
enable_x2 = "yes";
|
||||
t_reloc_prep = 1000; /* unit: millisecond */
|
||||
tx2_reloc_overall = 2000; /* unit: millisecond */
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
t_dc_prep = 1000; /* unit: millisecond */
|
||||
t_dc_overall = 2000; /* unit: millisecond */
|
||||
>>>>>>> fork_develop_new
|
||||
target_enb_x2_ip_address = (
|
||||
{ ipv4 = "192.168.18.199";
|
||||
ipv6 = "192:168:30::17";
|
||||
|
||||
Reference in New Issue
Block a user