3GPP TSG-RAN WG1 Meeting #121	R1-2503283
St Julian’s, Malta, May 19th – 23rd, 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: Support Option 2 for TDM DMRS mapping for 3.75kHz SCS OCC for NPUSCH format 1
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. 
Proposal 3: 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.
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 4: For the NPUSCH slots colliding with NRPACH resources, or UL GAP, the NPUSCH slots should be postponed with granularity of OCC span.
Proposal 5: For the NPUSCH slots colliding with UL timing adjustment gaps, the NPUSCH slots should be dropped with granularity of OCC span.
Proposal 6: Dynamic activation / deactivation of OCC and the OCC sequence index can be indicated in DCI format N0.
For 15kHz SCS OCC, “Subcarrier indication” field can be repurposed for dynamic activation / deactivation of OCC and the OCC sequence index. The mapping is in table 2
For 3.75kHz SCS OCC, 1 bit in "Modulation and coding scheme" field can be repurposed for dynamic activation / deactivation of OCC, as shown in table 3. If OCC is activated, 1bit in “Subcarrier indication” field can be repurposed for the OCC sequence index. The mappings OCC sequence index and subcarrier indication can be configurable by RRC according to table 4 and table 5.

3GPP TSG-RAN WG1 Meeting #121	R1-2503338
St Julian’s, Republic of Malta, May 19th – 23rd, 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	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 2	For 3.75kHz SCS OCC for NPUSCH format 1, and the mapping between DMRS sequence samples and active TDM DMRS slots as per Option 1 (i.e., Sequential mapping of samples of the original DMRS sequence to active DMRS slots).  One aspect to highlight is that the length of the OCC reference signal sequence  should account for the fact that the OCC spreading with OCC length 2 doubles the utilization of time-domain resources , therefore the length of the  sequence needs to be scaled by M.
Observation 3	For 3.75kHz SCS OCC for NPUSCH format 1, and the mapping between DMRS sequence samples and active TDM DMRS slots as per Option 2 (i.e., Dropping of samples of the original DMRS sequence in blanked slots).  One aspect to highlight is that the length of the OCC reference signal sequence  should account for the fact that the OCC spreading with OCC length 2 doubles the utilization of time-domain resources, therefore the length of the  sequence needs to be scaled by M.
Observation 4	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 5	A “Slot-level OCC” spreading using an “OCC length 2” inherently doubles the utilization of resources in the time-domain.
Observation 6	For 15kHz SCS OCC length 2 Slot-Level NPUSCH format 1, the OCC reference signal sequence  of the CDM DMRS formula agreed in RAN1# 120bis, invokes the legacy reference signal sequence  which is multiplied by  (i.e., the OCC codeword [1 1] or [1 -1]), meaning that for every  sample we get two as a result [] or [], which implicitly accounts for the OCC spreading without having to scale the length of the new  sequence length by M.
Observation 7	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 8	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 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 9	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 10	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 11	Touching upon the DCI design, in the last meeting six legacy DCI fields (Modulation and coding scheme, Repetition number, Redundancy version, Number of scheduled TB for Unicast, Subcarrier indication, Resource reservation) were listed as candidates for “indicating OCC sequence index and activation / deactivation”.
Observation 12	In relation with the previous observation, in Table 1 we compared one-on-one the Pros and Cons of those legacy DCI fields. All candidates have (at least to some extent) downsides, but among the listed legacy DCI fields the candidates identified with affordable impacts for “indicating OCC sequence index and activation / deactivation” are: the “Subcarrier indication” field, the “Number of scheduled TB for Unicast” field, and possibly the “Repetition number” field.
Observation 13	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 14	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 activation/deactivation” field.
Observation 15	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 16	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 17	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 18	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 19	In relation with previous observation, possible ways of overcoming the disruptions that a gap can cause on OCC’d transmissions, could be leaving it up to the network to avoid or at least alleviate the issues through a proper OCC scheduling that mind about the presence of gaps. If an issue were identified that is not solvable via implementation, RAN1 can strive to fix it during maintenance phase.
Observation 20	PUR already offers through “Shared-PUR,” the possibility of allowing up to 2 UEs transmitting over the same UL time-frequency resources.
Observation 21	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 22	Using PUR along with OCC will be challenging since the pre-configured based transmissions won’t allow for a dynamic pairing, which makes uncertain whether a persistent paring will continue to be suitable across subsequent uplink transmission occasions.
Observation 23	Before supporting OCC for Multi-TB grant, RAN1 needs to perform an analysis on how those two features will operate together and what are the foreseen specification impacts on the physical layer procedures describing the Multi-TB Grant in clauses 16.4.1, 16.4.2, 16.5, 16.5.1, 16.5.1.2, and 16.6.
			
Based on the discussion in the previous sections we propose the following:

Proposal 1	To secure the completion of this Rel-19 objective, for NPUSCH Format 1 single-tone with OCC length 2, RAN1 prioritizes finalizing the discussions on the TDM DMRS design, CDM DMRS design, and DCI design.
Proposal 2	For OCC length 2 Symbol-level NPUSCH format 1 single-tone with 3.75 kHz SCS, confirm the Working Assumption on the support of “TDM DMRS”.
Proposal 3	For OCC length 2 Symbol-level NPUSCH format 1 single-tone with 3.75 kHz SCS, the mappings between DMRS sequence samples and active TDM DMRS slots from RAN1# 120bis which are to be down-selected, are also described in terms of equations for clearly defining the length of the OCC reference signal sequence:
Option 1: The OCC reference signal sequence for the “Sequential mapping of samples of the original DMRS sequence to active DMRS slots” is defined as follows:
		
Where , M = 2 (i.e., OCC length), m = 0, 1. 
 
Option 2: The OCC reference signal sequence for the “Dropping of samples of the original DMRS sequence in blanked slots” is defined as follows:
 

Where M = 2 (i.e., OCC length), m = 0, 1. 

Proposal 4	For OCC length 2 Slot-level NPUSCH format 1 single-tone with 15 kHz SCS, the upper limit (i.e.,  in ) of the OCC reference signal sequence length for the CDM DMRS option 1_1 agreed in RAN1# 120bis is as follows:
, m=0, …, M-1	
Where: M is the OCC length, q is the assigned OCC codeword for the UE,  is the reference signal sequence defined in TS36.211 section 10.1.4.1.1.
Proposal 5	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 6	For the DCI design to support OCC-based single-tone transmissions on Format N0, RAN1 considers for “indicating OCC sequence index and activation / deactivation” the following legacy DCI fields: the “Subcarrier indication” field, the “Number of scheduled TB for Unicast” field, and possibly the “Repetition number” field.
Proposal 7	For the DCI design to support OCC-based single-tone transmissions on Format N0, RAN1 adopts the following design:
	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 activation/deactivation” 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 8	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).
It is left up to the Editor how to incorporate the additional scheduling delays “k0” into Table 16.5.1-1 of TS 36.213.
Proposal 9	The potential support of OCC for PUR requires more study (e.g., whether a persistent pairing will maintain orthogonality across PUR occasions), therefore OCC for PUR is not supported in Rel-19.
Proposal 10	RAN1 prioritizes finalizing the remaining open issues (TDM DMRs, CDM DMRS, DCI design) for the support of OCC for single-TB grant. Thus, OCC for Multi-TB grant is not supported in Rel-19.

5 

3GPP TSG RAN WG1 #121                                                                                           R1-2503381
St Julian’s, Malta, May 19th – 23rd, 2025


Source:	vivo
Title:	Remaining issues 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: With the proposed TP#1 based on understanding 2, legacy definitions for some variables are reused as much as possible, e.g. , , and specification modification could be less. 
 Observation 2: With the proposed TP#1 based on understanding 2, the same code rate and allocated time domain resource could be reached via scheduling between legacy mapping pattern and slot-level OCC for NPUSCH format 1 single-tone with 15kHz SCS. 
Observation 3: There is no feasibility issue to be identified for supporting TDM DMRS over 4 slots for 3.75kHz SCS OCC for NPUSCH format 1.
Observation 4: There is no new issue for OCC application for multi-TB scheduling with interleave/non-interleave, compared to the OCC application for single-TB scheduling. 
Observation 5: The phase continuity cannot be maintained after 40ms-UL gaps. 
Observation 6: Phase continuity is hard to be maintained between segments due to the UL re-synchronization within gap.
Observation 7: The OCC application could be across the guard periods for 3.75kHz UL transmissions.
Proposal 1: Support the understanding 2: .
Proposal 2: Support the proposed TP#1 for resource mapping in TS36.211 for OCC for NPUSCH format 1 based on understanding 2.
Proposal 3: Not support the RU extension for NPUSCH OCC. 
Proposal 4：Confirm the working assumption for 3.75kHz SCS OCC for NPUSCH format 1. 
Proposal 5：For TDM DMRS mapping for 3.75kHz SCS OCC, support option 2 for dropping of samples of the original DMRS sequence in blanked slots. 
Proposal 6: Support modulation and coding scheme field and redundancy version field to be repurposed for OCC sequence indication and activation/deactivation. 
Proposal 7: As for OCC application on 40ms-UL gaps for synchronization, NW should 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
NW should 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 #121			R1-2503530
Saint Julian, Malta, May 19th – 23th, 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.

Support option 2 for TDM DMRS pattern.
Option 2: Dropping of samples of the original DMRS sequence in blanked slots
Repurposing one bit from MCS field and repetition number field to indicate OCC sequence index and activation/deactivation.
For case 1, 2 and 3, up to network implement to avoid these cases.
Case 1: UL gaps for synchronization (from Rel-13)
Case 2: Gaps around NPRACH occasion
Case 3: UL timing adjustment gaps and segmentation for IoT-NTN (from Rel-17)
Case 4 and 5 have no impact on OCC.
Case 4: TDM DMRS that are muted
Case 5: Guard periods for 3.75kHz UL transmissions
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 (following 15kHz single-tone DMRS pattern) can be considered.
Reuse single-tone OCC design for indication of OCC sequence and activation/deactivation for multi-tone.

3GPP TSG RAN WG1 #121    		                           R1-2503585
St Julian’s, Malta, May 19th – 23th, 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 remaining details for uplink capacity/throughput evaluation. Followings are proposals in this contribution. 
Proposal 1: Support option 2 for mapping between DMRS sequence samples and active TDM DMRS slots in case of 3.75kHz SCS OCC for NPUSCH format 1. 
Proposal 2: Consider new DCI field for indicating OCC sequence index in DCI format N0. 

3GPP TSG RAN WG1 #121                                                                                         R1-2503638
St Julian’s, Malta, May 19th - 23nd, 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.
Proposal 7: 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.
Proposal 8: After postponements due to NPRACH / UL gap, the NPUSCH transmission is restarted in the first slot after the NPRACH/UL gap that is associated with the first slots of the whole NPUSCH transmission, e.g., .
Proposal 10: For CONNECTED mode, 
OCC sequence index and OCC activation/deactivation can be indicated by re-interpreting the Subcarrier indication filed in the DCI for 15kHz SCS.
OCC sequence index  and OCC activation/deactivation can be indicated by re-interpreting one bit of MCS and RV field in DCI for 3.75kHz SCS; 
Proposal 11: For semi-static configured transmission, 
UE-specific RRC signaling used to enable the OCC feature can be reused to indicate the OCC sequence index.

3GPP TSG RAN WG1 Meeting #121	                      R1-2503764
St Julian's, Malta, MT, May 19th – May 23rd, 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: For the number of repetitions under slot-level OCC, Option A can be considered.
Proposal 2: For the association between TDM DMRS and the OCC index, ption 1 will be a straightforward solution.
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.

3GPP TSG-RAN WG1 Meeting #121	  R1-2503777
St Julian's, Malta, 19 - 23 May, 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 in IoT-NTN is presented, and a few of observations and proposals are made as following:
Proposal 1: For the issue of mapping between DMRS sequence samples and active TDM DMRS slots, we support Option 2, in which dropping of samples of the original DMRS sequence in blanked slots is used.
Proposal 2: Consider the combination of 1bit for MCS and 1bit for repetition number to indicate OCC suquence index and activation/deactivation of OCC.

3GPP TSG RAN WG1 #121                                  			               R1-2503815
St Julian’s, Malta, May 19th – 23th, 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: For TDM DMRS in 3.75kHz SCS OCC for NPUSCH format 1, support option 2, i.e., dropping of samples of the original DMRS sequence in blanked slots.

3GPP TSG RAN WG1 #121                                          R1-2503848
St Julian's, Malta, 19 - 23 May, 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, the remaining issues for the OCC based multiplexing for IoT-NTN is discussed. The observations and proposals are listed below. 

Observation 1:
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 2:
The gaps around NPRACH occasions may impact the phase continuity of UE UL transmission. 

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

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

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

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

Observation 7:
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 8:
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 3.75kHz SCS OCC for NPUSCH format 1, for DMRS sequence samples and active TDM DMRS slots, support option 2.
Option 2: Dropping of samples of the original DMRS sequence in blanked slots

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

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

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

Proposal 5:
When NPUSCH transmission overlaps with the configured NPRACH resource, the NPUSCH can be postponed and transmitted after the configured NPRACH resources, with the granularity of the OCC group.

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

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

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

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

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

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

Proposal 12:
For indicating OCC sequence index and activation / deactivation, repurpose two bits from the following bit fields in DCI N0:
	-	Modulation and coding scheme
-	Redundancy version
-	Subcarrier indication
	

TDoc file reading error

3GPP TSG RAN WG1 #121		                                                    R1-2503932
St Julian's, Malta, 19 - 23 May, 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 proposal.

Proposal 1: For 3.75kHz SCS OCC for NPUSCH format 1, the mapping between DMRS sequence samples and active TDM DMRS slots is dropping of samples of the original DMRS sequence in blanked slots

3GPP TSG RAN WG1 #121			R1- 2503960
St Julian’s, Malta, May 19th – 23th, 2025

Agenda Item:	9.11.4
Source:	Sharp
Title:	IoT NTN OCC activation and sequence index indication 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: The the subcarrier indication and/or the number of repetitions fields in the DCI format N0 can be repurposed to indicate the OCC activation/deactivation and OCC sequence index.
The most signification bit in the subcarrier indication can be used.
The number of repetitions table may be configured with only 4 entries for NTN IoT, and the most significant bit can be used. 

3GPP TSG RAN WG1 #121 	R1- 2504034
St Julian’s, Malta, May 19th – 23th, 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: Legacy IoT NTN rely on segmented repetition periods to facilitate time/frequency synchronization.
Observation 3: The dropping of symbols as part of segmented transmissions may impact the orthogonality of the OCC. 
Observation 4: 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 confirm the working assumption for TDM pattern for DMRS of 3.75kHz with OCC.
Proposal 7: For 3.75kHz SCS OCC, option 2 with dropping of samples of original DMRS sequence in blanked slots should be supported.
Proposal 8: RAN1 to support that 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 for RRC IDLE mode cases, e.g. PUR/EDT/CB-Msg3, should not be supported in Rel19.
Proposal 10: No changing of DCI size when introducing OCC indication in DCI N0.
Proposal 11: RAN1 can select resourceReservationConfigUL field when there is no resource sharing with NR or 1 MSB bit in the subcarrier indication field to indicate the OCC feature activation/OCC sequence index with no restriction on the field values.
Proposal 12: 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 13: Compatibility and co-existence between OCC and non-OCC should be studied.
Proposal 14: RAN1 should discuss the coexistence of UEs supporting and not supporting OCC in IoT NTN.

3GPP TSG RAN WG1 #121								R1-2504071
St Julians, Malta. 19th – 23rd May 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 issues related to the TDM DMRS pattern applied for NPUSCH format 1 with a 3.75kHz SCS. The following proposals are made:
Proposal 1: 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.”

Proposal 2: For the mapping between DMRS sequence samples and active TDM DMRS slots, the following option is adopted:
Option 2: Dropping of samples of the original DMRS sequence in blanked slots

Proposal 3: RAN1 down-selects between the following options for determining the TDM DMRS pattern applied to a UE:
Option 1: NPUSCH transmission can start at every 4 slots; association between OCC codeword and TDM DMRS pattern
Option 2: DMRS pattern starts at beginning of NPUSCH and scheduler orthogonalizes DMRS pattern
Option 3: TDM DMRS pattern is a function of slot number and OCC codeword. NPUSCH can start at any slot boundary
Option 4: TDM DMRS pattern statically or semi-statically associated with a UE. Scheduler pairs UEs with compatible TDM DMRS patterns

Proposal 4: TDM DMRS pattern is a function of slot number and OCC codeword. NPUSCH can start at any slot boundary.

3GPP TSG RAN WG1 #121		R1-2504072	
St Julian’s, Malta, 19th – 23rd May 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#121. It contains the FLS discussion and lists the proposals that were considered in online and offline sessions.

3GPP TSG RAN WG1 #121		R1-2504073	
St Julian’s, Malta, 19th – 23rd May 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#121. It contains the FLS discussion and lists the proposals that were considered in online and offline sessions.

TDoc file unavailable

3GPP TSG RAN WG1 Meeting #121	R1-2504152
St Julian’s, Malta, 19-23 May, 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: For the mapping issue between DMRS sequence samples and active TDM DMRS slots, support option 2, where the original DMRS sequence samples are dropped in blanked slots.

Proposal 2. For the number of repetition via DCI, support the understanding 1

Proposal 3. RAN1 to repurpose the signaling utilizing the existing DCI format N0 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.  

3GPP TSG RAN WG1 #121		R1-2504202
St Julian’s, Malta, May 19th – 23th, 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. The following observations and proposals are made:
Observation 1: For symbol-level OCC2, at least the specification impact in terms of physical resource mapping procedure and TBS determination should be taken into account.
Observation 2: When NPUSCH transmission with OCC overlaps with the fully reserved uplink subframe
For , the postponement can be still performed in the unit of one subframe and the OCC group is not broken.
For , the TDM DMRS group of 4 slots may be separated by the fully reserved subframe.
Observation 3: When the SC-FDMA symbols in the NPUSCH transmission overlapping with reserved symbols are punctured, the OCC orthogonality may be affected.

Proposal 1: Slot-level OCC2 for NPUSCH 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 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 example, after mapping to  SC-FDMA symbols, the  SC-FDMA symbols shall be repeated  additional times, before continuing the mapping of  to the following SC-FDMA symbols.
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 3: When NPUSCH transmission with 3.75kHz SCS symbol-level OCC collides with the fully reserved uplink subframe, the following options can be considered:
Option 1: The postponement of NPUSCH transmission is performed in the unit of 4 slots
Option 2: The OCC is enabled only if the fully reserved uplink subframe is not configured.
Proposal 4: When NPUSCH transmission with OCC collides with the reserved uplink symbols, the following options can be considered:
Option 1: The SC-FDMA symbols in the NPUSCH transmission overlapping with the reserved symbols and the corresponding SC-FDMA symbols after spreading within an OCC group are punctured.
Option 2: The OCC is enabled only if reserved uplink symbols are not configured.
Proposal 5: For indicating OCC sequence index and activation / deactivation, the RV field can be repurposed and the resource reservation field can be constrained to be absent.
Proposal 6: Slot-level OCC2 is supported for multi-tone NPUSCH format 1 with 15 kHz.

3GPP TSG-RAN WG1 Meeting #121	R1-2504273
St Julian's, Malta, 19th -23rd May, 2025

Agenda item:	9.11.4
Source:	MediaTek Inc.
Title:	IoT-NTN uplink capacity and throughput enhancement
Document for:	Discussion

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

DM RS for OCC for NPUSCH:
Proposal 1: Confirm RAN1#120 Working assumption on TDM DMRS with DMRS REs blanking for 3.75kHz SCS OCC for NPUSCH format 1.
Proposal 2: For 3.75kHz SCS OCC for NPUSCH format 1, support Option 2: Dropping of samples of the original DMRS sequence in blanked slots.

OCC indication / Configuration:
Proposal 3: For the DCI indication OCC sequence index and activation / deactivation, support the following:
Repurposed DCI N0 field “Number of scheduled TB for Unicast” – 1 bit
Constrained DCI N0 “Modulation and Coding Scheme” – 1 bit

UL Transmission Gaps:
Proposal 4: 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 #121			R1-2504345
St Julian’s, Malta, May 19th – 23th, 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: For 3.75kHz SCS OCC for NPUSCH format 1, support dropping of samples of the original DMRS sequence in blanked slots.
Proposal 2: Support indication of OCC sequence index and activation/deactivation by re-interpreting 2bits from 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 3: If 3.75kHz SCS NPUSCH transmission collides with NPRACH resource, the entire NPUSCH transmissions covered by an OCC sequence are postponed.
Proposal 4: If NPUSCH transmission collides with UL timing adjustment gaps, the entire NPUSCH transmissions covered by an OCC sequence are dropped.

3GPP TSG RAN WG1 #121		                     R1-2504413
St Julian’s, Malta, May 19th – 23th, 2025
	
Agenda item:	9.11.4
Source: 	Qualcomm Incorporated
Title: 	IOT-NTN uplink capacity/throughput enhancement
Document for:	Discussion and Decision

Conclusion
RAN1 assumes no specification change to support pairing UEs with different modulation orders.

Agreement
For 3.75kHz SCS OCC for NPUSCH format 1, RAN1 down selects between the following mappings between DMRS sequence samples and active TDM DMRS slots:
Option 1: Sequential mapping of samples of the original DMRS sequence to active DMRS slots.
Option 2: Dropping of samples of the original DMRS sequence in blanked slots.

Agreement
For NPUSCH Format 1 single-tone 15kHz SCS, for CDM DMRS with legacy pattern:
DMRS symbols are spread before the OCC is applied
Option 1_1: according to the formula:
, m=0, …, M-1
Where: M is the OCC length, q is the assigned OCC codeword for the UE,  is the reference signal sequence defined in TS36.211 section 10.1.4.1.1 and X is the total number of slots in the NPUSCH transmission after OCC is applied.

Agreement
The OCC sequence index is signalled using DCI format N0.

Agreement
The RRC parameters for IoT-NTN UL capacity enhancements are:



Agreement
For indicating OCC sequence index and activation / deactivation, the following fields may be repurposed or constrained to be not present in the DCI:
Modulation and coding scheme
Repetition number
Redundancy version
Number of scheduled TB for Unicast
Subcarrier indication  
Resource reservation 
In this contribution we present our views on remaining issues for IOT NTN uplink capacity enhancements.
NPUSCH capacity enhancements 

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”.
In RAN#120b, it was agreed that: “For 3.75kHz SCS OCC for NPUSCH format 1, RAN1 down selects between the following mappings between DMRS sequence samples and active TDM DMRS slots:
Option 1: Sequential mapping of samples of the original DMRS sequence to active DMRS slots 
Option 2: Dropping of samples of the original DMRS sequence in blanked slots”

It is important to address the sequence design of the proposed TDM DMRS. We propose a DMRS design that doesn’t drop/skip the samples (due to TDM) i.e., Option 1. 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. 

Regarding Option 2, we note that dropping samples of the original DMRS sequence will result in different cells having the same DMRS sequence, which will result in large errors in channel estimation. For example, with OCC2, 2 UEs will use a downsampled Hadamard sequence (samples skipped = downsampling), which will impact the ability of respective sequences to orthogonalize amongst cells. Assuming UEs starting at the same time are using same TDM DMRS pattern in different cells – say UEs are using [1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0], the 16 Hadamard sequences that are responsible for orthogonalizing cells will look like the following Fig. 1:

Figure 1: Impact of skipping samples (Option 2) on underlying Hadamard sequences. The cell IDs (u) with the same-colored arrow illustrate same DMRS sequences generated for these cells 

It can be noted from the Fig. 1 above that UEs in cell 0 (u=0) will have same DMRS sequence as UEs in cells 2. Similarly, UEs in cell 1 will have the same DMRS sequence as in cell 3. If we observe all the DMRS collisions, for any cell, there is another cell with the exact same DMRS pattern (in the table, cells with same-colored arrows will have same DMRS). This issue does not exist for Option 1. Based on the discussion above, we make the following proposal.

Proposal 1: For 3.75kHz SCS OCC for NPUSCH format 1, the following mapping between DMRS sequence samples and active TDM DMRS slots is adopted:
Option 1:  Sequential mapping of samples of the original DMRS sequence to active DMRS slots, 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. RAN2 is already discussing OCC in conjunction with CB-msg3, so we propose to support this case:.
Proposal 2: RAN1 to specify NPUSCH OCC in the following scenarios:
Connected mode dynamic grant.
CB-msg3

Impact of power imbalance on OCC for CB-msg3:
In RAN2, discussions have been held regarding the impact of power imbalance on OCC in context of using OCC with CB-msg3. The issue is that if 2 UEs doing OCC have severe power imbalance, the performance of OCC may be impacted. We believe that is not true since the UEs will still be orthogonal. For example, let’s say UE 1 uses codeword [1 1] and let’s say UE 2 has a power imbalance of 10 dB, which can be considered as that UE 2 is using codeword [ -] with respect to UE 1. However, the codewords [1 1] and codeword [  -]are still orthogonal. Although CFO may slightly break the orthogonality, we show next that the performance degradation is negligible even for large values of power imbalance. 
We assume a power imbalance of 10 dB between 2 UEs i.e., UE 2 has a power boost of 10 dB more power than UE1. We assume TDM DMRS for both UEs, since it has been agreed as a working assumption already. Also note that TDM DMRS won’t be impacted by power imbalance. We concentrate on the performance of UE1 (with no power boost). The performance of UE1 with and without power imbalance in UE2 has been shown in Fig. 2.

