In case of Handover, NTNconfig sent in RRCreconfiguration triggering handover contains epoch time wrt
timing of Target cell. NTNconfig in RRC needs to be processed only after timing is acquired on the target cell
In case of Target cell, epoch time is the sfn nearest to the frame timing of the target cell.
Duplex is assumed to be static but for NTN bands, it is not static.
TxRX Duplex is defined in section 5.4.4 of 38.101-5 (for NTN) specs v1809
n256 190 MHz, 165 to 215 MHz
n255 -101.5 MHz, -72.5 to -130.5 MHz
n254 862 - 885 MHz
SPEC 38.331 section 5.2.2.6
Inform MAC that UL SYNC got lost because of T430 expiry
- Send message NR_MAC_RRC_CONFIG_RESET with cause UL_SYNC_LOST_T430_EXPIRY to MAC
Reacquire SIB19 after T430 expiry
This is not checked in this commit
- RACH needs to be performed through probably PDCCH order to reobtain UL-SYNC
- system usecase involving Recovery from T430 expiry not tested yet as that requires changes on gNB side.
Spec 38.331 section 5.2.2.4.21 indicates this
1> start or restart T430 for serving cell with the timer value set to ntn-UlSyncValidityDuration for the serving cell
from the subframe indicated by epochTime for the serving cell;
NOTE: UE should attempt to re-acquire SIB19 before the end of the duration indicated by ntn-UlSyncValidityDuration and epochTime
Epochtime IE
When explicitly provided through SIB, or through dedicated signaling, the EpochTime is the starting time of a DL
sub-frame, indicated by a SFN and a sub-frame number signaled together with the assistance information.
For serving cell, the field sfn indicates the current SFN or the next upcoming SFN after the frame where the message indicating the epochTime is received.
This field is mandatory present when ntn-Config is provided in dedicated configuration.
gNB implementation related to epochtime will be done in a separate merge request.
ntn-UlSyncValidityDuration in SIB19 from Spec 38.331 v17.12
A validity duration configured by the network for assistance information which indicates the maximum time duration
(from epochTime) during which the UE can apply assistance information without having acquired new assistance information.
The unit of ntn-UlSyncValidityDuration is second. Value s5 corresponds to 5 s, value s10 indicate 10 s and so on.
ntn-UlSyncValidityDuration-r17 ENUMERATED{ s5, s10, s15, s20, s25, s30, s35,s40, s45, s50, s55, s60, s120, s180, s240, s900}
Implementation of epochtime is under discussion.
It can be configured in configuration file according to the above enumeration. For GEO - 240s, MEO - 20s, LEO-5s can be used.
3GPP 38.331 release 16 specifies that If the field reportQuantity-r16 is present, UE shall ignore reportQuantity (without suffix).
reportQuantity-r16 configures SSB based SINR as the reporting quantity.
set do_SINR = 1; in gNB params part of the config file to enable SSB based SINR reporting instead of the default RSRP based.
According to 38.331 , cell specific K-OFFSET provided in SIB19 is provided in number of slots as per 15Khz SCS
Koffset before being applied, needs to be updated to the slots according to the configured subcarrier spacing.
Added support for NTN FDD FR1 bands 254, 255, 256 as specified in 3GPP TS 38.101-5
Conf files added for 15Khz, 5Mhz and 30Khz, 10Mhz configurations added for these bands
- num DL/UL harq processes, bits for harq id in DCIs, set according to IEs configured in RRC messages
- removed going through all the harq processes before triggering nr_ue_ulsch_procedures in phy_procedures_nr_ue.c
- did not remove usage of MAX_HARQ_PROCESSES in init phase
- Enabled configuration for number of dl, ul harq processes in conf file
- set "num_dlharq = 32; num_ulharq = 32;" under "gNBs" section in the conf file
- default values when not configured is 16 for DL, UL harq processes
- IEs in the RRC messages set according to the number of DL, UL harq processes configured.
- If value 32 is configured , then IEs related to num harq processes and dci bits also configured in Bandwidth parts.
- MAX HARQ PROCESSES set to 32
- for PDSCH - default setting in OAI is 16, according to 3GPP rel17 38.331 these are the possible configs
- if no IES are defined then 8
- if nrofHARQ-ProcessesForPDSCH is defined then these values- {n2, n4, n6, n10, n12, n16}
- if nrofHARQ-ProcessesForPDSCH-v1700 is defined then 32
- for harq bits in DCI
- DCI 1_0 - 4 bits spec 38.212, section 7.3.1.2.1
- DCI 1_1 - 4/5 bits according to IE harq-ProcessNumberSizeDCI-1-1, spec 38.212, section 7.3.1.2.2
- for PUSCH - default setting in OAI is 16, according to 3GPP rel17 38.331 these are possible configs
- if no IES are defined then 16
- if nrofHARQ-ProcessesForPUSCH-v1700 is defined then 32
- for harq bits in DCI
- DCI 0_0 - 4 bits spec 38.212, section 7.3.1.1.1
- DCI 0_1 - 4/5 bits according to IE harq-ProcessNumberSizeDCI-0-1, spec 38.212, section 7.3.1.1.2
- FOR HARQ32 , DCI 1_1, DCI 0_1 should be configured in UE dedicated search space. In OAI it is set.
- if search fails, keeps increasing the rx gain (set by --ue-rxgain) by
3 db until USRP max rx gain
- if initial sync is success, sets the rxgain to the value of
(TARGET_RX_POWER (50) - pbch digital power in dB/RE)
- Phy config update and Sidelink frame parameters initialisation
- PSBCH scheduler to trigger TX PSBCH/RX PSBCH actions
- Sidelink indication with rx ind to trigger send SL-MIB to MAC
- Enable Scope for PSBCH use -d or --dqt
- Enable system testing of PSBCH for example using RFSIMULATOR:
- UE1 is a SYNCRONISATION SOURCE UE which transmits PSBCH
started using command -
sudo ./nr-uesoftmodem --sl-mode 2 --sync-ref 4 --rfsim --rfsimulator.serveraddr server
- UE2 syncs onto UE1 during sidelink search, gets the timing and continues to receive PSBCH
started using command -
sudo ./nr-uesoftmodem --sl-mode 2 --rfsim --rfsimulator.serveraddr 127.0.0.1
- In the default use case 2 Sidelink SSBs sent over 16 frames.
- In case SL-SSB configuration needs to be changed use -O option in the above command like
-O ../../../targets/PROJECTS/NR-SIDELINK/CONF/sidelink_preconfig_1txpool.conf
- 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
LocationandBandwidth adjusted according to the location of SSB and Controlresourceset 0
For example for 106RBs configuration files -
- AbsoluteFrequencySSB = 641032 = RB43 (1032/24) - points to Subcarrier 0 of RB10 of SSB block
- Hence SSB is located from RB33-RB53
- Coresetzero sent in MIB is 0 which means offset 0, RBsize 24 from Start of SSB according to table 13.4 in Spec 38.213
- InitialBWP should start from RB 33 (offset is 0 from SSB) and should be a size of minimum 24 RBs.
- SLIV = 275 * (24-1) + 33 = 6358
Controlresourceset value wrongly configured to 12 , changed to 0 as sent in MIB.
Procedure fill_dmrs_mask is modified.
- PDSCH Mapping Type B is supported
- Modified according to sections 5.1.6.2 of Spec 38.214
- Single and double symbol DMRS are handled in Type A and Type B
Mapping type according to the time domain allocation from DCI should be used to get the values of DMRS config
For sending sib1 - DCI FORMAT 1_0 will be used with SI_RNTI, UE should perform these actions
according to sections 5.1.6.2 of Spec 38.214
Additional DMRS set to pos2 in case of msg2 reception, msg3 transmission.
Mapping type B is added to RRC reconfig.
- nr_dlsim updated to test typeA and typeB. Verified the changes.
- RFSIM Validation of PDSCH Mapping TypeB by changing timedomainallocation in configuration files.
- CDM groups used, multiple DMRS locations tested
- REMOVED compiler define NR_SC_FDMA
- enabled -Z option in ulsim for testing NR SC-FDMA
- Gnb UL Processing of LLRS even if last symbol allocated has no data
- transform precoding Enumerations used
Raghavendra Dinavahi