TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130 	 R2-2503353
St. Julian’s, Malta, May 19th – 23rd, 2025

Agenda item:	8.9.3
Source:	vivo
Title:	Further Discussion on CB-msg3-EDT Mechanism
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we have provided our understanding of CB-EDT procedure. And we made the following proposals:
CB-msg3-EDT configuration & selection:
Proposal 1: CB-msg3-EDT transmission window length and periodicity are configured in multiples of the CB-msg3-EDT occasion periodicity (e.g., value ranging from 1..32).
Proposal 2: If the network intends to set the same value for the window length and periodicity, it configures only the window periodicity. In this case, UE considers all occasions within the periodicity as valid for DSA.
Proposal 3: Regardless of whether the number of DSA replicas is 1 or another value, the network always configures the CB-msg3-EDT transmission window.
Proposal 4: The starting point of the very first CB-msg3-EDT transmission window is located at the beginning of the first symbol of the first available CB-msg3-EDT occasion occurring after the configured starting point offset.
Proposal 5: If RAN1 confirms support for a set of PRB allocation configurations for CB-msg3 specific to a CE level, it is up to UE implementation to select any one of the indicated PRB allocations.

CB-msg3 Tx:
Observation 1: HARQ operation is applicable for both Msg3 and Msg4. 
Observation 2: HARQ feedback is always applied to both Msg4 and PUR. 
Proposal 6: HARQ operation is used for CB-msg3 and CB-msg4 
Proposal 7: HARQ process id 0 and RV 0 are used for CB-msg3-EDT.
Proposal 8: MAC considers each replica transmission as a new transmission.
Proposal 9: HARQ entity obtains the MAC PDU from the HARQ process buffer for the secondary replica.
Proposal 10: RAN2 assumes that HARQ retransmission triggered by DCI is supported for CB-msg3(check with RAN1 on the feasibility in Rel-19 timeline).
Proposal 11: HARQ feedback is applied to CB-msg4.

CB-RNTI:
Proposal 12: RAN2 to definite the CB-RNTI value range to be entirely independent of the RA-RNTI.
Proposal 13: CB-RNTI calculation considers the following parameters,
the subframe timing index of the last valid CB-msg3 occasion within the corresponding CB-msg3-EDT transmission window;
the frequency resource index associated with that last valid CB-msg3 occasion (e.g. PRB index or carrier ID);
the maximum length of CB-msg4 monitoring window.

Response reception & MAC PDU format:
Proposal 14: For both eMTC and NB-IoT, the UE starts the CB-msg4 monitoring window at the end of the corresponding CB-msg3-EDT transmission window plus UE-eNB RTT. No additional network or UE processing time is considered in Rel-19.
Proposal 15: RAN2 confirms that a DSA pointer solution is not needed in Rel-19.
Proposal 16: The new MAC PDU for Cb-msg4 consists of one or more MAC subPDUs and optionally padding. Each MAC subPDU consists one of the following:
-	a MAC subheader with Backoff Indicator only;
-	a MAC subheader and ReleaseRAR including CRID, TAC, HARQ-ACK feedback parameters;
-	a MAC subheader and SetupRAR including C-RNTI, CRID, TAC, HARQ-ACK feedback parameters;
-	a MAC subheader and MAC SDU for CCCH, DCCH or DTCH;
-	a MAC subheader and padding.
Proposal 17: E/T/R/R/BI MAC subheader can be reused for Cb-msg4 MAC PDU format. 
Proposal 18: E/T/D/R/R/R/R/R MAC subheader is introduced for SetupRAR. The D field is used to indicate whether the MAC PDU for DTCH is present.
Proposal 19: R/R/R/LCID/F/L MAC subheader is introduced for MAC SDU carrying CCCH, DCCH or DTCH.  
Proposal 20: SetupRAR is introduced to include 48-bit CRID, 12-bit TAC, 16-bit C-RNTI, 2-bit TPC for HARQ-ACK, and  2-bit TPC for HARQ-ACK timing offset.
Proposal 21: For a given UE, SetupRAR and the corresponding DL RRC message are always sent in the same MAC PDU.
4 

3GPP TSG-RAN WG2 Meeting #130	R2-2503461
St. Julians, Malta, May 19th – 23rd, 2025

Agenda Item:	8.9.3
Source: 	CATT
Title: 	Discussion on open issues for CB-Msg3 EDT
Document for: 	Discussion and Decision

Conclusion
In this contribution, we discussed remaining open issues for CB-Msg3 EDT procedure in [1]. Our proposals are as follows:
Proposal 1 (MAC-2): RAN2 discusses whether to support one specified CB-RNTI value in the specification. 
Proposal 2 (MAC-7): HARQ operation (i.e. 5.4.2) also includes the transmission procedure for CB-Msg3 EDT. RAN2 discusses for a given MAC PDU whether the transmission on the resource(s) selected for subsequent replica(s) (other than the first replica) can be treated as "retransmission" in HARQ operation.
Proposal 3 (MAC-9): No need to introduce NW/UE processing time for the Msg4 monitoring window start. 
Proposal 4 (MAC-10): RAN2 no longer pursues the enhancement for the NW to configure that the Msg4 monitoring window starts in the subframe containing the last (N)PUSCH repetition of the first replica plus UE-eNB RTT.
Proposal 5 (MAC-11): CB-Msg4 without RRC message is allowed as a complete response to CB-Msg3 in CP solution.
Proposal 6 (MAC-12/13): CB-Msg4 MAC PDU includes the following elements:
One Backoff information MAC CE;
One or more Contention Resolution Identity MAC CEs, with each MAC CE including a Contention resolution Identity, C-RNTI (optionally) and timing alignment information (optionally);
(Optionally) One or more MAC SDUs, with each SDU including RRC signaling or User data and associated with a Contention Resolution Identity MAC CE.
Proposal 7 (MAC-14): It is up to RAN1 how to allocate the ACK/NCK feedback resources for a CB-Msg4 multiplexing responses to multiple UEs. 
Proposal 8 (MAC-15): When CB-Msg3 EDT procedure fails, MAC indicates to the upper layers (RRC) which determines whether to fall back to legacy 4-step RA. RAN2 further clarifies whether legacy 4-step RA includes legacy EDT.
Proposal 9 (MAC-18): Up to MAC running CR Rapporteur to decide whether to use a timer or window definition to handle CB-Msg4 reception (which is a Spec modelling issue).

TDoc file unavailable

3GPP TSG-RAN WG2 Meeting #130                                        R2-2503500
St Julian’s, Malta, 19th – 23rd May, 2025
Source:	ZTE Corporation, Sanechips
Title:	Remaining issues for CB-msg3-EDT in IoT NTN
Agenda Item:	8.9.3
Document for:	Discussion and Decision

Conclusion
Based on the above discussion, the following proposals are given:
The time-domain (N)PUSCH resources configuration 
Proposal 1: To introduce the following parameters for the configuration of time domain (N)PUSCH resources for CB-msg3 EDT:
- a start time point expressed by a start SFN and a start subframe
- a periodicity in units of radio frame

The configuration for CB-msg3 transmission window
Proposal 2a: It’s suggested to define the length of CB-msg3 transmission window in units of (N)PUSCH resources periodicity.
Proposal 2b: It’s suggested to introduce a multiplication factor for parameter of replicas, e.g., K as the configurable parameter for the length of CB-msg3 transmission window. The final value of the length of CB-msg3 transmission window is the result of [(the number of replicas) multiplied by the factor of K], that is:
Length of CB-msg3 transmission window = [(the number of replicas) * K] * (N)PUSCH resources periodicity
Proposal 2c: The number of K can be configured by the NW with the maximum value of 4.
Proposal 2d: It’s suggested to also define the periodicity of CB-msg3 transmission window as a value in units of (N)PUSCH resources periodicity.
Proposal 2e: It’s suggested to adjust the end of the CB-msg3 transmission window to at the end of the last (N)PUSCH transmission occasion within the window. The final value of the length of CB-msg3 transmission window is as below:
Length of CB-msg3 transmission window = [(the number of replicas) * K - 1] * (N)PUSCH resources periodicity + Length of (N)PUSCH transmission occasion