Figure 2: Comparison between no power imbalance and power imbalance on UE 1 for OCC2 with TDM DMRS and 3.75 kHz SCS, 4 RUs, 2 Repetitions, TBSize = 104 bits, Channel = NTN-TDL-C Rural 10 degree elevation with 5 Hz doppler

It can be observed from Fig. 5 that the loss due to power imbalance is minimal. If we observe the SNRs required to achieve 10% BLER, we see that there is only a 0.2 dB loss between the no power imbalance case and the 10 dB power imbalance case. 
Observation 1: Even a power imbalance of 10 dB results in only a performance degradation that is minimal i.e., 0.2 dB for NPUSCH with OCC.
Based on the above discussion, we see that power imbalance is not a problem when it comes to NPUSCH with OCC. Therefore, power imbalance will not be impacting system performance if it uses OCC in NPUSCH CB-msg3. We propose to inform RAN2 of this:
Proposal 3: RAN1 to send an LS to RAN2 indicating that impact of power imbalance on OCC is minimal:
A power imbalance of 10dB results in a performance degradation of 0.2dB (TDM DMRS and 3.75 kHz SCS, 4 RUs, 2 Repetitions, TBSize = 104 bits, Channel = NTN-TDL-C Rural 10 degree elevation with 5 Hz doppler)

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. 3 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 3: 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. 4. 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 4: 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)
For 15kHz NPUSCH, in order to not increase the DCI size, we propose the following design:
If OCC is configured and NPUSCH is scheduled without repetitions, the interpretation of the subcarrier allocation field in the DCI follows legacy design.
If OCC is configured and NPUSCH is scheduled with repetitions, then the interpretation of the DCI in the subcarrier allocation field in DCI is modified as follows:
For 15kHz SCS, the 64 values currently indicated in DCI are as follows:
12 values for single subcarrier
4 values for 3 subcarriers
2 values for 6 subcarriers
1 value for 12 subcarriers
64 – 19 = 45 reserved values
We propose to use the 45 reserved values to indicate single subcarrier with OCC and the OCC CW as follows:

Proposal 8: For 15kHz SCS:
If OCC is configured and NPUSCH is scheduled without repetitions, the interpretation of the subcarrier allocation field in the DCI follows legacy design.
If OCC is configured and NPUSCH is scheduled with repetitions, then the interpretation of the DCI in the subcarrier allocation field in DCI is modified as follows:


For 3.75 kHz single SC NPUSCH, the above technique may not be replicated because 48 values (0-47) are used from Isc field, which means no free bits are available. However, we may be able to jointly encode Isc and  ITBS given that we restrict values of ITBS. Right now, in specification, there are 11 entries in ITBS table with a bit width of 4. If we were to jointly encode Isc and  ITBS , it would require  = 10 bits, which means we won’t save any bits by joint encoding. However, if we were to restrict ITBS  to 10 values,  = 9 bits, therefore we save one bit. This bit may be used for indicating the OCC codeword. 
Due to the lack of spare bits in other fields, we would propose to add one additional bit to indicate OCC ON/OFF as follows:
Proposal 9: For 3.75kHz SCS, if OCC is configured, a new field “OCC ON/OFF” is added to the DCI:
If the number of repetitions for NPUSCH is equal to 1, or if the field "OCC ON/OFF” indicates “no OCC” the DCI is interpreted according to legacy specifications.
If the number of repetitions for NPUSC is greater than 1 and the field “OCC ON/OFF” indicates “OCC”:
The fields “subcarrier indication” and “modulation and coding scheme” are jointly interpreted (10 bits), signaling the location of the subcarrier (48 values), 10 values of I_TBS and the OCC codeword (2 values).
OCC cannot be simultaneously configured with “resource reservation”
DCI is size aligned between 3.75 and 15kHz SCS.

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 10:  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 11: 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


Summary
In this contribution we presented our views on uplink capacity enhancements for IOT NTN. We made the following observations and proposals:
Proposal 1: For 3.75kHz SCS OCC for NPUSCH format 1, the following mapping between DMRS sequence samples and active TDM DMRS slots is adopted:
Option 1:  Sequential mapping of samples of the original DMRS sequence to active DMRS slots, with the following equation:


Proposal 2: RAN1 to specify NPUSCH OCC in the following scenarios:
Connected mode dynamic grant.
CB-msg3

Observation 1: Even a power imbalance of 10 dB results in only a performance degradation that is minimal i.e., 0.2 dB for NPUSCH with OCC.

Proposal 3: RAN1 to send an LS to RAN2 indicating that impact of power imbalance on OCC is minimal:
A power imbalance of 10dB results in a performance degradation of 0.2dB (TDM DMRS and 3.75 kHz SCS, 4 RUs, 2 Repetitions, TBSize = 104 bits, Channel = NTN-TDL-C Rural 10 degree elevation with 5 Hz doppler)

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 15kHz SCS:
If OCC is configured and NPUSCH is scheduled without repetitions, the interpretation of the subcarrier allocation field in the DCI follows legacy design.
If OCC is configured and NPUSCH is scheduled with repetitions, then the interpretation of the DCI in the subcarrier allocation field in DCI is modified as follows:

Proposal 9: For 3.75kHz SCS, if OCC is configured, a new field “OCC ON/OFF” is added to the DCI:
If the number of repetitions for NPUSCH is equal to 1, or if the field "OCC ON/OFF” indicates “no OCC” the DCI is interpreted according to legacy specifications.
If the number of repetitions for NPUSC is greater than 1 and the field “OCC ON/OFF” indicates “OCC”:
The fields “subcarrier indication” and “modulation and coding scheme” are jointly interpreted (10 bits), signaling the location of the subcarrier (48 values), 10 values of I_TBS and the OCC codeword (2 values).
OCC cannot be simultaneously configured with “resource reservation”
DCI is size aligned between 3.75 and 15kHz SCS.

Proposal 10:  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 11: 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

3GPP TSG RAN WG1 #121			R1-2504460
Malta, May 19th – 23rd, 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 3.75kHz SCS OCC for NPUSCH format 1, the DMRS position in the TDM DMRS pattern is:
Option 1: DMRS position follows fixed TDM DMRS pattern from the first scheduled slot for each UE
Option 2: associated with the OCC sequence index
Option 3: signalled separately to the OCC sequence index
FFS: signalling 

Proposal 2: When [Nrep  in 213 or]  [in 211] is the value from the repetition field of the DCI, M is the OCC factor and   is the number of repetitions of the data before OCC itself, understanding 1 shall be adopted
understanding 1:  , and 
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 activation/deactivation and OCC sequence index is signaled by DCI format N0 with repurposing the existing fields (e.g, RV field+ MCS field or RV field + Subcarrier indication field).

3GPP TSG RAN WG1 #121	R1-2504543
St Julian’s, Malta, May 19th – 23rd, 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: Confirm the following working assumption: 
Working assumption
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.
Proposal 2: For 3.75kHz SCS OCC for NPUSCH format 1, the DMRS position in the TDM DMRS pattern is associated with the OCC sequence index.
Proposal 3: The OCC segment within a NPUSCH transmission with OCC is dropped if it collides with NPRACH occasion or with UL pre-compensation gap.
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, while the first 48 states are used for allocating NPUSCH with OCC-scheme.
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.
Proposal 7: . When [Nrep  in 213 or]  [in 211] is the value from the repetition field of the DCI, M is the OCC factor and   is the number of repetitions of the data before OCC itself, the following applies:  .

3GPP TSG RAN WG1 #121	 			                      R1- 2504564
St Julian’s, Malta, May 19th – 23rd, 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: Since the number of slots before and after the UL synchronization gap is multiples of 4 and the number of slots for the UL synchronization gap is multiples of 4, any specific enhancement is needed to resolve the OCC broken issue if the OCC broken issue is solved for the postponement due to NPRACH. 
Observation 2: For the postponement due to NPRACH, the postponement granularity of 2 slots can guarantee the TDM between two different DMRS TDM patterns even with the postponement due to NPRACH in the middle of the DMRS TDM pattern for 3.75kHz SCS. 
Observation 3: For pre-compensation gap, the postponement of 2 slots will cause too high latency for all the values of the pre-compensation gap especially for 3.75kHz SCS. Meanwhile, according to the current specification, the UE punctures parts of NPUSCH transmission during the pre-compensation gap instead of the postponement. 
Observation 4: For 3.75kHz single-tone NPUSCH format 1 DMRS sequence generation, dropping of samples of the original DMRS sequence in blanked slots can make identical sequences for different cells.
Observation 5: For 15kHz SCS, the number of reserved states for the subcarrier indication is sufficient to jointly indicate the allocated subcarrier(s), whether the OCC feature is activated, and the OCC sequence index. On the other hand, for 3.75kHz SCS, the number of reserved states for the subcarrier indication is not sufficient. 
Proposal 1: For NPUSCH format 1 with OCC feature enabled/activated:
After postponements due to NPRACH gap, the NPUSCH transmission is restarted in the first slot after the NPRACH gap that is a multiple of 2 for both 3.75kHz and 15kHz SCS.
After transmissions (and/or postponements due to NPRACH) of  time units, for frame structure type 1, a transmission gap of  time units shall be counted for the NPUSCH resource mapping but not used for transmission of the NPUSCH.
 is the smallest value of the multiples of the OCC that can cover  time units.
