- merged nr-schedule_ue_spec into nr_schedule_uss_dlsch_phytest
- enabled nr_ue_send_sdu for S1 mode
- increased ta_timer to 100
- restored NR_UPLINK_SLOT to 2 (as it was in develop-nr)
- fixed logic for S1 and noS1 modes
- code cleanup and formatting
- introduced new parameter in nr_ue_dl_indication for UL time alignment
- moved TA timer logic one level up so that now is executed every slot
- set timer value to 80 slots to cope with the sl_ahead design
- introduced new TA-related members to gNB MAC instance struct
- UE processing capability 1
- Setting the TA update to be applied after the reception of the TA command
- Durations of N1 and N2 symbols corresponding to PDSCH and PUSCH are
computed according to sections 5.3 and 6.4 of TS 38.214
- Introduced tables 5.3-1, 5.3-2, 6.4-1, 6.4-2 from TS 38.214
- ta_timer at gNB side to control the transmission of TA to the UE. This is now happening every 20 slots.
- when the timer resets gNB is now transmitting the TA whether it is zero or not.
- introduced struct NR_UL_TIME_ALIGNMENT_t to handle configuration of time alignment related parameters.
- UE PHY RX: is now triggered through a flag when to store the TA command, the frame and slot
when the application should occur.
- UE PHY TX: when the tx frame and slot match the time alignment configuration, it process the TA command and applies the
TA update
- "nr_process_timing_advance": TA to be applied is commented out, need to be uncommented
- with introduced delay of 50 in rx_rf, TA update should be 34 in MAC CE
but this does not occur when ta is applied at UE side according to standard
- introduced ULSCH scheduler and NR RX SDU functions
- fixes to logic in UL fill RX indication
- added crc indication in UL RX
- temporary hardcoded UE_id to 0, rnti not considered in the logic
- Initial gNB DLSCH and UE spec scheduling implentation
- MAC PDU generation (including header as per TS 38.321)
- MAC PDU processing at UE side with extracion of TA updates
- General code cleanup
- Introduced NR MAC COMMON folder, moved common files here
In 3/4 sampling mode, the OFDM symbol size is _not_ a power of two (e.g. 1536 instead of 2048).
In this case it is _not_ OK to calculate the modulus using a binary AND, it _must_ use either the actul modulus operator (%) using an integer division,
or a _correct_ if statement or tertianary operator like this:
re_offset = (re_offset + 4 >= ue->frame_parms.ofdm_symbol_size) ? (re_offset + 4 - ue->frame_parms.ofdm_symbol_size) : (re_offset + 4);
But of course using the actual modulus operator is much more readable and surely not much slower:
re_offset = (re_offset + 4) % ue->frame_parms.ofdm_symbol_size;
Guido Casati