Resources configuration and selection for the case of replica = 1
Proposal 3: When configured number of replica equals to 1, there is no need to configure the CB-msg3 EDT transmission window. The UE can select the nearest (N)PUSCH resource for CB-msg3 transmission. Furthermore, UE starts the Msg4 monitoring window after the end of last repetition of CB-msg3 transmission (e.g., the end of (N)PUSCH transmission occasion) plus UE-eNB RTT.

The CB-msg3-EDT resources configuration on non-anchor carrier 
Proposal 4a: It’s suggested to reuse the existing UL and DL non-anchor carriers list to provide CB-msg3 EDT resources configuration.
Proposal 4b: It’s feasible to configure only CB-msg3 EDT resources on a certain UL carrier. Meanwhile, it’s also feasible to configure both NPRACH resources and CB-msg3 EDT resources on a certain UL carrier. Such configuration flexibility can be left to NW implementation.
Proposal 4c: The legacy rules based on selection probability for NPRACH anchor/non-anchor carrier selection can also be reused for anchor/non-anchor carrier selection for CB-msg3 EDT. A separate selection probability different from that for NPRACH can be introduced.

The resources configuration for CB-msg3-EDT with OCC 
Proposal 5: One or multiples RSRP ranges could be introduced to control power imbalance for the UEs to use CB-msg3-EDT with OCC. And the separate RSRP ranges can be flexibly configured per CE level.

Backoff/Fallback schemes for CB-msg3
Proposal 6a: A range of waiting time needs to be included in the Backoff Indicator in Msg4. Based on this information, the UEs can wait for varying durations before retriggering the same procedure, e.g., CB-msg3 EDT.
Proposal 6b: For CB-msg3 EDT procedure, Backoff Indicator also needs to include the information of time occasion, frequency occasion and/or OCC sequence where collisions are detected.
Proposal 6c: For CB-msg3 EDT procedure, fallback to RACH based EDT procedure also needs to be supported.

HARQ for CB-msg3 transmission 
Proposal 7: PDCCH triggered re-transmission of CB-msg3 is not supported.

CB-msg4 monitoring window
Observation 1a: In the scenario 1 with large RTT and not long CB-msg3 transmission window, as there would be no issue of overlapping between CB-msg4 monitoring window and CB-msg3 transmission window, it’s feasible and also reasonable to allow NW configure earlier start of the CB-msg4 monitoring window, e.g., at the end of CB-msg3 EDT transmission occasion of the first replica plus UE-eNB RTT.
Observation 1b: In the scenario 2 with large RTT and long CB-msg3 transmission window, to start CB-msg4 monitoring window earlier can bring obvious gain, e.g., largely shorten the delay for CB-msg4 reception. Meanwhile, even there may be issue of overlapping between CB-msg4 monitoring window and CB-msg3 transmission window, as the transmission window is relatively long, by the time the monitoring window starts, the first or even the first few replicas may have already been successfully transmitted, so it’s also feasible and reasonable to allow NW configure earlier start of the CB-msg4 monitoring window, and prioritize CB-msg4 monitoring within the overlapped window part.
Proposal 8a: Based on network configuration, the CB-msg4 monitoring could start earlier at the end of CB-msg3 EDT transmission occasion of the first replica plus UE-eNB RTT.
Proposal 8b: The network configuration can be an enable/disable indication to enabling/disabling earlier start of CB-msg4 monitoring window.
Proposal 8c: When network configures earlier start of CB-msg4 monitoring window, if there is overlapping between CB-msg3 transmission window and CB-msg4 monitoring window, UE prioritizes the CB-msg4 monitoring.
Proposal 8d: It’s suggested to consider adding processing time with fixed value of 4 subframes for determining the start of CB-msg4 monitoring window.
Proposal 8e: To take the value range of pur-ResponseWindowTimer as baseline for the length of CB-msg4 monitoring window and further discuss whether extended values are needed.

CB-RNTI calculation 
Proposal 9: The CB-RNTI calculation can be as below:
CB-RNTI = 1 + floor(SFN_id/A) + [C*(H-SFN mod B)]
Where, SFN_id is the index of the radio frame of the first time-domain transmission occasion within the selected CB-msg3 transmission window and H-SFN is the index of the hyper frame of the first time-domain transmission occasion within the selected CB-msg3 transmission window.
A is determined by the minimum periodicity of the CB-msg3 transmission window in units of radio frame (e.g., 10ms). B is determined by the maximum length of CB-msg4 monitoring window in units of H-SFN duration. C is determined by the maximum value of floor(SFN_id/A)+1.

Type of CB-msg4
Proposal 10a: A UE Contention Resolution Identity MAC CE can be included in CB-msg4. UE checks whether the received UE Contention Resolution Identity matches the 48 first bits of the CCCH SDU transmitted in CB-msg3 and if matched, UE determines that contention is resolved.
Proposal 10b: For CP solution, if there is no data to be sent to the UE, UE Contention Resolution Identity MAC CE can be merely sent to early terminate the CB-msg3 EDT procedure, no need of RRC message together in the CB-msg4. 

CB-msg4 multiplexing 
Proposal 11: For CB-msg3-EDT procedure, if the CB-msg4 of multiple UEs are multiplexed into the same MAC PDU, the MAC CE or MAC SDU targeting for the same UE should be placed after the UE Contention Resolution Identity of that UE.

HARQ feedback for CB-msg4
Proposal 12: HARQ feedback should be given for each response in CB-msg4.

3GPP TSG-RAN WG2 Meeting #130	R2-2503529
St.Julians, Malta, May. 19th – 23rd, 2025

Agenda Item:	8.9.3
Source: 	OPPO
Title:  	Discussion on CB-msg3 EDT and msg4 enhancement
Document for:	Discussion and Decision

Conclusion
Based on the discussion in section2, we have following observation proposals:
Proposal 1	The CB-RNTI is preconfigured or predefined.
Proposal 2	The length of CB-Msg3 response window is configured shorter than the length of CB-Msg3 transmission window.
Proposal 3	The processing time is considered for the start of CB-Msg3 response window. Up to RAN1 to determine the value.
Proposal 4	Do not consider the solution that the Msg4 monitoring window starts at the end of the first replica.
Proposal 5	For CB-Msg3-EDT in CP solution, the procedure can be considered as terminated if only contention resolution ID is included in CB-Msg4.
Proposal 6	If C-RNTI is included in a CB-Msg4 without RRC message, the CB-Msg3-EDT is considered as terminated once the additional RRC message or data is received after CB-Msg4.
Proposal 7	NW-scheduled CB-Msg3 re-transmission is not supported.
Proposal 8	The resource information for HARQ feedback is indicated in CB-Msg4 for each UE with contention resolution.
Proposal 9	In multiplexed CB-msg4, the following information should be included in MAC PDU:
a.	A MAC subheader with Backoff indicator.
b.	MAC subheaders with time/frequency info of PUSCH occasion.
c.	successRAR including Contention resolution ID, C-RNTI, RRC message, TAC, Resource Information for HARQ feedback.
Proposal 10	MAC indicates CB-Msg3-EDT failure to upper layer when the maximum attempt time of CB-Msg3 is reached.
Proposal 11	In RRC, further UE actions upon reception of CB-Msg3-EDT failure indication from lower layers is left up to implementation.