e.g., for 3.75kHz SCS,  is 2 symbols, 1 slot, or 2 slots for , respectively.
e.g., for 15kHz SCS,  is 2 slots for all the values of . 
Proposal 2: For 3.75kHz SCS OCC for NPUSCH format 1, support 
Option 1: Sequential mapping of samples of the original DMRS sequence to active DMRS slots. 
Proposal 3: For 3.75kHz SCS OCC for NPUSCH format 1, down-select one of followings: 
Option A: Reference point for applying the DMRS TDM pattern is the beginning of the NPUSCH transmission.
DCI format N0 scheduling NPUSCH transmission with the OCC feature activated indicates the OCC sequence index and the DMRS TDM pattern separately. 
Option B: Reference point for applying the DMRS TDM pattern is SFN#0. 
The DMRS TDM pattern is determined by the OCC sequence index for the NPUSCH transmission. 
Proposal 4: At least for 3.75kHz SCS, if the OCC feature is enabled by the UE-specific RRC, 
DCI subframe repetition number field in the DCI format N0 is used to indicate whether the OCC feature is activated and the OCC sequence index.
FFS: Whether or how to indicate the DMRS TDM pattern index.
UE always assumes that the UE detect the NPDCCH with the maximum repetition factor with respect to the starting symbol of the NPDCCH. 
FFS: Whether the unified solution is used for 15kHz SCS or the subcarrier indication field is reused. 


Q1: For both eMTC and NB-IoT, RAN2 assumes power ramping should be supported for CB-msg3-EDT. RAN2 would like to confirm with RAN1 on whether to have power ramping on this Msg3 (re-)transmission. If RAN1 confirms, please provide the control parameters for power ramping. 
A1: RAN1 confirms to support power ramping for CB-msg3-EDT for both eMTC and NB-IoT. In RAN1 specification point of view, it is preferred to reuse the (N)PRACH transmission power formula including the control parameters for (N)PRACH for CB-msg3-EDT. 
Q2: For eMTC, RAN2 agrees to have MPDCCH configuration for shared resource configuration and decides to reuse the parameters from PUR MPDCCH configuration (in IE PUR-MPDCCH-Config-r16, as below) as baseline. RAN2 think TDD parameter is not needed and maybe narrowband configuration should be defined as a set, not one single narrow band. RAN2 would like to check with RAN1 on how to define the detail MPDCCH configuration. 
PUR-MPDCCH-Config-r16 ::=		SEQUENCE {
	mpdcch-FreqHopping-r16			BOOLEAN,
	mpdcch-Narrowband-r16			INTEGER (1..maxAvailNarrowBands-r13),
	mpdcch-PRB-PairsConfig-r16		SEQUENCE{
		numberPRB-Pairs-r16				ENUMERATED {n2, n4, n6, spare1},
		resourceBlockAssignment-r16		BIT STRING (SIZE(4))
	},
	mpdcch-NumRepetition-r16		ENUMERATED {r1, r2, r4, r8, r16, r32, r64, r128, r256},
	mpdcch-StartSF-UESS-r16			CHOICE {
		fdd								ENUMERATED {v1, v1dot5, v2, v2dot5, v4, v5, v8, v10},
		tdd							ENUMERATED {v1, v2, v4, v5, v8, v10, v20, spare1}
	},
	mpdcch-Offset-PUR-SS-r16	ENUMERATED {zero, oneEighth, oneQuarter,
											threeEighth, oneHalf, fiveEighth,
											threeQuarter, sevenEighth}
}
A2: RAN1 thinks TDD parameter is not needed. However, on the narrowband configuration, since it can have RAN1 specification impact, it is preferred to keep it as one single narrow band. 
Q3: For eMTC, RAN2 agrees to have PUSCH configuration for shared resource configuration and decides to reuse the parameters from PUR PUSCH configuration (in IE PUR-PUSCH-Config-r16, as below) as baseline. RAN2 has some questions on some parameters:
Whether pusch-CyclicShift-r16 and pusch-NB-MaxTBS-r16 are needed 
Whether prb-AllocationInfo should be defined as a “set” format with intention to provide a set of shared frequency-domain resources
Note that:
CE mode B related parameters will not be included as RAN2 agreed to preclude CE mode B.
The power related parameters (p0-UE-PUSCH-r16 and alpha-r16) should be updated based on the result of Q1.
RAN2 would like to check with RAN1 on how to define the detail PUSCH configuration.
A3: In RAN1 point of view, pusch-CyclicShift-r16 is needed since it is used for generating PUSCH DMRS sequence. On pusch-NB-MaxTBS-r16, it is not needed considering that it is used for the UE-specific data. To support CB-msg3-EDT, RAN1 also thinks that prb-AllocationInfo should be defined as a “set” format. On the power related parameters, the power related parameters for PRACH transmission (preambleInitialReceivedTargetPower and powerRampingStep) can be reused. 
Q4: For eMTC, RAN2 has discussed the PDSCH configuration for shared resource configuration. Some companies think PUR PDSCH configuration is configured according to UE capability, which is not the case for CB-Msg3/Msg4 configuration. So, RAN2 does not know whether the parameters of PUR PDSCH configuration (in pur-PDSCH-FreqHopping and pur-PDSCH-maxTBS within IE PUR-Config-r16) is needed. RAN2 would like to check with RAN1 on whether and how to define the detail PDSCH configuration.
PUR-Config-r16 ::=		SEQUENCE {	
	
	pur-PDSCH-FreqHopping-r16		BOOLEAN,
    
	...,
	[[	pur-PDSCH-maxTBS-r17		BOOLEAN						OPTIONAL	-- Need ON
	]]
}
A4: Regarding pur-PDSCH-FreqHopping, RAN1 does not see the clear benefit of supporting frequency hopping for the PDSCH transmission in IoT NTN scenario. On pur-PDSCH-maxTBS, it is not needed considering that it is used for the UE-specific data.
Q5: For eMTC, RAN2 agrees to have PUCCH configuration for shared resource configuration and decides to reuse the parameters from PUR PUCCH configuration (in IE PUR-PUCCH-Config-r16, as below) as baseline. RAN2 would like to check with RAN1 on how to define the detailed PUCCH configuration.
PUR-PUCCH-Config-r16 ::=			SEQUENCE {
	n1PUCCH-AN-r16						INTEGER (0..2047)			OPTIONAL,	-- Need ON
	pucch-NumRepetitionCE-Format1-r16	ENUMERATED {n1, n2, n4, n8}	OPTIONAL	-- Need ON
}
A5: If a single repetition number will be allowed for CB-msg3-EDT, RAN1 can confirm the current IE PUR-PUCCH-Config is a baseline for the PUCCH configuration in this WI. On the other hand, if multiple repetitions will be adopted for CB-msg3-EDT like PRACH transmission, RAN1 suggests to reuse the higher layer parameters pucch-NumRepetitionCE-Msg4-Level0-r13, pucch-NumRepetitionCE-Msg4-Level1-r13, pucch-NumRepetitionCE-Msg4-Level2-r13, and  pucch-NumRepetitionCE-Msg4-Level3-r13 for the PUCCH transmission for Msg4. 
Q6: For NB-IoT, RAN2 agrees to reuse the physical layer parameters pur-PhysicalConfig-r16 in PUR-Config-NB as baseline. RAN2 assumes to have below parameters:
Number of resource units for NPUSCH (as in npusch-NumRUsIndex-r16)
Number of repetitions for NPUSCH (as in npusch-NumRepetitionsIndex-r16)
Set of subcarriers (similar to npusch-SubCarrierSetIndex but change it to a “set”), FFS whether subcarriers are provided as a contiguous set.
MCS configuration for NPUSCH (as in npusch-MCS-r16).  
Note that the power parameters (p0-UE-NPUSCH-r16 and alpha-r16) should be updated according to the result of Q1. 

