NR UE: calculate TA based on SIB19 information in NTN mode, if autonomous TA is not enabled
To achieve the goal, the hyper frame number (HFN) is introduced at the NR UE
PHY, MAC and RRC layers.
Besides this, we also implemented an orbit propagation to improve the accuracy
of N_UE_TA_adj, and a fix to keep the N_TA from RAR and MAC CE.
Fixes#981
Fixes for BWP switching
This MR fixes some issues when performing BWP switching via
reconfiguration. It also adds a CI test for BWP switching. # Please
enter a commit message to explain why this merge is necessary,
In all cases (CFRA in SA for HO, or CFRA in NSA/do-ra for access), the
UE has the full configuration already. We can therefore directly switch
to a dedicated search space, as it is already known to the UE.
... so if we want to have 1 BWP configured at any given time we need to
reconfigure BWP 1 every time. This means that since the gNB has more
than 1 BWPs (for use for different UEs), that there is a "gNB BWP ID"
(as used by the gNB), which can be any BWP ID X, and one "UE BWP ID",
which is always 1. This commit implements this distinction.
Return from triggering reconfiguration with BWP switch if BWP is the
same as before the switch, and add check to verify if BWP triggered by
switch command exists
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
CFRA: mark RA complete when sending Msg2
The current contention-free random access forces a "Msg3" (which does
not exist in CFRA) to be received by a UE. Sometimes, this "Msg3" is not
received (for whatever reason), and the MAC declare that RA failed.
This is problematic, as the spec says that RA is complete once Msg2 is
received by the UE. Since the gNB cannot know when this is, simply mark
it as complete once we sent Msg2.
We still send Msg3 in CFRA, which is explained further in the commits.
Also, improve logging and stabilize an RFsim test by reducing sl_ahead.
Since the parent commit, CFRA is inconditionally marked complete on Msg3
reception (successful or not). This works because the current
implementation still sends a UL grant (see parent commit for details).
In this commit, handle Msg3 if received in CFRA (notably for TA and
power). Note that since we declare RA complete, UE->ra does not exist
anymore, and so an intermediate variable is introduced to capture the
CFRA flag. The code should be such that if we are in CFRA, we never
access any UE->ra variable.
The current contention-free random access forces a "Msg3" (which does
not exist in CFRA) to be received by a UE. Sometimes, this "Msg3" is not
received (for whatever reason), and the MAC declare that RA failed.
This is problematic, as the spec says that RA is complete once Msg2 is
received by the UE. To avoid this, inconditionally mark RA as complete
as soon as we receive an indication of Msg3 (DTX or not).
Note that after this change, we still send a UL grant in Msg2. This is
because 38.321 §5.1.4 is not clear to me whether we should send UL grant
(it does not explicitly exclude it), and it says
> 3> if the Random Access Response includes a MAC subPDU with RAPID only:
> [...]
> 4> indicate the reception of an acknowledgement for SI request to
> upper layers.
which is NOT the case (but then I don't know/think we can have CFRA for
SI request?). Since it also works with COTS UE, I leave Msg3 for the
moment.
The reason to not directly mark RA as complete when sending Msg2 is
because of possible retransmissions in do-ra mode. In fact, in do-ra,
there might already be data awaiting. In that case, the DLSCH scheduler
schedules data _in the same slot as Msg2_, which the UE does not decode,
leading to retransmissions.
Implementation of STOP exchange
This implements the STOP.request/indication for all 3 transport mechanisms, the
VNF will send the STOP.request to the PNF, indicating it will disconnect, and
await a STOP.indication from the PNF
The WLS VNF is reworked to be able to start before the PNF, by calling call
rte_eal_init and rte_dev_probe to determine if dpdk has been initialized
properly, before calling rte_eal_init in the intended process when it is
appropriate to do so
Fix reestablishment after handover
- fix reestablishment by not re-creating LCIDs with priority set to 0 (see first
commit for more details)
- cleanup code
The idea is to reestablish all RLC entities (it's a new UE, and we set
reestablishRLC on all bearerrs), so we should reestablish all RLC
entities on gNB side as well, without any additional loop.
Co-authored-by: Roberto Magueta <rmagueta@allbesmart.pt>
Move the file process_addmod_bearers_cellGroupConfig() to the file where
it is used. Correctly set priorities as requested in RLC bearer
configuration.
In all cases (NSA, HO), we create LCIDs before the UE triggers random
access. Hence, process_addmod_bearers_cellGroupConfig() is not
necessary, as it just tries to recreate an LCID.
Furthermore, it includes a bug, as this function does set a wrong
priority (0), so the sorting of LCIDs is not correct. This in turn
creates problems with reestablishment, as LCID 1/SRB1 is not in the
first position, making reestablishment fail (where we assume LCID 1 be
in first position).
The actual bug of setting priorities is fixed in the next commit.
Fix MIB encoding in F1SetupRequest: use encode_MIB_NR_setup instead of encode_MIB_NR
- The DU was using encode_MIB_NR() while constructing the GNB-DU System
Information for the F1SetupRequest.
- encode_MIB_NR() encodes a full NR_BCCH_BCH_Message_t, causing the MIB to be
wrapped in a BCH container.
- This results in incorrect MIB values in the F1SetupRequest PCAP (e.g., wrong
systemFrameNumber, SCS, DMRS position, cellBarred).
- According to 3GPP TS 38.473, the MIB carried in F1AP must be encoded as a raw
NR_MIB_t.
- The correct function encode_MIB_NR_setup() encodes MIB in the required format
but was not used.
- This patch replaces encode_MIB_NR() with encode_MIB_NR_setup() to ensure correct
and standards-compliant MIB encoding in the F1SetupRequest.
Closes issue #1034.
Fix DRB integrity failures during handover and re-establishment
This MR fixes DRB integrity protection failures that occur during N2 handover
and connection re-establishment scenarios. The issues were caused by incorrect
security key handling and ciphering configuration during these procedures with
DRB integity enabled.
See merge request !3767 for more details.
Avoid measGap configuration on handover in intra-freq scenarios
During the handover, we are incorrectly configuring the measGap, even though
neighboring cells are on the same frequency. Since gNB is not expecting this
measGap, the SRS scheduling is performed. Therefore, we are periodically
receiving these logs after the handover:
[NR_MAC] Invalid timing advance offset for RNTI 58e2
[NR_MAC] Invalid timing advance offset for RNTI 58e2
[NR_MAC] Invalid timing advance offset for RNTI 58e2
[NR_MAC] Invalid timing advance offset for RNTI 58e2
[NR_MAC] Invalid timing advance offset for RNTI 58e2
[NR_MAC] Invalid timing advance offset for RNTI 58e2
These logs occur at a time when UE is performing a MeasGap operation and not
sending the SRS, while gNB thinks it will receive the SRS, but will not receive
any SRS.
This MR resolves this issue, and after the handover, these logs no longer
appear.
Use UL functions for Qm/R determination
During refactoring, the wrong functions and correspondingly tables have
been used to calculate UL TB size. Fix through correct functions.
This should fix these error messages:
3624774.778195 [MAC] E (nr_get_Qm_dl:2034) Invalid MCS table index 3 (expected in range [0,2])
3624774.778207 [MAC] E (nr_get_code_rate_dl:2066) Invalid MCS table index 3 (expected in range [0,2])
3624774.778211 [NR_MAC] E (nr_compute_tbs:63) Error in compute TBS with a NULL input, returning NULL TBS
Fixes: 9449f777 ("Remove TBS table and recompute on demand")
During refactoring, the wrong functions and correspondingly tables have
been used to calculate UL TB size. Fix through correct functions.
This should fix these error messages:
3624774.778195 [MAC] E (nr_get_Qm_dl:2034) Invalid MCS table index 3 (expected in range [0,2])
3624774.778207 [MAC] E (nr_get_code_rate_dl:2066) Invalid MCS table index 3 (expected in range [0,2])
3624774.778211 [NR_MAC] E (nr_compute_tbs:63) Error in compute TBS with a NULL input, returning NULL TBS
Fixes: 9449f777cc ("Remove TBS table and recompute on demand")
Thomas Schlichter