3GPP TSG-RAN WG2 Meeting #130	R2-2503599
St Julian’s, Malta, 19th – 23th May, 2025	

Agenda Item:	8.9.3
Source: 	TCL
Title:  	Discussion on UL Capability Enhancement for IOT NTN
Document for:	Discussion and Decision

Conclusion
Based on the discussion above, we made the following observations and proposals:
For CB- Msg3 procedure, the Contention Resolution MAC CE is mandatory for Msg4, while the RRC message is not mandatory for Msg4.
RAN2 to confirm that UE can initiate the legacy 4-step RA when the CB-Msg3 procedure fails.
4. 

3GPP TSG-RAN WG2 Meeting #130	R2-2503662
Saint Julian’s, Malta, 19 – 23 May 2025		

Agenda item:	8.9.3
Source:	Nokia, Nokia Shanghai Bell
Title:	Further discussion on UL capacity enhancement for IoT NTN
WID/SID:	IoT_NTN_Ph3-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations and proposals:
CB-Msg3 replica transmission
Proposal 1: RAN2 confirms that the UE shall transmit the exact number of replicas configured by the network for the CB-Msg3 transmission window.

Maximum TBS for CB-Msg3 EDT triggering (open issue MAC-17)
Observation 1: The TBS threshold for legacy EDT is defined as per Coverage Enhancement level. 
Proposal 2: The maximum TBS for CB-Msg3 can be configured on per Converage Enhancement (CE) level specific.
Proposal 3: Below two options can be considered if RAN2 decides to introduce a flexible TBS selection for CB-Msg3.
Option1: NW can configure multiple CB-Msg3 TBS for a CE level
Option2: UE is allowed to select TBS smaller than the configured CB-Msg3 TBS for the corresponding CE level

CB-Msg3 Power Ramping
Proposal 4: The CB-Msg3 power ramping can only happen between CB-Msg3 transmission windows. There is no power ramping between different replicas within a CB-Msg3 transmission window.
Proposal 5: The UE should keep the same CE level within a CB-Msg3 transmission window.

OCC for CB-Msg3
Proposal 6: RAN2 to deprioritize the work on OCC for CB-Msg3.

CB-Msg4 monitoring window (open issue MAC-9 and 10)
Proposal 7: When the Msg4 monitoring window starts at the end of CB-Msg3-EDT transmission window plus UE-eNB RTT, there is no need to consider additional delays for NW/UE processing time.
Observation 2: For full-duplex UE, starting the Msg4 monitoring window in the subframe containing the last PUSCH repetition of the first replica plus UE-eNB RTT does not result in any UL/DL collision. Instead, it enables early termination of Msg3 replica transmissions.
Observation 3: The early termination of Msg3 replica transmissions brings benefits such as reduced UE power consumption, reduced latency and avoidance of PUSCH collisions between UEs.
Proposal 8a: For full-duplex UEs, the UE can start the Msg4 monitoring window in the subframe containing the last PUSCH repetition of the first replica plus UE-eNB RTT, without requiring additional enhancements for UL/DL collision handling.
Proposal 8b: For half-duplex UEs, the UE can start the Msg4 monitoring window in the subframe containing the last PUSCH repetition of the first replica plus UE-eNB RTT, by prioritizing UL replica transmission when the Msg4 monitoring window overlaps with it.
Proposal 9: It is configurable for the network to define the option for how the UE starts its CB-Msg4 monitoring window.

CB-RNTI for CB-Msg4 monitoring (open issue MAC-2)
Proposal 10: The RNTI for CB-Msg4 reception can be reused by different Msg3 transmission windows if the Msg4 monitoring windows corresponding to the different Msg3 transmission windows are not overlapping.
Proposal 11: RAN2 to discuss below formula for deriving RNTI for Msg4 monitoring.
RNTI=X + Msg3_W_index mod (ceil (Msg4_WS/Msg3_WP)) + ceil (Msg4_WS/Msg3_WP)*carrier_id, 
wherein:
X is the starting RNTI for Msg4 reception, which can be defined by RAN2 e.g. X=1 or any other value,
Msg3_W_index is the index of Msg3 transmission window within a periodicity of 1024 SFNs and index 0 corresponds to the Msg3 transmission window starts at the SFN defined by IE startSFN-r19.
Msg4_WS is the window size of Msg4,
Msg3_WP: is the transmission window periodicity of Msg3.

CB-Msg4 for Contention Resolution (open issue MAC-11)
Proposal 12: Reuse the contention resolution scheme in legacy 4-step RACH for CB-Msg3 EDT transmission.
Proposal 13: For CP solution, the CB-Msg3 procedure can be terminated by including the Contention Resolution Identity MAC CE only in CB-Msg4.
Observation 4: In legacy MAC specification, the UE declares Contention Resolution failure if a Msg4 addressed to the UE does not contain the CR ID MAC CE corresponding to the UE’s Msg3, but for CB-Msg3 the UE may have to receive multiple CB-Msg4s before the UE finds the matched CR ID.
Proposal 14: The network may provide assistance information to help the UE determine whether to continue monitoring for CB-Msg4 until the end of the Msg4 monitoring window.

CB-Msg3 EDT fallback and CE level increase (open issue MAC-15)
Proposal 15: If the number of contention resolution failures for CB-Msg3 EDT reaches a threshold, the UE should evaluate its latest measured RSRP to decide whether it should increase the CE level or fallback to 4-step RACH/EDT or PUR.
Proposal 16: If the measured RSRP is significantly better than the threshold to select the next robust CE level, the UE should not increase the CE level for CB-Msg3 re-attempts. Instead, it should fallback to 4-step RACH/EDT or PUR procedure.
Proposal 17: On top of the RSRP threshold for initial CE level selection, introduce an offset to decide whether to increase the CB-Msg3 CE level. 
Proposal 18: Fallback to 4-step RA/PUR is controlled by RRC upon indication from MAC. The UE maintains the CB-Msg3 MAC SDU to include the data in the fallback transmission.
Proposal 19a: Network-indicated fallback mechanism is supported for CB-Msg3 EDT. The UEs with failed contention resolution shall fall back to legacy 4-step RACH and EDT procedure if it receives a fallback indicator in CB-Msg4.
Proposal 19b: The network can also indicate UE to change the CE level for the next CB-Msg3 re-attempt.

CB-Msg4 Content (including open issue MAC-14)
Proposal 20: A new HARQ-Ack resource indicator could be included in the CB-Msg4 to indicate multiple HARQ feedback resource for multiple HARQ feedback.
Proposal 21: Reuse the existing TAC MAC CE format for CB-Msg4. The TAC MAC CE is UE-specific and optional presence.
Proposal 22: Multiple RRC messages (MAC SDUs) can be included into one CB-Msg4.
Proposal 23: RAN2 confirms the potential CB-Msg4 content may include:
Contention Resolution Identities 
RRC message for CB-Msg3 response 
C-RNTI
Timing Advance information
HARQ feedback information
Backoff information
FFS on other NW control information (such as information for assisting Msg4 monitoring, network initiated fallback or CE level change)

CB-Msg4 Structure (open issue MAC-12 and 13)
Observation 5: For MsgB in 2-step RACH, multiple UEs can be responded in one message by including multiple successRAR in one MsgB.
Observation 6: Each SuccessRAR includes the CR ID, the C-RNTI, the TA information and the HARQ feedback resource for a specific UE.
Proposal 24: Define a new MAC PDU format for CB-Msg4. The MsgB format in 2-step RACH can be the baseline.
Proposal 25: For the exact information to be included for each UE, the UE contention resolution ID is the only mandantory element to be delvierd to UE. All the other IEs are optional presence.

