If there are no active bearers, the function previously returned an
empty list. Return NULL if there are no bearers, so it is safe to call
this function even when no bearers are present. We can also pass it
every time to do_RRCReconfiguration(), which will not add an empty list
for DRBs.
Create a single function to activate an SRB. This function derives the
corresponding keys, triggers the setup in PDCP, and marks the SRB as set
up, instead of doing all of this common functionality in individual
steps. Use it at the corresponding places.
This commit implements retrieval of 5G-S-TMSI from Parts 1&2, or the
entire 5G-S-TMSI, depending on what the UE sends. Further, if it has
been retrieved, print a log of all constituent parts of it.
The UE-specific variable ng_5G_S_TMSI_Part2 is not needed, as we compute
the full 5G-S-TMSI as soon as we have Part2 (and 1).
The correct forwarding to the core is implemented in the following
commit.
We did not give a cause value, and therefore NGAP's "PDU sessions
failed" encoding failed. Give a cause value in all cases, so that this
cannot happen anymore.
To prevent against this, put an AssertFatal() into the encoder that
stops if an internally sent message does not have a correct cause value
(we can at least select a default).
Print an info message for all failed PDU sessions.
In rrc_gNB_send_NGAP_INITIAL_CONTEXT_SETUP_RESP(): if a PDU session is
already established, don't count it as failed.
If we are in one of these procedures, we basically must be in SA mode,
everything else is illogical. It also does not seem plausible to check
for this, as it is not apparent why only these couple of calls should
not be executed if not in SA. Hence, remove.
This implementation might work, but it simply triggers RRC setup on the new
DU when we might send a RRC reestablishment speeding up the whole
connection setup. For this:
- we should send the F1 UE context setup to the new DU
- we should still do the reestablishment, containing the reestablishment message
The latter should be sent once we received the F1 UE context setup
response. We don't need a new context. send a release to the old DU (and
don't release our own context!!).
We might also send the reestablishment to the UE encapsulated with the
F1 UE context setup response. Need to investigate if this is feasible
(because if the DU rejects [can that happen here?], the UE will still
send reestablishment complete -- what then?).
Also, we would need to send the E1 bearer context modification to the
CU-UP.
Keeping track if AS security is activated. This is important for a later
commit, where we use this to decide if we send a F1 UE Context Setup Req
with security command after receiving the E1 bearer context setup
response. The corresponding AssertFatal() removed in the same commit
implementing PDU session handling in NGAP Initial UE Context Setup.
38.401 Sec 8.1 asks for sending the Initial Context Setup Response after
a reconfiguration happened. Therefore, we can never send this message
directly from the handler in the Initial Context Setup Request
- CU-CP replying to the CU-UP with a Setup Failure message in case of unsuccessfull E1 Setup Request
- message is decoded by the CU-UP, and stops the process
RRC Version is a required IE. Hence, implement the encoder and decoder
for this message. At the DU and CU, read the RRC Version we use and fill
the corresponding field.
Co-authored-by: Robert Schmidt <robert.schmidt@openairinterface.org>
For LiteOn DU, we do not receive the MIB/SIB1 in the F1 Setup Request.
This is not a problem in itself, but it might happen that certain
procedures are executed without MIB/SIB1. Check for it and handle
appropriately:
- During normal connection establishment, we might not be able to
calculate measurement config
- During reestablishment, we might not be able to calculate ARFCN SSB
and cannot do reestablishment; do RRC setup instead.
When setting up bearer(s) through F1, the corresponding F1 message has
QoS fields for the DRB(s) to be set up, as well as for all flows
associated to this DRB. In this commit, set the DRB QoS field to be
equal to the first flow (it is unclear/unspecified how it should be set
up, based on the flows), which was not set before and therefore
contained unitialized data.
The F1 module uses this data, and in split mode, F1 message generation
failed due to uninitialized data.
We reuse RRC UE IDs at the RRC. Previous to this commit, we did not
release a UE at the CU-CP's PDCP (for SRBs). Thus, when reconnecting a
UE, the PDCP might not be in a good state, since we did not release the
previous PDCP UE context.
remove several unused files
remove mem_block_t that is never used in a different way than a simple heap buffer
move up IP address type and remove duplications of the same struct declaration
Position of SSB from Point A depends on offsetToPointA and Kssb, and for both, the unit for RB is expressed as 15KHz for FR1 and 60 KHz for FR2, so scaling must be 4 for FR2 frequencies
- Implement: Extend the F1 encoding and decoding with Qos
- Implement: E1 decoding for QoS
- Fix: Modify the UE_MODIFICATION_REQUEST_MSG towards DU to contain QoS info based on E1AP context response
- Fix: Modify the E1AP and F1AP message structures
- Fill the Qos configuration to send to MAC
Security part needs to be checked, may fail to work.
But if it fails, it was probably not working before either.
This commit also contains adding 'static' to nr_pdcp_entity_release()
and nr_pdcp_entity_delete() (it was too complicated to do a separate
commit for this).
We also update stats in free_rx_list() (again, too complicated for
a separate commit).
openair2/RRC/NR/rrc_gNB.c probably needs some more work, it is a
bit ugly to reestablish all the drbs without checking if they
exit. It will generate warnings at runtime. I didn't do it because
I don't know the proper way.
The function generateDRB() sets the value to 100ms but the function
rrc_gNB_process_NGAP_PDUSESSION_SETUP_REQ() sets it to 0ms.
So what happens is that the UE gets the value 100ms in the
RRC Reconfiguration but the gNB creates the PDCP entity with 0ms.
Let's create it with 100ms instead, to be aligned with how we configure
the UE.
And also avoid some PDCP warnings at runtime when some packets
are retransmitted but rejected because of the 0ms timer. This is
the warning:
[PDCP] discard NR PDU rcvd_count=68469, entity->rx_deliv 68481,sdu_in_list 0
This is just a hotfix. A real solution is to have the RB creation in
only one place. And we should also have those parameters configurable.
Work for later.
Robert Schmidt