Conclusions achieved in RAN1 meetings up to RAN1#120 are listed in sections 3 to 10.
The WI objective from the WID [1] is inserted below for convenience.
WID Objective
3GPP TSG RAN WG1 Meeting #116
RAN1#116 made the following agreements:
NR-NTN downlink coverage enhancement
RAN1#116 made the following agreements:
Agreement
For DL coverage study, consider the following additional reference satellite parameters scenarios for LEO600km Set1 in FR1 (i.e., S-band), referred to as Set1-1 FR1, Set1-2 FR1 and Set1-3 FR1:
Note: RAN1 will aim to identify necessary enhancements for these scenarios in the study phase. At the end of the study phase, RAN1 will further discuss whether the potential enhancements will be specified within Rel-19 framework.
Agreement
For DL coverage study at system level, consider the following additional reference satellite payload parameters for LEO600km in FR2 (i.e., Ka-band):
Agreement
Adopt the following phased array antenna parameters for LEO 600km in FR1:
Agreement
RAN1 to consider the following performance metrics for DL Coverage enhancement evaluation at system level:
At least:
CDF of the received SINR
The dwell time and revisit time interval for each beam illumination across the coverage
Periodicity of common control channels (e.g. SSB, CORESET0/SIB1, SIB19) and corresponding coverage ratio
Other metrics may be reported such as
CDF of the cell throughput
CDF of user perceived throughput (UPT)
CDF of Latency
Ratio of mean served cell throughput and offered cell throughput, denoted by 𝜌 (refer to TR36.889)
For system level study based on analytical evaluation:
N1 beam footprints are in state “off”
These beam footprints are not served by any signal (no satellite service in this area)
N2 beam footprints are in state “common messages only”
These beam footprints do not have any active user traffic, and are served the necessary information for cell discovery and initial access.
Optionally, companies may consider user arrival (e.g. RACH access) in this type of cell, and should describe how this is taken into account in the analytical evaluation
N3 beam footprints are in state “active traffic”
These beam footprints have X active (e.g. VoNR) users each.
These beam footprints are also served the necessary information for cell discovery and initial access
N1 + N2 + N3 = “Total number of beam footprints “
N1, N2, N3, X are to be reported by companies.
Resource utilization obtained under the assumptions above is to be reported by companies.
Other assumptions made in the evaluation are to be reported by companies, e.g. power sharing scheme, beam hopping scheme, etc.
Agreement
For NR NTN Rel-19 DL coverage evaluation, UE characteristics for handheld terminals in Table 6.1.1.1-3 in TR 38.821 can be reused, with the following:
-5.5 dBi antenna gain is assumed
at least 2Rx are considered at the UE
4Rx can be optionally considered and reported
Note: Redcap device is not considered in the scope of DL coverage study
Agreement
The following traffic models are considered for system level evaluation of DL coverage:
FTP3: as in Table 6.1.1.1-7 of TR 38.821: 0.5MB as packet size, 200ms as mean inter-arrival time
FTP3 IM: 0.1MB as packet size, 2s as mean inter-arrival time
VoIP can be considered in the evaluation.
It is up to company report which traffic model is used among the discussed traffic models in their evaluations.
Other models may be used as well, and parameter (e.g. packet size and arrival rate) adjustment can be optionally considered and reported.
Agreement
For NR NTN Rel-19 DL coverage evaluation, Beam layout defined in Table 6.1.1.1-4 in TR 38.821 can be reused.
Using other beam layouts is not precluded, and should be reported by companies
Agreement
For NR NTN Rel-19 DL coverage evaluation, a value of beam steering latency equal to 0 at least if phase array antenna is assumed.
Values different from 0 can be optionally reported
Agreement
DL coverage is evaluated at link level with the following considerations:
NGSO at LEO-600 operating in FR1 is considered in priority
Additional satellite payload parameters defined for system level evaluation are used
FFS: Antenna gain reduction due to steering loss can be considered
Agreement
For the evaluation of NTN downlink coverage at link level, reuse the target data rate from Rel-18 NTN Coverage enhancements:
For VoIP: AMR 4.75 kbps (TBS of 184 bits without CRC in physical layer) with 20 ms data arriving interval
For data rate service: both 3 kbps and 1Mbps can be considered
Companies can also use the data rates corresponding to the traffic types used for system level evaluations
Agreement
For link-level study, downlink coverage performance in NR NTN is evaluated according to the following steps.
Step 1: CNR is calculated as defined in 6.1.3.1 of TR 38.821
Step 2: Required SNR of target service is evaluated by LLS
Step 3: The CNR and the required SNR are compared
Agreement
For link-level study, for NR NTN DL coverage enhancement, the following channels/signals can be considered for evaluations:
PDSCH for VoIP
PDSCH for low data rate service
PDSCH Msg.2
PDSCH Msg.4
PDSCH carry SIB, e.g., SIB1, SIB 19
PDSCH for paging
PDCCH
Broadcast PDCCH (e.g. PDCCH of Msg.2, paging)
SSB
Note: RAN1 will aim to identify necessary link-level enhancements for these channels in the study phase. At the end of the study phase, RAN1 will further discuss whether the potential link-level enhancements will be specified within Rel-19 framework.
Agreement
For DL coverage performance evaluation, the following are assumed for all channels/signals
Channel model/Delay spread:
Channel model as in Table 6.1.2-4 of TR38.821, NTN-TDL-C (LOS)
Evaluation scenario:
Rural (LOS)
Channel estimation: Realistic estimation:
Companies are encouraged to report channel estimation method.
SCS:
15 kHz only
UE speed: 3 km/h
Frequency drift: TBD
Frequency offset: 0.1 ppm
Agreement
For link budget calculation, parameters in the following table are assumed:
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Work in RAN1 is limited to checking whether any essential changes are needed for their support (i.e. focusing on HD collision rules) by end of Q2/2024.
Agreement
Study at least the following scenarios for (e)RedCap HD-FDD UEs for NTN:
Whether existing handling rules for the following cases should be reused or updated when taking into account TA mismatch between actual TA used by UE and assumed TA at the gNB based on available TA report:
Case 1: Dynamically scheduled DL reception collides with semi-statically configured UL transmission
Case 2: Semi-statically configured DL reception collides with dynamically scheduled UL transmission
Case 3: Semi-statically configured DL reception collides with semi-statically configured UL transmissionÂ
Case 4: Dynamically scheduled DL reception collides with dynamic scheduled UL transmission
Case 5: Configured SSB collides with dynamically scheduled or configured UL transmission
Case 6: Dynamic or semi-static DL collides with valid RO
Case 7: Collision due to direction switching
At least the following potential issues can be further considered for (e)RedCap HD-FDD UEs
Error cases in case 3 and case 4
SIB19 reception collides with UL transmission
Slot counting for UL repetition transmission colliding with SSB reception
Invalid symbol determination for PUSCH repetition type B
Actual TDW determination due to the collision between DL reception and UL transmission with DMRS bundling
CPU occupation due to omitted DL reception or UL transmission
Note: Both GSO and Non-GSO should be considered.
NR-NTN uplink capacity/throughput enhancement
Agreement
Adopt the table below for assumptions for Evaluation parameters for link level evaluation in NR NTN UL capacity and throughput enhancements
Agreement
Adopt the table below for assumptions for modelling impairments for link level evaluation in NR NTN UL capacity and throughput enhancements
Agreement
Adopt the table below for assumptions for KPIs for link level evaluation in NR NTN UL capacity and throughput enhancements
3GPP TSG RAN WG1 Meeting #116bis
NR-NTN downlink coverage enhancement
Agreement
For coverage evaluation of PDCCH in NR NTN, the following table is assumed:
Agreement
For coverage evaluation of PDSCH in NR NTN, the following table is assumed:
Agreement
Antenna gain reduction due to steering loss is not considered in the link level evaluation.
Note: This is aligned with the assumptions made in Rel-18 UL coverage enhancement
Observation
The CNRs for the satellite payload parameters Set 1-1, Set 1-2 and Set 1-3 are equal to -1.9 dB, -1.9 dB and -9.9 dB respectively.
Agreement
Confirm the Satellite phased-array antenna parameters for LEO 600km in FR1 defined in RAN1#116.
Al least the above model is considered for SLS to ease the alignment between evaluation results. The model below can be optionally considered:
Note 1: The maximum antenna gain is determined by considering an overall array efficiency [of 50%.]
Agreement
For coverage evaluation of PDSCH in NR NTN, the following payload sizes for PDSCH are assumed:
Note: At least the above values are simulated and reported. Other values can be considered.
Note: the values above are not the TBS.
Agreement
For DL coverage study at system level, it is up to companies to report the following parameters for LEO600km Set1-1 FR2:
Agreement
For coverage performance evaluation of DL channels/signals before the SIB19 acquisition, the maximum Doppler frequency drift is assumed to be equal to 0.27 ppm/s based on TR 38.821.
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Work in RAN1 is limited to checking whether any essential changes are needed for their support (i.e. focusing on HD collision rules) by end of Q2/2024.
Observation
To avoid the occurrence of error cases 3 and 4 through network scheduling, there are less resources available for a scheduled HD-FDD RedCap/eRedCap UE in NTN compared to TN when there is TA mismatch between actual TA used by the UE and assumed TA for the UE at the gNB.
Observation
For collision cases 1, 2, 5 and 6, when there is TA mismatch between actual TA used by the UE and assumed TA for the UE at the gNB, there might be less resources available for the scheduled HD-FDD RedCap/eRedCap UE in NTN compared to TN if gNB attempts to avoid the collision or there is a loss of DL/UL transmissions due to collision.
Observation
When there is TA mismatch between actual TA used by the UE and assumed TA for the UE at the gNB, there may be a BLER performance degradation for the reception of UL transmissions at the gNB for the scheduled HD-FDD RedCap/eRedCap UE in NTN compared to TN if gNB does not attempt to avoid the collision at least in the following cases:
UL transmission with repetitions due to different available slot counting at UE and gNB when colliding with SSB reception
PUSCH repetition type B due to different invalid symbol determination at gNB and UE when colliding with DL transmissions
UL transmission with DMRS bundling due to the different actual TDW determination at gNB and UE when colliding with DL transmissions
Note: the above cases happen at least with one of collision cases 1, 2, 5, 6, and 7.
NR-NTN uplink capacity/throughput enhancement
Agreement
Support OCC for PUSCH in Rel-19 NR NTN:
At least PUSCH with Type A repetition
FFS PUSCH without Type A repetition for intra-symbol and/or inter-symbol cases
At least code length 2 or 4, FFS code length 8
FFS: number of RBs
Potential OCC techniques listed below are for further down-selection:
Inter-slot time-domain OCC with PUSCH repetition Type A
Inter-symbol(s) time domain OCC
Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4)
Combinations of OCC techniques
TBoMS for OCC techniques is FFS
Agreement
RAN1 to at least further study the potential specification aspects on OCC techniques:
TBS calculation / Rate matching
UCI multiplexing
RV cycling across repetitions
Frequency hopping, e.g. intra /inter slot
OCC indication/configuration
Power control
FFS others aspects
3GPP TSG RAN WG1 Meeting #117
NR-NTN downlink coverage enhancement
Observation
Based on LLS results on PDCCH coverage evaluation collected from different sources:
It is observed that the required SNR for PDCCH is in average equal to -6dB (17 sources)
With parameter LEO600km Set1-1 FR1 and 1-2 FR1:
17 sources observed that there is no coverage gap with Set1-1/1-2 FR1.
The coverage margin is around 4 dB compared to CNR of -1.9 dB.
With parameter LEO600km Set1-3 FR1:
15 sources observed that there is a PDCCH coverage gap of 3.9dB in average compared to CNR of -9.9 dB.
Note: the results above are obtained independently from the performance of other channels or signals, and it doesn’t imply the successful reception for other channels or signals before or after the detection of PDCCH.
Observation
Based on LLS results on PDSCH Msg2 coverage evaluation collected from different sources:
It is observed that the required SNR for PDSCH carrying Msg2 is in average equal to – 10.9 dB (14 sources)
With parameter LEO600km Set1-1 FR1 and 1-2 FR1:
14 sources observed that there is no coverage gap for PDSCH with Msg2:
The coverage margin is around 9 dB compared to CNR of -1.9 dB
With parameter LEO600km Set1-3 FR1:
12 sources observed that there is no coverage gap for PDSCH with Msg2:
The coverage margin is around 1 dB on average compared to CNR of -9.9 dB
Note: the results above are obtained independently from the performance of other channels or signals, and it doesn’t imply the successful reception for other channels or signals before or after the detection of PDSCH Msg2.
Observation
Based on LLS results on PDSCH Msg4 coverage evaluation collected from different sources:
It is observed that the required SNR for PDSCH carrying Msg4 is in average equal to – 5.2 dB (14 sources)
With parameter LEO600km Set1-1 FR1 and 1-2 FR1:
14 sources observed that there is no coverage gap for PDSCH with Msg4:
The coverage margin is around 3.3 dB on average compared to CNR of -1.9 dB
With parameter LEO600km Set1-3 FR1:
11 sources observed that there is a coverage gap for PDSCH with Msg4:
The coverage gap is around 4.7 dB on average compared to CNR of -9.9 dB
1 source observed that there is no coverage gap for PDSCH with Msg4 with a coverage margin of 0.3 dB compared to CNR of -9.9 dB
Note: the results above are obtained independently from the performance of other channels or signals, and it doesn’t imply the successful reception for other channels or signals before or after the detection of PDSCH Msg4.
Observation
Based on LLS results on PDSCH SIB1 coverage evaluation collected from different sources:
For PDSCH carrying SIB1 option 1 (with a payload size of 800bits) it is observed that the required SNR is in average equal to – 5.8 dB (14 sources)
For PDSCH carrying SIB1 option 2 (with a payload size of 1280bits) it is observed that the required SNR is in average equal to – 3.4 dB (12 sources)
With parameter LEO600km Set1-1 FR1 and 1-2FR1:
14 sources observed that there is no coverage gap for PDSCH with SIB1 option 1:
The coverage margin is around 3.9 dB on average compared to CNR of -1.9 dB
12 sources observed that there is no coverage gap for PDSCH with SIB1 option 2:
The coverage margin is around 1.5 dB on average compared to CNR of -1.9 dB
With parameter LEO600km Set1-3 FR1:
11 sources observed that there is a coverage gap for PDSCH with SIB1 option 1:
The coverage gap is around 4.1 dB on average compared to CNR of -9.9 dB
1 source observed that there is no coverage gap for PDSCH with SIB1 option 1:
The coverage margin is 3.4 dB compared to CNR of -9.9 dB
10 sources observed that there is a coverage gap for PDSCH with SIB1 option 2:
The coverage gap is around 6.5 dB on average compared to CNR of -9.9 dB
Note: some results assumed SIB1 combination (where SIB1 is repeated within 160 ms) and some results assumed no SIB1 combination
Note: the results above are obtained independently from the performance of other channels or signals, and it doesn’t imply the successful reception for other channels or signals before or after the detection of PDSCH carrying SIB1.
Observation
Based on LLS results on PDSCH SIB19 coverage evaluation collected from different sources:
It is observed that the required SNR for PDSCH carrying SIB19 is in average equal to – 6.9 dB (14 sources)
With parameter LEO600km Set1-1 FR1 and 1-2 FR1:
12 sources observed that there is no coverage gap for PDSCH with SIB19:
The coverage margin is around 4.2 dB on average compared to CNR of -1.9 dB
With parameter LEO600km Set1-3 FR1:
10 sources observed that there is a coverage gap for PDSCH with SIB19:
The coverage gap is around 3.5 dB on average compared to CNR of -9.9 dB
Note: all the results above assumed no SIB19 combination
Note: the results above are obtained independently from the performance of other channels or signals, and it doesn’t imply the successful reception for other channels or signals before or after the detection of PDSCH carrying SIB19.
Observation
Based on the results of DL coverage ratio evaluation at system level collected from 7 sources for all the three LEO600km satellite parameter sets where the beam footprint diameter is 50 km:
For Set 1-1/1-3, the coverage ratio can be improved from 10% to 100% if the SSB periodicity is increased from 20ms to 80ms and beam hopping is applied
For Set 1-2, the coverage ratio can be improved from 1.5% to 96.8% if the SSB periodicity is increased from 20ms to 320ms and beam hopping is applied.
Note: coverage ratio is N2+N3/ total beam footprints
Note: the baseline assumes no beam hopping. TDM between SIB1 and SIB19 is assumed in those results, following current specs.
Based on the results of DL coverage ratio evaluation at system level collected from 3 sources for a deployment scenario implementing wide beam footprint:
1 source reports that with a deployment of wide beam covering 4 narrow (of 50km size) beams, which means Set 1-2 FR1 with additional EIRP reduction of 6dB, using SSB periodicity of 80 ms can provide coverage ratio of 96.8%, and Set 1-1/1-3 FR1 with additional EIRP reduction of 6dB, SSB periodicity of 80 ms can provide coverage of 100%.
1 source observed that for Set 1-1, 1-2 and 1-3, the coverage ratio can be improved from 1.5% to 100% using the legacy default SSB periodicity of 20ms during initial access, by choosing a wide beam footprint with beam footprint sizes of 84 km and 56 km respectively.
Note: the PDCCH and the PDSCH for SIB19 is assumed to be transmitted within 2 OFDM symbols and 5 MHz bandwidth. the PDSCH for SIB1 is assumed to be transmitted within 3 OFDM symbols and 5 MHz bandwidth. This assumes no SIB1 and SIB19 transmission in N2 beam footprints. This assumes non-aligned SFN timing across different beams.
1 source observed, for Set 1-1 with increased beam size, that the legacy SSB periodicity of 20ms during initial access is usable with NTN beam hopping, by choosing a deployment scenario implementing wide beam footprint with beam footprint sizes of 70.7 km and 86.6 km, leading to a total of 529 and 353 beam footprints within the satellite coverage area, respectively, and the coverage ratio is 80% and 90%, respectively, and a ratio of simultaneously active beam footprints to the total number of beam foot prints equal to 20% and 30%.
Note: Beam footprint size is increased by increasing only the adjacent beam spacing without increasing the 3dB beamwidth.
Note: RAN1 will further investigate the impact of SSB periodicity extension
Note: Any needed clarification “SSB channel enhancement is not considered” in the WID is up to RAN plenary
Note: RAN1 will further investigate the impact of wider beam of SSB and/or other channels on performance (e.g. link budget, capacity...)
Observation
Based on LLS results on PDSCH for VoIP coverage evaluation collected from different sources:
It is observed that the required SNR for PDSCH for VoIP is in average equal to – 11 dB (11 sources)
With parameter LEO600km Set1-1 and 1-2 FR1:
When PDSCH repetition is enabled, 11 sources observed that there is no coverage gap for VoIP:
The coverage margin is around 9.1 dB on average, compared to CNR of -1.9 dB
With parameter LEO600km Set1-3 FR1:
When PDSCH repetition is enabled, 9 sources observed that there is no coverage gap for VoIP:
The coverage margin is around 2.3 dB on average, compared to CNR of -9.9 dB
1 source observed that even with 8 PDSCH repetitions there is a coverage gap of 1.5 dB compared to CNR of -9.9 dB
Note: the results above are obtained independently from the performance of other channels or signals, and it doesn’t imply the successful reception for other channels or signals before or after the detection of PDSCH for VoIP.
Observation
Based on LLS results on PDSCH 3kbps coverage evaluation collected from different sources:
It is observed that the required SNR for PDSCH for low data rate is in average equal to – 11 dB (8 sources)
With parameter LEO600km Set1-1 FR1 and 1-2 FR1:
When PDSCH repetition is enabled, 8 sources observed that there is no coverage gap for PDSCH with 3kbp:
The coverage margin is around 9.1 dB on average, compared to CNR of -1.9 dB
With parameter LEO600km Set1-3 FR1:
When PDSCH repetition is enabled, 6 sources observed that there is no coverage gap for PDSCH with 3kbp:
The coverage margin is around 1.6 dB on average, compared to CNR of -9.9 dB
Note: the results above are obtained independently from the performance of other channels or signals, and it doesn’t imply the successful reception for other channels or signals before or after the detection of PDSCH 3kbps.
Observation
Based on LLS results on PDSCH 1Mbps coverage evaluation collected from different sources:
It is observed that the required SNR for PDSCH with 1Mbps data rate is in average equal to – 4.1 dB (7 sources)
With parameter LEO600km Set1-1 FR1 and 1-2 FR1:
7 sources observed that there is no coverage gap for PDSCH with 1Mbps:
The coverage margin is around 2.2 dB on average, compared to CNR of -1.9 dB
With parameter LEO600km Set1-3 FR1:
5 sources observed that, there is a coverage gap for PDSCH with 1Mbps:
The coverage gap is around 5.5 dB on average, compared to CNR of -9.9 dB
Note: the results above are obtained independently from the performance of other channels or signals, and it doesn’t imply the successful reception for other channels or signals before or after the detection of PDSCH 1Mbps.
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Work in RAN1 is limited to checking whether any essential changes are needed for their support (i.e. focusing on HD collision rules) by end of Q2/2024.
Conclusion
For Rel-19 HD-FDD RedCap/eRedCap UE in NTN, the issues caused by TA mismatch between actual TA used by the UE and assumed TA for the UE at the gNB should be mitigated for collision cases 3 and 4.
Note: further discussion on other cases is not precluded
Conclusion
For collision cases 1, 2, 5 and 6, the existing priority rules can be reused for a HD-FDD (e)RedCap UE in NTN.
Observation
TA reporting is beneficial to mitigate the TA mismatch between actual TA used by the UE and assumed TA for the UE at the gNB for HD-FDD RedCap/eRedCap UE in NTN from RAN1 perspective.
Note: complexity, power consumption and signaling overhead impact of TA reporting for (e)redcap UEs was not investigated in this work item
NR-NTN uplink capacity/throughput enhancement
Agreement
For the normative phase, at least one of the OCC techniques will be specified:
Inter-slot time-domain OCC with PUSCH repetition Type A with OCC length 2 or 4
Inter-symbol(s) time domain OCC with OCC length 2 or 4
Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4) with OCC length 2 or 4
FFS Combination of OCC techniques including multiplexing of 8 UEs
FFS Use of OCC techniques with TBoMS
FFS Backward compatibility with non-Rel-19 UEs
Conclusion
OCC with PUSCH can support at least multiplexing of 2 or 4 UEs and achieve up to 2 or 4 times capacity gains respectively, when repetitions are used.
Note: the actual gain may be less due to e.g. intra/inter cell interference.
3GPP TSG RAN WG1 Meeting #118
NR-NTN downlink coverage enhancement
Observation
Based on the results of DL coverage evaluation at system level collected from different sources, it is observed that extending the default value of SSB periodicity (different from 20ms) in NTN with LEO600km satellite parameter sets where the beam footprint diameter is 50 km, is beneficial in terms of reduction of common control channel overhead, when targeting a full coverage of 1058 beam footprints:
With Set 1-1 FR1 and Set 1-3 FR1, the common messages (SSB, SIB1) overhead is around 40% assuming 5 MHz BW when SSB/SIB1 periodicity of 20ms is in use, this overhead ratio could be reduced to less than 14% when 160ms SSB/SIB1 periodicity is used.
With Set 1-2 FR1, the common message (SSB, SIB1) overhead is greater than 100% assuming 5 MHz BW when SSB/SIB1 periodicity of 20ms is in use, this overhead could be reduced to around 25.8% when 640ms SSB/SIB1 periodicity is used.
Note: the overhead of SIB19 was included in some of the results
Note: an observation when SSB/SIB1 periodicity is 320 ms will be discussed and added to the observation
Agreement
As part of the NTN DL coverage enhancements at both system level and link level, RAN1 to consider:
Extending the periodicity of the half frames with SS/PBCH blocks assumed by UE during initial access.
Default value[s] with extended periodicity assumed by NTN UE for initial access can be:
One [or more] values from the list {40ms, 80 ms, 160 ms, 320ms, 640ms}
Potential enhancements for transmitting the DL common channels using a wider beam footprint, while DL/UL dedicated channels (incl. PRACH) may be transmitted using a narrower beam footprint
Link-level enhancements for the following channels:
PDCCH
PDSCH with Msg 4
PDSCH with SIB1/SIB19.
Note: link-level enhancements for PDSCH with SIB1/SIB19 may be applicable to other SIBs, without additional specification impact.
Note: the above does not imply that all the channels above will be enhanced, but all of them should be considered based on this agreement
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Agreement
The collision case 3 (Semi-statically configured DL reception collides with semi-statically configured UL transmission) can’t be assumed as error case. When the collision happens at UE side for collision case 3, one of the following options on priority rules is supported.
Option A: the priority of keeping one direction and overriding another direction is based on different use cases (e.g. the collision happening in different channel types or different scheduling cases) without network signalling
It is not precluded that some or all use cases are left to UE implementation regarding whether DL reception or UL transmission is dropped
Note: it is not precluded that the same direction is prioritized for all different use cases
Option B: network indicates the priority configuration to the UE
It is not precluded that some use cases are left to UE implementation regarding whether DL reception or UL transmission is dropped
It is not precluded to define default rules, if necessary
Agreement
To mitigate the collisions of case3 and case4, the following TA reporting enhancements for Rel-19 NTN HD-FDD (e)Redcap UE can be further studied:
Finer TA report granularity
Smaller TA offset threshold
Trigger a TA report when the collision is detected at the UE
TA reporting with a new triggering mechanism from gNB
TA drifting rate reporting
Note: The benefit, complexity, power consumption and signaling overhead of each scheme is to be further investigated.
Note: other solutions can also be studied
NR-NTN uplink capacity/throughput enhancement
Agreement
At least one of the OCC techniques when PUSCH repetitions are used will be specified:
Inter-slot time-domain OCC with OCC length 2
Inter-slot time-domain OCC with OCC length 2 and 4
Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4) with OCC length 2
Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4) with OCC length 2 and 4
Note: combination of techniques is not precluded
PUSCH repetition Type B is not considered
Conclusion
Multiplexing of 8 UEs with PUSCH OCC is not discussed in RAN1 until the work for multiplexing of less than 8 UEs has been completed.
3GPP TSG RAN WG1 Meeting #118bis
NR-NTN downlink coverage enhancement
Agreement
For NR NTN, support extended periodicity of the half frames with SS/PBCH blocks assumed by UE during initial access.
The maximum of the additional default value (apart from the existing 20ms value) is at least 160 ms.
FFS: whether 320ms can be supported as the maximum of the additional default value instead of or in addition to 160ms
Agreement
Support PDCCH CSS Link level enhancement in Rel-19 for all CSS types except type 3.
The following techniques are for further study:
PDCCH repetition, including:
Option 1: Intra-slot PDCCH repetition
Option 2: Inter-slot PDCCH repetition
CORESET length (i.e. number of OFDM symbols) extension
DCI format optimization (e.g. size reduction, etc)
Note: the same technique is intended to apply to all search space types targeted for link level enhancements
For the above techniques, at least the following aspects should be discussed for the relevant candidate techniques:
Configuration
Backward compatibility and UE behaviour of legacy UE
Linked Search Space
Blocking probability
DCI format size budget
Resource overhead
Impact on CORESET0
Focus on coverage enhancement for set 1-3 with a target CNR of -8 dB for NR NTN DL coverage enhancements at link level.
FFS: whether to apply the selected solution to PDCCH CSS type3 and PDCCH USS
Agreement
For PDSCH with Msg4 Link level enhancement:
Continue studying PDSCH repetition
Further discuss the specification impact for at least the following:
Procedure and signaling
Repetition factor
Focus on coverage enhancement for set 1-3 with a target CNR of -8 dB for NR NTN DL coverage enhancements at link level.
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Conclusion
The different use cases (e.g. the collision happening in different channel types or different scheduling cases) from RAN1#118 agreement for collision case 3 (Semi-statically configured DL reception collides with semi-statically configured UL transmission) consist of pairs of one semi-statically configured DL reception and one semi-statically configured UL transmission, among:
Semi-statically configured DL reception includes Type-0/0A/0B/1/2-PDCCH CSS and dedicated semi-statically configured PDCCH USS/PDSCH SPS/CSI-RS/PRS/[Type 3 PDCCH CSS]
Semi-statically configured UL transmission includes semi-statically configured PUSCH/PUCCH/SRS
NR-NTN uplink capacity/throughput enhancement
Working assumption
For the normative phase,
Support OCC length 2 with inter-slot OCC to multiplex up to 2 UEs.
Support OCC length 4 with one of the following OCC techniques
Option 1: Inter-slot with OCC length 4 to multiplex up to 4 UEs.
Option 2: Intra-symbol pre-DFT OCC with OCC length 4 to multiplex up to 4 UEs.
Option 3: Combination of Inter-slot OCC with OCC length 2 and intra-symbol pre-DFT OCC with OCC length 2 to multiplex up to 4 UEs.
Note 1:
At least consider 8 slots, 16 slots, and 20 slots for VoIP with BLER 2% target, with 1 RB, 2 RBs when comparing Option 1, Option 2, and Option 3. Companies can additionally report on 4 slots at least for 2 RBs.
Option 2 assumes TBoMS, FFS Option 3 assumes TBoMS
Note 2: as part of the working assumption, it is assumed that there would be separate UE capabilities for OCC length 2 and OCC length 4, where UE capability for OCC length 2 is a prerequisite for UE capability for OCC length 4.
Conclusion
For TBS calculation and rate matching for OCC with PUSCH, for inter-slot OCC in the working assumption of RAN1#118bis:
for inter-slot OCC for OCC length 2 and for inter-slot OCC for OCC length 4 in option 1 in the working assumption of RAN1#118bis
No change in determination of TBS
No change for rate matching
Agreement
For RV cycling for OCC with PUSCH
For inter-slot OCC for OCC length 2 and for inter-slot OCC for OCC length 4 in option 1 in the working assumption of RAN1#118bis
Same RV value is used in one OCC group (i.e., OCC length applied to N slots).
FFS: RV cycling can be additionally used across OCC groups
Agreement
For OCC sequence for OCC with PUSCH:
For OCC length 2, re-use orthogonal sequence [1 1; 1 -1]
3GPP TSG RAN WG1 Meeting #119
NR-NTN downlink coverage enhancement
Agreement
For PDSCH with Msg4 Link level enhancement:
Support PDSCH repetition
FFS: signalling design including number of repetitions
FFS: impact on UE capability
Note: the target coverage enhancement to bridge the gap with respect to single Msg4 transmission is 2.8 dB
Focus on coverage enhancement for set 1-3 with a target CNR of -8 dB for NR NTN DL coverage enhancements at link level.
Observation
Backward compatibility for legacy UEs (i.e. Rel-17 and Rel-18 UEs) assuming a default SSB periodicity of 20ms is not guaranteed when SS/PBCH blocks periodicity is larger than 20ms within the cell used for initial frequency scan.
Legacy UEs (i.e. Rel-17 and Rel-18 UEs) are not expected to be able to camp on a cell with SS/PBCH blocks periodicity larger than 160 ms.
Agreement
For link level enhancement of PDSCH with SIB1:
Support PDSCH repetitions within 20 ms duration
The number of repetitions is fixed to 2 repetitions
Further discuss the specification impact for at least the following:
Procedure and signaling (enabling repetitions, associated time resource determination, etc.)
Note 1: without the above PDSCH repetitions, the coverage gap is 2.2 dB to 4.6 dB depending on SIB1 size.
Note 2: Focus on coverage enhancement for set 1-3 with a target CNR of -8 dB for NR NTN DL coverage enhancements at link level.
Note 3: the above is not related to multiple SIB1 transmissions across 20 ms periodicities of SSB, which may not be available when the SSB periodicity is 160 ms or larger (if supported) depending on the SSB and CORESET multiplexing pattern.
Agreement
For PDCCH CSS (except Type-3) link level enhancements, support only PDCCH repetition for NTN.
FFS: intra-slot and/or inter-slot
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Agreement
For Rel-19 HD-FDD (e)Redcap UE in RRC connected mode, for collision case 3,
Handling of collision with Type-0/0A/1/2-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 3 in RRC-Connected mode is that DL is prioritized.
Network is allowed to indicate UL overriding DL for all the other use cases above
This is signaled by RRC configuration
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13.
Agreement
The collision case 4 (Dynamically scheduled DL reception collides with dynamic scheduled UL transmission) is not considered as an error case for Rel-19 HD-FDD (e)Redcap UE in RRC connected mode.
FFS whether to prioritize UL or prioritize DL
NR-NTN uplink capacity/throughput enhancement
Agreement
RAN1 to confirm the working assumption of RAN1#118bis with revisions as follows:
Support OCC length 2 with inter-slot OCC to multiplex up to 2 UEs.
Support Option 1: inter-slot OCC with OCC length 4 to multiplex up to 4 UEs using Hadamard sequences
RAN1 does not pursue Option 2: Intra-symbol pre-DFT OCC with OCC length 4 to multiplex up to 4 UEs.
RAN1 does not pursue Option 3: Combination of Inter-slot OCC with OCC length 2 and intra-symbol pre-DFT OCC with OCC length 2 to multiplex up to 4 UEs.
Note 1: there will be separate UE capabilities for OCC length 2 and OCC length 4, where UE capability for OCC length 2 is a prerequisite for UE capability for OCC length 4.
Note 2: gNB can ensure the performance of Option 1 by UE grouping with similar CFO (e.g. maximum differential CFO of 50 or 100 Hz or 200 Hz). Without CFO grouping (e.g. maximum differential CFO of 400 Hz), the performance of option 1 is degraded by at least 1 dB in several cases. For CFO grouping, several companies in RAN1 state that CFO grouping is feasible based on network implementation without any new specification impact.
RAN1 assumes no specification impact for CFO grouping
RAN1 does not pursue closed-loop frequency adjustment commands.
RAN1 assumes that RAN4 does not define new UE requirements for CFO.
Observation:
Option 1 Inter-slot OCC with OCC length 4 to multiplex up to 4 UEs with 2 PRBs can meet VoIP 2% BLER within 1 dB of single UE baseline for 8 slots or larger with UE grouping with similar CFO (e.g. maximum differential CFO of 200 Hz).
Observation:
Option 2 Intra-symbol pre-DFT OCC with OCC length 4 to multiplex up to 4 UEs with TBoMS can meet VoIP 2% BLER target within 1 dB of single UE baseline with 2 PRBs and 4 repetitions or larger; and with 1 PRB and 8 repetitions or larger, without need for CFO grouping.
Agreement
For RV cycling for OCC with DG-PUSCH, the following are considered:
Option 1: RV cycling is used across OCC groups
Note 1: RV cycling is applied when the number of repetitions is greater than the OCC length
Option 2: Fixed RV is used across OCC groups
Option 3: For OCC length 2, fixed RV is used across two OCC groups, RV cycling is used across groups of two OCC groups
Agreement
If PUCCH without repetition overlaps with inter-slot OCC with any PUSCH repetitions in an OCC group, the following options to be considered:
Option 1: UCI is dropped
FFS: whether all UCI is dropped
Option 2: UCI is transmitted on PUCCH, and all PUSCH repetitions within the OCC group are dropped.
Option 3: UCI is multiplexed on PUSCH with inter-slot OCC
Option 3-a: UCI is multiplexed on all PUSCH repetitions within an OCC group with inter-slot OCC
FFS: which OCC group
Option 3-b: UCI is multiplexed on PUSCH and OCC is not applied within the OCC group
Option 3-c: UCI is multiplexed on PUSCH and OCC is not applied within the PUSCH repetitions
Note: combination of the above can be considered
FFS Details timeline of PUCCH and PUSCH
FFS: handling of PUCCH with repetition
FFS: handling of different UCI types
3GPP TSG RAN WG1 Meeting #120
NR-NTN downlink coverage enhancement
Agreement
For NR NTN, support extended periodicity of the half frames with SS/PBCH blocks assumed by UE during initial access.
The additional default value assumed by UE during initial access (apart from the existing 20ms value) is 160 ms.
Agreement
Support only inter-slot repetition for Type0 PDCCH CSS.
Agreement
For Msg4 PDSCH repetition support, RAN1 to consider:
Option 1: UE specific repetition indication via DCI
Option 2: Msg4 repetition is configured by SIB1
Option 3: Msg4 PDSCH repetition is implicitly determined by SIB1 PDSCH repetition
Agreement
At least for enabling PDCCH repetition for Type0 PDCCH CSS of searchSpaceZero configured within MIB pdcch-ConfigSIB1, RAN1 to consider the following options
Option 1: Using the spare 1 bit in MIB
Option 2: Using reserved bit(s) in PBCH payload
Option 3: Using codepoint(s) in PBCH payload
Option 4: UE blind decoding without signaling from the network during initial access
Agreement
For PDCCH repetition for Type0 PDCCH CSS of searchSpaceZero configured within MIB pdcch-ConfigSIB1, consider the following:
Option 1: Support repeated PDCCH candidates in the two consecutive slots and associated with the same SSB index ( as defined in section 13 of TS 38.213)
Repeated PDCCH candidates share the same aggregation level (AL), coded bits and same candidate index
FFS: Details including how the two PDCCH candidates are counted toward the BD limits
Note: with option 1, if the network repeats the Type 0 PDCCH across two consecutive slots, a legacy UE might decode the PDCCH and associated PDSCH in one slot and skip PDCCH monitoring in the other slot.
FFS: whether/how option 1 can be applicable for M=1 and M= ½
Option 2: Support repeated PDCCH candidates in the two slots and [or and ] associated with the same SSB index ( as defined in section 13 of TS 38.213)
Value of X>1, predefined or configured
FFS: Value of X
Repeated PDCCH candidates share the same aggregation level (AL), coded bits and same candidate index
FFS: Backward compatibility to legacy UE
Option 3:
The PDCCH candidates in slots n0 associated respectively with different SSB indexes are repetitions of each other and share the same aggregation level, coded bits and same candidate index
For M=1/2 and M=1, the repeated PDCCH candidates in two consecutive slots associated with different SSB indexes;
For M=2, the PDCCH candidates in slots n0+1 associated respectively with different SSB indexes are repetitions of each other and share the same aggregation level, coded bits and same candidate index
Option 4: Option 2 with cross SSB beam repetition support
The PDCCH candidates in slots n0 associated respectively with different SSB indexes are repetitions of each other and share the same aggregation level, coded bits and same candidate index
Agreement
For SIB1 link level enhancement, RAN1 to consider the following options:
Option 1: PDSCH repetition of SIB1 is transmitted within the same slot as the type0-CSS PDCCH repetition.
UE supporting SIB1 PDSCH coverage enhancement assumes that the PDCCH and associated PDSCH to be repeated in both slots where the corresponding PDCCHs are transmitted.
Each PDSCH SIB1 repetition is within the same slot of each PDCCH candidate for scheduling DCI
The two associated PDSCHs have the same RV
Option 2: Option 1 and an additional PDSCH with SIB1 repetition can occur after the slot of type0-PDCCH CSS repetition.
FFS: How to schedule the SIB1 repetition
Option 3: The repetition of PDSCH with SIB1 is indicated by the scheduling PDCCH
PDSCH is repeated in two slots
Note: Backward compatibility should be maintained
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Agreement
When network indicates UL overriding DL in RRC-Connected mode for collision case 3, one UE-specific RRC parameter is used to indicate overriding for all the applicable other use cases except for collisions with Type-0/0A/1/2-PDCCH CSS.
Conclusion
For Rel-19 HD-FDD (e)Redcap UE with CG-SDT procedure ongoing in RRC-inactive mode, for collision case 3,
Handling of collision with PDCCH CSS in RRC-inactive mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_INACTIVE while SDT procedure is not ongoing shall monitor for SI change indication in its own paging occasion(s) that the UE monitors as specified in TS 38.304 [20].
UEs in RRC_INACTIVE while SDT procedure is ongoing shall monitor for SI change indication in any paging occasion at least once per modification period, if the initial downlink BWP on which the SDT procedure is ongoing is associated with a CD-SSB.
ETWS or CMAS capable UEs in RRC_INACTIVE while SDT procedure is not ongoing shall monitor for indications about PWS notification in its own paging occasion every DRX cycle.
ETWS or CMAS capable UEs in RRC_INACTIVE while SDT procedure is ongoing shall monitor for indication about PWS notification in any paging occasion at least once every defaultPagingCycle.
Working assumption
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A[/1][/2]-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
FFS: handling of PDCCH ordered PRACH transmission
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that [DL or UL] is prioritized.
Network is allowed to indicate [UL or DL] overriding [DL or UL] for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13.
NR-NTN uplink capacity/throughput enhancement
Conclusion
For OCC time synchronization / alignment of multiplexed UEs to maintain orthogonality of the codes used for OCC, OCC group alignment is handled by network scheduling without specification impact.
Conclusion
OCC with Msg3 PUSCH is not in scope of Release 19 NR NTN Ph3.
Agreement
For RV cycling for OCC with DG-PUSCH, support Option 1
Option 1: RV cycling is used across OCC groups.
Note: when option 1 is applied, RV cycling is applied when the number of repetitions is greater than the OCC length
No optimization in Rel-19 for pairing UEs with OCC2 and UEs with OCC4.
|
3GPP TSG RAN WG1 #120bis R1-2503115
Wuhan, China, April 7th – 11th, 2025
Agenda Item: 9.11
Source: Ad-Hoc Chair (Huawei)
Title: Session notes for 9.11 Non-Terrestrial Networks (NTN) for NR Phase 3, Internet of Things (IoT) Phase 3, and IoT-NTN TDD mode
Document for: Discussion, Decision
Non-Terrestrial Networks (NTN) for NR Phase 3, Internet of Things (IoT) Phase 3, and IoT-NTN TDD mode
Please refer to RP-243300 for detailed scope of the WI for NR-NTN Phase 3. Please refer to RP-250472 for detailed scope of the WI for IoT-NTN Phase 3. Please refer to RP-243293 for detailed scope of the WI for Introduction of IoT-NTN TDD mode.
[120bis-R19-NTN] Email discussion on Rel-19 NTN enhancement – Mohamed (Thales)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2501729 Work plan for Rel-19 NR_NTN_Ph3 THALES, CATT
R1-2501842 RAN1 agreements for NR NTN Phase 3 up to RAN1#120 THALES
R1-2502056 Work plan for WID: introduction of IoT-NTN TDD mode Iridium Satellite LLC
R1-2502566 Initial RRC parameters list for Rel-19 NR NTN Phase 3 THALES
NR-NTN downlink coverage enhancement
R1-2501723 NR NTN Downlink coverage enhancements THALES
R1-2501822 Discussion on NR-NTN downlink coverage enhancement vivo
R1-2501841 On NR-NTN downlink coverage enhancement Ericsson
R1-2501847 Discussion on downlink coverage enhancements for NR NTN CCU
R1-2501880 Discussion on NR-NTN downlink coverage enhancement Spreadtrum, UNISOC
R1-2501890 Discussion on downlink coverage enhancement for NR NTN Fraunhofer IIS, Fraunhofer HHI
R1-2501899 Discussion on DL coverage enhancement for NR NTN ZTE Corporation, Sanechips
R1-2501972 Discussion on downlink coverage enhancement for NR NTN CATT
R1-2502031 Further Discussion on NR NTN downlink coverage enhancement China Telecom
R1-2502082 NR-NTN downlink coverage enhancement NEC
R1-2502130 Discussion on downlink coverage enhancements Fujitsu
R1-2502173 Discussion on NR-NTN DL coverage enhancement CMCC
R1-2502188 NR-NTN downlink coverage enhancement InterDigital, Inc.
R1-2502219 Discussion on downlink coverage enhancements for NR NTN Huawei, HiSilicon
R1-2502265 Discussion on NR-NTN downlink coverage enhancement OPPO
R1-2502383 Discussion on downlink coverage enhancement for NR-NTN Samsung
R1-2502454 Discussion on NR-NTN downlink coverage enhancement Xiaomi
R1-2502473 Discussion on DL coverage enhancements for NR-NTN NICT
R1-2502488 Discussion on downlink coverage enhancement for NR NTN Baicells Technologies Co. Ltd
R1-2502519 Discussion on NR-NTN downlink coverage enhancement ETRI
R1-2502532 Discussions on downlink coverage enhancements Nokia, Nokia Shanghai Bell
R1-2502549 Discussion on NR-NTN downlink coverage enhancement TCL
R1-2502559 NR-NTN Downlink Coverage Enhancement Panasonic
R1-2502629 On NR-NTN Downlink Coverage Enhancement Apple
R1-2502695 Discussion on NR-NTN downlink coverage enhancement HONOR
R1-2502716 NR-NTN downlink coverage enhancement MediaTek Inc.
R1-2502727 Discussion on downlink coverage enhancement for NR-NTN CSCN
R1-2502779 Discussion on DL coverage enhancement for NR-NTN NTT DOCOMO, INC.
R1-2502815 Discussion on NR-NTN downlink coverage enhancement LG Electronics
R1-2502822 Discussion on downlink coverage enhancement for NR NTN Lenovo
R1-2502854 Downlink coverage enhancement for NR NTN Qualcomm Incorporated
R1-2502902 Discussion on Downlink Coverage Enhancement for NR NTN Google Korea LLC
R1-2502920 Discussion on Downlink Coverage Enhancements for NR NTN CEWiT
R1-2501725 FL Summary #1: NR-NTN downlink coverage enhancements Moderator (THALES)
Agreement
When PDCCH CSS type-0 repetition is performed, for SIB1 link level enhancement, support PDSCH repetition of SIB1 transmitted within the same slot as the type0-CSS PDCCH repetition.
UE supporting SIB1 PDSCH coverage enhancement assumes that the PDCCH and associated PDSCH to be repeated in both slots where the corresponding PDCCHs are transmitted.
Each PDSCH SIB1 repetition is within the same slot of each PDCCH candidate for scheduling DCI
The two associated PDSCHs have the same RV
FFS: Whether it is supported that type-0 PDCCH repetition is not performed while the PDSCH-SIB1 repetition is performed, and if so whether/how to handle the slot determination.
Agreement
For enabling/disabling SIB1 PDSCH repetition, RAN1 to consider the following options:
Option 1: Using reserved bit(s) in PBCH payload.
Option 2: Using scheduling PDCCH.
Option 3: The enabling/disabling of SIB1 PDSCH repetition is implicitly indicating by the enabling/disabling of Type-0 CSS PDCCH repetition.
Agreement
For PDCCH repetition for Type0 PDCCH CSS of searchSpaceZero configured within MIB pdcch-ConfigSIB1:
Enabling/disabling using reserved bit(s) in PBCH payload
No UE behavior is defined for UE in connected mode specifically for the case where the network changes its signaling between enabling and disabling PDCCH repetition for Type0 PDCCH CSS.
R1-2501726 FL Summary #2: NR-NTN downlink coverage enhancements Moderator (THALES)
Agreement
For Msg4 PDSCH repetition scheme, the Msg4 PDSCH is repeated in N consecutive slots:
The same resource allocation is assumed for all repetitions
The supported repetition factors are: 2 and 4
The network configures a single value between 2 and 4 at a given time
The RV cycling is used for each repetition
If N=4:
Agreement
For PDCCH repetition for Type0 PDCCH CSS of searchSpaceZero configured within MIB pdcch-ConfigSIB1, support repeated PDCCH candidates in the two consecutive slots and associated with the same SSB index ( as defined in section 13 of TS 38.213) at least for M=2.
Repeated PDCCH candidates share the same aggregation level (AL), coded bits and same candidate index
Note: if the network repeats the Type 0 PDCCH across two consecutive slots, a legacy UE might decode the PDCCH and associated PDSCH in one slot and skip PDCCH monitoring in the other slot.
Note: further discuss the potential solution for M=1 and M=1/2.
Working assumption
For PDCCH CSS other than Type-0 CSS and other than Type-3 CSS for common search spaces other than SearchSpaceZero, intra-slot PDCCH repetition is supported.
RAN1 to down select between option 1 and option 2:
Option 1: Use same CORESET and two different SS (SS Set1 and SS Set2)
Linking two PDCCH candidates (adopt the same mechanism for SS linking specified in Release 17)
FFS: Blind decoding limit
Option 2: Use same CORESET associated with one SS which is repeated by introducing symbol domain offset X
FFS: Blind decoding limit
FFS: details configuration and signalling
Nokia expressed the concern on the above working assumption that this will take physical resources away from intra-slot scheduling for legacy PDSCH.
Agreement
For enabling/disabling Msg4 PDSCH repetition, RAN1 to down-select among the following options:
Option 1: UE specific PDSCH with Msg4 repetition activation indicated via PDCCH- DCI Format 1_0
FFS: indication details.
FFS: whether/how network is informed by the UE that certain conditions are met to trigger Msg4 PDSCH repetition (e.g. RSRP detected at UE is less than x dB)
Option 2: The enabling/disabling of Msg4 PDSCH repetition is implicitly indicated by the enabling/disabling of SIB1 PDSCH repetition.
Option 3: The enabling/disabling is indicated by SIB1 configuration
FFS: whether/how network is informed by the UE that certain conditions are met to trigger Msg4 PDSCH repetition (e.g. RSRP detected at UE is less than x dB)
FFS: Whether UE reports its capability
R1-2501727 FL Summary #3: NR-NTN downlink coverage enhancements Moderator (THALES)
R1-2501728 FL Summary #4: NR-NTN downlink coverage enhancements Moderator (THALES)
R1-2503127 Summary#1 of discussions on RRC parameters for Rel-19 NR NTN Phase 3 Moderator (THALES)
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
R1-2501757 Discussion on support of HD-FDD (e)RedCap UEs with NR NTN SageRAN
R1-2501823 Discussion on support of RedCap and eRedCap UEs with NR-NTN vivo
R1-2501881 Discussion on support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Spreadtrum, UNISOC
R1-2501900 Discussion on support of RedCap/eRedCap UEs for NR NTN ZTE Corporation, Sanechips
R1-2501973 Discussion on the enhancement of RedCap and eRedCap UEs In NTN CATT
R1-2502032 Discussion on Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands China Telecom
R1-2502174 Discussion on the collision issues of HD-FDD Redcap UE in FR1-NTN CMCC
R1-2502189 Discussion on half-duplex RedCap issues for NTN FR1 operation InterDigital, Inc.
R1-2502220 Discussion on HD-FDD RedCap UEs and eRedCap UEs for FR1-NTN Huawei, HiSilicon
R1-2502266 Discussion on supporting of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands OPPO
R1-2502305 On HD-FDD Redcap UEs for NTN Ericsson
R1-2502384 Discussion on support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Samsung
R1-2502455 Discussion on the support of Redcap and eRedcap UEs in NR NTN Xiaomi
R1-2502520 Discussion on HD UEs with NR NTN ETRI
R1-2502533 Discussion of support for RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Nokia, Nokia Shanghai Bell
R1-2502573 Discussion on HD-FDD RedCap UEs and eRedCap UEs for FR1-NTN TCL
R1-2502630 Discussion on support of RedCap UEs with NR NTN operation Apple
R1-2502651 Support of (e)RedCap UEs with NR NTN Sharp
R1-2502696 Discussion on support of (e)RedCap UEs in NR NTN HONOR
R1-2502717 Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands MediaTek Inc.
R1-2502780 Discussion on support of RedCap and eRedCap UEs in FR1-NTN NTT DOCOMO, INC.
R1-2502816 Discussion on support of (e)RedCap UEs with NR-NTN operating in FR1-NTN bands LG Electronics
R1-2502855 Support of Redcap and eRedcap UEs in NR NTN Qualcomm Incorporated
R1-2502883 Support of RedCap and eRedCap UEs in NR NTN Nordic Semiconductor ASA
R1-2502924 Discussion on support of RedCap/eRedCap UEs in NTN CAICT
R1-2503049 Summary #1 for Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Moderator (CATT)
R1-2503050 Summary #2 for Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Moderator (CATT)
Agreement
Update the working assumption in RAN1 #120 with the following updates:
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the note.
FFS: handling of PDCCH ordered PRACH transmission
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that DL is prioritized.
Network is allowed to indicate UL overriding DL for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13.
R1-2503051 Summary #3 for Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Moderator (CATT)
NR-NTN uplink capacity/throughput enhancement
R1-2501730 On uplink capacity enhancement for NR-NTN Ericsson
R1-2501824 Discussion on NR-NTN uplink capacity enhancement vivo
R1-2501882 Discussion on NR-NTN uplink capacity/throughput enhancement Spreadtrum, UNISOC
R1-2501901 Discussion on UL capacity enhancement for NR NTN ZTE Corporation, Sanechips
R1-2501974 Discussion on UL capacity enhancement for NR NTN CATT
R1-2502033 Discussion on NR-NTN uplink enhancement China Telecom
R1-2502083 NR-NTN uplink capacity/throughput enhancement NEC
R1-2502131 Discussion on uplink capacity/cell throughput enhancement for FR1-NTN Fujitsu
R1-2502175 Discussion on the NR-NTN uplink capacity/throughput enhancements CMCC
R1-2502190 NR-NTN uplink capacity/throughput enhancement InterDigital, Inc.
R1-2502221 Discussion on uplink capacity/throughput enhancement for FR1-NTN Huawei, HiSilicon
R1-2502267 Discussion on NR-NTN uplink capacity/throughput enhancement OPPO
R1-2502385 Discussion on uplink capacity/throughput enhancement for NR-NTN Samsung
R1-2502409 Discussion on the NR-NTN uplink capacity/throughput enhancements TCL
R1-2502456 Discussion on NR-NTN PUSCH capacity enhancement Xiaomi
R1-2502521 Discussion on NR-NTN uplink capacity/throughput enhancement ETRI
R1-2502534 Discussion of NR-NTN uplink capacity enhancements Nokia, Nokia Shanghai Bell
R1-2502589 Discussion on NR-NTN Uplink Capacity/Throughput Enhancement Lenovo
R1-2502631 On NR-NTN Uplink Capacity Enhancement Apple
R1-2502697 Discussion on NR-NTN UL capacity/throughput enhancement HONOR
R1-2502698 Uplink capacity/throughput enhancement for NR-NTN Panasonic
R1-2502718 NR-NTN uplink capacity and throughput enhancements MediaTek Inc.
R1-2502781 Discussion on NR-NTN uplink capacity/throughput enhancement NTT DOCOMO, INC.
R1-2502817 Discussion on NR-NTN uplink capacity/throughput enhancement LG Electronics
R1-2502856 NR-NTN uplink capacity / throughput enhancement Qualcomm Incorporated
R1-2502903 Discussion on NR-NTN uplink capacity/throughput enhancement Google Korea LLC
R1-2502983 Feature lead summary #1 of AI 9.11.3 on NR-NTN uplink capacity and throughput enhancements Moderator (MediaTek)
Agreement
RAN1 assumes that the UE is required to maintain phase continuity and power consistency for the duration of one OCC group with PUSCH.
FFS: under which conditions the above applies, e.g. under the same conditions that phase continuity applies for DMRS bundling
Agreement
Send LS to RAN4 on requirements for the phase continuity and power consistency:
RAN1 has agreed the following:
RAN1 assumes that the UE is required to maintain phase continuity and power consistency for the duration of one OCC group with PUSCH.
FFS: under which conditions the above applies, e.g. under the same conditions that phase continuity applies for DMRS bundling
RAN1 ask RAN4 whether the same phase continuity requirements as for DMRS bundling can be applied for OCC length 2 and/or OCC length 4 under the same conditions as for DMRS bundling, or if new requirements are needed.
R1-2503070 Draft LS on requirements for the phase continuity and power consistency for OCC with PUSCH in NR NTN Ph3
Agreement
The draft LS in R1-2503070 is endorsed. Final LS is in R1-2503071.
Agreement
OCC length and OCC sequence for OCC with CG PUSCH Type 1 is configured by RRC higher-layers.
Up to RAN2 whether to signal this with one or two RRC parameters
Note: OCC lengths and sequences to be provided in the table of RRC parameters to be prepared by the WI rapporteur
Agreement
For OCC with CG-PUSCH, the RV sequence applied across OCC groups is RRC configured among the RV sequences defined for legacy CG PUSCH, i.e., [0,2,3,1], [0,3,0,3] or [0,0,0,0].
Note: no new RRC parameter is needed for the above
FFS: if OCC group dropping is later agreed, how to count RVs may need to be discussed for that case
R1-2502984 Feature lead summary #2 of AI 9.11.3 on NR-NTN uplink capacity and throughput enhancements Moderator (MediaTek)
Agreement
For resolving the overlapping PUSCH repetitions with inter-slot OCC and PUCCH with/without repetitions, the legacy timeline conditions for UCI multiplexing or prioritization for dropping PUSCH [/ PUCCH] applies according with the following update:
“the first PUSCH repetition of an OCC group” is used instead of “PUSCH repetition” for the legacy timeline condition, where the legacy PUSCH repetition that overlaps with a PUCCH belongs to the OCC group
Note: how to capture the above agreement is up to the spec editor.
Agreement
For the OCC length applied for OCC DG PUSCH and CG PUSCH Type 2, consider the following options:
Option 1: Configured by RRC higher-layer parameter.
Note: this does not preclude jointly configuring OCC sequence and OCC length with the same RRC configuration
Option 2: Max value is configured by RRC higher-layer parameter, and the applied value is implicitly determined from the configured repetition number.
Option 3: Candidates values are configured by RRC higher-layer parameter, and the applied value is indicated by scheduling DCI for DG PUSCH or by activation DCI for CG PUSCH Type 2.
Note: this does not preclude jointly configuring OCC sequence and OCC length with the same RRC configuration
Option 4: Single value is indicated by scheduling DCI for DG PUSCH and by activation DCI for CG PUSCH Type 2 (no RRC configuration of candidate values).
Option 5: Max value is configured by RRC higher-layer parameter, and the applied value is indicated by scheduling DCI for DG PUSCH and by activation DCI for CG PUSCH Type 2.
Note: it is not precluded to select a different option for DG PUSCH and CG PUSCH Type 2.
R1-2502985 Feature lead summary #3 of AI 9.11.3 on NR-NTN uplink capacity and throughput enhancements Moderator (MediaTek)
Agreement
If PUCCH without repetitions overlaps with inter-slot OCC with any PUSCH repetitions in an OCC group with a same priority index for PUCCH/PUSCH, the legacy conditions and rules for UCI multiplexing or prioritization for dropping applies with the following updates:
If the UCI is multiplexed on the PUSCH repetition according to legacy rules and the updated timeline conditions for UCI multiplexing are satisfied, UCI is multiplexed on all PUSCH repetitions without A-CSI reports within an OCC group with inter-slot OCC overlaps with the PUCCH. (Option 3-a)
FFS: PUSCH repetition with A-CSI reports
If the PUSCH repetition is dropped according to legacy rules and the updated timeline conditions for PUSCH dropping are satisfied, UCI is transmitted on PUCCH and all PUSCH repetitions within the OCC group that overlaps with the PUCCH are dropped (Option 2)
FFS: if PUCCH is overlap with PUSCH repetition in both time and frequency domain.
UE does not expect there are multiple PUCCHs without repetitions in different PUCCH slots with a same or different UCI types other than SR overlapping with multiple PUSCH repetitions in the same OCC group.
FFS: whether the above applies only when at least one of the overlapping PUCCHs result in a UCI being multiplexed on the PUSCH
Note 1: If the UCI on the PUCCH is dropped according to legacy rules and [updated] timeline conditions for UCI dropping are satisfied, there is no [additional] spec impact. (Option 1)
Note 2: There can be multiple PUCCHs with same or different UCI types in the same slot (i.e. CSI report and HARQ-ACK) as in the legacy specifications
Working assumption 1: The above agreement applies to different priority indexes for PUCCH/PUSCH if no additional specification impact is identified.
Working assumption 2: The above agreement applies to PUCCH with repetitions if no additional specification impact is identified.
Agreement
For the OCC sequence applied for OCC DG PUSCH and CG PUSCH Type 2, the sequence is indicated dynamically in DCI
FFS: with a new field or reusing an existing field
IoT-NTN uplink capacity/throughput enhancement
R1-2501825 Discussion on IoT-NTN uplink capacity enhancement vivo
R1-2501883 Discussion on IoT-NTN uplink capacity/throughput enhancement Spreadtrum, UNISOC
R1-2501902 Discussion on UL capacity enhancement for IoT NTN ZTE Corporation, Sanechips
R1-2501975 Discussion on UL capacity enhancement for IoT NTN CATT
R1-2502084 IoT-NTN uplink capacity/throughput enhancement NEC
R1-2502094 IoT-NTN uplink capacity enhancement Nokia, Nokia Shanghai Bell
R1-2502176 Discussion on the IoT-NTN uplink capacity/throughput enhancements CMCC
R1-2502191 IoT-NTN uplink capacity/throughput enhancement InterDigital, Inc.
R1-2502222 Discussion on UL capacity enhancements for IoT NTN Huawei, HiSilicon
R1-2502268 Discussion on IoT-NTN uplink capacity/throughput enhancement OPPO
R1-2502306 On uplink capacity enhancements for IoT-NTN Ericsson
R1-2502330 On IoT-NTN uplink capacity enhancements Sony
R1-2502333 Final FL Summary for IoT-NTN Moderator (Sony)
R1-2502344 IoT NTN OCC signaling for NPUSCH Sharp
R1-2502386 Discussion on uplink capacity/throughput enhancement for IoT-NTN Samsung
R1-2502457 Discussion on IoT-NTN uplink capacity enhancement Xiaomi
R1-2502522 Discussion on uplink capacity/throughput enhancement for IoT NTN ETRI
R1-2502560 Discussion on the IoT-NTN uplink capacity/throughput enhancements TCL
R1-2502632 Discussion on IoT-NTN Uplink Capacity Enhancement Apple
R1-2502719 IoT-NTN uplink capacity and throughput enhancement MediaTek Inc.
R1-2502818 Discussion on IoT-NTN uplink capacity/throughput enhancement LG Electronics
R1-2502823 Discussion on uplink capacity enhancement for IoT NTN Lenovo
R1-2502857 IOT-NTN uplink capacity/throughput enhancement Qualcomm Incorporated
R1-2502882 IoT-NTN uplink capacity/throughput enhancement Nordic Semiconductor ASA
R1-2502331 FL Summary #1 for IoT-NTN Moderator (Sony)
Agreement
For the 3.75kHz SCS symbol-based OCC scheme, the granularity of spreading for data is one symbol.
Agreement
Dynamic activation / deactivation of OCC is supported by DCI.
FFS: details of signalling by DCI
Conclusion
RAN1 assumes no specification change to support pairing UEs with different modulation orders.
Agreement
For 3.75kHz SCS OCC for NPUSCH format 1, RAN1 down selects between the following mappings between DMRS sequence samples and active TDM DMRS slots:
Option 1: Sequential mapping of samples of the original DMRS sequence to active DMRS slots
Option 2: Dropping of samples of the original DMRS sequence in blanked slots
R1-2502332 FL Summary #2 for IoT-NTN Moderator (Sony)
Agreement
For NPUSCH Format 1 single-tone 15kHz SCS, for CDM DMRS with legacy pattern:
DMRS symbols are spread before the OCC is applied
Option 1_1: according to the formula:
, m=0, …, M-1
Where: M is the OCC length, q is the assigned OCC codeword for the UE, is the reference signal sequence defined in TS36.211 section 10.1.4.1.1 and X is the total number of slots in the NPUSCH transmission after OCC is applied
Agreement
The OCC sequence index is signalled using DCI format N0.
Agreement
The RRC parameters for IoT-NTN UL capacity enhancements are:
R1-2503122 FL Summary #3 for IoT-NTN Moderator (Sony)
Agreement
For indicating OCC sequence index and activation / deactivation, the following fields may be repurposed or constrained to be not present in the DCI:
Modulation and coding scheme
Repetition number
Redundancy version
Number of scheduled TB for Unicast
Subcarrier indication
Resource reservation
IoT-NTN TDD mode
R1-2501724 Discussion on IoT-NTN TDD mode THALES
R1-2501826 Discussion on IoT-NTN TDD mode vivo
R1-2501884 Discussion on IoT-NTN TDD mode Spreadtrum, UNISOC
R1-2501903 Discussion on the IoT-NTN TDD mode ZTE Corporation, Sanechips
R1-2501976 Discussion on Physical layer design of IoT-NTN TDD CATT
R1-2502057 Remaining aspects of loT-NTN TDD mode Iridium Satellite LLC
R1-2502059 Stage 2 proposal (for RAN2 TS 36.300) for Introduction of IoT-NTN TDD mode Iridium Satellite LLC
R1-2502095 Discussion on IoT-NTN TDD mode Nokia, Nokia Shanghai Bell
R1-2502177 Discussion on the new NB-IoT NTN TDD mode CMCC
R1-2502223 Discussion on IoT-NTN TDD mode Huawei, HiSilicon
R1-2502269 Discussion on IoT-NTN TDD mode OPPO
R1-2502345 IoT NTN TDD guard period and uplink segmentation Sharp
R1-2502387 Discussion on IoT-NTN TDD mode Samsung
R1-2502458 Discussion on IoT-NTN TDD mode Xiaomi
R1-2502633 Discussion on IoT-NTN TDD mode Apple
R1-2502782 Discussion on IoT-NTN TDD mode NTT DOCOMO, INC.
R1-2502819 Discussion on IoT-NTN TDD mode LG Electronics
R1-2502824 Discussion on IoT-NTN TDD mode Lenovo
R1-2502858 IOT-NTN TDD mode Qualcomm Incorporated
R1-2502881 On R19 TDD IoT-NTN Nordic Semiconductor ASA
R1-2502999 Feature lead summary #1 on IoT-NTN TDD mode Moderator (Qualcomm Incorporated)
Agreement
Confirm the following working assumption:
Uplink transmission gaps do not apply in NB-IoT NTN TDD.
Agreement
NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s). The unit of postponement is one PRU.
NOTE: “U NB-IoT subframes” are subframes contained within the set of U=8 usable consecutive uplink subframes in the TDD structure.
NPRACH periodicities of 40ms and 80ms are not supported in NB-IoT NTN TDD mode
Instead, periodicities of 90ms and 180ms are supported
Agreement
The guard period between the end of the downlink subframes and the beginning of the uplink subframes is fixed in specifications to be 50ms at the ULSRP.
NOTE: This roughly corresponds to the largest separation between DL and UL Iridium slot pairs.
Note: Adjustments to align with different UL/DL pair can be achieved by adjusting the common TA.
R1-2503081 Feature lead summary #2 on IoT-NTN TDD mode Moderator (Qualcomm Incorporated)
Agreement
For the issue of handling DL gaps in NB-IoT NTN TDD mode, down-select among the following options:
Option 1: DL gaps do not apply for NB-IoT NTN TDD mode.
Option 2: DL gaps apply based on current specifications.
Option 3: DL gaps apply, where new periodicity(ies) are introduced (either implicity e.g. the periodicity is scaled by a fixed factor F, or explicitly)
Agreement
For the issue of handling NPDCCH postponing, down-select among the following options:
Option 1: No new periodicities are introduced for NPDCCH search space monitoring
FFS: Changes in postponing / overlapping rules, if any
FFS: Introduction of constraints on the configuration of search space parameters (e.g. Rmax, G…), if any
Option 2: New periodicities are introduced for NPDCCH search space monitoring
FFS: Details of the new periodicity, e.g. the existing periodicity is scaled by a fixed factor F, explicit signalling of the new periodicity, reusing the NB-IoT TN TDD periodicities, etc.
Working assumption
DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) is not present in a NB-IoT NTN TDD cell.
NOTE1: All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE2: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
Agreement
SIB1-NB is dropped in non-D NB-IoT subframes
NOTE 1: “non-D NB-IoT subframes” are subframes not contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
NOTE 2: RAN1 observes that some combinations of {TBS, number of repetitions, additional SIB1 repetitions}, and depending on aspects such as minimum elevation angle or antenna gain, may not meet the link budget. It is up to the network to properly configure such values to ensure the link budget is met. No specification impact.
Agreement
For GNSS measurement gap, RAN1 to further discuss at least the following options:
Option 1: No enhancement on the Rel-18 timeline for the start of GNSS gap
Option 2: The start of the GNSS measurement gap starts at a non-D/non-U subframe
Option 3: GNSS measurement gap does not apply for NB-IoT NTN TDD
R1-2503101 Feature lead summary #3 on IoT-NTN TDD mode Moderator (Qualcomm Incorporated)
Working assumption
For precompensation, from RAN1 perspective:
The UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.
FFS: whether spec impact is in RAN1, RAN4 or both
Inform RAN4 of the WA above and ask if there are any issues with the above WA.
R1-2503141 [DRAFT] LS on precompensation for NB-IoT NTN TDD mode Qualcomm Incorporated
R1-2503142 LS on precompensation for NB-IoT NTN TDD mode RAN1, Qualcomm Incorporated
Proposal
The LS to RAN4 in R1-2503142 is agreed.
|