TDoc file reading error

GPP TSG-RAN WG2#130   									           R2-2503880
St Julian’s, Malta, May 19th – 23th, 2025
Agenda Item:	8.9.3
Source: 	NEC
Title:	        Discussion on UL Capacity Enhancement for IoT-NTN
Document for:	 Discussion and Decision

Conclusion
This contribution provides our observation and proposals for UL capacity enhancement as listed below:
Observation 1: The candidate RU numbers for EDT are 3, 4, 5, 6, 8, and 10, with each RU number covering various TBSs in the range of 328 to 1000.
Observation 2: The duration of one replica depends on the required number of RUs, the SCS, and the number of subcarriers.
Observation 3: For NB-IoT, the time duration for one CB-msg3 resource could be up to 40.96 s (i.e. 3.75 kHz SCS, 10 RUs, 160 slots, 128 repetitions), which is longer than the duration of one hyper-frame.
Observation 4: For NB-IoT, the time duration for one CB-msg3 resource might neither divides one hyper-frame duration nor is divisible by one hyper-frame duration.
Observation 5: For legacy PUR and NPRACH, the frequency domain resource is a set of contiguously allocated subcarriers. 
Observation 6: The network could control the CB-msg3 EDT power imbalance between different UEs through the RSRP threshold configuration. 

Proposal 1: For the time domain CB-msg3 resource configuration parameters, both the hyper-frame number (H-SFN) and frame number (SFN) are needed.
Proposal 2: For the DSA window starting time:
Option 1: DSA window starts with the CB-msg3 resource together.
Option 2: DSA window stars with an offset to the CB-msg3 resource. 
Option 3: DSA window stars at a configured H-SFN and SFN.
Proposal 3: The DSA window size may be:
Option 1: Implicitly indicated by the DSA replica number times the PUSCH resource periodicity. 
Option 2: Explicitly indicated by the network.
Proposal 4: The DSA window periodicity may be:
Option 1: Implicitly indicated by the DSA window size. 
Option 2: Explicitly indicated by the network.
Proposal 5: Eliminate the DSA window periodicity parameter by aligning it with the DSA window size (i.e., setting periodicity equal to window size).
Proposal 6: RAN2 further discusses the following frequency-domain configuration options:
Option 1: A single contiguous subcarrier set, i.e. one subcarrier starting point with one range
Option 2: Multiple contiguous subcarrier sets, i.e. several subcarriers starting points with corresponding ranges
Proposal 7: RAN2 should configure non-anchor carrier resources for CB-msg3 EDT transmission in SIB22-NB. 
Proposal 8: When multiple carriers are provided for CB-msg3-EDT resource for the same enhanced coverage level from the SIBx, it is up to the UE implementation to select any of the carriers. 
Proposal 9: The next DSA window is the first window instance containing all the selected replica occasions after CB-msg3 is triggered.
Proposal 10: The network should configure at least two RSRP thresholds with a narrow gap to enable CB-msg3 EDT with OCC.
Proposal 11: RAN2 support OCC based CB-msg3 via narrow RSRP gaps and separate resources from the non-OCC based transmission. 
Proposal 12: RAN2 to discuss the CB-msg3 resource, other than cell-specific CB-Msg3 PUSCH resources, to reduce the contention, enhance the successful rate, and improve the whole system performance.
Proposal 13: When determining the starting point of the Msg4 monitoring window, a preconfigured or network indicated processing time is necessary.
Proposal 14: The RNTI calculation should, at least, consider the carrier ID if non-anchor carrier transmission is supported and H-SFN related to the transmission window.
Proposal 15: For CP solution, L2 ACK is supported.
Proposal 16: There is only one UE’s RRC message and/or DL data that could be included in CB-Msg4 if there are RRC messages and/or data from multiple UEs.
Proposal 17: HARQ feedback resource could be indicated to the UE by MAC CE.
Proposal 18: 6 bits relative TAC could be indicated to the UE by MAC CE.
Proposal 19: TPC is also indicated to the UE by MAC CE when the UE enters RRC_CONNECTED state.
Proposal 20: For CB-Msg4, one unified MAC CE could be introduced to include Contention resolution ID, C-RNTI, HARQ feedback resource, TAC, and TPC.
Proposal 21: The unified MAC CE has a variable size considering the different information requirements for the different scenarios.
Proposal 22: One MAC subheader with the number of MAC CEs for all multiplexed MAC CEs should be used to reduce the subheader overhead.
Proposal 23: For MAC PDU format of CB-Msg4, the following two options for the orders of subheader, MAC CE and MAC SDU may be considered:
Option 1: BI subheader, MAC CE subheader, MAC SDU subheader, multiple MAC CEs, MAC SDU, and padding.
Option 2: BI subheader, MAC CE subheader, multiple MAC CEs, MAC SDU subheader, MAC SDU, and padding.
Proposal 24: RAN2 considers defining backoff value as number of DSA window periodicity and the parameter size can be less than 4bits.
Proposal 25: A fallback MAC CE could be included in CB-Msg4, and a UE will fall back to 4-step RACH procedure, when it has received a fallback MAC CE and failed to receive Msg4 response.
Proposal 26: UE MAC can indicate CB-EDT failure to RRC, and if the EDT is allowed to continue, RRC shall trigger RACH-based EDT rather than CB-EDT.
Proposal 27: It is a failure when the max re-attempt number for the current CE level has been reached. 

3GPP TSG-RAN WG2 Meeting #130	R2-2503909
St. Julians, Malta, May 19th – 23rd, 2025                       Revision of R2-2502356

Agenda item:		8.9.3
Source:		Lenovo
Title:		EDT for uplink capacity enhancement in NTN
Document for:		Discussion

Conclusion
In this contribution we discuss the potential issues and solutions for EDT enhancements in IoT NTN. The following proposals are given:
Proposal 1: RAN2 to discuss the fallback schemes for Msg3 transmission failure in CB EDT.
Proposal 2: RAN2 to discuss how to handle the CB-EDT initiation that occurs during GNSS position fix or ephemeris (SIB31) acquiring.
Proposal 3: RAN2 to discuss the following enhancements for Msg4 delivery in EDT:
Msg4 delivery in non-unicast ways (e.g., multicast);
Msg4 delivery using lower layer indication (e.g., Layer 1 indication or MAC CE as in PUR).

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130                              R2-2504047 
St.Julians, Malta, May 19th – 23rd, 2025
                                              
		
Agenda Item:	8.9.3
Source: 	Transsion Holdings
Title:  	Discussion on uplink capacity enhancement 
Document for:	Discussion and Decision 

Conclusion
In this contribution we discussed issues related to uplink capacity enhancement in IoT-NTN and made the following proposals:
Proposal 1: An indication can be included in the DCI to tell UE which shared PUSCH resource’s response is included in the scheduled Msg4, if the UE finds out that the schedulred Msg4 doesn’t include the response corresponding to the shared PUSCH resource the UE sends CB-Msg3-EDT replica, the UE ignores the DCI or skips decoding the corresponding PDSCH.
Proposal 2: An indication can be included in the DCI to tell UE to stop the Msg4 monitoring window.

Proposal 3: the CE level increase mechanism can be considered for CB-Msg3, if the consecutive failures are mainly caused by RF condition,the UE can increase CE level, how to distinguish the failure causes can be FFS.
Proposal 4: if the consecutive failures are mainly caused by resource collision, the UE can fallback to legacy RACH procedure or adjust the DSA parameters to mitigate collision, the details can be FFS.