RAN2 would like check with RAN1 on how to define the detail physical layer parameters.
	pur-PhysicalConfig-r16				SEQUENCE {
		carrierConfig-r16					CarrierConfigDedicated-NB-r13,
		npusch-NumRUsIndex-r16				INTEGER (0..7),
		npusch-NumRepetitionsIndex-r16		INTEGER (0..7),
		npusch-SubCarrierSetIndex-r16		CHOICE {
			khz15								INTEGER (0..18),
			khz3dot75							INTEGER (0..47)
		},
		npusch-MCS-r16						CHOICE {
			singleTone							INTEGER (0..10),
			multiTone							INTEGER (0..13)
		},
		p0-UE-NPUSCH-r16					INTEGER (-8..7),
		alpha-r16							ENUMERATED {al0, al04, al05, al06,
														al07, al08, al09, al1},
		npusch-CyclicShift-r16				ENUMERATED {n0, n6},
		npdcch-Config-r16					NPDCCH-ConfigDedicated-NB-r13
	}	OPTIONAL,	-- Need ON
A6: In RAN1 point of view, npusch-CyclicShift-r16 is needed since it is used for generating multi-tone NPUSCH DMRS sequence. To support CB-msg3-EDT, RAN1 also thinks that npusch-SubCarrierSetIndex should be defined as a “set” format. On the power related parameters, the power related parameters for NPRACH transmission (preambleInitialReceivedTargetPower and powerRampingStepCE1 and preambleInitialReceivedTargetPowerCE1) can be reused. 

Q7: For NB-IoT, RAN2 agrees to have NPDCCH configuration for shared resource configuration and decides to reuse the parameters from PUR PDCCH configuration (in IE NPDCCH-ConfigDedicated-NB-r13, as below) as baseline. RAN2 would like to check with RAN1 on how to define the detail NPDCCH configuration.
NPDCCH-ConfigDedicated-NB-r13 ::=	SEQUENCE {
	npdcch-NumRepetitions-r13			ENUMERATED {r1, r2, r4, r8, r16, r32, r64, r128,
													r256, r512, r1024, r2048,
													spare4, spare3, spare2, spare1},
	npdcch-StartSF-USS-r13				ENUMERATED {v1dot5, v2, v4, v8, v16, v32, v48, v64},
	npdcch-Offset-USS-r13				ENUMERATED {zero, oneEighth, oneFourth, threeEighth}
}

NPDCCH-ConfigDedicated-NB-v1530 ::=	SEQUENCE {
	npdcch-StartSF-USS-v1530			ENUMERATED {v96, v128}
}
A7: Considering the NPDCCH configuration is used for Msg4 scheduling, npdcch-StartSF-USS-r13 and npdcc-Offset-USS-r13 can be reused. However, it is unclear whether or not to reuse npdcch-StartSF-USS-v1530 which is currently not supported for Type2-NPDCCH CSS. 
Q8: For both eMTC and NB-IoT, any other L1 parameters are needed for CB-Msg3-EDT procedure in additional to previous discussion? 

In addition, RAN2 agrees that:
Introduce a new RNTI (i.e. CB-RNTI) for CB-Msg4 monitoring and CB-Msg3 scrambling. We include this agreement in the LS to RAN1 

RAN2 would like to inform RAN1 on the new RNTI for CB-Msg4 monitoring and CB-Msg3 scrambling. RAN2 has not yet made agreements on how to determine the RNTI, but RAN2 assumes there may be some potential RAN1 specification impact on this.
A8: In RAN1 point of view, if the name of the new RNTI is not Temporary C-RNTI, RAN1 specification need to be updated to define new search space with respect to the new RNTI. If the name of the new RNTI is Temporary C-RNTI, RAN1 understands the current Type2-NPDCCH CSS can be reused. 

3GPP TSG RAN WG1#121	   R1-2504704
St Julian’s, Malta, May 19th – 23th, 2025

Agenda Item:	9.11
Source:	WI rapporteur (MediaTek)
Title:	RAN1 agreements for IoT NTN Phase 3 up to RAN1#121
Document for:	Information

Conclusions achieved in RAN1 meetings up to RAN1#121 are listed in sections 2 to 10.

The WI objective from the WID [1] is inserted below for convenience.

WID Objective
The objectives for Release 19 IoT NTN Phase 3 are copied below. 


3GPP TSG RAN WG1 Meeting #116, Feb 24
RAN1#116 made the following agreements:
IoT-NTN uplink capacity/throughput enhancement
Agreements on 9.11.4 IoT-NTN uplink capacity/throughput enhancement

Agreement
For single-tone NPUSCH format 1 transmissions with both 3.75kHz and 15kHz SCS, the following OCC schemes are considered by RAN1 for further study:
Time domain OCC where OCC spreads across:
Symbol-level
Slot-level 
Repetition-level
RV-level

For multi-tone NPUSCH format 1 transmissions, the following OCC schemes are considered by RAN1 for further study:
Time domain OCC where OCC spreads across:
Symbol-level
Slot-level (including Nslot level)
Repetition-level
RV-level
Intra-symbol pre-DFT spreading OCC 

Agreement
The following evaluation assumptions are used for the study of OCC for NPUSCH format 1:



3GPP TSG RAN WG1 Meeting #116bis, Apr 24
IoT-NTN uplink capacity/throughput enhancement
Agreement
For the NPUSCH evaluation assumptions, update the DMRS configuration, as follows:


Agreement
At least the following NPRACH OCC schemes are considered by RAN1 for study:
Intra-symbol group OCC
Inter-symbol group(s) OCC
Inter-repetition OCC 

Agreement
The study of OCC for NPRACH does not consider NPRACH format 2.

Agreement
The following evaluation assumptions are used for the study of OCC for NPRACH:


Agreement
OCC multiplexing is not supported between a UE using NPUSCH format 1 with 3.75kHz SCS and another UE using NPUSCH format 1 with 15kHz SCS.

Agreement
For OCC of NPUSCH format 1, RAN1 will not consider multiplexing more than 4 UEs.

Agreement
For single-tone DMRS when OCC is applied to NPUSCH format 1, RAN1 considers at least the following for further study:
TDM of DMRS. The time domain locations of DMRS for different UEs are different. No OCC is applied for the DMRS of different UEs. 
FFS: Detailed mapping 
CDM of DMRS. The time domain locations of DMRS for different UEs are the same. Different OCCs are applied for the DMRS of different UEs. 
FFS: Detailed mapping
Other schemes are not precluded, including combinations of the above


Agreement
For the NPUSCH evaluation assumptions, update the frequency error assumption, as follows.




3GPP TSG RAN WG1 Meeting #117, May 24
IoT-NTN uplink capacity/throughput enhancement
Agreement
For 3.75kHz single-tone OCC for NPUSCH format 1, RAN1 supports either symbol-level OCC or slot-level OCC. Other OCC schemes are not pursued.
For 15kHz single-tone OCC for NPUSCH format 1, RAN1 supports either symbol-level OCC or slot-level OCC. Other OCC schemes are not pursued.

Agreement
Inter-repetition OCC for NPRACH is not studied further in RAN1.

Agreement
For the time-domain DMRS pattern (including blanked DMRS, if any):
For 15kHz single-tone, RAN1 strives to reuse the Rel-17 DMRS pattern
For 3.75kHz single-tone
 RAN1 studies
Rel-17 DMRS pattern
A new DMRS pattern
The DMRS overhead (including blanked DMRS, if any) for OCC is the same as for Rel-17

Agreement
The Rel-17 guard period locations and length for NB-IoT 3.75kHz UL slot are preserved when OCC is applied to NPUSCH format 1.



3GPP TSG RAN WG1 Meeting #118, Aug 24
IoT-NTN uplink capacity/throughput enhancement

Agreement
RAN1 studies whether the following types of UL transmission gap will impact the design of OCC for IoT-NTN when considering e.g. phase continuity
UL gaps for synchronization (from Rel-13)
Gaps around NPRACH occasions
UL timing adjustment gaps and segmentation for IoT-NTN (from Rel-17)
TDM DMRS that are muted
Guard periods for 3.75kHz UL transmissions

Agreement
The following combinations are considered for further simulation in RAN1 for 3.75kHz SCS OCC for NPUSCH format 1:
Option 1: OCC2, Symbol-level, TDM DMRS
Option 2: OCC2, Symbol-level, CDM DMRS with new pattern
Option 3: OCC2, Slot-level, TDM DMRS
Option 4: OCC2, Slot-level, CDM DMRS with legacy pattern
Option 6: OCC4, Symbol-level, CDM DMRS with new pattern

