Skip to content

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

rm unnecessary files

parent bbee4d98
Pipeline #182 canceled with stages
      Show whitespace changes
      Inline Side-by-side
      Showing with 0 additions and 537515 deletions
      doc/5Gnas.md deleted 100644 → 0
      View file @ bbee4d98
      <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 @ bbee4d98
      <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 @ bbee4d98
      <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">OAI Build Procedures</font></b>
      </td>
      </tr>
      </table>
      This page is valid on tags starting from **`2019.w09`**.
      # Soft Modem Build Script
      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.
      OAI softmodem sources, which aim to implement 3GPP compliant UEs, eNodeB and gNodeB can be downloaded from the Eurecom [gitlab repository](./GET_SOURCES.md).
      Sources come with a build script [build_oai](../cmake_targets/build_oai) located at the root of the `openairinterface5g/cmake_targets` directory. This script is developed to build the oai binaries (executables,shared libraries) for different hardware platforms, and use cases.
      The main oai binaries, which are tested by the Continuous Integration process are:
      - The LTE UE: `lte-uesoftmodem`
      - The 5G UE: `nr-uesoftmodem`
      - The LTE eNodeB: `lte-softmodem`
      - The 5G gNodeB: `nr-softmodem`
      - The LTE PHY simulators: `dlsim` and `ulsim`
      - The 5G PHY simulators: `nr_dlschsim` `nr_dlsim` `nr_pbchsim` `nr_pucchsim` `nr_ulschsim` `nr_ulsim` `polartest` `smallblocktest`
      `ulsim` `ldpctest`
      Running the [build_oai](../cmake_targets/build_oai) script also generates some utilities required to build and/or run the oai softmodem binaries:
      - `conf2uedata`: a binary used to build the UE data from a configuration file. The created file emulates the sim card of a 3GPP compliant phone.
      - `nvram`: a binary used to build UE (IMEI...) and EMM (IMSI, registered PLMN) non volatile data.
      - `rb_tool`: radio bearer utility
      - `genids` T Tracer utility, used at build time to generate T_IDs.h include file. This binary is located in the [T Tracer source file directory](../common/utils/T) .
      The build system for OAI uses [cmake](https://cmake.org/) which is a tool to generate makefiles. The `build_oai` script is a wrapper using cmake, make and standard linux shell commands to ease the oai build and use . The file describing how to build the executables from source files is the [CMakeLists.txt](../cmake_targets/CMakeLists.txt), it is used as input by cmake to generate the makefiles.
      The oai softmodem supports many use cases, and new ones are regularly added. Most of them are accessible using the configuration file or the command line options and continuous effort is done to avoid introducing build options as it makes tests and usage more complicated than run-time options. The following functionalities, originally requiring a specific build are now accessible by configuration or command line options:
      - s1, noS1
      - all simulators as the rfsimulator, the L2 simulator, with exception of PHY simulators, which are distinct executables.
      Calling the `build_oai` script with the -h option gives the list of all available options, but a process to simplify and check the requirements of all these options is on-going. Check the [table](BUILD.md "# `build_oai` options") At the end of this page to know the status of `buid_oai` options which are not described hereafter.
      # Building PHY Simulators
      The PHY layer simulators (LTE and NR) can be built as follows:
      ```
      cd <your oai installation directory>/openairinterface5g/
      source oaienv
      cd cmake_targets/
      ./build_oai -I --phy_simulators
      ```
      After completing the build, the binaries are available in the cmake_targets/ran_build/build directory.
      A copy is also available in the target/bin directory, with all binaries suffixed by the 3GPP release number, today **.Rel15**.
      Detailed information about these simulators can be found [in this dedicated page](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/OpenAirLTEPhySimul)
      # Building UEs, eNodeB and gNodeB Executables
      After downloading the source files, a single build command can be used to get the binaries supporting all the oai softmodem use cases (UE and [eg]NodeB):
      ```
      cd <your oai installation directory>/openairinterface5g/
      source oaienv
      cd cmake_targets/
      ./build_oai -I -w USRP --eNB --UE --nrUE --gNB
      ```
      - The `-I` option is to install pre-requisites, you only need it the first time you build the softmodem or when some oai dependencies have changed. Note: for Ubuntu 20 use cmake_targets/install_external_packages.ubuntu20 instead!
      - The `-w` option is to select the radio head support you want to include in your build. Radio head support is provided via a shared library, which is called the "oai device" The build script creates a soft link from `liboai_device.so` to the true device which will be used at run-time (here the USRP one,`liboai_usrpdevif.so` . USRP is the only hardware tested today in the Continuous Integration process. The RF simulator[RF simulator](../targets/ARCH/rfsimulator/README.md) is implemented as a specific device replacing RF hardware, it can be specifically built using `-w SIMU` option, but is also built during any softmodem build.
      - `--eNB` is to build the `lte-softmodem` executable and all required shared libraries
      - `--gNB` is to build the `nr-softmodem` executable and all required shared libraries
      - `--UE` is to build the `lte-uesoftmodem` executable and all required shared libraries
      - `--nrUE` is to build the `nr-uesoftmodem` executable and all required shared libraries
      You can build any oai softmodem executable separately, you may not need all of them depending on your oai usage.
      After completing the build, the binaries are available in the `cmake_targets/ran_build/build` directory. A copy is also available in the `target/bin` directory, with all binaries suffixed by the 3GPP release number, today .Rel15.
      When installing the pre-requisites, especially the `UHD` driver, you can now specify if you want to install from source or not.
      - For `fedora`-based OS, it was already the case all the time. But now you can specify which version to install.
      - For `ubuntu` OS, the Ettus PPA currently installs the following versions:
      * `Ubuntu16.04`: --> version `3.15.0.0`
      * `Ubuntu18.04`: --> version `4.1.0.0`
      ```bash
      export BUILD_UHD_FROM_SOURCE=True
      export UHD_VERSION=3.15.0.0
      ./build_oai -I -w USRP
      ```
      The `UHD_VERSION` env variable `SHALL` be a valid tag (minus `v`) from the `https://github.com/EttusResearch/uhd.git` repository.
      ## Issue when building `nasmeh` module ##
      A lot of users and contributors have faced the issue: `nasmesh` module does not build.
      The reason is that the linux headers are not properly installed. For example:
      ```bash
      $ uname -r
      4.4.0-145-lowlatency
      $ dpkg --list | grep 4.4.0-145-lowlatency | grep headers
      ii linux-headers-4.4.0-145-lowlatency 4.4.0-145.171
      ```
      In my example it is properly installed.
      Check on your environment:
      ```bash
      $ uname -r
      your-version
      $ dpkg --list | grep your-version | grep headers
      $
      ```
      Install it:
      ```bash
      $ sudo apt-get install --yes linux-headers-your-version
      ```
      On CentOS or RedHat Entreprise Linux:
      ```bash
      $ uname -r
      3.10.0-1062.9.1.rt56.1033.el7.x86_64
      $ yum list installed | grep kernel | grep devel
      kernel-devel.x86_64 3.10.0-1062.9.1.el7 @rhel-7-server-rpms
      kernel-rt-devel.x86_64 3.10.0-1062.9.1.rt56.1033.el7
      ```
      If your kernel is generic, install `kernel-devel` package: `sudo yum install kernel-devel`
      In most case, your kernel is real-time. Install `kernel-rt-devel` package: `sudo yum install kernel-rt-devel`
      # Building Optional Binaries
      ## Telnet Server
      The telnet server can be built with the `--build-lib telnetsrv` option, after building the softmodem or while building it.
      `./build_oai -I -w USRP --eNB --UE --build-lib telnetsrv`
      or
      `./build_oai --build-lib telnetsrv`
      You can get documentation about the telnet server [here](common/utils/telnetsrv/DOC/telnetsrv.md)
      ## Other optional libraries
      Using the help option of the build script you can get the list of available optional libraries. Those which haven't been mentioned above are known to need more tests and documentation.
      `./build_oai --build-lib all` will build all available optional libraries.
      # `build_oai` options
      | Option | Status | Description |
      | ----------------------------------------------------------- | ------------------------------------------- | :----------------------------------------------------------- |
      | -h | maintained | get help |
      | -c | maintained | erase all previously built files for this target before starting the new build. |
      | -C | maintained, needs improvement | erase all previously built files for any target before starting the new build. |
      | --verbose-compile | maintained | get compilation messages, as when running `make` or `gcc` directly. |
      | --cflags_processor | maintained | used to pass options to the compiler. |
      | --clean-kernel | unknown | no code in the script corresponding to this option |
      | --install-system-files | maintained | install oai built binaries in linux system files repositories |
      | -w | maintained and tested in CI for USRP device | build corresponding oai device and create the soft link to enforce this device usage at run-time |
      | --phy_simulators | maintained, tested in CI | build all PHY simulators, a set of executables allowing unitary tests of LTE and 5G channel implementation within oai. |
      | --core_simulators | | |
      | -s | | |
      | --run-group | | |
      | -I | maintained, tested in CI | install external dependencies before starting the build |
      | --install-optional-packages | maintained | install optional packages, useful for developing and testing. look at the check_install_additional_tools function in cmake_targets/tools/build_helper script to get the list |
      | -g | maintained | Specifies the level of debugging options used to build the binaries. Available levels are `Release`, `RelWithDebInfo`, `MinSizeRe` and `Debug`. If -g is not specified, `Release` is used, if -g is used without any level, `Debug` is used. |
      | -G | maintained | Display Cmake debugging messages |
      | --eNB | maintained and tested in CI | build `lte-softmodem` the LTE eNodeB |
      | --UE | maintained and tested in CI | build `lte-uesoftmodem` the LTE UE |
      | --gNB | maintained and tested in CI | build `nr-softmodem` the 5G gNodeB |
      | --nrUE | maintained and tested in CI | build `nr-uesoftmodem` the 5G UE |
      | --usrp-recplay | deprecated | use the USRP configuration parameters to use the record player. |
      | --build-lib | maintained | build optional shared library(ies), which can then be loaded at run time via command line option. Use the --help option to get the list of supported optional libraries. `all` can be used to build all available optional libraries. |
      | --UE-conf-nvram | maintained | Specifies the path to the input file used by the conf2uedata utility. defaults to [NAS/TOOLS/ue_eurecom_test_sfr.conf](../NAS/TOOLS/ue_eurecom_test_sfr.conf) |
      | --UE-gen-nvram | maintained | Specifies the path where the output file created by the conf2uedata utility will be placed. Defaults to `target/bin` |
      | -V | deprecated | Used to build with support for synchronization diagram utility. This is now available via the T-Tracer and is included if T-Tracer is not disabled. |
      | --build-doxygen | unknown | build doxygen documentation, many oai source files do not include doxygen comments |
      | --disable-deadline --enable-deadline --disable-cpu-affinity | deprecated | These options were used to activate or de-activate specific code depending on the choice of a specific linux scheduling mode. This has not been tested for a while and should be implemented as configuration options |
      | --disable-T-Tracer | maintained, to be tested | Remove T_Tracer and console LOG messages except error messages. |
      | --ue-autotest-trace --ue-timing --ue-trace | deprecated | Were used to enable conditional code implementing debugging messages or debugging statistics. These functionalities are now either available from run-time options or not maintained. |
      | --build-eclipse | unknown | |
      | | | |
      [oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
      [oai softmodem features](FEATURE_SET.md)
      [running the oai softmodem ](RUNMODEM.md)
      doc/F1-design.md deleted 100644 → 0
      View file @ bbee4d98
      <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 @ bbee4d98
      **Table of Contents**
      1. [Functional Split Architecture](#functional-split-architecture)
      2. [OpenAirInterface Block Diagram](#openairinterface-block-diagram)
      2. [OpenAirInterface 4G-LTE eNB Feature Set](#openairinterface-4g-lte-enb-feature-set)
      1. [eNB PHY Layer](#enb-phy-layer)
      2. [eNB MAC Layer](#enb-mac-layer)
      3. [eNB RLC Layer](#enb-rlc-layer)
      4. [eNB PDCP Layer](#enb-pdcp-layer)
      5. [eNB RRC Layer](#enb-rrc-layer)
      6. [eNB X2AP](#enb-x2ap)
      7. [eNB/MCE M2AP](#enbmce-m2ap)
      8. [MCE/MME M3AP](#mcemme-m3ap)
      3. [OpenAirInterface 4G-LTE UE Feature Set](#openairinterface-4g-lte-ue-feature-set)
      1. [LTE UE PHY Layer](#lte-ue-phy-layer)
      2. [LTE UE MAC Layer](#lte-ue-mac-layer)
      3. [LTE UE RLC Layer](#lte-ue-rlc-layer)
      4. [LTE UE PDCP Layer](#lte-ue-pdcp-layer)
      5. [LTE UE RRC Layer](#lte-ue-rrc-layer)
      4. [OpenAirInterface 5G-NR gNB Feature Set](#openairinterface-5g-nr-feature-set)
      1. [General Parameters](#general-parameters)
      2. [gNB Physical Layer](#gnb-phy-layer)
      3. [gNB Higher Layers](#gnb-higher-layers)
      5. [OpenAirInterface 5G-NR UE Feature Set](#openairinterface-5g-nr-ue-feature-set)
      1. [UE Physical Layer](#ue-phy-layer)
      2. [UE Higher Layers](#ue-higher-layers)
      # Functional Split Architecture #
      - RCC: Radio-Cloud Center
      - RAU: Radio-Access Unit
      - RRU: Remote Radio-Unit
      - IF4.5 / IF5 : similar to IEEE P1914.1
      - FAPI (IF2) : specified by Small Cell Forum (open-nFAPI implementation)
      - IF1 : F1 in 3GPP Release 15
      ![Functional Split Architecture](./oai_enb_func_split_arch.png)
      # OpenAirInterface Block Diagram #
      ![Block Diagram](./oai_enb_block_diagram.png)
      # OpenAirInterface 4G LTE eNB Feature Set #
      ## eNB PHY Layer ##
      The Physical layer implements **3GPP 36.211**, **36.212**, **36.213** and provides the following features:
      - LTE release 8.6 compliant, and implements a subset of release 10
      - FDD and TDD configurations: 1 (experimental) and 3
      - Bandwidth: 5, 10, and 20 MHz
      - Transmission modes: 1, 2 (stable), 3, 4, 5, 6, 7 (experimental)
      - Max number of antennas: 2
      - CQI/PMI reporting: aperiodic, feedback mode 3 - 0 and 3 - 1
      - PRACH preamble format 0
      - Downlink (DL) channels are supported: PSS, SSS, PBCH, PCFICH, PHICH, PDCCH, PDSCH, PMCH, MPDCCH
      - Uplink (UL) channels are supported: PRACH, PUSCH, PUCCH (format 1/1a/1b), SRS, DRS
      - HARQ support (UL and DL)
      - Highly optimized base band processing (including turbo decoder)
      - Multi-RRU support: over the air synchro b/ multi RRU in TDD mode
      - Support for CE-modeA for LTE-M. Limited support for repeatition, single-LTE-M connection, legacy-LTE UE attach is disabled.
      ### Performances ###
      **Transmission Mode, Bandwidth** | **Expected Throughput** | **Measured Throughput** | **Measurement Conditions**
      -------------------------------- | ----------------------- | ------------------------| ----------------:
      FDD DL: 5 MHz, 25 PRBS/ MCS 28 | 16 - 17 Mbit/s | TM1: 17.0 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      FDD DL: 10 MHz, 50 PRBS/ MCS 28 | 34 - 35 Mbit/s | TM1: 34.0 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      FDD DL: 20 MHz, 100 PRBS/ MCS 28 | 70 Mbit/s | TM1: 69.9 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      | | |
      FDD UL: 5 MHz, 25 PRBS/ MCS 20 | 9 Mbit/s | TM1: 8.28 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      FDD UL: 10 MHz, 50 PRBS/ MCS 20 | 17 Mbit/s | TM1: 18.3 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      FDD UL: 20 MHz, 100 PRBS/ MCS 20 | 35 Mbit/s | TM1: 18.6 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      | |
      TDD DL: 5 MHz, 25 PRBS/ MCS **XX** | 6.5 Mbit/s | TM1: 6.71 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      TDD DL: 10 MHz, 50 PRBS/ MCS **XX** | 13.5 Mbit/s | TM1: 13.6 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      TDD DL: 20 MHz, 100 PRBS/ MCS **XX** | 28.0 Mbit/s | TM1: 27.2 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      | | |
      TDD UL: 5 MHz, 25 PRBS/ MCS **XX** | 2.0 Mbit/s | TM1: 3.31 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      TDD UL: 10 MHz, 50 PRBS/ MCS **XX** | 2.0 Mbit/s | TM1: 7.25 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      TDD UL: 20 MHz, 100 PRBS/ MCS **XX** | 3.0 Mbit/s | TM1: 4.21 Mbits/s | COTS-UE Cat 4 (150/50 Mbps)
      ### Number of supported UEs ###
      * 16 by default
      * up to 256 when compiling with dedicated compile flag
      * was tested with 40 COTS-UE
      ## eNB MAC Layer ##
      The MAC layer implements a subset of the **3GPP 36.321** release v8.6 in support of BCH, DLSCH, RACH, and ULSCH channels.
      - RRC interface for CCCH, DCCH, and DTCH
      - Proportional fair scheduler (round robin scheduler soon), with the following improvements:
      - Up to 30 users tested in the L2 simulator, CCE allocation in the preprocessor ; the scheduler was also simplified and made more modular
      - Adaptative UL-HARQ
      - Remove out-of-sync UEs
      - No use of the `first_rb` in the UL scheduler ; respects `vrb_map_UL` and `vrb_map` in the DL
      - DCI generation
      - HARQ Support
      - RA procedures and RNTI management
      - RLC interface (AM, UM)
      - UL power control
      - Link adaptation
      - Connected DRX (CDRX) support for FDD LTE UE. Compatible with R13 from 3GPP. Support for Cat-M1 UE comming soon.
      ## eNB RLC Layer ##
      The RLC layer implements a full specification of the 3GPP 36.322 release v9.3.
      - RLC TM (mainly used for BCCH and CCCH)
      * Neither segment nor concatenate RLC SDUs
      * Do not include a RLC header in the RLC PDU
      * Delivery of received RLC PDUs to upper layers
      - RLC UM (mainly used for DTCH)
      * Segment or concatenate RLC SDUs according to the TB size selected by MAC
      * Include a RLC header in the RLC PDU
      * Duplication detection
      * PDU reordering and reassembly
      - RLC AM, compatible with 9.3
      * Segmentation, re-segmentation, concatenation, and reassembly
      * Padding
      * Data transfer to the user
      * RLC PDU retransmission in support of error control and correction
      * Generation of data/control PDUs
      ## eNB PDCP Layer ##
      The current PDCP layer is header compliant with **3GPP 36.323** Rel 10.1.0 and implements the following functions:
      - User and control data transfer
      - Sequence number management
      - RB association with PDCP entity
      - PDCP entity association with one or two RLC entities
      - Integrity check and encryption using the AES and Snow3G algorithms
      ## eNB RRC Layer ##
      The RRC layer is based on **3GPP 36.331** v15.6 and implements the following functions:
      - System Information broadcast (SIB 1, 2, 3, and 13)
      * SIB1: Up to 6 PLMN IDs broadcast
      - RRC connection establishment
      - RRC connection reconfiguration (addition and removal of radio bearers, connection release)
      - RRC connection release
      - RRC connection re-establishment
      - Inter-frequency measurement collection and reporting (experimental)
      - eMBMS for multicast and broadcast (experimental)
      - Handover (experimental)
      - Paging (soon)
      - RRC inactivity timer (release of UE after a period of data inactivity)
      ## eNB X2AP ##
      The X2AP layer is based on **3GPP 36.423** v14.6.0 and implements the following functions:
      - X2 Setup Request
      - X2 Setup Response
      - X2 Setup Failure
      - Handover Request
      - Handover Request Acknowledge
      - UE Context Release
      - X2 timers (t_reloc_prep, tx2_reloc_overall)
      - Handover Cancel
      - X2-U interface implemented
      - EN-DC is implemented
      - X2AP : Handling of SgNB Addition Request / Addition Request Acknowledge / Reconfiguration Complete
      - RRC : Handling of RRC Connection Reconfiguration with 5G cell info, configuration of 5G-NR measurements
      - S1AP : Handling of E-RAB Modification Indication / Confirmation
      ## eNB/MCE M2AP ##
      The M2AP layer is based on **3GPP 36.443** v14.0.1:
      - M2 Setup Request
      - M2 Setup Response
      - M2 Setup Failure
      - M2 Scheduling Information
      - M2 Scheduling Information Response
      - M2 Session Start Request
      - M2 Session Start Response
      ## MCE/MME M3AP ##
      The M3AP layer is based on **3GPP 36.444** v14.0.1:
      - M3 Setup Request
      - M3 Setup Response
      - M3 Setup Failure
      - M3 Session Start Request
      - M3 Session Start Response
      # OpenAirInterface 4G LTE UE Feature Set #
      ## LTE UE PHY Layer ##
      The Physical layer implements **3GPP 36.211**, **36.212**, **36.213** and provides the following features:
      - LTE release 8.6 compliant, and implements a subset of release 10
      - FDD and TDD configurations: 1 (experimental) and 3
      - Bandwidth: 5, 10, and 20 MHz
      - Transmission modes: 1, 2 (stable)
      - Max number of antennas: 2
      - CQI/PMI reporting: aperiodic, feedback mode 3 - 0 and 3 - 1
      - PRACH preamble format 0
      - All downlink (DL) channels are supported: PSS, SSS, PBCH, PCFICH, PHICH, PDCCH, PDSCH, PMCH
      - All uplink (UL) channels are supported: PRACH, PUSCH, PUCCH (format 1/1a/1b), SRS, DRS
      - LTE MBMS-dedicated cell (feMBMS) procedures subset for LTE release 14 (experimental)
      - LTE non-MBSFN subframe (feMBMS) Carrier Adquistion Subframe-CAS procedures (PSS/SSS/PBCH/PDSH) (experimental)
      - LTE MBSFN MBSFN subframe channel (feMBMS): PMCH (CS@1.25KHz) (channel estimation for 25MHz bandwidth) (experimental)
      ## LTE UE MAC Layer ##
      The MAC layer implements a subset of the **3GPP 36.321** release v8.6 in support of BCH, DLSCH, RACH, and ULSCH channels.
      - RRC interface for CCCH, DCCH, and DTCH
      - HARQ Support
      - RA procedures and RNTI management
      - RLC interface (AM, UM)
      - UL power control
      - Link adaptation
      - MBMS-dedicated cell (feMBMS) RRC interface for BCCH
      - eMBMS and MBMS-dedicated cell (feMBMS) RRC interface for MCCH, MTCH
      ## LTE UE RLC Layer ##
      The RLC layer implements a full specification of the 3GPP 36.322 release v9.3.
      ## LTE UE PDCP Layer ##
      The current PDCP layer is header compliant with **3GPP 36.323** Rel 10.1.0.
      ## LTE UE RRC Layer ##
      The RRC layer is based on **3GPP 36.331** v14.3.0 and implements the following functions:
      - System Information decoding
      - RRC connection establishment
      - MBMS-dedicated cell (feMBMS) SI-MBMS/SIB1-MBMS management
      ## LTE UE NAS Layer ##
      The NAS layer is based on **3GPP 24.301** and implements the following functions:
      - EMM attach/detach, authentication, tracking area update, and more
      - ESM default/dedicated bearer, PDN connectivity, and more
      # OpenAirInterface 5G-NR Feature Set #
      ## General Parameters ##
      The following features are valid for the gNB and the 5G-NR UE.
      * Static TDD,
      * FDD
      * Normal CP
      * 30 kHz subcarrier spacing
      * Bandwidths: 10, 20, 40, 80, 100MHz (273 Physical Resource Blocks)
      * Intermediate downlink and uplink frequencies to interface with IF equipment
      * Single antenna port (single beam)
      * Slot format: 14 OFDM symbols in UL or DL
      * Highly efficient 3GPP compliant LDPC encoder and decoder (BG1 and BG2 supported)
      * Highly efficient 3GPP compliant polar encoder and decoder
      * Encoder and decoder for short blocks
      * Support for UL transform precoding (SC-FDMA)
      ## gNB PHY Layer ##
      * 30KHz SCS for FR1 and 120 KHz SCS for FR2
      * Generation of NR-PSS/NR-SSS
      * NR-PBCH supports multiple SSBs and flexible periodicity
      * Generation of NR-PDCCH (including generation of DCI, polar encoding, scrambling, modulation, RB mapping, etc)
      - common search space
      - user-specific search space
      - DCI formats: 00, 10, 01 and 11
      * Generation of NR-PDSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
      - PDSCH mapping type A and B
      - DMRS configuration type 1 and 2
      - Single and multiple DMRS symbols
      - PTRS support
      - Support for 1, 2 and 4 TX antennas
      - Support for up to 2 layers (currently limited to DMRS configuration type 2)
      * NR-CSIRS Generation of sequence at PHY
      * NR-PUSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
      - PUSCH mapping type A and B
      - DMRS configuration type 1 and 2
      - Single and multiple DMRS symbols
      - PTRS support
      - Support for 1 RX antenna
      - Support for 1 layer
      * NR-PUCCH
      - Format 0 (2 bits, for ACK/NACK and SR)
      - Format 2 (up to 11 bits, mainly for CSI feedback)
      * NR-SRS
      - SRS signal reception
      - Channel estimation (with T tracer real time monitoring)
      - Power noise estimation
      * NR-PRACH
      - Formats 0,1,2,3, A1-A3, B1-B3
      * Highly efficient 3GPP compliant LDPC encoder and decoder (BG1 and BG2 are supported)
      * Highly efficient 3GPP compliant polar encoder and decoder
      * Encoder and decoder for short block
      ## gNB Higher Layers ##
      **gNB MAC**
      - MAC -> PHY configuration using NR FAPI P5 interface
      - MAC <-> PHY data interface using FAPI P7 interface for BCH PDU, DCI PDU, PDSCH PDU
      - Scheduler procedures for SIB1
      - Scheduler procedures for RA
      - Contention Free RA procedure
      - Contention Based RA procedure
      - Msg3 can transfer uplink CCCH, DTCH or DCCH messages
      - CBRA can be performed using MAC CE or C-RNTI
      - Scheduler procedures for CSI-RS
      - MAC downlink scheduler
      - phy-test scheduler (fixed allocation and usable also without UE)
      - regular scheduler with dynamic allocation
      - MCS adaptation from HARQ BLER
      - MAC header generation (including timing advance)
      - ACK / NACK handling and HARQ procedures for downlink
      - MAC uplink scheduler
      - phy-test scheduler (fixed allocation)
      - regular scheduler with dynamic allocation
      - HARQ procedures for uplink
      - Scheduler procedures for SRS reception
      - Periodic SRS reception
      - MAC procedures to handle CSI measurement report
      - evalution of RSRP report
      - evaluation of CQI report
      - MAC scheduling of SR reception
      **gNB RLC**
      - Send/Receive operations according to 38.322 Rel.16
      - Segmentation and reassembly procedures
      - RLC Acknowledged mode supporting PDU retransmissions
      - RLC Unacknowledged mode
      - DRBs and SRBs establishment/handling and association with RLC entities
      - Timers implementation
      - Interfaces with PDCP, MAC
      - Interfaces with gtp-u (data Tx/Rx over F1-U at the DU)
      **gNB PDCP**
      - Send/Receive operations according to 38.323 Rel.16
      - Integrity protection and ciphering procedures
      - Sequence number management, SDU dicard and in-order delivery
      - Radio bearer establishment/handling and association with PDCP entities
      - Interfaces with RRC, RLC
      - Interfaces with gtp-u (data Tx/Rx over N3 and F1-U interfaces)
      **gNB RRC**
      - NR RRC (38.331) Rel 16 messages using new asn1c
      - LTE RRC (36.331) also updated to Rel 15
      - Generation of CellGroupConfig (for eNB) and MIB
      - Generation of system information block 1 (SIB1)
      - Generation of system information block 2 (SIB2)
      - Application to read configuration file and program gNB RRC
      - RRC can configure PDCP, RLC, MAC
      - Interface with gtp-u (tunnel creation/handling for S1-U (NSA), N3 (SA) interfaces)
      - Integration of RRC messages and procedures supporting UE 5G SA connection
      - RRCSetupRequest/RRCSetup/RRCSetupComplete
      - RRC Uplink/Downlink Information transfer carrying NAS messages transparently
      - RRC Reconfiguration/Reconfiguration complete
      - Support for master cell group configuration
      - Interface with NGAP for the interactions with the AMF
      - Interface with F1AP for CU/DU split deployment option
      **gNB X2AP**
      - Integration of X2AP messages and procedures for the exchanges with the eNB over X2 interface supporting the NSA setup according to 36.423 Rel. 15
      - X2 setup with eNB
      - Handling of SgNB Addition Request / Addition Request Acknowledge / Reconfiguration Complete
      **gNB NGAP**
      - Integration of NGAP messages and procedures for the exchanges with the AMF over N2 interface according to 38.413 Rel. 15
      - NGAP Setup request/response
      - NGAP Initial UE message
      - NGAP Initial context setup request/response
      - NGAP Downlink/Uplink NAS transfer
      - NGAP UE context release request/complete
      - NGAP UE radio capability info indication
      - NGAP PDU session resource setup request/response
      - Interface with RRC
      **gNB F1AP**
      - Integration of F1AP messages and procedures for the control plane exchanges between the CU and DU entities according to 38.473 Rel. 16
      - F1 Setup request/response
      - F1 DL/UL RRC message transfer
      - F1 Initial UL RRC message transfer
      - F1 UE Context setup request/response
      - F1 gNB CU configuration update
      - Interface with RRC
      - Interface with gtp-u (tunnel creation/handling for F1-U interface)
      **gNB GTP-U**
      - New gtp-u implementation supporting both N3 and F1-U interfaces according to 29.281 Rel.15
      - Interfaces with RRC, F1AP for tunnel creation
      - Interfaces with PDCP and RLC for data send/receive at the CU and DU respectively (F1-U interface)
      # OpenAirInterface 5G-NR UE Feature Set #
      * Supporting "noS1" mode (DL and UL):
      - Creates TUN interface to PDCP to inject and receive user-place traffic
      - No connection to the core network
      * Supporting Standalone (SA) mode:
      - UE can register with the 5G Core Network, establish a PDU Session and exchange user-plane traffic
      ## NR UE PHY Layer ##
      * Initial synchronization
      * Time tracking based on PBCH DMRS
      * Frequency offset estimation
      * 30KHz SCS for FR1 and 120 KHz SCS for FR2
      * Reception of NR-PSS/NR-SSS
      * NR-PBCH supports multiple SSBs and flexible periodicity
      * Reception of NR-PDCCH (including reception of DCI, polar decoding, de-scrambling, de-modulation, RB de-mapping, etc)
      - common search space configured by MIB
      - user-specific search space configured by RRC
      - DCI formats: 00, 10, 01 and 11
      * Reception of NR-PDSCH (including Segmentation, LDPC decoding, rate de-matching, de-scrambling, de-modulation, RB de-mapping, etc).
      - PDSCH mapping type A and B
      - DMRS configuration type 1 and 2
      - Single and multiple DMRS symbols
      - PTRS support
      - Support for 1, 2 and 4 RX antennas
      - Support for up to 2 layers (currently limited to DMRS configuration type 2)
      * NR-PUSCH (including Segmentation, LDPC encoding, rate matching, scrambling, modulation, RB mapping, etc).
      - PUSCH mapping type A and B
      - DMRS configuration type 1 and 2
      - Single and multiple DMRS symbols
      - PTRS support
      - Support for 1 TX antenna
      - Support for 1 layer
      * NR-PUCCH
      - Format 0 (2 bits for ACK/NACK and SR)
      - Format 2 (up to 64 bits, mainly for CSI feedback)
      - Format 1, 3 and 4 present but old code never dested (need restructuring before verification)
      * NR-SRS
      - Generation of sequence at PHY
      - SRS signal transmission
      * NR-PRACH
      - Formats 0,1,2,3, A1-A3, B1-B3
      * SS-RSRP
      - RSRP measured on synchronization SSB (ok only for single SSB)
      * Highly efficient 3GPP compliant LDPC encoder and decoder (BG1 and BG2 are supported)
      * Highly efficient 3GPP compliant polar encoder and decoder
      * Encoder and decoder for short block
      ## NR UE FAPI ##
      * MAC -> PHY configuration via UE FAPI P5 interface
      * Basic MAC to control PHY via UE FAPI P7 interface
      * PHY -> MAC indication (needs some improvement)
      ## NR UE Higher Layers ##
      **UE MAC**
      * Minimum system information (MSI)
      - MIB processing
      - Scheduling of system information block 1 (SIB1) reception
      * Random access procedure (needs improvement, there is still not a clear separation between MAC and PHY)
      - Mapping SSBs to multiple ROs
      - Scheduling of PRACH
      - Processing of RAR
      - Transmission and re-transmission of Msg3
      - Msg4 and contention resolution
      * DCI processing
      - format 10 (RA-RNTI, C-RNTI, SI-RNTI, TC-RNTI)
      - format 00 (C-RNTI, TC-RNTI)
      - format 11 (C-RNTI)
      - format 01 (C-RNTI)
      * UCI processing
      - ACK/NACK processing
      - Triggering periodic SR
      - CSI measurement reporting (SSB RSRP only)
      * DLSH scheduler
      - Configuration of fapi PDU according to DCI
      - HARQ procedures
      * ULSCH scheduler
      - Configuration of fapi PDU according to DCI
      * Scheduler procedures for SRS transmission
      - Periodic SRS transmission
      **UE RLC**
      * Tx/Rx operations according to 38.322 Rel.16
      - Segmentation and reassembly procedures
      - RLC Acknowledged mode supporting PDU retransmissions
      - RLC Unacknowledged mode
      - DRBs and SRBs establishment and handling
      - Timers implementation
      - Interfaces with PDCP, MAC
      **UE PDCP**
      * Tx/Rx operations according to 38.323 Rel.16
      - Integrity protection and ciphering procedures
      - Sequence number management, SDU dicard and in-order delivery
      - Radio bearer establishment/handling and association with PDCP entities
      - Interfaces with RRC, RLC
      **UE RRC**
      * Integration of RRC messages and procedures supporting UE 5G SA connection according to 38.331 Rel.16
      - RRCSetupRequest/RRCSetup/RRCSetupComplete
      - RRC Uplink/Downlink Information transfer carrying NAS messages transparently
      - RRC Reconfiguration/Reconfiguration complete
      - Support for master cell group configuration
      * Interface with PDCP: configuration, DCCH and CCCH message handling
      * Interface with RLC and MAC for configuration
      **UE NAS**
      * Transfer of NAS messages between the AMF and the UE supporting the UE registration with the core network and the PDU session establishment according to 24.501 Rel.16
      - Identity Request/Response
      - Authentication Request/Response
      - Security Mode Command/Complete
      - Registration Request/Accept/Complete
      - PDU Session Establishment Request/Accept
      - NAS configuration and basic interfacing with RRC
      [OAI wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
      [OAI softmodem build procedure](BUILD.md)
      [Running the OAI softmodem ](RUNMODEM.md)
      doc/GET_SOURCES.md deleted 100644 → 0
      View file @ bbee4d98
      <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 @ bbee4d98
      <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 @ bbee4d98
      <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 @ bbee4d98
      <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 @ bbee4d98
      <table style="border-collapse: collapse; border: none;">
      <tr style="border-collapse: collapse; border: none;">
      <td style="border-collapse: collapse; border: none;">
      <a href="http://www.openairinterface.org/">
      <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
      </img>
      </a>
      </td>
      <td style="border-collapse: collapse; border: none; vertical-align: center;">
      <b><font size = "5">L2 nFAPI Simulator (no S1 Mode / 2-host deployment)</font></b>
      </td>
      </tr>
      </table>
      **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`.**
      ## Table of Contents ##
      1. [Environment](#1-environment)
      2. [Retrieve the OAI eNB-UE source code](#2-retrieve-the-oai-enb-ue-source-code)
      3. [Setup of the USIM information in UE folder](#3-setup-of-the-usim-information-in-ue-folder)
      4. [Setup of the Configuration files](#4-setup-of-the-configuration-files)
      1. [The eNB Configuration file](#41-the-enb-configuration-file)
      2. [The UE Configuration file](#42-the-ue-configuration-file)
      5. [Build OAI UE and eNodeB](#5-build-oai-ue-and-enodeb)
      6. [Start the eNB](#6-start-the-enb)
      7. [Start the UE](#7-start-the-ue)
      8. [Test with ping](#8-test-with-ping)
      9. [Limitations](#9-limitations)
      # 1. Environment #
      You may not have access to an EPC or you don't want to hassle to deploy one.
      2 servers are used in this deployment. You can use Virtual Machines instead of each server; like it is done in the CI process.
      * Machine B contains the OAI eNB executable (`lte-softmodem`)
      * Machine C contains the OAI UE(s) executable (`lte-uesoftmodem`)
      Example of L2 nFAPI Simulator testing environment:
      <img src="./images/L2-sim-noS1-2-host-deployment.png" alt="" border=3>
      Note that the IP addresses are indicative and need to be adapted to your environment.
      # 2. Retrieve the OAI eNB-UE source code #
      At the time of writing, the tag used in the `develop` branch to do this documentation was `2020.w16`.
      The tutorial should be valid for the `master` branch tags such as `v1.2.0` or `v1.2.1`. But you may face issues that could be fixed in newer `develop` tags.
      Please try to use the same commit ID on both eNB/UE hosts.
      ```bash
      $ ssh sudousername@machineB
      git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git enb_folder
      cd enb_folder
      git checkout develop
      ```
      ```bash
      $ ssh sudousername@machineC
      git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ue_folder
      cd ue_folder
      git checkout develop
      ```
      # 3. Setup of the USIM information in UE folder #
      ```bash
      $ ssh sudousername@machineC
      cd ue_folder
      # Edit NAS/TOOLS/ue_eurecom_test_sfr.conf with your preferred editor
      ```
      Edit the USIM information within this file in order to match the HSS database. They **HAVE TO** match:
      * PLMN+MSIN and IMSI of users table of HSS database **SHALL** be the same.
      * OPC of this file and OPC of users table of HSS database **SHALL** be the same.
      * USIM_API_K of this file and the key of users table of HSS database **SHALL** be the same.
      When testing multiple UEs, it is necessary to add other UEs information like described below for 2 Users. Only UE0 (first UE) information is written in the original file.
      ```
      UE0:
      {
      USER: {
      IMEI="356113022094149";
      MANUFACTURER="EURECOM";
      MODEL="LTE Android PC";
      PIN="0000";
      };
      SIM: {
      MSIN="0000000001"; // <-- Modify here
      USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";
      OPC="e734f8734007d6c5ce7a0508809e7e9c";
      MSISDN="33611123456";
      };
      ...
      };
      // Copy the UE0 and edit
      UE1: // <- Edit here
      {
      USER: {
      IMEI="356113022094149";
      MANUFACTURER="EURECOM";
      MODEL="LTE Android PC";
      PIN="0000";
      };
      SIM: {
      MSIN="0000000002"; // <-- Modify here
      USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";
      OPC="e734f8734007d6c5ce7a0508809e7e9c";
      MSISDN="33611123456";
      };
      ...
      };
      ```
      You can repeat the operation for as many users you want to test with.
      # 4. Setup of the Configuration files #
      **CAUTION: both proposed configuration files resides in the ci-scripts realm. You can copy them but you CANNOT push any modification on these 2 files as part of an MR without informing the CI team.**
      ## 4.1. The eNB Configuration file ##
      ```bash
      $ ssh sudousername@machineB
      cd enb_folder
      # Edit ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf with your preferred editor
      ```
      First verify the nFAPI interface setup on the physical ethernet interface of machineB and put the proper IP addresses for both hosts.
      ```
      MACRLCs = (
      {
      num_cc = 1;
      local_s_if_name = "ens3"; // <-- HERE
      remote_s_address = "192.168.122.169"; // <-- HERE
      local_s_address = "192.168.122.31"; // <-- HERE
      local_s_portc = 50001;
      remote_s_portc = 50000;
      local_s_portd = 50011;
      remote_s_portd = 50010;
      tr_s_preference = "nfapi";
      tr_n_preference = "local_RRC";
      }
      );
      ```
      If you are testing more than 16 UEs, a proper setting on the RUs is necessary. **Note that this part is NOT present in the original configuration file**.
      ```
      RUs = (
      {
      local_rf = "yes"
      nb_tx = 1
      nb_rx = 1
      att_tx = 20
      att_rx = 0;
      bands = [38];
      max_pdschReferenceSignalPower = -23;
      max_rxgain = 116;
      eNB_instances = [0];
      }
      );
      ```
      Last, the S1 interface shall be properly set.
      ```
      ////////// MME parameters:
      mme_ip_address = ( { ipv4 = "CI_MME_IP_ADDR"; // replace with 192.168.122.195
      ipv6 = "192:168:30::17";
      active = "yes";
      preference = "ipv4";
      }
      );
      NETWORK_INTERFACES :
      {
      ENB_INTERFACE_NAME_FOR_S1_MME = "ens3"; // replace with the proper interface name
      ENB_IPV4_ADDRESS_FOR_S1_MME = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
      ENB_INTERFACE_NAME_FOR_S1U = "ens3"; // replace with the proper interface name
      ENB_IPV4_ADDRESS_FOR_S1U = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
      ENB_PORT_FOR_S1U = 2152; # Spec 2152
      ENB_IPV4_ADDRESS_FOR_X2C = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
      ENB_PORT_FOR_X2C = 36422; # Spec 36422
      };
      ```
      ## 4.2. The UE Configuration file ##
      ```bash
      $ ssh sudousername@machineB
      cd ue_folder
      # Edit ci-scripts/conf_files/ue.nfapi.conf with your preferred editor
      ```
      Verify the nFAPI interface setup on the loopback interface.
      ```
      L1s = (
      {
      num_cc = 1;
      tr_n_preference = "nfapi";
      local_n_if_name = "ens3"; // <- HERE
      remote_n_address = "192.168.122.31"; // <- HERE
      local_n_address = "192.168.122.169"; // <- HERE
      local_n_portc = 50000;
      remote_n_portc = 50001;
      local_n_portd = 50010;
      remote_n_portd = 50011;
      }
      );
      ```
      # 5. Build OAI UE and eNodeB #
      See [Build documentation](./BUILD.md).
      # 6. Start the eNB #
      In the first terminal (the one you used to build the eNB):
      ```bash
      $ ssh sudousername@machineB
      cd enb_folder/cmake_targets
      sudo -E ./ran_build/build/lte-softmodem -O ../ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf --noS1 > enb.log 2>&1
      sleep 10
      ifconfig
      ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
      inet addr:192.168.122.31 Bcast:192.168.122.255 Mask:255.255.255.0
      ....
      oaitun_enb1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.0.1.1 P-t-P:192.172.0.2 Mask:255.255.255.0
      ....
      ```
      If you don't use redirection, you can test but many logs are printed on the console and this may affect performance of the L2-nFAPI simulator.
      We do recommend the redirection in steady mode once your setup is correct.
      # 7. Start the UE #
      In the second terminal (the one you used to build the UE):
      ```bash
      $ ssh sudousername@machineC
      cd ue_folder/cmake_targets
      # Test 64 UEs, 1 thread in FDD mode
      sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
      # Test 64 UEs, 1 thread in TDD mode
      sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 -T 1 > ue.log 2>&1
      # The "-T 1" option means TDD config
      ```
      - The number of UEs can set by using `--num-ues` option and the maximum UE number is 255 (with the `--mu*` options, otherwise 16).
      - The number of threads can set with the `--nums-ue-thread`. This number **SHALL NOT** be greater than the number of UEs.
      * At the time of writing, it seems to be enough to run on a single thread.
      - The `--nokrnmod 1` option makes use of the preferred and supported tunnel interface.
      - How many UE that can be tested depends on hardware (server , PC, etc) performance in your environment.
      For example, running with 4 UEs:
      ```bash
      $ ssh sudousername@machineC
      cd ue_folder/cmake_targets
      sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --noS1 --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
      sleep 10
      ifconfig
      ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
      inet addr:192.168.122.169 Bcast:192.168.122.255 Mask:255.255.255.0
      ....
      oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.0.1.2 P-t-P:192.172.0.2 Mask:255.255.255.0
      ....
      oaitun_ue2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.0.1.3 P-t-P:192.172.0.3 Mask:255.255.255.0
      ....
      oaitun_ue3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.0.1.4 P-t-P:192.172.0.4 Mask:255.255.255.0
      ....
      oaitun_ue4 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.0.1.5 P-t-P:192.172.0.5 Mask:255.255.255.0
      ....
      oaitun_uem1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.0.2.2 P-t-P:10.0.2.2 Mask:255.255.255.0
      ....
      ....
      ```
      Having the 4 oaitun_ue tunnel interfaces up and with an allocated address means the connection with EPC went alright.
      # 8. Test with ping #
      In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB: Check with ifconfig
      ```bash
      $ ssh sudousername@machineB
      # Ping UE1 IP address based on the EPC pool used: in this example:
      ping -I oaitun_enb1 -c 20 10.0.1.2
      # Ping UE4 IP address based on the EPC pool used: in this example:
      ping -I oaitun_enb1 -c 20 10.0.1.5
      ```
      Ping from the UE side:
      ```bash
      $ ssh sudousername@machineC
      ping -I oaitun_ue1 -c 20 10.0.1.1
      ping -I oaitun_ue3 -c 20 10.0.1.1
      ```
      iperf operations can also be performed.
      DL traffic:
      ```bash
      $ ssh sudousername@machineC
      iperf -B 10.0.1.2 -u -s -i 1 -fm -p 5002
      $ ssh sudousername@machineB
      iperf -c 10.0.1.2 -u -t 30 -b 3M -i 1 -fm -B 10.0.1.1 -p 5002
      ```
      UL traffic:
      ```bash
      $ ssh sudousername@machineB
      iperf -B 10.0.1.1 -u -s -i 1 -fm -p 5002
      $ ssh sudousername@machineC
      iperf -c 10.0.1.1 -u -t 30 -b 2M -i 1 -fm -B 10.0.1.2 -p 5002
      ```
      # 9. Limitations #
      ----
      [oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
      [oai softmodem features](FEATURE_SET.md)
      [oai softmodem build procedure](BUILD.md)
      [L2 nfapi simulator](L2NFAPI.md)
      doc/L2NFAPI_S1.md deleted 100644 → 0
      View file @ bbee4d98
      <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 (with S1 / 2-host deployment)</font></b>
      </td>
      </tr>
      </table>
      **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`.**
      ## Table of Contents ##
      1. [Environment](#1-environment)
      2. [Prepare the EPC](#2-prepare-the-epc)
      3. [Retrieve the OAI eNB-UE source code](#3-retrieve-the-oai-enb-ue-source-code)
      4. [Setup of the USIM information in UE folder](#4-setup-of-the-usim-information-in-ue-folder)
      5. [Setup of the Configuration files](#5-setup-of-the-configuration-files)
      1. [The eNB Configuration file](#51-the-enb-configuration-file)
      2. [The UE Configuration file](#52-the-ue-configuration-file)
      6. [Build OAI UE and eNodeB](#6-build-oai-ue-and-enodeb)
      7. [Start EPC](#7-start-epc)
      8. [Start the eNB](#8-start-the-enb)
      9. [Start the UE](#9-start-the-ue)
      10. [Test with ping](#10-test-with-ping)
      11. [Limitations](#11-limitations)
      # 1. Environment #
      3 servers are used in this deployment. You can use Virtual Machines instead of each server; like it is done in the CI process.
      * Machine A contains the EPC.
      * Machine B contains the OAI eNB executable (`lte-softmodem`)
      * Machine C contains the OAI UE(s) executable (`lte-uesoftmodem`)
      Example of L2 nFAPI Simulator testing environment:
      <img src="./images/L2-sim-S1-3-host-deployment.png" alt="" border=3>
      Note that the IP addresses are indicative and need to be adapted to your environment.
      # 2. Prepare the EPC #
      Create the environment for the EPC and register all **USIM** information into the **HSS** database.
      If you are using OAI-EPC ([see on GitHub](https://github.com/OPENAIRINTERFACE/openair-epc-fed)), build **HSS/MME/SPGW** and create config files.
      # 3. Retrieve the OAI eNB-UE source code #
      At the time of writing, the tag used in the `develop` branch to do this documentation was `2020.w16`.
      The tutorial should be valid for the `master` branch tags such as `v1.2.0` or `v1.2.1`. But you may face issues that could be fixed in newer `develop` tags.
      Please try to use the same commit ID on both eNB/UE hosts.
      ```bash
      $ ssh sudousername@machineB
      git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git enb_folder
      cd enb_folder
      git checkout develop
      ```
      ```bash
      $ ssh sudousername@machineC
      git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ue_folder
      cd ue_folder
      git checkout develop
      ```
      # 4. Setup of the USIM information in UE folder #
      ```bash
      $ ssh sudousername@machineC
      cd ue_folder
      # Edit NAS/TOOLS/ue_eurecom_test_sfr.conf with your preferred editor
      ```
      Edit the USIM information within this file in order to match the HSS database. They **HAVE TO** match:
      * PLMN+MSIN and IMSI of users table of HSS database **SHALL** be the same.
      * OPC of this file and OPC of users table of HSS database **SHALL** be the same.
      * USIM_API_K of this file and the key of users table of HSS database **SHALL** be the same.
      When testing multiple UEs, it is necessary to add other UEs information like described below for 2 Users. Only UE0 (first UE) information is written in the original file.
      ```
      UE0:
      {
      USER: {
      IMEI="356113022094149";
      MANUFACTURER="EURECOM";
      MODEL="LTE Android PC";
      PIN="0000";
      };
      SIM: {
      MSIN="0000000001"; // <-- Modify here
      USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";
      OPC="e734f8734007d6c5ce7a0508809e7e9c";
      MSISDN="33611123456";
      };
      ...
      };
      // Copy the UE0 and edit
      UE1: // <- Edit here
      {
      USER: {
      IMEI="356113022094149";
      MANUFACTURER="EURECOM";
      MODEL="LTE Android PC";
      PIN="0000";
      };
      SIM: {
      MSIN="0000000002"; // <-- Modify here
      USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";
      OPC="e734f8734007d6c5ce7a0508809e7e9c";
      MSISDN="33611123456";
      };
      ...
      };
      ```
      You can repeat the operation for as many users you want to test with.
      # 5. Setup of the Configuration files #
      **CAUTION: both proposed configuration files resides in the ci-scripts realm. You can copy them but you CANNOT push any modification on these 2 files as part of an MR without informing the CI team.**
      ## 5.1. The eNB Configuration file ##
      ```bash
      $ ssh sudousername@machineB
      cd enb_folder
      # Edit ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf with your preferred editor
      ```
      First verify the nFAPI interface setup on the physical ethernet interface of machineB and put the proper IP addresses for both hosts.
      ```
      MACRLCs = (
      {
      num_cc = 1;
      local_s_if_name = "ens3"; // <-- HERE
      remote_s_address = "192.168.122.169"; // <-- HERE
      local_s_address = "192.168.122.31"; // <-- HERE
      local_s_portc = 50001;
      remote_s_portc = 50000;
      local_s_portd = 50011;
      remote_s_portd = 50010;
      tr_s_preference = "nfapi";
      tr_n_preference = "local_RRC";
      }
      );
      ```
      If you are testing more than 16 UEs, a proper setting on the RUs is necessary. **Note that this part is NOT present in the original configuration file**.
      ```
      RUs = (
      {
      local_rf = "yes"
      nb_tx = 1
      nb_rx = 1
      att_tx = 20
      att_rx = 0;
      bands = [38];
      max_pdschReferenceSignalPower = -23;
      max_rxgain = 116;
      eNB_instances = [0];
      }
      );
      ```
      Last, the S1 interface shall be properly set.
      ```
      ////////// MME parameters:
      mme_ip_address = ( { ipv4 = "CI_MME_IP_ADDR"; // replace with 192.168.122.195
      ipv6 = "192:168:30::17";
      active = "yes";
      preference = "ipv4";
      }
      );
      NETWORK_INTERFACES :
      {
      ENB_INTERFACE_NAME_FOR_S1_MME = "ens3"; // replace with the proper interface name
      ENB_IPV4_ADDRESS_FOR_S1_MME = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
      ENB_INTERFACE_NAME_FOR_S1U = "ens3"; // replace with the proper interface name
      ENB_IPV4_ADDRESS_FOR_S1U = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
      ENB_PORT_FOR_S1U = 2152; # Spec 2152
      ENB_IPV4_ADDRESS_FOR_X2C = "CI_ENB_IP_ADDR"; // replace with 192.168.122.31
      ENB_PORT_FOR_X2C = 36422; # Spec 36422
      };
      ```
      ## 5.2. The UE Configuration file ##
      ```bash
      $ ssh sudousername@machineB
      cd ue_folder
      # Edit ci-scripts/conf_files/ue.nfapi.conf with your preferred editor
      ```
      Verify the nFAPI interface setup on the loopback interface.
      ```
      L1s = (
      {
      num_cc = 1;
      tr_n_preference = "nfapi";
      local_n_if_name = "ens3"; // <- HERE
      remote_n_address = "192.168.122.31"; // <- HERE
      local_n_address = "192.168.122.169"; // <- HERE
      local_n_portc = 50000;
      remote_n_portc = 50001;
      local_n_portd = 50010;
      remote_n_portd = 50011;
      }
      );
      ```
      # 6. Build OAI UE and eNodeB #
      See [Build documentation](./BUILD.md).
      # 7. Start EPC #
      Start the EPC on machine `A`.
      ```bash
      $ ssh sudousername@machineA
      # Start the EPC
      ```
      # 8. Start the eNB #
      In the first terminal (the one you used to build the eNB):
      ```bash
      $ ssh sudousername@machineB
      cd enb_folder/cmake_targets
      sudo -E ./ran_build/build/lte-softmodem -O ../ci-scripts/conf_files/rcc.band7.tm1.nfapi.conf > enb.log 2>&1
      ```
      If you don't use redirection, you can test but many logs are printed on the console and this may affect performance of the L2-nFAPI simulator.
      We do recommend the redirection in steady mode once your setup is correct.
      # 9. Start the UE #
      In the second terminal (the one you used to build the UE):
      ```bash
      $ ssh sudousername@machineC
      cd ue_folder/cmake_targets
      # Test 64 UEs, 1 thread in FDD mode
      sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
      # Test 64 UEs, 1 thread in TDD mode
      sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 -T 1 > ue.log 2>&1
      # The "-T 1" option means TDD config
      ```
      - The number of UEs can set by using `--num-ues` option and the maximum UE number is 255 (with the `--mu*` options, otherwise 16).
      - The number of threads can set with the `--nums-ue-thread`. This number **SHALL NOT** be greater than the number of UEs.
      * At the time of writing, it seems to be enough to run on a single thread.
      - The `--nokrnmod 1` option makes use of the preferred and supported tunnel interface.
      - How many UE that can be tested depends on hardware (server , PC, etc) performance in your environment.
      For example, running with 4 UEs:
      ```bash
      $ ssh sudousername@machineC
      cd ue_folder/cmake_targets
      sudo -E ./ran_build/build/lte-uesoftmodem -O ../ci-scripts/conf_files/ue.nfapi.conf --L2-emul 3 --num-ues 64 --nums_ue_thread 1 --nokrnmod 1 > ue.log 2>&1
      sleep 10
      ifconfig
      ens3 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
      inet addr:192.168.122.169 Bcast:192.168.122.255 Mask:255.255.255.0
      ....
      oaitun_ue1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:192.172.0.2 P-t-P:192.172.0.2 Mask:255.255.255.0
      ....
      oaitun_ue2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:192.172.0.3 P-t-P:192.172.0.3 Mask:255.255.255.0
      ....
      oaitun_ue3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:192.172.0.4 P-t-P:192.172.0.4 Mask:255.255.255.0
      ....
      oaitun_ue4 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:192.172.0.5 P-t-P:192.172.0.5 Mask:255.255.255.0
      ....
      oaitun_uem1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.0.2.2 P-t-P:10.0.2.2 Mask:255.255.255.0
      ....
      ....
      ```
      Having the 4 oaitun_ue tunnel interfaces up and with an allocated address means the connection with EPC went alright.
      # 10. Test with ping #
      In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB: Check with ifconfig
      ```bash
      $ ssh sudousername@machineA
      # Ping UE1 IP address based on the EPC pool used: in this example:
      $ ping -c 20 192.172.0.2
      # Ping UE4 IP address based on the EPC pool used: in this example:
      $ ping -c 20 192.172.0.5
      ```
      iperf operations can also be performed.
      # 11. Limitations #
      ----
      [oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
      [oai softmodem features](FEATURE_SET.md)
      [oai softmodem build procedure](BUILD.md)
      [L2 nfapi simulator](L2NFAPI.md)
      doc/NR_NFAPI_archi.md deleted 100644 → 0
      View file @ bbee4d98
      # 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 @ bbee4d98
      <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 Softmodem</font></b>
      </td>
      </tr>
      </table>
      After you have [built the softmodem executables](BUILD.md) you can set your default directory to the build directory `cmake_targets/ran_build/build/` and start testing some use cases. Below, the description of the different oai functionalities should help you choose the oai configuration that suits your need.
      # Basic Simulator
      See the [dedicated page](BASIC_SIM.md).
      # RF Simulator
      The rf simulator is a oai device replacing the radio heads (for example the USRP device). It allows connecting the oai UE (LTE or 5G) and respectively the oai eNodeB or gNodeB 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. The rf simulator has some preliminary support for channel modeling.
      It is planned to enhance this simulator with the following functionalities:
      - Support for multiple UE connections,each UE being a `lte-uesoftmodem` or `nr_uesoftmodem` instance.
      - Support for multiple eNodeB's or gNodeB's for hand-over tests
      This is an easy use-case to setup and test, as no specific hardware is required. The [rfsimulator page](../targets/ARCH/rfsimulator/README.md ) contains the detailed documentation.
      # L2 nFAPI Simulator
      This simulator connects a eNodeB and UEs through a nfapi interface, short-cutting the L1 layer. The objective of this simulator is to allow multi UEs simulation, with a large number of UEs (ideally up to 255 ) .Here to ease the platform setup, UEs are simulated via a single `lte-uesoftmodem` instance. Today the CI tests just with one UE and architecture has to be reviewed to allow a number of UE above about 16. This work is on-going.
      As for the rf simulator, no specific hardware is required. The [L2 nfapi simulator page](L2NFAPI.md) contains the detailed documentation.
      # L1 Simulator
      The L1 simulator is using the ethernet fronthaul protocol, as used to connect a RRU and a RAU to connect UEs and a eNodeB. UEs are simulated in a single `lte-uesoftmodem` process, as for the nfapi simulator.
      The [L1 simulator page](L1SIM.md) contains the detailed documentation.
      ## noS1 mode
      The noS1 mode is now available via the `--noS1`command line option. It can be used with simulators, described above, or when using oai with true RF boards. Only the oai UE can be connected to the oai eNodeB in noS1 mode.
      By default the noS1 mode is using linux tun interfaces to send or receive ip packets to/from the linux ip stack. using the `--nokrnmod 0`option you can enforce kernel modules instead of tun.
      noS1 code has been revisited, it has been tested with the rf simulator, and tun interfaces. More tests are on going and CI will soon include noS1 tests.
      # Running with a true radio head
      oai supports [number of deployment](FEATURE_SET.md) model, the following are tested in the CI:
      1. [Monolithic eNodeB](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/HowToConnectCOTSUEwithOAIeNBNew) where the whole signal processing is performed in a single process
      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
      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```
      In phy-test mode it is possible to mimic the reception of UE Capabilities at gNB by passing through the command line parameter `--uecap_file` the location and file name of the input UE Capability file, e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap.xml`
      ### 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`
      In do-ra mode it is possible to mimic the reception of UE Capabilities at gNB by passing through the command line parameter `--uecap_file` the location and file name of the input UE Capability file, e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap.xml`
      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`
      ## SA setup with OAI
      The sa flag is used to run gNB in standalone mode.
      In order to run gNB and UE in standalone mode, the following flag is needed:
      `--sa`
      At the gNB the --sa flag does the following:
      - The RRC encodes SIB1 according to the configuration file and transmits it through NR-BCCH-DL-SCH.
      At the UE the --sa flag will:
      - Decode SIB1 and starts the 5G NR Initial Access Procedure for SA:
      1) 5G-NR RRC Connection Setup
      2) NAS Authentication and Security
      3) 5G-NR AS Security Procedure
      4) 5G-NR RRC Reconfiguration
      5) Start Downlink and Uplink Data Transfer
      Command line parameters for UE in --sa mode:
      - `C` : downlink carrier frequency in Hz (default value 0)
      - `CO` : uplink frequency offset for FDD in Hz (default value 0)
      - `numerology` : numerology index (default value 1)
      - `r` : bandwidth in terms of RBs (default value 106)
      - `band` : NR band number (default value 78)
      - `s` : SSB start subcarrier (default value 512)
      ### Run OAI in SA mode
      From the `cmake_targets/ran_build/build` folder:
      gNB on machine 1:
      `sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --sa`
      UE on machine 2:
      `sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 -s 516 --sa`
      With the RF simulator (on the same machine):
      `sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --rfsim --sa`
      `sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 -s 516 --rfsim --sa`
      where `-r` sets the transmission bandwidth configuration in terms of RBs, `-C` sets the downlink carrier frequency and `-s` sets the SSB start subcarrier.
      Additionally, at UE side `--uecap_file` option can be used to pass the UE Capabilities input file (path location + filename), e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap.xml`
      ## IF setup with OAI
      OAI is also compatible with Intermediate Frequency (IF) equipment. This allows to use RF front-end that with arbitrary frequencies bands that do not comply with the standardised 3GPP NR bands.
      To configure the IF frequencies it is necessary to use two command-line options at UE side:
      - `if_freq`, downlink frequency in Hz
      - `if_freq_off`, uplink frequency offset in Hz
      Accordingly, 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 arbitrary frequencies
      The following example uses DL frequency 2169.080 MHz and UL frequency offset -400 MHz, with a configuration file for band 66 (FDD) 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 --if_freq 2169080000 --if_freq_off -400000000`
      [Selecting an alternative ldpc implementation at run time](../PHY/PHY/CODING/DOC/LDPCImplementation.md)
      [oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
      [oai softmodem features](FEATURE_SET.md)
      [oai softmodem build procedure](BUILD.md)
      doc/RUN_NR_NFAPI.md deleted 100644 → 0
      View file @ bbee4d98
      # 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 @ bbee4d98
      ```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 @ bbee4d98
      <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>
      ```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 --> 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
      --> 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 --> L1_tx_free2>L1 tx free]
      -- async launch --> tx_func
      L1_tx_free2 -- send_msg --> rsp((resp_L1))
      end
      rx_func --> rxfunc
      subgraph tx
      direction LR
      subgraph tx_func2
      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
      tx_func2 --> tx_reorder_thread
      end
      ```
      This tuto for 5G gNB design, with Open Cells main
      {: .text-center}
      # 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()
      handles uplink control information, i.e., for the moment HARQ feedback.
      {: .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 main scheduler function 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 schedule_nr_prach() which schedules the (fixed) PRACH region one frame in
      advance.
      Calls nr_csi_meas_reporting() to check when to schedule CSI in PUCCH.
      Calls nr_schedule_RA(): checks RA process 0's state. Schedules Msg.2 via
      nr_generate_Msg2() if an RA process is ongoing, and pre-allocates the Msg. 3
      for PUSCH as well.
      Calls nr_schedule_ulsch(): It is divided into the "preprocessor" and the
      "postprocessor": the first makes the scheduling decisions, the second fills
      nFAPI structures to indicate to the PHY what it is supposed to do. To signal
      which users have how many resources, the preprocessor populates the
      NR_sched_pusch_t (for values changing every TTI, e.g., frequency domain
      allocation) and NR_sched_pusch_save_t (for values changing less frequently, at
      least in FR1 [to my understanding], e.g., DMRS fields when the time domain
      allocation stays between TTIs) structures. Furthermore, the preprocessor is an
      exchangeable module that schedules differently based on a particular
      use-case/deployment type, e.g., one user for phytest [in
      nr_ul_preprocessor_phytest()], multiple users in FR1
      [nr_fr1_ulsch_preprocessor()], or maybe FR2 [does not exist yet]:
      * calls preprocessor via pre_processor_ul(): the preprocessor is responsible
      for allocating CCEs (using allocate_nr_CCEs()) and deciding on resource
      allocation for the UEs including TB size. Note that we do not yet have
      scheduling requests. What it typically does:
      1) check whether the current frame/slot plus K2 is an UL slot, and return if
      not.
      2) Find first free start RB in vrb_map_UL, and as many free consecutive RBs
      as possible.
      3) Either set up resource allocation directly (e.g., for a single UE,
      phytest), or call into a function to perform actual resource allocation.
      Currently, this is done using pf_ul() which implements a basic
      proportional fair scheduler:
      * for every UE, check for retransmission and allocate as necessary
      * Calculate DMRS stuff (nr_set_pusch_semi_static())
      * Calculate the PF coefficient and put eligible UEs into a list
      * Allocate resources to the UE(s) with the highest coefficient
      4) Mark used resources in vrb_map_UL.
      * loop through all users: get a HARQ process as indicated through the
      preprocessor, update statistics, fill nFAPI structures directly for PUSCH,
      and call config_uldci() and fill_dci_pdu_rel15() for DCI filling and PDCCH
      messages.
      Calls nr_schedule_ue_spec(). It is divided into the "preprocessor" and the
      "postprocessor": the first makes the scheduling decisions, the second fills
      nFAPI structures to indicate to the PHY what it is supposed to do. To signal
      which users have how many resources, the preprocessor populates the
      NR_UE_sched_ctrl_t structure of affected users. In particular, the field rbSize
      decides whether a user is to be allocated. Furthermore, the preprocessor is an
      exchangeable module that schedules differently based on a particular
      use-case/deployment type, e.g., one user for phytest [in
      nr_preprocessor_phytest()], multiple users in FR1
      [nr_fr1_dlsch_preprocessor()], or maybe FR2 [does not exist yet].
      * calls preprocessor via pre_processor_dl(): the preprocessor is responsible
      for allocating CCEs and PUCCH (using allocate_nr_CCEs() and
      nr_acknack_scheduling()) and deciding on the frequency/time domain
      allocation including the TB size. What it typically does:
      1) Check available resources in the vrb_map
      2) Checks the quantity of waiting data in RLC
      3) Either set up resource allocation directly (e.g., for a single UE,
      phytest), or call into a function to perform actual resource allocation.
      Currently, this is done using pf_dl() which implements a basic
      proportional fair scheduler:
      * for every UE, check for retransmission and allocate as necessary
      * Calculate the PF coefficient and put eligible UEs into a list
      * Allocate resources to the UE(s) with the highest coefficient
      4) Mark taken resources in the vrb_map
      * loop through all users: check if a new TA is necessary. Then, if a user has
      allocated resources, update statistics (round, sent bytes), update HARQ
      process information, and fill nFAPI structures (allocate a DCI and PDCCH
      messages, TX_req, ...)
      # RRC
      RRC is a regular thread with itti loop on queue: TASK_RRC_GNB
      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 implemented directly on pthreads, ignoring OAI common functions.
      It is a library, running in thread RRC but also in PHY layer threads and some bits in pdcp running thread or F1 interface threads.
      RLC data is isolated and encapsulated.
      It is stored under a global var: nr_rlc_ue_manager
      The init function rlc_module_init() populates this global variable.
      A small effort could lead us to return the pointer to the caller of rlc_module_init() (internal type: nr_rlc_ue_manager_internal_t)
      but it returns void.
      It could return the initialized pointer (as FILE* fopen() for example), then the RLC layer could have multiple instances in one process.
      Even, a future evolution could remove this global rlc layer: rlc can be only a library that we create a instance for each UE because it doesn't shareany data between UEs.
      For DL (respectively from UL in UE), the scheduler need to know the quantity of data waitin to be sent: it calls mac_rlc_status_ind()
      That "peek" the size of the waiting data for a UE.
      The scheduler then push orders to lower layers. The transport layer will actually pull data from RLC with: mac_rlc_data_req()
      the low layer push data into rlc by: mac_rlc_data_ind()
      Still on DL (gNB side), PDCP push incoming data into RLC by calling: rlc_data_req()
      For UL, the low layer push data into rlc by: mac_rlc_data_ind()
      Then, rlc push it to pdcp by calling pdcp_data_ind() from a complex rlc internal call back (deliver_sdu())
      When adding a UE, external code have to call nr_rrc_rlc_config_asn1_req(), to remove it: rrc_rlc_remove_ue()
      Inside UE, channels called drd or srb can be created: ??? and deleted: rrc_rlc_config_req()
      nr_rlc_tick() must be called periodically to manage the internal timers
      successful_delivery() and max_retx_reached(): in ??? trigger, the RLC sends a itti message to RRC: RLC_SDU_INDICATION (neutralized by #if 0 right now)
      #PDCP
      The PDCP implementation is also protected through a general mutex.
      The design is very similar to rlc layer. The pdcp data is isolated and encapsulated.
      pdcp_layer_init(): same as rlc init
      we have to call a second init function: pdcp_module_init()
      At Tx side (DL in gNB), pdcp_data_req() is the entry function that the upper layer calls.
      The upper layer can be GTP or a PDCP internal thread enb_tun_read_thread() that read directly from Linux socket in case we skip 3GPP core implementation.
      PDCP internals for pdcp_data_req() is thread safe: inside pdcp_data_req_drb(), the pdcp manager protects with the mutex the access to the SDU receiving function of PDCP (recv_sdu() callback, corresponding to nr_pdcp_entity_drb_am_recv_sdu() for DRBs). When it needs, the pdcp layer push this data to rlc by calling : rlc_data_req()
      Also, incoming downlink sdu can comme from internal RRC: in this case, pdcp_run() reads a itti queue, for message RRC_DCCH_DATA_REQ, to0 only call 'pdcp_data_req()'
      At Rx side, pdcp_data_ind() is the entry point that receives the data from RLC.
      - Inside pdcp_data_ind(), the pdcp manager mutex protects the access to the PDU receiving function of PDCP (recv_pdu() callback corresponding to nr_pdcp_entity_drb_am_recv_pdu() for DRBs)
      - Then deliver_sdu_drb() function sends the received data to GTP thread through an ITTI message (GTPV1U_ENB_TUNNEL_DATA_REQ).
      pdcp_config_set_security(): not yet developped
      nr_DRB_preconfiguration(): the mac layer calls this for ???
      nr_rrc_pdcp_config_asn1_req() adds a UE in pdcp, pdcp_remove_UE() removes it
      # 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.
      # New GTP
      ## initialization
      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
      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
      ## 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)?
      About all messages are exchanged with RRC thread
      <div class="panel panel-info">
      **Note**
      {: .panel-heading}
      <div class="panel-body">
      </div>
      </div>
      doc/SystemX-tutorial-design.md deleted 100644 → 0
      View file @ bbee4d98
      # OpenAirInterface for SystemX
      # Terminology
      ****This document use the 5G terminology****
      **Central Unit (CU):** It is a logical node that includes the gNB
      functions like Transfer of user data, Mobility control, Radio access
      network sharing, Positioning, Session Management etc., except those
      functions allocated exclusively to the DU. CU controls the operation of
      DUs over front-haul (Fs) interface. A central unit (CU) may also be
      known as BBU/REC/RCC/C-RAN/V-RAN/VNF
      **Distributed Unit (DU):** This logical node includes a subset of the
      gNB functions, depending on the functional split option. Its operation
      is controlled by the CU. Distributed Unit (DU) also known with other
      names like RRH/RRU/RE/RU/PNF.
      In OpenAir code, the terminology is often RU and BBU.
      # OpenAirUsage
      ## EPC and general environment
      ### OAI EPC
      Use the stable OAI EPC, that can run in one machine (VM or standalone)
      Draft description:
      <https://open-cells.com/index.php/2017/08/22/all-in-one-openairinterface-august-22nd/>
      ## Standalone 4G
      EPC+eNB on one machine, the UE can be commercial or OAI UE.
      ### USRP B210
      Main current issue: traffic is good only on coaxial link between UE and
      eNB (probably power management issue).
      ### Simulated RF
      Running eNB+UE both OAI can be done over a virtual RF link.
      The UE current status is that threads synchronization is implicit in
      some cases. As the RF simulator is very quick, a “sleep()” is required
      in the UE main loop
      (line 1744, targets/RT/USER/lte-ue.c).
      Running also the UE in the same machine is possible with simulated RF.
      Running in same machine is simpler, offers about infinite speed for
      virtual RF samples transmission.
      A specific configuration is required because the EPC Sgi interface has
      the same IP tunnel end point as the UE.
      So, we have to create a network namespace for the UE and to route data
      in/out of the namespace.
      ```bash
      ip netns delete aNameSpace 2&gt; /dev/null
      ip link delete v-eth1 2&gt; /dev/null
      ip netns add aNameSpace
      ip link add v-eth1 type veth peer name v-peer1
      ip link set v-peer1 netns aNameSpace
      ip addr add 10.200.1.1/24 dev v-eth1
      ip link set v-eth1 up
      iptables -t nat -A POSTROUTING -s 10.200.1.0/255.255.255.0 -o enp0s31f6 \
      -j MASQUERADE
      iptables -A FORWARD -i enp0s31f6 -o v-eth1 -j ACCEPT
      iptables -A FORWARD -o enp0s31f6 -i v-eth1 -j ACCEPT
      ip netns exec aNameSpace ip link set dev lo up
      ip netns exec aNameSpace ip addr add 10.200.1.2/24 dev v-peer1
      ip netns exec aNameSpace ip link set v-peer1 up
      ip netns exec aNameSpace bash
      ```
      After the last command, the Linux shell is in the new namespace, ready
      to run the UE.
      To make user plan traffic, the traffic generator has to run in the same
      namespace
      ```bash
      ip netns exec aNameSpace bash
      ```
      The traffic genenrator has to specify the interface:
      ```bash
      route add default oaitun_ue1
      ```
      or specify the outgoing route in the traffic generator (like option “-I”
      in ping command).
      ## Split 6 DL 4G
      The contract describes to reuse the uplink existing if4p5 and to develop
      is this work the downlink “functional split 6”.
      The customer required after signature to develop also the uplink
      functional split 6. This is accepted, as long as the whole work is
      research with no delivery completeness warranty.
      ### Simulation
      To be able to verify the new features and to help in all future
      developments, Open Cells added and improved the Rf board simulator
      during this contract.
      We added the channel modeling simulation, that offer to simulate various
      3GPP defined channels.
      ### Main loop
      The main log is in RF simulator is in
      `targets/RT/USER/lte-ru.c and targets/RT/USER/lte-enb.c`
      As this piece of SW is very complex and doesn’t meet our goals
      (functional split 6), a cleaned version replaces these 2 files in
      executables/ocp-main.c (PHY/SCHED/prach\_procedures.c is also
      replaced by this new file as it only launching the RACH actual work in a
      way not compatible with our FS6).
      The main loop cadences the I/Q samples reception, signal processing and
      I/Q samples sending.
      The main loop uses extensively function pointers to call the right
      processing function depending on the split case.
      A lot of OAI reduntant global variables contains the same semantic data: time,frame, subframe.
      The reworked main loop take care of a uniq variable that comes directly from harware: RF board sampling number.
      To use OAI, we need to set all OAI variables that derivates from this timestamp value. The function setAllfromTS() implements this.
      ### Splitted main level
      When FS6 is actived, a main loop for DU (du_fs6()) a main loop for CU case replaces the uniq eNB main loop.
      Each of these main loops calls initialization of OAI LTE data and the FS6 transport layer initialization.
      Then, it runs a infinite loop on: set time, call UL and DL. The time comes from the RF board, so the DU sends the time to the CU.
      This is enough for RF board dialog, but the FS6 is higher in SW layers,
      we need to cut higher functions inside downlink and uplink procedures.
      As much as possible, the FS6 code is in the directory OPENAIR_DIR/executables. When a given OAI piece of code is small or need complex changes, it is reworked in the file fs6-main.c. The functions naming keeps the OAI function name, adding suffix _fromsplit() or _tosplit().
      When this organization would lead to large code copy, it is better to insert modifications in OAI code. This is done in two files:
      - PHY/SCHED/phy_procedures_lte_eNb.c: to send signaling channels computation results
      - the function sendFs6Ulharq() centralizes all signaling channels forwarding to CU
      - PHY/PHY/LTE_TRANSPORT/ulsch_decoding.c: to deal with FS6 user plane split
      - sendFs6Ul() is used once to forward user plane to CU
      ### DownLink
      The main procedure is phy\_procedures\_eNB\_TX()
      This is building the common channels (beacon, multi-UE signaling).
      The FS6 split breaks this function into pieces:
      * The multi-UE signals, built by common\_signal\_procedures(),
      subframe2harq\_pid(), generate\_dci\_top(), subframe2harq\_pid()
      * These functions run in the DU, nevertheless all context has to be sent
      (it is also needed partially for UL spitting)
      * Run in the DU also to meet the requirement of pushing
      in DU the data encoded with large redundancy (&gt;3 redundancy)
      * the per UE data: pdsch\_procedures() needs further splitting:
      * dlsch\_encoding\_all() that makes the encoding: turbo code
      and lte\_rate\_matching\_turbo() that will be in the DU (some
      unlikely cases can reach redundancy up to x3, when MCS is very
      low (negative SINR cases)).
      * dlsch\_encoding() output needs to be transmitted between the
      DU and the CU for functional split 6.
      * dlsch\_scrambling() that will go in the DU
      * dlsch\_modulation() that will go in the DU
      The du user plane data is made of expanded bit in OAI at FS6 split level. 1 pair of functions compact back these bits into 8bits/byte before sending data and expand it again in the DU data reception (functions: fs6Dl(un)pack()).
      ### Uplink
      The uplink require configuration that is part of the DL transmission.
      It interprets the signalling to extract the RACH and the per UE data
      channels.
      Ocp-main.c:rxtx() calls directly the entry procedure
      phy\_procedures\_eNB\_uespec\_RX() calls:
      * rx\_ulsch() that demodulate and extract soft bits per UE.
      * This function runs in the DU
      * the output data will be processes in the DU, so it needs to be
      transmitted to the DU
      * ulsch\_decoding() that do lte\_rate\_matching\_turbo\_rx()
      sub\_block\_deinterleaving\_turbo()
      then turbo decode that is in the CU
      * fill\_ulsch\_cqi\_indication() fill\_crc\_indication() , fill\_rx\_indication()
      * DU performs the signal processing of each channel data, prepare and sent to the CU the computed result
      * Random access channel detection runs in the DU
      * the DU reports to the CU only the detected temprary identifier for RACH response
      ### signaling data in each direction (UL and DL)
      * each LTE channel needs to be propagated between CU and DU
      * the simplest are the almost static data such as PSS/SSS, that need only static eNB parameters and primary information (frame numbering)
      * all the other channels require data transmission CU to DU and DU to CU
      * the general design push all the low level processing for these channels in the DU
      * the CU interface transports only signal processing results (UL) or configuration to create the RF signal (DL case)
      * HARQ is detected in the DU, then only the ACK or NACK is reported to CU
      * the CU have to control the power and MCS (modulation and coding scheme)
      * the DU performs the signal processing and report only the decoded data like the CQI
      * as the DU performas the modulation, scrambling and puncturing, each data packet is associated with the LTE parameters required for these features
      * in DL, the CU associates the control parameters and the user plane data
      * in UL, the CU sends upfront the scheduled UL data to the DU. So, the DU have the required knowledge to decode the next subframes in time.
      ### UDP transport layer
      A general UDP transport layer is in executables/transport\_split.c
      Linux offers a UDP socket builtin timeout, that we use.
      In and out buffers are memory zones that contains compacted
      (concatenated) UDP chunks.
      For output, sendSubFrame() sends each UDP chunk
      For input, receiveSubFrame() collects all UDP chunks for a group (a
      subframe in OAI LTE case). It returns in the following cases:
      - all chunks are received
      - a timeout expired
      - a chunk from the next subframe already arrived
      ### Functional split 6 usage
      The ocp cleaned main hale to be used: run ocp-softmodem instead of
      lte-softmodem.
      The functionality and parameters is the same, enhanced with FS6 mode.
      The end line option “--split73” enables the fs6 (also called split 7.3) mode and decided to be cu or du.
      Example:
      ```bash
      ./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 cu:127.0.0.1
      ```
      Run the CU init of the split 6 eNB, that will call du on 127.0.0.1 address
      ```bash
      ./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 du:127.0.0.1
      ```
      will run the du, calling the cu on 127.0.0.1
      If the CU and the DU are not on the same machine, the remote address of each side need to be specified as per this example
      ```bash
      ./ocp-softmodem -O $OPENAIR_DIR/enb.fs6.example.conf --rfsim --log_config.phy_log_level debug --split73 du:192.168.1.55
      ```
      runs the functional split 6 DU
      ```bash
      ./lte-uesoftmodem -C 2685000000 -r 50 --rfsim --rfsimulator.serveraddr 192.168.1.1 -d
      ```
      Runs the UE (to have the UE signal scope, compile it with make uescope)
      CU+DU+UE can run with option `--noS1` to avoid to use a EPC and/or with `--rfsim` to simulate RF board
      ## 5G and F1
      Today 5G achievement is limited to physical layer.
      The available modulation is 40MHz, that require one X310 or N300 for the
      gNB and a X310 or N300 for the nrUE.
      ### Usage with X310
      Linux configuration:
      <https://files.ettus.com/manual/page_usrp_x3x0_config.html>
      We included most of this configuration included in OAI source code.
      Remain to set the NIC (network interface card) MTU to 9000 (jumbo
      frames).
      ### Running 5G
      Usage with RFsimulator:
      **gNB**
      ```bash
      sudo RFSIMULATOR=server ./nr-softmodem -O \
      ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf \
      --parallel-config PARALLEL\_SINGLE\_THREAD
      ```
      **nrUE**
      ```bash
      sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem --numerology 1 -r 106 -C \
      3510000000 -d
      ```
      doc/TESTBenches.md deleted 100644 → 0
      View file @ bbee4d98
      ## 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 @ bbee4d98
      <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">OAI 5G SA tutorial</font></b>
      </td>
      </tr>
      </table>
      **TABLE OF CONTENTS**
      1. [SA setup with COTS UE](#1--sa-setup-with-cots-ue)
      1. [gNB build and configuration](#11--gnb-build-and-configuration)
      2. [OAI 5G Core Network installation and configuration](#12--oai-5g-core-network-installation-and-configuration)
      3. [Execution of SA scenario](#13--execution-of-sa-scenario)
      2. [SA Setup with OAI NR UE Softmodem](#2-sa-setup-with-oai-nr-ue-softmodem)
      1. [Build and configuration](#21-build-and-configuration)
      2. [OAI 5G Core Network installation and configuration](#22--oai-5g-core-network-installation-and-configuration)
      3. [Execution of SA scenario](#23-execution-of-sa-scenario)
      In the following tutorial we describe how to deploy configure and test the two SA OAI setups:
      - SA setup with OAI gNB and COTS UE
      - SA setup with OAI gNB and OAI UE
      The operating system and hardware requirements to support OAI 5G NR are described [here](https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/5g-nr-development-and-setup).
      # 1. SA setup with COTS UE
      At the moment of writing this document interoperability with the following COTS UE devices is being tested:
      - [Quectel RM500Q-GL](https://www.quectel.com/product/5g-rm500q-gl/)
      - [Simcom SIMCOM8200EA](https://www.simcom.com/product/SIM8200EA_M2.html)
      - Huawei Mate 30 Pro
      End-to-end control plane signaling to achieve a 5G SA connection, UE registration and PDU session establishment with the CN, as well as some basic user-plane traffic tests have been validated so far using SIMCOM/Quectel modules and Huawei Mate 30 pro. In terms of interoperability with different 5G Core Networks, so far this setup has been tested with:
      - [OAI CN](https://openairinterface.org/oai-5g-core-network-project/)
      - Nokia SA Box
      - [Free CN](https://www.free5gc.org/)
      ## 1.1 gNB build and configuration
      To get the code and build the gNB executable:
      ### Ubuntu 18.04
      ```bash
      git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
      git checkout develop
      cd openairinterface5g/
      source oaienv
      cd cmake_targets/
      ./build_oai -I -w USRP #For OAI first time installation only to install software dependencies
      ./build_oai --gNB -w USRP
      ```
      ### Ubuntu 20.04
      ```bash
      # Build UHD from source
      # https://files.ettus.com/manual/page_build_guide.html
      sudo apt-get install libboost-all-dev libusb-1.0-0-dev doxygen python3-docutils python3-mako python3-numpy python3-requests python3-ruamel.yaml python3-setuptools cmake build-essential
      git clone https://github.com/EttusResearch/uhd.git
      cd uhd/host
      mkdir build
      cd build
      cmake ../
      make -j 4
      make test # This step is optional
      sudo make install
      sudo ldconfig
      sudo uhd_images_downloader
      git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
      git checkout develop
      # Install dependencies in Ubuntu 20.04
      cd
      cd openairinterface5g/
      source oaienv
      cd cmake_targets/
      ./install_external_packages.ubuntu20
      # Build OAI gNB
      cd
      cd openairinterface5g/
      source oaienv
      cd cmake_targets/
      ./build_oai --gNB -w USRP
      ```
      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.
      ```bash
      // Tracking area code, 0x0000 and 0xfffe are reserved values
      tracking_area_code = 1;
      plmn_list = ({
      mcc = 208;
      mnc = 99;
      mnc_length = 2;
      snssaiList = (
      {
      sst = 1;
      sd = 0x1; // 0 false, else true
      },
      {
      sst = 1;
      sd = 0x112233; // 0 false, else true
      }
      );
      });
      ```
      Then, the source and destination IP interfaces for the communication with
      the Core Network also need to be set as shown below.
      ```bash
      ////////// AMF parameters:
      amf_ip_address = ( { ipv4 = "192.168.70.132";
      ipv6 = "192:168:30::17";
      active = "yes";
      preference = "ipv4";
      }
      );
      NETWORK_INTERFACES :
      {
      GNB_INTERFACE_NAME_FOR_NG_AMF = "demo-oai";
      GNB_IPV4_ADDRESS_FOR_NG_AMF = "192.168.70.129/24";
      GNB_INTERFACE_NAME_FOR_NGU = "demo-oai";
      GNB_IPV4_ADDRESS_FOR_NGU = "192.168.70.129/24";
      GNB_PORT_FOR_S1U = 2152; # Spec 2152
      };
      ```
      In the first part (*amf_ip_address*) we specify the IP of the AMF and in the second part (*NETWORK_INTERFACES*) we specify the gNB local interface with AMF (N2 interface) and the UPF (N3 interface).
      **CAUTION:** the `192.168.70.132` AMF IF address is the OAI-CN5G `AMF` Container IP address. You certainly will need to do some networking manipulations for the `gNB` server to be able to see this AMF container.
      Please read [CN5G tutorial for more details](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/README.md).
      ### **gNB configuration in CU/DU split mode**
      For the configuration of the gNB in CU and DU blocks, the following sample configuration files are provided for the [CU](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/targets/PROJECTS/GENERIC-NR-5GC/CONF/cu_gnb.conf) and the [DU](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/targets/PROJECTS/GENERIC-NR-5GC/CONF/du_gnb.conf) entities respectively. These configuration files have to be updated with the IP addresses of the CU and the DU over the F1 interface. For example, in the following section from the DU configuration file, *local_n_address* corresponds to the DU address and *remote_n_address* corresponds to the CU address:
      ```bash
      MACRLCs = (
      {
      num_cc = 1;
      tr_s_preference = "local_L1";
      tr_n_preference = "f1";
      local_n_if_name = "lo";
      local_n_address = "127.0.0.3";
      remote_n_address = "127.0.0.4";
      local_n_portc = 601;
      local_n_portd = 2152;
      remote_n_portc = 600;
      remote_n_portd = 2152;
      }
      );
      ```
      At the point of writing this document the control-plane exchanges between the CU and the DU over *F1-C* interface, as well as some IP traffic tests over *F1-U* have been validated using the OAI gNB/nrUE in RFSIMULATOR mode.
      ## 1.2 OAI 5G Core Network installation and configuration
      The instructions for the installation of OAI CN components (AMF, SMF, NRF, UPF) using `docker-compose` can be found [here](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/README.md).
      ## 1.3 Execution of SA scenario
      After having configured the gNB, we can start the individual components in the following sequence:
      - Launch 5G Core Network
      - Launch gNB
      - Launch COTS UE (disable airplane mode)
      The execution command to start the gNB (in monolithic mode) is the following:
      ```bash
      cd cmake_targets/ran_build/build
      sudo ./nr-softmodem -E --sa -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf
      ```
      # 2. SA Setup with OAI NR UE Softmodem
      The SA setup with OAI UE has been validated with **RFSIMULATOR**. Both control plane and user plane for the successful UE registration and PDU Session establishment has been verified with OAI and Nokia SA Box CNs.
      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*)
      - USIM_API_K and OPc keys
      - NSSAI (*Network Slice Assistance Information*)
      - DNN (*Data Network Name*)
      Below is a sample configuration file that can be parsed through the execution command ([section 2.3](#23-execution-of-sa-scenario)).
      ```bash
      uicc0 = {
      imsi = "208990000007487";
      key = "fec86ba6eb707ed08905757b1bb44b8f";
      opc= "C42449363BBAD02B66D16BC975D77CC1";
      dnn= "oai";
      nssai_sst=1;
      nssai_sd=1;
      }
      ```
      Alternatively, the values can be hardcoded/edited in source file ***UICC/usim_interface.c*** through the following lines:
      ```bash
      #define UICC_PARAMS_DESC {\
      {"imsi", "USIM IMSI\n", 0, strptr:&(uicc->imsiStr), defstrval:"2089900007487", TYPE_STRING, 0 },\
      {"nmc_size" "number of digits in NMC", 0, iptr:&(uicc->nmc_size), defintval:2, TYPE_INT, 0 },\
      {"key", "USIM Ki\n", 0, strptr:&(uicc->keyStr), defstrval:"fec86ba6eb707ed08905757b1bb44b8f", TYPE_STRING, 0 },\
      {"opc", "USIM OPc\n", 0, strptr:&(uicc->opcStr), defstrval:"c42449363bbad02b66d16bc975d77cc1", TYPE_STRING, 0 },\
      {"amf", "USIM amf\n", 0, strptr:&(uicc->amfStr), defstrval:"8000", TYPE_STRING, 0 },\
      {"sqn", "USIM sqn\n", 0, strptr:&(uicc->sqnStr), defstrval:"000000", TYPE_STRING, 0 },\
      {"dnn", "UE dnn (apn)\n", 0, strptr:&(uicc->dnnStr), defstrval:"oai", TYPE_STRING, 0 },\
      {"nssai_sst", "UE nssai\n", 0, iptr:&(uicc->nssai_sst), defintval:1, TYPE_INT, 0 }, \
      {"nssai_sd", "UE nssai\n", 0, iptr:&(uicc->nssai_sd), defintval:1, TYPE_INT, 0 }, \
      };
      ```
      For interoperability with OAI or other CNs, it should be ensured that the configuration of the aforementioned parameters match the configuration of the corresponding subscribed user at the core network.
      ## 2.1 Build and configuration
      To build the gNB and OAI UE executables:
      ```bash
      cd cmake_targets
      # Note: For OAI first time installation please install software dependencies as described in 1.1.
      ./build_oai --gNB --nrUE -w SIMU
      ```
      The gNB configuration can be performed according to what is described in [section 1.1](#11--gnb-build-and-configuration), using the same reference configuration file as with the RF scenario.
      ## 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).
      ## 2.3 Execution of SA scenario
      The order of starting the different components should be the same as the one described in [section 1.3](#13--execution-of-sa-scenario).
      the gNB can be launched in 2 modes:
      - To launch the gNB in `monolithic` mode:
      ```bash
      sudo RFSIMULATOR=server ./nr-softmodem --rfsim --sa \
      -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf
      ```
      - To launch the gNB in `CU/DU split` mode:
      1. Launch the CU component:
      ```bash
      sudo RFSIMULATOR=server ./nr-softmodem --rfsim --sa \
      -O ../../../ci-scripts/conf_files/gNB_SA_CU.conf
      ```
      2. Launch the DU component:
      ```bash
      sudo RFSIMULATOR=server ./nr-softmodem --rfsim --sa \
      -O ../../../ci-scripts/conf_files/gNB_SA_DU.conf
      ```
      - To launch the OAI UE (valid in `monolithic` gNB and `CU/DU split` gNB):
      ```bash
      sudo RFSIMULATOR=127.0.0.1 ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 \
      --rfsim --sa --nokrnmod -O <PATH_TO_UE_CONF_FILE>
      ```
      The IP address at the execution command of the OAI UE corresponds to the target IP of the gNB host that the RFSIMULATOR at the UE will connect to. In the above example, we assume that the gNB and UE are running on the same host so the specified address (127.0.0.1) is the one of the loopback interface.
      doc/TESTING_GNB_W_COTS_UE.md deleted 100644 → 0
      View file @ bbee4d98
      STATUS 2020/10/15 : added External Resources section and links
      ## Table of Contents ##
      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
      ## Configuration Overview
      * Non Standalone (NSA) configuration : initial Control Plane established between UE and RAN eNB, then User Plane established between UE and gNB, Core network is 4G based supporting rel 15
      * OAI Software Defined gNB and eNB
      * eNB RF front end: USRP (ETTUS) B200 Mini or B210
      * gNB RF front end: USRP (ETTUS) B200 Mini or B210 (N310 will be needed for MIMO and wider BW's)
      * 5G TDD duplexing mode
      * 5G FR1 Band n78 (3.5 GHz)
      * BW: 40MHz
      * Antenna scheme: SISO
      ## COTS UEs
      Our code might not work with all 5G phones yet, but we are constantly improving it. Here is a list of COTS UEs that we know that work with OAI.
      * Oppo Reno 5G
      * Samsung A90 5G
      * Samsung A42 5G
      * Google Pixel 5G (note1)
      * Simcom SIMCOM8200EA
      * Quectel RM500Q-GL
      Note1: In the version we have at Eurecom, you need to set the PLMN to 50501, and you also need to change the firmware to "11.0.0 (RD1A.201105.003.B1, Nov 2020, EU carriers)" (see https://developers.google.com/android/images)
      ## Repository
      https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop
      ## Architecture Setup
      The scheme below depicts our typical setup:
      ![image info](./testing_gnb_w_cots_ue_resources/oai_fr1_setup.jpg)
      The photo depicts the FR1 setup part of the scheme above:
      ![image info](./testing_gnb_w_cots_ue_resources/oai_fr1_lab.jpg)
      ## Build and Install
      General guidelines to build eNB and gNB :
      See https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/doc/BUILD.md#building-ues-enodeb-and-gnodeb-executables
      - **eNB**
      ```
      cd <your oai installation directory>/openairinterface5g/
      source oaienv
      cd cmake_targets/
      ./build_oai -I -w USRP --eNB
      ```
      - **gNB**
      ```
      cd <your oai installation directory>/openairinterface5g/
      source oaienv
      cd cmake_targets/
      ./build_oai -I -w USRP --gNB
      ```
      - **EPC**
      for reference:
      https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
      ## Configuration Files
      Each component (EPC, eNB, gNB) has its own configuration file.
      These config files are passed as arguments of the run command line, using the option -O \<conf file\>
      The **REFERENCE** files for eNB and gNB, **used by the CI**, can be found here:
      [enb conf file](../ci-scripts/conf_files/enb.band7.tm1.fr1.25PRB.usrpb210.conf)
      [gnb conf file](../ci-scripts/conf_files/gnb.band78.tm1.fr1.106PRB.usrpb210.conf)
      These files have to be updated manually to set the IP addresses and frequency.
      **ATTENTION** : an **EXTERNAL** clock is used to sync the eNB and gNB,
      whether the clock is internal or external is defined in the configuration files (!! details needed !!)
      1- In the **eNB configuration file** :
      - look for MME IP address, and update the **ipv4 field** with the IP address of the **EPC** server
      ```
      ////////// MME parameters:
      mme_ip_address = ( { ipv4 = "**YOUR_EPC_IP_ADDR**";
      ipv6 = "192:168:30::17";
      active = "yes";
      preference = "ipv4";
      }
      );
      ```
      - look for S1 IP address, and update the **3 fields below** with the IP address of the **eNB** server
      ```
      NETWORK_INTERFACES :
      {
      ENB_INTERFACE_NAME_FOR_S1_MME = "eth0";
      ENB_IPV4_ADDRESS_FOR_S1_MME = "**YOUR_ENB_IP_ADDR**";
      ENB_INTERFACE_NAME_FOR_S1U = "eth0";
      ENB_IPV4_ADDRESS_FOR_S1U = "**YOUR_ENB_IP_ADDR**";
      ENB_PORT_FOR_S1U = 2152; # Spec 2152
      ENB_IPV4_ADDRESS_FOR_X2C = "**YOUR_ENB_IP_ADDR**";
      ENB_PORT_FOR_X2C = 36422; # Spec 36422
      };
      ```
      2- In the **gNB configuration file** :
      - look for MME IP address, and update the **ipv4 field** with the IP address of the **EPC** server
      ```
      ////////// MME parameters:
      mme_ip_address = ( { ipv4 = "**YOUR_EPC_IP_ADDR**";
      ipv6 = "192:168:30::17";
      active = "yes";
      preference = "ipv4";
      }
      );
      ```
      - look for X2 IP address, and update the **4 fields** with the IP address of the **eNB** server / **gNB** server as below (notice : even if -in principle- S1 MME is not required for gNB setting)
      ```
      ///X2
      enable_x2 = "yes";
      t_reloc_prep = 1000; /* unit: millisecond */
      tx2_reloc_overall = 2000; /* unit: millisecond */
      target_enb_x2_ip_address = (
      { ipv4 = "**YOUR_ENB_IP_ADDR**";
      ipv6 = "192:168:30::17";
      preference = "ipv4";
      }
      );
      NETWORK_INTERFACES :
      {
      GNB_INTERFACE_NAME_FOR_S1_MME = "eth0";
      GNB_IPV4_ADDRESS_FOR_S1_MME = "**YOUR_GNB_IP_ADDR**";
      GNB_INTERFACE_NAME_FOR_S1U = "eth0";
      GNB_IPV4_ADDRESS_FOR_S1U = "**YOUR_GNB_IP_ADDR**";
      GNB_PORT_FOR_S1U = 2152; # Spec 2152
      GNB_IPV4_ADDRESS_FOR_X2C = "**YOUR_GNB_IP_ADDR**";
      GNB_PORT_FOR_X2C = 36422; # Spec 36422
      };
      ```
      3- The frequency setting requires a manual update in the .C and in the gNB conf file:
      In the C file **RRC/LTE/rrc_eNB.c:3217**
      set the nrarfcn to the same value as absoluteFrequencySSB in the **gNB config file**, that is **641272** in the example below
      C file :
      ```
      MeasObj2->measObject.choice.measObjectNR_r15.carrierFreq_r15 =641272;
      ```
      gNB config file :
      ```
      # absoluteFrequencySSB is the central frequency of SSB
      absoluteFrequencySSB = 641272;
      dl_frequencyBand = 78;
      # the carrier frequency is assumed to be in the middle of the carrier, i.e. dl_absoluteFrequencyPointA_kHz + dl_carrierBandwidth*12*SCS_kHz/2
      dl_absoluteFrequencyPointA = 640000;
      #scs-SpecificCarrierList
      dl_offstToCarrier = 0;
      # subcarrierSpacing
      # 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
      dl_subcarrierSpacing = 1;
      dl_carrierBandwidth = 106;
      ```
      ## Run and Test
      The order to run the different components is important:
      1- first, CN
      2- then, eNB
      3- then, gNB
      4- finally, switch UE from airplane mode ON to OFF (ie Radio from OFF to ON)
      It is recommended to redirect the run commands to the same log file (fur further analysis and debug), using ```| tee **YOUR_LOG_FILE**``` especially for eNB and gNB.
      It is not very useful for the CN.
      The test takes typically a few seconds, max 10-15 seconds. If it takes more than 30 seconds, there is a problem.
      - **EPC** (on EPC host):
      for reference:
      https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
      - **eNB** (on the eNB host):
      Execute:
      ```
      ~/openairinterface5g/cmake_targets/ran_build/build$ sudo ./lte-softmodem -O **YOUR_ENB_CONF_FILE** | tee **YOUR_LOG_FILE**
      ```
      - **gNB** (on the gNB host)
      **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
      Execute:
      ```
      ~/openairinterface5g/cmake_targets/ran_build/build$ sudo ./nr-softmodem -O **YOUR_GNB_CONF_FILE** -E | tee **YOUR_LOG_FILE**
      ```
      ## Test Case
      The test case corresponds to the UE attachement, that is the UE connection and its initial access in 5G, as depicted below:
      **Source** : https://www.sharetechnote.com/html/5G/5G_LTE_Interworking.html
      ![image info](./testing_gnb_w_cots_ue_resources/attach_signaling_scheme.jpg)
      The test reaches step **12. E-RAB modifcation confirmation** , eventhough not all the messages will appear in the log file.
      ## Log file monitoring
      From the log file that is generated, we can monitor several important steps, to assess that the test was successful.
      Log files examples can be found here:
      [enb log file](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/rh_doc_update_3/doc/testing_gnb_w_cots_ue_resources/oai_enb.log)
      [gnb log file](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/rh_doc_update_3/doc/testing_gnb_w_cots_ue_resources/oai_gnb.log)
      - eNB receives UE capabilities information, including its NR capabilites, and triggers sGNB Addition Request message:
      ***eNBlog.1315 :***
      ```
      [RRC] [FRAME 00000][eNB][MOD 00][RNTI 43eb] received ueCapabilityInformation on UL-DCCH 1 from UE
      ...
      [RRC] [eNB 0] frame 0 subframe 0: UE rnti 43eb switching to NSA mode
      ...
      <X2AP-PDU>
      <initiatingMessage>
      <procedureCode>27</procedureCode>
      <criticality><reject/></criticality>
      <value>
      <SgNBAdditionRequest>
      <protocolIEs>
      <SgNBAdditionRequest-IEs>
      <id>111</id>
      <criticality><reject/></criticality>
      <value>
      <UE-X2AP-ID>0</UE-X2AP-ID>
      </value>
      </SgNBAdditionRequest-IEs>
      ```
      - gNB receives sGNB Addition request, processes UE capabilities for the corresponding UE and triggers sGNB Addition Request ACK, carrying NR RRC Reconfiguration message:
      ***gNBlog.2291 :***
      ```
      <X2AP-PDU>
      <successfulOutcome>
      <procedureCode>27</procedureCode>
      <criticality><reject/></criticality>
      <value>
      <SgNBAdditionRequestAcknowledge>
      <protocolIEs>
      <SgNBAdditionRequestAcknowledge-IEs>
      <id>111</id>
      <criticality><reject/></criticality>
      <value>
      <UE-X2AP-ID>0</UE-X2AP-ID>
      </value>
      </SgNBAdditionRequestAcknowledge-IEs>
      ```
      - Upon reception of the sGNB Addition Request ACK, the eNB sends a new RRCConnectionReconfiguration message containing the NR Reconfiguration.
      The UE replies with a Reconfiguration Complete message:
      ***eNBlog.1686 :***
      ```
      [RRC] [FRAME 00000][eNB][MOD 00][RNTI 43eb] UE State = RRC_RECONFIGURED (default DRB, xid 1)
      ```
      - The Random Access procedure of the UE to the gNB takes place:
      ***gNBlog.2382 :***
      ```
      [PHY] [gNB 0][RAPROC] Frame 751, slot 19 Initiating RA procedure with
      preamble 63, energy 35.7 dB, delay 6
      [0m [0m[MAC] [gNB 0][RAPROC] CC_id 0 Frame 751, Slot 19 Initiating RA
      procedure for preamble index 63
      [0m [0m[MAC] [gNB 0][RAPROC] CC_id 0 Frame 751 Activating Msg2
      generation in frame 752, slot 7 using RA rnti 10b
      [0m [0m[MAC] [gNB 0] [RAPROC] CC_id 0 Frame 752, slotP 7: Generating
      RAR DCI, state 1
      [0m [0m[MAC] [RAPROC] DCI type 1 payload: freq_alloc 120 (0,6,24),
      time_alloc 3, vrb to prb 0, mcs 0 tb_scaling 0
      [0m [0m[MAC] Frame 752: Subframe 7 : Adding common DL DCI for RA_RNTI 10b
      [0m [0m[MAC] Frame 752, Subframe 7: Setting Msg3 reception for Frame
      752 Subframe 17
      [0m [0m[PHY] ULSCH received ok
      ```
      - The eNB triggers the path switch procedure towards the MME, so that
      the traffic can be routed now from the SGW towards the gNB on the S1-U
      plane.
      ***eNBlog.1691 :***
      ```
      <S1AP-PDU>
      <initiatingMessage>
      <procedureCode>50</procedureCode>
      <criticality><reject/></criticality>
      <value>
      <E-RABModificationIndication>
      <protocolIEs>
      <E-RABModificationIndicationIEs>
      <id>0</id>
      <criticality><reject/></criticality>
      <value>
      <MME-UE-S1AP-ID>553648130</MME-UE-S1AP-ID>
      </value>
      </E-RABModificationIndicationIEs>
      ```
      Eventually, step **12. E-RAB Modification Confirmation** is successfully reached
      ## Required tools for debug
      - **Wireshark** to trace X2AP and S1AP protocols
      - **Ttracer** for 5G messages
      - **GDB debugger** to check function calls
      ## Status of interoperability
      The following parts have been validated with FR1 COTS UE:
      - Phone accepts the configurtion provided by OAI eNB:
      this validates RRC and X2AP
      - Successful Random Access Procedure:
      PRACH is correctly decoded at gNB
      Phone correctly receives and decodes msg2 (NR PDCCH Format 1_0 and NR PDSCH)
      msg3 is transmitted to gNB according to the configuration sent in msg2, and received correctly at gNB
      - Successful path switch of user plane traffic from 4G to 5G cell (E-RAB modification message):
      this validates S1AP
      - Downlink traffic:
      PDCCH DCI format 1_1 and correponding PDSCH are decoded correctlyby the phone
      ACK/NACK (PUCCH format 0) are successfully received at gNB
      - **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.
      doc/d2d_emulator_setup.txt deleted 100644 → 0
      View file @ bbee4d98
      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 @ bbee4d98
      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 @ bbee4d98
      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 @ bbee4d98
      Active_eNBs = ( "eNB-Eurecom-LTEBox");
      # Asn1_verbosity, choice in: none, info, annoying
      Asn1_verbosity = "none";
      eNBs =
      (
      {
      # real_time choice in {hard, rt-preempt, no}
      real_time = "no";
      ////////// Identification parameters:
      eNB_ID = 0xe01;
      cell_type = "CELL_MACRO_ENB";
      eNB_name = "eNB-Eurecom-LTEBox";
      // Tracking area code, 0x0000 and 0xfffe are reserved values
      tracking_area_code = 1;
      plmn_list = (
      { mcc = 222; mnc = 01; mnc_length = 2; }
      );
      tr_s_preference = "local_mac"
      ////////// Physical parameters:
      component_carriers = (
      {
      node_function = "eNodeB_3GPP";
      node_timing = "synch_to_ext_device";
      node_synch_ref = 0;
      nb_antenna_ports = 1;
      ue_TransmissionMode = 1;
      frame_type = "FDD";
      tdd_config = 3;
      tdd_config_s = 0;
      prefix_type = "NORMAL";
      eutra_band = 7;
      downlink_frequency = 2680000000L; //2655000000L;
      uplink_frequency_offset = -120000000;
      Nid_cell = 0;
      N_RB_DL = 25; //100;
      Nid_cell_mbsfn = 0;
      nb_antennas_tx = 1;
      nb_antennas_rx = 1;
      prach_root = 0;
      tx_gain = 90;
      rx_gain = 115;
      pbch_repetition = "FALSE";
      prach_config_index = 0;
      prach_high_speed = "DISABLE";
      prach_zero_correlation = 1;
      prach_freq_offset = 2;
      pucch_delta_shift = 1;
      pucch_nRB_CQI = 0;
      pucch_nCS_AN = 0;
      pucch_n1_AN = 0;
      pdsch_referenceSignalPower = -29;
      pdsch_p_b = 0;
      pusch_n_SB = 1;
      pusch_enable64QAM = "DISABLE";
      pusch_hoppingMode = "interSubFrame";
      pusch_hoppingOffset = 0;
      pusch_groupHoppingEnabled = "ENABLE";
      pusch_groupAssignment = 0;
      pusch_sequenceHoppingEnabled = "DISABLE";
      pusch_nDMRS1 = 1;
      phich_duration = "NORMAL";
      phich_resource = "ONESIXTH";
      srs_enable = "DISABLE";
      /* srs_BandwidthConfig =;
      srs_SubframeConfig =;
      srs_ackNackST =;
      srs_MaxUpPts =;*/
      pusch_p0_Nominal = -96;
      pusch_alpha = "AL1";
      pucch_p0_Nominal = -96;
      msg3_delta_Preamble = 6;
      pucch_deltaF_Format1 = "deltaF2";
      pucch_deltaF_Format1b = "deltaF3";
      pucch_deltaF_Format2 = "deltaF0";
      pucch_deltaF_Format2a = "deltaF0";
      pucch_deltaF_Format2b = "deltaF0";
      rach_numberOfRA_Preambles = 64;
      rach_preamblesGroupAConfig = "DISABLE";
      /*
      rach_sizeOfRA_PreamblesGroupA = ;
      rach_messageSizeGroupA = ;
      rach_messagePowerOffsetGroupB = ;
      */
      rach_powerRampingStep = 4;
      rach_preambleInitialReceivedTargetPower = -108;
      rach_preambleTransMax = 10;
      rach_raResponseWindowSize = 10;
      rach_macContentionResolutionTimer = 48;
      rach_maxHARQ_Msg3Tx = 4;
      pcch_default_PagingCycle = 128;
      pcch_nB = "oneT";
      bcch_modificationPeriodCoeff = 2;
      ue_TimersAndConstants_t300 = 1000;
      ue_TimersAndConstants_t301 = 1000;
      ue_TimersAndConstants_t310 = 1000;
      ue_TimersAndConstants_t311 = 10000;
      ue_TimersAndConstants_n310 = 20;
      ue_TimersAndConstants_n311 = 1;
      //Parameters for SIB18
      rxPool_sc_CP_Len = "normal";
      rxPool_sc_Period = "sf40";
      rxPool_data_CP_Len = "normal";
      rxPool_ResourceConfig_prb_Num = 20;
      rxPool_ResourceConfig_prb_Start = 5;
      rxPool_ResourceConfig_prb_End = 44;
      rxPool_ResourceConfig_offsetIndicator_present = "prSmall";
      rxPool_ResourceConfig_offsetIndicator_choice = 0;
      rxPool_ResourceConfig_subframeBitmap_present = "prBs40";
      rxPool_ResourceConfig_subframeBitmap_choice_bs_buf = "00000000000000000000";
      rxPool_ResourceConfig_subframeBitmap_choice_bs_size = 5;
      rxPool_ResourceConfig_subframeBitmap_choice_bs_bits_unused = 0;
      /* rxPool_dataHoppingConfig_hoppingParameter = 0;
      rxPool_dataHoppingConfig_numSubbands = "ns1";
      rxPool_dataHoppingConfig_rbOffset = 0;
      rxPool_commTxResourceUC-ReqAllowed = "TRUE";
      */
      // Parameters for SIB19
      discRxPool_cp_Len = "normal"
      discRxPool_discPeriod = "rf32"
      discRxPool_numRetx = 1;
      discRxPool_numRepetition = 2;
      discRxPool_ResourceConfig_prb_Num = 5;
      discRxPool_ResourceConfig_prb_Start = 3;
      discRxPool_ResourceConfig_prb_End = 21;
      discRxPool_ResourceConfig_offsetIndicator_present = "prSmall";
      discRxPool_ResourceConfig_offsetIndicator_choice = 0;
      discRxPool_ResourceConfig_subframeBitmap_present = "prBs40";
      discRxPool_ResourceConfig_subframeBitmap_choice_bs_buf = "f0ffffffff";
      discRxPool_ResourceConfig_subframeBitmap_choice_bs_size = 5;
      discRxPool_ResourceConfig_subframeBitmap_choice_bs_bits_unused = 0;
      }
      );
      srb1_parameters :
      {
      # timer_poll_retransmit = (ms) [5, 10, 15, 20,... 250, 300, 350, ... 500]
      timer_poll_retransmit = 80;
      # timer_reordering = (ms) [0,5, ... 100, 110, 120, ... ,200]
      timer_reordering = 35;
      # timer_reordering = (ms) [0,5, ... 250, 300, 350, ... ,500]
      timer_status_prohibit = 0;
      # poll_pdu = [4, 8, 16, 32 , 64, 128, 256, infinity(>10000)]
      poll_pdu = 4;
      # poll_byte = (kB) [25,50,75,100,125,250,375,500,750,1000,1250,1500,2000,3000,infinity(>10000)]
      poll_byte = 99999;
      # max_retx_threshold = [1, 2, 3, 4 , 6, 8, 16, 32]
      max_retx_threshold = 4;
      }
      # ------- SCTP definitions
      SCTP :
      {
      # Number of streams to use in input/output
      SCTP_INSTREAMS = 2;
      SCTP_OUTSTREAMS = 2;
      };
      enable_measurement_reports = "yes";
      ////////// MME parameters:
      mme_ip_address = ( { ipv4 = "192.168.18.99";
      ipv6 = "192:168:30::17";
      active = "yes";
      preference = "ipv4";
      }
      );
      ///X2
      enable_x2 = "yes";
      t_reloc_prep = 1000; /* unit: millisecond */
      tx2_reloc_overall = 2000; /* unit: millisecond */
      t_dc_prep = 1000; /* unit: millisecond */
      t_dc_overall = 2000; /* unit: millisecond */
      NETWORK_INTERFACES :
      {
      ENB_INTERFACE_NAME_FOR_S1_MME = "eth1";
      ENB_IPV4_ADDRESS_FOR_S1_MME = "192.168.18.199/24";
      ENB_INTERFACE_NAME_FOR_S1U = "eth1";
      ENB_IPV4_ADDRESS_FOR_S1U = "192.168.18.199/24";
      ENB_PORT_FOR_S1U = 2152; # Spec 2152
      ENB_IPV4_ADDRESS_FOR_X2C = "192.168.18.199/24";
      ENB_PORT_FOR_X2C = 36422; # Spec 36422
      };
      log_config :
      {
      global_log_level ="info";
      hw_log_level ="info";
      phy_log_level ="info";
      mac_log_level ="info";
      rlc_log_level ="debug";
      pdcp_log_level ="info";
      rrc_log_level ="info";
      };
      }
      );
      MACRLCs = (
      {
      num_cc = 1;
      tr_s_preference = "local_L1";
      tr_n_preference = "local_RRC";
      phy_test_mode = 0;
      puSch10xSnr = 160;
      puCch10xSnr = 160;
      }
      );
      THREAD_STRUCT = (
      {
      parallel_config = "PARALLEL_RU_L1_TRX_SPLITaaaaaa";
      worker_config = "WORKER_ENABLE";
      }
      );
      L1s = (
      {
      num_cc = 1;
      tr_n_preference = "local_mac";
      }
      );
      RUs = (
      {
      local_rf = "yes"
      nb_tx = 1
      nb_rx = 1
      att_tx = 0
      att_rx = 0;
      bands = [7];
      max_pdschReferenceSignalPower = -27;
      max_rxgain = 118;
      eNB_instances = [0];
      }
      );
      log_config :
      {
      global_log_level ="info";
      hw_log_level ="info";
      phy_log_level ="info";
      mac_log_level ="info";
      rlc_log_level ="info";
      pdcp_log_level ="info";
      rrc_log_level ="info";
      };
      doc/testing_gnb_w_cots_ue_resources/gnb.conf deleted 100755 → 0
      View file @ bbee4d98
      Active_gNBs = ( "gNB-Eurecom-5GNRBox");
      # Asn1_verbosity, choice in: none, info, annoying
      Asn1_verbosity = "none";
      gNBs =
      (
      {
      ////////// Identification parameters:
      gNB_ID = 0xe00;
      cell_type = "CELL_MACRO_GNB";
      gNB_name = "gNB-Eurecom-5GNRBox";
      // Tracking area code, 0x0000 and 0xfffe are reserved values
      tracking_area_code = 1;
      plmn_list = ({mcc = 222; mnc = 01; mnc_length = 2;});
      tr_s_preference = "local_mac"
      ////////// Physical parameters:
      ssb_SubcarrierOffset = 31; //0;
      pdsch_AntennaPorts = 1;
      servingCellConfigCommon = (
      {
      #spCellConfigCommon
      physCellId = 0;
      # downlinkConfigCommon
      #frequencyInfoDL
      # this is 3600 MHz + 84 PRBs@30kHz SCS (same as initial BWP)
      absoluteFrequencySSB = 641272; //641032; #641968; 641968=start of ssb at 3600MHz + 82 RBs 641032=center of SSB at center of cell
      dl_frequencyBand = 78;
      # this is 3600 MHz
      dl_absoluteFrequencyPointA = 640000;
      #scs-SpecificCarrierList
      dl_offstToCarrier = 0;
      # subcarrierSpacing
      # 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
      dl_subcarrierSpacing = 1;
      dl_carrierBandwidth = 106;
      #initialDownlinkBWP
      #genericParameters
      # this is RBstart=84,L=13 (275*(L-1))+RBstart
      initialDLBWPlocationAndBandwidth = 6366; //28875; //6366; #6407; #3384;
      # subcarrierSpacing
      # 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
      initialDLBWPsubcarrierSpacing = 1;
      #pdcch-ConfigCommon
      initialDLBWPcontrolResourceSetZero = 0;
      initialDLBWPsearchSpaceZero = 0;
      #uplinkConfigCommon
      #frequencyInfoUL
      ul_frequencyBand = 78;
      #scs-SpecificCarrierList
      ul_offstToCarrier = 0;
      # subcarrierSpacing
      # 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
      ul_subcarrierSpacing = 1;
      ul_carrierBandwidth = 106;
      pMax = 20;
      #initialUplinkBWP
      #genericParameters
      initialULBWPlocationAndBandwidth = 6366; //28875; //6366; #6407; #3384;
      # subcarrierSpacing
      # 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
      initialULBWPsubcarrierSpacing = 1;
      #rach-ConfigCommon
      #rach-ConfigGeneric
      prach_ConfigurationIndex = 98;
      #prach_msg1_FDM
      #0 = one, 1=two, 2=four, 3=eight
      prach_msg1_FDM = 0;
      prach_msg1_FrequencyStart = 0;
      zeroCorrelationZoneConfig = 13;
      preambleReceivedTargetPower = -118;
      #preamblTransMax (0...10) = (3,4,5,6,7,8,10,20,50,100,200)
      preambleTransMax = 6;
      #powerRampingStep
      # 0=dB0,1=dB2,2=dB4,3=dB6
      powerRampingStep = 1;
      #ra_ReponseWindow
      #1,2,4,8,10,20,40,80
      ra_ResponseWindow = 5;
      #ssb_perRACH_OccasionAndCB_PreamblesPerSSB_PR
      #1=oneeighth,2=onefourth,3=half,4=one,5=two,6=four,7=eight,8=sixteen
      ssb_perRACH_OccasionAndCB_PreamblesPerSSB_PR = 4;
      #oneHalf (0..15) 4,8,12,16,...60,64
      ssb_perRACH_OccasionAndCB_PreamblesPerSSB = 14; //15;
      #ra_ContentionResolutionTimer
      #(0..7) 8,16,24,32,40,48,56,64
      ra_ContentionResolutionTimer = 7;
      rsrp_ThresholdSSB = 19;
      #prach-RootSequenceIndex_PR
      #1 = 839, 2 = 139
      prach_RootSequenceIndex_PR = 2;
      prach_RootSequenceIndex = 1;
      # SCS for msg1, can only be 15 for 30 kHz < 6 GHz, takes precendence over the one derived from prach-ConfigIndex
      #
      msg1_SubcarrierSpacing = 1,
      # restrictedSetConfig
      # 0=unrestricted, 1=restricted type A, 2=restricted type B
      restrictedSetConfig = 0,
      msg3_DeltaPreamble = 1;
      p0_NominalWithGrant =-90;
      # pucch-ConfigCommon setup :
      # pucchGroupHopping
      # 0 = neither, 1= group hopping, 2=sequence hopping
      pucchGroupHopping = 0;
      hoppingId = 40;
      p0_nominal = -90;
      # ssb_PositionsInBurs_BitmapPR
      # 1=short, 2=medium, 3=long
      ssb_PositionsInBurst_PR = 2;
      ssb_PositionsInBurst_Bitmap = 1; #0x80;
      # ssb_periodicityServingCell
      # 0 = ms5, 1=ms10, 2=ms20, 3=ms40, 4=ms80, 5=ms160, 6=spare2, 7=spare1
      ssb_periodicityServingCell = 2;
      # dmrs_TypeA_position
      # 0 = pos2, 1 = pos3
      dmrs_TypeA_Position = 0;
      # subcarrierSpacing
      # 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
      subcarrierSpacing = 1;
      #tdd-UL-DL-ConfigurationCommon
      # subcarrierSpacing
      # 0=kHz15, 1=kHz30, 2=kHz60, 3=kHz120
      referenceSubcarrierSpacing = 1;
      # pattern1
      # dl_UL_TransmissionPeriodicity
      # 0=ms0p5, 1=ms0p625, 2=ms1, 3=ms1p25, 4=ms2, 5=ms2p5, 6=ms5, 7=ms10
      dl_UL_TransmissionPeriodicity = 6;
      nrofDownlinkSlots = 7; //8; //7;
      nrofDownlinkSymbols = 6; //0; //6;
      nrofUplinkSlots = 2;
      nrofUplinkSymbols = 4; //0; //4;
      ssPBCH_BlockPower = 10;
      }
      );
      # ------- SCTP definitions
      SCTP :
      {
      # Number of streams to use in input/output
      SCTP_INSTREAMS = 2;
      SCTP_OUTSTREAMS = 2;
      };
      ////////// MME parameters:
      mme_ip_address = ( { ipv4 = "192.168.18.99";
      ipv6 = "192:168:30::17";
      active = "yes";
      preference = "ipv4";
      }
      );
      ///X2
      enable_x2 = "yes";
      t_reloc_prep = 1000; /* unit: millisecond */
      tx2_reloc_overall = 2000; /* unit: millisecond */
      t_dc_prep = 1000; /* unit: millisecond */
      t_dc_overall = 2000; /* unit: millisecond */
      target_enb_x2_ip_address = (
      { ipv4 = "192.168.18.199";
      ipv6 = "192:168:30::17";
      preference = "ipv4";
      }
      );
      NETWORK_INTERFACES :
      {
      GNB_INTERFACE_NAME_FOR_S1_MME = "eth0";
      GNB_IPV4_ADDRESS_FOR_S1_MME = "192.168.18.198/24";
      GNB_INTERFACE_NAME_FOR_S1U = "eth0";
      GNB_IPV4_ADDRESS_FOR_S1U = "192.168.18.198/24";
      GNB_PORT_FOR_S1U = 2152; # Spec 2152
      GNB_IPV4_ADDRESS_FOR_X2C = "192.168.18.198/24";
      GNB_PORT_FOR_X2C = 36422; # Spec 36422
      };
      }
      );
      MACRLCs = (
      {
      num_cc = 1;
      tr_s_preference = "local_L1";
      tr_n_preference = "local_RRC";
      }
      );
      L1s = (
      {
      num_cc = 1;
      tr_n_preference = "local_mac";
      }
      );
      RUs = (
      {
      local_rf = "yes"
      nb_tx = 1
      nb_rx = 1
      att_tx = 0
      att_rx = 0;
      bands = [7];
      max_pdschReferenceSignalPower = -27;
      max_rxgain = 114;
      eNB_instances = [0];
      clock_src = "internal";
      }
      );
      THREAD_STRUCT = (
      {
      #three config for level of parallelism "PARALLEL_SINGLE_THREAD", "PARALLEL_RU_L1_SPLIT", or "PARALLEL_RU_L1_TRX_SPLIT"
      //parallel_config = "PARALLEL_RU_L1_TRX_SPLIT";
      parallel_config = "PARALLEL_SINGLE_THREAD";
      #two option for worker "WORKER_DISABLE" or "WORKER_ENABLE"
      worker_config = "WORKER_ENABLE";
      }
      );
      security = {
      # preferred ciphering algorithms
      # the first one of the list that an UE supports in chosen
      # valid values: nea0, nea1, nea2, nea3
      ciphering_algorithms = ( "nea0" );
      # preferred integrity algorithms
      # the first one of the list that an UE supports in chosen
      # valid values: nia0, nia1, nia2, nia3
      integrity_algorithms = ( "nia2", "nia0" );
      # setting 'drb_ciphering' to "no" disables ciphering for DRBs, no matter
      # what 'ciphering_algorithms' configures; same thing for 'drb_integrity'
      drb_ciphering = "yes";
      drb_integrity = "no";
      };
      log_config :
      {
      global_log_level ="info";
      hw_log_level ="info";
      phy_log_level ="info";
      mac_log_level ="info";
      rlc_log_level ="info";
      pdcp_log_level ="info";
      rrc_log_level ="info";
      };
      doc/testing_gnb_w_cots_ue_resources/oai_enb.log deleted 100755 → 0
      View file @ bbee4d98
      This source diff could not be displayed because it is too large. You can view the blob instead.
      doc/testing_gnb_w_cots_ue_resources/oai_gnb.log deleted 100755 → 0
      View file @ bbee4d98
      This source diff could not be displayed because it is too large. You can view the blob instead.
      src/PHY/SIMULATION/NR_UE_PHY/unit_tests/build/reflogs/srs_test.txt deleted 100644 → 0
      View file @ bbee4d98
      This source diff could not be displayed because it is too large. You can view the blob instead.
      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