3GPP TSG RAN WG1 #120bis                                                                                       R1-2501825
Wuhan, China, April 7th – 11th, 2025


Source:	vivo
Title:	Discussions on IoT-NTN uplink capacity enhancement
Agenda Item:	9.11.4
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on IoT NTN uplink capacity enhancement. According to the discussions, we have the following observations and proposals: 
Observation 1: The OCCed UEs in option 3 could be compatible with legacy UEs with less specification impact.
Observation 2: There is no suitable field in DCI format N0 to be reinterpreted for indication of OCC sequence index. 
Observation 3: The phase continuity cannot be maintained after 40ms-UL gaps. 
Observation 4: Phase continuity is hard to be maintained between segments due to the UL re-synchronization within gap.
Observation 5: The OCC application could be across the guard periods for 3.75kHz UL transmissions.
Proposal 1：The existing definition of the number of NB-IoT UL slots of one RU should be unchanged. 
Proposal 2: The actual number of scheduled RU for NPUSCH with OCC is the product of the value of    which is derived as R18, and the OCC length.
Proposal 3：Further discussion on TDM DMRS for NPUSCH format 1 with 3.75kHz SCS could wait for the LS reply. 
Proposal 4：Considering the compatibility and specification impact, option 3 as CDM DMRS scheme for NPUSCH format 1 single-tone 15kHz SCS is preferred. Option 1_1 could be an acceptable compromise if only minimal spec impacts are identified, e.g. reusing the formula of DMRS symbol for NPUSCH format 2.
Proposal 5: Do not support an additional dynamic activation/deactivation of OCC feature.
Proposal 6：Support indication of OCC sequence index via RRC.
Proposal 7: There are 2 options to OCC application on 40ms-UL gaps for synchronization
Option 1: UE does not apply OCC code after UL gaps.
Option 2: NW avoid scheduling NPUSCH with OCC with a UL gap occurs in between. 
Proposal 8: The OCC application should be restricted within a segment.
Proposal 9: From the perspective of phase continuity, 
the followings do not affect the design of OCC for IoT-NTN:
Guard periods for 3.75kHz UL transmissions
the followings could affect the design of OCC for IoT-NTN:
UL gaps for synchronization (from Rel-13) and the following options could be considered
Option 1: UE does not apply OCC code after 40ms-UL gaps. 
Option 2: NW avoid scheduling NPUSCH with OCC with a UL gap occurs in between. 
UL timing adjustment gaps and segmentation for IoT-NTN (from Rel-17)
The OCC application should be restricted within a segment.

3GPP TSG RAN WG1 #120bis			R1-2501883
Wuhan, China, 07th – 11th April 2025
Agenda Item:	9.11.4
Source:	Spreadtrum, UNISOC
Title: 	Discussion on IoT-NTN uplink capacity/throughput enhancement
Document for:	Discussion and decision

Conclusion
In this contribution, we provided our views on the details of UL capacity enhancement. The following observations and proposals are made:
Repetition is based on Nslot slots for 15kHz multi-tone and Nslot=2.
The length of guard period for 3.75kHz UL transmission is much smaller than symbol.

Support Option 2-1 or Option 3 for 15kHz single-tone DMRS.
Option 2_1: OCC is applied to the legacy complex-valued DMRS symbol used in slot 1 and slot 2, e.g. according to the formula: 
Option 3: DMRS symbols are not spread and OCC is not applied.
Support Nslot slot-level OCC for multi-tone and Nslot=2.
For multi-tone NPUSCHs multiplexed with OCC, DMRS sequences with different cyclic shifts or CDM DMRS can be considered.
For case 1, 2 and 3, UEs in the same OCC group can drop the overall OCC segment around the gaps or depend on network implement to avoid these cases.
Case 4 and 5 has no impact on OCC.
Repurposing one bit from MCS field or repetition number field in DCI N0 to indicate OCC sequence index when network enable OCC feature should be supported.

3GPP TSG RAN WG1 #120bis                                                                                   R1-2501902
Wuhan, China, April 7th - 11st, 2025

Source:	ZTE Corporation, Sanechips
Title:	Discussion on UL capacity enhancement for IoT NTN
Agenda Item:	9.11.4
Document for:   Discussion
 

Conclusions
In this contribution, the UL capacity enhancement for NPRACH and NPUSCH are discussed with following observation and proposals.
Proposal 1: For NPUSCH multi-tone 15kHz SCS, OCC across  slots requires almost no changes on the legacy resource mapping,e.g., repetition times and repetition granularity .
Proposal 2: For NPUSCH single-tone 15kHz SCS, legacy segmented resource mapping with update on repetition times can be reused, e.g., repetition times and repetition granularity .
Proposal 3: For both single-tone and multi-tone 15kHz SCS, OCC should be applied to   slots.
Proposal 4: For NPUSCH single-tone 15kHz SCS, RU length should not be extended after applying OCC.
Proposal 5: For NPUSCH single-tone 3.75kHz SCS, legacy segmented resource mapping with update on repetition times can be reused for OCC across symbols, e.g., the repetition times and repetition granularity .
Proposal 6: For NPUSCH single-tone 3.75kHz SCS, OCC should be applied to   symbols.
Observation 1: For NPUSCH single-tone 15kHz SCS, 
Option 1-1 can maintain orthogonality in both aglined transmission and staggered transmission
Option 2-2 cannot maintain orthogonality in both aglined transmission and staggered transmission; 
option 2-1 and option 3 can only maintain orthogonality in aglined transmission; 
Proposal 7: For NPUSCH single-tone 15kHz SCS, Option 1 is prefered.
Proposal 8: For NPUSCH single-tone 3.75kHz SCS, slot sub-group in each slot group to transmit DMRS should be a function of the OCC index, e.g., mod(OCC index, OCC length).
Proposal 9: For CONNECTED mode, OCC sequence index can be indicated by re-interpreting the existing filed in the DCI.
Proposal 10: For semi-static configured transmission, 
UE-specific RRC signalling used to enable the OCC feature can be reused to indicate the OCC sequence index.

3GPP TSG RAN WG1 #120bis                                            R1-2501975
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.11.4
Source:	CATT
Title:	Discussion on UL capacity enhancement for IoT NTN
Document for:	Discussion and Decision

Conclusion
In this contribution, technical analysis of OCC for NPUSCH format 1 and NPRACH in IoT-NTN is presented, and a few of observations and proposals are made as following:
Proposal 1：For 15 kHz single-tone NPUSCH, prioritize Option 1-1, that is, the DMRS symbols are spread before the OCC is applied.
Proposal 2：For the 15kHz single-tone NPUSCH, the eNB scheduling should avoid overlap between the OCC group and the aforementioned gaps. Otherwise, the overlapping part will be postponed or discarded.
Proposal 3：For 15 kHz multi-tone NPUSCH, consider reusing the OCC scheme for 15 kHz single-tone NPUSCH or refer to UL OCC scheme of NR NTN.
Proposal 4：For the 3.75kHz NPUSCH, the eNB schedules to avoid overlap between the OCC group and the aforementioned gaps. If overlap occurs, the overlapping part will be postponed or discarded.
Proposal 5：For the support of single-tone OCC length 2 NPUSCH Format 1, adopt Option A) as the definition of the number of repetitions.
Proposal 6：Network should schedule the users with same modulation scheme to OCC pairing to avoid phase rotation issue.    
Proposal 7：Consider using the remaining bits in the Subcarrier indication field to indicate the OCC codeword index.

3GPP TSG RAN WG1 #120bis		                                                    R1-2502084
Wuhan, China, April 7th – 11st, 2025

Agenda Item:	9.11.4
Source:	NEC
Title:	IoT-NTN uplink capacity/throughput enhancement
Document for:	Discussion 

Conclusion
From the discussion, we have the following observations and proposals.