The following combinations are considered for further simulation in RAN1 for 15kHz SCS OCC for NPUSCH format 1:
Option 1: OCC2, Symbol-level, TDM DMRS
Option 3: OCC2, Slot-level, TDM DMRS
Option 4: OCC2, Slot-level, CDM DMRS with legacy pattern
Option 5: OCC4, Symbol-level, TDM DMRS
Option 7: OCC4, Slot -level, TDM DMRS
Option 8: OCC4, Slot-level, CDM DMRS with legacy pattern

Note 1: For TDM, the legacy DMRS pattern, with DMRS symbols appropriately muted/blanked is used. Companies to report their assumption on whether spreading is applied to the legacy DMRS pattern for 15 kHz SCS.
Note 2: Companies to report DMRS sequence applied.

Agreement
For 3.75kHz SCS, NPUSCH format 1 simulations are performed using an appropriate MCS with SNR at least in the range of -8dB to 0dB.


3GPP TSG RAN WG1 Meeting #118bis, Oct 24
IoT-NTN uplink capacity/throughput enhancement
Agreement
At least the following schemes are supported for single-tone:
For 3.75kHz SCS OCC for NPUSCH format 1:
OCC length 2, Symbol-level
FFS: DMRS pattern(s)
For 15kHz SCS OCC for NPUSCH format 1: 
OCC length 2, Slot-level, CDM DMRS with legacy pattern
FFS: CDM details, e.g. with or without spreading

Agreement
For NPRACH transmission, inter-symbol group OCC is not further studied.

Agreement
For support of single-tone OCC for NPUSCH format 1, RAN1 studies:
The parameters that need to be signalled, considering the following:
OCC codeword
Enabling of OCC feature
FFS: other parameters
For dynamic grant in RRC CONNECTED, study which and whether any parameters are signalled via DCI and which and whether any parameters are signalled by RRC
FFS: whether/how to support cases other than dynamic grant in RRC CONNECTED, e.g. Msg3, PUR, CB Msg3 EDT

3GPP TSG RAN WG1 Meeting #119, Nov 24
IoT-NTN uplink capacity/throughput enhancement

Agreement
For 3.75kHz SCS OCC for NPUSCH format 1, the maximum OCC length is 2 for connected mode.

Agreement
For single tone 15kHz SCS Slot-level OCC for NPUSCH format 1, OCC length larger than 2 is not supported.

Agreement
For NPUSCH Format 1 single-tone 15kHz SCS, RAN1 studies at least the following options for CDM DMRS with legacy pattern for down-selection:
Option 1: DMRS symbols are spread before the OCC is applied, e.g. according to the formula:

Where: M is the OCC length, q is the assigned OCC codeword for the UE and  is the reference signal sequence defined in TS36.211 section 10.1.4.1.1
Option 2: DMRS symbols are not spread before the OCC is applied. 
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 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.
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.

Agreement
For NPUSCH Format 1 single-tone 15kHz SCS, the slot-level scheme for non-DMRS symbols is that spreading is performed in the unit of one slot.
Note: whether RU length is extended or not after applying OCC is a separate discussion.

Agreement
For support of single-tone OCC for NPUSCH format 1 for connected mode, the parameters that need to be signalled are:
OCC sequence index
Enabling of OCC feature
FFS: whether signaling is explicit or implicit


3GPP TSG RAN WG1 Meeting #120, Feb 25
IoT-NTN uplink capacity/throughput enhancement
Agreement
For the support of OCC length 2 for NPUSCH Format 1 single-tone with 3.75 kHz SCS and 15 kHz SCS, the orthogonal sequences are [1 1; 1 -1].

Working assumption
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.
Send LS to RAN4 asking whether there would be any issue (e.g. phase continuity) for supporting such TDM DMRS for IoT NTN.

Agreement
Send the following LS to RAN4:
Overall description
RAN1 has made the following working assumption on the DMRS pattern for OCC for 3.75kHz 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.
  Question:
1. From a RAN4 perspective, is it feasible to introduce support of TDM DMRS, as per the description above, in Rel-19?

Agreement
For CONNECTED mode, UE-specific RRC signalling is used for enabling of the OCC feature.

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.

Agreement
Response to RAN2 LS, to be sent to RAN plenary as well:
From RAN1 perspective, it may be possible to find solutions with specification impact for supporting NB-IoT UEs in RRC connected mode monitor PWS notifications, while some companies expressed concerns due to increased implementation complexity, power consumption at UE side and timely delivery of PWS notifications in NTN context. However, the amount of RAN1 workload for specifying this may not fit in the Rel-19 TU allocation for NTN. RAN1 would like to ask RAN plenary to decide whether RAN1 should work on specifying support of NB-IoT UEs in RRC connected mode monitor PWS notifications in Rel-19.


3GPP TSG RAN WG1 Meeting #120-bis, Apr 25
IoT-NTN uplink capacity/throughput enhancement
Agreement
For the 3.75kHz SCS symbol-based OCC scheme, the granularity of spreading for data is one symbol.

Agreement
Dynamic activation / deactivation of OCC is supported by DCI.
FFS: details of signalling by DCI

Conclusion
RAN1 assumes no specification change to support pairing UEs with different modulation orders.

Agreement
For 3.75kHz SCS OCC for NPUSCH format 1, RAN1 down selects between the following mappings between DMRS sequence samples and active TDM DMRS slots:
Option 1: Sequential mapping of samples of the original DMRS sequence to active DMRS slots 
Option 2: Dropping of samples of the original DMRS sequence in blanked slots


Agreement
For NPUSCH Format 1 single-tone 15kHz SCS, for CDM DMRS with legacy pattern:
DMRS symbols are spread before the OCC is applied
Option 1_1: according to the formula:
           , m=0, …, M-1
Where: M is the OCC length, q is the assigned OCC codeword for the UE,  is the reference signal sequence defined in TS36.211 section 10.1.4.1.1 and X is the total number of slots in the NPUSCH transmission after OCC is applied 


Agreement
The OCC sequence index is signalled using DCI format N0.

Agreement
The RRC parameters for IoT-NTN UL capacity enhancements are:




Agreement
For indicating OCC sequence index and activation / deactivation, the following fields may be repurposed or constrained to be not present in the DCI:
Modulation and coding scheme
Repetition number
Redundancy version
Number of scheduled TB for Unicast
Subcarrier indication  
Resource reservation 


 3GPP TSG RAN WG1 Meeting #121, May 25

 IoT-NTN uplink capacity/throughput enhancement

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]

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.

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

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. 

3GPP TSG-RAN WG1 #121	R1-2504803
St Julian's, Malta, 19th -23rd May, 2025               



Agenda Item:	5
Source:	MediaTek Inc., Qualcomm
Title:	Discussion on reply LS on CB-msg3-EDT
Document for:	Discussion & Decision 


1. 

Conclusions:
TBA


11. Appendix A
In RAN2#129
RAN2 #129 Agreements:
1.	RAN2 assumes that at least the following will be part of the shared resources configuration for CB-msg3 (FFS on other aspects)
	-	Time domain resources for (N)PUSCH occasions: periodicity and start time (e.g., start subframe, start SFN)
	-	Frequency domain resources for (N)PUSCH occasions 
	-	repetition number
	-	(N)PDCCH resource
	-	MCS
6.	As Signalling design Baseline RAN2 assumes the PUR config and the NPRACH config for shared (N)PUSCH config can be used and some of the parameters can be included in a new CB EDT config.

In RAN2#129bis

Agreements;
4.	We don’t introduce support for eMTC CE mode B case (it will not be possible to signal resources to be used for this case)
5.	We specify support for NB-IoT with 15kHz with no specific enhancements, leaving to NW implementation whether to implement this or not, accepting potential performance degradation.
7.	The start of CB-msg3 EDT transmission window is aligned with the start of time domain (N)PUSCH resource.
8.	The CB-msg3 EDT transmission window length and periodicity may be different. FFS on possible signalling optimization in case the length and periodicity are the same.
9.	RAN2 assumes power ramping should be supported for CB-msg3-EDT (for both eMTC and NB-IoT) should be supported and will ask RAN1 for confirmation and in case which parameters should apply

(CB-Msg3-EDT configuration for eMTC)
10.	For eMTC, introduce a new IE (e.g. CB-Msg3-ConfigSIB-r19) for shared resources configuration of CB-Msg3 in SIB2.
11.	For eMTC, introduce MPDCCH configuration in shared resources configuration. The fields in IE PUR-MPDCCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters (e.g. whether additional narrow band is needed).
12.	We will not support TDD related parameters.
13.	For eMTC, introduce PUSCH configuration in shared resources configuration. The fields in IE PUR-PUSCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters. (e.g. whether pusch-CyclicShift-r16, pusch-NB-MaxTBS-r16 are needed, whether prb-AllocationInfo should be defined as a “set” format with intention to provide a set of shared frequency-domain resources).
14.	For eMTC, check with RAN1 if anything is needed for PDSCH configuration in shared resources configuration
15.	For eMTC, introduce PUCCH configuration in shared resources configuration. The fields in IE PUR-PUCCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters.

