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 Meeting #120-bis
NR-NTN downlink coverage enhancement
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
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
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.
NR-NTN uplink capacity/throughput enhancement
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.
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
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.
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
|
3GPP TSG RAN WG1 #121 R1-2504897
St Julian’s, Malta, May 19th – 23th, 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.
[121-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-2503693 RRC parameters list for Rel-19 NR NTN Phase 3 Rapporteur (THALES)
R1-2503701 TP on RAN1 additions to CR for TS 38.300 Rapporteur (THALES)
R1-2503702 RAN1 agreements for NR NTN Phase 3 up to RAN1#120-bis Rapporteur (THALES)
R1-2504933 Draft LS on NR-NTN TP for TS 38.300
Agreement
The draft LS in R1-2504933 with NR-NTN TP for TS 38.300 is endorsed with the following revisions:
These enhancements are specifically targeted at mitigating the issues in HD collision cases, including scenarios where semi-statically configured downlink reception collides with semi-statically configured uplink transmission, and where dynamically scheduled downlink reception collides with dynamically scheduled uplink transmission.
Inter-slot Orthogonal Cover Codes (OCC) with length 2 to multiplex up to two UEs
Insertion of in missing places
Final LS in R1-2504934.
R1-2504931 Summary of discussions on higher-layers parameters for Rel-19 NR NTN.
NR-NTN downlink coverage enhancement
R1-2503280 Discussion on downlink coverage enhancements for NR NTN Huawei, HiSilicon
R1-2503308 On NR-NTN downlink coverage enhancement Ericsson
R1-2503378 Remaining issues on NR-NTN downlink coverage enhancement vivo
R1-2503527 Discussion on NR-NTN downlink coverage enhancement Spreadtrum, UNISOC
R1-2503582 Discussion on downlink coverage enhancement for NR-NTN Samsung
R1-2503635 Discussion on DL coverage enhancement for NR NTN ZTE Corporation, Sanechips
R1-2503687 NR NTN Downlink coverage enhancements THALES
R1-2503774 Discussion on downlink coverage enhancement for NR NTN CATT
R1-2503812 NR-NTN downlink coverage enhancement InterDigital, Inc.
R1-2503845 Discussion on NR-NTN DL coverage enhancement CMCC
R1-2503861 Discussion on downlink coverage enhancement for NR NTN Fraunhofer IIS, Fraunhofer HHI
R1-2503895 Discussion on NR-NTN downlink coverage enhancement Xiaomi
R1-2503930 NR-NTN downlink coverage enhancement NEC
R1-2504001 Discussion on downlink coverage enhancements Fujitsu
R1-2504005 Discussion on downlink coverage enhancement for NR NTN Baicells Technologies Co. Ltd
R1-2504103 Discussion on NR-NTN downlink coverage enhancement HONOR
R1-2504109 NR-NTN Downlink Coverage Enhancement Panasonic
R1-2504149 Discussion on NR-NTN downlink coverage enhancement ETRI
R1-2504166 Discussion on NR-NTN downlink coverage enhancement TCL
R1-2504170 Discussion on downlink coverage enhancements for NR NTN CCU
R1-2504179 Discussions on downlink coverage enhancements Nokia, Nokia Shanghai Bell
R1-2504199 Discussion on NR-NTN downlink coverage enhancement OPPO
R1-2504270 NR-NTN downlink coverage enhancement MediaTek Inc.
R1-2504342 On NR-NTN Downlink Coverage Enhancement Apple
R1-2504410 Downlink coverage enhancement for NR NTN Qualcomm Incorporated
R1-2504447 Further Discussion on NR NTN downlink coverage enhancement China Telecom
R1-2504459 Discussion on downlink coverage enhancement for NR NTN Lenovo
R1-2504480 Discussion on NR NTN Downlink Enhancements Sharp
R1-2504515 Discussion on DL coverage enhancement for NR-NTN NTT DOCOMO, INC.
R1-2504545 Discussion on downlink coverage enhancement for NR-NTN CSCN
R1-2504561 Discussion on NR-NTN downlink coverage enhancement LG Electronics
R1-2504581 Discussion on DL coverage enhancements for NR-NTN NICT
R1-2504583 Discussion on Downlink Coverage Enhancement for NR NTN Google Korea LLC
R1-2504605 Discussion on Downlink Coverage Enhancements for NR NTN CEWiT
R1-2503689 FL Summary #1: NR-NTN downlink coverage enhancements THALES
Agreement
The enabling/disabling of SIB1 PDSCH repetition is implicitly indicated by the enabling/disabling of Type-0 CSS PDCCH repetition.
R1-2503690 FL Summary #2: NR-NTN downlink coverage enhancements THALES
Agreement
For the activation/deactivation of Msg4 PDSCH repetition:
Alt 1: UE specific PDSCH with Msg4 repetition activation indicated via DCI Format 1_0:
Signaling uses re-interpretation of 1 MSB in MCS field in DCI.
A UE capable of Msg4 PDSCH repetition may report its capability/request in Msg3 PUSCH.
Note: RAN1 considers there is no difference between capability and request
FFS: whether to specify condition(s) for the UE to report its capability/request. Such conditions may be discussed in RAN1 or other WGs.
The aggregation factor is configured in SIB1, with possible value 2 or 4
When the aggregation factor is configured in SIB1, the PDSCH MSG4 repetition is enabled.
Send LS to RAN2 informing about the above agreement, asking RAN2 to consider the agreement when designing the report in Msg3 PUSCH.
R1-2504935 Draft LS on Msg4 PDSCH repetition
Agreement
The draft LS in R1-2504935 is endorsed with the following revision:
RAN1 has support for Msg4 PDSCH repetition
Final LS in R1-2504936.
Agreement
For PDCCH repetition for Type0 PDCCH CSS of searchSpaceZero configured within MIB pdcch-ConfigSIB1, the solution agreed for M = 2 is also applied to M = 1 and M = 1/2.
Agreement
Revise the RAN1#120bis agreement as follows:
Agreement
For PDCCH repetition for Type0 PDCCH CSS of searchSpaceZero configured within MIB pdcch-ConfigSIB1:
Enabling/disabling using a reserved bit(s) (i.e ) 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-2503691 FL Summary #3: NR-NTN downlink coverage enhancements THALES
R1-2503692 FL Summary #4: NR-NTN downlink coverage enhancements THALES
Agreement
For PDCCH CSS other than Type-0 CSS and other than Type-3 CSS for common search spaces other than SearchSpaceZero, support intra-slot repetition based on:
The starting symbol of monitoring occasion of the second SS is located right after the ending symbol of monitoring occasion of the first SS.
BD is counted as one or two, subject to UE capability, in RRC connected mode
UE assumes that a DCI Format with the same content is repeated on two PDCCH candidates.
Note: From RAN1 perspective UE is expected to deliver performance no worse than soft combining
PDCCH repetition is applicable to RNTI of the CSS.
Repeated PDCCH candidates within the same CORESET repeated in the slot, and share the same aggregation level (AL), coded bits and same candidate index.
Up to editor how to capture this in writing the relevant RAN1 specification.
Working assumption
Inter-slot Type-0 CSS PDCCH repetition is only applicable to the SI-RNTI, and the following rule for BD counting is defined:
1 BD in first slot.
In the second slot: 2 BD in RRC connected mode
One BD for Type-0 CSS PDCCH repetition with SI-RNTI and one BD for other PDCCH
Conclusion
It can be discussed in UE feature session whether a dedicated PDSCH repetition capability (e.g. FG5-17a and FG16-2b-5) is a pre-requisite UE feature for Msg4 PDSCH repetition.
Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
R1-2503281 Discussion on HD-FDD RedCap UEs and eRedCap UEs for FR1-NTN Huawei, HiSilicon
R1-2503325 Discussion on support of HD-FDD (e)RedCap UEs with NR NTN SageRAN
R1-2503337 On HD-FDD Redcap UEs for NTN Ericsson
R1-2503379 Remaining issues on support of RedCap and eRedCap UEs with NR-NTN vivo
R1-2503528 Discussion on support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Spreadtrum, UNISOC
R1-2503583 Discussion on support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Samsung
R1-2503636 Discussion on support of RedCap/eRedCap UEs for NR NTN ZTE Corporation, Sanechips
R1-2503775 Discussion on the enhancement of RedCap and eRedCap UEs In NTN CATT
R1-2503813 Discussion on half-duplex RedCap issues for NTN FR1 operation InterDigital, Inc.
R1-2503846 Discussion on the collision issues of HD-FDD Redcap UE in FR1-NTN CMCC
R1-2503896 Discussion on the support of Redcap and eRedcap UEs in NR NTN Xiaomi
R1-2504104 Discussion on support of (e)RedCap UEs in NR NTN HONOR
R1-2504150 Discussion on HD UEs with NR NTN ETRI
R1-2504167 Discussion on HD-FDD Redcap UEs and eRedcap UEs for FR1-NTN TCL
R1-2504180 Discussion of support for RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Nokia, Nokia Shanghai Bell
R1-2504200 Discussion on supporting of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands OPPO
R1-2504271 Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands MediaTek Inc.
R1-2504343 Discussion on support of RedCap UEs with NR NTN operation Apple
R1-2504411 Support of Redcap and eRedcap UEs in NR NTN Qualcomm Incorporated
R1-2504432 Support of (e)RedCap UEs with NR NTN Sharp
R1-2504516 Discussion on support of RedCap and eRedCap UEs in FR1-NTN NTT DOCOMO, INC.
R1-2504544 Support of RedCap and eRedCap UEs in NR NTN Nordic Semiconductor ASA
R1-2504557 Discussion on support of RedCap/eRedCap UEs in NTN CAICT
R1-2504562 Discussion on support of (e)RedCap UEs with NR-NTN operating in FR1-NTN bands LG Electronics
R1-2504725 Summary#1 for 9.11.2 Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Moderator (CATT)
R1-2504726 Summary#2 for 9.11.2 Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands Moderator (CATT)
Agreement
Confirm working assumption in RAN1 #120b with the following update:
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 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.
Handling of collision with PDSCH scheduled by Type-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 note.
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
f 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
R1-2503240 On uplink capacity enhancements for NR-NTN Ericsson
R1-2503282 Discussion on uplink capacity/throughput enhancement for FR1-NTN Huawei, HiSilicon
R1-2503380 Remaining issues on NR-NTN uplink capacity enhancement vivo
R1-2503529 Discussion on NR-NTN uplink capacity/throughput enhancement Spreadtrum, UNISOC
R1-2503584 Discussion on uplink capacity/throughput enhancement for NR-NTN Samsung
R1-2503637 Discussion on UL capacity enhancement for NR NTN ZTE Corporation, Sanechips
R1-2503763 Discussion on the NR-NTN uplink capacity/throughput enhancements TCL
R1-2503776 Discussion on UL capacity enhancement for NR NTN CATT
R1-2503814 NR-NTN uplink capacity/throughput enhancement InterDigital, Inc.
R1-2503847 Discussion on the NR-NTN uplink capacity/throughput enhancements CMCC
R1-2503897 Discussion on NR-NTN PUSCH capacity enhancement Xiaomi
R1-2503909 Discussion on the NR-NTN uplink capacity/throughput enhancements NTPU
R1-2503931 NR-NTN uplink capacity/throughput enhancement NEC
R1-2504002 Discussion on uplink capacity/cell throughput enhancement for FR1-NTN Fujitsu
R1-2504055 Discussion on NR-NTN uplink enhancement China Telecom
R1-2504105 Discussion on NR-NTN UL capacity/throughput enhancement HONOR
R1-2504151 Discussion on NR-NTN uplink capacity/throughput enhancement ETRI
R1-2504155 Discussion on NR-NTN Uplink Capacity/Throughput Enhancement Lenovo
R1-2504181 Discussion of NR-NTN uplink capacity enhancements Nokia, Nokia Shanghai Bell
R1-2504201 Discussion on NR-NTN uplink capacity/throughput enhancement OPPO
R1-2504272 NR-NTN uplink capacity and throughput enhancements MediaTek Inc.
R1-2504344 On NR-NTN Uplink Capacity Enhancement Apple
R1-2504412 NR-NTN uplink capacity / throughput enhancement Qualcomm Incorporated
R1-2504443 Uplink capacity/throughput enhancement for NR-NTN Panasonic
R1-2504481 Discussion on NR NTN Uplink Enhancements Sharp
R1-2504517 Discussion on NR-NTN uplink capacity/throughput enhancement NTT DOCOMO, INC.
R1-2504563 Discussion on NR-NTN uplink capacity/throughput enhancement LG Electronics
R1-2504584 Discussion on NR-NTN uplink capacity/throughput enhancement Google Korea LLC
R1-2503684 Feature lead summary #1 of AI 9.11.3 on NR-NTN uplink capacity and throughput MediaTek Inc.
Agreement
Remove the FFS in sub-bullet of 2nd bullet in RAN1#120bis agreement on UCI multiplexing.
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.
Agreement
When OCC is applied on the PUSCH with UL-SCH with repetition type A and A-CSI report is triggered, the following applies:
The A-CSI report(s) is multiplexed on all PUSCH repetitions within the first OCC group
Agreement
For the OCC length applied for OCC DG PUSCH and CG PUSCH Type 2, support:
Option 3: Candidates values are configured by RRC higher-layer parameter as part of the TDRA table with a new column for configuring the OCC length, and the applied value is indicated by scheduling DCI for DG PUSCH or by activation DCI for CG PUSCH Type 2.
No additional rows for the TDRA table
Conclusion
RAN1 will not specify enhancements for support of TBoMS with inter-slot OCC for PUSCH in Rel-19.
Conclusion
There is no consensus in RAN1 to introduce a restriction on the number of PRBs to support inter-slot OCC for PUSCH.
R1-2503685 Feature lead summary #2 of AI 9.11.3 on NR-NTN uplink capacity and throughput MediaTek Inc.
Agreement
For the OCC sequence applied for OCC DG PUSCH and CG PUSCH Type 2, the sequence is indicated dynamically in DCI Format 0_1 and Format 0_2. Support implicit DCI indication with re-use of antenna port field.
Association between antenna ports and OCC sequence is defined by re-using the legacy tables with two new columns added for OCC sequence. Note: the tables could directly reference the OCC sequence index (Table 6.3.2.5A-1 and Table 6.3.2.5A-2 in TS38.211) or spell out the sequence as in the example below.
Table 7.3.1.1.2-6: Antenna port(s), transform precoder is enabled, dmrs-Type=1, maxLength=1,
except that dmrs-UplinkTransformPrecoding and tp-pi2BPSK are both configured and
π/2-BPSK modulation is used
Table 7.3.1.1.2-6A: Antenna port(s), transform precoder is enabled, dmrs-UplinkTransformPrecoding and tp-pi2BPSK are both configured, π/2-BPSK modulation is used, dmrs-Type=1, maxLength=1
Table 7.3.1.1.2-7: Antenna port(s), transform precoder is enabled, dmrs-Type=1, maxLength=2,
except that dmrs-UplinkTransformPrecoding and tp-pi2BPSK are both configured and
π/2-BPSK modulation is used
Table 7.3.1.1.2-7A: Antenna port(s), transform precoder is enabled, dmrs-UplinkTransformPrecoding and tp-pi2BPSK are both configured, π/2-BPSK modulation is used, dmrs-Type=1, maxLength=2
Conclusion
Explicit configuration / indication of OCC enabler is not supported.
Agreement
Revise the first bullet in RAN1#120bis agreement on UCI multiplexing with “without A-CSI reports” and FFS removed as below:
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
Agreement
Remove the FFS in the sub-bullet of 3rd bullet in RAN1#120bis agreement on UCI multiplexing.
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
Agreement
Confirm RAN1#120bis Working Assumption 2 on UCI multiplexing with revised text:
Working Assumption 2: The above agreement applies to PUCCH with repetitions if no additional specification impact is identified.
Agreement
Confirm RAN1#120bis Working Assumption 1 on UCI multiplexing with revised text:
Working assumption 1: The above agreement applies to different priority indexes for PUCCH/PUSCH if no additional specification impact is identified.
Agreement
A UE is not expected to be configured with frequency hopping for PUSCH repetitions with inter-slot OCC.
Agreement
Alt 2. For PUSCH grouping with inter slot OCC, the integer number of OCC groups is determined as M =N/L, where N is the number of repetitions of PUSCH and L is the OCC length.
An OCC group is defined by L consecutive PUSCH repetitions. OCC Group m includes PUSCH repetition mxL, mxL+1, .., (m+1)xL-1, where m=0,1, .., M-1
R1-2503686 Feature lead summary #3 of AI 9.11.3 on NR-NTN uplink capacity and throughput MediaTek Inc.
IoT-NTN uplink capacity/throughput enhancement
R1-2503283 Discussion on UL capacity enhancements for IoT NTN Huawei, HiSilicon
R1-2503338 On uplink capacity enhancements for IoT-NTN Ericsson
R1-2503381 Remaining issues on IoT-NTN uplink capacity enhancement vivo
R1-2503530 Discussion on IoT-NTN uplink capacity/throughput enhancement Spreadtrum, UNISOC
R1-2503585 Discussion on uplink capacity/throughput enhancement for IoT-NTN Samsung
R1-2503638 Discussion on UL capacity enhancement for IoT NTN ZTE Corporation, Sanechips
R1-2503764 Discussion on the IoT-NTN uplink capacity/throughput enhancements TCL
R1-2503777 Discussion on UL capacity enhancement for IoT NTN CATT
R1-2503815 IoT-NTN uplink capacity/throughput enhancement InterDigital, Inc.
R1-2503848 Discussion on the IoT-NTN uplink capacity/throughput enhancements CMCC
R1-2503898 Discussion on IoT-NTN uplink capacity enhancement Xiaomi
R1-2503932 IoT-NTN uplink capacity/throughput enhancement NEC
R1-2503960 IoT NTN OCC activation and sequence index indication for NPUSCH Sharp
R1-2504034 IoT-NTN uplink capacity enhancement Nokia, Nokia Shanghai Bell
R1-2504071 On IoT-NTN uplink capacity enhancements Sony
R1-2504074 Final FL Summary for IoT-NTN Moderator (Sony)
R1-2504152 Discussion on uplink capacity/throughput enhancement for IoT NTN ETRI
R1-2504202 Discussion on IoT-NTN uplink capacity/throughput enhancement OPPO
R1-2504273 IoT-NTN uplink capacity and throughput enhancement MediaTek Inc.
R1-2504345 Discussion on IoT-NTN Uplink Capacity Enhancement Apple
R1-2504413 IOT-NTN uplink capacity/throughput enhancement Qualcomm Incorporated
R1-2504460 Discussion on uplink capacity enhancement for IoT NTN Lenovo
R1-2504543 IoT-NTN uplink capacity/throughput enhancement Nordic Semiconductor ASA
R1-2504564 Discussion on IoT-NTN uplink capacity/throughput enhancement LG Electronics
R1-2504072 FL Summary #1 for IoT-NTN Moderator (Sony)
Agreement
Confirm the following working assumption from RAN1#120 Athens:
“For 3.75kHz SCS OCC for NPUSCH format 1, support TDM DMRS over 4 slots where DMRS are transmitted in the first 2 slots and DMRS REs are blanked in the next 2 slots, or vice-versa, where the DMRS REs are as in legacy NB-IoT and the guard period within the slot is as in legacy NB-IoT.”
Agreement
The total number of slots in the NPUSCH transmission after OCC is applied is , where the parameters have the legacy definitions in TS36.211 and .
Agreement
For 3.75kHz SCS, the TDM DMRS positions that are activated within the TDM DMRS pattern are associated at least with the OCC sequence index.
Agreement
When the OCC is configured by RRC, if the number of repetitions of NPUSCH Format 1 is equal to 1, the DCI is interpreted as per legacy, otherwise:
For 15kHz SCS:
the reserved states in the subcarrier indication field are used to indicate the location of subcarriers, OCC sequence index and OCC activation / deactivation
For 3.75kHz SCS:
The redundancy version field is repurposed to indicate [OCC activation / deactivation or OCC sequence index]
Down-select between:
Option 1: The fields “subcarrier indication” and “modulation and coding scheme” are jointly encoded to indicate the location of the subcarriers, the value of ITBS and [OCC activation / deactivation or OCC sequence index]
Option 2: the MSB bit of “modulation and coding scheme” is used to indicate [OCC activation / deactivation or OCC sequence index]
R1-2504073 FL Summary #2 for IoT-NTN Moderator (Sony)
Agreement
For 3.75kHz SCS OCC for NPUSCH format 1, the following mappings between DMRS sequence samples and active TDM DMRS slots is applied:
Option 1: Sequential mapping of samples of the original DMRS sequence to active DMRS slots
Agreement
For the TDM DMRS positions that are activated within the TDM DMRS pattern:
For an NPUSCH format 1 with 3.75kHz SCS allocated to start in slot m, the NPUSCH is postponed to start in the next slot, whose index satisfies (SFN * 5 + ns) mod 4 = 0. The UE transmits TDM DMRS in the nth slot after the start of its NPUSCH transmission according to:
Agreement
For 3.75kHz SCS:
RV indicates activation / deactivation.
The UE initiates NPUSCH format 1 transmission with
Agreement
For 3.75kHz SCS:
The fields “subcarrier indication” and “modulation and coding scheme” are jointly encoded to indicate the location of the subcarriers, the value of ITBS and OCC sequence index. The joint encoding does not support indication of ITBS = 10.
Agreement
For NPUSCH Format1, Symbol-level OCC applied to 3.75kHz SCS single tone and Slot-level OCC applied to 15kHz SCS single-tone, the same RV value is used within an OCC group for slots, where M is the OCC length. RV cycling is performed across the OCC groups.
Note: the number of RVs is /M.
Note: the RV sequence is as in legacy specifications.
R1-2503613 LS on CB-msg3-EDT RAN2, MediaTek
RAN2 is requesting RAN1 input on physical layer parameters for CB-Msg3-EDT procedure. Response needed. To be handed in agenda item 9.11. Moderator: Gilles (MediaTek).
Relevant tdoc(s):
R1-2503339 Discussion LS on CB-msg3-EDT Ericsson
R1-2503632 Discussion on the LS on CB-msg3-EDT ZTE Corporation, Sanechips
R1-2503663 Draft reply LS on CB-msg3-EDT vivo
R1-2503765 Discussion on LS reply on CB-msg3-EDT CATT
R1-2503870 Discussion on RAN2 LS on CB-msg3-EDT Xiaomi
R1-2504036 Discussion on LS from RAN2 on CB-Msg3-EDT Nokia, Nokia Shanghai Bell
R1-2504204 Discussion on LS on CB-msg3-EDT OPPO
R1-2504284 Discussion on reply LS on CB Msg3 EDT MediaTek Inc.
R1-2504292 Discussion on LS rely on CB-msg3-EDT Huawei, HiSilicon
R1-2504377 CB-msg3-EDT for IOT NTN Qualcomm Incorporated
R1-2504803 Moderator summary #1 on reply LS on CB-msg3-EDT on IoT-NTN uplink capacity and throughput enhancements Moderator (MediaTek), Qualcomm
Reply to Q1
RAN1 has not evaluated the potential performance of power ramping for CB-msg3-EDT, and it is likely that there will not be sufficient time to evaluate this topic within the R19 timeframe
For open loop power control the following UL power control parameters can be reused for CB-msg3-EDT
p0-UE-NPUSCH-r16 and alpha-r16 for NB-IoT NTN
p0-UE-PUSCH-r16 and alpha-r16 for eMTC NTN
Reply to Q2
From RAN1 perspective, the MPDCCH PUR configuration can be reused, with the following modifications:
The TDD parameters are not needed.
The search space will be a common search space (CSS) instead of UE-specific search space (USS).
There is no consensus in RAN1 on the need to define the set of narrowbands as a set.
mpdcch-FreqHopping-r16 is not needed
Reply to Q3
From RAN1 perspective:
pusch-NB-MaxTBS-r16 and pusch-CyclicShift-r16 are not needed to be signaled.
prb-AllocationInfo should be defined as a “set” format with intention to provide a set of shared frequency-domain resources
pur-PUSCH-FreqHopping-r16 is not needed
RAN1 wonders whether RAN2 intends to support multi-PRB allocation or sub-PRB allocation or both
Reply to Q4
From RAN1 perspective:
pur-PDSCH-FreqHopping and pur-PDSCH-maxTBS are not needed to be signaled.
Reply to Q6
RAN1 agrees to re-use pur-PhysicalConfig-r16 configuration for CB-msg3-EDT as baseline. RAN1 discussed the following fields in CB-msg3-EDT configuration for NB-IoT NTN:
The following parameters can be supported:
npusch-NumRUsIndex-r16
npusch-NumRepetitionsIndex-r16
npusch-SubCarrierSetIndex-r16 (but defining this as a set)
npusch-MCS-r16
Note: To be confirmed by RAN2 whether to support both singleTone and multitone, or singleTone only for HL parameter npusch-MCS-r16.
Reply to Q7
NPDCCH-ConfigDedicated-NB-r13 IE can be used as baseline for NPDCCH configuration for indication of msg4 on NPDSCH for CB-msg3-EDT. RAN1 assumes this configuration will be provided over broadcast RRC signalling.
Agreement
The draft LS in R1-2504904 is endorsed with the following revisions:
Title: Draft Reply LS on CB Msg3 EDT for IoT NTN Ph3
Response to: R1-250361/R2-2503175
From RAN1 perspective, the MPDCCH PUR configuration can be reused, with the following modifications:
Final LS in R1-2504905
IoT-NTN TDD mode
R1-2503284 Discussion on IoT-NTN TDD mode Huawei, HiSilicon
R1-2503382 Remaining issues on IoT-NTN TDD mode vivo
R1-2503531 Discussion on IoT-NTN TDD mode Spreadtrum, UNISOC
R1-2503586 Discussion on IoT-NTN TDD mode Samsung
R1-2503639 Discussion on the IoT-NTN TDD mode ZTE Corporation, Sanechips
R1-2503688 Discussion on IoT-NTN TDD mode THALES
R1-2503778 Discussion on Physical layer design of IoT-NTN TDD CATT
R1-2503849 Discussion on the new NB-IoT NTN TDD mode CMCC
R1-2503899 Discussion on IoT-NTN TDD mode Xiaomi
R1-2503958 Remaining aspects of loT-NTN TDD mode Iridium Satellite LLC
R1-2503959 Stage 2 proposal (for RAN2 TS 36.300) for Introduction of IoT-NTN TDD mode Iridium Satellite LLC
R1-2503961 Remaining issues on IoT NTN TDD Sharp
R1-2504035 Discussion on IoT-NTN TDD mode Nokia, Nokia Shanghai Bell
R1-2504203 Discussion on IoT-NTN TDD mode OPPO
R1-2504346 Discussion on IoT-NTN TDD mode Apple
R1-2504414 IOT-NTN TDD mode Qualcomm Incorporated
R1-2504461 Discussion on IoT-NTN TDD mode Lenovo
R1-2504518 Discussion on IoT-NTN TDD mode NTT DOCOMO, INC.
R1-2504565 Discussion on IoT-NTN TDD mode LG Electronics
R1-2504576 On R19 TDD IoT-NTN Nordic Semiconductor ASA
R1-2504718 Feature lead summary #1 on IoT-NTN TDD mode Moderator (Qualcomm Incorporated)
Agreement
The following RRC parameter is endorsed for inclusion in RAN2 LS:
*Agreement
NPRACH periodicities of 40ms and 80ms are not supported in NB-IoT NTN TDD mode
Instead, periodicities of 90ms and 180ms are supported
NOTE: It is up to RAN2 how to implement this agreement (e.g. keeping the same codepoints as in legacy but with a NOTE that for NBIOT NTN TDD 40/80ms are interpreted as 90/180)
Agreement
For GNSS measurement gap:
GNSS measurement gap can be applied in NB-IoT NTN TDD
RAN1 does not specify any enhancement on the Rel-18 timeline for the start of GNSS gap.
Conclusion
Additional SIB1-NB transmissions are supported based on current specifications without the need of indicating DL bitmap.
NOTE: RAN1 assumes that all NTN-IoT TDD UEs can interpret additionalTransmissionSIB1-r15 in MIB
Working assumption
For NPDCCH monitoring, new periodicities are introduced for NPDCCH monitoring by scaling the periodicity by a scaling factor F = 11.25
FFS: which G values are applicable for this scaling (to be decided at RAN1#121)
FFS: whether/how to update the NPDCCH start subframe offset
R1-2504719 Feature lead summary #2 on IoT-NTN TDD mode Moderator (Qualcomm Incorporated)
Agreement
Confirm the working assumption of RAN1#120b with the following modifications
DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) does not apply to 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.
Up to RAN2 to decide whether DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) is constrained to not being present in a NB-IoT NTN TDD cell, or it can be configured with values all set to ‘1’.
Agreement
Confirm the following working assumption with modifications:
For precompensation, from RAN1 perspective:
The UE may adjust 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.
The UE may adjust its time/frequency pre-compensation at the beginning of an NPUSCH/NPRACH transmission (same behavior as Rel-18)
Segmented precompensation is not supported.
It is not supported to perform precompensation within the set of 8 consecutive uplink subframes other than at the beginning of an NPUSCH/NPRACH transmission
FFS: whether spec impact is in RAN1, RAN4 or both.
NOTE: RAN1 may revisit this agreement if RAN4 reply LS shows concerns, including concerns on meeting the requirements without segmented precompensation
Agreement
Confirm the following WA with the following modification
For NPDCCH monitoring, new periodicities are introduced for NPDCCH monitoring by scaling the periodicity by a scaling factor F = 11.25 supporting values of G={11.25*4, 11.25*8} instead of G={4,8}
Agreement
The TP below is endorsed for TS 36.300
Anchor carrier: in NB-IoT, a carrier where the UE assumes that NPSS/NSSS/NPBCH/SIB-NB for FDD and IoT-NTN TDD or NPSS/NSSS/NPBCH for TDD are transmitted.
In this release of the specification, NTN is only applicable to FDD and IoT-NTN TDD system.
Downlink and uplink transmissions are organized into radio frames with 10 ms duration. Three radio frame structures are supported:
- Type 1, applicable to FDD
- Type 2, applicable to TDD;
…
For IoT-NTN TDD mode, Frame Structure Type-1 is used where uplink and downlink transmissions are separated in the time domain and constitute of set of D non-overlapping usable contiguous DL subframes and set of U usable contiguous UL subframes separated by fixed guard period (GP). This pattern is repeated every N radio frames. IoT-NTN TDD mode is applicable for the IoT-NTN TDD band (1616-1626.5 MHz) specified in [36.102].
R1-2504882 TP for 36.300 for IOT NTN TDD mode Qualcomm
R1-2504883 TP for 36.300 for IOT NTN TDD mode RAN1, Qualcomm
Agreement
The draft LS in R1-2504882 is endorsed.
Final LS in R1-2504883.
Agreement
For the issue of handling DL gaps in NB-IoT NTN TDD mode:
DL gaps apply based on current specifications, with the following modification:
dl-GapPeriodicity with a value of “sf1024” is supported instead of the value of “sf64”
|