Observation 1: Option 3 and Option 2-2 introduce substantial specification impacts due to their requirements for dynamic DMRS sequence variations; Option 2-1  fails to guarantee full-scenario compatibility, as its non-spread DMRS implementation compromises orthogonality between paired UEs under certain DMRS sequences defined in current specification; Option 1-2 wastes (M-1)/M of the legacy define  sequence.

Observation 2: Option 1-1 could ensure:
Backward compatibility with legacy DMRS designs.
Orthogonality preservation through unified OCC operation.
Minimal specification impact by leveraging existing sequence determination and slot-level OCC operation frameworks.

Proposal 1: Support DMRS symbols are spread before the OCC is applied according to the formula:  , m=0,1,…,M-1

Proposal 2: RAN1 assumes the RU size and TBS determination follow the R-18 procedure.

Proposal 3: RAN1 assumes the network will not pair UEs using different modulation orders in one OCC group.

3GPP TSG RAN WG1 #120bis 	R1-2502094
Wuhan, China, 7 – 11 April 2025

Agenda item:		9.11.4
Source:	Nokia, Nokia Shanghai Bell
Title:	IoT-NTN uplink capacity enhancement
Document for:		Discussion and Decision

Conclusion
In this contribution, we discussed our view on OCC for IoT NTN. Our observations and proposals are as follows:
Observation 1: Although the transmission starting time and repetition number for different UE may be different, the OCC spreading for UEs transmitting on the same resource should be always aligned.
Observation 2: TDM DMRS with muting will significantly impact the channel estimation, phase continuity and resulting into impact to decoding reliability, high coverage with high energy efficiency.
Observation 3: Supporting resource sharing between UE support OCC and UE not support OCC will also avoid impact on flexibility of scheduling based on whether and when there is requirement for capacity enhancement and all resource can be scheduled for all the UE whether supporting OCC or not.
Observation 4: Legacy IoT NTN rely on segmented repetition periods to facilitate time/frequency synchronization.
Observation 5: The dropping of symbols as part of segmented transmissions may impact the orthogonality of the OCC. 
Observation 6: The UE transmission timing can be controlled for PUR with OCC using the legacy Time Alignment Timer. 
Observation 7: The UE transmission timing can be controlled for EDT with OCC using the legacy Timing Advance Command in the Random Access Response. 
Observation 8: It is problematic if OCC feature enabling via RRC implies any subsequent NPUSCH transmission has to apply OCC.
Observation 9: If OCC request different size of resource than non-OCC, then there may be impact to UE not supporting OCC.

Proposal 1: Common solution for time domain OCC should be supported for single-tone and multi-tone cases.
Proposal 2: RAN1 should discuss how to align the OCC spreading of different UE NPUSCH multiplexing on same resource with repetitions and scheduling time.
Proposal 3: OCC should consider different traffic rate and arrival time of UEs, and not impact scheduling flexibility considering flexible traffic from different UE.
Proposal 4: eNB indication/configuration based OCC alignment/pairing should be considered instead of all depend on scheduling with restrictions resulting in performance loss.
Proposal 5: Considering the OCC impact to RV cycling, RAN1 should consider a way forward that has minimum impact to specification and implementation of NB-IoT.
Proposal 6: RAN1 should reuse legacy DMRS sequences and allocate DMRS sequences to UEs based on different OCC index, e.g. the DMRS sequence is selected by a UE based on cell ID and OCC index for NPUSCH of this UE for both single-tone and multiple-tone. 
Proposal 7: RAN1 should support common DMRS design for single-tone and multiple-tone with OCC.
Proposal 8: RAN1 to discuss whether the UE shall drop all symbols that are spread according to the OCC length, when at least one symbol is part of the segmentation gap.
Proposal 9: OCC is supported for PUR and EDT. FFS how to configure OCC for EDT.
Proposal 10: The enabling of OCC feature via RRC shall further depend on whether the scheduling DCI N0 also defines that OCC is to be applied on the scheduled NPUSCH. 
Proposal 11: RAN1 to specify OCC feature activation or OCC index signaling via DCI format N0 in addition to RRC signaling for OCC.
Proposal 12: RAN1 to discuss whether a field of DCI format N0 can be repurposed to indicate the OCC feature activation/OCC sequence index with no restriction on the field values.
Proposal 13: RAN1 to discuss whether OCC can be implicitly activated/OCC index indicated when a DCI format N0 parameter is within a RRC configured range.
Proposal 14: Compatibility and co-existence between OCC and non-OCC should be studied.
Proposal 15: RAN1 should discuss the coexistence of UEs supporting and not supporting OCC in IoT NTN.

3GPP TSG RAN WG1 #120bis                                          R1-2502176
Wuhan, China, April 7th – 11th, 2025
Source: 	CMCC
Title:	Discussion on the IOT-NTN uplink capacity/throughput enhancements
Agenda item:	9.11.4
Document for:	Discussion & Decision

Conclusions
In this contribution, we discussed potential OCC schemes to enhance uplink capacity/throughput for IoT-NTN, and the following proposals are made.

Observation 1:
Compared with the slot-level OCC, the symbol-level OCC may have a better performance but also non-negligible specification impacts to the data mapping procedure. 

Observation 2:
The specification impact to the codeword mapping or RV cycling in the case of multiple tone NPUSCH repetitions is negligible. 

Observation 3:
For slot level OCC,  should be divisible by OCC group length , i.e., .

Observation 4:
Compared with the symbol-level OCC, the slot level OCC may have less specification impact especially on the codeword mapping procedure and RV cycling. 

Observation 5:
During the UL gaps for synchronization from Rel-13, the HD-FDD redcap cannot maintain the phase continuity of the UL transmissions before and after the UL gap. 

Observation 6:
The gaps around NPRACH occasions may impact the phase continuity of UE UL transmission. 

Observation 7:
The TA adjustment during the segmented pre-compensation gaps will break the phase continuity. 

Observation 8:
Segmented pre-compensation gaps will also impact the PUSCH mapping with OCC.

Observation 9:
The phase continuity can be maintained by UE over the muted DMRS symbol in the slot. 

Observation 10:
Guard periods for 3.75kHz UL transmissions will not impact the phase continuity. 

Observation 11:
The performance of the OCC multiplexing is affected by many issues, e.g. timing accuracy, frequency offsets and power imbalance. eNB can pair the UEs for the OCC multiplexing and provide a better performance based on the information above. 

Observation 12:
It is difficult for eNB to pair the UEs for OCC multiplexing when UEs are carrying out their 1st uplink transmission or in idle mode. 

Proposal 1:
For the enhancements of DMRS for NPUCH OCC multiplexing, the legacy design/specification should be reused as much as possible to reduce the difficulties for implementation and commercialization.

Proposal 2:
For single tone 3.75KHz NPUSCH OCC multiplexing, the TDM DMRS pattern #1, in which the DMRSs in two consecutive slots are combined for one UE, should be supported. Consider the working assumption as an agreement.

Proposal 3:
The UL gaps for synchronization needs to be considered when supporting OCC multiplexing.

Proposal 4:
It needs further discussion on how many symbols a IoT UE can maintain the phase continuity without any transmission. 

Proposal 5:
The impact of gaps around NPRACH occasions should be considered during the design of the OCC multiplexing. 

Proposal 6:
When NPUSCH transmission overlaps with the configured NPRACH resource, the overlapping part of NPUSCH will be postponed and transmitted after the configured NPRACH resources, at the granularity of the OCC group level.

Proposal 7:
The segmented pre-compensation gaps should be considered for the design of OCC multiplexing.

Proposal 8:
Guard periods for 3.75kHz UL transmissions should be considered for the OCC multiplexing design. 

Proposal 9:
The enabling of the OCC multiplexing feature can be achieved at least based on the RRC configuration.

Proposal 10:
The indication of the specific OCC sequence can be based on RRC configuration and DCI based indication.