3GPP TSG-RAN WG2 Meeting #130	R2-2504065
St. Julians, Malta, 19 - 23 May 2025

Agenda Item:	8.9.3
Source:	Huawei, HiSilicon, Turkcell
Title:	Further consideration on UL capacity enhancement 
Document for: Discussion and Decision
1	

Conclusion
This contribution analyses the UL capacity enhancement, and proposes the following:
CB-Msg3 EDT Fallback
Proposal 1: (MAC-15) When the max re-attempt number has been reached, the UE directly falls back to 4-step random access based EDT.
Proposal 2: (MAC-15) When the max re-attempt number has been reached, the MAC layer needs to notify the RRC layer. 
CB-RNTI calculation
Proposal 3: (MAC-2) The calculation of CB-RNTI is based on the first PUSCH occasion within the Msg3 transmission window and can reuse the RA-RNTI calculation formula. 
HARQ feedback for MSG4
Proposal 4: (MAC-14) HARQ feedback resources can be included in the Msg4 payload.
MSG4 monitoring for CB-Msg3 EDT
Proposal 5: (MAC-10) RAN2 confirms that NW can configure that the Msg4 monitoring window starts/restarts in the subframe containing the last (N)PUSCH repetition of each replica plus UE-eNB RTT. The UL/DL collision can be avoided by implementation.

4	

3GPP TSG-RAN WG2 Meeting #130	R2-2504091
Malta, Malta, 19th – 23rd May, 2025	


Agenda item:	8.9.3
Source:	Samsung
Title:	On procedures and open issues for CB-Msg3-EDT
WID/SID:	IoT_NTN_Ph3-Core
Document for:	Discussion and Decision

Conclusion
In this contribution we discussion further issues on contention-based Msg3: 
Observation 1: A CB-Msg4 may contain 0, 1 or 2 MAC SDUs addressed to it.   
Proposal 1: Do not introduce Msg4 monitoring window starting in the subframe containing the last (N)PUSCH repetition (plus UE-eNB RTT).  
Proposal 2: Same RNTI is used for CB-Msg3 and Msg4 and it is derived based on the transmission window.  
Proposal 3: CB-Msg4 monitoring window is a configurable timer. FFS on the value range.   
Proposal 4: The UEs will send HARQ ACK for CB-Msg4 based on scheduling in MAC subheader.   
Proposal 5: For CB-Msg3-EDT CP solution, the RRC procedures can be completed (in MAC and RRC) if UE receives a matching CRID without an RRC message in a CB-Msg4. The CB-Msg4 still needs to be acknowledged.    
Proposal 6: For CB-Msg3-EDT UP solution, the legacy EDT RRC procedures are followed, i.e the procedures can only be completed with an RRC message.     
Proposal 7: RAN2 introduces a single MAC subheader for the case of (MAC-layer) successful CB-Msg3 EDT procedure in CB-Msg4 with at least the following:   
    - UE CRID
    - HARQ Feedback resource configuration
    - Timing Advance Command
    - C-RNTI
Proposal 8: This single MAC subheader is used for all successful cases, i.e completing EDT RRC procedure without RRC message (CP solution), completing EDT RRC procedures with RRC procedure with RRC message, falling back to RRC connected and for rejecting the UE. 
Proposal 9: Send LS to RAN1 regarding design of the HARQ feedback resource configuration field. 
Proposal 10: CB-Msg4 may contain a backoff indication sub-header, which only contains the Backoff Indication.  
Proposal 11: MAC PDU for CB-Msg4 is specified as follows as a baseline (according to Figure 3): 
MAC header consists of optional Backoff indication subheader, CB-Success and 0-2 subheaders for LCID and length indicators for MAC SDUs. The sub-headers for the MAC SDU for a UE follows after the CB-Success. 
MAC payload consists of MAC subPDUs for each UE along with padding. Each MAC subPDU consists of one or two MAC SDUs addressed to one UE. 
Proposal 12: The guiding principle of modelling CB-Msg3-EDT in relation to legacy EDT is that CB-Msg3-EDT is a lower layer enhancement or lower layer special case of EDT.  
Proposal 13: RAN2 to confirm CQI reporting for CB-Msg3-EDT is supported.   

3GPP TSG RAN WG2 #130	R2-2504098
St Julian’s, Malta, May 19 - 23, 2025

Agenda Item:	8.9.3 
Source:	Toyota ITC
Title:	Discussion on Diversity Slotted ALOHA Randomization
Document for:	Discussion and Decision

Conclusion
The observations and proposals of this contribution are summarized as follows: 
Observation 1: A standardized randomization algorithm ensures predictable, consistent and testable UE behavior.
Proposal 1: Standardize a randomization algorithm for Diversity Slotted ALOHA

TDoc file reading error

3GPP RAN WG2 Meeting #130 	R2-2504180
St.Julians, Malta,  May 19th – 23rd , 2025	

Agenda Item:	8.9.3
Source:	InterDigital, Inc.
Title:	CB-EDT.
Document for:	Discussion

Conclusion
In this contribution we discuss uplink capacity enhancements and make the following proposals for discussion:

Msg3 transmission without msg1/RAR

Proposal 1: Introduce new thresholds for CE level selection for PUSCH, separate to the existing PRACH thresholds, and a new “minimum” threshold for selecting CB-EDT/PRACH.

Proposal 2: If the UE determines that the RSRP is below the minimum threshold for CB-EDT, then perform CE level selection for PRACH as per legacy.

Proposal 3: Upon detecting CB-EDT failure then perform CE level selection for PRACH as per legacy. 

Proposal 4: Select from the following options for determining CB-EDT failure (what happens when UE reaches the configured maximum attempts for the current CE level).
Option 1) Re-use the per-CE level PRACH failure handling for CB-Msg3 failures – if transmission fails using the selected CE level configuration, then select the next CE level configuration and retry. Once all CE levels have been tried then CB-EDT is considered to have failed.
Option 2) If CB-EDT fails for the first selected CE level then CB-EDT is considered to have failed, without attempting other CE levels.

 
Efficient delivery (reduced overhead) of msg4 / RRCEarlyDataComplete
Observation 1: PUR feature can terminate the EDT procedure without using RRC, by using Layer 1 ACK or Timing advance MAC CE, if eNB is aware that there is no pending downlink data or signalling. 

Proposal 5: RAN2 to discuss how eNB knows that there is no pending downlink data from the application layer.

Observation 2: With the PUR feature it is possible for the UE to indicate in PURConfigurationRequest whether it expects a downlink response by RRC.

Proposal 6: Introduce “rrc-ACK”, to RRCEarlyDataRequest to indicate whether an RRC Response Message is preferred by the UE for CB-Msg3, similar to PURConfigurationRequest

Proposal 7: Contention Resolution MAC CE includes a new flag indicating whether to terminate only the uplink transmissions, or to terminate the entire procedure and return to RRC_IDLE.

3GPP TSG-RAN WG2 Meeting #130                                    	R2-2504318
St. Julians, Malta, 19 - 23 May 2025                                 	 
	 
Agenda item:	8.9.3
Source:	Qualcomm Incorporated
Title:	CB-Msg3-EDT and Msg4 multicast
Document for:	Discussion and Decision

