Add support for O1 in O-DU via telnet
This change set adds a simple telnet interface to nr-softmodem. Together
with oai/o1-adapter>, this implements a part of the O1 interface, for
the DU only. Currently supported uses cases:
- some stats are send to an SMO (such as bandwidth, PLMN, frequency, ...)
- re-configuration of bandwidth, frequency
- stop/start of the softmodem, while keeping the CU and L2 running
- the o1-adapter implements two alarms, load overload and base station
offline, using this interface.
It is possible to use the telnet interface by itself (i.e., "o1" without
the o1-adapter). To do this, compile with telnet support (./build_oai
--build-lib telnetsrv) and start the nr-softmodem with O1 module
(./nr-softmodem --telnetsrv --telnetsrv.shrmod o1). You can then do the
following:
- see some statistics as exposed to o1-adapter, in JSON: echo o1 stats | nc 127.0.0.1 9090 && echo
- stop the L1: echo o1 stop_modem | nc 127.0.0.1 9090 && echo
- reconfigure bandwidth: e.g., echo o1 bwconfig 20 | nc 127.0.0.1 9090 && echo (also supported: 40, 60, 100)
- start the L1: echo o1 start_modem | nc 127.0.0.1 9090 && echo
Note that the reconfiguration works with split-8 radios. Notably, it
does not work yet out-of-the-box with 7.2 radios, because they have to
be manually reconfigured on bandwith/frequency switch. The planned
M-plane should allow such use case, though.
To help with the above, this branch also includes fixes (for more
information, refer to the corresponding commits):
- fixes for stopping the L1, notably stop threads in right order, stop
thread pool of RU
- collect some general MAC metrics, fix some bugs in MAC
- fix problems in F1AP gNB-DU configuration update message, update test
- fix some problems in RRC
Split out these functions, to be reused in a follow-up commit to
correctly have gNB-DU configuration update message working.
Change the return type copy_f1ap_served_cell_info(), to return the copy,
which IMO is more intuitive then passing target and source in
parentheses.
For the "restart" feature, earlier versions where creating multiple UL
TDA. This is not a problem (anymore), but to avoid that we call this
multiple times, add this assert.
NGAP Failure message - Initial Context Setup Failure.
When an Initial Context Setup Request is received with the UE context as null, it triggers Initial Context Setup failure.
* tac is optional IE, and it was assumed as always present
* is now allocated in DU container by copy_f1ap_served_cell_info
when present in the updated cell info and missing in the
DU container
Refactor of includes in gNB/UE for improved header management
This merge request implements changes suggested by the Include What You Use
(IWYU) open source tool to streamline the project’s header file usage.
The adjustments ensure that each file includes only the necessary headers for
the symbols it uses, making the code more efficient and maintainable.
Unnecessary includes have been removed, and missing headers have been added
where required. This improves modularity and reduces inter-dependencies between
files, helping to avoid future build issues caused by unused or missing includes.
Each output has been manually reviewed.
Followed a similar approach as in !2953 (merged).
Affected folders/files:
- NR_MAC_gNB/main.c
- nr-softmodem.c
- unitary simulators: nr_dlsim, nr_ulsim, prachsim
- openair2/RRC/NR
- openair3/NGAP
- openair2/LAYER2/nr_pdcp
- openair2/SDAP/nr_sdap
Added NTN FDD FR1 bands defined in 3GPP TS 38.101-5
Added support for NTN FDD FR1 bands 254, 255, 256 as specified in 3GPP
TS 38.101-5. Example Conf files added for band254 for 15Khz, 5Mhz and
30Khz, 10Mhz configurations. Tested NTN GEO configuration on band 254
using these conf files.
Added support for NTN FDD FR1 bands 254, 255, 256 as specified in 3GPP TS 38.101-5
Conf files added for 15Khz, 5Mhz and 30Khz, 10Mhz configurations added for these bands
Set SA mode as default
- Set standalone (SA) mode as the default.
- Adjust commands in Docker Compose files by removing --sa flags and
adding --nsa flags where applicable.
- Add a function to verify that only one mode is being used at a time.
- Update all relevant documentation.
Fix Regression 4G
- Fix various bugs and/or regressions in 4G code
- Also, the CI does not test RFsim 4G with --sanitize, enables this to
detect problems.
Simplify logs in gNB&UE
- reduce the amount of printf() that outputs useless info
- in MAC, PHY, NGAP, RRC, mark some "important" UE events with LOG_A for
better visibility -> can put log_config.global_log_level analysis to
only see important stuff
- in RRC, use some macro to consistently print logs
- track the cellID of a UE in RRC
During preparation of SIB1, first digit of MNC was not taking into account.
This leads to XRES*, RES* mismatch during Authentication Procedure between 5GCore and UE because of derived serving network names.
Add F1 Handover procedures
- Clean up at RRC and MAC
- Add DU handover procedures, completely handle CellGroupConfig at DU
- Add CU handover procedures
- Maintain reestablishment working between/after handover
- Changes at UE to resync on different frequency DUs
Instructions: see doc/handover-tutorial.md
Things not implemented/open/missing: see #855
When receiving a measurement report including an A3 event, trigger
handover towards the indicated cell.
Note that currently, we are still limited to one Cell by DU, hence
looking up a cell comes down to looking up a DU, as is done here.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: Luis Pereira <lpereira@allbesmart.pt>
Co-authored-by: Robert Schmidt <robert.schmidt@openairinterface.org>
This commit implements reestablishment during handover when occurring at
the source DU, either as a handover Failure or "normal" reestablishment
(something else went wrong). In this case, the CU will trigger HO
cancel, which in F1, means to cancel on the target DU. Also, undo any
previous ID changes. Retain the old CellGroupConfig (before handover)
for the case of reestablishment at source. If not needed, it is freed
after the reconfiguration complete.
Reestablishment on target cell during handover cannot be handled by the
gNB (yet). It is the same as with a normal reestablishment (not during
handover) on a different cell: that cell has no notion of the old UE, so
we cannot simply indicate the old UE to reestablish; at least, we would
need to cleanup the CellGroupConfig, and I am not sure this works out of
the box, either.
After handover, the last CellGroupConfig received is the one for
handover, containing a reconfigurationWithSync. Resending this
CellGroupConfig to the UE after reestablishment would trigger a
handover. Free the reconfigurationWithSync to have the UE complete
reestablishment at the current cell.
The CU implementation of reestablishment modifies the CellGroupConfig.
It should not do this, but does as of now. The specification (38.473 Sec
8.7) foresees an optional F1 UE context modification procedure (which
can be used to receive the CellGroupConfig). This should be done instead
to retrieve the correct CellGroupConfig.
Note that the F1 UE context setup procedure, similar to the UE context
modification procedure, would also allow to perform reestablishment on a
DU that is not the original one.
If we release a request from a DU during, handle as follows:
- from the source: Handover is still ongoing, so ignore it by
acknowledging the release, and marking handover as done. In this case,
we did not receive an acknowledgement from the target, but since the
source DU does not keep the UE context, we could not cancel the
handover anymore either. The UE might come back on any DU through
reestablishment (or simply be connected on the target)
- from the target: consider this to be a genuine release, and forward to
AMF.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
The HO is completed (from a pure RAN perspective) when receiving
reconfiguration complete. In that case, remove the HO context, and
signal successful handover through the callback. For the F1 handover,
this means releasing the UE at the source DU.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
We expect the UE's RRC Reconfiguration Complete to come through the
target DU, as the "new UE" at the target CU. Also, function
CU_handle_UL_RRC_MESSAGE_TRANSFER() checks that the UL RRC Message,
through which we will receive RRC Reconfiguration Complete, matches the
DU UE ID stored in RRC. Since the DU UE ID will be the one at the target
DU, while up to now, we stored the DU UE ID at the source DU.
Correspondingly, update the DU UE ID to the one at the target DU; also
update the corresponding assoc_id.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
In this commit, handle the reception of a UE context setup response, in
the case of handover. In that case, store the gNB-DU UE ID and C-RNTI of
the UE at the target DU, and trigger a reconfiguration towards the UE at
the source DU via the callback.
To ensure that the CU-UP's PDCP is SN-aligned with the UE, use
cuup_notify_reestablishment() to reset the bearers with PDCP
reestablishment, which has already been implemented in the last commit.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
This is preparatory work to handle the UE context setup response from
the target DU. There are two cases:
- "Initial" UE context setup response (during connection setup): we need
to inform the CU-UP via an E1 message of the new bearers (GTP tunnel
update)
- F1 handover: we need to inform the CU-UP via an E1 message that there
are DRBs to reestablish
There are two different functions, e1_send_bearer_updates() and
cuup_notify_reestablishment(), to do this. Harmonize the code, before
implementing the actual handover logic in the next commit.
Add a function to trigger an F1 handover, including the corresponding
telnet function implementation. The function looks up source&target DU,
creates a HO context, and reads PDU information to send a UE context
setup request to the target DU towards which to handover.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
Functions get_qos_char_from_qos_flow_param() and
get_qos_characteristics() will be used in rrc_gNB_mobility.c to read PDU
information for handover. Move the definitions to a header to reuse
later.
HandoverPreparationInformation will be used in the follow-up commit to
trigger a handover.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
Robert Schmidt