(CB-Msg3 configuration for NB-IoT)
16.	For NB-IoT, introduce a new IE (e.g. CB-Msg3-ConfigSIB-NB-r19) for shared resources configuration of CB-Msg3 in SIB2-NB and SIB22-NB for non-anchor carrier.
17.	For NB-IoT, introduce below physical layer parameters in shared resources configuration as below: 
	-	Number of resource units for NPUSCH (as in npusch-NumRUsIndex-r16)
	-	Number of repetitions for NPUSCH (as in npusch-NumRepetitionsIndex-r16)
	-	Set of subcarriers (similar to npusch-SubCarrierSetIndex but change it to a “set”), FFS whether subcarriers are provided as a contiguous set.
	-	MCS configuration for NPUSCH (as in npusch-MCS-r16).  
	-	PDCCH parameters (as in NPDCCH-ConfigDedicated-NB-r13)
	-	The non-anchor carrier index for monitoring Msg4. If this field is absent, anchor carrier is assumed to be used.
	NOTE: confirm with RAN1 is needed

Agreements (part3):
1.	The CB-msg3-EDT configuration (e.g., number of replicas, number of time resources and number of frequency resources) is CE level specific.



12. Appendix B
According to the specifications in TS 36.213 Clause 16.5.1.1 Resource allocation
The resource allocation information in uplink DCI format N0 for NPUSCH transmission or configured by higher layers for NPUSCH transmission using preconfigured uplink resource indicates to a scheduled UE
a set of contiguously allocated subcarriers () of a resource unit determined by the Subcarrier indication field, or by the higher layer parameter npusch-SubCarrierSetIndex in PUR-Config-NB
a number of resource units () determined by the resource assignment field according to Table 16.5.1.1-2, or by the higher layer parameter npusch-NumRUsIndex in PUR-Config-NB
a repetition number () determined by the repetition number field according to Table 16.5.1.1-3, and for a NPUSCH transmission using preconfigured uplink resource, the UE shall use the repetition number configured by higher layers; except for NPUSCH with 16QAM where .
For NPUSCH transmission with subcarrier spacing, where  is the subcarrier indication field and is reserved, or nsc is configured by higher layers parameter npusch-SubCarrierSetIndex in PUR-Config-NB for NPUSCH transmissions using preconfigured uplink resources.
For NPUSCH transmission with subcarrier spacing, the subcarrier indication field () in the DCI or npusch-SubCarrierSetIndex in PUR-Config-NB for NPUSCH transmissions using preconfigured uplink resources determines the set of contiguously allocated subcarriers () according to Table 16.5.1.1-1.

Table 16.5.1.1-1: Allocated subcarriers for NPUSCH with .


Table 16.5.1.1-2: Number of resource units () for NPUSCH.

Table 16.5.1.1-3: Number of repetitions () for NPUSCH.


13. 

3GPP TSG-RAN WG1 #121	R1-2504804
St Julian's, Malta, 19th -23rd May, 2025               



Agenda Item:	5
Source:	MediaTek Inc., Qualcomm
Title:	Moderator summary #2 on reply LS on CB-msg3-EDT on IoT-NTN uplink capacity and throughput enhancements 
Document for:	Discussion & Decision 


1. 

Conclusions:
A reply LS including the replies to RAN2 questions Q1, Q2, Q3, A4, Q6, and Q7 was sent to RAN2 in R2-2504905. 


11. Appendix A
In RAN2#129
RAN2 #129 Agreements:
1.	RAN2 assumes that at least the following will be part of the shared resources configuration for CB-msg3 (FFS on other aspects)
	-	Time domain resources for (N)PUSCH occasions: periodicity and start time (e.g., start subframe, start SFN)
	-	Frequency domain resources for (N)PUSCH occasions 
	-	repetition number
	-	(N)PDCCH resource
	-	MCS
6.	As Signalling design Baseline RAN2 assumes the PUR config and the NPRACH config for shared (N)PUSCH config can be used and some of the parameters can be included in a new CB EDT config.

In RAN2#129bis

Agreements;
4.	We don’t introduce support for eMTC CE mode B case (it will not be possible to signal resources to be used for this case)
5.	We specify support for NB-IoT with 15kHz with no specific enhancements, leaving to NW implementation whether to implement this or not, accepting potential performance degradation.
7.	The start of CB-msg3 EDT transmission window is aligned with the start of time domain (N)PUSCH resource.
8.	The CB-msg3 EDT transmission window length and periodicity may be different. FFS on possible signalling optimization in case the length and periodicity are the same.
9.	RAN2 assumes power ramping should be supported for CB-msg3-EDT (for both eMTC and NB-IoT) should be supported and will ask RAN1 for confirmation and in case which parameters should apply

(CB-Msg3-EDT configuration for eMTC)
10.	For eMTC, introduce a new IE (e.g. CB-Msg3-ConfigSIB-r19) for shared resources configuration of CB-Msg3 in SIB2.
11.	For eMTC, introduce MPDCCH configuration in shared resources configuration. The fields in IE PUR-MPDCCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters (e.g. whether additional narrow band is needed).
12.	We will not support TDD related parameters.
13.	For eMTC, introduce PUSCH configuration in shared resources configuration. The fields in IE PUR-PUSCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters. (e.g. whether pusch-CyclicShift-r16, pusch-NB-MaxTBS-r16 are needed, whether prb-AllocationInfo should be defined as a “set” format with intention to provide a set of shared frequency-domain resources).
14.	For eMTC, check with RAN1 if anything is needed for PDSCH configuration in shared resources configuration
15.	For eMTC, introduce PUCCH configuration in shared resources configuration. The fields in IE PUR-PUCCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters.

(CB-Msg3 configuration for NB-IoT)
16.	For NB-IoT, introduce a new IE (e.g. CB-Msg3-ConfigSIB-NB-r19) for shared resources configuration of CB-Msg3 in SIB2-NB and SIB22-NB for non-anchor carrier.
17.	For NB-IoT, introduce below physical layer parameters in shared resources configuration as below: 
	-	Number of resource units for NPUSCH (as in npusch-NumRUsIndex-r16)
	-	Number of repetitions for NPUSCH (as in npusch-NumRepetitionsIndex-r16)
	-	Set of subcarriers (similar to npusch-SubCarrierSetIndex but change it to a “set”), FFS whether subcarriers are provided as a contiguous set.
	-	MCS configuration for NPUSCH (as in npusch-MCS-r16).  
	-	PDCCH parameters (as in NPDCCH-ConfigDedicated-NB-r13)
	-	The non-anchor carrier index for monitoring Msg4. If this field is absent, anchor carrier is assumed to be used.
	NOTE: confirm with RAN1 is needed

Agreements (part3):
1.	The CB-msg3-EDT configuration (e.g., number of replicas, number of time resources and number of frequency resources) is CE level specific.



12. Appendix B
According to the specifications in TS 36.213 Clause 16.5.1.1 Resource allocation
The resource allocation information in uplink DCI format N0 for NPUSCH transmission or configured by higher layers for NPUSCH transmission using preconfigured uplink resource indicates to a scheduled UE
a set of contiguously allocated subcarriers () of a resource unit determined by the Subcarrier indication field, or by the higher layer parameter npusch-SubCarrierSetIndex in PUR-Config-NB
a number of resource units () determined by the resource assignment field according to Table 16.5.1.1-2, or by the higher layer parameter npusch-NumRUsIndex in PUR-Config-NB
a repetition number () determined by the repetition number field according to Table 16.5.1.1-3, and for a NPUSCH transmission using preconfigured uplink resource, the UE shall use the repetition number configured by higher layers; except for NPUSCH with 16QAM where .
For NPUSCH transmission with subcarrier spacing, where  is the subcarrier indication field and is reserved, or nsc is configured by higher layers parameter npusch-SubCarrierSetIndex in PUR-Config-NB for NPUSCH transmissions using preconfigured uplink resources.
For NPUSCH transmission with subcarrier spacing, the subcarrier indication field () in the DCI or npusch-SubCarrierSetIndex in PUR-Config-NB for NPUSCH transmissions using preconfigured uplink resources determines the set of contiguously allocated subcarriers () according to Table 16.5.1.1-1.

Table 16.5.1.1-1: Allocated subcarriers for NPUSCH with .


Table 16.5.1.1-2: Number of resource units () for NPUSCH.

Table 16.5.1.1-3: Number of repetitions () for NPUSCH.


13.