uper_encode_to_buffer() of asn1c returns the number of BITS that have
been encoded; if we use this, we need to calculate the resulting number
of bytes (rounding up) to get the right buffer size.
Note that do_NR_ULInformationTransfer() uses
uper_encode_to_new_buffer() which returns the number of BYTES, hence, in
this similar function, we should not modify the return value.
In the case of PDU sessions in the NG UE context setup request, we first
have to set up security. Hence, in this commit, implement the "delayed"
set up of theses PDU sessions, and acknowledge the setup request after
reconfiguration, as requested by O-RAN.WG5.C.1-v11.
Trigger UE ctxt setup response for the case of "registration request"
(no PDU sessions in UE Context setup response), as mandated by
O-RAN.WG5.C.1-v11.
As of this commit, since we now send the UE security command as a DL NAS
message, there is no F1 UE Context setup request. Hence, instead of
sending a UE context modif request, send the UE context setup request
after the E1 bearer setup response (which logically also makes more
sense, as the E1 setup procedure comes before the F1 setup procedure).
This reverts commit 0f100a6e94, which
introduced a hack to possibly wait with a PDU session setup at the RRC
in case a RRC UE capability transaction (requesting UE capabilities from
a UE) was ongoing. This happened, as we delayed the UE capabilities to
after the first RRC reconfiguration; in that case, certain UEs were
requesting the next PDU session, and if RRC did not delay the new PDU
session (as requested from the core), this procedure might occur while
UE capability enquiry was ongoing, leading to failures in these
transactions.
The default RRC reconfiguration was previously sent after the security
mode command as a "first" RRC reconfiguration. However, it is simply not
needed, as it will be triggered through a subsequent reconfiguration
that also sets up DRBs.
Move the Measurement Config to the "other/dedicated" RRC
reconfiguration.
This reconfiguration would have forwarded a NAS PDU (typically a
registration accept). This is now done by a dedicated forwarding of NAS.
This reverts commit 4a7d7975ce.
Trigger the UE capability right after security mode complete, as
specified in O-RAN WG5.C.1-v11. Also, there is no "need" for the
"default" RRC Reconfiguration (it will come once PDU sessions are
requested), so remove this as well.
Previously, the CU sent the Security Mode Command as part of a UE
context setup request. This was done "because it was possible", not
because there was an inherent need to do this. However the LiteOn DU
does not like this, as it expects to also have a DRB in the UE context
setup request procedure, which is not always the case.
Hence, send the Security Mode Command in a normal DL RRC msg transfer
over F1. As of this commit, there is not UE context Setup Request (so it
might not work with all DUs), but the OAI DU is cool and does not care,
so RFsim still works.
This also aligns the CU's behavior with O-RAN.WG5.C.1-v11.
Finally, as of this commit, we do not trigger a UE context setup
request, so we cannot handle PDU sessions inside the initial UE context
setup request at the same time as the security mode command (which was
done previously before reaching this point). This will be fixed in a
later commit.
In the DU, read slice information from the DU config file. Handle
multiple slices within the F1 Setup Request structure representation,
and forward it via F1 to CU. The DU slice information is stored in the
setup request structure.
This reverts commit eaf28414ca.
This assertion was introduced as we (wrongfully) thought we needed to
calculate the SSB ARFCN at the CU. Since PBCH might carry one bit, which
is not available at the CU, only certain SSB ARFCNs would have been
possible.
With the availability of the SSB ARFCN through the
MeasurementTimingConfiguration, this is not necessary anymore.
MeasTimingConfig may not come with F1 Setup Request: some DUs send it
with the DU configuration update. Handle this gracefully by checking for
MTC before using it.
Use the correct MIB data structure, MIB_t. This is required by 38.473,
and the LiteOn DU sends only that. So our CU needs to handle it, so
align the OAI DU as well.
- according to 5.3.7.4 of TS 38.331: 1> re-establish RLC for SRB1;
- gNB:
1) re-establish RLC for SRB1 in nr_rlc_update_id
2) re-establish RLC for remaining RBs concurrently with RRCReconfiguration
issue: gNB) in nr_rlc_update_id the gNB is re-establishing RLC for all
RBs at the same time when receiving RRCReestablishmentRequest
from UE
UE) according to the specs, the UE is re-establishing RLC for
SRB1 with RRCReestablishmentRequest the other RBs are
re-established during RRCReconfiguration (in our case in
nr_rrc_ue_process_RadioBearerConfig) when receiving
reestablishRLC IE in rlc_BearerToAddModList
RLC TX) this leads to RLC counters mismatch after re-establishment:
control PDUs discarded until max nb of retx is reached
and then UL failure occurs
Robert Schmidt