Merge remote-tracking branch 'origin/develop' into bupt-ulmimo-4
This commit is contained in:
francescomani
@@ -0,0 +1,210 @@
|
||||
<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">F1 split design</font></b>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
# 1. Introduction
|
||||
|
||||
We use OpenAirInterface source code, and it's regular deployment scheme.
|
||||
|
||||
F1 specification is in 3GPP documents: TS 38.470 header document and all documents listed in chapter 2 References of TS 38.470.
|
||||
|
||||
This document explains how the source code works.
|
||||
|
||||
Offered features and deployment instructions are described in:
|
||||
https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/f1-interface
|
||||
|
||||
# 2. Common multi-threading architecture #
|
||||
|
||||
The CU and DU interfaces are based on ITTI threads (see oai/common/utils/ocp_itti/itti.md)
|
||||
|
||||
All OAI upper layers use the ITTI framework to run isolated threads dedicated to one feature.
|
||||
The lower layers adopt case by case specific software architecture.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Linux[configuration file] --> APP[gNB_app_task]
|
||||
Socks[Linux UDP] --> GTP[nr_gtpv1u_gNB_task]
|
||||
APP --> CU
|
||||
APP --> DU
|
||||
A[Linux SCTP] -->|sockets| SCTP(OAI itti thread TASK_SCTP)
|
||||
SCTP-->|TASK_NGAP| NG[ngap_gNB_task]
|
||||
NG-->|TASK_SCTP| SCTP
|
||||
SCTP-->|TASK_DU_F1| DU[F1AP_DU_task]
|
||||
SCTP-->|TASK_CU_F1| CU[F1AP_CU_task]
|
||||
CU-->|TASK_RRC_GNB| RRC
|
||||
RRC -->|non ITTI| PHY[OAI L1+L2]
|
||||
RRC -->|API calls to create tunnels| GTP
|
||||
PHY --> |user plane| GTP
|
||||
CU --> |TASK_GTPV1_U| GTP
|
||||
DU --> |TASK_GTPV1_U| GTP
|
||||
```
|
||||
A "task" is a Linux thread running infinite waiting loop on one ITTI queue
|
||||
|
||||
app task manages the initial configuration
|
||||
|
||||
sctp task mamanges the SCTP Linux sockets
|
||||
|
||||
CU code runs in the task F1AP_CU_task. It stores it's private data context in a static variable. No mutex is used, as the single interface to CU ITTI tast in incoming ITTI messages. CU task is a single ITTI queue, but multiple CU could exist in one Linux process, using the "instance id" (called "module id" also) to create separate contextual information for each CU instance.
|
||||
|
||||
DU code runs in the task F1AP_DU_task. The design is similar to CU task
|
||||
|
||||
All GTP-U tunnels are managed in a Linux Thread, that have partially ITTI design:
|
||||
|
||||
1. tunnel creation/deletion is by C API functions direct calls (a mutex protects it)
|
||||
2. outgoing packets are pushed in a ITTI queue to the gtp thread
|
||||
3. incoming packets are sent to the tunnel creator using a C callback (the callback function is given in tunnel creation order). The callback should not block
|
||||
|
||||
|
||||
# 3. CU F1AP messages #
|
||||
|
||||
## startup
|
||||
|
||||
CU thread starts when the CU starts. It opens listening socket on F1AP_PORT_NUMBER by sending the appropriate message to TASK_SCTP.
|
||||
|
||||
It will accept the first incoming connection on this port
|
||||
|
||||
## F1 SETUP
|
||||
|
||||
DU has connected, and sent this message.
|
||||
|
||||
The CU receives, decode it and send relevant information to RRC thread by message F1AP_SETUP_REQ
|
||||
|
||||
## F1 SETUP response
|
||||
|
||||
RRC sends two messages to CU F1 task: the information to encode the F1 setup response and a second message to encode F1AP_GNB_CU_CONFIGURATION_UPDATE
|
||||
|
||||
Upon reception of these two messages the CU task encodes and sends the messages to the DU
|
||||
|
||||
## UE entry
|
||||
|
||||
When CCH channel decoding finds a new UE identity, it call rrc_gNB_generate_RRCSetup() that will send F1AP_DL_RRC_MESSAGE to the CU task.
|
||||
|
||||
The CU encodes and sends to DU DLRRCMessageTransfer
|
||||
|
||||
## UE attach/detach
|
||||
|
||||
When rrc_gNB_process_RRCReconfigurationComplete() occurs, the RRC sends to CU task the message F1AP_UE_CONTEXT_SETUP_REQ. The CU task encodes the F1 message UEContextSetup and send it to the DU over F1AP.
|
||||
|
||||
This function rrc_gNB_process_RRCReconfigurationComplete() also creates the GTP-U user plane bearers.
|
||||
|
||||
## F1AP incoming messages
|
||||
|
||||
SCTP tasks sends a ITTI message SCTP_DATA_IND to the CU task.
|
||||
|
||||
A array of functions pointers and the F1AP standard identifier "procedureCode", the CU calls the appropriate function
|
||||
|
||||
Hereafter the most significant messages processing
|
||||
|
||||
### CU_handle_F1_SETUP_REQUEST
|
||||
|
||||
Transcodes information to the same message toward RRC (F1AP_SETUP_REQ)
|
||||
|
||||
### CU_handle_INITIAL_UL_RRC_MESSAGE_TRANSFER
|
||||
|
||||
Transcodes information to the same message toward RRC (NR_RRC_MAC_CCCH_DATA_IND)
|
||||
|
||||
### CU_handle_UL_RRC_MESSAGE_TRANSFER
|
||||
|
||||
Encode and send data to PDCP (calling pdcp_data_ind ()) for processing UL data.
|
||||
|
||||
# DU F1 Messages
|
||||
|
||||
## Startup
|
||||
|
||||
The task "gNB app" after rzading the configuration file, sends a first message F1AP_SETUP_REQ to DU task
|
||||
|
||||
Using this message, the uniq DU task (Linux Thread) creates a DU instance context memory space, calls SCTP task to create a socket to the CU.
|
||||
|
||||
When it receives from the SCTP task the socket creation success, the DU task encodes+sends the F1 setup message to the CU.
|
||||
|
||||
## F1AP_INITIAL_UL_RRC_MESSAGE
|
||||
|
||||
When MAC layer push UL data to DU task, the DU sends to CU the message InitialULRRCMessageTransfer
|
||||
|
||||
## F1AP_UL_RRC_MESSAGE
|
||||
|
||||
In case of SRB bearer, the RLC layer use this message to push rlc bearer payload to DU task, that forward to CU
|
||||
|
||||
## pdcp_data_ind
|
||||
|
||||
This function call in RLC, when it is a DRB will be replaced by F1-U transport to CU
|
||||
|
||||
## F1AP incoming messages
|
||||
|
||||
SCTP tasks sends a ITTI message SCTP_DATA_IND to the DU task.
|
||||
|
||||
A array of functions pointers and the F1AP standard identifier "procedureCode", the DU calls the appropriate function
|
||||
|
||||
Hereafter the most significant messages processing
|
||||
|
||||
### DU_send_F1_SETUP_RESPONSE
|
||||
|
||||
Decode the CU message, then encode a message to TASK_GNB_APP. The thread "APP" extracts the system information block and reconfigure the DU with: du_extract_and_decode_SI(), configure_gnb_du_mac()
|
||||
|
||||
### DU_handle_gNB_CU_CONFIGURATION_UPDATE
|
||||
|
||||
No developped
|
||||
|
||||
### DU_handle_UE_CONTEXT_SETUP_REQUEST
|
||||
|
||||
Push data to RLC layer for transmisstion in DL (to the UE) by calling enqueue_rlc_data_req()
|
||||
|
||||
### DU_handle_DL_RRC_MESSAGE_TRANSFER
|
||||
|
||||
Depending on the content, adds UE context in DU low layers and/or send data to the UE with rlc_data_req()
|
||||
|
||||
# F1-U messages
|
||||
|
||||
The data path by itself doesn't make any difficulty:
|
||||
1. for UL, rlc calls pdcp_data_ind (DRB) or sends a message to RRC (SRB). So, we can replace pdcp_data_ind() by du_pdcp_data_ind() that will push the message in the GTP tunnel. In CU, assuming the tunnel is in place, the right call back decapsulate the transport (cu_ul_recv()), then calls pdcp_data_ind() in CU
|
||||
The SRB are sent in DU RRC tasks via itti F1AP_UL_RRC_MESSAGE (see above the processing)
|
||||
2. For DL, pdcp (in CU for DRBs) calls rlc_data_req (by a decoupling queue and thread rlc_data_req_thread, so function du_rlc_data_req() or enqueue_rlc_data_req()). in DU, assuming the gtp-u tunnel exists, a reception call back (du_dl_recv()) decapsulate the gtp-u packet and calls du_rlc_data_req()
|
||||
|
||||
Hereafter the processing design, that doesn't require to setup a new context storage, as we can use the GTP-U internal tables: rnti+rb=>teid for outgoing gtp-u packets and teid=>rnti+rb for incoming gtp-u packets
|
||||
|
||||
In CU case, the DRB tunnel to DU and the tunnel on N3 have the same key (rnti, rb id), but they run in two different GTP-U instances.
|
||||
Each instance binds on diffrent sockets.
|
||||
|
||||
For F1-U, both DU and CU binds on the full quadruplet (IP source, port source, IP destination, port destination) from the configuration file parameters:
|
||||
local_s_address, remote_s_address,local_s_portd, remote_s_portd
|
||||
|
||||
These 4 values are in:
|
||||
CU: at cell level (same level as nr_cellid parameter), they are read if tr_s_preference = "f1"; is set
|
||||
DU: in block MACRLCs, if tr_n_preference = "f1"; is set in this block
|
||||
|
||||
## tunnels setup
|
||||
In GTP-U, TS 29.281 specifies a option header (NR RAN Container This extension header may be transmitted in a G-PDU over the X2-U, Xn-U and F1-U user plane interfaces), but it is not mandatory optional header (as is the N3 one).
|
||||
|
||||
So, we can use this header a something reliable with other vendors implementation.
|
||||
|
||||
In DL, we need to associate the packet with: rnti, rb (radio bearer) and "mui" (a OAI internal id that is optional and may be removed soon) to call rlc_data_req()
|
||||
|
||||
In UL, we need also the RNTI, the rb
|
||||
|
||||
So, we need to create a gtp-u tunnel for each rb over F1, then manage in CU and DU the association between a uniq TEid and the pair(rnti, rb). This is already what we have in existing OAI GTP-U layer interface.
|
||||
|
||||
In F1AP, for each "DRB to Be Setup Item IEs", we have a field TNL (transport network layer) to set a specific GTP tunnel (@IP, TEid, udp port is always 2152). This is the same for each message related to DRBs. (F1AP carries the SRB payload inside F1AP).
|
||||
|
||||
So, For each F1AP containing DRB setup/modification/deletion, the related GTP-U tunnels will be modified one to one.
|
||||
The exception is the intialisation of new tunnel: in the call to tunnel creation, we need to send the remote TEID, but we don't know yet if we are the initial source. In this case, we issue a dummy (0xFFFF) remote teid; when we receive the remote answer, we get the source teid, that we can inform GTP-U with (using update tunnel).
|
||||
|
||||
## processing on GTP-U incoming message
|
||||
|
||||
Du_dl_recv() or cu_ul_recv() are called because we have set this callbacks in creat/update tunnel calls to gtp-u. As gtp-u maintains a pair(rnti,rbid) associated to each tunnel, the functions can be very simple stateless callback that calls pdcp_data_ind() or rlc_data_req() to get back in normal processing path
|
||||
|
||||
## CU/DU outgoing
|
||||
|
||||
DU rlc north output goes to du_pdcp_data_ind() that push a outgoing packet request to gtp-u, using the rnti+rb as ids. GTP-U must have the tunnel existing, then it simply implement the same as in N3 for exemple.
|
||||
|
||||
CU pdcp south output calls cu_rlc_data_ind() that do the same symetric processing.
|
||||
|
||||
|
||||
+25
-14
@@ -304,25 +304,36 @@ gtpv1u_create_s1u_tunnel(), delete tunnel, ... functions are called inside the o
|
||||
|
||||
# New GTP
|
||||
## initialization
|
||||
Coexistance until full merge with legacy GTP
|
||||
cmake new option: NEW_GTPU to use the new implementation (it changes for the entire executable)
|
||||
It is possible to use both old and new GTP in same executable because the itti task and all functions names are different
|
||||
Current status of new implementation: not tested, X2 not developped, 5G new GTP option not developped, remain issues on data coming from void: muid, enb_flag, ...
|
||||
|
||||
ocp_gtpv1uTask(): this creates only the thread, doesn't configure anything
|
||||
gtpv1Init(): creates a listening socket to Linux for a given reception and select a local IP address
|
||||
|
||||
newGtpuCreateTunnel() this function will replace the xxx_create_tunnel_xxx() for various cases
|
||||
This creates a outgoing context for a teid (in input), it computes and return the incoming teid that will be used for incoming packets
|
||||
These teids and in a "instance", so in a Linux socket: same teid can co-exist for different sockets
|
||||
Remain here a lack to fill: the information given in the legacy funtions is not enough to fullfil the data needed by the callback
|
||||
stuff like enb_flag, but also mui and more important data are not given explicitly by any legacy function (gtpv1u_create_s1u_tunnel), but the legacy and the new interface to lower layer (like pdcp) require this data.
|
||||
The datamodel is still not fully understood, so this data source remain unknown
|
||||
A new parameter is the callback function: will be pdpcp_data_req() and gtpv_data_req() (x2 case) for existing implementation and later other call backs like the F1-U implementation.
|
||||
## newGtpuCreateTunnel()
|
||||
this function will replace the xxx_create_tunnel_xxx() for various cases
|
||||
The parameters are:
|
||||
1. outgoing TEid, associated with outpoing pair(rnti, id)
|
||||
2. incoming packets callback, incoming pair(rnti,id) and a callback function for incoming data
|
||||
|
||||
incoming packets
|
||||
the gtp layer retrieves the data, the teid, find out the related data: rnti, bearer and quite a lot of other parameters (not clear why, because it looks like all is statefull, so the lower layer should have the context)
|
||||
if lower layers can be stateless, it is a good idea to keep the context in the gtp layer and pass it to the callback, but the design remain obfuscated.
|
||||
## outgoing packets
|
||||
|
||||
Each call to newGtpuCreateTunnel() creates a outgoing context for a teid (given as function input), a pair(rnti,outgoing id).
|
||||
Each outgoing packet received on GTP-U ITTI queue must match one pair(rnti,id), so the gtp-u thread can lookup the related TEid and use it to encode the outpoing GTP-U tunneled packet.
|
||||
|
||||
## incoming packets
|
||||
|
||||
newGtpuCreateTunnel() computes and return the incoming teid that will be used for incoming packets.
|
||||
When a incoming packet arrives on this incoming teid, the GTP-U thread calls the defined callback, with the associated pair(rnti, incoming id).
|
||||
|
||||
stuff like enb_flag, mui and more important data are not given explicitly by any legacy function (gtpv1u_create_s1u_tunnel), but the legacy and the new interface to lower layer (like pdcp) require this data. We hardcode it in first version.
|
||||
|
||||
## remaining work
|
||||
These teids and "instance", so in a Linux socket: same teid can co-exist for different sockets
|
||||
Remain here a lack to fill: the information given in the legacy funtions is not enough to fullfil the data needed by the callback
|
||||
|
||||
Coexistance until full merge with legacy GTP
|
||||
cmake new option: NEW_GTPU to use the new implementation (it changes for the entire executable)
|
||||
It is possible to use both old and new GTP in same executable because the itti task and all functions names are different
|
||||
Current status of new implementation: not tested, X2 not developped, 5G new GTP option not developped, remain issues on data coming from void: muid, enb_flag, ...
|
||||
|
||||
# NGAP
|
||||
NGAP would be a itti thread as is S1AP (+twin thread SCTP that is almost void processing)?
|
||||
|
||||
@@ -95,7 +95,7 @@ To get the code and build the gNB executable:
|
||||
./build_oai --gNB -w USRP
|
||||
```
|
||||
|
||||
A reference configuration file for the gNB is provided [here](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf).
|
||||
A reference configuration file for the **monolithic** gNB is provided [here](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/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.
|
||||
@@ -194,6 +194,8 @@ The SA setup with OAI UE has been validated with **RFSIMULATOR**. Both control p
|
||||
|
||||
In the following, we provide the instructions on how to build, configure and execute this SA setup.
|
||||
|
||||
As another option, if you do not want to build anything and instead deploy the OAI RAN (RFSIMULATOR) and Core Network components directly using docker images and docker-compose, please have a look at [this tutorial](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/ci-scripts/yaml_files/5g_rfsimulator/README.md).
|
||||
|
||||
### NAS configuration for the OAI UE
|
||||
The NAS configuration parameters of the OAI UE can be set as input parameters, configuration file or can be hardcoded. More specifically:
|
||||
- SUCI (*Subscription Concealed Identifier*)
|
||||
@@ -245,7 +247,6 @@ The gNB configuration can be performed according to what is described in [sectio
|
||||
## 2.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).
|
||||
|
||||
In addition, if you do not want to build anything, please have a look at [this tutorial](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/ci-scripts/yaml_files/5g_rfsimulator/README.md).
|
||||
|
||||
## 2.3 Execution of SA scenario
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 275 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 102 KiB |
@@ -0,0 +1,49 @@
|
||||
There are fundamental changes to the L2 emulation mechanism; these changes allow the
|
||||
user to run multiple UEs in separate Linux processes/machines/VMs/etc. They use a separate
|
||||
entity between the UE(s) and eNB. The UEs use nFAPI to communicate with the eNB. The
|
||||
nFAPI interface allows us to run in an emulated layer 2 mode, meaning that we are bypassing
|
||||
the layer 1 (PHY) functionality. Because we are bypassing the PHY layer,
|
||||
channel modeling capabilties have been added in the LTE UE phy_stub_ue.c file. To understand
|
||||
the interfaces between the different components associated with LTE mode, the image
|
||||
functional_diagram_proxy_lte.png has been provided.
|
||||
|
||||
This functionality allows the user to plug in their own channel model and emulate the packet dropping procedure
|
||||
in real time. The channel modeling has not been provided by EpiSci, but the OAI code
|
||||
base already has some BLER curves available for use. The channel modeling functionality
|
||||
that is included in the phy_stub_ue.c file only includes the downlink channel modeling.
|
||||
Any uplink channel modeling must be conducted in some sort of proxy, which would sit
|
||||
between the UEs and eNB. (A description of the downlink channel modeling is shown in the
|
||||
Channel_Abstraction_UE_Handling_LTE.PNG image).
|
||||
|
||||
The updates to the OAI code base removed some latent bugs, added multi-UE scalability,
|
||||
and were tested with a standard bypass proxy between the UE(s) and eNB. The bypass proxy is
|
||||
publicly available on GitHub (https://github.com/EpiSci/oai-lte-multi-ue-proxy). With this package,
|
||||
various multi-UE scenarios can be tested without the overhead of PHY-layer features
|
||||
of underlying radios. The features added in the L2 Emulator Mode for LTE are:
|
||||
|
||||
- Ease of use of gprof and address sanitizer for debugging purposes
|
||||
- Updated json files to allow for GDB, real-time debugging capabilities
|
||||
- Updated logging features to minimally log only key connection milestones. This improves scalability of multiple UEs.
|
||||
The logging mechanism described here is located in the log.c and log.h files. The LOG_MINIMAL
|
||||
function allows us to remove most OAI logging and includes LOG_A(...) logs and above. The LOG_A
|
||||
logs were chosen as analysis logs to meet EpiSci's internal testing procedure. The LOG_As
|
||||
only include logs that are considered to be milestones in a given test. For example, a
|
||||
log indicating that the RACH procedure has been completed for LTE. To select full logging,
|
||||
set LOG_MINIMAL = 0 in the log.h file.
|
||||
- Updated logging to include time stamp for timing analysis
|
||||
- Updated memory allocation procedures to correct size requirements
|
||||
- Added debugging features to handle signal terminations
|
||||
- nfapi.c pullarray8 fix invalid pointer math
|
||||
- Overlapping destination and source memory in memcpy, so updated to memmove to check for this bug
|
||||
- Advanced error checking mechanisms in critical pack and unpack functions
|
||||
- Created option for CPU assignment to UE to improve scalability
|
||||
- Added EPC integration to allow multiple individual UE entities to each have their USIM information parsed by the executables
|
||||
- Updated random value seeds to minimize probability of error in generation of random values
|
||||
- Enables capability round robin scheduler if desired
|
||||
- Enables capability real time scheduler if desired
|
||||
- Added new standalone functions to the UE phy-layer (phy_stub_ue.c) to incorporate individual UE entities
|
||||
- Updated sending and packing functions in UE (lte_ue.c) to incorporate new standalone changes
|
||||
- Incorporated semaphores to control timing of incoming downlink packets
|
||||
- Implemented new queuing system to handle message exchange from UE to eNB and vice versa
|
||||
- Updated global value in nFAPI for size of subframe
|
||||
- Updated global value to increase scalability in system
|
||||
@@ -0,0 +1,94 @@
|
||||
There are fundamental changes to the L2 emulation mechanism; these changes allow the
|
||||
user to run multiple UEs in separate Linux processes/machines/VMs/etc. They use a separate
|
||||
entity between the UE(s) and eNB/gNB. The UEs use nFAPI to communicate with the eNB/gNB. The
|
||||
nFAPI interface allows us to run in an emulated L2 mode, meaning that we are bypassing
|
||||
the layer 1 (PHY) layer functionality. Becasue we are bypassing the PHY layer, special
|
||||
channel modeling capabilty has been added in the LTE UE phy_stub_ue.c file. To understand
|
||||
the interfaces between the different components associated with NSA mode, the image
|
||||
functional_diagram_proxy_nsa.png has been provided.
|
||||
|
||||
This functionality allows the user to plug in their own channel model and emulate the packet dropping procedure
|
||||
in real time. The channel modeling has not been provided by EpiSci, but the OAI code
|
||||
base already has some BLER curves available for use. The chanel modeling functionality
|
||||
that is included in the phy_stub_ue.c file only includes the downlink channel modeling.
|
||||
Any uplink channel modeling must be conducted in some sort of proxy, which would sit
|
||||
between the UEs and eNB/gNB. (A description of the downlink channel modeling is shown in the
|
||||
Channel_Abstraction_UE_Handling_LTE.PNG image).
|
||||
|
||||
The updates to the OAI code base removed some latent bugs, added multi-UE scalability,
|
||||
and were tested with a standard bypass proxy between the UE(s) and eNB/gNB. The bypass proxy is
|
||||
publicly available on GitHub (https://github.com/EpiSci/oai-lte-multi-ue-proxy). With this package,
|
||||
various multi-UE scenarios can be tested without the overhead of PHY-layer features
|
||||
of underlying radios. The added features to the OAI code base are listed below.
|
||||
|
||||
- Ease of use of gprof and address sanitizer for debugging purposes
|
||||
- Updated json files to allow for GDB, real-time debugging capabilities
|
||||
- Updated logging features to minimally log only key connection milestones. This improves scalability of multiple UEs.
|
||||
The logging mechanism described here is located in the log.c and log.h files. The LOG_MINIMAL
|
||||
function allows us to remove most logs and include LOG_A(...) logs and above. The LOG_A
|
||||
logs were chosen as analysis logs to meet EpiSci's internal testing procedure. The LOG_As
|
||||
only include logs that are considered to be milestones in a given test. For example, a
|
||||
log indicating that the CFRA procedure has been completed for NSA mode. To revert to full logging,
|
||||
set LOG_MINIMAL = 0 in the log.h file.
|
||||
- Updated logging to include time stamp for timing analysis
|
||||
- Updated memory allocation procedures to correct size requirements
|
||||
- Added debugging features to handle signal terminations
|
||||
- nfapi.c pullarray8 fix invalid pointer math
|
||||
- Overlapping destination and source memory in memcpy, so updated to memmove to check for this bug
|
||||
- Advanced error checking mechanisms in critical pack and unpack functions
|
||||
- Created option for CPU assignment to UE to improve scalability
|
||||
- Added EPC integration to allow multiple individual UE entities to each have their USIM information parsed by the executables
|
||||
- Updated random value seeds to minimize probability of error in generation of random values
|
||||
- Enables capability round robin scheduler if desired
|
||||
- Enables capability real time scheduler if desired
|
||||
- Added new standalone functions to the UE phy-layer (phy_stub_ue.c) to incorporate individual UE entities
|
||||
- Updated sending and packing functions in UE (lte_ue.c) to incorporate new standalone changes
|
||||
- Incorporated semaphores to control timing of incoming downlink packets
|
||||
- Implemented new queuing system to handle message exchange from UE to eNB and vice versa
|
||||
- Updated global value in nFAPI for size of subframe
|
||||
- Updated global value to increase scalability in system
|
||||
|
||||
|
||||
Additionally, NSA mode includes the establishment between an NR UE and the gNB via the LTE UE and eNB
|
||||
connection. For NSA mode, the downlink channel abstraction has not been added to the feature set yet.
|
||||
NSA mode has been tested and is fully functional with EpiSci's public version of the nFAPI proxy
|
||||
located at https://github.com/EpiSci/oai-lte-multi-ue-proxy
|
||||
NSA mode establishment includes the following steps:
|
||||
|
||||
- First UE capability enquiry is sent to NR UE
|
||||
- NR UE updates and fills first capability enquiry
|
||||
- eNB request for a measurement report
|
||||
- Measurement request is sent to NR UE
|
||||
- Measurement report is filled in NR UE
|
||||
- Measurement report is received in eNB
|
||||
- Request for second UE capability enquiry
|
||||
- Send second enquiry to NR UE
|
||||
- Second capability information is filled by NR UE
|
||||
- Second capability information is sent to eNB
|
||||
- NR UE capability information is received in gNB
|
||||
- Periodic measurement report received in gNB
|
||||
- RRCReconfigurationRequest is sent to NR UE
|
||||
- RRCReconfigurationComplete is sent from NR UE
|
||||
- RACH is received in the gNB
|
||||
- RAR is received in NR UE
|
||||
- Msg 3 is generated and sent to gNB
|
||||
- CFRA procedure is complete
|
||||
|
||||
Please note, the current status is:
|
||||
- A single NSA UE is able to ping an external source
|
||||
- Up to 4 NSA UEs can complete the CFRA procedure with a single gNB
|
||||
- UE-to-UE traffic is still in work (incomplete due to gNB crashing)
|
||||
- The gNB is crashing regularly and is still in work
|
||||
|
||||
Test Setup:
|
||||
For launching the multi-UE for NSA mode, there is a provided test script in the
|
||||
public EpiSci GitHub multi-ue-proxy repository. However, a brief outline of the
|
||||
test set up is included below.
|
||||
|
||||
If running multiple NSA UEs in a single machine, you will need to launch
|
||||
multiple LTE and NR UE processes. For example, to launch a 2 NSA UE scenario
|
||||
there will be a total of 7 processes running for this particular scenario.
|
||||
These processes are LTE UE #1, LTE UE #2, NR UE #1, NR UE #2, eNB, gNB and the
|
||||
proxy. A detailed description of the launch processes can be found at
|
||||
https://github.com/EpiSci/oai-lte-multi-ue-proxy/blob/master/README.md
|
||||
|
||||
Reference in New Issue
Block a user