Jaroslava Fiedlerova
8db35e468d
Cleanup PDU Session Handling in RRC/NGAP
Currently, NGAP and RRC share the same structures and responsibilities when
handling PDU Session information: this creates tight coupling, redundancy, and
makes the code harder to maintain.
- NGAP should be responsible only for: Protocol-specific encoding/decoding
(3GPP TS 38.413)
- RRC should own: PDU Session handling and storage in the UE context
This MR is the first step in a broader refactoring of the PDU Session handling
code across NGAP and RRC layers, with the goal of splitting responsibilities
cleanly between both modules.
- Unified gtpu_tunnel_t for tunnel endpoint config (formerly f1u_tunnel_t)
- Refactored and relocated PDU Session struct definitions for better separation
between NGAP and RRC
- Moved pdusession_t for PDU Session handling out of NGAP, now defined and
managed by RRC only
- Defined 3GPP TS 38.413 message-specific structs in NGAP module
- NGAP now decodes NGAP PDU Session Resource Setup/Modify IEs and transfers
decoded data to RRC via ITTI
- Add helper functions to copy from NGAP message to pdusession_t
- Introduced new encoders/decoders/helpers in NGAP for handling PDU Session
Resource Setup/Modify procedures (e.g. decode_pdusession_transfer)
- Migrated to NGAP and removed duplicated logic for QoS information decoding
(fill_qos)
- Improved logging of GTP tunnel info
- Merged redundant functions (f1u_dl_gtp_update and f1u_ul_gtp_update)
- Removed unused code and obsolete types
- do free_func in seq_arr_erase_it on the provided range and updated unit test
- Other fixes and simplifications (e.g. simplified and clarified naming of
tunnel/session parameters and structs)
This cleanup improves code readability, has a high code churn (the deletions are
~159.7% of the insertions) and prepares for better modularity before the
refactoring of PDU Session handling in RRC/NGAP.
OpenAirInterface License
It is distributed under OAI Public License V1.1.
The license information is distributed under LICENSE file in the same directory.
Please see NOTICE file for third party software that is included in the sources.
Where to Start
- General overview of documentation
- The implemented features
- System Requirements for Using OAI Stack
- How to build
- How to run the modems
Not all information is available in a central place, and information for specific sub-systems might be available in the corresponding sub-directories. To find all READMEs, this command might be handy:
find . -iname "readme*"
RAN repository structure
The OpenAirInterface (OAI) software is composed of the following parts:
openairinterface5g
├── charts
├── ci-scripts : Meta-scripts used by the OSA CI process. Contains also configuration files used day-to-day by CI.
├── CMakeLists.txt : Top-level CMakeLists.txt for building
├── cmake_targets : Build utilities to compile (simulation, emulation and real-time platforms), and generated build files.
├── common : Some common OAI utilities, some other tools can be found at openair2/UTILS.
├── doc : Documentation
├── docker : Dockerfiles to build for Ubuntu and RHEL
├── executables : Top-level executable source files (gNB, eNB, ...)
├── maketags : Script to generate emacs tags.
├── nfapi : (n)FAPI code for MAC-PHY interface
├── openair1 : Layer 1 (3GPP LTE Rel-10/12 PHY, NR Rel-15 PHY)
├── openair2 : Layer 2 (3GPP LTE Rel-10 MAC/RLC/PDCP/RRC/X2AP, LTE Rel-14 M2AP, NR Rel-15+ MAC/RLC/PDCP/SDAP/RRC/X2AP/F1AP/E1AP), E2AP
├── openair3 : Layer 3 (3GPP LTE Rel-10 S1AP/GTP, NR Rel-15 NGAP/GTP)
├── openshift : OpenShift helm charts for some deployment options of OAI
├── radio : Drivers for various radios such as USRP, AW2S, RFsim, 7.2 FHI, ...
├── targets : Some configuration files; only historical relevance, and might be deleted in the future
└── tools : Tools for use by the developers/ci machines: code analysis and formatting
How to get support from the OAI Community
You can ask your question on the mailing lists.
Your email should contain below information:
- A clear subject in your email.
- For all the queries there should be [Query] in the subject of the email and for problems there should be [Problem].
- In case of a problem, add a small description.
- Do not share any photos unless you want to share a diagram.
- OAI gNB/DU/CU/CU-CP/CU-UP configuration file in
.confformat only. - Logs of OAI gNB/DU/CU/CU-CP/CU-UP in
.logor.txtformat only. - In case your question is related to performance, include a small description of the machine (Operating System, Kernel version, CPU, RAM and networking card) and diagram of your testing environment.
- Known/open issues are present on GitLab, so keep checking.
Always remember a structured email will help us understand your issues quickly.