tx_next was increased only when all segments of an SDU were sent to
lower layers. This may lead to a situation where the receive entity
transmits a control PDU that is rejected because it sets its ACK to
tx_next+1 (if all segments were not transmitted when the control PDU
is sent).
What is done now is to increase tx_next as soon as we send the first
segment of an SDU to lower layers. A control PDU received from the
receive entity is now accepted and processed.
Specifications (38.322 5.2.3.1.1) say to increase tx_next when the
RLC entity receives an SDU from upper layers. But for us, since the
buffering of SDUs is done in the RLC layer and since the buffer size
may be big, we may increase tx_next too much. The choice has been
made to increase it only when we transmit an SDU to lower layers.
We may change this logic if needed. (But it won't be simple.)
- MAC creates CellGroupConfig and sends to RRC
- the RRC does not manually update the CellGroupConfig
- MAC handles the RRC processing timer
In this commit, any updates to the CellGroupConfig previously done at
the RRC don't work. In other words, MIMO etc don't work; this is
implemented in the next commit.
Note that the change to take out spCellConfig during reestablishment is
because after reestablishment, as per spec (38.331 5.3.7.2), the UE
should drop the spCellConfig, which we generate by default on the first
UE connection.
Furthermore, add a new variable apply_cellgroup to signal if, after RRC
processing timer, we wish to apply the CellGroup. In some situations,
e.g., Msg.4 ack, we do not want to apply the CellGroup, because for
instance in reestablishment, we await for a reconfiguration of cellgroup
that would be triggered too early.
!SIB1 is not correctly filled! This commit does not work with COTS UEs!
The next commit fixes this.
- Move radio config (e.g., minRXTXTIME, SIB1 TDA, do_SRS, etc) down to
MAC.
- Some parameters in MAC are redundant: delete them.
- Remove call to nr_mac_config_scc() from RRC and simulators, the MAC
initialization routine calls it implicitly
Previously, filling of F1 Setup Request depended on reading the RRC;
hence, for timing reasons, we only initialized and sent the F1 Setup
Request once the MAC and RRC are ready.
After moving SCC, SCD, MIB, and SIB1 to MAC, the MAC does not depend on
an RRC being present anymore, and hence, the F1 Setup Request does
neither. In this commit, we read the F1 Setup Request after initializing
the MAC.
The MasterInformationBlock is handled at the DU and sent to the CU in
the F1 Setup Response. Hence, move it down to the MAC. Furthermore:
- Change type because MIB_PDU_t is 4G type
- Simplify schedule_nr_mib()
Note: the reestablishment is broken, and a later commit fixes it.
The ServingCellConfigCommon is an inherently radio-related
configuration. As such, it should be handled by the DU, not the CU.
Therefore, move it "down" to the MAC.
- send F1 Setup using callback
- store f1 setup req locally for reference
- check F1 Setup Req against RRC data structures:
* if matches: send F1 Setup Response using callback
* if not matching: send F1 Setup Failure using callback
- don't send CU config update by default, we don't need this
- if the Setup Response does not contain a cell, don't activate. It is
possible the CU sends a gNB-CU configuration update, which will
initialize the structures
- Fix 4G and 5G discrepancy in TLV padding requirements: 4G does not
need padding, whereas 5G needs, so make separate set of function for
padding for NR
- Fix packing/unpacking for (n)FAPI PARAM and CONFIG.request/response
messages
- Handle message padding to next 32-bit boundary, as per SCF
specification in packing and unpacking functions
- Account for message header size upon receiving message in PNF and VNF
rmagueta