Conclusion
Following proposals are made:
Proposal 1	Confirm CB-Msg3 transmission using OCC is supported.
Proposal 2	The transmission window configuration includes start time, periodicity and within transmission window includes number of replicas, number of PUSCH occasions and periodicity of PUSCH occasions.
Proposal 3	For NB-IoT, the Msg4 monitoring starts at the end of CB-Msg3-EDT transmission window plus UE-eNB RTT.
Proposal 4	For eMTC, the Msg4 monitoring starts at the end of first replica of CB-Msg3-EDT transmission plus UE-eNB RTT.
Proposal 5	For eMTC half-duplex, the transmission of replica has higher priority than monitoring Msg4 in case of overlapping.
Proposal 6	For eMTC, the CB-RNTI is derived as SFN_id mod (Cmax/10)+offset, where SFN_id is the index of the first radio frame of the specified CB-Msg3 window, Cmax is the maximum possible CB-Msg4 Contention resolution window size in subframes and Offset is defined as the largest value that RA-RNTI can take.
Proposal 7	For NB-IoT, the CB-RNTI is derived as 1 + floor(SFN_id/M) + (1024/M)*carrier_id + offset where SFN_id is the index of the first radio frame of the specified CB-Msg3 window and carrier_id is the index of the UL carrier associated with the specified CB-Msg3, M is the periodicity in radio frames allowed for CB-Msg3 window and Offset is defined as the largest value that RA-RNTI can take.
Proposal 8	For CB-Msg3 EDT, NR 2 step RACH mechanisms should be reused for Msg4 response formats and multiplexing responses of multiple UEs.
Proposal 9	For CB-Msg3 EDT, support the formats for (1) the success response sending UE to RRC_IDLE (with or without DL data), success response waiting further DL data, and success response sending UE to RRC_CONNECTED, (2) response with retry and (3) backoff indication.
Proposal 10	Same as in EDT, discuss whether to allow network sending UE non-EDT UL grant (i.e., asking just to send RRC establishment request message without UL data) while providing CB-Msg3 EDT retransmission UL grant.
Proposal 11	The enhancements done for Msg4 transmission can be applicable to normal 4 step RACH or CB-Msg3 or DSA transmission.

3GPP TSG RAN WG2 #130	R2-2504338
St. Julians, Malta, May 19th – 23rd, 2025

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

Conclusions
In this contribution we discussed issues related to uplink capacity enhancement for NB-IoT-based NTN system, and we have the following proposals:
Proposal 1: Send LS to RAN1 informing on the potential RAN1 work pertaining to detailed physical resource mapping of PUSCH payload data to the configured PUSCH resource and potential other RAN1 topics.
Proposal 2: The total data volume per CB-Msg3 session per UE is upper limited.
Proposal 3: UE is allowed to start transmission of its payload using CB-Msg3 if its payload is smaller or equal to the configured maximum TBS, and the UE may request a scheduled transmission for the rest of the payload via CCCH of Msg3, if the whole payload does not fit into a configured CB-Msg3 resource.
Proposal 4: Upon the request by UE, the base station may move UE to RRC-connected mode by responding the UE with an RRCConnectionSetup(-NB)-message, if the contention resolution for the UE was successful, and thereafter UE does not need to transmit the “initial” transmission again in RRC-Connected state.

3GPP TSG RAN WG2 Meeting #130	R2-2504393
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.9.3
Source:	CMCC	
Title:	Further discussion on uplink capacity enhancement for IoT-NTN
Document for:	Discussion, Decision

Conclusion
Based on the discussions mentioned above, in this contribution we provide some discussions on EDT enhancements for IoT-NTN and have the following observations and proposals:
Proposal 1: Reuse existing configuration solution, that is provide maximum TBS per CE level, and whether configure same maximum TBS value for different CE level is up to network configuration.
Proposal 2: It is proposed to calculate the CB-RNTI based on the start of the time domain (N)PUSCH resource.
Proposal 3: If window length or window periodicity is absent, it could implicitly indicated the two parameters are the same value, we could just provide some description in the field, further enhancement is not needed.
Proposal 4: It is proposed that clarify the configured maximum repetition value for NB-IoT NTN firstly before discuss the issue that whether the periodicity of CB-Msg3 resource may be larger than H-SFN duration.
Proposal 5: NW/UE processing time (e.g. 4 subframes) is needed to be considered for Msg4 monitoring.
Observation 1: The agreed solution has some drawback that after one replica, Msg4 may successfully arrives at UE side but before the end of the Msg3 transmission window, which would lead to an increase in latency.
Proposal 6: It will also be possible for the NW to configure that the Msg4 monitoring window starts in the subframe containing the last (N)PUSCH repetition of the first replica plus UE-eNB RTT as well as NW/UE processing time (If proposal 5 is supported).
Proposal 7: UE prioritize Msg4 monitoring when Msg4 monitoring window overlaps with replica.
Proposal 8: A CB-Msg4 without RRC message is allowed as the complete response to the CB-Msg3 in CP solution.
Proposal 9: Include multiple Contention Resolution Identities corresponding to different UEs in one CB-msg4.
Proposal 10: Reuse the TAC MAC CE to provide the timing alignment information.
Proposal 11: It is proposed to convey CB-Msg4, e.g., the UE Contention Resolution Identity information, C-RNTI, via MAC CE, rather than RRC signaling.
Proposal 12: The CB-Msg4 MAC PDU would have variable size and no padding bits, and each MAC CE consists of CRID MAC CE and/or TAC MAC CE and/or C-RNTI MAC CE for a specific UE.
Proposal 13: It is proposed that provide HARQ ACK per UE corresponding to the successful reception UE to the network.
Proposal 14: The feedback resource could be included in the CB-Msg4 or PDCCH scheduling the CB-Msg4.
Proposal 15: UE fallback to a higher CE level due to contention resolution failure at current CE level with the maximum re-attempt number and continue re-attempt, until the highest CE level. And if the re-attempt at the highest CE level reaches the maximum re-attempt number but still contention resolution failure, then UE could initiate the legacy 4-step RA procedure.

3GPP RAN WG2 Meeting #130	R2-2504479
St.Julians, Malta, May 19th – 23rd, 2025          		      
Agenda Item:	8.9.3
Source:	HONOR
Title:	Discussion on UL capacity enhancement
Document for:	Discussion and Decision
1. 

Conclusions
In this contribution, we discussed the issues related to CB-Msg3 mechanism. Based on the discussion, the following proposals are concluded:
Proposal 1: (issue MAC-12) For CB-MSG3 transmission on the same time domain resource or on the same frequence domain resource, MSG4 can be multiplexed into one MAC PDU.
Proposal 2: (issue MAC-12) For MSG4 multiplexing with the same time domain resource, it needs to indicate the information of the frequency domain resource that used for MSG4 multiplexing transmission.
Proposal 3: (issue MAC-12) For MSG4 multiplexing with the same time domain resource, the frequence domain resource occasion corresponding to CB-MSG3 transmission should be indicated for each MSG4. 
Proposal 4: (issue MAC-12) For MSG4 multiplexing with the same frequency domain resource, the time domain resource occasion corresponding to CB-MSG3 transmission should be indicated for each MSG4.
Proposal 5: (issue MAC-12) If the successRAR is followed by one MAC SDU/padding, one filed in the subheader for successRAR can be used to indicate the length that the UE can skip decoding the followed MAC SDU/padding.
Proposal 6: (issue MAC-13) Reuse the legacy contention resolution mechanism, UE contention resolution identity(48bits) should be included.
Proposal 7: (issue MAC-13) The C-RNTI can be included in the success RAR to indicate the UE needs to receive the subsequent RRC messages or DL data.
Proposal 8: (issue MAC-13) A RRC message is allowed to be included in MSG4, and it is up to NW implementation to decide whether a RRC message is included in MSG4.
Proposal 9: The Msg4 monitoring window should be started/restarted after sending every replica.
4. 

3GPP TSG-RAN WG2 Meeting #130        											                          R2-2504528
Malta, Malta, May 19th – 23th, 2025                                                          Revision of R2-2502771

Agenda item:	8.9.3
Source:	MediaTek Inc.
Title:	Discussion on CB-Msg3-EDT procedure
Document for:	Discussion and Decision

