TDoc R2-2302693:
- Change in BandNR parameters in section 4.2.7.2
- Changes in RRM measurement features in section 5.6

Example snippet: "4.2.7.2 BandNR parameters"

TDoc R2-2303034:
- Inclusion of feature sets into featureSetsEUTRA in UE-EUTRA-Capability in section 2
- Inclusion of received frequencyBandListFilter in the field appliedFreqBandListFilter of the requested UE capability in section 1
- Removal of the band combination from the list of "candidate band combinations" in section 3

Example snippet: "1> include the received frequencyBandListFilter in the field appliedFreqBandListFilter of the requested UE capability"

TDoc R2-2303035:
- Addition of nonCriticalExtension field in IDC-Assistance-r16 in section 1
- Addition of ReducedAggregatedBandwidth-r17 in section 2

Example snippet: "ReducedAggregatedBandwidth-r17 ::= ENUMERATED {mhz0, mhz100, mhz200, mhz400, mhz800, mhz1200, mhz1600, mhz2000}"

TDoc R2-2303096:
- Indication of traffic characteristic of sidelink logical channels in sl-UE-AssistanceInformationNR in section 1

Example snippet: "sl-UE-AssistanceInformationNR Indicates the traffic characteristic of sidelink logical channel(s), specified in the IE SL-TrafficPatternInfo"

TDoc R2-2303164:
- Need for R measDurationSymbols-v1700, ref-SCS-CP-v1700, and tci-StateInfo-r17 in section 1
- Addition of ref-BWPId-r17 in section 2

Example snippet: "measDurationSymbols-v1700 ENUMERATED {sym140, sym560, sym1120} OPTIONAL"

1. RLC-BearerConfig information element:
- Defines the logical channel identity and the type of radio bearer used.
- Can include RLC configuration and MAC logical channel configuration.
- Supports reestablishment of RLC.
- Example snippet: servedRadioBearer CHOICE { srb-Identity SRB-Identity, drb-Identity DRB-Identity }

2. FrequencyInfoUL-SIB:
- Provides basic parameters of an uplink carrier and transmission.
- Includes optional parameters such as additional spectrum emission and frequency shift.
- Example snippet: scs-SpecificCarrierList SEQUENCE (SIZE (1..maxSCSs)) OF SCS-SpecificCarrier

3. ARFCN-ValueNR:
- Indicates the ARFCN for a downlink, uplink or bi-directional NR global frequency raster.
- Defined in TS 38.101-1 [15] TS 38.101-2 [39], clause 5.4.2.
- Example snippet: absoluteFrequencyPointA ARFCN-ValueNR OPTIONAL

4. IntraFreqNeighCellInfo:
- Provides information about neighboring cells in the same frequency band.
- Includes parameters such as physical cell ID and q-offset range.
- Supports SSB position QCL relation and Q-RxLevMinOffsetCell.
- Example snippet: physCellId PhysCellId, q-OffsetCell Q-OffsetRange

5. InterFreqCarrierFreqInfo:
- Defines the carrier frequency for inter-frequency cells.
- Includes optional parameters such as frequency band list.
- Example snippet: dl-CarrierFreq ARFCN-ValueNR, frequencyBandList MultiFrequencyBandListNR-SIB OPTIONAL

6. MeasReportQuantityCLI-r16:
- Indicates the measurement report quantity for CLI.
- Can be SRS-RSRP or CLI-RSSI.
- Example snippet: MeasReportQuantityCLI-r16 ::= ENUMERATED {srs-rsrp, cli-rssi}

7. MeasResultCellListSFTD-NR:
- Consists of SFN and radio frame boundary difference between the PCell and an NR cell.
- Includes hysteresis and time to trigger.
- Supports A4 and A5 threshold.
- Example snippet: timeToTrigger TimeToTrigger, hysteresis Hysteresis

Example snippets:
- "servedRadioBearer CHOICE { srb-Identity SRB-Identity, drb-Identity DRB-Identity }"
- "absoluteFrequencyPointA ARFCN-ValueNR OPTIONAL"
- "scs-SpecificCarrierList SEQUENCE (SIZE (1..maxSCSs)) OF SCS-SpecificCarrier"
- "physCellId PhysCellId, q-OffsetCell Q-OffsetRange"
- "dl-CarrierFreq ARFCN-ValueNR, frequencyBandList MultiFrequencyBandListNR-SIB OPTIONAL"
- "MeasReportQuantityCLI-r16 ::= ENUMERATED {srs-rsrp, cli-rssi}"
- "timeToTrigger TimeToTrigger, hysteresis Hysteresis"

Technical Differences Among TDocs:

1. TDoc R2-2303461: Defines variables such as Ml1, Ml2, Hys, Thresh1, and Thresh2 for distance calculations in reportConfigNR.
Example: "Ml1 is the distance between UE and a reference location for this event (i.e. referenceLocation1 as defined within reportConfigNR for this event), not taking into account any offsets."

2. TDoc R2-2303785: Instructs UE to start or restart T430 upon receiving SIB19 for serving cell with the timer value set to ntn-UlSyncValidityDuration for the serving cell from the subframe indicated by epochTime for the serving cell.
Example: "1> start or restart T430 for serving cell with the timer value set to ntn-UlSyncValidityDuration for the serving cell from the subframe indicated by epochTime for the serving cell."

3. TDoc R2-2303923: Establishes RLC entity and logical channel for target cell group, suspends SRBs for source cell group, and applies newUE-Identity as the C-RNTI in the target cell group.
Example: "3> for each SRB: 4> establish an RLC entity for the target cell group, with the same configurations as for the source cell group;"

4. TDoc R2-2303924: Instructs UE to store the acquired MIB and perform cell re-selection to other cells on the same frequency as the barred cell as specified in TS 38.304 if cellBarred in the acquired MIB is set to barred.
Example: "2> if the cellBarred in the acquired MIB is set to barred: 3> if the UE is a RedCap UE and ssb-SubcarrierOffset indicates SIB1 is transmitted in the cell (TS 38.213 [20]; 3> perform cell re-selection to other cells on the same frequency as the barred cell as specified in TS 38.304 [13])."

Overall, these TDocs differ in terms of the variables defined, instructions for UE actions upon receiving certain signals, and configuration of lower layers for target SpCell.

• Legacy 38.331 defines UE behavior in case of configuration failure during reconfiguration or inability to comply with RRCResume configuration.
Example: "if UE cannot comply with a configuration provided to UE for: case 1) during reconfiguration (defined as a failure in Reconfiguration message), UE shall initiate reestablishment procedure."

• RAN2 specification should be updated to ignore corresponding configuration if a UE in RRC_INACTIVE moves to a new cell that does not support the corresponding features.
Proposal: "When a UE in RRC_INACTIVE is configured with SDT and eDRX and moves to a new cell in which the UE does not support the corresponding features, RAN2 specification should be updated to ignore (i.e., consider as not configured) the corresponding configuration already available in UE."

• SnonIntraSearchQ defines the behavior of UE in terms of measurement initiation and priority for NR inter-frequency or inter-RAT frequency cells based on distanceThresh and referenceLocation.
Example: "If the distance between UE and the serving cell reference location referenceLocation is shorter than distanceThresh, the UE may choose not to perform measurements of NR inter-frequency cells of equal or lower priority, or inter-RAT frequency cells of lower priority."

• There is no restriction on the relationship between SMTC configuration and satellite. One-to-one association between SMTC and satellite is proposed for IDLE/INACTIVE UE to perform SMTC adjustment correctly.
Example: "In order for IDLE/INACTIVE UE to perform the SMTC adjustment correctly, the simple way is to introduce the restriction on one-to-one association between SMTC and satellite."

• Online, 17th - 26th April, 2023, first change 4 UE radio access capability parameters, including supported max data rate for DL/UL for NR and the computing formula for data rate.
Example: "For NR, the approximate data rate for a given number of aggregated carriers in a band or band combination is computed as follows. Data rate (in Mbps) = wherein J is the number of aggregated EUTRA component carriers in MR-DC band combination is the total maximum number of DL-SCH transport block bits received or the total maximum number of UL-SCH transport block bits transmitted, within a 1ms TTI for j-th CC, as derived from TS36.213 [19] based on the UE supported maximum MIMO layers for the j-th CC, and based on the maximum modulation order for the j-th CC and number of PRBs based on the bandwidth of the j-th CC according to indicated UE capabilities."

3GPP-R2-121-bis-e    Agenda Item 6.7.1 : General and stage 2 corrections

- TDoc R2-2304053 covers Multi-RTT Positioning Procedures and DL-AoD Positioning Procedures.
- 8.10.3.1.2.1 Assistance Data Transfer between LMF and UE is specific to Multi-RTT Positioning Procedures.
- Pre-configured DL-PRS assistance data may consist of multiple instances, where each instance is applicable to a different area within the network. This is applicable to both Multi-RTT and DL-AoD Positioning Procedures.
- TDoc R2-2304054 covers the calibration/compensation of the relative time delay between different RF chains in the same TRP/UE and may also possibly consider the offset of the Tx/Rx antenna phase centre to the physical antenna centre.
- Pre-configured DL-PRS assistance data may consist of multiple instances, where each instance is applicable to a different area within the network.
- Positioning integrity is a measure of the trust in the accuracy of the position-related data and the ability to provide associated alerts.
- Rx Timing Error is not specifically mentioned in either TDoc, but may be a factor in both Multi-RTT and DL-AoD Positioning Procedures.

Example snippets from TDoc R2-2304053:
- "8.10.3.1.2.1 Assistance Data Transfer between LMF and UE"
- "Pre-configured DL-PRS assistance data may consist of multiple instances, where each instance is applicable to a different area within the network."
- "8.11.3 DL-AoD Positioning Procedures"

Example snippets from TDoc R2-2304054:
- "The calibration/compensation may also include the calibration/compensation of the relative time delay between different RF chains in the same TRP/UE and may also possibly consider the offset of the Tx antenna phase centre to the physical antenna centre."
- "Pre-configured DL-PRS assistance data may consist of multiple instances, where each instance is applicable to a different area within the network."
- "Positioning integrity"
- "Rx Timing Error" (not specifically mentioned in the TDoc, but relevant to the topic)

TDoc R2-2302404:

- CT4 is implementing GNSS integrity requirements as agreed in SA2 CR S2-2300953.
- There is no clear data structure definition of TTA, TIR, and AL in TS 38.305, which prevents CT4 from implementing this feature.
- CT4 asks RAN2 to define the data structure of TTA, TIR, and AL and provide the related reference to CT4 for implementation.
- Definitions of TTA, TIR, and AL are specified in TS 38.305 [9].

TDoc R2-2302429:

- RAN4 thanks RAN2 for the LS R4-2218006 on the applicability of timing error margin of Rx TEG.
- RAN4 discussed the issues and provided reply LS R4-2220729.
- RAN4 kindly asks RAN2 to take the above information into account in the following work on NR positioning enhancements.

TDoc R2-2304178:

- LS R2-2213320 was sent to SA2 for the parameters sent between LCS client/UE/AF and LMF.
- During the discussion in R2#120, the contribution proposed adding the AD for alert limit and time to alert, with proposed TP.
- The data structure of the contribution above can be taken as the baseline for the discussion on the reply LS to CT4.
- Proposal: Adopt the values for Alert Limit and Time to Alert in R2-2212892 as the baseline for the data structure of TIR and AL.

Example snippets from the original TDoc to support the difference highlighting:

- TDoc R2-2302404: "However, there is no clear data structure definition of TTA, TIR, and AL in TS 38.305, CT4 could not implement this feature based on current definition."
- TDoc R2-2302429: "RAN4 thanks RAN2 for the LS R4-2218006 (R2-2210977) on applicability of timing error margin of Rx TEG."
- TDoc R2-2304178: "During R2#120 meeting, LS R2-2213320 has been sent to SA2 for the parameters sent between LCS client/UE/AF and LMF."

- TDoc R2-2302637:
- NR Enhanced cell ID positioning method
- LMF-initiated Location Information Transfer from UE
- DL-TDOA positioning
- UE sends LPP Provide Location Information message to LMF
- PRS processing window configuration
- Measurement gap configuration
- LMF provides PRS information of neighbor TRPs to serving gNB
- TDoc R2-2302744:
- Pre-configure UE with PRS processing window
- Pre-configure UE with measurement gap
- LMF provides PRS information of neighbor TRPs to serving gNB
- TDoc R2-2304052:
- Assistance data transferred from gNB to LMF
- UL-SRS configuration information requested by LMF from serving gNB
- Table 8.10.2.3-1 lists assistance data that may be transferred from gNB to LMF
- Table 8.13.2.0-1 lists assistance data that may be transferred from gNB to LMF
- Figure 8.13.3.2.1-1 shows UL information Delivery operation from serving gNB to LMF

Examples from TDoc R2-2302637:
- "Figure 8.9.3.3-1 shows the Location Information Transfer operations for the NR E-CID method from UE when the procedure is initiated by the LMF."
- "The UE sends an LPP Provide Location Information message to the LMF and reports the requested measurements that are available in the UE."
- "This request includes the NR E-CID measurements requested by the LMF and supported by the UE as listed in Table 8.9.2.2-1 together with a required response time."

Examples from TDoc R2-2302744:
- "The serving gNB decides to pre-configure the UE with PRS processing window and provides pre-configured PRS processing window configuration(s) with associated ID(s) to the UE by sending RRC Reconfiguration message specified in TS 38.331."
- "The serving gNB decides to pre-configure the UE with measurement gap and provides pre-configured measurement gap configuration(s) with associated ID(s) to the UE by sending RRC Reconfiguration message specified in TS 38.331."
- "The LMF provides the PRS information of the neighbour TRPs to the serving gNB and requests the serving gNB to configure the UE with measurement pre-configurations via NRPPa MEASUREMENT PRECONFIGURATION REQUIRED message."

Examples from TDoc R2-2304052:
- "Table 8.10.2.3-1: Assistance data that may be transferred from gNB to the LMF."
- "The configuration data for a target UE that may be transferred from the serving gNB to the LMF is listed in Table 8.10.2.3-2."
- "Figure 8.13.3.2.1-1 shows the UL information Delivery operation from the serving gNB to the LMF."

3GPP-R2-121-bis-e    Agenda Item 6.7.2 : RRC corrections

3GPP-R2-121-bis-e    Agenda Item 6.7.3 : LPP corrections

• The TDoc defines multiple Information Elements (IEs) including nr-AssistanceAvailability-r16, nr-DL-AoD-ReportConfig-r16, multiMeasInSameReport-r17, NR-DL-PRS-ProcessingCapability, NR-On-Demand-DL-PRS-Configurations, GNSS-SupportList, GNSS-SupportElement, adr-Support, velocityMeasurementSupport, TBS-ProvideCapabilities-r13, NR-DL-TDOA-ProvideCapabilities-r16, NR-DL-AoD-ProvideCapabilities-r16, LOS-NLOS-IndicatorType1-r17, LOS-NLOS-IndicatorType2, and LOS-NLOS-Indicator-r17.
• The IE multiMeasInSameReport-r17 specifies a set of possible DL-PRS configurations that can be requested on-demand by the target device.
• The IE GNSS-SupportList is a sequence of up to 16 GNSS-SupportElement IEs that provide information on GNSS capabilities.
• The IE adr-Support is a Boolean value indicating whether Address Resolution Protocol (ARP) is supported.
• The IE velocityMeasurementSupport is a Boolean value indicating whether velocity measurements are supported.
• The IE TBS-ProvideCapabilities-r13 specifies the Transmission Block Size (TBS) modes supported by the device.
• The IEs NR-DL-TDOA-ProvideCapabilities-r16 and NR-DL-AoD-ProvideCapabilities-r16 specify device capabilities related to time-difference-of-arrival (TDOA) and angle-of-departure (AoD) measurements in the downlink.
• The IE LOS-NLOS-IndicatorType1-r17 provides information on the type of LOS-NLOS-Indicator.
• The IE LOS-NLOS-IndicatorType2 provides information on the LOS-NLOS-Indicator type.
• The IE LOS-NLOS-Indicator provides information on the likelihood of a Line-of-Sight (LOS) propagation path from the source to the receiver.