Proposal 11:
Besides RRC signaling, MAC CE signaling for OCC activation and de-activation should be supported.

Proposal 12:
For the Msg3 with OCC multiplexing, the performance impact of the uplink timing alignment, power imbalance and frequency shifting should be evaluated. 

Proposal 13:
The identification of the UE capability of OCC multiplexing for Msg 3 needs more discussion. 

Proposal 14:
It needs further study for the supporting of OCC multiplexing for contention based Msg3 EDT.

3GPP TSG RAN WG1 #120bis                                  			               R1-2502191
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.11.4	
Source:	InterDigital, Inc.
Title:	IoT-NTN uplink capacity/throughput enhancement
Document for:	Discussion

Conclusions
In this contribution, the following proposals are made for IoT NTN UL capacity enhancements:
Proposal 1: Support Option 1 for DMRS design for single tone 15 kHz SCS.
Proposal 2: Specify the OCC design for NPUSCH Format 1 single tone transmission. Multi-tone transmissions are only discussed in Rel-19 after single tone design is complete.

3GPP TSG-RAN WG1 Meeting #120bis	R1-2502222
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.11.4
Source:	Huawei, HiSilicon
Title:	Discussion on UL capacity enhancements for IoT NTN
Document for:	Discussion and Decision

Conclusions
The observations and proposals made in this contribution are summarized below:
Proposal 1: For NPUSCH Format 1 single-tone 15kHz SCS, support Option 1_1 for CDM DMRS because of better channel estimation and less scheduling restriction of NPUSCH.
Proposal 2: For 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. RV cycling can be performed across the OCC groups. 
Observation 1: Phase continuity cannot be maintained after NPRACH occasion, UL gaps for synchronization or UL timing adjustment gaps.
Observation 2: Phase continuity can be maintained after guard periods of 3.75kHz SCS or TDM DMRS that are muted.
Proposal 3: For the NPUSCH slots colliding with NRPACH resources, UL GAP and UL timing adjustment gaps, the NPUSCH slots should be postponed with granularity of OCC span.
Proposal 4: MAC CE can be used to activate or deactivate the OCC more dynamically especially for UE only support CP solution. 
Proposal 5: The OCC sequence index and corresponding DMRS port can be indicated in DCI format N0 (e.g. by repurposing 1 bit of MCS field) or in the activation MAC CE.
Proposal 6: The number of scheduled repetitions is a multiple of the OCC length to account for the transmitted data and its spreading, the existing TBS determination from  and  can be reused. 
Proposal 7: NW should avoid pairing two UEs with single-tone NPUSCH for OCC multiplexing, when they are scheduled with π/2-BPSK and π/4-QPSK, respectively.
Proposal 8: For multi-tone with 15kHz SCS, Nslot-level OCC with OCC length 2 can be supported when the number of repetitions is not smaller than 4. 
Proposal 9: For multi-tone NPUSCHs multiplexed with OCC, DMRS ports with different cyclic shifts can be applied.
Observation 3: For multi-tone NPUSCH with 15kHz SCS, Nslot-level OCC and One slot-level OCC achieve similar BLER performance with OCC length of 2.
Observation 4: For multi-tone NPUSCH with 15kHz SCS, both Nslot-level OCC and One slot-level OCC suffer obvious performance degradation when OCC length is 4. 
Proposal 10: To support OCC for PUSCH format 1, the RRC parameters in Table 2 should be introduced.

3GPP TSG RAN WG1 #120bis		R1-2502268
Wuhan, China, April 7th – 11th, 2025

Source:	OPPO
Title:	Discussion on IoT-NTN uplink capacity/throughput enhancement
Agenda Item:	9.11.4
Document for:	Discussion and Decision

Conclusion
In this contribution, we present our view and analysis on enhancements to support UE multiplexing with OCC for NPUSCH format 1 and DMRS. The following observations and proposals are made:
Observation 1: Regarding the options for CDM DMRS with legacy pattern:
For Option 1, the de-OCC procedure on NPUSCH and DMRS symbols are exactly the same.
For Option 2_1, Option 2_2 and Option 3, the de-OCC operation on DMRS symbols varies with the value of .
For Option 2_2 and Option 3, the orthogonality of multiplexed UEs cannot be always guaranteed between every two slots.
Observation 2: After de-OCC is performed at the gNB side, the inter-cell inference orthogonality on DMRS symbols can be well guaranteed for Option 1.
Observation 3: For symbol-level OCC2, at least the spec impact in terms of physical resource mapping procedure and TBS determination should be taken into account.

Proposal 1: Slot-level OCC2 for NUPSCH format 1 with 15kHz SCS is supported based on the current slot-level repetition mechanism, where the RU length can remain unchanged, with the following adaptations:
 for 

Proposal 2: For NPUSCH Format 1 single-tone 15kHz SCS, RAN1 to support DMRS symbols spreading before the OCC is applied (Option 1) as the CDM DMRS with legacy pattern.
Proposal 3: For support of symbol-level OCC2 for NPUSCH format 1, at least the following enhancements should be considered: 
For physical resource mapping procedure, symbol-level spreading with orthogonal sequence  is supported.
For TBS determination, two options can be further discussed:
Opt 1: Portion the NPUSCH codeword mapped to 1 slot of the allocated  RUs is transmitted in  slots.
Opt 2: The number of SC-FDMA symbols in a slot are scaled up by the OCC length .
Proposal 4: Slot-level OCC2 is supported for multi-tone NPUSCH format 1 with 15 kHz.

3GPP TSG-RAN WG1 Meeting #120-bis	R1-2502306
Wuhan, People’s Republic of China, April 7th – 11th, 2025

Agenda Item:	9.11.4
Source:	Ericsson
Title:	On uplink capacity enhancements for IoT-NTN
Document for:	Discussion

1	

Conclusion
Based on the discussion in the previous section we made the following observations:
Observation 1	DL transmissions won’t be orthogonal, therefore scheduling 2 OCC UEs to transmit simultaneously on the same time-frequency UL resources will in principle require 2 independent DCIs.
Observation 2	In relation with the previous observation, the legacy specification Table 16.5.1-1 of TS 36.213 only counts with four scheduling delays {8, 16, 32, 64} that are far from each other and that won’t be suitable for OCC-based transmissions accounting for repetitions and no-repetitions.
Observation 3	For scheduling 2 OCC UEs to transmit simultaneously on the same time-frequency UL resources using independent DCIs, the following scheduling delays are required:
	No repetition case: UE2 k0 = Legacy Value, UE1 k0 = Legacy Value + 1. For example: UE2 k0 = 8, UE1 k0 = 9.
	2 repetition case: UE2 k0 = Legacy Value, UE1 k0 = Legacy Value + 2. For example: UE2 k0 = 8, UE1 k0 = 10.
	4 repetition case: UE2 k0 = Legacy Value, UE1 k0 = Legacy Value + 4. For example: UE2 k0 = 8, UE1 k0 = 12.
	8 repetition case: UE2 k0 = Legacy Value, UE1 k0 = Legacy Value + 8. For example: UE2 k0 = 8, UE1 k0 = 16.
	16 repetition case: UE2 k0 = Legacy Value, UE1 k0 = Legacy Value + 16. For example: UE2 k0 = 8, UE1 k0 = 24.
