fix NTN LEO scenarios
- gNB: add support for NTN parameter ta-CommonDrift-r17
- NR UE: fix application of NTN TA information
- NR UE: add command line parameter ntn-initial-time-drift to compensate
time drift during initial sync
- NR UE: fix writeTimestamp inconsistencies
- NR UE: add MAC state UE_RECEIVING_SIB ensuring to start RA only after
successfully receiving SIBs
- rfsimulator: update earth radius for LEO simulation to match UE
position in ue.conf file
- update conf files for NTN LEO scenario
- update description how to run NTN scenarios in RUNMODEM.md
- fix: ta-Common is a round-trip-time, not a one-way delay
- NR UE: simplify calculation of next_tx_slot_and_frame by moving up
assignment of duration_rx_to_tx
- cellbarredNTN indicates notbarred in SIB1 if NTN access is available
- Removed b66 NTN and enabled B254 NTN conf file in CI
- NR UE: RRC layer now explicitly tells MAC layer when the RA procedure
can be started
- move NTN LEO config to band 254 and update doc/RUNMODEM.md
Closes#901
The "writeTimestamp inconsistencies" are coming from the fact that during the actual processing we write `N_TA_offset` samples _and_ `NR_UE_CAPABILITY_SLOT_RX_TO_TX` slots ahead,
but both was not corrently considered in readFrame() and syncInFrame().
Therefore, there was always a warning about a gap in write timestamps as soon the actual processing starts.
The value of ntn_init_time_drift is used at initial sync to compensate for the time drift during initial sync detection.
To perform the initial time and frequency sync, the OAI UE currently takes a snapshot of two frames and then performes PSS correlation, SSS detection and MIB decoding.
Doing this takes much time, several tens of ms. During that time, the DL timing drifts so much, that we immediatedly lose sync again.
Therefore the current OAI UE implementation needs to know the drift rate to compensate for this drift, as we are "blind" while performing the initial sync.
To my undestanding, commercial UEs simply have a faster initial sync, so the DL timing will not drift away too much while performing that initial sync.
Add check on force_local in custom_command CI handling
The force_local flag was introduced earlier in the main CI script in
order to run a CI test locally.
The flag was still missing in the Custom_Command handling, which was
still targeting the node specified in the test configuration file. This
was causing a failure in the tests with custom commands and therefore
limiting the scenarios that could be run locally.
With this commit, if force_local is enabled the node for the
Custom_Command is set to localhost.
Refactor and extend NAS Registration Request
Extended NAS Registration Request generation and encoding according to
8.2.6 of 3GPP TS 24.501. Main topics:
- NAS Registration Type
- NAS KSI
- integrity protection
- NAS container encoding
Improvements:
- Add 5GMM Modes in NAS
- Introduced 5GMM state machine
Fixes:
- add 5GMM Capability IE to Registration Request
- closes#881, #819
Dynamic PDCCH aggregation level
The aggregation level search order for PDCCH candidates is modified:
- the search starts from desired_agg_level_index, which is a value from
0 to 4 proportial to pdcch_cl_adjust.
- pdcch_cl_adjust is a value between 0 and 1 that indicates PDCCH
channel quality by averaging HARQ DTX rate. A value of 0 means perfect
channel, a value o 1 means impaired channel.
Also added configuration option for number of PDCCH candidates per
aggregation level.
The aggregation level search order for PDCCH candidates is modified:
- the search starts from desired_agg_level_index, which is a value from 0 to 4
proportial to pdcch_cl_adjust.
- pdcch_cl_adjust is a value between 0 and 1 that indicates PDCCH channel quality
by averaging HARQ DTX rate. A value of 0 means perfect channel, a value o 1 means
impaired channel.
* The force_local flag was introduced earlier in the main CI script
in order to run a CI test locally. The flag was missing in the
Custom_Command handling, which was still targeting the node specified
in the test configuration file. With this commit, if force_local
is enabled the node for the Custom_Command is set to localhost.
Integration: `2025.w06`
See merge request oai/openairinterface5g!3248
* !3202 Simplify usage of the old segment decoding libraries with the slot coding interface
* !3240 Fix typos in NR_SA_Tutorial_OAI_multi_UE.md
* !3242 Period based phytest bitmap
* !3238 Refactor tun_if.h
* !3000 Improvements for NR dlsim and ulsim
* !3239 Remove inexistant SIMD instruction
* !3246 Deadlock avoidance in rfsimulator
* !3251 nFAPI: make 4-layer on 100MHz work
* !3243 Reset E1 UE contexts after E1 Setup Response
* !3245 Added Support of 35Mhz,45Mhz,70Mhz Bandwidth
* !3219 E1AP enc/dec lib improvements
E1AP enc/dec lib improvements
This MR is including some fixes and improvements for the E1AP library,
focusing mostly on Bearer Context Management:
- struct reorganization: split setup and modification request messages
into distinct structures, ensuring compliance with 3GPP TS 38.463
specifications
- add encoding/decoding sub-functions for different IEs
- improvements to Bearer Context Management: Implemented various
improvements to the E1 Bearer Context Setup Response and Request,
including the adoption of encoding/decoding sub-functions for
different IEs
- use lib functions whenever need (e.g. cp_bearer_context_setup_request
in cucp_cuup_e1ap.c)
- handle optional struct members as pointers
- updated copy/equality check utility functions
EDIT: The MR is also including the changes from !3222 (closed):
> While testing E1 with security enabled for DRBs, it was found that
> data traffic was not functional.
>
> The problem was that security settings were modified in the PDCP
> reestablishment happening when receiving Bearer Context Modification
> Request.
>
> So some restructuring was done.
>
> The actual fix is in 18176297, the others are for support. Basically
> we introduce a boolean to check if the security settings are present in
> Bearer Context Modification Request and we change PDCP security settings
> only if they are.
>
> (Note that in OAI CU security settings are not sent in Bearer Context
> Modification Request, so we could also remove all this, but we need to
> be compatible with other cu-up and/or cu-cp.)
Added Support of 35Mhz,45Mhz,70Mhz Bandwidth
Added Support of 35Mhz,45Mhz,70Mhz Bandwidth for 30Khz Subcarrier
Spacing, Also added 35Mhz, 45Mhz bw for 15Khz Subcarrierspacing.
Referred Spec TS 38.101 v18.6.0 section 5.3.2, table 5.3.2-1
Reset E1 UE contexts after E1 Setup Response
38.463 sec. 8.2.3 says
> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes
> like a Reset procedure would do.
Hence, delete all contexts after reception of E1 Setup Response. This
minimizes a risk of receiving an E1 bearer setup req for an existing UE,
which currently leads to an assert [we trust the CU-CP does not send the
same UE ID twice, as we only "mirror" the existing UE ID]. After this
MR, this is what happens if these entities fail:
- CU-CP fails: all context lost implicitly, upon reconnection, both DU
and CU-UP reset all contexts (like "start from zero")
- DU fails: CU-CP triggers NGAP UE context release request immediately
(radio connection with UE lost), all UE contexts attached to this DU
cleared (like "start from zero" for affected DU)
- CU-UP fails: initially, nothing (UE has no user plane); upon
reconnection of CU-UP, CU-CP triggers NGAP UE context release request
(cause radio connection with UE lost) and sends F1 Reset to DU, all UE
contexts associated to this DU cleared (like "start from zero")
for the last case, a possible improvement could be to use the F1 Reset
message to only clear affected UE conetxts. I chose not to do this,
because this MR is very big now already, and possible "victim" UEs
that were not at that CU-UP will reconnect as well
In Bearer Context Modification Request, the security information
field is needed only if we change the PDCP algorithms/keys. Since we
don't, no need to pass it.
Let's keep the old code, maybe the current understanding of the
specifications is wrong.
If the Bearer Context Modification Request does not contain security
information, the PDCP entity shall keep the currently configured security
settings.
Passing -1 for ciphering_algorithm and integrity_algorithm is the way
to implement this logic.
Check if the IE is memory allocated to deal with presence/absence of this information
element in Bearer Context Modification Request and add encoding/decoding
in the code.
Note that for decoding the integrity settings may be absent, in which
case we consider NIA0 to be used (no integrity protection). To be refined
if needed.
And for encoding, we always encode integrity settings, even if it's NIA0.
May also be refined if needed.
This was not a big problem, but we were advertising wrong
algorithm and deriving keys using this wrong algorithm in case
DRB ciphering and/or integrity was not active. (Say SRBs
are configured with NIA2 but DRBs are configured without
integrity, we would advertise NIA2 and send the integrity
key derived for NIA2, instead of NIA0 for both.)
It was not a problem because in the PDU Session Resource To Setup
item, there is "securityIndication" which we use to effectively
activate/deactivate the ciphering and/or integrity.
But it did not look clean to see a SecurityInformation with
incorrect data when inspecting the message in wireshark.
So let's use the correct values.
We could also not include the SecurityInformation if both ciphering
and integrity are not used, and only include ciphering if integrity
is not used (because integrity settings are optional).
But then if only integrity is used, we still need to include
ciphering, setting algorithm to NEA0 (no ciphering), because
the ciphering settings are always included.
This logic is too complex, let's use the simple one to always
include SecurityInformation with NEA0 and/or NIA0 if ciphering
and/or integrity is not activated.
As in deba3ae066 ("Reset CU-UP E1 UE contexts after E1 Setup
Response"), the CU-CP should reset the E1 UE contexts after E1 Setup
Response. 38.463 sec. 8.2.3 says
> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes like
> a Reset procedure would do.
In the case of CU-CP, this is a bit more complicated. More precisely, we
need to wait for the CU-UP to be available again before informing the DU
about the loss (implemented via an F1 Reset message), because otherwise,
the UE might reconnect immediately, before the CU-UP is online again.
Hence, on connection loss, we mark affected UEs (by setting their E1
association ID to 0); as long as the CU-UP does not connect, nothing
will happen (but UEs don't have user plane). Upon CU-UP connecting
again, we request release of the UEs via NGAP (similarly to what is done
if the DU goes offline, see invalidate_du_connections()), free the UE
contexts locally, and send an F1 Reset message to the DU, because
38.473 sec 8.2.1.2.1 says
> a failure at the gNB-CU [...] has resulted in the loss of some or
> all transaction reference information [...] a RESET message shall be
> sent to the gNB-DU.
The core should accept and send an NGAP release command message; since
no UE contexts are to be found (already deleted), the CU-CP will just
send a release complete (together with some warnings).
It might be possible to more gracefully handle the situation (e.g., as
described in 38.401 section 8.9.5 "Change of gNB-CU-UP"), but
- we lack the PDCP SN exchange
- the current procedure has the advantage of being equivalent to
"restart of the entire gNB", with less downtown.
The next commit will use rrc_remove_ue() to delete a CU(-CP+-UP)
context. However, we don't send NGAP UE context release at that moment
(we will instead *request* the release); more generally, it's not clear
that every user of rrc_remove_ue() wants to actually send this message.
Hence, refactor the code by separately calling
rrc_gNB_send_NGAP_UE_CONTEXT_RELEASE_COMPLETE() where appropriate.
Robert Schmidt