Skip to content

O
OpenXG UE
Commit a687e811 authored by Luhan Wang's avatar Luhan Wang
Browse files
Options

rm unnecessary files

parent c50101f3
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 0 additions and 45609 deletions
doc/5Gnas.md deleted 100644 → 0
View file @ c50101f3
<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
RRC/NR/nr_ngap_gNB.c: skeleton for interface with NGAP
NAS/COMMON/milenage.h: a simple milenage implementation, depend only on crypto library
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
NAS/COMMON/nr_common.c: 5G NAS common code between gNB and UE
UICC/usim_interface.c: UICC simulation for USIM messages
NAS/NR_UE/ue_process_nas.c: NAS code for UE
NAS/gNB/network_process_nas.c: NAS code for gNB running without 5GC
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>
doc/BASIC_SIM.md deleted 100644 → 0
View file @ c50101f3
<table style="border-collapse: collapse; border: none;">
<tr style="border-collapse: collapse; border: none;">
<td style="border-collapse: collapse; border: none;">
<a href="http://www.openairinterface.org/">
<img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
</img>
</a>
</td>
<td style="border-collapse: collapse; border: none; vertical-align: center;">
<b><font size = "5">Running OAI Basic Simulator</font></b>
</td>
</tr>
</table>
This page is valid on the following branches:
- `master` starting from tag `v1.1.0`
- `develop` starting from tag `2019.w11`
# 1. Building the basic-simulator.
After the build simplification, the basic simulator is available directly from the standard build.
```bash
$ source oaienv
$ cd cmake_targets
$ ./build_oai --eNB --UE
```
Both eNB (lte-softmodem) and UE (lte-uesoftmodem) are present on `cmake_targets/ran_build/build` folder.
More details are available on the [build page](BUILD.md).
# 2. Running the basic simulator.
The basic simulator is a oai device replacing the radio heads (for example the USRP device). It allows connecting the oai UE and the oai eNodeB through a network interface carrying the time-domain samples, getting rid of over the air unpredictable perturbations.
This is the ideal tool to check signal processing algorithms and protocols implementation and having debug sessions without any HW radio equipment.
The main limitations are:
- A single OAI UE will connect to the OAI eNB
- No channel noise
## 2.1. Starting eNB
The basic simulator is able to run with a connected EPC or without any (the so-called "noS1" mode).
Example 1: running in FDD mode with EPC.
```bash
$ source oaienv
$ cd cmake_targets/ran_build/build
$ ENODEB=1 sudo -E ./lte-softmodem -O $OPENAIR_HOME/ci-scripts/conf_files/lte-fdd-basic-sim.conf --basicsim
```
Edit previously the `ci-scripts/conf_files/lte-fdd-basic-sim.conf` file to modify:
- `N_RB_DL` field to change the Bandwidth (25, 50, 100)
- `CI_MME_IP_ADDR` with the EPC IP address
- `CI_ENB_IP_ADDR` with the container (physical server, virtual machine, ...) on which you are executing the eNB soft-modem
Example 2: running in TDD mode without any EPC.
```bash
$ source oaienv
$ cd cmake_targets/ran_build/build
$ ENODEB=1 sudo -E ./lte-softmodem -O $OPENAIR_HOME/ci-scripts/conf_files/lte-tdd-basic-sim.conf --basicsim --noS1
```
## 2.2. Starting UE
Before starting the UE, you may need to edit the SIM parameters to adapt to your eNB configuration and HSS database.
The <conf> file to use for conf2uedate is `NAS/TOOLS/ue_eurecom_test_sfr.conf`
You need to set the correct OPC, USIM_API_K, MSIN (this is the end par of the IMSI), HPLMN (the front part of IMSI) to match values from HSS.
```bash
$ source oaienv
# Edit NAS/TOOLS/ue_eurecom_test_sfr.conf
$ cd cmake_targets/ran_build/build
$ ../../nas_sim_tools/build/conf2uedata -c $OPENAIR_HOME/NAS/TOOLS/ue_eurecom_test_sfr.conf -o .
$ sudo -E ./lte-uesoftmodem -C 2625000000 -r 25 --ue-rxgain 140 --basicsim [--noS1]
```
The `-r 25` is to use if in the conf file of the eNB you use N_RB_DL=25. Use 50 if you have N_RB_DL=50 and 100 if you have N_RB_DL=100.
The `-C 2625000000` is the downlink frequency. Use the same value as `downlink_frequency` in the eNB configuration file.
The `--noS1` is mandatory if you started the eNB in that mode.
# 3. Testing the data plane
# 3.1. In S1 mode
First we need to retrieve the IP address allocated to the OAI UE.
On the server that runs the UE:
```bash
$ ifconfig oaitun_ue1
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.172.0.2 P-t-P:192.172.0.2 Mask:255.255.255.0
...
```
`192.172.0.2` is the IP address that has been allocated by the SPGW in the EPC.
On the server that runs the EPC:
```bash
$ ping -c 20 192.172.0.2
--- 192.172.0.2 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19020ms
rtt min/avg/max/mdev = 13.241/18.999/24.208/2.840 ms
```
You can ping the EPC from the UE:
```bash
$ ping -I oaitun_ue1 -c 20 192.172.0.1
--- 192.172.0.1 ping statistics ---
...
20 packets transmitted, 20 received, 0% packet loss, time 19019ms
rtt min/avg/max/mdev = 13.015/18.674/23.738/2.917 ms
```
For DL iperf testing:
On the server that runs the UE.
```bash
$ iperf -B 192.172.0.2 -u -s -i 1 -fm -p 5001
```
On the server that runs the EPC.
```bash
$ iperf -c 192.172.0.2 -u -t 30 -b 10M -i 1 -fm -B 192.172.0.1 -p 5001
```
For UL iperf testing:
On the server that runs the EPC.
```bash
$ iperf -B 192.172.0.1 -u -s -i 1 -fm -p 5001
```
On the server that runs the UE.
```bash
$ iperf -c 192.172.0.1 -u -t 30 -b 2M -i 1 -fm -B 192.172.0.2 -p 5001
```
# 3.2. In noS1 mode
The IP addresses are fixed. But we can still retrieve them programmatically.
For the UE it is quite the same:
```bash
$ ifconfig oaitun_ue1
oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.2 P-t-P:10.0.1.2 Mask:255.255.255.0
...
```
For the eNB:
```bash
$ ifconfig oaitun_enb1
oaitun_enb1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.1.1 P-t-P:10.0.1.1 Mask:255.255.255.0
...
```
Pinging like this:
```bash
$ ping -I oaitun_ue1 -c 20 10.0.1.1
$ ping -I oaitun_enb1 -c 20 10.0.1.2
```
And the same for iperf:
```bash
$ iperf -B 10.0.1.2 -u -s -i 1 -fm
$ iperf -c 10.0.1.2 -u -b 1.00M -t 30 -i 1 -fm -B 10.0.1.1
```
doc/BUILD.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/F1-design.md deleted 100644 → 0
View file @ c50101f3
<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.
doc/FEATURE_SET.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/GET_SOURCES.md deleted 100644 → 0
View file @ c50101f3
<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">The OpenAirInterface repository: the sources</font></b>
</td>
</tr>
</table>
The OpenAirInterface software can be obtained from our gitLab
server. You will need a git client to get the sources. The repository
is currently used for main developments.
# Prerequisites
You need to install the subversion/git using the following commands:
```shell
sudo apt-get update
sudo apt-get install subversion git
```
# Using EURECOM Gitlab
The [openairinterface5g repository](https://gitlab.eurecom.fr/oai/openairinterface5g.git)
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 more recent version is available under our GitHub domain:
* [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):
```shell
git config --global user.name "Your Name"
git config --global user.email "Your email address"
```
- Add a certificate from gitlab.eurecom.fr to your Ubuntu 14.04 installation:
```shell
echo -n | openssl s_client -showcerts -connect gitlab.eurecom.fr:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt
```
- Disable certificate check completely if you do not have root access to /etc/ssl directory
```shell
git config --global http.sslverify false
```
## In order to clone the Git repository (for OAI Users without login to gitlab server)
Cloning RAN repository (eNB RAN + UE RAN):
```shell
git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
```
## In order to contribute to the Git RAN repository (for OAI Developers/admins with login to gitlab server)
Please send email to [contact@openairinterface.org](mailto:contact@openairinterface.org) to be added to the repository
as a developer (only important for users who want to commit code to the repository). If
you do not have account on gitlab.eurecom.fr, please register yourself to gitlab.eurecom.fr and provide the identifiant in the email.
* Clone with using ssh keys:
* You will need to put your ssh keys in https://gitlab.eurecom.fr/profile/keys
to access to the git repo. Once that is done, clone the git repository using:
* `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`
# Which branch to checkout?
On the RAN side:
* **master**: This branch is targeted for the user community. Since January 2019, it is also subject to a Continuous Integration process. The update frequency is about once every 2-3 months. We are also performing bug fixes on this branch.
* **develop**: This branch contains recent commits that are tested on our CI test bench. The update frequency is about once a week.
Please see the work flow and policies page :
https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/oai-policies-home
you can find the latest stable tag release here :
https://gitlab.eurecom.fr/oai/openairinterface5g/tags
The tag naming conventions are :
- On `master` branch: **v1.`x`.`y`** where
* `x` is the minor release number, incremented every 2-3 months when we are merging `develop` into `master` branch.
* `y` is the maintenance number, starting at 0 when we do a minor release and being incremented when a bug fix is incorporated into `master` branch.
- On `develop` branch **`yyyy`.w`xx`**
* `yyyy` is the calendar year
* `xx` the week number within the year
doc/ITTISIM.md deleted 100755 → 0
View file @ c50101f3
<table style="border-collapse: collapse; border: none;">
<tr style="border-collapse: collapse; border: none;">
<td style="border-collapse: collapse; border: none;">
<a href="http://www.openairinterface.org/">
<img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
</img>
</a>
</td>
<td style="border-collapse: collapse; border: none; vertical-align: center;">
<b><font size = "5">Running L3 ITTI simulator</font></b>
</td>
</tr>
</table>
This page is valid on the following branches:
- `develop` starting from tag `2020.w48`
# 1. Building the ITTI simulator.
The ITTI simulator is available directly from the standard build.
```bash
$ source oaienv
$ cd cmake_targets
$ sudo ./build_oai -x -w None -c -ittiSIM
```
# 2. Running the ITTI simulator.
The ITTI simulator establishes ITTI-threaded communication between the gNB RRC task and the UE RRC task.
This allows to test the sequence of NGAP/RRC/NAS messages.
The main limitations are:
- NAS is a simple stub that just sends and receives messages
- only initial Attach sequence
## 2.1. Starting the ITTI simulator
The ITTI simulator is able to run with a connected 5GC or without any.
The develop branch tag `2020.w48` only works RRC without 5GC connection.
```bash
$ sudo -E ./ran_build/build/nr-ittisim -O gnb.conf
```
doc/L1SIM.md deleted 100644 → 0
View file @ c50101f3
<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">Open Air LTE Emulation</font></b>
</td>
</tr>
</table>
This page is valid for the develop branch
# Table of Contents: #
* [How to build the eNB and the UE](#build)
* [How to run an eNB built with the noS1 option](#run-noS1-eNB)
* [How to run a UE built with the noS1 option](#run-noS1-UE)
* [Continuous Integration notes](#CInote)
* [How to ping an eNB from a UE and vice versa (with the noS1 option)](#noS1-pinging)
The old oaisim is dead! Long live oaisim! :)
If you are looking for a description of the old oaisim (which is still available in some branches/tags), please see [here](OpenAirLTEEmulation) and [here](how-to-run-oaisim-with-multiple-ue).
oaisim has been scraped and replaced by the same programs that are used for the real-time operation, `lte-softmodem` and `lte-uesoftmodem`. The latter also now includes an optional channel model, just like oaisim did.
# <a name="build">[How to build the eNB and the UE](BUILD.md)</a>
The following paragraph explains how to run the L1 simulator in noS1 mode and using the oai kernel modules.
# <a name="run-noS1-eNB">How to run an eNB with the noS1 option</a>
Modify the configuration file for IF4p5 fronthaul, `/openairinterface5g/ci-scripts/conf_files/rcc.band7.nos1.simulator.conf`, and replace the loopback interface with a physical ethernet interface and the IP addresses to work on your network. Copy your modifications to a new file, let's call YYY.conf the resulting configuration file.
Run lte-softmodem as usual with this configuration.
```bash
$ source oaienv
$ cd cmake_targets/tools
$ sudo -E ./init_nas_nos1 eNB
$ cd ../ran_build/build
$ sudo -E ./lte-softmodem -O YYY.conf --noS1 --nokrnmod 0
```
# <a name="run-noS1-UE">How to run a UE with the noS1 option</a>
Similarly modify the example configuration file in `/openairinterface5g/ci-scripts/conf_files/rru.band7.nos1.simulator.conf` and replace loopback interface and IP addresses. Copy your modifications to a new file, let's call XXX.conf the resulting configuration file.
Run it like:
```bash
$ source oaienv
$ cd cmake_targets/tools
$ sudo -E ./init_nas_nos1 UE
$ cd ../ran_build/build
$ sudo ./lte-uesoftmodem -O XXX.conf -r 25 --siml1 --noS1 --nokrnmod 0
```
That should give you equivalent functionality to what you had with oaisim including noise and RF channel emulation (path loss / fading, etc.). You should also be able to run multiple UEs.
# <a name="CInote">Continuous Integration notes</a>
The CI currently tests the noS1 build option with one eNB and one UE in the following scenarios:
* pinging one UE from one eNB
* pinging one eNB from one UE
* iperf download between one eNB and one UE
* iperf upload between one eNB and one UE
* all the above tests are done in FDD 5Mhz mode.
# <a name="noS1-pinging">How to ping an eNB from a UE and vice versa (with the noS1 option)</a>
Once your eNB and UE (built with the noS1 option) are running and synchronised, you can ping the eNB from the UE with the following command:
```bash
ping -I oai0 -c 20 $eNB_ip_addr
```
where $eNB_ip_addr is the IP address of your eNB.
Similarly, you can ping the UE from the eNB.
The IP adresses of the eNB and the UE are set up by the init_nas_nos1 program and should have the following values:
* eNB_ip_addr set to 20 10.0.1.1
* ue_ip_addr set to 20 10.0.1.2
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
doc/L2NFAPI.md deleted 100644 → 0
View file @ c50101f3
<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 Usage</font></b>
</td>
</tr>
</table>
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.**
**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
Currently the Continuous Integration process is validating this simulator the following way:
* the LTE modem executable is run on one host (in our CI deployment it is a **Xenial Virtual Machine**)
* 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)
**2022/03/08: Starting the `2022.w01` tag on the `develop` branch, the L2 nFAPI simulation is using a proxy.**
A tutorial is available on the [EpiSci GitHub Repository](https://github.com/EpiSci/oai-lte-5g-multi-ue-proxy#readme).
This proxy allows to perform L2 nFAPI simulator for:
* LTE
* 5G-NSA
* 5G-SA
----
[oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
[oai softmodem features](FEATURE_SET.md)
[oai softmodem build procedure](BUILD.md)
doc/L2NFAPI_NOS1.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/L2NFAPI_S1.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/NR_NFAPI_archi.md deleted 100644 → 0
View file @ c50101f3
# global
xnf is pnf or vnf
The xnf starting functions are configure_nfapi_xnf()
The OAI code that read the configuration parameters call these functions that will create autonomous thread for xnf control part
These control threads create a SCTP socket by Linux API call (no use of OpenAir internal architecture with SCTP itti thread).
The main() function of softmodem has to create and start the other threads+loop on event for appropriate work: RF Rx in pnf, NGAP, GTP-U, X2, RLC, PDCP for vnf
NFAPI has it's own code directly on Linux+Posix, it doesn't reuse any piece of the OpenAir framework: SCTP thread, thread creation and management, ...
## signaling (P5) xnf main loop
nfapi_vnf_start() create the SCTP socket, then do event waiting in a infinite loop while(vnf->terminate == 0). It accepts the pnf connections, then process the messages on reception
nfapi_pnf_start() initiate connection to vnf until it has a link. Then it enter a similar infinite loop in pnf_message_pump()
After some checks, when a message is obtained, it calls pnf_handle_p5_message() or vnf_handle_p4_p5_message() that have a switch on each p5 message types: the enum nfapi_message_id_e
Each message type has it's own processing function in the switch, like
```
case NFAPI_START_RESPONSE:
vnf_handle_start_response(pRecvMsg, recvMsgLen, config, p5_idx);
break;
```
These loops are autonomous in their thread waiting incoming message.
## P7 xnf main loop
When the p5 interface receives appropriate message, it starts the p7 interface by launching a thread (see the calls to pthread_create() in nfapi/oai_integration/nfapi_xnf.c)
The p7 main loops starting is a bit simpler, thanks to UDP non connected protocol. The xnf_dispatch_p7_message() do p7 fragments re-assembly, then
calls xnf_dispatch_p7_message() that have the big switch on message type (as in p5 above description)
So, we have the logic for UL reception in vnf, and DL reception in pnf
## P7 UL transmission by PNF
RF samples are received, and decoding is done by the PNF using control data transmitted by the VNF to the PNF through downlink p7 messages (UL_TTI_req and UL_DCI_req).
After decoding, results are accumulated into the xNB->UL_INFO structure at the PNF.
The data in the UL_INFO struct is transmitted through a socket in the form of 'uplink indication functions' from the PNF to the VNF. Each uplink indication message is transmitted from their respective handle functions in NR_UL_indication(). For example,
```
void handle_nr_rach(NR_UL_IND_t *UL_info) {
if(NFAPI_MODE == NFAPI_MODE_PNF) {
if (UL_info->rach_ind.number_of_pdus>0) {
oai_nfapi_nr_rach_indication(&UL_info->rach_ind); //This function calls the routines required for packing + transmission through socket
UL_info->rach_ind.number_of_pdus = 0;
}
}
```
## P7 UL reception at VNF
Through the infinite loop [while(vnf_p7->terminate == 0)] running in nfapi_nr_vnf_p7_start(), the VNF receives and unpacks the uplink indication message received on its socket. Based on the unpacked messages, UL_INFO struct on the VNF side gets populated.
```
// have a p7 message
if(FD_ISSET(vnf_p7->socket, &rfds))
{
vnf_nr_p7_read_dispatch_message(vnf_p7);
}
```
vnf_nr_dispatch_p7_message() is the function that contains the switch on various message headers so that the appropriate unpack function is called.
## P7 DL Transmission by VNF
DL messages are scheduled at the VNF, through NR_UL_indication(). NR_UL_indication() is called when the SFN/slot in the UL_info structure changes (this acts as a trigger for next slot processing, instead of running a separate clock at the VNF). The SFN/slot at the VNF in UL_info is updated using the slot_indication uplink p7 message, which is sent at the beginning of every slot by the PNF. The slot_indication message contains SFN/slot of the TX_thread, so that the scheduler operates slot_ahead slots ahead of the RX thread. This ensures that UL_tti_req is received before RX slot processing at the PNF.
The function NR_schedule_response calls oai_nfapi_[DL P7 msg]_req(), which contains the routines for packing + transmission of scheduled messages through the socket to the PNF. For example, to send the 'TX_data_req' p7 message
```
if (Sched_INFO->TX_req->Number_of_PDUs > 0)
{
oai_nfapi_tx_data_req(Sched_INFO->TX_req);
}
```
```mermaid
graph TD
pselect[VNF socket pselect] -- timed out : end of slot --> call_sched[Call Scheduler NR_UL_indication] -- oai_nfapi_***_req sends the DL p7 msg--> slot_inc[Increment sfn/slot];
pselect[VNF socket pselect] -- UL p7 xyz msg recvd --> msg_recvd[Read message vnf_nr_p7_read_dispatch_message] --> header_unpack[Unpack Header] -- switch cases on header --> unpack_msg[Handle Message vnf_handle_nr_xyz] --> fill_ul_info[Fill UL info struct with fn pointer vnf_p7->_public.nr_rx_xyz];
fill_ul_info -- update pselect_timeout: next_slot_start - time_xyz_msg_recvd-->pselect;
slot_inc -- next slot --> pselect
```
Note that since DL P7 message reception and TX/RX processing are done on separate threads, there is the issue of the L1 processing threads trying to do their job before the required P7 message is received. In the case of RX processing, since the scheduler operates slot_ahead slots ahead of the RX thread, the required messages conveniently arrive earlier than they are required. However, in the case of TX processing, this cannot be ensured if the scheduler is exactly in sync with the TX thread.
Therefore, we operate the VNF vnf_slot_ahead (which is currently 2) slots ahead of the PNF. This is to ensure that the DL fapi structures for a particular TX slot are all received before TX processing for that slot.
## P7 DL Reception at PNF
Through the infinite loop [while(pnf_p7->terminate == 0)] running in pnf_nr_p7_message_pump(), the PNF receives and unpacks the downlink P7 message received on its socket. Based on the unpacked message, the appropriate message structures are filled in the PNF, and these are used further down the pipeline for processing.
While receiving the DL P7 message, we check whether the message was received within a timing window from which it was sent. The duration of the window can be set by the user (set as a parameter for xnf in the p5 messages). Note that the DL information must be received by the PNF within a timing window at least lesser than the duration of slot_ahead variable (timing_window <= slot_ahead * slot_duration).
```mermaid
graph TB
pselect[PNF socket pselect] -- timed out : end of slot --> slot_inc[Increment sfn/slot];
pselect[PNF socket pselect] -- DL p7 xyz msg recvd --> msg_recvd[Read message pnf_nr_nfapi_p7_read_dispatch_message] --> header_unpack[Unpack Header] -- switch cases on header --> unpack_msg[Unpack Message pnf_handle_nr_xyz] --> fill_pnf_p7[Fill pnf_p7 global structure pnf_handle_nr_xyz] --Data from pnf_p7 struct copied to fapi structures using pnf_phy_***_req. Called every slot from handle_nr_slot_ind-->pselect;
slot_inc -- next slot --> pselect
```
Once the messages are received, they are filled into slot buffers, and are stored until the processing of the slot that they were meant for.
doc/RUNMODEM.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/RUN_NR_NFAPI.md deleted 100644 → 0
View file @ c50101f3
# Procedure to run nFAPI in 5G NR
## Contributed by 5G Testbed IISc
### Developers: Gokul S, Mahesh A, Aniq U R
## Procedure to Build gNB and UE
The regular commands to build gNB and UE can be used
```
sudo ./build_oai --gNB --nrUE
```
## Procedure to run NR nFAPI using RF-Simulator
### Bring up another loopback interface
If running for the first time on your computer, or you have restarted your computer, bring up another loopback interface with this command:
sudo ifconfig lo: 127.0.0.2 netmask 255.0.0.0 up
### VNF command
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/rcc.band78.tm1.106PRB.nfapi.conf --nfapi 2 --noS1 --phy-test
```
### PNF command
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/oaiL1.nfapi.usrpx300.conf --nfapi 1 --rfsim --phy-test --rfsimulator.serveraddr server
```
### UE command
```
sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem --rfsim --phy-test --rrc_config_path . -d
```
## Procedure to run NR nFAPI using Hardware (tested with USRP x310)
### VNF command
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/rcc.band78.tm1.106PRB.nfapi.conf --nfapi 2 --noS1 --phy-test
```
### PNF command
```
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/oaiL1.nfapi.usrpx300.conf --nfapi 1 --phy-test
```
### UE command
```
sudo ./nr-uesoftmodem --usrp-args "addr=*USRP_ADDRESS*,clock_source=external,time_source=external" --phy-test --rrc_config_path ../../../ci-scripts/rrc-files
```
doc/SW-archi-graph.md deleted 100644 → 0
View file @ c50101f3
```mermaid
flowchart TB
A[ru_thread] --> RFin>block rx_rf] --> feprx
feprx --> half-slot --> end_feprx
feprx --> second-thread -- block_end_feprx --> end_feprx>feprx]
end_feprx --> rx_nr_prach_ru
rx_nr_prach_ru -- block_queue_singleton --> resp_L1>resp L1]
resp_L1 -- async launch --> rx_func
resp_L1 -- immediate return --> RFin
subgraph rxfunc
rx_func_implem[rx_func]
subgraph rxfuncbeg
handle_nr_slot_ind
--> rnti_to_remove-mgmt
--> L1_nr_prach_procedures
--> apply_nr_rotation_ul
end
subgraph phy_procedures_gNB_uespec_RX
fill_ul_rb_mask
--> pucch(decode each gNB->pucch)
-->nr_fill_ul_indication
--> nr_ulsch_procedures
--> nr_ulsch_decoding
--> segInParallel[[all segments decode in parallel]]
--> barrier_end_of_ulsch_decoding
end
subgraph NR_UL_indication
handle_nr_rach
--> handle_nr_uci
--> handle_nr_ulsch
subgraph gNB_dlsch_ulsch_scheduler
run_pdcp
--> nr_rrc_trigger
--> schedule_xxxx
end
handle_nr_ulsch --> gNB_dlsch_ulsch_scheduler
subgraph NR_Schedule_response
L1_tx_free3>L1_tx_free]
--> handle_nr_nfapi_xxx_pdu
--> sendTxFilled((L1_tx_filled))
--> nr_fill_ul_xxx
--> nr_fill_prach
end
gNB_dlsch_ulsch_scheduler --> NR_Schedule_response
end
rx_func_implem --> rxfuncbeg
rxfuncbeg --> phy_procedures_gNB_uespec_RX
phy_procedures_gNB_uespec_RX --> NR_UL_indication
-- block_queue_block_PNF_monolithic --> L1_tx_free2>L1 tx filled]
-- async launch --> tx_func
L1_tx_free2 -- send_msg --> rsp((resp_L1))
end
rx_func --> rxfunc
subgraph tx_func
direction LR
subgraph phy_procedures_gNB_TX
dcitop[nr_generate dci top]
--> nr_generate_csi_rs
--> apply_nr_rotation
-- send_msg --> end_tx_func((L1_tx_out))
end
subgraph tx_reorder_thread
L1_tx_out>L1_tx_out]
--> reorder{re order} --> reorder
reorder --> ru_tx_func
reorder --> L1_tx_free((L1_tx_free))
ru_tx_func --> feptx_prec
--> feptx_ofdm
end
end
```
doc/SW_archi.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/SystemX-tutorial-design.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/TESTBenches.md deleted 100644 → 0
View file @ c50101f3
## 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
![image info](./testbenches_doc_resources/legacy1.jpg)
## Legacy 2 Bench
**Purpose** : TDD Band 40, TM2 2xTX 2xRX
**Note** : CN can run in a container, could also run on Massive
![image info](./testbenches_doc_resources/legacy2.jpg)
## Next Bench for DEV
**Note** : Benetel CI can also run on this bench at night
![image info](./testbenches_doc_resources/next_dev.jpg)
## Next Bench for CI
**Note** : The current test running on Caracal could run on this bench with a N300/N300 setup
![image info](./testbenches_doc_resources/next_ci.jpg)
## Indoor Live Network Bench
![image info](./testbenches_doc_resources/indoor_live.jpg)
## Outdoor Live Network Bench
![image info](./testbenches_doc_resources/outdoor_live.jpg)
doc/TESTING_5GSA_setup.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/TESTING_GNB_W_COTS_UE.md deleted 100644 → 0
View file @ c50101f3
This diff is collapsed.
doc/d2d_emulator_setup.txt deleted 100644 → 0
View file @ c50101f3
Scenario 1 : Off-network UE2UE link
SynchREF UE (UE1)
UE1(eth0 - 10.10.10.1)--------UE2(eno1 - 10.10.10.2)
Here's an example of /etc/network/interfaces configuration for UE1
auto eth0
iface eth0 inet static
address 10.10.10.1
netmask 255.255.255.0
gateway 10.10.10.1
Prepare the environment:
- git clone https://gitlab.eurecom.fr/matzakos/LTE-D2D.git #branch: master
This branch contains all the current development for DDPS
- UE MAC<-> UE MAC for Scenario 1
- eNB MAC<->UE MAC (NFAPI Transport)
- RRC Extensions for “on-network” cases
NFAPI configuration (required even for Scenario 1 target)
- git clone https://github.com/cisco/open-nFAPI.git
- cd open-nfapi
- patch -p1 --dry-run < $OPENAIR_HOME/open-nfapi.oai.patch
Validate that there are no errors
- patch -p1 < $OPENAIR_HOME/open-nfapi.oai.patch
OAI build/execute
- export NFAPI_DIR=XXX (place where NFAPI was installed)
- cd cmake_targets
- ./build_oai --UE
(if necessary, use ./build_oai -I --UE to install required packages)
- cd ran_build/build/
- cp ../../../targets/bin/.ue* .
- cp ../../../targets/bin/.usim* .
- sudo insmod ../../../targets/bin/ue_ip.ko
UE1:
- sudo ifconfig oip0 10.0.0.1
- sudo iptables -A POSTROUTING -t mangle -o oip0 -d 224.0.0.3 -j MARK --set-mark 3
- (if necessary) sudo route add default gw 10.10.10.1 eth0
UE2:
- sudo ifconfig oip0 10.0.0.2
- sudo iptables -A POSTROUTING -t mangle -o oip0 -d 224.0.0.3 -j MARK --set-mark 3
- (if necessary) sudo route add default gw 10.10.10.1 eno1
UE1 and UE2: Get and build vencore_app from d2d-l3-stub (branch: l3_stub)
- gcc -I . vencore_app.c -o vencore_app -lpthread
--------------------------------
TEST ONE-TO-MANY
Run UE1 then UE2, for example:
UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
Test with Ping
- Sender - UE1: ping -I oip0 224.0.0.3
- Receiver - UE2: using wireshark
Test with Iperf
- Sender - UE1: iperf -c 224.0.0.3 -u -b 0.1M --bind 10.0.0.1 -t 100
- Receiver - UE2: sudo ./mcreceive 224.0.0.3 5001
Filter the incomming packets according to GroupL2Id: receiver (one-to-many) can discard the packets if it doesn't belong to this group.
For the moment, both sender and receiver use the same set of Ids (hardcoded)
UE1 (sender)
- sudo ./lte-softmodem-stub -U --emul-iface eth0
- ./vencore_app #send the sourceL2Id, groupL2Id to OAI
- ping -I oip0 224.0.0.3
UE2(receiver)
- sudo ./lte-softmodem-stub -U --emul-iface eno1
#we can see the incomming packets from OAI log, however, cannot see from Wireshark -> they are discarded at MAC layer
- ./vencore_app #we can see the packets appearing in Wireshark
--------------------------------------
TEST PC5-S (UE1 -sender, UE2 - receiver) and PC5-U for ONE-TO-ONE scenario
Configure UE1/UE2
UE1:
- sudo ifconfig oip0 10.0.0.1
- sudo iptables -A POSTROUTING -t mangle -o oip0 -d 10.0.0.2 -j MARK --set-mark 3
- sudo route add default gw 10.10.10.1 eth0
UE2:
- sudo ifconfig oip0 10.0.0.2
- sudo iptables -A POSTROUTING -t mangle -o oip0 -d 10.0.0.1 -j MARK --set-mark 3
- sudo route add default gw 10.10.10.1 eno1
step 1:
- UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
step 2:
- UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
- UE2: ./vencore_app -r #listen to incomming message from PC5-S
step 3:
- UE1: ./vencore_app -s #send a message via PC5-S (e.g., DirectCommunicationRequest)
Generate unicast traffic
UE1: ping -I oip0 10.0.0.2
--------------------------------------
TEST PC5-D
step 1:
- UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
- UE1: ./vencore_app -d #send a PC5-Discovery-Announcement via PC5D
step 2:
- UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
- UE2: ./vencore_app -d #send a PC5-Discovery-Announcement via PC5D
doc/episys/lte_mode_l2_emulator/README.txt deleted 100644 → 0
View file @ c50101f3
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
doc/episys/nsa_mode_l2_emulator/README.txt deleted 100644 → 0
View file @ c50101f3
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
doc/testing_gnb_w_cots_ue_resources/enb.conf deleted 100755 → 0
View file @ c50101f3
This diff is collapsed.
doc/testing_gnb_w_cots_ue_resources/gnb.conf deleted 100755 → 0
View file @ c50101f3
This diff is collapsed.
doc/testing_gnb_w_cots_ue_resources/oai_enb.log deleted 100755 → 0
View file @ c50101f3
This diff is collapsed.
doc/testing_gnb_w_cots_ue_resources/oai_gnb.log deleted 100755 → 0
View file @ c50101f3
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment