[E2 agent] RAN Control SM - support for REPORT Style 1 ("RRC Message" and "UE ID" RAN Parameter IDs)
[Spring of Code 2024] contributions
Extended the RAN Control Service Model at E2 Agent to support all RC
REPORT Styles (1 - 5)
Implemented the following RAN Parameter IDs for REPORT Style 1:
1. "RRC Message": any DL-DCCH, and any UL-DCCH
2. "UE ID": as per spec, when the RRC Setup Complete or F1 UE Context
Setup Request detected
Fix inconsistent maxnoofPDUSessions definitions between NGAP and platform constants
There are 2 different definition of maxnoofPDUSessions (as per 3GPP TS
38.413), one in NGAP lib (set to 16) and one in platform_constants.h
(256 as per specs). The NGAP lib definition is removed in this commit
and replaced by the one compliant with the specs.
This is fixing the warning:
In function 'fill_pdu_session_resource_failed_to_setup_item',
inlined from 'rrc_gNB_send_NGAP_INITIAL_CONTEXT_SETUP_RESP' at /openair2/RRC/NR/rrc_gNB_NGAP.c:588:7:
/openair2/RRC/NR/rrc_gNB_NGAP.c:451:12: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
451 | f->cause = cause;
| ~~~~~~~~~^~~~~~~
In file included from /common/utils/ocp_itti/intertask_interface.h:235,
from /openair2/RRC/NR/rrc_gNB_NGAP.h:39,
from /openair2/RRC/NR/rrc_gNB_NGAP.c:31:
/openair2/COMMON/ngap_messages_types.h: In function 'rrc_gNB_send_NGAP_INITIAL_CONTEXT_SETUP_RESP':
/openair2/COMMON/ngap_messages_types.h:546:13: note: at offset [8724, 25769812488] into destination object 'gNB_ue_ngap_id' of size 4
546 | uint32_t gNB_ue_ngap_id;
| ^~~~~~~~~~~~~~
As per spec, UE ID shall be reported when the message event configured by
the Event Trigger Style 1 is set to “RRC Setup Complete" message (UE attach), or
“Xn/NG Handover Request” or “F1 UE Context Setup Request” (Intra gNB Handover).
In OAI RAN, Xn/NG Handover is not yet supported, and therefore not added as the trigger event
in this commit.
Additionally, as the Event Trigger Definition Format 1 is common for both "RRC Message" and "UE ID",
E2 node will report the “RRC Setup Complete" message which the xApp will decode and print.
Co-authored-by: Khanh Toan Pham <khanh.toan.pham@hhi.fraunhofer.de>
Co-authored-by: Shrinish Donde <shrinish.donde@hhi.fraunhofer.de>
Co-authored-by: Theodoros Tsourdinis <theodoros.tsourdinis@sorbonne-universite.fr>
Co-authored-by: Miguel Fuentes <miguel.fuentes@i2cat.net>
Co-authored-by: Teodora Vladic <teodora.vladic@openairinterface.org>
Fixes for E1 and PDU session usage
Fix a number of problems in E1 and PDU session handling:
- For multiple PDU session setup reqs, we send a bearer context setup
each time; fix an assert that was triggered on the second bearer
context setup message
- Add a log for E1 bearer context setup, as already done for
modification and release
- If we get a PDU session setup for an existing PDU session, reject it
as required by the spec [actually, it says to reject individual PDU
sessions; keep it simple for now and reject the entire message, which
might not be correct if there is one new PDU session that does not
exist]
- Add a workaround to handle multiple PDU session setup requests that
come in quick succession for different PDU sessions
Leading to clang error:
/oai-ran/openair2/RRC/NR/rrc_gNB_NGAP.c:1329:37: error: result of comparison of constant 256 with expression of type
'uint8_t' (aka 'unsigned char') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
The value comes from the decoding of: ie->value.choice.PDUSessionResourceToReleaseListRelCmd.list.count
There are 2 different definition of maxnoofPDUSessions (as per 3GPP TS 38.413),
one in NGAP lib (set to 16) and one in platform_constants.h (256 as per specs).
The NGAP lib definition is removed in this commit and replaced by the one
compliant with the specs.
This is fixing the warning:
In function 'fill_pdu_session_resource_failed_to_setup_item',
inlined from 'rrc_gNB_send_NGAP_INITIAL_CONTEXT_SETUP_RESP' at /openair2/RRC/NR/rrc_gNB_NGAP.c:588:7:
/openair2/RRC/NR/rrc_gNB_NGAP.c:451:12: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
451 | f->cause = cause;
| ~~~~~~~~~^~~~~~~
In file included from /common/utils/ocp_itti/intertask_interface.h:235,
from /openair2/RRC/NR/rrc_gNB_NGAP.h:39,
from /openair2/RRC/NR/rrc_gNB_NGAP.c:31:
/openair2/COMMON/ngap_messages_types.h: In function 'rrc_gNB_send_NGAP_INITIAL_CONTEXT_SETUP_RESP':
/openair2/COMMON/ngap_messages_types.h:546:13: note: at offset [8724, 25769812488] into destination object 'gNB_ue_ngap_id' of size 4
546 | uint32_t gNB_ue_ngap_id;
| ^~~~~~~~~~~~~~
This is a hack. With some UEs/CN combinations, PDU session requests
might come in quick succession. Since 38.331 asks us to only have one
reconfiguration at once, we need to delay a second, third, ... PDU
session request until the first has passed, to make one reconfiguration
at a time.
38.413 section 8.2.1.4 says that if PDU session resource setup req
contains an existing PDU session, that one should be reported as failed.
That is rather complicated for us to do; simply reject all PDU sessions
and let the core deal with that.
Use 5G-S-TMSI as UE identity in RRCSetupRequest
This MR includes the following implementation:
- Handle 5G-S-TMSI in RRCSetup:
- Set the ue-Identity to ng-5G-S-TMSI-Part1 in RRCSetupRequest and
- If RRCSetup is received in response to an RRCSetupRequest: set the
ng-5G-S-TMSI-Value to ng-5G-S-TMSI-Part2 in do_RRCSetupComplete
TS 38.331 5.3.3.3 Actions related to transmission of RRCSetupRequest message:
The UE shall set the contents of RRCSetupRequest message as follows:
1> set the ue-Identity as follows:
2> if upper layers provide a 5G-S-TMSI:
3> set the ue-Identity to ng-5G-S-TMSI-Part1;
- Pass 5G-S-TMSI to RRC when NAS receives GUTI in Registration Accept
- NAS extracts GUTI from Registration Accept
- send ITTI indication from NAS to RRC when GUTI is available and store
5G-S-TMSI in RRC instance
- Rework of Initial UE message handling in RRCSetupComplete: simplify code and memory management
- Fix for integrity failure after UE comes back from RRC IDLE
- Other NAS fixes
Note:
- Initial implementation of Initial NAS Message: Service Request -> moved to !3065 (merged)
- Rework of Registration Request added to !3176 (merged)
Closes#772
After a new connection from RRC IDLE, an integrity failure occurs. This
commit is addressing this issue to pass the integrity check.
* Reset ciphering and integrity algorithms when going into RRC IDLE
* Use uplink NAS COUNT in Registration Request for initial KgNB derivation
* Temporarily deriving UP protection keys in Registration Request
* Note: AS SMC handling should be done according to 33.501 §6.8.1.1.2.2
* Use the 5G-S-TMSI stored in RRC to be used as UE identity
* Use 5G-S-TMSI part 1 in RRCSetupRequest encoding (TS 38.331 clause 5.3.3.3)
* Set the ng-5G-S-TMSI-Value in RRCSetupComplete to ng-5G-S-TMSI-Part2 (5.3.3.4 of 3GPP TS 38.331)
* current and only scenario: RRCSetup is received in response to an RRCSetupRequest
* use initialNasMsg to store nas messages buffer and length
* buffer is dynamically allocated in generateRegistrationRequest, so do the
same in NSA and free dynamic allocated data afterwards
* NAS -> RRC: RRC receives an ITTI message with NAS 5GMM indication message
containing the 5G-S-TMSI derived from NAS GUTI
* 5G-S-TMSI is stored in the RRC instance and to be later encoded in the RRCSetup
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
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
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.
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.
francescomani