Observation 4	For NPUSCH Format 1 single-tone (= 1) with 3.75 kHz SCS, the RU length spans= 16 slots, which results in 32 ms given that the slot duration is 2 ms.
Observation 5	For TDM DMRS scheme under WA, in our understanding the shortest elapsing time between two adjacent DMRS symbols is 2 ms (i.e., (275 us)7 + (75us)1 = 2 ms), whereas the largest elapsing time between two adjacent DMRS symbols having DMRS symbols blanked in between is 6 ms (i.e., (275 us)21 + (75us)3 = 6 ms).
Observation 6	For NPUSCH Format 1 single-tone (= 1) with 15 kHz SCS, the RU length spans= 16 slots, which results in 8 ms given that the slot duration is 0.5 ms.
Observation 7	A “Slot-level OCC” spreading using an “OCC length 2” inherently doubles the utilization of resources in the time-domain.
Observation 8	During RAN1#120 there was a discussion around the CDM DMRS options, and one essential question was about the length of the sequence .
Observation 9	In our understanding, due to the OCC spreading, the length of is twice the length of . We believe that the CDM DMRS scheme as per Option 1 (i.e., “”) is a suitable scheme if it is clarified how the length of the sequence is determined.
Observation 10	In CDM DMRS Option1, the sequence invokes the legacy sequence , therefore configuring  as a multiple of the OCC length will impact both. However, the length of the legacy sequence shall remain unimpacted. Thus, in our understanding should keep using , whereas  can use which configurable values are multiple of the OCC length (e.g., ).
Observation 11	In relation with the previous observation, one alternative approach is to keep using  as per legacy for both  and . In this case, the length of the sequence for can be given by , where  is the OCC length.
Observation 12	On the alternative of using as CDM DMRS a “DMRS generation formula” like the one used for NPUSCH format 2, which in the case of OCC length 2 Slot-level NPUSCH format 1 single-tone with 15 kHz SCS would be: “”. Such a formula also needs to clarify the definition of m (e.g., m = 0, M-1, where M is the OCC length) and how is the length of the sequence determined (i.e., given “m” is it “”?).
Observation 13	For NPUSCH Format 1 with 15 kHz SCS for multi-tone, the possible allocations are 3-subcarriers, 6-subcarriers, and 12-subcarriers with RUs equal to 4ms, 2ms, and 1ms respectively. Thus, for multi-tone three different pairs of and need to be considered.
Observation 14	In our understanding, the motivation behind applying OCC to NPUSCH transmissions relies on exploiting the possibility of adding at least one more simultaneous transmission on top of a transmission that unavoidably requires utilizing time-frequency resources during a long-time (e.g., single-tone where the one RU is 32 ms) because the UE is in low SNR conditions. Thus, multi-tone transmissions, which are typically assigned to high SNR UEs do not seem to be in line with the motivation behind introducing OCC for NPUSCH.
Observation 15	Applying the same OCC scheme used for single-tone to the multi-tone case does not seem to be possible, mainly because for single-tone the allocation in the frequency-domain is constant (1-tone), whereas for multi-tone the allocation in the frequency-domain is variable (i.e., either 3, 6, or 12 tones). The OCC mapping is foreseen to be impacted.
Observation 16	In terms of DCI design, 1-bit is required for creating a new field for the “OCC sequence index” which would be used to assign one out of the two OCC codewords/sequences to the UE (i.e., [1 1] or [1 -1].
Observation 17	Touching upon the DCI design, in the last meeting there was a proposal about indicating via DCI whether the scheduled transmission should be OCC’d or not. In our view this proposal incorporates flexibility and is beneficial, although one additional bit is foreseen to be required.
Observation 18	One other DCI related comment was about using one or more than one bit from the “Modulation and coding scheme field” in DCI. However, according with Table 16.5.1.2-1 in TS 36.213 applicable for single-tone allocations, there are eleven IMCS indices which require 4 bits, those indices are mapped to ITBS indices using Modulation Order 1 and 2 (i.e., already no 16-QAM), therefore it does not seem to be possible reducing the number of bits of this legacy field.
Observation 19	In our view, RAN1 should aim for a design not increasing the DCI size of Format N0 (and therefore no side effect on the size of Format N1 either).
Observation 20	In our opinion, if OCC-based transmissions were supported only for single-tone, then it would be possible reducing by 1-bit the legacy field “Subcarrier indication” in DCI Format N0 (i.e., this since multi-tone allocations won’t be needed), which will make available 1-bit for creating a new field for the “OCC sequence index”.
Observation 21	Yet, if the 1-bit field “Number of scheduled TB for Unicast” were not expected to be used along with OCC-based transmissions, then it will make 1-bit available to create a new field for indicating dynamically whether the scheduled transmission should be OCC’d or not i.e., “OCC enabled/disabled” field.
Observation 22	A gap introduced into an OCC’d transmission could disrupt the time alignment and compromise the orthogonality (e.g., causing interference between the sequences).
Observation 23	In relation with previous observation, possible ways of overcoming the disruptions that a gap can cause on OCC’d transmissions could be: 1) Using OCC sequences robust to time misalignments, 2) Timing correction/control techniques that could control or correct transmission timing variations, 3) Receiver processing techniques that can help to compensate for the distortions caused by the gap.
Observation 24	The NPRACH periodicity causes the NPUSCH transmission to be postponed, thus an OCC’d NPUSCH transmission (i.e., a spread transmission) is prone to more postponements.
Observation 25	PUR already offers through “Shared-PUR,” the possibility of allowing up to 2 UEs transmitting over the same UL time-frequency resources.
Observation 26	For “Shared-PUR,” the UL transmissions of 2 UEs can overlap over 12 tones at low SNR regimes (iff the total length of the allocated NPUSCH resources for the UE is greater than or equal to 64 ms).
Observation 27	Pairing the most suitable UEs to transmit simultaneously using OCC seems to be essential towards preserving orthogonality, otherwise the orthogonality may suffer from an unsuitable UE pairing (e.g., if the UEs being paired happen to be too imbalanced in terms of transmit power).
			
Based on the discussion in the previous sections we propose the following:

Proposal 1	For scheduling 2 OCC UEs to transmit NPUSCH Format 1 single-tone simultaneously on the same time-frequency UL resources using independent DCIs, RAN1 determines which additional scheduling delays “k0” are supported depending on the foreseen required repetitions for NPDCCH (e.g., no repetitions, 2 repetitions, 4 repetitions, 8 repetitions, 16 repetitions).
FFS:  How to incorporate the additional scheduling delays “k0” into Table 16.5.1-1 of TS 36.213.
Proposal 2	For OCC length 2 Symbol-level NPUSCH format 1 single-tone with 3.75 kHz SCS, confirm the Working Assumption on “TDM DMRS” until RAN4 has replied to the LS, meanwhile RAN1 clarifies the following aspects:
	Confirm that the “Symbol-level OCC” spreading only applies on the data symbols.
	The “Guard period” keeps its location within the slot.
	The DMRS symbols keep their location within the slot such that TDM applies blanking on every other pair of adjacent DMRS symbols.
Proposal 3	For CDM DMRS with OCC length 2 Slot-level NPUSCH format 1 single-tone and 15 kHz SCS, RAN1 clarifies for Option 1 (i.e., “”) how the length of the sequence is determined:
A)	The length of the sequence  is given by , where  for it to be a multiple of the OCC length. This to account for the transmitted data and its spreading.
B)	The length of the sequence  is given by , where  is the OCC length and is added to account for the transmitted data and its spreading.
For both A) and B), the legacy sequence  and its length remains unmodified, and  is configured as in legacy, including the value of 1.
Proposal 4	RAN1 prioritizes OCC length 2 NPUSCH Format 1 single-tone for concluding the design aspects of both 15 kHz and 3.75 kHz (including DMRS pattern and DCI design). Thus, OCC for NPUSCH Format 1 for multi-tone is not supported in Rel-19.
Proposal 5	For the DCI design to support OCC-based single-tone transmissions on Format N0, RAN1 considers:
	Reducing by 1-bit the legacy field “Subcarrier indication” in DCI Format N0.
