- Phy configuration will be prepared by MAC
- Sidelink preconfiguration parameters passed from RRC->MAC
- Only 1 SSB TA allocation used
- psbch payload prepared by MAC after receiving the tx slss req
SCF FAPI 222.10.02 had a bug on the description of CoreSetType:
0: CORESET is configured by the PBCH or SIB1
(subcarrier 0 of CRB0 for DMRS mapping)
1: otherwise (subcarrier 0 of CORESET)
That was fixed in SCF 222.10.04:
0: CORESET is configured by the PBCH or SIB1
(subcarrier 0 of the CORESET)
1: otherwise (subcarrier 0 of CRB0 for DMRS mapping)
That wrong description created a misunderstanding, to overcome it we "wrongly" added a third value. This commit fixes that and aligns the CoreSetType with FAPI 222.10.04
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
PDU Length is as per SCF 222.10.02: The total length (in bytes) of the
PDU description and PDU data, without the padding bytes. From
TX_DATA.request we get 8 (2 bytes PDU_Length + 2 bytes PDU_Index + 4
bytes num_TLV ) and from each TLV we get 4 + value size ( 2 bytes tag +
2 bytes length + value size without pading)
Therefore, add function to compute PDU_length() value for
TX_Data.request, taking into account how many TLVs there are.
compute_PDU_length() does not rely on access to `nfapi_nr_pdu_t`.
Put it into nr_mac_common.c to avoid introducing dependencies.
Creation and usage of packing/unpacking functions for DCI payload
Update Proxy commit id for CI
Apply formatting on changed functions and fix pull/push return value checking
- 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
1. Adding a "SL" frequency for Sidelink mode. The
importance of this variable is to ensure that
when we are in mode 1 (UE+UE+gNB), that the slot
configuration and frequencies do not overlap. This
SL frequency is important for rotation and allows
us to utilize the OFDM modulation and demodulation
functions that already exist in OAI.
2. Adding sl_mode to the command line for proper UE
deployment when in SL mode. sl_mode can be set to 0,
1, or 2. sl_mode 0 indicates no-Sidelink at all,
mode 1 is gNB, UE, and UE (3GPP defines mode numbers).
sl_mode 2 indicated UE to UE communications with no
gNB at all.
3. New functions for calculating the carrier frequency
for SL mode.
Robert Schmidt