On NGSetupFailure, before moving, we might have
[NGAP] Received NG setup failure for AMF... please check your parameters
[NGAP] Received NGSetupResponse from AMF
In the Initial Context Setup message, the NGAP forwards the AMF UE ID,
but not in the DL NAS Message, although 38.413 says, in $8.3.1.2 either
> The NG-RAN node shall use the AMF UE NGAP ID IE and RAN UE NGAP ID IE
> received in the INITIAL CONTEXT SETUP REQUEST message as identification
> of the logical connection
or in $8.6.2.2
> The NG-RAN node shall use the AMF UE NGAP ID IE and RAN UE NGAP ID IE
> received in the DOWNLINK NAS TRANSPORT message as identification of the
> logical connection
So forward in both cases for harmonization.
Refactor key derivation logic to properly handle Next Hop (NH) chain
synchronization according to 3GPP TS 33.501 specifications for both
RRC Reestablishment and Master Key Update procedures.
Changes in rrc_gNB.c:
- Clarify key derivation in rrc_gNB_generate_RRCReestablishment by
explicitly selecting base key (NH or KgNB) based on nh_ncc value
- Add comment explaining vertical vs horizontal derivation logic
Changes in rrc_UE.c:
- Add nr_sync_nh_chain(): Common helper to synchronize NH parameter
chain per TS 33.501 Annex A.10, supporting both Master Key Update
and RRC Reestablishment procedures
- Add nr_derive_kgnb_horizontal(): Derive KNG-RAN* from current KgNB
when NCC values match (horizontal derivation per TS 33.501 A.11/A.12)
- Add nr_derive_kgnb_vertical(): Derive KNG-RAN* from synchronized NH
after NH chain sync (vertical derivation per TS 33.501 A.11/A.12)
- Add nr_update_kgnb_from_ncc(): Unified function implementing TS 33.501
6.9.2.3.4 logic for updating KgNB based on received nextHopChainingCount
- Refactor as_security_key_update(): Use new nr_update_kgnb_from_ncc()
helper function for cleaner, more maintainable code
- Fix nr_rrc_ue_process_rrcReestablishment(): Properly handle received
nextHopChainingCount and update KgNB using unified helper function
- Add debug logging for key derivation process
Key NAS deriver utils:
- update derive_kgnb documentation and protect input keys with const attribute
The PDUSessionResourceReleaseResponse message was missing the mandatory
pDUSessionResourceReleaseResponseTransfer IE in each released PDU session item. This caused Open5GS to send an error indication.
Changes:
- Add encode_ngap_pdusession_release_response_transfer() function to
properly encode the transfer structure (empty since Secondary RAT Usage
Information is optional and not used, per 9.3.4.21)
- Always include the mandatory PDUSessionResourceReleasedListRelRes IE
- Always encode the pDUSessionResourceReleaseResponseTransfer for each
PDU session item
- Fix Release Command handler to decode and log Cause from command transfer:
instead of incorrectly copying command data to response: the 2 transfer
IEs in the Command and the Response messages are different and should
not be mixed
- Split Command/Response struct type definitions
- Add missing includes
1) Remove UE Context Release Response code: there is no
such thing in the specs, it is either UE Context Release Request
(NG-RAN node initiated) or UE Context Release (AMF initiated)
(3GPP TS 38.413). The former message has only the request, no
response is defined by the specs. The code in the stack had no
purpose at all and was removed.
2) The UE Context Release Request message only contains a PDU
Session Resource List (optional) of PDU Session IDs, therefore
the use of pdusession_release_t was wrong and was refactored
PDU Session Release
This MR implements end-to-end PDU Session Release functionality
according to 3GPP TS 38.413 and TS 38.331 specifications.
Reason for Change Previous implementation had incomplete and wrongly
places tunnel cleanup during PDU session release. UP cleanup shall be
done at CUUP, RRCReconfiguration shall be sent after retrieval of
updated CellGroupConfig from the DU. This implies F1 and E1 exchanges
during PDU session release procedure.
Major Changes:
1. RRC PDU Session Release: DRBs and PDU session teardown in NGAP PDU
Session Release Response callback
- Helper Functions: Introduced rm_pduSession,
find_drb_by_pdusession_id and rm_drbs() helpers to locate and clean
up DRBs linked to a specific PDU session
- Targeted Cleanup: RRC PDU Session and per-session DRB removal in
rrc_gNB_send_NGAP_PDUSESSION_RELEASE_RESPONSE()
- Status Cleanup: Removed unused PDU_SESSION_STATUS_RELEASED status
2. RRC PDU Session Release: Refactor
rrc_gNB_process_NGAP_PDUSESSION_RELEASE_COMMAND
- Any PDU session in the pdusession_release_params list that is
present in the RRC list can be set to release, regardless of its
status
- Function Signature Update: Updated function signature and other
minor changes
- Response Handling: rrc_gNB_send_NGAP_PDUSESSION_RELEASE_RESPONSE is
sent upon completion of RRCReconfiguration
3. RRC PDU Session Release: add missing procedures E1AP Integration:
- Populates E1AP Bearer Modification for each to be released session
- PDCP Enhancement: Added nr_pdcp_release_drbs() to remove all DRBs
linked to a given PDU session in CUUP
- GTP-U Cleanup: GTP tunnel teardown handled in CUUP
e1_bearer_context_modif() using correct F1 or N3 GTP instance
4. NR PDCP/GTP:
- Enhanced Tunnel Deletion Logic: Separate handling for N3 tunnels (1
per PDU session) and F1-U tunnels (1 per DRB)
- New PDCP API Function: Added nr_pdcp_get_drb_ids_for_pdusession()
function to retrieve all DRB IDs associated with a specific PDU
session
5. RRC PDU Session Release: F1AP-based UE Context Modification:
- Replaced direct RRC message transfer with F1AP UE Context
Modification Request for proper retrieval from DU
- Cell Group Configuration: handling of updated CellGroupConfig from
DU ensures DRB release at CU
6. Docs and testing:
- Added PDU session add/remove test cases to 25 PRB RFSIM pipeline
- Documentation: Added PDU Session Release sequence diagram
- Telnet Commands: Added ci command to trigger NGAP PDU Session
Release and ciUE command to trigger establishment of a new PDU
Session
7. Additional fixes:
- UE RLC Management: ensure release of RLC entities
- Unify NG delay control before calling the RRC NGAP handler, for both
Setup and Release
8. Code Cleanup: Cleaned up unused GTP teardown functions.
Closes#867
The partial-tunnel deletion API was buggy and redundant:
* e.g. It erased entries from globGtp.te2ue_mapping but never erases
the corresponding entries from inst->ue2te_mapping[ue].bearers
All current use cases are already covered by:
* newGtpuDeleteOneTunnel() for targeted deletion
* newGtpuDeleteAllTunnels() for full cleanup
Call sites should explicitly loop over newGtpuDeleteOneTunnel()
if multiple tunnels need removal.
This commit implements proper PDU Session Release handling across
RRC, PDCP, F1AP, E1AP to ensure clean resource cleanup when
a PDU session is terminated.
Key changes:
NGAP:
In `rrc_gNB_process_NGAP_PDUSESSION_RELEASE_COMMAND()`:
* Populates E1AP Bearer Modification for each released session
* If a CU-UP is connected, triggers `bearer_context_mod()` for PDU teardown
PDCP:
* Added `nr_pdcp_release_drbs()` to remove all DRBs linked to a given PDU session
* Called from `e1_bearer_context_modif()` for correct clean-up during session release
F1AP UE Context Modification:
Replace direct RRC message transfer with F1AP UE Context Modification Request
to properly handle PDU session release according to 3GPP TS 38.331.
3GPP TS 38.331 `5.3.5.6.4 DRB release` says: whether or not the RLC and MAC entities associated
with a PDCP entity are reset or released is determined by the CellGroupConfig. Thus,
updated CellGroupConfig needs to be received by the UE. This has to be retrieved by CUCP
from the DU. Therefore:
After receiving an NGAP_PDUSESSION_RELEASE_COMMAND, the CUCP shall:
1) forward (store for later) the NAS PDU to the UE, if present as per 3GPP TS 38.413, and
2) send a UE Context Modification to the DU with the list of DRBs to release
and the RRC container (RRCReconfiguration with NAS PDU)
After reception of UE Context Modification Response, the list of drbs to release
is prepared based on PDU session status PDU_SESSION_STATUS_TORELEASE
in rrc_gNB_generate_dedicatedRRCReconfiguration and then encoded
in drb_ToReleaseList for a new RRCReconfiguration with the new cellGroupConfig.
Key changes:
* rrc_gNB_generate_dedicatedRRCReconfiguration_release() now uses F1AP UE Context
Modification Request instead of direct RRC transfer
* Only DRBs to be released are now added to the list.
* The ASN.1 memory allocation is entirely done in build_RRCReconfiguration_IEs
* No longer needed to store ASN1 struct in UE context
GTP-U:
* Previous implementation had incomplete tunnel cleanup during PDU session release
- Missing distinction between N3 (PDU session level) and F1-U (DRB level) tunnels
- Lack of proper DRB identification for F1-U tunnel deletion
Major Changes:
* GTP tunnel teardown now handled in `e1_bearer_context_modif()` using the correct
F1 or N3 GTP instance (`newGtpuDeleteOneTunnel()`)
* Enhanced Tunnel Deletion Logic (cucp_cuup_handler.c):
- Separate handling for N3 tunnels (1 per PDU session) and F1-U tunnels (1 per DRB)
- Added proper DRB identification for F1-U tunnel cleanup
- Improved error handling with detailed logging for each tunnel deletion
- Enhanced logging to distinguish between N3 and F1-U tunnel operations
* New PDCP API Function (nr_pdcp_oai_api.c/h):
- Added nr_pdcp_get_drb_ids_for_pdusession() function
- Enables retrieval of all DRB IDs associated with a specific PDU session
- Supports proper F1-U tunnel cleanup by providing DRB identifiers in CUUP
* Enhanced GTP Interface (gtp_itf.cpp/h):
- Modified newGtpuDeleteOneTunnel() to accept tunnel_type parameter
- Improved logging to distinguish between PDU session and DRB tunnel types
- Better error messages for tunnel deletion failures
- Enhanced debugging information for remaining tunnels
Clean-up:
* Ensured xid tracking works consistently between PDU Session Establishment (with NAS PDU)
and dedicated RRCReconfiguration
* Add function to release GTP-U tunnel in Bearer Context Modification Request handler
* Do not send rrc_gNB_send_NGAP_PDUSESSION_RELEASE_RESPONSE when no PDU session are to
be released: it is sent upon completion of the RRCReconfiguration and needs to contain
released PDU Sessions (mandatory IE), therefore it is no necessary to send it in case
there is no PDU session to release.
Related to #867
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
[NGAP] Fix incorrect AMF Set ID type (uint8 → uint16) causing AMF lookup failure
This PR fixes issue #1012 , a data type issue related to the AMF Set ID used
during UE RRC reestablishment. The AMF Set ID was mistakenly declared as uint8_t
instead of uint16_t, even though it is a 10-bit field as specified in 3GPP TS
23.003 section 2.10.1. As a result, AMF Set IDs greater than 255 were truncated,
leading to failed AMF lookups and the following warning: No matching AMF found
for PLMN (MCC=%03d MNC=%0*d) and AMF SetID=%u.
Verified reestablishment succeeds with AMF Set IDs >255.
Problem:
- GTP-U logs showed negative TEID values (e.g., -1943516315) due to signed/unsigned
conversion. Due to wrong conversion from uint32_t to int and overflow caused negative values.
- TEID values were inconsistently formatted across different log statements, due to
mixed use of %d, %u, %x formats for TEID logging. Made debugging and troubleshooting difficult
Changes:
1. Fixed signed/unsigned conversion bug: use teid_t. Prevents overflow when TEID values exceed int range.
2. Standardized TEID logging format: all TEID values now use '0x%x' hexadecimal format.
Consistent 'TEID' capitalization throughout
- Corrected AMF Set ID data type in ngap_gNB_nnsf_select_amf_by_amf_setid() from uint8_t to uint16_t.
- AMF Set ID is a 10-bit field as per 3GPP TS 38.413 §9.3.3.12.
- The incorrect data type caused truncation for AMF Set IDs >255, leading to lookup failures during RRC reestablishment.
- Verified successful reestablishment with large AMF Set IDs after the fix.
Reason for fix: AMF lookup using AMF Set ID was failing because the 10-bit AMF Set ID was truncated to 8 bits.
Closes#1012
Stop the receive thread before closing the socket, which avoids an error
message when stopping the GTP softmodem:
[GTPU] [91] Recvfrom failed (Bad file descriptor)
[GTPU] exiting thread
On error, exit the GTP thread after printing a diagnostic message. This
avoids also an error flagged by address sanitizer for use-after-free.
[GTPU] [91] Recvfrom failed (Bad file descriptor)
=================================================================
==285377==ERROR: AddressSanitizer: heap-use-after-free on address 0x7cd7b7fe5590 at pc 0x0000006a9e18 bp 0x7b97ad4e1d50 sp 0x7b97ad4e1d48
READ of size 4 at 0x7cd7b7fe5590 thread T8
=================================================================
==285377==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x0000006a9e17 in gtpv1uReceiver /home/richie/oai/openair3/ocp-gtpu/gtp_itf.cpp:1346
#1 0x7f97b9a28ee5 in asan_thread_start(void*) (/lib64/libasan.so.8+0x28ee5) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
#2 0x7f97b8e7ff53 in start_thread (/lib64/libc.so.6+0x71f53) (BuildId: 48c4b9b1efb1df15da8e787f489128bf31893317)
#3 0x7f97b8f0332b in __clone3 (/lib64/libc.so.6+0xf532b) (BuildId: 48c4b9b1efb1df15da8e787f489128bf31893317)
#0 0x7f97b9ae60cb in memalign (/lib64/libasan.so.8+0xe60cb) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
#1 0x000000471039 in newNotifiedFIFO_elt /home/richie/oai/common/utils/threadPool/notified_fifo.h:75
#2 0x000000471039 in tx_func /home/richie/oai/executables/nr-gnb.c:107
#3 0x000000471039 in L1_tx_thread /home/richie/oai/executables/nr-gnb.c:167
#4 0x7f97b9a28ee5 in asan_thread_start(void*) (/lib64/libasan.so.8+0x28ee5) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
0x7cd7b7fe5590 is located 336 bytes inside of 400-byte region [0x7cd7b7fe5440,0x7cd7b7fe55d0)
freed by thread T0 here:
SUMMARY: AddressSanitizer: 160 byte(s) leaked in 1 allocation(s).
Refactor SDAP adaptation work for QoS
This MR is an adaptation of the code introduced in !2703.
The goal is a cleanup and functional refactor of the SDAP/PDCP
integration, that is:
- centralize SDAP configuration logic
- simplify entity creation
- improve robustness of role-based SDAP handling
- prepare the codebase for clean support of DRB reconfiguration and
teardown flows
More concretely:
1. New sdap_config_t and get_sdap_Config()
- Introduced an internal struct sdap_config_t to abstract SDAP config
input
- Centralized SDAP config parsing into new get_sdap_Config() function
that translates ASN.1 NR_SDAP_Config into this internal
representation. This is called during RRC triggered
(re)configuration procedures.
- Enable mapping of number of QoS flows > 1
2. Unified role handling with bitmasks
- Added a bitmask-based entity_role field to track SDAP directions:
SDAP_UL_RX, SDAP_UL_TX, SDAP_DL_RX, SDAP_DL_TX: header presence was
determined by simple direction (UE vs gNB) and individual
is_sdap_rx/tx() checks, however nr_sdap_rx_entity behaves
differently depending on the direction of the RX entity (DL/UL),
therefore this change can help enable a more accurate SDAP header
handling across directions and node types.
- Replaces old helpers is_sdap_rx() / is_sdap_tx() with internal
checks against the role bitfield
- QFI-to-DRB mapping is now annotated with direction for both data and
control PDUs
3. Simplified DRB and SDAP setup
- add_drb() in PDCP API now delegates SDAP config processing cleanly
- new_nr_sdap_entity() is used consistently to register a fresh SDAP
context for the UE and PDU session.
- Also, re-use and reconfigure existing SDAP entity if already
exists.
- logging has been added to trace mapped QFIs from RRC and resulting
table entries
4. Improved QFI-to-DRB management
- Refactored nr_sdap_qfi2drb_map_update() to register QFIs based on
parsed config
- Ensures control PDUs are correctly routed even after reconfiguration
- Extended nr_sdap_ue_qfi2drb_config: perform UL QoS flow to DRB
mapping configuration for a SDAP entity has already been established
according to TS 37.324, 5.3 QoS flow to DRB Mapping, 5.3.1
Configuration Procedures. Handle both UL QoS Flows mapping rules to
add and to remove. QFIs will now be properly unmapped if specified
via mappedQoS_FlowsToRelease, this might prevent stale QFI mappings
from being used incorrectly.
- nr_sdap_qfi2drb() and sdap_map_ctrl_pdu() now strictly fallback to
default_drb only if a QFI mapping is missing. Missing default DRB
now triggers LOG_E() (previously silent or misrouted to DRB 0).
5. Other cleanup
- Remove dependencies from legacy rb_id_t
- Remove rb_id parameter from nr_sdap_tx_entity() function signature
- Update tx_entity function pointer
- Remove rb_id parameter from sdap_data_req() function signature
- Remove unused rb_id variable from sdap_tun_read_thread
The rb_id parameter was redundant since SDAP determines DRB ID
from QFI mapping via entity->qfi2drb_map(entity, qfi). This
simplifies the interface.
This commit is removing the storage of selected PLMN in NGAP UE context.
We store the Serving PLMN in the RRC UE context instead.
The Selected PLMN is the PLMN that the UE chose (or was directed to) for registration
and it is sent in the RRCSetupComplete. This is different from the selected
PLMN mentioned in the NG INITIAL UE MESSAGE for network sharing.
Selected PLMN: determines which core network and AMF the UE is registered with
GUAMI = Identifies the serving AMF and includes the PLMN of that AMF
Serving PLMN: the PLMN that is currently serving the UE (e.g. contained in GUAMI)
The AMF’s PLMN may match the selected PLMN, or not (especially in network sharing or roaming).
Regardless, the UE always have a Serving PLMN.
Initial UE message does not have a TAI IE per se, but TAI is a mandatory
member of the mandatory UserLocationInformation CHOICE.
NR CGI is also mandatory and carried inside UserLocationInformation:
in network sharing, the PLMN ID in TAI takes on additional
significance: RAN is shared but CN are different, so in this case PLMN in TAI is
needed for the AMF route the message to the correct operator’s core.
If network sharing applies (e.g., shared RAN between PLMN-A and PLMN-B):
the UE or network may select PLMN-B instead, and that PLMN identity
is included in the Initial UE Message’s TAI IE.
Conclusion:
1) UE always sends the selected PLMN during the registration,
regardless of whether it is shared or not.
2) Selected PLMN Identity is an actual IE sent in the RRCSetupComplete
while in NGAP there's no Selected PLMN Identity IE, only PLMN Identity
IEs in both TAI and NR CGI. It is a subtle difference.
3) The serving PLMN of the UE needs to be stored in RRC UE Context for
later use in NAS procedures. e.g. at initial registration it matches
the Selected PLMN
4) No need to store PLMN in NGAP UE Context, params are passed by RRC
5) TAI and NR CGI, which contain the PLMN identity, are mandatory in
UserLocationInformation IE CHOICE, and should reflect current status
Changes
- Initial UE Message: pass UE-selected PLMN and NR cell id from RRC to NGAP
- Uplink NAS Transport: use PLMN, TAC, and cell id provided by the message;
- Build NR CGI from gNB ID + cell id
- Store UE-selected PLMN only in RRC UE context at NAS_FIRST_REQ for later
Uplink NAS, stop storing PLMN in NGAP UE context
Make all targets compile
This MR enables us to compile all targets, and does that in one CI test. This
closes#726. Now, this should work:
cd ~/openairinterface5g
mkdir build && cd build
cmake .. -GNinja && ninja
To achieve this, I did the following:
- some targets have been fixed (warnings, errors)
- some targets have been removed when they did not seem to serve a good purpose
(e.g., an almost empty test)
- some targets have been commented (e.g., LTE simulators, some unitary tests)
which we maybe want to revive in the future
- some targets built when just building with ninja, but not all. For instance,
telnetsrv_enb would typically build, but it was missing a dependency. Doing
cmake .. -GNinja && ninja telnetsrv_enb would show this (in develop)
To help with the last bullet point, there is a script compile_targets.sh that
can compile targets independently (and in parallel, to not wait for ages) to
show that targets compile properly compile-targets.patch.
In almost all cases, the problem is that a specific module uses the logging
module, which depends on T, which needs to dynamically create headers. The way
to do this is to have a dependency, and many targets use generate_T or {T_LIB}
({} intentional: T might be absent, so then it evaluates to nothing). However,
not all do this, and those that depend on T actually don't depend on T, but on
the logging module, which in turn depends on T. So in many places, a simple
dependency onto log_headers fixes this problem, and generate_T or {T_LIB}
simplifies the dependency (but not always). The commits should have more info.
Note that at least the targets in FlexRIC do not all compile, at least in the
configuration that we use in docker/Dockerfile.build.ubuntu. So for the latter,
we cannot build with a simple ninja, but FlexRIC seems to be the only one that
does not compile. Since FlexRIC is a separate repository, that needs to be
addressed in the corresponding repository.
- ngap_gNB_handover_notify: Fix misleading error message from 'Failed to encode'
to 'Failed to find UE context' for better clarity
- ngap_gNB_handle_ul_ran_status_transfer: Standardize error message format
from 'Could not find' to 'Failed to find' for consistency across functions
This ensures consistent and accurate error reporting across all NGAP handover functions.
- Update encoder functions in ngap_gNB_mobility_management.c to use calloc_or_fail
- Provides zero-initialized memory and consistent error handling
- Prevents uninitialized fields and improves memory safety
Also:
- Update NG Setup Request to use calloc_or_fail
Move UE context creation and storage to after successful PDU encoding
to prevent memory leaks if encoding fails. Also add proper PDU cleanup
when AMF fetch fails and use consistent NULL check style.
This ensures UE context is only stored when the operation is guaranteed
to succeed, improving error handling and memory management.
In the current memory management the caller wasn't responsible for freeing
memory they allocate. The ngap_gNB_encode_pdu function was taking ownership
of PDU contents by calling ASN_STRUCT_FREE_CONTENTS_ONLY, while callers
also expected to manage the same memory. This created unclear ownership semantics and
potential double-free bugs.
- Remove ASN_STRUCT_FREE_CONTENTS_ONLY from ngap_gNB_encode_pdu to prevent double-free
- Remove unnecessary ASN_STRUCT_FREE when encode function returns NULL
- Add proper ASN_STRUCT_FREE cleanup for heap-allocated PDUs in ngap_gNB.c functions
- Add ASN_STRUCT_FREE_CONTENTS_ONLY cleanup for stack-allocated PDUs in NAS and context management functions
- Ensure consistent memory cleanup patterns across all NGAP encoder callers
- Fix potential memory leaks in all ngap_gNB_encode_pdu call sites
This prevents double-free bugs and ensures proper cleanup of ASN.1 structures
in both heap and stack allocation scenarios.
These libraries depend on the logging module, so add the right
dependency log_headers. Indirectly, this will fulfill the condition of
T. I consider the prior usage of generate_T or {T_LIB} incorrect,
because basically none of these libraries actually, actively use T, but
rather only the logging module, which pulls in T. The dependency of
log_headers will also take care of generating and including T headers,
which is a dependency of the logging module.
For conf2uedata and related, fulfill the dependency
through conf2uedata_lib (on which the rest depends).
We don't use JER. This avoids compilation problems, such as:
/usr/bin/ld: openair3/NRPPA/MESSAGES/libasn1_nrppa.a(INTEGER_jer.c.o): in function `INTEGER_decode_jer':
tmp.MtrwVDhQqY/openair3/NRPPA/MESSAGES/INTEGER_jer.c:186:(.text+0x5b8): undefined reference to `jer_decode_primitive
- Replace error handling for impossible ID mismatches with DevAssert statements
- If ngap_get_ue_context() succeeds, returned context must have matching NGAP gNB UE IDs by definition
- This catches potential bugs in the lookup function immediately
- Affects: handover_required, handover_notify, handover_cancel, ul_ran_status_transfer
These checks were logically impossible since we looked up the context using
the same IDs we were then checking for mismatch.
* There is no IE corresponding to PDU sessions failed to release
in the PDU SESSION RESOURCE RELEASE RESPONSE message. This was removed
and the corresponding code was refactored and cleaned up.
* In the Release Command handler, only established PDU Session are set to be
released. The Response message is filled accordingly.
- Move QoS-related enums and structures from ngap_messages_types.h to 5g_platform_types.h
- Replace ngap_* QoS types with generic qos_* types for better reusability
- Update field names from allocation_retention_priority to arp for consistency
- Update all references across RRC and NGAP modules to use new type names
- Remove duplicate QoS type definitions from NGAP-specific header
This improves code organization by centralizing QoS parameter definitions
in a common platform types header and eliminates NGAP-specific naming
in favor of more generic, reusable type definitions.
Previously, the RRC layer was incorrectly allocating stack memory for the ho_required_transfer field and passing it to NGAP, however it was not used. The IE is mandatory but contains only 1 optional IE, therefore is encoded in the NG message with empty content.
Changes:
- Remove unnecessary ho_required_transfer field from pdusession_resource_t definition, the IE is encoded anyway with empty content. If Direct Forwarding Path Availability is needed at any stage in the future it can be added to pdusession_resource_t and filled in RRC.
- Add clarifying comment about empty HandoverRequiredTransfer structure
This commit completes the NGAP Mobility Management procedure for N2 handover.
Upon failure on source gNB the Handover Cancel message is sent to the AMF which
in return responds with an ack.
According to 4.9.1.3.3 of 3GPP TS 23.502:
> 2a. - 2c. The S-RAN sends the Uplink RAN Status Transfer message to the S-AMF,
> as specified in TS 36.300 [46] and TS 38.300 [9]. The S-RAN may omit sending
> this message if none of the radio bearers of the UE shall be treated with PDCP status preservation.
TS 38.300 says:
> For DRBs not configured with DAPS, the source gNB sends the SN STATUS TRANSFER message to the target
> gNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs for
> which PDCP status preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at
> least the PDCP SN of the first missing UL PDCP SDU and may include a bit map of the receive status of the out
> of sequence UL PDCP SDUs that the UE needs to retransmit in the target cell, if any. The downlink PDCP SN
> transmitter status indicates the next PDCP SN that the target gNB shall assign to new PDCP SDUs, not having a
> PDCP SN yet.
i.e., for DRBs for which PDCP status preservation applies (i.e. for RLC AM), which is is our case.
This commit introduces full support for NG-RAN Status Transfer message handling
(TS 38.413 §9.2.3.13-14) in CU. It enables correct state transfer of PDCP COUNT
values (SN + HFN) during mobility or recovery scenarios.
Summary of changes - NGAP:
* Added encoding/decoding support for UL/DL RAN Status Transfer message
* Defined structures for: ngap_drb_count_value_t, ngap_drb_status_t,
ngap_ran_status_container_t, ngap_ran_status_transfer_t
This commit introduces the NG Mobility Management Procedure known as
Handover Notification. The outbound message is sent by the target NG-RAN
and is known as Handover Notify. The procedure is used to indicate to
the AMF that the UE has arrived to the target cell and the NG-based
handover has been successfully completed
* after RRCReconfiguration complete, in the N2 callback for HO success
* add NGAP encoder for the message
* RRC callback to trigger Handover Notify message
Co-authored-by: batuhan duyuler <batuhan.duyuler@firecell.io>
* add NG Handover Command message decoder
* process in RRC: encode RRCReconfiguration message
from the received HandoverCommandMessage
* trigger RRCReconfiguration for handover
Co-authored-by: batuhan duyuler <batuhan.duyuler@firecell.io>
This commit completes the NG Mobility Management Procedure known as
Handover Resource Allocation. The outbound message is sent by the
target NG-RAN and is known as Handover Request Acknowledge.
Major changes:
* add RRC callback to trigger the generation of NG Handover
Request Acknowledge on the target NG-RAN
* add NG Handover Request Acknowledge encoder
Co-authored-by: batuhan duyuler <batuhan.duyuler@firecell.io>
This commit introduces the NG Mobility Management Procedure known as
Handover Resource Allocation. The inbound message is sent by the AMF
and is known as Handover Request.
Major changes:
(0) Add Handover Resource Allocation initiating message decoding
* add case for NGAP initiating message and unsuccessful message decoding
(1) handle Handover Request on the target NG-RAN
(2) decode NG Handover Request message
(3) process payload, e.g. create UE context,
store IDs, set UP security and trigger bearer setup
Co-authored-by: batuhan duyuler <batuhan.duyuler@firecell.io>
This message is sent from the Target NG-RAN to the AMF.
The commit introduces:
* NGAP encoding function
* N2 callback for the target gNB
* handle the failure in RRC, inform NGAP
* send NGAP message to AMF via SCTP
Note: UE context in NGAP is fetched from the amf_ue_ngap_id
Co-authored-by: batuhan duyuler <batuhan.duyuler@firecell.io>
This commit introduces the NG Mobility Management Procedure known as
Handover Preparation. The outbound message is sent by the source NG-RAN
and is known as Handover Required.
* introduce NGAP library for Mobility Management
* introduce NGAP IEs encoder functions for Handover Required and relevant common IEs
* handle RRC trigger in NGAP and Send NGAP Handover Required to the AMF
Co-authored-by: batuhan duyuler <batuhan.duyuler@firecell.io>
Robert Schmidt