Conclusion
Proposal 1a: (MAC-2) For eMTC, CB-RNTI = 2401+ floor(SFN_id / Wmin) where the SFN_id is the start SFN of the transmission window and the Wmin is the minimum value of transmission window length.
Proposal 1b: (MAC-2) For NB-IoT, CB-RNTI = 4097+ floor(SFN_id / Wmin) + N*carrier_id where the SFN_id is the start SFN of the transmission window, the Wmin is the minimum value of transmission window length, the carrier_id is the index of UL carrier and the N can be the maximum value of floor(SFN_id / Wmin). The carrier_id of the anchor carrier is 0.
Proposal 2a: (MAC-7) HARQ process 0 is used to transmit CB-Msg3.
Proposal 2b: (MAC-7) HARQ feedback is not used for CB-Msg3 transmission.
Proposal 3: (MAC-9) A 3ms processing time is added when the Msg4 monitoring starts.
Proposal 4: (MAC-10) RAN2 does not specify another way of starting Msg4 monitoring window.
Proposal 5: (MAC-11) A CB-Msg4 with only contention resolution identity is allowed as the complete response to the CB-Msg3 in CP solution.
Proposal 6: (MAC-12) Multiple contention resolution IDs could be included in CB-MSG4, the information related to the UE can be assembled in the MAC PDU after the corresponding contention resolution ID.
Proposal 7: (MAC-14) The HARQ resource information can be included in the CB-Msg4 together with contention resolution ID which identity the specific UE.
Proposal 8: (MAC-14) UE will send HARQ ACK for CB-Msg4 if the contention resolution ID matches. No HARQ NACK is sent.
Proposal 9: (MAC-14) The HARQ feedback for CB-Msg4 can be disabled if the HARQ feedback resource is not provided.
Proposal 10: (MAC-14) For NB-IoT, the SubCarrierSpacing of the HARQ feedback for CB-Msg4 is same as the CB-Msg3.
Proposal 11: (MAC-13) The MAC PDU for CB-Msg4 is consist of sub-header(s) follow by MAC payload and optional padding if needed. RAN2 takes the following figure as the baseline for the MAC PDU format of CB-Msg4.

Proposal 12a: (MAC-13) Introduce a new CB BI MAC sub-header in CB-MSg4 for backoff parameter. It has 1bit E for subhead/payload indication, 2 bits T for subhead type, 4 bits BI for backoff indication and 1 bit R for reservation.


Proposal 12b: (MAC-13) Introduce a new CB-Msg3 Response (CBR) MAC sub-header in CB-MSg4. It has 1bit E for subhead/payload indication, 2 bits T for subhead type, 1bit T2 for HARQ ACK resource present, 1 bit T3 for TAC present, 1 bit T4 for C-RNTI present and 2bit R for reservation.

Proposal 12c: (MAC-13) Introduce a new CB Data MAC sub-header in CB-MSg4. It has 1 bit E for subhead/payload indication, 2 bits T for subhead type, 5 bits LCID, 7 bits or 15 bits L for MAC SDU length, 1 bit F for 15 bits L indication.


Proposal 13a: (MAC-13) The 2-bit HARQ ACK resource for eMTC and 4-bit HARQ ACK resource for NB-IoT is used in the CB-Msg3 response.
Proposal 13b: (MAC-13) The 6-bit TAC is used in the in the CB-Msg3 response.
Proposal 13c: (MAC-13) New CB-Msg3 Response (CBR). It has 48 bits contention resolution ID, 2 bits HARQ ACK resource offset for eMTC, 4 bits HARQ-ACK resource for NB-IoT, 6 bits TAC, 16 bits C-RNTI.

CBR for NB-IoT

CBR for eMTC

Proposal 14a: (MAC-15) The MAC layer should indicate the CB-Msg3 failure to the RRC layer.
Proposal 14b: (MAC-15) The RRC layer can decide whether to initiate the legacy 4-step RA or indicate to the NAS layer the failure of connection establishment.
Proposal 15: (MAC-17) RAN2 postpones the discussion on multiple TBSs in CB-Msg3-EDT.
Proposal 16: (MAC-18) A CB-Msg3 contention resolution timer is used to model the CB-Msg3 response window (similar to legacy mac-ContentionResolutionTimer). The network should be able to configure the length of the CB-Msg3 response window longer than the length of legacy contention resolution window.

3GPP TSG-RAN WG2 #130	R2-2504645
St. Julians, Malta, 19 - 23 May 2025

Agenda Item:	8.9.3
Source:	Ericsson
Title:	UL capacity enhancements for IoT NTN
Document for:	Discussion, Decision

1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	Only RAN2#130 and RAN2#131 meetings remain for this work item.
Observation 2	At RAN2#129bis meeting, 35 agreements were made using 952 words and an LS was sent to RAN1 where reply is likely to arrive after RAN2#130.
Observation 3	A single CB-RNTI used by all UEs to scramble Msg3 will minimize the number of RNTIs used for the CB-Msg3-EDT feature and simplifies the specification compared to a CB-Msg3 RNTI that is dependent on which time/frequency resources that are used for sendingthe CB-Msg3.
Observation 4	A single CB-RNTI used by all UEs to monitor for a Msg4 will maximize the NWs ability to multiplex multiple UEs in one Msg4 and thus saving DL resources for Msg4.
Observation 5	The NW can handle high load on Msg4 resources by reconfigure the resources for CB-Msg3-EDT.
Observation 6	When DSA is supported, SA is a special setting of the DSA parameters.
Observation 7	Msg4 monitoring that overlap potential Msg3 transmission opportunities, in the same Msg3 transmission window, will lead to an uneven load on the Msg3 resources and the eNB will have an ambiguity on when it can reply to a correctly decoded Msg3.
Observation 8	A UE individual Msg4 window, after each UEs Msg3 replica transmission or after a few Msg3 opportunities, has less opportunities for the eNB to answer multiple Msg3 in one Msg4 and will prolong the Msg3 window in time for allowing the monitoring for Msg4.
Observation 9	Having only one Msg4 window that start after the end of the Msg3 window ensures plenty of Msg3s to answer in one Msg4 and gives an even load on the Msg3 opportunities.
Observation 10	Specification effort will be higher if fallback from CB-Msg3-EDT is intertwined with random access or PUR.
Observation 11	For 3.75 kHz SCS, the legacy HARQ ACK resource allocation can support up to eight UEs simultaneously when repetitions are needed.
Observation 12	For 15 kHz SCS, the legacy HARQ ACK resource allocation can support up to four UEs simultaneously when more than two repetitions are needed.
Observation 13	In the 5G QoS model, there is an acceptable packet delay budget that 98% of the packets need to fulfill and a there is an acceptable packet loss rate.
Observation 14	There is a standardized 5QI 10 that targets NTNs. It has an RAN PDB of 1080 ms and a PER of 10^-6.
Observation 15	For 5QI 10, each transmission can have a failure rate of up to 14% without violating the QOS requirements in GEO scenarios.
Observation 16	Restrictions that limit the UEs ability to freely select transmission opportunities within a DSA window will increase the probability of collision.
Observation 17	When configuring resources for the DSA window, it is beneficial to allocate more resources in the time domain and less in frequency domain than vice versa.
Observation 18	For 3.75 kHz SCS, HARQ ACK/NACK transmission without repetitions use 8 ms on one subcarrier.
Observation 19	For 15 kHz SCS, HARQ ACK/NACK transmission without repetitions use 2 ms on one subcarrier.
Observation 20	For 3.75 kHz SCS, NPUSCH Format 1 transmission on one RU without repetitions use 32 ms on one subcarrier.
Observation 21	For 15 kHz SCS, NPUSCH Format 1 transmission on one RU without repetitions use 8 ms for one subcarrier, 4 ms for three subcarriers, 2 ms for six subcarriers and 1 ms for twelve subcarriers.
Observation 22	Increasing number of RUs can increase the UL transport block size.
Observation 23	The number of subframes for one NPUSCH transmission increase if more RUs or more repetitions are used.
Observation 24	Some of the contiguous subframes cannot be used for NPUSCH transmissions.
Observation 25	The NB-IoT UEs cannot transmit NPUSCH continuously for more than 256 ms before inserting a 40 ms silent period of postponed NPUSCH transmission subframes.
Observation 26	The NPDSCH transmissions uses 15 kHz SCS and 12 subcarriers.
Observation 27	Not all DL subframes are available for NPDSCH transmission, for example subframes with NPBCH, NPSS, NSSS, SIB1-NB and configured gaps are excluded.
Observation 28	Increasing number of subframes can increase the DL transport block size.
Observation 29	The number of subframes for one NPDSCH transmission increase if more subframes or more repetitions are used.
Observation 30	Some of the contiguous subframes cannot be used for NPDSCH transmissions.
Observation 31	The resource for HARQ ACK/NACK is indicated with 4 bits in the DCI.
Observation 32	For 3.75 kHz SCS, HARQ ACK resources can be on one of 8 different subcarriers and use one of 2 different scheduling delays.
Observation 33	For 15 kHz SCS, HARQ ACK resources can be on one of 4 different subcarriers and use one of 4 different scheduling delays.
Observation 34	There is a gap of at least 12 subframes between the the last NPDSCH subframe and the first NPUSCH subframe carrying the HARQ ACK/NACK.
Observation 35	NPDCCH uses 6 or 12 subcarriers in one subframe (without repetitions) can carry two respectively one DCI.
Observation 36	There is a guard period of at least 3 subframes after an NPUSCH transmission (Format 1 or 2) and first possible NPDCCH reception.
Observation 37	There is a guard period of at least 12 subframes after an NPDSCH reception and the first possible NPDCCH reception.
Observation 38	Some of the contiguous subframes cannot be used for NPDCCH transmissions.
Observation 39	The UEs likely must decode every Msg4 even if each Msg3 use a different RNTIs because UE do not know which RNTI the eNB will reply to, when multiple RNTIs are used.
Observation 40	One Msg4 window can allow for multiple Msg4 transmissions consecutive in time.