o	Creating 1-bit new field for the “OCC sequence index” which would be used to assign one out of the two OCC codewords/sequences to the UE (i.e., [1 1] or [1 -1].
	Not using the 1-bit legacy field “Number of scheduled TB for Unicast” along with OCC-based transmissions
o	Creating 1-bit new field for the “OCC enabled/disabled” field which would be used for indicating dynamically whether the scheduled transmission should be OCC’d or not.
	Based on the above bullets, consider the following DCI design:

Proposal 6	RAN1 to study the potential loss of orthogonality derived from pairing UEs transmitting simultaneously using OCC, accounting for traffic characteristics, number of repetitions, modulation schemes, location, transmit power, etc.
Proposal 7	On the proposal on “whether / how to enable OCC across UEs using different modulation orders (π/2-BPSK and π/4-QPSK)”. RAN1 considers the possibility of leaving up to the scheduler not pairing “UEs using different modulation orders”, which will avoid additional specification impacts”.

5 

3GPP TSG RAN WG1 #120bis								R1-2502330
Wuhan, PR China. 7-11 April 2025
Agenda Item 	:	9.11.4
Source 	:	Sony 
Title 	:	On IoT-NTN uplink capacity enhancements  
Document for 	:	Discussion and decision

Conclusion 
This document has considered the impact of CFO on OCC performance for IoT-NTN, alignment of OCC-ed NPUSCH transmissions and TDM DMRS for 3.75kHZ SCS. The following observations and proposals are made:
Observation 1: NPUSCH format 1 transmissions may be long for IoT-NTN and may contain gaps.
Observation 2: Resynchronisation during a long OCC transmission of NPUSCH format 1 is expected to improve NPUSCH performance due to CFO error diversity.
Proposal 1: RAN1 studies the performance of OCC for NPUSCH format 1 when the UE resynchronises during an ongoing NPUSCH format 1 transmission, accounting for the randomisation of CFO error.
Proposal 2: To support alignment of NPUSCH format 1 transmissions, RAN1 considers the following schemes:
Increased number of k0 values in DCI
Implicit addition of delay to the signalled k0 offset as a function of OCC codeword
Proposal 3: Confirm the working assumption that TDM DMRS over 4 slots is supported where DMRS are transmitted in the first 2 slots and DMRS REs are blanked in the next 2 slots, or vice-versa.

3GPP TSG RAN WG1 #120bis		R1-2502331	
Wuhan, China, 7th – 11th April 2025


Agenda Item 	:	9.11.4
Source 	:	Moderator (Sony)
Title 	:	FL Summary #1 for IoT-NTN
Document for	: Discussion



1	

Conclusions

This document is the feature lead summary for IoT-NTN in RAN1#120bis. It contains the FLS discussion and lists the proposals that were considered in online and offline sessions.

3GPP TSG RAN WG1 #120bis		R1-2502332	
Wuhan, China, 7th – 11th April 2025


Agenda Item 	:	9.11.4
Source 	:	Moderator (Sony)
Title 	:	FL Summary #2 for IoT-NTN
Document for	: Discussion



1	

Conclusions

This document is the feature lead summary for IoT-NTN in RAN1#120bis. It contains the FLS discussion and lists the proposals that were considered in online and offline sessions.

3GPP TSG RAN WG1 #120bis		R1-2502333	
Wuhan, China, 7th – 11th April 2025


Agenda Item 	:	9.11.4
Source 	:	Moderator (Sony)
Title 	:	Final FL Summary for IoT-NTN
Document for	: Discussion



1	

Conclusions

This document is the feature lead summary for IoT-NTN in RAN1#120bis. It contains the FLS discussion and lists the proposals that were considered in online and offline sessions.

3GPP TSG RAN WG1 #120bis			R1- 2502344
Wuhan, China, April 7th – 11th, 2025 

Agenda Item:	9.11.4
Source:	Sharp
Title:	IoT NTN OCC signaling for NPUSCH 
Document for:	Discussion and Decision

Conclusions
In this contribution, we discussed the OCC signaling methods for IoT NTN NPUSCH, we propose
Proposal 1: If OCC is supported, the OCC index can be indicated by DCI format N0 with re-interpreation of some bits in the DCI format N0.
Proposal 2: With OCC feature enabled by RRC signaling, dynamical OCC on/off can be further supported.  
Proposal 3: When OCC is enabled by RRC, dynamic OCC on/off can be performed by a new OCC-RNTI.

3GPP TSG RAN WG1 #120bis    		                           R1-2502386
Wuhan, China, April 7th – 11th, 2025
Agenda item:		9.11.4
Source:			Samsung
Title:			Discussion on uplink capacity/throughput enhancement for IoT-NTN
Document for:		Discussion and decision

Conclusion
This contribution discussed on evaluation assumptions for uplink capacity/throughput evaluation. Followings are proposals in this contribution. 
Proposal 1: Consider single-tone OCC for PUSCH format 1 in RRC IDLE mode e.g.,  Msg3, PUR, CB Msg3 EDT with reusing mechanisms for dynamic grant in RRC CONNECTED mode without any further optimization. 
Proposal 2: Consider explicit signaling for OCC related parameters for single-tone OCC for NPUSCH format 1. 
Proposal 3: Consider new DCI field in DCI format N0 in USS for enabling NPUSCH with OCC, and the new DCI field exists when the corresponding UE-specific RRC signaling is provided. 

TDoc file reading error

3GPP TSG RAN WG1 Meeting #120b	R1-2502522
Wuhan, China, April 7th – 11st, 2025
Agenda item:	9.11.4 IoT NTN uplink capacity/throughput enhancement
Source: 	ETRI
Title:	Discussion on uplink capacity/throughput enhancement for IoT NTN
Document for:	Discussion/Decision

Conclusion
In this contribution, ETRI presented our views on uplink capacity/throughput enhancement for IoT NTN. We made the following observations and proposals:

Proposal 1. RAN1 to discuss the two consecutive slot type or odd/even numbered slot type in TDM DMRS scheme for NPUSCH format 1

Proposal 2: For single-tone 15kHz SCS in NPUSCH format 1, Option 1 is preferable for conventional implementation of CDM-based DMRS scheme.

Proposal 3. RAN1 to study the signaling aspect utilizing the existing DCM field of OCC related indication for NPUSCH format 1. 

Proposal 4. RAN1 to consider QPSK modulation for OCC mode single tone mode instead of π/4-QPSK.  

Proposal 5. It is necessary to prioritize the study of UL TA gaps and segmentation impact on the NPUSCH and NPRACH OCC schemes

3GPP TSG RAN WG1 Meeting #120bis	                      R1- 2502560
China, Wuhan, April 7th – April 11th, 2025
Agenda Item: 9.11.4
Source: TCL
Title: Discussion on the IoT-NTN uplink capacity/throughput enhancements
Document for: Discussion and Decision

Conclusion
In this contribution, we provided our views on IoT-NTN uplink capacity enhancements. Our proposals are as follows:
Proposal 1: DMRS pattern for 15 kHz can be that DMRS symbols are spread by OCC.
Proposal 2: For the number of repetitions under slot-level OCC, Option A can be considered.
Proposal 3: OCC sequence index can be indicated in DCI by adding a field or reusing the bits from other bit fields or encoding jointly with other domains.
Proposal 4: Support study for the usage of NPUSCH OCC for EDT/PUR to improve the UL capacity.
Proposal 5: The reference point for enabling OCC can be introduced to allow the OCC to ensure the alignment of OCC codewords.
Proposal 6: Deprioritize enhancement of NPRACH with OCC for IoT-NTN.
Proposal 7: The impact of NPRACH with OCC on RAR needs to be considered.

3GPP TSG RAN WG1 #120bis			R1-2502632
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.11.4
Source:	Apple
Title:	Discussion on IoT-NTN Uplink Capacity Enhancement
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided our views on IoT-NTN uplink capacity enhancements. Our observation and proposals are as follows:
Proposal 1: Support OCC for multi-subcarrier NPUSCH format 1 transmission with the repetitions. 
Proposal 2: For single-tone NPUSCH transmission with OCC, if OCC is enabled, the actual repetition number is equal to Nrep*2.
Proposal 3: For 15kHZ SCS single-tone NPUSCH transmission with OCC, support DMRS symbols spreading before the OCC is applied.
Proposal 4: Support indication of OCC sequence index by re-interpreting reserved code points of subcarrier indication field in DCI format N0.
Observation: The following gaps do not impact the OCC design for IoT-NTN.
UL gaps for synchronization
TDM DMRS that are muted
Guard periods for 3.75kHz UL transmissions
Proposal 5: RAN1 to study the standard impacts of gaps around NPRACH occasions and UL timing adjustment gaps on supporting OCC for NPUSCH. 

3GPP TSG-RAN WG1 Meeting #120bis	R1-2502719
Wuhan, China, April 7th– 11th, 2025
Source:	MediaTek Inc.
Title:	IoT-NTN uplink capacity and throughput enhancement
Agenda item:	9.11.4
Document for:	Discussion

Conclusion
In this contribution, we have the following observations and proposals:

DM RS for OCC for NPUSCH:
Proposal 1: For NPUSCH Format 1 single-tone 15 kHz SCS, support Option 3: “DMRS symbols are not spread and OCC is not applied” for CDM DRS with legacy pattern.

RU length for slot-level OCC with NPUSCH Format 1:
Observation 1: There is no need to extend RU length for slot-level OCC with NPUSCH Format 1 single-tone 15kHz SCS or single-tone 3.75 kHz SCS before applying OCC.
Proposal 2: The legacy RU length     before spreading is used for slot-level OCC with NPUSCH Format 1 single-tone 15 kHz SCS and single-tone 3.75 kHz SCS.

UL Transmission Gaps:
Proposal 3: OCC length can be applied to a NPUSCH transmission segment with mod(Nprecompensationsegment, OCC-length) = 0 to avoid specification impact on UL gaps for synchronization, UL timing adjustment gaps and segmentation.

3GPP TSG RAN WG1 #120bis					        R1- 2502818
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.11.4
Source: 	LG Electronics
Title: 	Discussion on IoT-NTN uplink capacity/throughput enhancement
Document for:	Discussion and decision

Conclusions
In this contribution, we discussed capacity/throughput enhancement for IoT-NTN. Based on the above discussion, our observations and proposals are given as follows:
Observation 1: For UL capacity enhancement for NPUSCH format 1, the OCC needs to be applied within a UL segment since the phase-continuity would not be guaranteed across different UL segments. Moreover, it would be necessary to avoid that a single OCC is shortened or punctured by the UL segment gap. 
Observation 2: For NPUSCH Format 1 single-tone 15kHz SCS DMRS sequence generation, in Option 1, due to the DMRS spreading before applying 16-length OCC, the effective length of the 16-legnth OCC will be reduced into 8. It will result that the 16-length OCC sequences with different index will be the same. 
Observation 3: Even with the different phase rotations between different NPUSCH transmissions due to the modulation order and/or the starting position, eNB can still distinguish NPUSCH transmissions with different OCC sequences that are multiplexed in the same time-and-frequency resources. 

Proposal 1: For NPUSCH format 1 DMRS design, the OCC pattern periodicity is selected to be a divisor of (UL segment size – UL segment gap size).
Proposal 2: For 3.75kHz NPUSCH format 1 DMRS design, RAN1 can consider followings:
Option 1: The legacy DMRS sequence is generated and mapped on the DMRS symbols before blanking DMRS symbols, and then UE does not transmit parts of DMRS sequence in the blanked DMRS symbols. 
Option 2: DMRS sequence is generated and mapped on the DMRS symbols after blanking DMRS symbols. 
Proposal 3: For UL capacity/throughput enhancement for NPUSCH format 1, RAN1 considers followings:
For 15kHz single-tone transmission, the value of  is increased into the target OCC length. 
For 3.75kHz single-tone transmission, symbol-level spreading before physical layer mapping is adopted. 
Proposal 4: For NPUSCH Format 1 single-tone 15kHz SCS, RAN1 studies at least the following options for CDM DMRS with legacy pattern, support Option 2_2 with some change: 
Option 2: DMRS symbols are not spread before the OCC is applied. 
Option 2_2: OCC is applied to the complex-valued DMRS symbol with different random seed used in slot 1 and slot 2, e.g. according to the formula: 
Proposal 5: For UL capacity/throughput enhancement for NPUSCH format 1, OCC sequence index is signaled by DCI format N0 in USS.
OCC sequence indication filed is only present if higher layer parameter for OCC feature is enabled.
Proposal 6: RAN1 does not pursue specific enhancements on the phase rotation with respect to the modulation order and the starting position in Rel-19 IoT-NTN WI. 

3GPP TSG RAN WG1 #120bis			R1-2502823
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.11.4
Source:	Lenovo
Title:	Discussion on uplink capacity enhancement for IoT NTN 
Document for:	Discussion and decision

Conclusions
In this contribution, considerations of uplink capacity enhancement via OCC for IoT NTN are provided. The following proposals are present: 
Proposal 1: For the support of single-tone OCC length 2 NPUSCH Format 1, the number of scheduled repetitions is a multiple of the OCC length to account for the transmitted data and its spreading.
Proposal 2: For NPUSCH Format 1 single-tone 15kHz SCS, the following options for CDM DMRS with legacy pattern can be adopted:
Option 1: DMRS symbols are spread before the OCC is applied.

Proposal 3: For TBS calculation for PUSCH with OCC, the TBS is determined by TBS index and RU number indicated by DCI format N0 as legacy.
Proposal 4: RV spanning time duration for each repetition should be doubled, and the actual repetition number (after OCC) for NPUSCH with OCC should be scaled down in case of OCC 2.
Proposal 5: For NPUSCH format 1 of multiple tone case (15kHz), slot-based OCC solution can be considered and each of the OCC [elements] duration can be configured/fixed as 2 uplink slot.
Proposal 6: OCC sequence index is signaled by DCI format N0 with repurposing the existing field (e.g, RV field).

3GPP TSG RAN WG1 Meeting #120bis	R1-2502857
Wuhan, China, April 07th – 11th, 2025
	
Agenda item:	9.11.4
Source: 	Qualcomm Incorporated
Title: 	IOT-NTN uplink capacity/throughput enhancement
Document for:	Discussion and Decision

Conclusion
RAN1 did not reach consensus on whether OCC for NPRACH is beneficial or not. RAN1 will not specify support for OCC for NPRACH in Rel-19 IoT NTN.


NPUSCH capacity enhancements 
15kHz SCS: DMRS design 
For 15kHz SCS, the agreement in RAN1#118b cites “CDM DMRS with legacy pattern” as the option for DMRS. In this section, we present our views on the DMRS design.
First, let us briefly recall the components of the Rel-13 NB-IoT uplink DMRS, according to TS 36.211. The DMRS sequence is the product of two sequences
A first sequence , which is a BPSK-modulated Gold binary sequence initialized at the start of a transmission with a fixed seed ()
A second sequence , which is a length-16 Hadamard sequence, with the Hadamard row selected according to the cell ID.
The overall DMRS is , with 
The intention of the sequence  is to provide interference randomization across cells of UEs that start their transmissions at different points in time (due to scheduling or lack of cell synchronization). Sequence  orthogonalizes transmissions across multiple cells that start at the same point in time.
For OCC, it would be desirable to design a DMRS that meets the following criteria:
It shall be possible to orthogonalize the DMRS of UEs (within the same cell) that start their transmissions at different points in time.
In some cases (e.g. UEs starting transmissions at the same point in time), DMRS may be orthogonal across cells.
In other cases, DMRS interference from a different cell should be uncorrelated with the DMRS of the serving cell (i.e., DMRS sequence should be randomized with respect to the DMRS of the current cell).In our view, a simple way to achieve these requirements is to spread the legacy DMRS sequence by the OCC factor M, and multiply by the desired orthogonal vector, q, as follows:

Proposal 1:  Adopt the following DMRS pattern for 15kHz NPUSCH uplink capacity enhancements ( is the OCC length,  is the assigned OCC codeword for the UE):
Option 1: DMRS symbols are spread before the OCC is applied according to the formula: 
We show next that the other options agreed in RAN1#119 do not meet some of the requirements above:
Option 2_1: OCC is applied to the legacy complex-valued DMRS symbol used in slot 1 and slot 2, e.g. according to the formula :  : 
Intra-cell loss of orthogonality: Two UEs starting its transmissions at different points in time will not be orthogonal, since the sequence  would be different.
Inter-cell identical sequences: Two UEs in two different cells may have identical DMRS sequences in the following case:
UE1 is in cell 0 using Hadamard sequence 0 (), . This UE does not use OCC
UE2 is in cell 1 using Hadamard sequence 1 (), . It uses OCC with codeword 
UE1 and UE2 start at the same point in time (and therefore have the same )
Due to the product of  and , the resulting sequence is identical to .
Option 2_2: OCC is applied to the complex-valued DMRS symbol used in slot 1 and slot 2. Depending on the OCC codeword, different DMRS sequence is used.
Intra-cell loss of orthogonality: Same as with Option 2_1. Additionally, if different DMRS sequence is used for different UEs, orthogonality may be lost even if both users start at the same point in time.
Inter-cell identical sequences: Cannot assess due to lack of details on how “different DMRS sequence” is selected.
Option 3: DMRS symbols are not spread and OCC is not applied.  Legacy complex-valued DMRS symbol is used in slots corresponding to an OCC codeword of NPUSCH. Different DMRS sequences are used for multiplexed UEs.
Intra-cell loss of orthogonality: Same as previous options.
Inter-cell identical sequences: Cell planning has to be carefully done in pairs such that each cell ID is assigned 2 Hadamard sequences that are orthogonal. This means that half the cell IDs cannot be used (for instance, only even cell IDs may be used).

3.75kHz SCS: DMRS design

In RAN#120, the following working assumption was agreed to pursue TDM DMRS for 3.75 kHz SCS OCC for NPUSCH format 1:
“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”.
It is important to address the sequence design of the proposed TDM DMRS. As discussed in the section above, a desirable DMRS design should meet certain requirements. Keeping in mind these requirements, we propose a DMRS design that doesn’t drop/skip the samples (due to TDM). Let  be the transmitted DMRS symbol at slot number n, cell u (u = NcellID mod 16) and UE m (m goes from 0 to M-1). Let OCC factor be M. We can write  as following:



The table below shows timeline for transmission of the proposed DMRS design for two UEs using OCC in the same cell. 

We note that dropping samples of the original DMRS sequence will result in some cells having the same DMRS sequence, which will result in large errors in channel estimation error. Therefore we make the following proposal

Proposal 2:  Adopt the DMRS pattern for 3.75 kHz SCS NPUSCH uplink capacity enhancements that does not skip/drop the samples due to TDM, with the following equation:


Interaction with other features

In NB-IoT NTN, in addition to the RRC_CONNECTED data transfer, enhancements like EDT (including Rel-19 CB-msg3) and PUR may be used for short data transfer. In some cases, networks may operate with a majority of the UEs using these techniques. Therefore, it is proposed that NPUSCH OCC is supported in all these cases.
Proposal 3: RAN1 to specify NPUSCH OCC in the following scenarios:
Connected mode dynamic grant.
EDT
PUR
CB-msg3

Other specification impacts

Uplink gap handling for NPUSCH with OCC:
In NB-IoT UL Transmissions, there are 2 types of gaps:
Half Duplex (HD) gap: After 256 ms of contiguous UL transmission, an NB-IoT UE has to stop transmitting and must receive DL signals for the next 40 ms. 
NPRACH gap: The UE has to stop its ongoing contiguous UL transmission to transmit NPRACH during NPRACH occasion. These NPRACH occasions are known to UEs since they are broadcasted in the SIB. Note that these UL NPRACH transmissions also contribute to the total 256 ms HD gap i.e., the UE has to stop transmitting after 256ms – whether it is NPUSCH transmission or NPRACH or both – to receive DL information.
For NPUSCH with OCC, these gaps may cause performance degradation. For example, let   be slot j at UE i , as shown in Fig. 7 below. We have one cover-coded copy of the slot before the gap and one after the gap. We observe that the second cover-coded copy of the slot comes after the UL transmission gap. Depending on the duration of the gap, impairments like CFO will severely distort the phase of the second cover-coded copy – which will result in loss of orthogonality and hence loss in performance of OCC. This scenario is also true for symbols located at each boundary of the UL gaps when symbol-level OCC is considered. Note that these symbols may be DMRS also – which will also impact channel estimation negatively. Therefore, these UL gaps may impact the overall performance of systems with OCC. The UE may have to postpone some transmissions before and/or after these gaps to tackle this performance loss. For example, a UE may have to postpone transmission at the nearest time unit (e.g., an RU) before the gap and do the same after the gap.

Figure 7: OCC with UL transmission gaps (HD gap or NPRACH gap)
In addition, these gaps may hinder/dictate how a new OCC user may be added to a group of OCC users i.e., if UEs doing OCC have different starting transmission times and one UE is finished before the other. Adding another UE (in place of the finished UE) to the OCC group may also cause some postponement of UL transmissions due to these gaps. For example, after the gap, the network must make sure that it adds the new UE to the OCC group at a time instance (e.g., slot number) such that the structure of OCC doesn’t break. OCC structure in this context means that the OCC codewords of all the UEs in the OCC group are still aligned, including DMRS. If the codeword of the newly added UE was misaligned, the newly added UE will become undecodable and the other UEs will also suffer from increased interference from this newly added UE.
One simple way to solve all the issues above is to make sure that any uplink transmission is aligned between UEs. This can be achieved as follows:
For 3.75kHz SCS, due to the DMRS design, the alignment and minimum unit needs to be in groups of 4 slots.
For 15kHz SCS, since both DMRS and data are using slot-OCC, the alignment and minimum unit is 2 slots.
Therefore, we propose to treat any postponing (and restarting of transmission) in terms of this number of slots:

Proposal 4: For NPUSCH with OCC:
NPUSCH transmissions can only start in slots that are a multiple of 
After postponements due to NPRACH / UL gap, the NPUSCH transmission is restarted in the first slot after the NPRACH / UL gap that is a multiple of 
If a group of  overlaps with NPRACH / UL gap, the whole set of  is postponed.
 for 15kHz SCS, and  for 3.75kHz SCS

Resource unit determination and RV cycling for NPUSCH with OCC:
For OCC to work effectively, it is necessary that enough resources are allocated to the UEs being multiplexed. This is because when OCC is applied, the coding rate of the system increases by a factor of M. If enough resources are not allocated to a system with OCC, the combining gain obtained via OCC may be overshadowed by coding rate loss. Therefore, resource unit allocations and RV cycling mechanisms need to be designed, which help in maximizing UL capacity of the NTN over NB-IoT. One solution to make sure that systems with OCC have ample resources may be looking at a “group of M” entities, rather than the entity itself. For example, if a system without OCC is scheduled to transmit with 1 RU, a system with OCC has to transmit using at least M RUs. This group of RUs can be somewhat considered the basic unit of transmission for OCC and can be termed as a “super RU”. This is illustrated in Fig. 9. Similarly, the same concept can be applied to an RV for systems with OCC and a group of M RVs can be considered as a “super RV” and circular buffer manipulation (rate matching etc.) maybe done on a super-RV basis rather than on a legacy RV basis.

Figure 8: Resource unit determination for NPUSCH with 2 UEs using OCC
Based on the discussion above, determination of RUs and RV cycling for NPUSCH using OCC should be studied,  along with solutions that help in exploiting the maximum capacity gains from doing OCC.
Proposal 5: RAN1 to define the basic unit of transmission for NPUSCH with OCC as a “super RU” to leverage capacity gains from OCC. A “super-RU” is a set of consecutive M RUs.
Proposal 6: RAN1 to consider RV cycling on a “super-RV” basis for NPUSCH with OCC.

Enabling/Disabling OCC and indicating OCC codeword:
For NPUSCH with OCC, the enablement of OCC should follow the regular procedures in NB-IoT: the feature is enabled by RRC, and after this configuration the DCI may indicate which codeword (and potentially OCC order) is to be used by the UE. Note that dynamic signaling of the codeword is desirable to allow dynamic pairing of UEs based on e.g. data arrival, power imbalance, etc. Similarly, indication of OCC factor (e.g. M=1 or 2) is desirable to be indicated in DCI to adapt to changing channel conditions and availability of UEs to pair with. Therefore, for NPUSCH with OCC, the UE needs to be notified about the following OCC parameters:
The OCC factor (M) – dynamically indicated (implicitly or explicitly) using DCI.
The OCC codeword (CW) – For each OCC factor, there are M possible codewords. The UE needs to be informed in the DCI (implicitly or explicitly) about what codeword to use for a given OCC factor.
Proposal 7: For NPUSCH with OCC:
The OCC codeword and OCC order (including OCC ON/OFF) is indicated dynamically in DCI.
FFS: Details (e.g. whether explicit or implicit)

Interaction with multi-TB
When multi-TB DCI is enabled, the following specification aspects need to be inspected:
A single DCI will schedule up to 2 TBs. It is our assumption that, similarly to the case of uplink resource allocation (i.e., subcarrier index), both TBs should use the same OCC index.
For the case of multi-TB with interleaving, the current specification (TS 36.213, 16.5.1) states that the unit of interleaving is  for single subcarrier (i.e., interleaving is performed at the repetition level). We propose to maintain this notion, adapting it to the fact that the basic unit of scheduling would be scaled by the OCC factor M. Therefore, the unit of interleaving should be  with M the OCC factor.
Proposal 8:  For multi-TB scheduling:
The OCC codeword and order indicated in the DCI applies to all scheduled TBs.	
If interleaved transmission is enabled, the unit of interleaving is , with M the OCC factor

Segmented pre-compensation for 3.75kHz
Current configuration for segmented pre-compensation comprises an indication of segment length. In some cases, this segment length may be exceedingly small (e.g. down to 2ms), which may not be compatible with the DMRS patterns under consideration for 3.75kHz SCS. Both patterns under study for OCC factor 2 (TDM and CDM) have a basic structure of 4 slots (8ms). In both cases, there are two consecutive slots without any DMRS. In order to enable channel estimation, the segmented pre-compensation length should be at least 8ms.
Proposal 9: When a UE is scheduled with 3.75kHz SCS with OCC-2, the UE applies a pre-compensation segment length of at least 8ms
FFS: details

Mixed BPSK and QPSK
The baseband signal generation of -BPSK and -QPSK includes a phase rotation  across OFDM symbols (TS 36.211, 10.1.5). This different phase rotation across different modulation orders results in a loss of orthogonality across UEs using -BPSK and -QPSK: despite both users using orthogonal cover codes (e.g. with a phase of  for the BPSK user, and  for the QPSK user), after applying the phase rotation the baseband signal would have a phase of [ for the BPSK user, and   for the QPSK user, which is not orthogonal.
Proposal 10: RAN1 to study whether / how to enable OCC across UEs using different modulation orders (-BPSK and -QPSK)
One potential solution to this issue would be to disable the rotation of  for the QPSK case, since the impact on PAPR/CM is much smaller than in the BPSK case.

Summary
In this contribution we presented our views on uplink capacity enhancements for IOT NTN. We made the following observations and proposals:
Proposal 1:  Adopt the following DMRS pattern for 15kHz NPUSCH uplink capacity enhancements ( is the OCC length,  is the assigned OCC codeword for the UE):
Option 1: DMRS symbols are spread before the OCC is applied according to the formula: 

Proposal 2:  Adopt the DMRS pattern for 3.75 kHz SCS NPUSCH uplink capacity enhancements that does not skip/drop the samples due to TDM, with the following equation:


Proposal 3: RAN1 to specify NPUSCH OCC in the following scenarios:
Connected mode dynamic grant.
EDT
PUR
CB-msg3
Proposal 4: For NPUSCH with OCC:
NPUSCH transmissions can only start in slots that are a multiple of 
After postponements due to NPRACH / UL gap, the NPUSCH transmission is restarted in the first slot after the NPRACH / UL gap that is a multiple of 
If a group of  overlaps with NPRACH / UL gap, the whole set of  is postponed.
 for 15kHz SCS, and  for 3.75kHz SCS

Proposal 5: RAN1 to define the basic unit of transmission for NPUSCH with OCC as a “super RU” to leverage capacity gains from OCC. A “super-RU” is a set of consecutive M RUs.

Proposal 6: RAN1 to consider RV cycling on a “super-RV” basis for NPUSCH with OCC.

Proposal 7: For NPUSCH with OCC:
The OCC codeword and OCC order (including OCC ON/OFF) is indicated dynamically in DCI.
FFS: Details (e.g. whether explicit or implicit)

Proposal 8:  For multi-TB scheduling:
The OCC codeword and order indicated in the DCI applies to all scheduled TBs.	
If interleaved transmission is enabled, the unit of interleaving is , with M the OCC factor

Proposal 9: When a UE is scheduled with 3.75kHz SCS with OCC-2, the UE applies a pre-compensation segment length of at least 8ms
FFS: details

Proposal 10: RAN1 to study whether / how to enable OCC across UEs using different modulation orders (-BPSK and -QPSK)

3GPP TSG RAN WG1 #120bis	R1-2502882
Wuhan, China, April 7th – 11th, 2025

Agenda item:		9.11.4
Source:	Nordic Semiconductor ASA
Title:					IoT-NTN uplink capacity/throughput enhancement
Document for:		Discussion and Decision

Conclusions

In this contribution we discussed issues related to uplink capacity/throughput enhancement for NB-IoT-based NTN system, and we have the following proposals:
Proposal 1: For NPUSCH Format 1 single-tone 15kHz SCS, Option 1 is selected for implementation of CDM-based DMRS scheme.
Proposal 2: The OCC segment within a NPUSCH transmission with OCC is dropped if it collides with NPRACH occasion.
Proposal 3: The dynamic activation/deactivation of OCC feature for both 15 kHz and 3.75 kHz SCS is considered. Alternatively, the dynamic selection between the legacy DMRS and the new DMRS schemes is implemented. 
Proposal 4: In the case of 15 kHz SCS, dynamic indication of OCC index and dynamic activation/deactivation of OCC feature can be implemented by re-using the reserved states of subcarrier indication field of DCI Format N0.
Proposal 5: In the case of 3.75 kHz SCS, the 16 reserved states of the subcarrier indication field of DCI Format N0 are used to indicate an allocation for legacy NPUSCH transmission or an allocation for OCC-based NPUSCH transmission with the legacy DMRS for those UEs which are configured to OCC-based NPUSCH transmission by RRC signalling, while the first 48 states are used for allocating NPUSCH with OCC-scheme and a new DMRS pattern.
Proposal 6: In the case of 3.75 kHz SCS, the RV index and OCC index are indicated jointly using the RV index field of the DCI Format N0.

3GPP TSG RAN WG1 #120bis		R1-2503122	
Wuhan, China, 7th – 11th April 2025


Agenda Item 	:	9.11.4
Source 	:	Moderator (Sony)
Title 	:	FL Summary #3 for IoT-NTN
Document for	: Discussion



1	

Conclusions

This document is the feature lead summary for IoT-NTN in RAN1#120bis. It contains the FLS discussion and lists the proposals that were considered in online and offline sessions.