Example snippets from the original TDoc:
• "multiMeasInSameReport-r17 ENUMERATED { requested } OPTIONAL -- SEQUENCE { on-demand-dl-prs-configuration-list-r17 SEQUENCE (SIZE (1..maxOD-DL-PRS-Configs-r17)) OF On-Demand-DL-PRS-Configuration-r17" - this snippet shows the definition of the IE multiMeasInSameReport-r17 and provides an example of its usage.
• "GNSS-SupportList ::= SEQUENCE (SIZE(1..16)) OF GNSS-SupportElement" - this snippet shows the definition of the IE GNSS-SupportList and its sequence element.
• "adr-Support BOOLEAN" - this snippet shows the definition of the IE adr-Support.
• "TBS-ProvideCapabilities-r13 ::= SEQUENCE { tbs-Modes-r13 BIT STRING" - this snippet shows the definition of the IE TBS-ProvideCapabilities-r13.
• "LOS-NLOS-IndicatorType1-r17 ::= ENUMERATED { hardvalue, softvalue }" - this snippet shows the definition of the IE LOS-NLOS-IndicatorType1-r17.

TDoc R2-2304050:

- The proposal is to refine the LPP periodic location information reporting interval from seconds to milliseconds.
- There is a mismatch in resolution between the scheduled location time and the periodic location information reporting interval, where the former can be configured down to milliseconds and the latter down to seconds.
- There is a mismatch in resolution between the response time and the periodic location information reporting interval, where the former can be configured down to tens of milliseconds and the latter down to seconds.
- Example snippet: "In LPP common request location information, there is a mismatch in resolution between the scheduled location time and the periodic location information reporting interval, where the former can be configured down to milliseconds and the latter down to seconds."

TDoc R2-2304192:

- "Timing Error Margins" are defined in TS 38.133 for the actual measurements only, not for maximum applicable values.
- The reference to a "maximum applicable value in TS 38.133" should be deleted from the field description for nr-UE-RxTEG-TimingErrorMargin in NR-Multi-RTT-SignalMeasurementInformation.
- Proposal 4 is to discuss and decide whether the CR in "R2-2304051, "Missing finer periodicities than 1s", Ericsson." is an essential corrections or not.
- Proposal 1 is that the CR in "R2-2302639, "Corrections on applicability of timing error margin of RxTEG in NR-Multi-RTT-SignalMeasurementInformation field descriptions", CATT" is an essential correction.
- Example snippet: "Therefore, the reference to a 'maximum applicable value in TS 38.133' should be deleted from the field description for nr-UE-RxTEG-TimingErrorMargin in NR-Multi-RTT-SignalMeasurementInformation, as proposed in the CR [1]."

Technical Differences Between TDoc R2-2302639 and TDoc R2-2304139:

1. Purpose:
- TDoc R2-2302639: provides NR Multi-RTT measurements to the location server.
- TDoc R2-2304139: provides DL-PRS assistance data to the location server.

2. Information Elements:
- TDoc R2-2302639: NR-Multi-RTT-SignalMeasurementInformation
- TDoc R2-2304139: NR-DL-PRS-AssistanceData

3. ASN.1 Definition:
- TDoc R2-2302639:
ASN1START NR-Multi-RTT-SignalMeasurementInformation-r16 ::=
ASN1STOP
- TDoc R2-2304139:
ASN1START NR-DL-PRS-AssistanceData-r16 ::=
- The ASN.1 definition for TDoc R2-2304139 includes more details and information compared to TDoc R2-2302639.

Example Snippets from the Original TDocs:

- TDoc R2-2302639:
"The IE NR-Multi-RTT-SignalMeasurementInformation is used by the target device to provide NR Multi-RTT measurements to the location server."
- TDoc R2-2304139:
"The IE NR-DL-PRS-AssistanceData is used by the location server to provide DL-PRS assistance data."

- TDoc R2-2302639:
"6.5.12.4 NR Multi-RTT Location Information Elements – NR-Multi-RTT-SignalMeasurementInformation"
- TDoc R2-2304139:
"First Modified Subclause – NR-DL-PRS-AssistanceData"

- TDoc R2-2302639:
"ASN1START NR-Multi-RTT-SignalMeasurementInformation-r16 ::="
- TDoc R2-2304139:
"ASN1START NR-DL-PRS-AssistanceData-r16 ::="

- TDoc R2-2304139:
"The nr-DL-PRS-SFN0-Offset's and nr-DL-PRS-expectedRSTD's in nr-DL-PRS-AssistanceDataList are provided relative to the "assistance data reference" TRP."
- TDoc R2-2304139:
"NOTE 2: The nr-DL-PRS-ReferenceInfo defines the "assistance data reference" TRP whose DL-PRS configuration is included in nr-DL-PRS-AssistanceDataList."

3GPP-R2-121-bis-e    Agenda Item 6.7.4 : MAC corrections

3GPP-R2-121-bis-e    Agenda Item 6.7.5 : UE capabilities

3GPP-R2-121-bis-e    Agenda Item 6.9.1 : Stage-2

1. Observation 1: For split bearer, either MN or SN can configure the UL PDCP packet delay (D1 measurement) to UE, and it has to be handled by network implementation. For excess delay configuration in NR-DC, the node owning the PDCP terminating point configures the UE.

Example snippet from TDoc R2-2303898:

- "For split bearer, either MN or SN can configure the UL PDCP packet delay (D1 measurement) to UE."
- "For excess delay configuration in NR-DC, Node owning the PDCP terminating point configures the UE."

2. Proposal 1: For the UL PDCP average delay measurement of split bearer, it is proposed RAN2 to agree that the node hosting PDCP entity can configure the measurement.

Example snippet from TDoc R2-2303898:

- "For the UL PDCP average delay measurement of split bearer, it is proposed RAN2 to agree that the node hosting PDCP entity can configure the measurement."

3. In signalling-based immediate MDT, MME provides MDT configuration for both MN and SN towards MN including multi-RAT SN configuration, specifically E-UTRA and NR MDT configuration. In management-based immediate MDT, OAM provides the MDT configuration to both MN and SN independently.

Example snippet from TDoc R2-2303899:

- "In signalling based immediate MDT, MME provides MDT configuration for both MN and SN towards MN including multi RAT SN configuration, specifically E-UTRA and NR MDT configuration."
- "In management-based immediate MDT, OAM provides the MDT configuration to both MN and SN independently."

4. For both MN and SN, management-based MDT should not overwrite signalling-based MDT.

Example snippet from TDoc R2-2303899:

- "For both MN and SN, Management based MDT should not overwrite signalling based MDT."

5. For split bearer, only the node configuring the measurement to UE will receive the measurement result from the UE.

Example snippet from TDoc R2-2303899:

- "For split bearer: only can configure the measurement to UE, and the UE reports the measurement result to corresponding node where the configuration was received from."

3GPP-R2-121-bis-e    Agenda Item 6.9.3 : SON Corrections

# TDoc R2-2302612:
- Specifies how mobility history information is stored by the UE for RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED.
- Example: "This procedure specifies how the mobility history information is stored by the UE for up to N previous RRC connections (N is UE dependent), covering RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED states."

# TDoc R2-2303451:
- Specifies how to set fields in VarRLF-report in case of HO failure or RLF, based on different conditions.
- Example: "If the UE supports RLF-Report for DAPS handover and if any DAPS bearer was configured while T304 was running, set lastHO-Type to daps."
- Example: "If radio link failure was detected in the source PCell, according to clause 5.3.10.3, set timeConnSourceDAPS-Failure to the time between the initiation of the DAPS handover execution and the radio link failure detected in the source."

# TDoc R2-2303452:
- Specifies how to set the measResultListNR in measResultNeighCells for neighboring cells based on CSI-RS measurements.
- Example: "If the CSI-RS measurement quantities are available, set the measResultListNR in measResultNeighCells to include all the available measurement quantities of the best measured cells, other than the source PCell and target PCell, ordered such that the cell with highest CSI-RS SINR is listed first."
- Example: "For the neighboring cells set ordered based on the CSI-RS measurement quantities, the UE includes measurements only for the cells not yet included in measResultListNR in measResultNeighCells to avoid overriding SS/PBCH block-based ordered measurements."

Note: the examples given are not a comprehensive list of all the technical differences between the TDocs, but rather a few examples to support the highlighted differences.

1. MeasResult2EUTRA-r16 and MeasResultRLFNR-r16 are two different SEQUENCE types.
2. MeasResult2EUTRA-r16 contains carrier frequency and measurement result list for EUTRA.
3. MeasResultRLFNR-r16 contains measurement result for cell results, rsIndex results and critical extensions.
4. MeasResultFreqList is a SEQUENCE of MeasResult2NR.
5. MeasResultSCG-Failure is an optional parameter for MeasResultFreqList.

Example snippets from the TDoc to support the difference highlighting:

1. MeasResult2EUTRA-r16 ::= SEQUENCE { carrierFreq-r16 ARFCN-ValueEUTRA, measResultList-r16 MeasResultListEUTRA }
2. MeasResultRLFNR-r16 ::= SEQUENCE { measResult-r16 SEQUENCE { cellResults-r16 SEQUENCE{ resultsSSB-Cell-r16 MeasQuantityResults OPTIONAL, resultsCSI-RS-Cell-r16 MeasQuantityResults OPTIONAL }, rsIndexResults-r16 SEQUENCE{ resultsSSB-Indexes-r16 ResultsPerSSB-IndexList OPTIONAL, ssbRLMConfigBitmap-r16 BIT STRING (SIZE (64)) OPTIONAL, resultsCSI-RS-Indexes-r16 ResultsPerCSI-RS-IndexList OPTIONAL, csi-rsRLMConfigBitmap-r16 BIT STRING (SIZE (96)) SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { ueInformationResponse-r16 UEInformationResponse-r16-IEs, criticalExtensionsFuture 3GPP TSG-RAN WG2 Meeting INTEGER (0..1023) =
3. MeasResultFreqList ::= SEQUENCE (SIZE (1..maxFreq)) OF MeasResult2NR -- TAG-SCGFAILUREINFORMATION-STOP -- ASN1STOP End of Changes MeasResultFreqList OPTIONAL, measResultSCG-Failure OCTET STRING (CONTAINING MeasResultSCG-Failure) OPTIONAL
4. MeasResult2EUTRA-r16 contains carrier frequency and measurement result list for EUTRA.
5. MeasResultRLFNR-r16 contains measurement result for cell results, rsIndex results and critical extensions.

• TDoc R2-2303717: Technical differences include:
- The UE supports QCI1 indication in Radio Link Failure Report and has a DRB for which QCI is 1: include the drb-EstablishedWithQCI-1
- Set the connectionFailureType to rlf
- Set the c-RNTI to the C-RNTI used in the PCell
- Set the rlf-Cause to the trigger for detecting radio link failure
- If the UE is configured with (NG)EN-DC; and if T316 is configured; and if SCG transmission is not suspended; and if the SCG is not deactivated; and if neither NR PSCell change nor NR PSCell addition is ongoing: The measurements are based on the time domain measurement resource restriction, if configured.
Example snippet from TDoc R2-2303717: "except for NB-IoT, if the UE supports QCI1 indication in Radio Link Failure Report and has a DRB for which QCI is 1: include the drb-EstablishedWithQCI-1"

• TDoc R2-2304083: Technical differences include:
- Packet loss is expected to be upper bounded by the PER (packet error rate, as defined in TS 23.501)
- The granularity for Packet loss rate measurement is per DRB per UE
- The statistical accuracy of an individual packet loss rate measurement result is dependent on how many packets have been received, and thus the time for the measurement.
Example snippet from TDoc R2-2304083: "The statistical accuracy of an individual packet loss rate measurement result is dependent on how many packets have been received, and thus the time for the measurement."

: The following bullet point list summarizes technical differences among the TDocs:

[TDoc R2-2302653]:
- Proposal to introduce a new measurement of packet loss rate in Rel-17 for TS 38.314
- The numerator of the measurement for DL packet loss rate formula defined in TS 38.314 doesn't contain successfully transmitted but delayed packets
- This is only suitable for QoS Flows with non-GBR resource type and GBR resource type, but not suitable for QoS Flows with delay-critical GBR resource type
- L2 measurements can represent the performance of the network and corresponding optimization of layer 2 can be made
- Reasonable to restrict the discussion scope only in Layer 2 measurement
- No Uu, NG, Xn interface signalling involved
- Statistical accuracy of an individual packet loss rate measurement result is dependent on how many packets have been received and the time for the measurement

[TDoc R2-2303696]:
- Current procedure does not have NB-IoT UEs report availability of the RLF report to the network
- Network may request NB-IoT UE to report the RLF report without explicit indication in the UEInformationRequest-NB by configuring rlf-ReportReq
- NB-IoT UEs do not report the availability of the RLF report to the network
- UE reports the location information in any subsequent measurement report including RLF report and SCGFailureInformationNR if obtainLocation is configured at the UE.

3GPP-R2-121-bis-e    Agenda Item 6.10.1 : General and Stage 2 corrections

• TDoc R2-2302684:
- RX UE can send assistance information to TX UE to determine SL DRX configuration for RX UE.
- TX UE determines SL DRX configuration for RX UE in RRC_IDLE/RRC_INACTIVE/OOC or in RRC_CONNECTED and using mode 2 resource allocation, regardless of whether assistance information is provided or not.
- RX UE can report received SL DRX configuration to serving gNB when using mode 1 resource allocation in RRC_CONNECTED.
- TX UE selects resources taking into account active time of RX UE(s) configured with SL DRX.

• TDoc R2-2303213:
- UE reports each destination L2 ID and associated SL DRX on/off indication to gNB supporting SL DRX when in RRC_CONNECTED and using mode 1 resource allocation for groupcast.
- RX UE maintains a single SL DRX cycle and single SL on-duration for each destination L2 ID when multiple QoS profiles are configured for that L2 ID for groupcast and broadcast.
- TX UE restarts its timer corresponding to the SL inactivity timer for the destination L2 ID upon reception of new data with the same destination L2 ID for groupcast.
- RX UE selects the largest SL inactivity timer value if multiple SL inactivity timer values associated with different QoS profiles are configured for that L2 ID for groupcast.

• TDoc R2-2303383:
- UE reports each destination L2 ID and associated SL DRX on/off indication to gNB supporting SL DRX when in RRC_CONNECTED and using mode 1 resource allocation for groupcast.
- TX UE restarts its timer corresponding to the SL inactivity timer for the destination L2 ID upon reception of new data with the same destination L2 ID for groupcast.
- TX UE selects resources taking into account active time of RX UE(s) determined by timers maintained at the TX UE when data is available for transmission to one or more RX UE(s) configured with SL DRX for groupcast.
- RX UE maintains a single SL DRX cycle and single SL on-duration for each destination L2 ID when multiple QoS profiles are configured for that L2 ID for groupcast and broadcast.

Examples:
- TDoc R2-2302684: "Regardless of whether assistance information is provided or not, the TX UE in RRC_IDLE/RRC_INACTIVE/OOC, or in RRC_CONNECTED and using mode 2 resource allocation, determines the SL DRX Configuration for the RX UE."
- TDoc R2-2303213: "For groupcast, the RX UE maintains a single SL DRX cycle (selected as the smallest SL DRX cycle of any QoS profile of that L2 ID) and single SL on-duration (selected as the largest SL on-duration of any QoS profile of that L2 ID) for each destination L2 ID when multiple QoS profiles are configured for that L2 ID."
- TDoc R2-2303383: "When data is available for transmission to one or more RX UE(s) configured with SL DRX, the TX UE selects resources taking into account the active time of the RX UE(s) determined by the timers maintained at the TX UE."

- The TDoc R2-2302839 supports two schemes of inter-UE coordination: IUC scheme 1 and IUC scheme 2.
- In IUC scheme 1, the IUC information sent from one UE to another UE can be either preferred or non-preferred resources for the sending UE's transmission.
- In IUC scheme 2, the IUC information sent from one UE to another UE is the presence of expected/potential resource conflict on the resources indicated by the sending UE's SCI. The receiving UE uses these resources as the set of non-preferred resources or excludes them to determine a set of preferred resources.
- The resources for (re)selection of both UEs can be based on both their sensing results (if available) and the IUC information, or only on the IUC information.
- For IUC information transmission triggered by a condition other than an explicit request, the preferred resource set is transmitted in unicast manner and the non-preferred resource set is transmitted in unicast, groupcast, or broadcast manner.

Example snippet from TDoc R2-2302839: "UE's resources for resource (re)selection can be based on both UE's sensing results (if available) and the IUC information, or it can be based only on IUC information."

- In TDoc R2-2302840, only IUC scheme 1 is supported.
- The transmission of IUC information from one UE to another UE can be triggered either by an explicit request or by a condition at the sending UE.
- The sending UE determines the set of resources reserved by other UEs or slots where it does not expect to perform SL reception from the receiving UE due to half-duplex operation.
- The resources for (re)selection of the receiving UE can be based on both its sensing results (if available) and the IUC information received from the sending UE or only on the IUC information.
- For scheme 1, MAC CE and second-stage SCI or MAC CE only can be used to send IUC information.

Example snippet from TDoc R2-2302840: "The resources for resource (re)selection of the receiving UE can be based on both UE-B's sensing results (if available) and the IUC information received from UE-A, or it can be based only on IUC information received from UE-A."

3GPP-R2-121-bis-e    Agenda Item 6.10.2 : Control plane corrections

1. TDoc R2-2302617: SL-CBR-PriorityTxConfigList information element

- This information element indicates the mapping between PSSCH transmission parameter sets by using the indexes of the configurations provided in sl-CBR-PSSCH-TxConfigList, CBR ranges by an index to the entry of the CBR range configuration in sl-CBR-RangeConfigList, and priority ranges.
- The SEQUENCE (SIZE (1..8)) OF SL-PriorityTxConfigIndex-r16 is used to define the priority list.
- The TAG-SL-CBR-PRIORITYTXCONFIGLIST-START and TAG-SL-CBR-PRIORITYTXCONFIGLIST-STOP are used to mark the start and end of this information element.

2. TDoc R2-2302683: SL-MinMaxMCS-Config-r16

- This information element defines the minimum and maximum MCS values for PSSCH transmission.
- It uses the SEQUENCE {sl-MCS-Table-r16 ENUMERATED {qam64, qam256, qam64LowSE}, sl-MinMCS-PSSCH-r16 INTEGER (0..27), sl-MaxMCS-PSSCH-r16 INTEGER (0..31)} to define the MCS table.
- SL-BetaOffsets-r16 is used to define beta offsets.
- This information element is used in UECapabilityInformationSidelink, uuMessageTransferSidelink-r17, UuMessageTransferSidelink-r17, and remoteUEInformationSidelink-r17.

3. TDoc R2-2303908: SL-CBR-CommonTxConfigList information element

- This information element is used to configure the common transmission parameters for CBR services.
- It uses the SEQUENCE {sl-CBR-RangeConfigList-r16 SEQUENCE (SIZE (1..maxCBR-Config-r16)), SL-CBR-PriorityTxConfigList-r16, SL-CBR-r16, sl-TxParameters-r16, SL-PSSCH-TxParameters-r16} to define the configuration parameters.
- The TAG-SL-CBR-COMMONTXCONFIGLIST-START and TAG-SL-CBR-COMMONTXCONFIGLIST-STOP are used to mark the start and end of this information element.
- SL-CBR-RangeConfigList-r16 is used to define the CBR range configuration.

Example snippets from TDoc R2-2302617:

- "The IE SL-CBR-PriorityTxConfigList indicates the mapping between PSSCH transmission parameter (such as MCS, PRB number, retransmission number, CR limit) sets..."
- "The SEQUENCE (SIZE (1..8)) OF SL-PriorityTxConfigIndex-r16 is used to define the priority list."
- "The TAG-SL-CBR-PRIORITYTXCONFIGLIST-START and TAG-SL-CBR-PRIORITYTXCONFIGLIST-STOP are used to mark the start and end of this information element."

Example snippets from TDoc R2-2302683:

- "This information element defines the minimum and maximum MCS values for PSSCH transmission."
- "It uses the SEQUENCE {sl-MCS-Table-r16 ENUMERATED {qam64, qam256, qam64LowSE}, sl-MinMCS-PSSCH-r16 INTEGER (0..27), sl-MaxMCS-PSSCH-r16 INTEGER (0..31)} to define the MCS table."
- "SL-BetaOffsets-r16 is used to define beta offsets."

Example snippets from TDoc R2-2303908:

- "This information element is used to configure the common transmission parameters for CBR services."
- "It uses the SEQUENCE {sl-CBR-RangeConfigList-r16 SEQUENCE (SIZE (1..maxCBR-Config-r16)), SL-CBR-PriorityTxConfigList-r16, SL-CBR-r16, sl-TxParameters-r16, SL-PSSCH-TxParameters-r16} to define the configuration parameters."
- "The TAG-SL-CBR-COMMONTXCONFIGLIST-START and TAG-SL-CBR-COMMONTXCONFIGLIST-STOP are used to mark the start and end of this information element."

• The three TDocs all relate to the DRX-ConfigSL information element used for configuring additional DRX parameters for UE performing sidelink operation with resource allocation mode 1, as specified in TS 38.321.
• The ASN1START and ASN1STOP tags are the same in all three TDocs.
• The SEQUENCE for DRX-ConfigSL-r17 is the same in all three TDocs.
• The ENUMERATED values for drx-RetransmissionTimerSL-r17 are the same in all three TDocs.
• TDoc R2-2303907 specifies the DRX-ConfigSL IE as part of Sidelink information elements, while TDocs R2-2303926 and R2-2303927 specify it as part of Radio resource control information elements.
• TDoc R2-2303907 includes additional text about the end and start of the change in April 2023, which is not present in the other two TDocs.
• TDoc R2-2303926 includes a reference to #121bis-e, while TDoc R2-2303927 includes a reference to 3GPP TSG-RAN WG2 Meeting [3].

Examples from TDoc R2-2303907:
- "6.3.5 Sidelink information elements...- DRX-ConfigSL"
- "The IE DRX-ConfigSL is used to configure additional DRX parameters for the UE performing sidelink operation with resource allocation mode 1, as specified in TS 38.321"

Examples from TDoc R2-2303926:
- "6.3.2 Radio resource control information elements...- DRX-ConfigSL"
- "The IE DRX-ConfigSL is used to configure additional DRX parameters for the UE performing sidelink operation with resource allocation mode 1, as specified in TS 38.321"
- "#121bis-e R2-2303926 Electronic, 17th April – 26th April 2023"

Examples from TDoc R2-2303927:
- "6.3.2 Radio resource control information elements...- DRX-ConfigSL"
- "The IE DRX-ConfigSL is used to configure additional DRX parameters for the UE performing sidelink operation with resource allocation mode 1, as specified in TS 38.321"
- "#121bis-e R2-2303927 Electronic, 17th April – 26th April 2023"
- "3GPP TSG-RAN WG2 Meeting [3]"

1. Sidelink Communication:

- When UE is in-coverage for sidelink operation according to clause 8.2, it may perform NR sidelink communication according to SIB12.
- When UE is out-of-coverage for sidelink, it may perform NR sidelink communication according to SL-V2X-PreconfigurationNR or according to SIB12 of the cell on the frequency which provides inter-carrier NR sidelink configuration.
- For NR sidelink broadcast and groupcast, the UE may obtain SL DRX configuration from SIB12 (for in-coverage UE in RRC_IDLE and RRC_INACTIVE state) or SL-PreconfigurationNR (for UE out-of-coverage).

2. Inter-UE Coordination Information:

- The UE may obtain inter-UE coordination (IUC) information configuration from SIB12 (for in-coverage UE in RRC_IDLE and RRC_INACTIVE state) or SL-PreconfigurationNR (for UE out-of-coverage).

3. Default CBR Parameters:

- RAN2 continued a discussion on whether the case was valid when default CBR parameters are applied to normal pool when full sensing result is used and available.
- There was a 50-50 split of opinions in regard to whether the case was valid or not.
- RAN1 does not see any major difference in behavior by adding the parameters for default CBR with adding parameters for partial and random resource selection pool.
- This TDoc handles the matter of whether “case 3” is valid or not in respect to the usage of default CBR for partial and random resource selection.

4. SL Grant without PDCCH:

- For SL configured grant type-1, there is no associated PDCCH and therefore no corresponding BWP for the UE to derive the numerology of the timers.
- The UE may derive the length of drx-HARQ-RTT-TimerSL/drx-RetransmissionTimerSL based on the active DL BWP of the PCell also for SL grants other than SL configured grant type-1.

Example snippets from the TDoc:

1. Sidelink Communication:

- "For NR sidelink broadcast and groupcast, the UE may obtain SL DRX configuration from SIB12 (for in-coverage UE, as defined in clause 8.2, in RRC_IDLE and RRC_INACTIVE state) or SL-PreconfigurationNR (for UE out-of-coverage)." [TDoc R2-2302686]
- "For inter-UE coordination (IUC) information configuration, the UE may obtain it from SIB12 (for in-coverage UE, as defined in clause 8.2, in RRC_IDLE and RRC_INACTIVE state) or SL-PreconfigurationNR (for UE out-of-coverage)." [TDoc R2-2302686]

2. Default CBR Parameters:

- "However, the chair made a quick vote to see companies’ opinion on the applicable cases: In, RAN2 continued a discussion on whether the case was valid when default CBR parameters are applied to normal pool when full sensing result is used and available, with a 50-50 split of opinions in regard to whether the case was valid (i.e. CBR measurement is not available although full sensing result is available) or not (i.e. default CBR parameters are not used when full sensing result is available)." [TDoc R2-2302795]
- "Observation 2: RAN1 does not see any major difference in behaviour by adding the parameters for default CBR with adding parameters for partial and random resource selection pool." [TDoc R2-2302795]
- "This Tdoc handles the (R1-2302174) on the matter of whether “case 3” is valid or not in respect to the usage of default CBR for partial and random resource selection." [TDoc R2-2302795]

3. SL Grant without PDCCH:

- "For SL configured grant type-1, there is no associated PDCCH and therefore no corresponding BWP for the UE to derive the numerology of the timers." [TDoc R2-2303925]
- "Proposal 2: RAN2 to discuss whether the UE derives the length of drx-HARQ-RTT-TimerSL/drx-RetransmissionTimerSL based on the active DL BWP of the PCell also for SL grants other than SL configured grant type-1." [TDoc R2-2303925]

3GPP-R2-121-bis-e    Agenda Item 6.10.3 : User plane corrections

Technical Differences between TDoc R2-2302618 and TDoc R2-2302619:

1. TDoc R2-2302619 has an additional NOTE indicating that the resources for transmission should follow the specifications in clause 8.1.4 of TS 38.214.
Example from TDoc R2-2302619: "randomly select the time and frequency resources for one transmission opportunity from the resources indicated by the physical layer as specified in clause 8.1.4 of TS 38.214 and are specified in clause 8.1.4 of TS 38.214 NOTE"

2. TDoc R2-2302618 and TDoc R2-2302619 both have a condition for selecting the sl-defaultTxConfigIndex or CBR measurement results.
Example from TDoc R2-2302618 and TDoc R2-2302619: "if CBR measurement results are available or the corresponding sl-defaultTxConfigIndex configured by RRC if CBR measurement results are not available"

3. TDoc R2-2302618 and TDoc R2-2302619 both have a condition for selecting resources when sl-InterUE-CoordinationScheme1 is not configured by RRC.
Example from TDoc R2-2302618 and TDoc R2-2302619: "if sl-InterUE-CoordinationScheme1 enabling reception/transmission of preferred resource set and non-preferred resource set is not configured by RRC"

4. TDoc R2-2302618 and TDoc R2-2302619 both have a condition for selecting resources when transmission is based on random selection by upper layers.
Example from TDoc R2-2302618 and TDoc R2-2302619: "if transmission based on random selection is configured by upper layers:"

5. TDoc R2-2302618 and TDoc R2-2302619 both have a condition for randomly selecting time and frequency resources based on the amount of selected frequency resources, remaining PDB of SL data available, and the latency requirement of the triggered SL CSI reporting.
Example from TDoc R2-2302618 and TDoc R2-2302619: "randomly select the time and frequency resources for one transmission opportunity from the resources pool which occur within the SL DRX Active time if configured as specified in clause 5.28.2 of the destination UE selected for indicating to the physical layer the SL DRX Active time above, according to the amount of selected frequency resources and the remaining PDB of SL data available in the logical channel(s) allowed on the carrier, and the latency requirement of the triggered SL CSI reporting."

• TDocs R2-2302647, R2-2303215, R2-2303744, and R2-2303745 are all related to Sidelink (SL) communication in 5G wireless networks.

• The main technical difference among these TDocs is related to the way time and frequency resources are selected for SL communication.

• TDocs R2-2302647 and R2-2303215 specify that time and frequency resources are randomly selected for one transmission opportunity from the resources pool that occurs within the SL DRX Active time if configured, according to the amount of selected frequency resources and the remaining PDB of SL data available in the logical channel(s) allowed on the carrier. However, R2-2302647 specifies that time and frequency resources are selected based on the resources indicated by the physical layer, while R2-2303215 specifies that they are selected from the resources pool.

• TDocs R2-2303744 and R2-2303745 specify that time and frequency resources are randomly selected from the resources later than the resources for either the removed resource or the dropped resource indicated by a prior SCI, from the resource indicated by the physical layer, which occur within the SL DRX active time. However, R2-2303744 specifies that time and frequency resources are selected according to the amount of selected frequency resources, the selected number of HARQ retransmissions, and the remaining PDB of either SL data available in the logical channel(s), while R2-2303745 excludes this last requirement.

• The bullet points below highlight some of the example snippets from the original TDocs that support the differences mentioned above:

- TDoc R2-2302647: "randomly select the time and frequency resources for one transmission opportunity from the resources indicated by the physical layer" vs. "randomly select the time and frequency resources for one transmission opportunity from the resources pool"
- TDoc R2-2303215: "according to the amount of selected frequency resources and the remaining PDB of SL data available in the logical channel(s)" vs. "according to the amount of selected frequency resources, the selected number of HARQ retransmissions, and the remaining PDB of either SL data available in the logical channel(s)"
- TDoc R2-2303744: "by ensuring the minimum time gap between any two selected resources of the selected sidelink grant in case that PSFCH is configured for this pool of resources" vs. "excluding..."
- TDoc R2-2303745: "excluding..."

Technical differences between TDoc R2-2302685 and TDoc R2-2302908:

1. TDoc R2-2302685 deals with Sidelink (SL) communications, while TDoc R2-2302908 deals with uplink (UL) and downlink (DL) communications.
- Example from TDoc R2-2302685: "if the corresponding Sidelink process was not successfully decoded"
- Example from TDoc R2-2302908: "if a MAC PDU is transmitted in a configured uplink grant"

2. TDoc R2-2302685 involves starting timers for retransmission, while TDoc R2-2302908 involves setting timers related to RTT (round trip time).
- Example from TDoc R2-2302685: "start the sl-drx-RetransmissionTimer/sl-DRX-GC-RetransmissionTimer"
- Example from TDoc R2-2302908: "set HARQ-RTT-TimerUL-NTN for the corresponding HARQ process equal to drx-HARQ-RTT-TimerUL plus the latest available UE-gNB RTT value"

3. TDoc R2-2302685 deals with groupcast transmissions, while TDoc R2-2302908 deals with HARQ (hybrid automatic repeat request) modes.
- Example from TDoc R2-2302685: "if the SCI indicates a new transmission where the cast type is set to groupcast"
- Example from TDoc R2-2302908: "if the corresponding HARQ process is configured as HARQModeA"

4. TDoc R2-2302685 involves starting timers based on the availability of resources, while TDoc R2-2302908 involves starting timers based on the end of a transmission.
- Example from TDoc R2-2302685: "start the sl-drx-HARQ-RTT-Timer for the corresponding Sidelink process in the slot following the end of PSSCH transmission"
- Example from TDoc R2-2302908: "start the HARQ-RTT-TimerUL-NTN for the corresponding HARQ process in the first symbol after the end of the last transmission (within a bundle) of the corresponding PUSCH transmission"

Example from TDoc R2-2302908: "stop the drx-RetransmissionTimerUL for the corresponding HARQ process" is not directly related to any of the differences mentioned above.

3GPP-R2-121-bis-e    Agenda Item 6.11 : RACH indication and partitioning

3GPP-R2-121-bis-e    Agenda Item 7.1.1 : Organizational

1. TDoc R2-2302414 discusses the RRC and MAC CE parameters for NCR in Rel-18.
- "RRC parameters and MAC CE parameters attached are agreed based on the RAN1’s progress on side control information indication."
- "Discussion on the detailed signalling structure can be considered in RAN2."

2. TDoc R2-2302414 provides information on upcoming TSG WG1 meetings.
- "TSG WG#1 RAN1#112-bis-e 17th – 26th Apr 2023 Online"
- "TSG WG#1 RAN1#113 22th – 26th May 2023 Incheon, KR."
- "ACTION: RAN1 kindly asks RAN2 to take the attached RRC and MAC CE parameter into account."

3. TDoc R2-2302789 modifies section abbreviations in TR 21.905 for the present document.
- "For the purposes of the present document, the abbreviations given in TR 21.905 Modified section 4.2.2 General parameters."
- "An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1] and the following apply."

Example snippets:
- "RRC parameters and MAC CE parameters attached are agreed based on the RAN1’s progress on side control information indication." (TDoc R2-2302414)
- "Discussion on the detailed signalling structure can be considered in RAN2." (TDoc R2-2302414)
- "TSG WG#1 RAN1#112-bis-e 17th – 26th Apr 2023 Online" (TDoc R2-2302414)
- "TSG WG#1 RAN1#113 22th – 26th May 2023 Incheon, KR." (TDoc R2-2302414)
- "An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1] and the following apply." (TDoc R2-2302789)

TDoc R2-2303445:

- The first snippet describes the beam failure recovery (BFR) procedure for a serving cell when a PDCCH with an uplink grant for a new transmission is received.
- If the PDCCH contains BFR information for a specific BFD-RS (beam failure detection reference signal) set of the serving cell, the BFI_COUNTER of that set is set to 0 and all triggered BFRs for that set are cancelled.
- If the serving cell is an SCell (secondary cell), and it is deactivated, the BFI_COUNTER of all BFD-RS sets of the SCell is set to 0, and all triggered BFRs for all sets of the serving cell are cancelled.
- The serving cell can only have two BFD-RS sets if failureDetectionSet1 and failureDetectionSet2 are configured for the active DL BWP of the serving cell.

TDoc R2-2303446:

- This TDoc summarizes MAC impact and related proposals for NCR (New Radio Carrier) work.
- Proposal 1 confirms the use of the one-octet eLCID space for new NCR MAC CEs, as per TDoc R2-2303445.
- Proposal 2 suggests the use of a new dedicated RNTI value, NCR-RNTI, for NCR-MT (New Radio Carrier-Message Type) operation for sending side control information.
- The rapporteur acknowledges that the new NCR MAC CEs are more complex than the NCR AC Link Beam Indication MAC CE and cannot be uniquely identified by the L-field in the MAC sub-header.

TDoc R2-2303901:

- This TDoc outlines the cell reselection criteria for a UE performing slice-based cell reselection.
- If the highest ranked or best cell in a frequency does not support the NSAG (Network Slice Assistance Information Group) derived according to clause 5.2.4.5, but supports other NSAGs according to this clause, the UE re-derives a reselection priority for the frequency based on the supported NSAG(s) of that cell.
- If the cell does not support any NSAG according to clause 5.2.4.5 or any other NSAG, the UE re-derives a reselection priority for the frequency as if none of the NSAG(s) provided by NAS is supported.
- The UE only performs cell reselection evaluation for NR frequencies and inter-RAT frequencies that are given in system information and have a provided priority.
- TreselectionNR specifies the timer value for cell reselection for NR.

Example snippets from TDoc R2-2303445:

- "if a PDCCH addressed to C-RNTI indicating uplink grant for a new transmission is received for the HARQ process used for the transmission of the Enhanced BFR MAC CE or Truncated Enhanced BFR MAC CE which contains beam failure recovery information of this BFD-RS set of the Serving Cell"
- "set BFI_COUNTER of the BFD-RS set to 0"
- "consider the Beam Failure Recovery procedure successfully completed for this BFD-RS set and cancel all the triggered BFRs of this BFD-RS set of the Serving Cell"
- "if the Serving Cell is SCell and the SCell is deactivated as specified in clause 5.9"
- "set BFI_COUNTER of each BFD-RS set of SCell to 0"
- "consider the Beam Failure Recovery procedure successfully completed and cancel all the triggered BFRs of all BFD-RS sets of the Serving Cell"
- "The Serving Cell is configured with two BFD-RS sets if and only if failureDetectionSet1 and failureDetectionSet2 are configured for the active DL BWP of the Serving Cell."

Example snippets from TDoc R2-2303446:

- "This tdoc captures several outstanding issues to do with MAC impact of NCR work"
- "RAN2 confirms that the one-octet eLCID space should be used for the new NCR MAC CEs, as per R2-2303445"
- "RAN2 confirms that the name to be used for a new dedicated RNTI value for NCR-MT operation (for sending of side control information) is NCR-RNTI (subject to any alignment with RAN1)."
- "These MAC CEs are admittedly more complex than the NCR AC Link Beam Indication MAC CE, and in rapporteur’s understanding, relying solely on L-field in the MAC sub-header for these MAC CEs would not resolve to a unique MAC CE layout."

Example snippets from TDoc R2-2303901:

- "For a UE performing slice-based cell reselection"
- "if the highest ranked cell or best cell in a frequency fulfils the inter- freqeuency cell reselection criteria (see clause 5.2.4.5) based on reselection priority for the frequency and NSAG derived according to this clause or fulfils intra-frequency and equal priority inter-frequency cell reselection criteria (see clause 5.2.4.6), but this cell does not support the NSAG according to this clause"
- "if this cell supports any other NSAG(s) according to this clause, the UE shall re-derive a reselection priority for the frequency by considering the NSAG(s) supported by this cell (rather than those of the corresponding NR frequency);"
- "Otherwise, the UE shall re-derive a reselection priority for the frequency as if none of the NSAG(s) provided by NAS is supported."
- "The UE shall only perform cell reselection evaluation for NR frequencies and inter-RAT frequencies that are given in system information and for which the UE has a priority provided."
- "TreselectionNR This specifies the cell reselection timer value TreselectionRAT for NR."

1. Maximum number of supported configurations for PUCCH cell switching: The TDoc R2-2303289 defines the maximum number of supported configurations of primary PUCCH group and secondary PUCCH group config. The maxCBR-Config-r16 INTEGER is defined as 8, which means the maximum number of CBR range configurations for sidelink communication congestion control is 8. The maxCBR-Config-1-r16 INTEGER is defined as 7, which means the maximum number of CBR range configurations for sidelink communication congestion control minus 1.

2. Maximum number of PUCCH Resources per PUCCH-ResourceSet: The maxNrofPUCCH-P0-PerSet INTEGER is defined as 8, which means the maximum number of P0-pucch present in a p0-pucch set is 8.

3. Maximum number of RSs used as pathloss reference for PUCCH power control: The maxNrofPUCCH-PathlossReferenceRSs INTEGER is defined as 4, which means the maximum number of RSs used as pathloss reference for PUCCH power control is 4.

4. Maximum number of services which the UE can include in the MBS interest indication: The maxNrofMBS-Session-r17 INTEGER is defined as 1024, which means the maximum number of services which the UE can include in the MBS interest indication is 1024.

5. Maximum number of cells supporting the NSAG: The maxNrofTRS-ResourceSets-r17 INTEGER is defined as 64, which means the maximum number of cells supporting the NSAG is 64.

6. Direct Path: The TDoc R2-2304113 defines Direct Path as a type of UE-to-Network transmission path, where data is transmitted between a UE and the network without sidelink relaying.

7. AS functionality enabling ProSe non-Relay Discovery and ProSe UE-to-Network Relay discovery: The TDoc R2-2303289 defines AS functionality enabling ProSe non-Relay Discovery and ProSe UE-to-Network Relay discovery for Proximity based Services as defined in TS 23.304 [48] between two or more nearby UEs, using NR technology but not traversing any network node.

8. IAB-MT: The TDoc R2-2303289 defines IAB-MT as an IAB-node function that terminates the Uu interface to the parent node using the procedures and behaviours specified for UEs unless stated otherwise.

9. Indirect Path: The TDoc R2-2304113 defines Indirect Path as a type of UE-to-Network transmission path, where data is forwarded via a U2N Relay UE between a U2N Remote UE and the network.

10. Uu Relay RLC channel: The TDoc R2-2303289 defines Uu Relay RLC channel as an RLC channel between L2 U2N Relay UE and gNB, which is used to transport packets over Uu for L2 UE-to-Network Relay.

11. gNB: The TDoc R2-2303289 defines gNB as a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC.

Example snippets from the original TDoc:

- "maxCBR-Config-r16 INTEGER ::= 8" (TDoc R2-2303289)
- "maxNrofPUCCH-P0-PerSet INTEGER ::= 8" (TDoc R2-2303289)
- "maxNrofPUCCH-PathlossReferenceRSs INTEGER ::= 4" (TDoc R2-2303289)
- "maxNrofMBS-Session-r17 INTEGER ::= 1024" (TDoc R2-2303289)
- "maxNrofTRS-ResourceSets-r17 INTEGER ::= 64" (TDoc R2-2303289)
- "Direct Path: a type of UE-to-Network transmission path, where data is transmitted between a UE and the network without sidelink relaying." (TDoc R2-2304113)
- "AS functionality enabling ProSe non-Relay Discovery and ProSe UE-to-Network Relay discovery for Proximity based Services as defined in TS 23.304 [48] between two or more nearby UEs, using NR technology but not traversing any network node." (TDoc R2-2303289)
- "IAB-MT: IAB-node function that terminates the Uu interface to the parent node using the procedures and behaviours specified for UEs unless stated otherwise." (TDoc R2-2303289)
- "Indirect Path: a type of UE-to-Network transmission path, where data is forwarded via a U2N Relay UE between a U2N Remote UE and the network." (TDoc R2-2304113)
- "Uu Relay RLC channel: an RLC channel between L2 U2N Relay UE and gNB, which is used to transport packets over Uu for L2 UE-to-Network Relay." (TDoc R2-2303289)
- "gNB: node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC." (TDoc R2-2303289)

3GPP-R2-121-bis-e    Agenda Item 7.1.2 : Signalling for side control information

The technical differences among the TDoc can be summarized as follows:

1. Control of NCR behaviour in IDLE mode: TDoc R2-2303237 proposes that the gNB should be able to control the NCR behaviour in IDLE mode by configuring side control information in RRC CONNECTED mode or RRC release message. This would ensure that the NCR does not go out of control when it enters IDLE mode.

Example snippet from TDoc R2-2303237: "Proposal 1: gNB can control NCR behaviour in IDLE mode by configure side control information in RRC CONNECTED mode or RRC release message."

2. Validity time duration of side control information: TDoc R2-2303237 also proposes that a valid timer should be used to control the validity time duration of side control information for NCR in IDLE mode. This would ensure that the NCR does not use outdated side control information when it resumes operation.

Example snippet from TDoc R2-2303237: "Proposal 2: A valid timer is used to control the validity time duration of side control information for NCR in IDLE mode."

3. Wake-up timer for NCR-MT: TDoc R2-2303237 proposes that a timer should be used to wake up the NCR-MT from IDLE mode and trigger it to establish RRC connection with the gNB. This would ensure that the NCR-MT does not remain in IDLE mode indefinitely and can resume operation when needed.

Example snippet from TDoc R2-2303237: "Proposal 3: A timer is used to wake up NCR-MT from IDLE mode and trigger NCR-MT to establish RRC connection with gNB."

4. Resumption of NCR-MT after cell reselection: TDoc R2-2302927 highlights the need for the NCR-MT to resume operation after cell reselection so that it can receive side-control configuration from the new gNB. This can be done through network configuration using existing specifications.

Example snippet from TDoc R2-2302927: "After cell reselection, the NCR-MT to resume so that it can receive side-control configuration from the new gNB (can be done by network configuration using existing specifications)."

3GPP-R2-121-bis-e    Agenda Item 7.1.3 : Other RAN2 aspects

NCR-MT treats certain cell settings as if they were set to allowed, including cellBarred, cellReservedForOperatorUse, cellReservedForFutureUse, and intraFreqReselection (NOTE x).

It is unclear whether CRC bits for scheduling PDSCH carrying side control information are scrambled by C-RNTI or ncr-RNTI (Proposal 1).

The field specifying allowed/forbidden cells is only applicable to RedCap UEs and is indicated in MIB message (Proposal 1).

New IOT (capability) bits are introduced for non-supported features by NCR-MT (Summary).

NCR-MT may resume forwarding when released to RRC_IDLE with a wake-up timer provided by gNB. However, there is no specification for ensuring backhaul link quality or NCR-MT behavior when the timer is running (TDoc R2-2302947).

NCR-specific q-RxLevMinNCR is defined, and Qrxlevmin for NCR-MT cell selection criterion S is obtained from it (TDoc R2-2303264).

For NCR-MT in IDLE, autonomous RRC connection establishment is needed when it selects an acceptable cell or when no cell is found (TDoc R2-2303276).

NCR-Fwd is OFF when RLF is declared, and NCR can wait for new configuration from the network to resume forwarding (TDoc R2-2303291).

NCR-Fwd needs to use the same beam as gNB for backhaul link to ensure consistency (TDoc R2-2303387).

When releasing NCR-MT to RRC_INACTIVE state, NW decides which configuration is suitable for NCR in INACTIVE state. NCR-Fwd is switched OFF if NCR-MT in RRC_INACTIVE state reselects a different cell than the last serving cell (TDoc R2-2303387).

• The state (ON/OFF) of the NCR-Fwd and how to reconnect to the network when the NCR-MT is in idle state are open issues.

Example: "According to the above agreements, the state (ON/OFF) of the NCR-Fwd and how to reconnect to the network when the NCR-MT is in idle state are open issues."

• When the NCR-MT enters into the RRC_IDLE while the NCR-Fwd is on, the NCR can fall back to the legacy RF repeater to ensure network coverage.

Example: "In addition, when the NCR-MT enters into the RRC_IDLE while the NCR-Fwd is on, the NCR can fall back to the legacy RF repeater to ensure network coverage."

• The behaviour of NCR-Fwd when the NCR-MT is in RRC_IDLE still needs to be determined.

Example: "However, the behaviour of NCR-Fwd when the NCR-MT is in RRC_IDLE still needs to be determined."

• In the definition of T3512, we see that the timer is normally stopped when the UE enters state 5GMM-DEREGISTERED or 5GMM-CONNECTED mode, which means the T3512 may still be running when the UE previously camping on the acceptable cell goes back to the suitable cell.

Example: "In the definition of T3512, we see that the timer is normally stopped when the UE enters state 5GMM-DEREGISTERED or 5GMM-CONNECTED mode, which means the T3512 may still be running when the UE previously camping on the acceptable cell goes back to the suitable cell."

• When NCR-MT is released to RRC_IDLE, the NCR-Fwd can be ON or OFF following the last configuration received from the gNB.

Example: "When NCR-MT is released to RRC_IDLE, the NCR-Fwd can be ON or OFF following the last configuration received from the gNB."

• The support of BFD and BFR appear as beneficial for the management of NCR.

Example: "We would like to start by highlighting that since FR2 appears to be key for NCRs, the support of BFD and BFR appear as beneficial for the management of NCR."

• The NG-RAN that requests the paging to the core network is the last node to have the NCR-MT in RRC_CONNECTED, but it may not be the same node later.

Example: "Also, the NG-RAN that requests the paging to the core network is the last node to have the NCR-MT in RRC_CONNECTED, but it may not be the same node later."

• Introducing a new signalling over the NG interface to request the core network to page the NCR-MT is not desirable, as it is complex and needs the involvement of SA and CT (which are not part of the WID).

Example: "Introducing a new signalling over the NG interface to request the core network to page the NCR-MT is not desirable, as it is complex and needs the involvement of SA and CT (which are not part of the WID)."

Technical Differences among TDocs:

1. Observation 5: Not supporting or optionally supporting RRC release with redirection in NCR has specification impacts; mandating that NCR-MT supports RRC release with redirection does not preclude a gNB from not triggering the mechanism for NCR-MT.

- This observation highlights the impact of not supporting RRC release with redirection in NCR and proposes that mandating NCR-MT to support it does not prevent a gNB from choosing not to use it.
- Example snippet from TDoc R2-2302928: "Not supporting or optionally supporting RRC release with redirection in NCR has specification impacts; mandating that NCR-MT supports RRC release with redirection does not preclude a gNB from not triggering the mechanism for NCR-MT."

2. Observation 2: RRC release with redirection is not an ideal substitute for handover since redirection is based on carrier frequency; and there are limited ways (possibly only through network slicing) that the gNB can even know which cell or carrier is preferred for NCR.

- This observation points out that RRC release with redirection is not a perfect replacement for handover due to its reliance on carrier frequency and the limited methods available to the gNB to determine the preferred cell or carrier for NCR.
- Example snippet from TDoc R2-2302928: "RRC release with redirection is not an ideal substitute for handover since redirection is based on carrier frequency; and there are limited ways (possibly only through network slicing) that the gNB can even know which cell or carrier is preferred for NCR."

3. Conclusion: Legacy paging is not enough for NCR-MT to transit from IDLE to CONNECTED mode.

- This conclusion suggests that relying solely on legacy paging is insufficient for NCR-MT to transition from IDLE to CONNECTED mode.
- Example snippet from TDoc R2-2303238: "Observation: Legacy paging is not enough for NCR-MT to transit from IDLE to CONNECTED mode."

4. Proposal 1: NCR-MT transit from IDLE to CONNECTED mode based on gNB indication e.g. configured timer that in RRC release message or gNB based paging.

- This proposal recommends using a gNB indication, such as a timer configured in an RRC release message or a paging message with NCR-MT ID, to transition NCR-MT from IDLE to CONNECTED mode.
- Example snippet from TDoc R2-2303238: "More specifically, to control the NCR-MT transit from RRC_IDLE mode to RRC_CONNECTED mode, gNB can configure a timer in RRC connection release message, which indicate after how long time NCR-MT needs to enter RRC_CONNECTED mode and receive the RRC signaling from gNB again. On the other hand, if gNB want to control NCR-MT and trigger NCR-MT to enter RRC_CONECTED mode, gNB can send a paging message with NCR-MT id. NCR-MT monitor the paging for itself and if it receive the paging message from gNB with indication to enter RRC_CONNECTED mode, NCR-MT starts to establish RRC connection with gNB."

5. If the RRCReconfiguration message was received as part of ConditionalReconfiguration: continue using the configuration used prior to when the inability to comply with the RRCReconfiguration message was detected.

- This statement specifies the action to be taken if the RRCReconfiguration message was received as part of ConditionalReconfiguration.
- Example snippet from TDoc R2-2304004: "3> if the RRCReconfiguration message was received as part of ConditionalReconfiguration: 4> continue using the configuration used prior to when the inability to comply with the RRCReconfiguration message was detected."

6. The compliance also covers the SCG configuration carried within octet strings e.g. field mrdc-SecondaryCellGroupConfig.

- This statement clarifies that compliance also covers the SCG configuration carried within octet strings, such as the field mrdc-SecondaryCellGroupConfig.
- Example snippet from TDoc R2-2304004: "NOTE 0a: The compliance also covers the SCG configuration carried within octet strings e.g. field mrdc-SecondaryCellGroupConfig."

7. If sdt-MAC-PHY-CG-Config is configured: configure the PCell with the configured grant resources for SDT and instruct the MAC entity to start the cg-SDT-TimeAlignmentTimer.

- This statement provides instructions for configuring the PCell with the grant resources for SDT and starting the cg-SDT-TimeAlignmentTimer if sdt-MAC-PHY-CG-Config is configured.
- Example snippet from TDoc R2-2304015: "3> if sdt-MAC-PHY-CG-Config is configured: 4> configure the PCell with the configured grant resources for SDT and instruct the MAC entity to start the cg-SDT-TimeAlignmentTimer."

8. The Network should provide full configuration to UE for SRS for Positioning in RRC_INACTIVE.

- This statement recommends that the network provide full configuration to UE for SRS for Positioning in RRC_INACTIVE.
- Example snippet from TDoc R2-2304015: "NOTE 1b: The Network should provide full configuration to UE for SRS for Positioning in RRC_INACTIVE."

9. Remove all the entries within the MCG and the SCG VarConditionalReconfig, if any.

- This statement instructs to remove all the entries within the MCG and the SCG VarConditionalReconfig, if any.
- Example snippet from TDoc R2-2304015: "2> remove all the entries within the MCG and the SCG VarConditionalReconfig, if any."

10. If the associated measObjectId is only associated to a UE Inactive AS Context, except for the fields explicitly specified. No specification impact.

- This statement specifies that there is no specification impact if the associated measObjectId is only associated to a UE Inactive AS Context, except for the explicitly specified fields.
- Example snippet from TDoc R2-2304015: "3> if the associated measObjectId is only associated to a UE Inactive AS Context, except for the fields explicitly specified. No specification impact."

Technical Differences:

1. The RRC forwarding configuration used by the NCR-FWD after the NCR-MT enters RRC_INACTIVE:
- In TDoc R2-2302893, it is observed that the backhaul beam for the forwarding is not indicated.
- Additionally, the NCR-MT cannot receive dynamic indication of the backhaul beam for the NCR-FWD while in RRC_INACTIVE.

Example snippet from TDoc R2-2302893: "The RRC forwarding configuration used by the NCR-FWD after the NCR-MT enters RRC_INACTIVE does not indicate the backhaul beam for the forwarding."

2. Resuming connection in case of beam reselection:
- In proposal 2 from TDoc R2-2302893, it is suggested that the NCR-MT in RRC_INACTIVE state should resume connection to receive updated side control configuration if it reselects a new beam of the same camped cell.

Example snippet from TDoc R2-2302893: "The NCR-MT in RRC_INACTIVE resumes connection to receive updated side control configuration if it reselects a new beam of the same camped cell."

3. Wake-up timer maintenance:
- In TDoc R2-2302944, option 2 suggests that when RRC of the NCR-MT receives RRCRelease message with wake-up timer, RRC of the NCR-MT forwards the timer value to NAS of the NCR-MT and the timer is maintained by NAS of the NCR-MT.
- Possible option 1 is also mentioned, which involves RRC of NCR-MT sending a notification to NAS of NCR-MT at the expiry of the wake-up timer.

Example snippet from TDoc R2-2302944: "When RRC of the NCR-MT receives RRCRelease message with wake-up timer, RRC of the NCR-MT forwards the timer value to NAS of the NCR-MT and the timer is maintained by NAS of the NCR-MT."

3GPP-R2-121-bis-e    Agenda Item 7.2.1 : Organizational

Technical differences among the TDocs:

- TDoc R2-2302409: Addresses the lack of support in current RAN1 specifications for simultaneous measurements/transmissions for multiple UEs, including a target UE and a PRU. RAN1 will continue discussions on necessary enhancements to support simultaneous measurements/transmissions.
- TDoc R2-2302446: Discusses the support of low power and/or high accuracy positioning in the study phase of release 18 eLCS_Ph3 work item. SA2 asks RAN1, RAN2, and SA1 about the scope and requirements of this aspect.
- TDoc R2-2302448: Identifies use cases where multiple target UEs are involved in the same positioning session and asks RAN2 about the support of multiple target UEs and signalling of positioning results for them in the Ranging/SL Positioning Protocol.
- TDoc R2-2302449: Agrees on procedure enhancements for PRU support and asks RAN1 and RAN2 about required enhancements and the possibility of PRU providing its location information together with location measurements reports.

Example snippets from the TDocs:

- In TDoc R2-2302409, RAN1 requests for enhancements to LPP, NRPPa, and/or RAN signaling to support simultaneous measurements/transmissions for multiple UEs, including a target UE and a PRU.
- TDoc R2-2302446 highlights the study phase of release 18 eLCS_Ph3 work item and asks RAN1, RAN2, and SA1 about the scope and requirements of the low power and/or high accuracy positioning aspect.
- TDoc R2-2302448 asks RAN2 about the support of multiple target UEs and signalling of positioning results for them in the Ranging/SL Positioning Protocol.
- TDoc R2-2302449 asks RAN1 and RAN2 about required enhancements and the possibility of PRU providing its location information together with location measurements reports.

• The proposal is to allow PRU to provide location information together with measurement reports
- "RAN2 sees the benefit to allow PRU to provide its location information together with the measurement reports" (Answer to Question 1)
- "RAN2 sees the benefit to allow PRU to provide its location information together with the measurement report" (Proposal 2)

• Current LMF can only require a device to report either a location estimate or positioning measurements
- "Currently, LMF can only require a device to report either a location estimate or positioning measurements" (TDoc R2-2303707)

• PRU UE should provide both location measurement and current location estimate using the same transaction upon NW request
- "PRU UE provides location measurement and current location estimate using the same transaction upon NW request" (TDoc R2-2303707)
- "PRU UE should provide both location measurement and current location estimate using the same transaction upon NW request" (TDoc R2-2303707)

• The stored PRU information may need to be updated
- "The stored PRU information may need to be updated" (TDoc R2-2303707)

- The TDoc specifies new core requirements and enhancements for enabling LPHAP use-case 6 in NR systems, including extending eDRX cycle beyond 10.24s in RRC_INACTIVE state towards meeting the battery life requirement for LPHAP and positioning-specific enhancement for eDRX cycle beyond 10.24s to be defined as part of Rel-18 WI on expanded and improved NR positioning.
- The TDoc also specifies solutions for support of sidelink positioning (including ranging) in NR systems, including specifying SL PRS for support of sidelink positioning and solutions for alignment between eDRX and PRS configurations.
- TDoc R2-2302738 proposes various changes to the ASN.1 part of SLPP, including following the NR RRC approach, defining ASN.1 elements for common UE capabilities in a dedicated section, having a common section for constraints, and introducing a setup release structure in SLPP.
- The RAN plenary approved the updated WID on expanded and improved NR positioning and allocated the specification number TS38.355 for new specification on Sidelink Positioning Protocol.
- Proposal 1 endorses the TS Skeleton in R2-230xxxx as the baseline for further updates.
- Proposal 2 addresses the location information provided by a PRU, specifying that a PRU should be able to report the location coordinates of the PRU only, the location measurements performed by the PRU only, or the location coordinates of the PRU together with any performed location measurements.
- Observation 3 notes that security and privacy are not impediments to distribution of SLPP Location Information to multiple target UEs within the same Ranging/SL Positioning session and proposes modifications to the SLPP Session based on capability information from a previous step.

Example snippets from the original TDoc supporting these differences include:

- "Specify enhancements for enabling LPHAP use-case 6 as defined in TS 22.104 including: Extending eDRX cycle beyond 10.24s in RRC_INACTIVE state towards meeting the battery life requirement for LPHAP [RAN2, RAN3, RAN4] Positioning-specific enhancement for eDRX cycle beyond 10.24s to be defined as part of Rel-18 WI on expanded and improved NR positioning."
- "Specify solutions for support of sidelink positioning (including ranging) in NR systems, including the following [RAN1, RAN2, RAN3, RAN4]: Specify SL PRS for support of sidelink positioning such that the SL PRS uses a comb-based (full RE mapping pattern is not precluded) frequency domain structure and a pseudorandom-based sequence where the existing sequence of DL-PRS is used as a starting point [RAN1]."
- "Regarding the ASN.1 part of SLPP, follow NR RRC approach, e.g. - FFS on Need code (e.g. how to support no UL/DL), support of delta signalling - Define ASN.1 elements for common UE capabilities in a dedicated section (i.e. “UE capability information elements”); FFS whether any positioning method specific capability IEs should be grouped by positioning method. - Common section for constraints - “nonCriticalExtension” at message level - Fields in the field description are sorted based on alphabetical order - FFS on whether setup release structure should be introduced in SLPP."
- "At RAN#99, RAN plenary approved the updated WID on expanded and improved NR positioning [7] and allocated the specification number TS38.355 for new specification on Sidelink Positioning Protocol as: In this contribution, we continue the discussion on the structure of TS38.355."
- "Proposal 1: Endorse the TS Skeleton in R2-230xxxx as baseline for further updates."
- "Regarding the 2nd SA2 question on 'Location information provided by a PRU', RAN2 to reply the following: 'A PRU should be able to report (a) the location coordinates of the PRU only, (b) the location measurements performed by the PRU only, or (c) the location coordinates of the PRU together with any performed location measurements, where location measurements above include the currently defined location measurements in LPP and potential new location measurements defined in Rel-18 and location coordinates provide the known location of the PRU, obtained independently from the location measurements.'"
- "Observation 3: Security and privacy are not impediments to distribution of SLPP Location Information to multiple target UEs within the same Ranging/SL Positioning session, including over unicast, groupcast or broadcast. RAN2’s current agreements already support request and distribution of Capability and Assistance data to multiple target UEs within the same Ranging/SL Positioning session, with that request and distribution supported over unicast, groupcast or broadcast for both UE-assisted and UE-based sidelink ranging and positioning."

3GPP-R2-121-bis-e    Agenda Item 7.2.3 : RAT-dependent integrity

Technical Differences Among TDocs:

1. Implementation of Measurement Error Sources Bound Distribution
- Proposal to leave the acquisition of measurement error sources bound distribution to implementation or algorithm of LMF
- TRP related error sources are already known to LMF due to implementation
- No additional spec impacts to support LMF-based integrity from RAN perspective
- Any interaction between LMF and NG-RAN to support determination of error sources is in RAN3 scope

2. Granularity of Integrity Information
- Two options considered: UE to report integrity information directly or LMF to handle all error sources based on implementation
- DNU flag designed to ensure network provides usability of related GNSS signal and integrity service alerts
- Slightly prefer solution where UE reports own estimation of integrity information along with measurement information

3. RAT-Dependent Integrity Assistance Information
- RAT-dependent positioning methods involve UE, NG-RAN node, and LMF entity
- UE and network entity may perform integrity information collection and transmit to LMF or UE in timely manner
- Integrity alert output performed for both UE-based and LMF-based integrity modes

4. Signalling Procedures for LMF-Based Positioning Integrity
- LPP provide location information message used for UE reporting results related to integrity to LMF
- NRPPa message used for RAN to send results related to integrity to LMF
- UE and gNB provide error sources for different positioning methods

5. Error Source Association
- Rx-Tx time difference measurements should be associated with one set of error distribution parameters
- All RSTD measurements within a TRP should be associated with one set of error distribution parameters

Example Snippets from TDocs:

- "It is proposed to leave the acquisition of the measurement error sources bound distribution to implementation or algorithm of LMF, i.e., up to implementation or algorithm, LMF generate the measurement error sources bound distribution based on the measurement results reported by UE and/or NG-RAN in normal positioning procedure." (R2-2302504)
- "The DNU flag is designed to ensure that, for the current epoch, the network should provide the usability of the related GNSS signal (i.e. GNSS-RealTimeIntegrity, to provide a bad GNSS signal list) and integrity service alerts in terms of ionosphere or troposphere related information (i.e. ionosphereDoNotUse, TroposphereDoNotUse)." (R2-2302959)
- "Contrary to GNSS positioning integrity where UE is equipped with GNSS receiver and only UE and LMF transfer the integrity information, RAT-dependent positioning methods involve UE, NG-RAN node and LMF entity, and each entity may generate error sources or feared events which affect the integrity performances." (R2-2303230)
- "It is suggested that the UE could send the measurement error generated from UE, e.g. RSTD measurement, UE Rx-Tx time difference measurement, to LMF via LPP ProvideLocationInformation message while NG-RAN could send the error in assistant data and measurement generated from NG-RAN node, e.g. TRP location, RTOA measurement, inter-TRP synchronization, gNB." (R2-2303540)
- "For LMF-based integrity, LMF needs to know the error bounds of UE-side measurement error for calculating integrity results. If latter is applied, all RSTD measurements containing in a same measurement report (i.e., a same NR-DL-TDOA-ProvideLocationInformation LPP message) should be associated with one set of error distribution parameters." (R2-2303495)

TDoc R2-2302581:

- The SEQUENCE includes milli-arc-second-units-r16, height-units-r16, delta-latitude-r16, delta-longitude-r16, delta-height-r16, and locationUNC-r16.
- milli-arc-second-units-r16 and height-units-r16 are ENUMERATED types.
- Delta-Latitude-r16 is a SEQUENCE that includes delta-Latitude-r16 and coarse-delta-Latitude-r16.
- Delta-Longitude-r16 is OF NR-DL-AoD-AdditionalMeasurementElement-r16.
- NR-DL-AoD-AdditionalMeasurementsExt-r17 is a SEQUENCE with a size range of 1 to maxAddMeasAoD-r17.

Example snippet: "height-units-r16 ENUMERATED {mm, cm, m, ...}"

TDoc R2-2303705:

- Error sources for LMF-based and UE-based positioning integrity modes are listed in Table 6.1.1-1.
- Identified candidates for distributions to model the errors due to different error sources are listed in Table 6.1.1-2.
- The RAT dependent positioning error sources are categorized.

Example snippet: "Table 6.1.1-1: Error sources for LMF-based and UE-based positioning integrity modes"

Technical differences among the TDocs:

1. TDoc R2-2303571 proposes modifications to the LPP and NRPPa protocols to deliver error sources related information for positioning integrity calculation estimation between UE, network, and LMF. For UE-based integrity, two types of error sources, including TRP location and inter-TRP synchronization, will be provided to UE via assistance data from LMF. For RAT-dependent positioning integrity, the Rel-17 standard will define the positioning integrity capabilities, including error source receiving, error source reporting, and positioning integrity result reporting.

2. TDoc R2-2303682 proposes optional provision of "Integrity Correlation Times" for the integrity assistance data in NR to allow the use of time-based estimation techniques in addition to snapshot-based techniques. The document also proposes providing Integrity Alert IEs in the Assistance Data for any bound that is still valid to satisfy the condition in Equation 8.x.2-1. The document further states that Integrity Bounds provide the statistical distribution of the errors.

3. TDoc R2-2303994 proposes studying which parameters in assistance data should be applied for DNU flags, and whether the UE and gNB need to provide additional measurements related to measurement error sources for LMF-based integrity of DL and UL positioning. The document also proposes reusing the integrity related IE and fields defined for GNSS integrity for RAT-dependent positioning integrity where possible, e.g., mean and standard deviation as bounds for an error source.

4. TDoc R2-2304058 proposes that the UE should provide integrity bounds for measurement errors in LMF-based mode for all measurements reported, and the LMF should be configured with integrity bounds for errors for these measurements. The document also proposes RAN2 to discuss and identify the residual risks specific and applicable to RAT-dependent positioning integrity and evaluate their impacts.

Example snippets from the original TDocs to support the difference highlighting:

- TDoc R2-2303571: "Thus, in order to obtain positioning integrity calculation estimation, error sources related information needs to be delivered between UE, network and LMF as shown in the table 1, which will modify the LPP and NRPPa protocols."
- TDoc R2-2303682: "The 'Integrity Correlation Times', defining the minimum time interval beyond which two sets of assistance data parameters for a given error can be considered to be independent from one another, should optionally be provided for the integrity assistance data for NR to allow the use of time-based estimation techniques (e.g. Kalman Filtering) in addition to snapshot-based techniques."
- TDoc R2-2303994: "Proposal 1: Study which parameters in assistance data should be applied for DNU flags. Proposal 2: Study whether there’s a need for the UE to provide additional measurements (e.g., statistical information about measurements) to the LMF related to measurement error sources for LMF-based integrity of DL positioning. Proposal 3: Study whether there’s a need for the gNB to provide additional measurements (e.g., statistical information about measurements) to the LMF related to measurement error sources for LMF-based integrity of UL positioning."
- TDoc R2-2304058: "For all measurements that are reported in the LMF-based mode (e.g. RSTD, UE Rx-Tx TD, DL-PRS RSRPP of the first path or RSRP of additional paths), where UE reports the measurement and LMF estimates the position and integrity results, the UE needs to provide the integrity bounds (for measurement errors) to the LMF or the LMF must be configured with integrity bounds for errors for these measurements."

3GPP-R2-121-bis-e    Agenda Item 7.2.4 : LPHAP

Technical differences among the TDocs:

1. Approach for delivering DRX configuration to UE:
- Option1, PCCH-Config in SIB1 for both RRC_IDLE and RRC_INACTIVE
- Option2, PCCH-Config in RRCRelease message for RRC_INACTIVE
- Option3, NAS message for both RRC_IDLE and RRC_INACTIVE received when the UE is in RRC_CONNECTED

2. Mapping of SRS configuration to downlink reference signal:
- Proposal 3: A SRS configuration shall be mapped to a downlink reference signal
- UE could be configured to monitor certain downlink resources (occasional DL-PRS)

3. Reporting of DL-PRS measurements in RRC_IDLE state:
- Proposal 8: RAN2 to send LS to SA2, to inform them that RAN has agreed to support “DL PRS measurements for a UE in RRC_IDLE state and reporting of the measurements in RRC_CONNECTED state”
- Proposal 3: RAN2 to agree that the DL-PRS configuration to be applied in the RRC_Idle state could be valid in a large area, i.e., list of cells, to keep the continuity of the positioning service in the RRC_Idle state.

4. Determination of UL timing for SRS transmission:
- Option 1: UE maintains the TA obtained from the last serving cell within the validity area
- Option 2: UE autonomously adjusts the TA

5. Communication of positioning results to the network:
- Hence, regardless of whether UE-based or network-based positioning is used, in the end the result needs to be communicated to the network, which requires the UE to be connected.

Example snippets from the original TDocs:

- "When multiple DRX cycles are configured with the options above, the UE should choose the shortest cycle to monitor paging such that the UE does not miss any paging occasion, either from the gNB or from the LMF."
- "For the UL timing advance, further study the following options, including the DL reference timing for each option: Option 1: UE maintains the TA obtained from the last serving cell within the validity area Option 2: UE autonomously adjusts the TA"
- "Proposal 2: When UE moves out of the cell which configures the SRS with the validity area for the UE, the SRS transmission from the UE will lead to inference to other UE in serving cell, and the inference should be avoid."
- "Proposal 3: A SRS configuration shall be mapped to a downlink reference signal, the measurement on the DL reference signal indicates to the UE whether some other UE in the network is currently using the uplink SRS configuration or not."
- "Observation 1: TS 22.104 use-case 6 “tracking of workpiece in assembly area” and usage of DL positioning are likely to require the UE to be in RRC_CONNECTED, therefore only C-DRX needs to be considered for PRS alignment (according to TS 22.104)."
- "Proposal 8: RAN2 to send LS to SA2, to inform them that RAN has agreed to support “DL PRS measurements for a UE in RRC_IDLE state and reporting of the measurements in RRC_CONNECTED state” and would like to check whether the CN can handle the measurement reports from the UE in RRC_CONNECTED, while the positioning was performed in RRC_IDLE for MO-LR, MT-LR and NI-LR."

TDoc R2-2303494:

- PTW-enabled UE should request multiple PRS periodicity values for alignment of paging cycle inside and outside PTW.
- UE monitors CN paging or RAN paging based on minimum paging cycle value and paging location parameter in RRC SIB.

TDoc R2-2303570:

- RAN1 progress needed for validation of SRS transmission with interference, timing advance, and spatial relation information.
- Option 1 is more power efficient and less complex to avoid SRS configuration update or activation/deactivation procedure during UE movement within validity area.

TDoc R2-2303704:

- Exposure of LPHAP information to gNB and/or LMF can be discussed in normative work for any agreed enhancement of LPHAP.
- UE continues SRS transmission during reselection to another cell within SRS validity area, subject to validation.

TDoc R2-2303886:

- LMF needs to request multiple TRP sets to measure SRS from target UE even if UE can transmit SRS toward only one set of TRPs.
- Proposal 1: Discuss possibility of configuring different spatial relation information/pathloss reference for each cell within validity area for SRS configuration.

Example snippets:

- "...the UE should request more than 1 PRS periodicity values in a on-demand PRS request for the alignment of paging cycle inside the PTW and outside the PTW, respectively."
- "UE monitors CN paging or RAN paging according to the minimum paging cycle value...and the paging location parameter in the RRC SIB."
- "Option 1 is more power efficient and less complex."
- "UE continues the SRS transmission, subject to validation for SRS transmission."
- "...configuring different spatial relation information/pathloss reference in the SRS configuration can be configured differently for each cell within validity area..."

Technical Differences:

1. RRC SRS Activation message: The receiving gNB may send an RRC SRS Activation message to the UE, which includes the ID of the preconfigured SRS to be activated, along with the pathloss reference, spatial relation, the TA timer, and RSRP-change-threshold. This is highlighted in section 5 of TDoc R2-2303697.

2. DL-PRS measurements in RRC_IDLE state: Proposal 11 suggests performing DL-PRS measurements for a UE in RRC_IDLE state and reporting the measurements in RRC_CONNECTED state using existing signaling. A new NG-RAN triggered NRPPa procedure may also be possible, but it may not provide CN DRX information for idle mode to the LMF. The UE may set the dl-prs-ResourceSetPeriodicityReq based on the configured LCS reporting activity and (e)DRX configuration. This is mentioned in both sections 5 and 6 of TDoc R2-2303697.

3. (e)DRX/PRS alignment optimization: Based on the knowledge of the UE's (e)DRX configuration, the LMF can optimize the PRS configuration of the UE so that the PRS measurement (or SRS transmission) can be aligned with the already configured (e)DRX active time. This can reduce power consumption of the UE for PRS measurement or SRS transmission when it wakes up from sleep. This is discussed in TDoc R2-2304059.

4. Impact of UE mobility on (e)DRX configuration: UE mobility necessitates changes to (e)DRX configuration if the DRX configuration is aligned for a given/fixed PRS configuration, and this may impact the (e)DRX performance of other UEs. This observation is also mentioned in TDoc R2-2304059.

Example Snippets:

1. Section 5 of TDoc R2-2303697: "The receiving gNB may then send an RRC SRS Activation message to the UE which includes the ID of the preconfigured SRS to be activated, and possibly the pathloss reference, spatial relation, the TA timer and RSRP-change-threshold."

2. Section 6 of TDoc R2-2303697: "Performing DL-PRS measurements (or any other positioning measurements) for a UE in RRC_IDLE state and reporting of the measurements in RRC_CONNECTED state can already be supported with existing signaling."

3. TDoc R2-2304059: "Based on the knowledge of the UE's (e)DRX configuration, the LMF can optimize the PRS configuration of the UE so that the PRS measurement (or SRS transmission) can be aligned with the already configured (e)DRX active time, which can reduce power consumption of the UE for PRS measurement or SRS transmission when it wakes up from sleep."

4. TDoc R2-2304059: "UE mobility necessitates changes to (e)DRX configuration if the DRX configuration is aligned for a given/fixed PRS configuration, and this may impact the (e)DRX performance of other UEs."

1. SRS configuration validation in RRC_INACTIVE/RRC_IDLE UEs:
- UE continues SRS transmission when reselecting to another cell within SRS validity area during SRS transmission
- RSRP threshold and TAT value for SRS introduced for time alignment validation
- TA-related issue to be solved for Rel-18 SRS configuration enhancements
- Proposal to support broadcast of SRS configuration
(TDoc R2-2303539)

2. DL-PRS configuration:
- Two directions of solutions for DRX/PRS alignments based on "PRS alignment with fixed DRX" or "DRX alignment with fixed PRS"
- Three directions of solutions according to TR 38.859
(TDoc R2-2303985)

3. Positioning in RRC_IDLE state:
- PRS measurement in RRC_IDLE recommended for normative work
(TDoc R2-2303985)

4. Power consumption issues with frequent RRC state transitions to RRC_CONNECTED for SRS configurations:
- Observation made during study phase
- LPP supports assistanceDataValidityArea for PRS validation across multiple cells in R17
(TDoc R2-2303985)

3GPP-R2-121-bis-e    Agenda Item 7.2.5 : RedCap positioning, carrier phase positioning, and bandwidth aggregation for positioning

1. Postponement of positioning discussion for Bandwidth aggregation until progress in RAN1 is made. (TDoc R2-2302743)

Example: "Postpone the discussion on positioning for Bandwidth aggregation until there is reasonable progress in RAN1."

2. Potential RAN2 impact is to capture RAN1 parameters and feature lists, including enhancements to LPP, NRPPa, and/or RAN signaling for simultaneous measurements and transmissions. (TDoc R2-2302743, R2-2302818)

Examples: "Potential RAN2 impact is to capture RAN1 parameters, feature lists and may introduce new RAT dependent positioning method and corresponding measurements, procedure." "Regarding the support of PRU, SA2 asked questions in [3], e.g. Whether additional enhancement would be needed to support the simultaneous measurements for the target UE and PRU."

3. Awareness of RedCap UE capability at the LMF for supporting different positioning methods and aspects of a particular positioning method. (TDoc R2-2302818)

Example: "In the current specification, the capabilities in an LPP context refer to supporting of different positioning methods defined for LPP, different aspects of a particular positioning method (e.g. different types of assistance data for A-GNSS) and common features not specific to only positioning method (e.g. ability to handle multiple LPP transactions)."

4. Signaling designs for positioning of RedCap UEs, bandwidth aggregation, and carrier phase-based positioning. (TDoc R2-2303996)

Example: "Signalling designs for positioning of RedCap UEs, bandwidth aggregation and carrier phase-based positioning are needed to support the aforementioned functionalities."

5. SRS configuration for positioning in RRC_CONNECTED mode and potential enhancement for joint measurement and report for PRS resources aggregated across different PFLs. (TDoc R2-2303887)

Examples: "Regarding the SRS configuration for positioning, the UE is allowed to transmit SRS within the active UL BWP of a CC in RRC_CONNECTED mode in release 16." "RAN2 to discuss potential enhancement on provide/request location information in LPP to support the joint measurement and report for the PRS resources aggregated across different PFLs."

6. Details related to signaling of frequency hopping for PRS or SRS for positioning and clarification of reporting needed for carrier phase measurement. (TDoc R2-2303996)

Examples: "In addition, SRS hopping will be supported using mechanism different than BWP switching since the current specification supports only up to 4 BWPs which is not enough to cover 100MHz, which is the baseline bandwidth to yield satisfactory performance for positioning, assuming each BWP is 20MHz." "Although a definition for carrier phase measurement was agreed, details related to reporting needs more clarification."

Proposal 2:
- Supports on-demand PRS configuration with group information for PRS bandwidth aggregation
- UE can request on-demand PRS configuration ID(s) or group ID(s)
- UE can request PRS bandwidth larger than that of a single PFL implying PRS bandwidth aggregation request
- Example snippet: "The UE may request PRS configuration IDs or group IDs for PRS bandwidth aggregation."

Proposal 3:
- Supports LMF-initiated on-demand PRS request for PRS bandwidth aggregation
- LMF can request PRS bandwidth larger than that of a single PFL implying PRS bandwidth aggregation request
- Sends an LS to RAN3
- Example snippet: "The LMF may initiate on-demand PRS request for PRS bandwidth aggregation."

Proposal 4:
- Supports SRS bandwidth aggregation across carriers
- Higher layer signaling to indicate which carriers are linked
- SRS resources for positioning between linked carriers are one-to-one mapping
- Example snippet: "Higher layer signaling is required to indicate which carriers are linked, where the SRS resources for positioning between the linked carriers are one-to-one mapping."

[TDoc R2-2303706]:
- Discusses signaling of UE capability and mechanism to indicate DL-PRS that can be aggregated together in AD message in bandwidth aggregation for positioning
- Supports partially overlapped DL PRS frequency hopping and partially overlapped UL SRS frequency hopping for DL-TDOA, UL-TDOA and multi-RTT for RedCap UEs
- New or extended signaling needed to configure UL SRS configuration between LMF and UE, LMF and gNB, and between UE and gNB
- Supports reporting DL-PRS carrier phase and/or DL-PRS carrier phase difference with DL-TDOA positioning method
- No explicit frequency support for NB-IoT, but narrowband PRS can be separately configured on multiple NB-IoT carriers, resulting in artificial frequency hopping
- Example snippet: "To achieve these target positioning requirements for RedCap UEs, the recommended solutions from the corresponding SI in Rel-18 are partially overlapped DL PRS frequency hopping and partially overlapped UL SRS frequency hopping for DL-TDOA, UL-TDOA and multi-RTT."

3GPP-R2-121-bis-e    Agenda Item 7.3.1 : Organizational

3GPP-R2-121-bis-e    Agenda Item 7.3.2 : DTX/DRX mechanism

-TDoc R2-2302763: Observation 1 proposes that restricting UE from monitoring PDCCH for dynamic grants/assignments for new transmissions during Cell DTX non-active period has no impact on network energy saving and only brings marginal UE power saving gain.

-TDoc R2-2302796: Proposal 5 suggests that cell level common L1 signalling for Cell DTX/DRX activation/deactivation is beneficial from RAN2 perspective. However, detailed comments indicate that this discussion is premature and further decisions are first needed on gNB and UE behaviour during cell DTX/DRX and gNB state definitions.

-TDoc R2-2302835: The document proposes that multiple DTX/DRX configurations require a configuration list in RRC that doesn’t greatly increase specification work. It also proposes that on-duration of each UE’ C-DRX should fall within Cell DTX active period, and Cell DTX non-active period should fall within the common part of C-DRX non-active period among UE.

-TDoc R2-2302914: Observation 4 suggests that configuring Cell DTX without UE CDRX is bad for UE power as it forces all UEs into being ON (decoding PDCCH) for longer than they need. The document also notes that L1 switching is an implementation challenge.

-TDoc R2-2303152: Observation 5 proposes that to achieve a tradeoff between UE power saving and latency, the active duration of UE CDRX can be extended in some cases.

-TDoc R2-2303369: Observation 4 suggests that if new transmission is to be considered in non-active period of Cell DTX, the UE in the cell can be configured with UE-specific Cell DTX inactivity timer.

-TDoc R2-2303604: The document discusses the expected gNB and UE behaviours during Cell DRX and Cell DTX non-active periods, and suggests that achieving additional UE energy savings through Cell DTX would be favourable.

Overall, the TDocs highlight various technical differences and proposals related to Cell DTX/DRX configuration, UE CDRX, PDCCH monitoring for dynamic grants/assignments, and gNB and UE behaviour during non-active periods. The proposals suggest potential solutions to achieve a tradeoff between network and UE energy savings, while also ensuring sufficient transmission and reception capabilities.

Technical Differences among TDoc:

1. Cell DTX/DRX Configuration-related Issues:

- In Option 1, the gNB sends a dynamic indication to inform UE about the activation of cell DTX/DRX, and all UEs update the DRX parameters such as DRX cycle, drx-startoffset, or drx-slotoffset to a common start offset.

- In Option 2, the gNB pre-configures a UE DRX periodicity that is a multiple of the serving Cell’s DTX periodicity along with the cell DTX configuration.

- The alignment of UE DRX can be done along with L1 activation and deactivation of cell DTX/DRX.

- The UE does not expect to monitor PDCCH, but it is allowed to initiate UL transmission according to the configured resources during the UE DRX off period.

Example: "Option 2: The gNB pre-configures a UE DRX periodicity that is multiple of the serving Cell’s DTX periodicity along with the cell DTX configuration."

2. Single or Multiple Configurations:

- Multiple cell DTX/DRX configurations can enable the gNB to dynamically adjust cell DTX/DRX pattern.

Example: "Some companies suggest multiple cell DTX/DRX configurations can enable the gNB to dynamically adjust cell DTX/DRX pattern."

3. UE Active Time during Cell DTX Configuration:

- UE active time should be the moment that is overlapped within the Cell DTX on duration time.

- There is no need to introduce Cell DTX/DRX inactivity timer, similar to UE DRX inactivity timer mechanism in cell DTX/DRX configuration.

Example: "Proposal 2: When the Cell DTX is configured, the UE active time will be the time that is overlapped with the Cell DTX active period."

4. PDCCH Monitoring:

- Scheduling a DG-PUSCH can be a mechanism for the NW to override Cell DRX without the need for full-on reconfiguration.

- Restricting the periodicity of UE C-DRX configurations to be the same or a multiple of the serving Cell's DTX periodicity could negatively impact UE QoE by leaving the UE with few C-DRX on-duration occasions.

Example: "Observation 6: Restricting the periodicity of UE C-DRX configurations to be the same or a multiple of the serving Cell's DTX periodicity could negatively impact UE QoE by leaving the UE with few C-DRX on-duration occasions."

Technical Differences between TDoc R2-2302797 and R2-2303827:

1. UE Behaviour Change During Cell DTX Non-Active Period: TDoc R2-2302797 proposes that during the cell DTX non-active period, the UE should change its behaviour and proactively stop receiving/monitoring signals/channels that the gNB will not transmit to save power. The UE transitions to C-DRX sleep (stops PDCCH monitoring) during this period. Fig.1 shows an example of this behaviour change. In contrast, TDoc R2-2303827 does not propose any behaviour change during the cell DTX non-active period.

Example from TDoc R2-2302797: " Fig.1 UE C-DRX behaviour change according to the Cell DTX"

2. Exceptional Scheduling During Non-Active Time of Cell DTX/DRX: TDoc R2-2303827 proposes that exceptional scheduling in non-active time of Cell DTX/DRX may be allowed to a specific UE when the current DRX retransmission timer is running. This means that scheduling may be allowed for a specific UE (whose DRX retransmission timer is running) in non-active time of Cell DTX/DRX until the corresponding transmission is completed. In contrast, TDoc R2-2302797 does not propose any exceptional scheduling during the non-active time of Cell DTX/DRX.

Example from TDoc R2-2303827: "Proposal 3: Exceptional scheduling in non-active time of Cell DTX/DRX may be allowed to a specific UE when the current DRX retransmission timer is running."

3. Alignment Between UE C-DRX and Cell DTX/DRX: TDoc R2-2302797 proposes that the alignment between UE C-DRX and cell DTX/DRX is necessary and beneficial for power consumption and transmission reliability reasons. The existing UE C-DRX behaviour does not change during the Cell DTX active period. In contrast, TDoc R2-2303827 proposes that the alignment between Cell DTX and UE C-DRX may need not mean that the on-duration of UE C-DRX falls within the Cell DTX active period.

Example from TDoc R2-2302797: "Consequentially, the alignment between UE C-DRX and cell DTX/DRX is necessary and beneficial for power consumption and transmission reliability reasons."

Example from TDoc R2-2303827: "That is, the alignment between Cell DTX and UE C-DRX may need not mean that the on-duration of UE C-DRX falls within the Cell DTX active period."

4. Support for Exceptional Scheduling: TDoc R2-2303827 proposes that exceptional scheduling in non-active time of Cell DTX/DRX should be support optionally by network configuration. In contrast, TDoc R2-2302797 does not discuss support for exceptional scheduling.

Example from TDoc R2-2303827: "Also, the exceptional scheduling in non-active time of Cell DTX/DRX should be support optionally by network configuration."

• The Cell DTX/DRX configuration from gNB to UE would contain at least periodicity, start slot/offset, and on duration of the Cell DTX pattern.
• UEs may fail to decode L1 signals or are newly attached to the cell which may cause cell DTX/DRX status miss-match problem.
• There will be no impact to RACH, paging, and SIBs in idle/inactive for both gNB and Rel-18 and legacy UEs
• Rel-18 NES capable CONNECTED UE(s) can perform RACH and receive SIBs in non-active duration of cell DTX and/or DRX.
• Rel-18 UE does not transmit on UL channels during Cell DTX non-active period.
• The down selection for extension of cell DTX based on following options: Option 1.1: Yes, the notification of cell DTX active duration to other UEs is needed; Option 1.2: Yes, the notification of cell DTX active duration to other UEs is not needed; Option 2: If no, the pattern of cell DTX is up to the semi-static configuration and the mechanism of cell DTX is simple, but the flexibility is lost.
• UE shall send HARQ feedback for SPS, monitor possible retransmissions for SPS/CG and monitor responses for SR as well even if during non-active period.
• UE doesn’t monitor PDCCH for dynamic grants/assignments for new transmissions during Cell DTX non-active period, even if the UE is in C-DRX Active time.
• No reconfiguration of UE DRX is needed upon Cell DTX/DRX activation/deactivation.
• The alignment of C-DRX ON occasions between different UEs affects the common start time of Cell DTX/DRX.
• A common starting point of Cell DTX/DRX pattern in both the network and the UEs side cannot be guaranteed by the baseline proposal (i.e., activated immediately once configured by RRC.).
• The start offset (i.e., drx-LongCycleStartOffset) is used for spreading the network scheduling load corresponding to different C-DRX cycle lengths.

Example snippets from the original TDoc to support the difference highlighting:

• "However, with only the above two signals, there could be cell DTX/DRX status miss-match problem for A) UEs which have failed to decode the L1 signals, and/or B) UEs which are newly attached to the cell."
• "Rel-18 NES capable CONNECTED UE(s) can perform RACH and receive SIBs in non-active duration of cell DTX and/or DRX."
• "UE shall send HARQ feedback for SPS, monitor possible retransmissions for SPS/CG and monitor responses for SR as well even if during non-active period."
• "No reconfiguration of UE DRX is needed upon Cell DTX/DRX activation/deactivation."
• "A common starting point of Cell DTX/DRX pattern in both the network and the UEs side cannot be guaranteed by the baseline proposal (i.e., activated immediately once configured by RRC.)."

3GPP-R2-121-bis-e    Agenda Item 7.3.4 : Cell selection/re-selection

• TDoc R2-2303514 discusses the ability for non-NES UEs to access NES cells if the NES solution is backwards compatible.

Example: "RAN2 confirms that non-NES UEs can access to NES cells if NES solution is backwards compatible."

• This TDoc prioritizes NES cells for NES-capable UEs when network load is high and there are many legacy UEs camping on legacy cells.

Example: "When the network load is relatively high and there are large number of legacy UEs camping on the legacy cells, it should be allowed for the NES capable UEs to consider NES frequency as high priority."

• The TDoc discusses whether NES cells should be prioritized or de-prioritized for intra-frequency cell reselection scenarios.

Example: "For the intra-frequency cell reselection scenario, i.e., NES cells and legacy cells are deployed on the same frequency, whether it should be allowed to prioritize or de-prioritize the NES cell for intra-frequency cell reselection?"

• The TDoc mentions cell barring and cell (re)selection for NES-capable UEs and legacy UEs, but notes that detailed solutions for NES haven't been established.

Example: "Considering the detail solutions for NES haven’t been clear, in this contribution, we only discuss on some high level views on the cell barring and cell (re)selection for NES capable UEs and legacy UEs."

• TDoc R2-2304070 proposes defining conditions for each technology in the cell barred and cell selection/re-selection mechanisms for UEs that only support some of the Rel-18 NES technologies.

Example: "Therefore, if a UE supports only some of the Rel-18 NES technologies as described in ii), it is necessary to define conditions for each technology in the cell barred and cell selection/re-selection mechanisms."

• The TDoc emphasizes the importance of granularity in setting UE capability and conditions to prevent legacy UEs from camping into NES cells.

Example: "Mechanisms to prevent legacy UE from camping into NES cells should be considered along with the granularity of how UE capability defines. RAN2 discuss to be sure about the granularity of setting UE capability and the granularity of setting conditions to the appropriate mechanisms to prevent legacy UE from camping into NES cells."

• The TDoc notes that the network side is expected to apply multiple NES technologies in combination and proposes setting capacities for each technology.

Example: "The network side is expected to apply and operate one or more of the NES technologies in combination. Considering the variety of devices for various applications, it is natural that capacities for NES should be set for each technology."

In summary, the TDocs discuss various technical differences related to the implementation of NES cells and their interaction with legacy UEs. These differences include considerations around cell barring, cell (re)selection, prioritization, and the granularity of UE capability and conditions. The TDocs also note the need for setting capacities for multiple NES technologies.

3GPP-R2-121-bis-e    Agenda Item 7.4.1 : Organizational

Technical Differences Among TDoc R2-2302412 and R2-2302432:

TDoc R2-2302412:
- Determines whether RAR is received from serving cell or candidate cell
- Specifies the configuration/indication of whether RAR needs to be received
- Allows UE to report support for RAR and without RAR schemes
- Requires sending LS to RAN2 and RAN3 for feasibility checking
- Definition of candidate cells is left up to RAN2

Example snippet: "As the feasibility of schemes included in the agreement above is related to the designs of RAN2 and RAN3, RAN 1 respectfully asks RAN2 and RAN3 to check the feasibility and potential impact on specs of RAN2 and RAN 3 of all options, i.e. with RAR (from serving or candidate cell) and without RAR, in this agreement."

TDoc R2-2302432:
- Discusses the relaxation of restrictions on non-serving cell SSB measurement
- Includes feedback on whether to consider RTD of serving cell and neighbour cell larger than one CP for intra-frequency L1-RSRP measurement
- Discusses the scenarios and requirements for L1-RSRP measurement for those scenarios

Example snippet: "Whether to consider RTD of serving cell and neighbour cell larger than one CP for intra-frequency L1-RSRP measurement? At least in some scenarios, the SSB for intra-frequency L1 measurement may not be covered by serving cell active BWP."

- TDoc R2-2302945 discusses how to handle unnecessary information in RAR and how to avoid potential preamble confliction.
- In case additional information is introduced, legacy RAR cannot be used, and RAN2 needs to discuss the format of the RAR and the UE behavior to receive it.
- RAN2 also needs to discuss how to maintain the TA of the candidate cell at the UE side and whether any specific handling is necessary to avoid interruption in data transmission.
- TDoc R2-2302946 analyzes the potential specs impact for Case B, which includes discussing the format of RAR and UE behavior to receive it if additional information is introduced.
- The legacy RAR can be used if additional information is not introduced.
- The preambles used for LTM in the candidate DU may be different from the serving DU in the inter-DU case.

Example snippets from TDoc R2-2302945:
- "Although RAN2 needs to discuss how to handle unnecessary information (e.g., UL grant, Temporary C-RNTI) in RAR and specify the result of the discussion, spec impact may be smaller than the former case."
- "RAN2 needs to discuss how to avoid potential preamble confliction and specify the result of the discussion."
- "RAN2 needs to discuss the format of the RAR and the UE behavior to receive the RAR if the additional information is introduced."
- "RAN2 needs to discuss whether the caused data transmission interruption at the source is acceptable or any specific handling is necessary to avoid it."

Example snippets from TDoc R2-2302946:
- "Irrespective of whether the RAR is received from the serving cell or the candidate cell, at least the following aspects needs to be discussed in RAN2 and will be potential RAN2 specs impact."
- "RAN2 needs to discuss the format of the RAR and the UE behavior to receive the RAR if the additional information is introduced."
- "The legacy RAR can be used if the additional information is not introduced."
- "For inter-DU case, the preambles used for LTM in the candidate DU may be different from the serving DU."

Technical differences between the two TDocs include:

TDoc R2-2302450:

- The focus is on the handling of sk-counter/S-KgNB in scenarios where a UE is connected to multiple Serving Networks (SNs)
- RAN2 is requesting feedback from SA3 regarding the acceptability of the existing handling of sk-counter/S-KgNB in these scenarios
- If SA3 finds the existing handling not acceptable, RAN2 is asking for requirements for a solution

Example snippet: "RAN2 would like to know whether SA3 considers the existing handling of sk-counter/ S-KgNB in the above scenarios acceptable"

TDoc R2-2302458:

- The focus is on supporting inter-DU LTM cell switch during execution in 5G networks
- RAN3 is discussing two approaches to support this, and is asking for feedback from RAN2 on which approach to use
- RAN3 is also open to suggestions for other possibilities

Example snippet: "RAN3 kindly asks RAN2 to provide the feedback on the above approaches"

Overall, TDoc R2-2302450 is focused on security considerations related to a UE being connected to multiple SNs, while TDoc R2-2302458 is focused on technical approaches for supporting inter-DU LTM cell switch.

3GPP-R2-121-bis-e    Agenda Item 7.4.2.1 : General and Stage-2

1. Candidate cells can be grouped to share the same TA value for RACH-less LTM.
- TDoc R2-2303751: "TAs of candidate cells for a UE can be grouped with multiple TAGs."

2. In RACH-based LTM execution, the UE may transmit an RA preamble indicated in the pre-configuration.
- TDoc R2-2303751: "The physical channel configurations included in the pre-configuration are not reserved for the UE and can be used for UEs served by the candidate cell or a new UE, which needs to move into the cell by mobility, until the UE executes a cell switch to the candidate cell."

3. If RAR is received from the candidate cell for intra DU cell switch, one DU needs to transmit RAR on both SpCell and the candidate cell.
- TDoc R2-2303940: "If RAR is received from the candidate cell for intra DU cell switch, this breaks the legacy rule for reception of RAR and one DU needs to transmit RAR on both SpCell and the candidate cell."

4. The serving DU can include dynamic information set by the target DU in the LTM cell switch command.
- TDoc R2-2304102: "Examples of such dynamic information about target cell to further reduce the latency are: Beam information, such as information enabling the UE to determine the TCI state(s) to be activated in the target cell during the LTM cell switch. SCell activation/deactivation state in the target."

5. The RACH configuration for the candidate cell needs to be prepared separately from the RACH configuration for the serving cell to execute early UL sync.
- TDoc R2-2304185: "Observation3: To execute early UL sync, the RACH configuration for the candidate cell needs to be prepared separately from the RACH configuration for the serving cell."

Technical Differences among TDocs:

1. Option for CU to request DU to reserve required PRACH/UL RS resources for the UE in first-RRC-Reconfiguration
- The CU can request the corresponding candidate DU to reserve required PRACH/UL RS resources for the UE.
- "which is then provided by the source DU to the UE in first-RRC-Reconfiguration"
- PDCCH ordered DCI may contain a corresponding index indicating candidate cell(s) for which the Early TA needs to be acquired.
- "Here the First-RRC-Reconfiguration contains: a list of candidate cells Random Access Preamble indices and indication of RACH occasions with the associated SSB indices for each candidate cell"

2. Pre-configuring candidates using RRC in the LTM preparation phase may not be sufficient
- "pre-configuring one or a selected few candidates using RRC in the LTM preparation phase may not be sufficient"
- RAN2 to discuss other LTM execution triggers that can be used such as RLF, HOF, BFD
- UE performs L3 measurements and reports the neighbor cells which are above a threshold.

3. Data Loss at LTM cell switch
- In option 1, for DL data transfer, the DU can check the HARQ status for each HARQ process and figure out whether the corresponding RLC SDUs/segments are successfully delivered or not at LTM cell switch.
- The opposite option is to minimize the ping-pong rates and reduce cell switch execution number as basic handover procedure by setting longer TTT or introducing additional L1-RSRP threshold for cell switch.

4. Adaptive gap configurations to reduce interruption towards source cell
- To reduce the interruption towards source cell, the gNB can perform adaptive gap configurations.
- The gNB can configure different gaps for different target cells.
- The UE may perform DL synchronization with the candidate cell during the measurement.

Example snippets from the original TDocs:

1. [TDoc R2-2303650]
- "which is then provided by the source DU to the UE in first-RRC-Reconfiguration"
- "Here the First-RRC-Reconfiguration contains: a list of candidate cells Random Access Preamble indices and indication of RACH occasions with the associated SSB indices for each candidate cell"
- "PDCCH ordered DCI may contain a corresponding index indicating candidate cell(s) for which the Early TA needs to be acquired."

2. [TDoc R2-2303709]
- "pre-configuring one or a selected few candidates using RRC in the LTM preparation phase may not be sufficient"
- "UE performs L3 measurements and reports the neighbor cells which are above a threshold."

3. [TDoc R2-2303754]
- "In option 1, for DL data transfer, the DU can check the HARQ status for each HARQ process and figure out whether the corresponding RLC SDUs/segments are successfully delivered or not at LTM cell switch."
- "The opposite option is to minimize the ping-pong rates and reduce cell switch execution number as basic handover procedure by setting longer TTT or introducing additional L1-RSRP threshold for cell switch."

4. [TDoc R2-2303869]
- "To reduce the interruption towards source cell, the gNB can perform adaptive gap configurations."
- "The gNB can configure different gaps for different target cells."
- "The UE may perform DL synchronization with the candidate cell during the measurement."

Summary of Technical Differences:

TDoc R2-2304103:

- Study of both gNB scheduled and/or UE initiated report
- Baseline for obtaining RS measurement configuration for L1 measurements from ServingCellConfigCommon of each candidate
- Configuration options for L1 measurement RS provided under ServingCellConfig for serving cells
- L1 inter-frequency measurement supported from RAN1 point of view outside CellGroupConfig for Rel-18 LTM

Example Snippet: "Option 1) Configurations for L1 measurement RS is provided under ServingCellConfig for the serving cells - is useful to reuses the mechanism for Rel-17 ICBM and necessary information to support inter-frequency measurement will be added there."

TDoc R2-2304104:

- Legacy random access involves UE transmitting preamble and expecting RAR within RAR window
- C-DU calculates TA value associated with preamble and transmits to CU, which provides to S-DU
- Approach 2 allows for possibility of C-DU response including TA value
- CU may include request for configuring LTM candidate cell and initiating time alignment acquisition procedure associated with requested LTM candidate cell(s)

Example Snippet: "Assuming that the CU is aware which LTM candidate cells are UL sync or not with the UE’s current serving cell, the CU may also include in the UE CONTEXT SETUP REQUEST to a C-DU the request for configuring an LTM candidate cell and a request for initiating a time alignment acquisition procedure associated to the requested LTM candidate cell(s)."

3GPP-R2-121-bis-e    Agenda Item 7.4.2.2 : RRC

- The LTM is intended to enable fast cell switch with low interruption, limiting the scenarios to intra-DU and intra-CU inter-DU cases only.
- UE should not apply the legacy principle for the need code or toAddModeList/toRelaseList when applying the candidate configuration upon LTM cell switch.
- L1 measurement reporting configurations for LTM should be configured within each candidate and serving cell configuration.
- The TA network adjustment factor is determined by the CU and configured to the UE through RRC LTM pre-configuration.
- The reference configuration is managed separately and cannot be one of the configured candidate cells or serving cells.
- Option 3 incorporates the L1 measurement configuration within each candidate cell configuration, and early decoding for the candidate cell RRC configuration is needed to obtain the corresponding L1 measurement configuration.
- At LTM execution, the reference and the candidate delta configuration will completely override top-level fields that can be included in the LTM candidate configuration.
- The set of candidate cell index shall be common among different groups to avoid additional signalling overhead for the need to include group index in cell switch MAC CE.
- If the candidate configuration of the target cell and the candidate configuration of the source cell belongs to the same candidate configuration set, the UE applies partial MAC reset and keeps RLC and PDCP.
- RAN2 to discuss whether multiple reference configurations can be configured in inter-DU LTM with a restriction that there is at most one per DU.
- RAN2 to agree that if the reference configuration is the source configuration, the network can send an indication to do so, instead of sending the reference configuration.
- RAN2 to modify the RRC re-establishment with LTM procedure to make use of the fact that the CU does not change in case the recovery is using a candidate LTM cell.

- The gNB-DU is responsible for preparing the CellGroupConfig and mapping between CSI report and RS configurations.
- RS configurations of all candidate cells need to be sent from gNB-CU to all gNB-DUs in order for them to update the CSI-MeasConfig as long as one new candidate cell is added or RS configuration is changed in any of the existing candidate cells.
- UE needs to decode all RRCReconfigurations (containing CellGroupConfigs) in the candidate cell configuration to obtain the full picture of RS configurations.
- The requirement of sequential cell switch needs to be understood before comparing different options of L1 measurement configuration.
- The CellGroupConfig for each candidate cell contains RS configurations of all candidate cells and mapping between the report configuration and RS configurations.
- The first option is to reuse the signaling structure of Rel-17 ICBM (see Option 1).
- LTM candidate configurations for intra-CU mobility are invalid if inter-CU handover is triggered for the UE configured with them.
- Compliance check for conditional reconfiguration can be performed upon the reception or upon CHO/CPA/CPC execution, and the gNB cannot identify which candidate configuration is invalid and may provide the same configuration.
- In the LTM procedure, the gNB decides to use LTM and initiates LTM candidate preparation by transmitting an RRCReconfiguration message to the UE.
- One RRCReconfiguration message for each candidate configuration is used for LTM candidate cell configurations.
- The method for Rel-17 Inter-cell Beam Management (ICBM) can be reused for inter-frequency measurement.
- Information of candidate cells required before LTM cell switch is provided in candidate configuration if UE is allowed to access parameters that are not in its current serving cell configurations.
- Legacy handover is a reconfigurationWithSync procedure and requires synchronization towards the target cell.
- Candidate delta configuration is applied on top of the reference configuration to form a complete candidate configuration.
- One RRCReconfiguration message for each candidate target configuration is used to configure target candidate cells.
- The candidate delta configuration is applied on top of the reference configuration to form a complete candidate configuration when the UE receives the LTM configuration (before the LTM cell switch).

Technical Differences among TDoc:

1. Alt.2 and Alt.3: In Alt.2 and Alt.3, the UE can identify whether a full Layer 2 reset is required or not based on the LTM candidate configuration ID included in the cell switch command. The UE can also perform the compliance check upon receiving the reference configuration to reduce the configuration handling delay during LTM execution. However, Alt.3 is similar to Alt.2, and it focuses on improving the RRC Resume procedure by indicating the configuration ID in RRC Resume to trigger LTM towards the current cell in Msg4.

2. Use of Reference Configuration: The use of reference configuration is limited, and it is likely that candidate configurations are similar to each other and to the original cell. However, LTM candidate configurations are still valid after resuming the connection, even if the UE has performed some cell reselection in the meantime (within a limited area). Therefore, the UE needs to indicate updates of the valid cells using uplink signaling.

3. Role of a Cell in Different LTM Events: Depending on which candidate cell is chosen as LTM target, a cell may play a role as SpCell or SCell after LTM to the candidate cell. To support different roles of a cell in different/subsequent LTM events, the reference configuration should be able to include both SpCellConfig and SCellConfig even for the same cell.

4. Case on When the Reference Configuration is the Current UE Configuration: If the reference configuration is the current UE configuration, this can be achieved by two different solutions. In one solution, the network will send a reference configuration to the UE containing a configuration that is exactly the same as the current UE configuration. In the other solution, the UE will consider a joint RLM process where it not only monitors the status of its serving cell but also the status of the configured candidate cells for LTM.

Example Snippets from the Original TDoc:

1. "In Alt. 2, the UE can also identify whether the full L2 reset is required or not, based on the LTM candidate configuration ID included in the cell switch command..."

2. "...the NW can provide full candidate configuration or delta candidate configuration based on the current UE configuration, i.e. the configuration used when receiving the RRC message."

3. "While this approach may save on downlink signaling, it requires the UE to indicate updates of the valid cells using uplink signaling."

4. "Depending on which candidate cell (cell_B) is chosen as LTM target, the cell_A may play a role as be SpCell or SCell after LTM to the candidate cell_B..."

5. "If now the case on when the reference configuration is the current UE configuration is allowed, this basically can be achieved according to two different solutions..."

- Two options for L1 measurements and reporting of a deactivated SCell that is a candidate LTM cell: Option 1: UE follows same configuration for deactivated SCell as when activated. Option 2: UE follows LTM-specific configuration for deactivated SCell.
- Option 2 may result in dynamically dependent L1 report payloads, so CSI report configuration may include pointer to both CSI-resource configuration of serving cell and L1 measurement RS configuration for SSBs of candidate LTM cell.
- Providing UE with additional LTM-specific measurement and reporting configurations of serving PCell for being a candidate LTM cell becomes redundant.
- Release of RRC configurations in UE can be decided by CU, serving DU, or target DU.
- Usage of same BWP between source and target reduces interruption time, but if BWP changes in source, target cell needs to be notified, at least for RACH-less scenarios.
- Option 1 is less flexible for configuration management than option 2.
- When one candidate configuration is updated, the associated complete candidate configuration with the same configuration ID in the UE should be updated.
- Complete candidate configuration of LTM and associated configuration ID should be stored by UE when it receives LTM candidate configuration and generates it.

Example snippets from TDoc R2-2302831:

- "Option 2 may create the issue that the payload of the L1 report may become dynamically dependent on the activation/deactivation state(s) of the one or more SCells."
- "Therefore, providing the UE with additional LTM-specific measurement and reporting configurations of the serving PCell for being a candidate LTM cell becomes redundant."
- "Therefore, the CSI report configuration associated with the report instance may include a pointer to both a CSI-resource configuration of a serving cell and the L1 measurement RS configuration for the SSBs of a candidate LTM cell."

Example snippets from TDoc R2-2303592:

- "Usage of the same BWP between the source and the target reduces the interruption time."
- "but in case the BWP changes in the source, it requires the target cell to be notified, at least for the RACH-less scenario."

Example snippets from TDoc R2-2303847:

- "Compared with option 2, option 1 is not flexible for configuration management."
- "When one candidate configuration is updated, the associated complete candidate configuration with the same configuration ID in the UE should be updated."

3GPP-R2-121-bis-e    Agenda Item 7.4.2.3 : Cell Switch