Based on the discussion in the previous sections we propose the following:
Proposal 1	RAN2 shall only work on the essential functions of CB-Msg3-EDT and RAN2 shall minimize work on non-essential functions for CB-Msg3-EDT.
Proposal 2	RAN2 deprioritize work on CB-Msg3-EDT for eMTC in release 19.
Proposal 3	The CB-Msg3-EDT configuration indicates one carrier per CE level.
Proposal 4	The UE shall use the cell specific Koffset for the CB-Msg3-EDT procedure, regardless of if it has a UE specific Koffset or not.
Proposal 5	One single CB-RNTI, configured in SIB, is used by all UEs for scrambling Msg3 and for monitoring for Msg4.
Proposal 6	Power ramping for CB-Msg3-EDT is not considered in release 19.
Proposal 7	RAN2 do work on OCC for CB-Msg3-EDT in release 19.
Proposal 8	In the specification, no special provisions are captured for slotted aloha.
Proposal 9	The periodicity of (N)PUSCH resources for CB-Msg3 is not larger than H-SFN duration.
Proposal 10	The scheduling of Msg4 uses NPDCCH format 1.
Proposal 11	The Msg4 contention resolution reuses legacy UE Contention Resolution Identity MAC Control Element.
Proposal 12	There is one Msg4 window per Msg3 window and the Msg4 window start immediately after the Msg3 window, taking UE-eNB RTT and eNB processing into account, that is, there is never any overlap between the Msg3 window and the corresponding Msg4 window.
Proposal 13	If a Msg3 window end in uplink subframe n, the UE is not required to monitor NPDCCH in any downlink subframe that overlaps with uplink subframe n+1 to subframe n+Kmac+3. The UE shall start NPDCCH monitoring in the first NPDCCH subframe, after uplink subframe n+Kmac+3, that do not overlap uplink subframe n+Kmac+3. FFS eMTC timing.
Proposal 14	The CB-Msg4 can contain one C-RNTI MAC CE per UE that is replied to.
Proposal 15	If the UE receives a Msg4 with a UE contention resolution ID MAC CE that match the Msg3 that the UE sent, with an [RRCEarlyDataComplete or RRCConnectionRelease], the UE shall consider the CB-Msg3-EDT procedure successfully completed.
Proposal 16	If the UE receives a Msg4 with a UE contention resolution ID MAC CE that match the Msg3 that the UE sent, without any RRC message the UE shall consider the CB-Msg3-EDT procedure successfully completed and behave as if an [RRCEarlyDataComplete or RRCConnectionRelease] had been received.
Proposal 17	If the UE receives a Msg4 with a UE contention resolution ID MAC CE that match the Msg3 that the UE sent, and a C-RNTI MAC CE (with or without an RRC message) the UE shall consider the contention resolution of the CB-Msg3-EDT successfully completed and start the TAT (possibly implementing an received TAC first) the  and start monitoring PDCCH. FFS how long time the UE shall monitor PDCCH. FFS when/if the MAC indicate (un)successful CB-Msg3-EDT procedure to higher layers in case a C-RNTI is received.
Proposal 18	If no successful contention resolution was received in the Msg4 window after a Msg3 window where a Msg3 was transmitted, the UE shall draw a random number from a back off indicator (indicated in a Msg4, if received, or from a back off indicator in system information) and wait the number of Msg3 windows and in the Msg3 window after the wait, attempt the CB-Msg3 replica selection and transmission of all replicas. FFS if/how power ramping is incorporated. FFS if counters for maximum number of attempts are needed.
Proposal 19	If the UE does not receive a Msg4, with a UE contention resolution ID MAC CE that match the Msg3 that the UE sent, within the Msg4 window after the UEs last CB-Msg3 uplink transmission (including any CB-Msg3 reattempt and possible stepping of CE level), the UE shall consider the CB-Msg3-EDT procedure as unsuccessful.
Proposal 20	If MAC layer has determined that the CB-Msg3-EDT procedure is either successful or unsuccessful, the MAC layer shall inform the higher layers. FFS how/when RRC layers determines (un)successful CB-Msg3-EDT procedure.
Proposal 21	If CB-Msg3-EDT procedure is unsuccessful, it is up to UE implementation whether to trigger further actions (for example, trigger EDT using the random access procedure or trigger PUR transmission or trigger another CB-Msg3-EDT procedure or inform NAS of unsuccessful EDT).
Proposal 22	The NW may include one Timing Advance Command field in Msg4 per UE replied to, the TAC field reuses the eleven-bit TAC field from RAR.
Proposal 23	The Msg4 can contain MAC SDUs carrying downlink data for each UE that is replied to in the Msg4.
Proposal 24	For each UE answered in a Msg4, the successful reception of a Msg4 can be individually acknowledged with a HARQ ACK transmission.
Proposal 25	The number of Msg3 replies in one Msg4 can be left to eNB implementation.
Proposal 26	For each UE that is replied to, Msg4 has a 4 bit HARQ ACK resource allocation, reusing the existing HARQ ACK/NACK allocation signalling in the DCI. FFS eMTC
Proposal 27	In the HARQ-ACK resources for Msg4, the value ‘15’ indicate HARQ feedback disabled. FFS eMTC

8