Apex Standards 3GPP Meeting Tracker

---

updated as of Sun, Apr 16, 2023, 04:47 PM UTC (1 day ago)
Sun, Apr 16, 09:47 AM California
Sun, Apr 16, 06:47 PM Berlin/Paris
Mon, Apr 17, 12:47 AM Beijing

3GPP-R3-119-bis-e    Agenda Item 3 : Approval of the Agenda

3GPP-R3-119-bis-e    Agenda Item 4 : Approval of the minutes from previous meetings

3GPP-R3-119-bis-e    Agenda Item 6 : Organizational topics

3GPP-R3-119-bis-e    Agenda Item 8.1 : New Incoming LSs

1. Upon subsequent Connection Resume in CM-IDLE with Suspend procedure as response to the paging, the AMF is expected to send an N2 Connection Resume Response or N2 Path Switch Ask to NG-RAN.
- Supporting TDoc: R3-231104

2. The SMF shall trigger a Network Triggered Service Request as the UE is considered as CM Idle when receiving subsequent DL Data report from the UPF for a PDU session of which user plane connection is suspended.
- Supporting TDoc: R3-231104

3. RAN1 has agreed to introduce 1-symbol PRS with legacy comb sizes for NR positioning and requests RAN2 and RAN3 to take this into account in their Rel-18 specification updates.
- Supporting TDoc: R3-231108

4. RAN2 suggests using PSER definition as "the PSER defines an upper bound for a rate of non-congestion related PDU Set losses" and respectfully asks SA2 to take their feedback into consideration.
- Supporting TDoc: R3-231109

5. There may be a need for updates to allow management-based trace data to be correlated for a session originating from the secondary node of a Dual Connectivity deployment or from the CUUP/DU in split RAN architecture deployments.
- Supporting TDoc: R3-231121

6. When downlink data is received and the SMF/UPF is requested to perform buffering as specified in clause 4.8.1.1a, the UPF/SMF checks with AMF for the possibility of data delivery based on the stored eDRX cycle value for RRC_INACTIVE state.
- Supporting TDoc: R3-231303

7. The NG-RAN may expose congestion information, indicate changes in guaranteed bitrate for GBR QoS Flow, and measure and expose data rate information on a per QoS Flow basis based on SMF request over NGAP.
- Supporting TDoc: R3-231452

8. RAN UE ID is available in RAN for a purpose similar to trace data correlation but does not survive inter-node HO or UE going to Idle or Inactive.
- Supporting TDoc: R3-231622

9. The RAN UE ID has been introduced in rel-15 for a purpose similar to what SA5 is now asking and exists in RAN but is limited to the split RAN architecture.
- Supporting TDoc: R3-231622

• RAN3 discussed the availability of a UE identifier for trace data correlation for dual-connectivity and split RAN architecture, and concluded that the existing 64 bits RAN UE ID can be reused to correlate traces from different RAN entities, for the same session. [TDoc R3-231623]

• RAN3 proposes to add some description to stage-2 specifications, such as TS 37.340 and TS 38.401, on how to allocate, use and transfer the RAN UE ID. [TDoc R3-231623]

• RAN3 enhanced the Cell Traffic Trace mechanism in Rel-16 to support trace for Dual Connectivity, allowing management-based trace data to be correlated for a session originating from the secondary node of a Dual Connectivity deployment or from the gNB-CU-UP and gNB-DU in split RAN architecture deployments. [TDoc R3-231632]

• UE identifiers currently defined in TS 32.423 (Rel-17) are the ones specified in Annex A1 of this specification. [TDoc R3-231632]

• To support trace for Dual Connectivity specifically, there may be a need for updates to allow management-based trace data to be correlated for a session originating from the secondary node of a Dual Connectivity deployment or from the CUUP/DU in split RAN architecture deployments. [TDoc R3-231698]

• RAN3 proposes to rely on SA5 that for management based trace initiated to gNB-CU or gNB-CU-CP, the gNB-CU or gNB-CU-CP may trigger the Cell Traffic Trace procedure on NG interface to inform AMF to send the IMSI/IMEI(SV) to the TCE for trace data correlation. [TDoc R3-231723]

• If the serving NG-RAN node for UEs selected for management-based trace is MN, the MN may trigger the Cell Traffic Trace procedure on NG interface to inform AMF to send the IMSI/IMEI(SV) to the TCE for trace data correlation. [TDoc R3-231723]

• Proposal 1: In order to meet requirement from SA5, how to use RAN UE ID should be specified in stage 3 for Management based Trace/MDT. In order to meet requirement from SA5, how to use RAN UE ID should be specified in stage 2 for Management based Trace/MDT. [TDoc R3-231698]

• Feasibility of RAN providing RAN UE ID applies to Management based Trace and MDT. [TDoc R3-231698]

In summary, RAN3 discussed the availability of a UE identifier for trace data correlation for dual-connectivity and split RAN architecture and proposed to reuse the existing 64 bits RAN UE ID for correlating traces from different RAN entities for the same session. RAN3 also proposed adding descriptions to the stage-2 specifications on how to allocate, use and transfer the RAN UE ID. Furthermore, RAN3 enhanced the Cell Traffic Trace mechanism in Rel-16 to support trace for Dual Connectivity and suggested that SA5 takes into account these enhancements. Additionally, RAN3 proposed relying on SA5 to specify how to use the RAN UE ID in stage 3 and stage 2 for Management based Trace/MDT. Finally, RAN3 proposed that it is feasible for RAN to provide RAN UE ID applies to Management based Trace and MDT.

- TDoc R3-231699 includes a message for S-NODE ADDITION REQUEST, which is sent by the M-NG-RAN node to the S-NG-RAN node to request the preparation of resources for dual connectivity operation for a specific UE.
- TDoc R3-231700 includes a modification request message, but the exact details of the modification are not specified in the snippet provided.
- TDoc R3-231699 includes a successful operation figure (8.6.3.2-1) for MeNB initiated SeNB Modification Preparation, which involves the MeNB sending a SENB MODIFICATION REQUEST message to the SeNB.

Example snippet supporting S-NODE ADDITION REQUEST:
"This message is sent by the M-NG-RAN node to the S-NG-RAN node to request the preparation of resources for dual connectivity operation for a specific UE."

Example snippet supporting successful operation figure:
"The MeNB initiates the procedure by sending the SENB MODIFICATION REQUEST message to the SeNB."

Technical Differences among TDoc R3-231835 and R3-231836:

1. On-demand PRS vs PRS Configuration:
TDoc R3-231835 discusses On-demand PRS, while TDoc R3-231836 discusses PRS Configuration.

Example from TDoc R3-231835: "9.2.65 On-demand PRS"
Example from TDoc R3-231836: "9.3.1.177 PRS Configuration"

2. Syntax Definitions:
TDoc R3-231835 includes syntax definitions for PRSResource-List and PRSResource-Item, while TDoc R3-231836 includes syntax definitions for PRSResourceSet-List and PRSResourceSet-Item.

Example from TDoc R3-231835: "PRSResource-List::= SEQUENCE (SIZE (1..maxnoofPRSresources)) OF PRSResource-Item"
Example from TDoc R3-231836: "PRSResourceSet-List ::= SEQUENCE (SIZE (1.. maxnoofPRSresourceSets)) OF PRSResourceSet-Item"

3. Parameter Definitions:
TDoc R3-231835 defines parameters such as pRSResourceID and qCLInfo, while TDoc R3-231836 defines parameters such as prsPowerLevel and prsBandwidth.

Example from TDoc R3-231835: "PRSResource-Item ::= SEQUENCE { pRSResourceID PRS-Resource-ID, qCLInfo PRSResource-QCLInfo OPTIONAL }"
Example from TDoc R3-231836: "PRS-Configuration ::= SEQUENCE { prsPowerLevel ENUMERATED { level0, level1, level2, level3, level4, level5, level6, level7 } OPTIONAL, prsBandwidth ENUMERATED { bw12, bw24, bw48, bw96, bw192, bw384, bw768 } OPTIONAL }"

4. Meeting Information:
TDoc R3-231835 is from 3GPP TSG-RAN WG3 Meeting, while TDoc R3-231836 is from 3GPP TSG-RAN WG4 E-meeting.

Example from TDoc R3-231835: "3GPP TSG-RAN WG3 Meeting"
Example from TDoc R3-231836: "3GPP TSG-RAN WG4 E-meeting"

5. Protocol Extension Container:
TDoc R3-231835 includes ProtocolExtensionContainer for PRSResource-Item-ExtIEs, while TDoc R3-231836 does not include any ProtocolExtensionContainer.

Example from TDoc R3-231835: "iE-Extensions ProtocolExtensionContainer { { PRSResource-Item-ExtIEs} } OPTIONAL"
Example from TDoc R3-231836: "No example present in the TDoc"

6. Changes in Text:
TDoc R3-231835 has some text changes related to On-demand PRS, while TDoc R3-231836 has some text changes related to PRS Configuration.

Example from TDoc R3-231835: "<<<<<<<<<<<<<<<<<<<< Changes Begin >>>>>>>>>>>>>>>>>>>>"
Example from TDoc R3-231836: "E-meeting, 17 April – 26 April, 2023 } OPTIONAL }"

3GPP-R3-119-bis-e    Agenda Item 9.1 : LTE

3GPP-R3-119-bis-e    Agenda Item 9.2.1 : SONMDT

1. TDoc R3-231546 has a direction from NG-RAN node 1 to NG-RAN node 2, while TDoc R3-231547 has the same direction.
- "This message is sent by NG-RAN node1 to transfer access and mobility related information to NG-RAN node2."

2. TDoc R3-231548 has a direction from gNB-CU to gNB-DU.
- "This message is sent by gNB-CU to gNB-DU to provide access and mobility information to the gNB-DU."

3. TDoc R3-231546 and R3-231547 use the term "ACCESS AND MOBILITY INDICATION" while TDoc R3-231548 uses "ACCESS MOBILITY INDICATION".
- "9.1.3.25 ACCESS AND MOBILITY INDICATION" (R3-231546 and R3-231547)
- "9.2.10.1 ACCESS MOBILITY INDICATION" (R3-231548)

4. TDoc R3-231546 and R3-231547 are between NG-RAN nodes, while TDoc R3-231548 is between gNB-CU and gNB-DU.
- Direction: NG-RAN node 1 NG-RAN node 2. (R3-231546 and R3-231547)
- Direction: gNB-CU gNB-DU. (R3-231548)

5. TDoc R3-231546 and R3-231547 are related to "transfer access and mobility related information", while TDoc R3-231548 is related to "provide access and mobility information".
- "This message is sent by NG-RAN node1 to transfer access and mobility related information to NG-RAN node2." (R3-231546 and R3-231547)
- "This message is sent by gNB-CU to gNB-DU to provide access and mobility information to the gNB-DU." (R3-231548)

Technical differences among the TDoc snippets are as follows:

[TDoc R3-231549]:
- Provides access and mobility information from gNB-CU to gNB-DU
- Direction: gNB-CU gNB-DU
- Includes section 9.2.10.1 ACCESS

[TDoc R3-231727]:
- Discusses optional area scope parameter in MDT data collection in TS 32.422 stage 2 spec in SA5 for both LTE MDT and NG-RAN MDT
- Issue with optional area scope IE not being aligned to NGAP and S1/X2 in LTE MDT
- Area scope IE supports PLMN wide branch option for MDT data correction in whole serving PLMN
- Suggests changing area scope to optional in S1/X2 and NG for alignment, as per Rel-10
- Shows area scope IE as mandatory in forwarding MDT Configuration IE over X2 interface in section 9.2.56, TS 36.423

[TDoc R3-231728]:
- Describes behavior of S-NG-RAN node if Trace Activation IE includes MDT Activation IE and MDT Location Information IE in MDT Configuration IE
- If MDT Activation IE is set to Immediate MDT and Trace, initiate trace session and MDT session as described in TS 32.422
- If MDT Activation IE is set to Immediate MDT Only or Logged MDT Only, initiate MDT session as described in TS 32.422 and ignore Interfaces To Trace IE and Trace Depth IE
- Store and take into account MDT Location Information IE if supported
- If Mobility Information IE is provided in HANDOVER REQUEST message, target NG-RAN node should store if supported

[TDoc R3-231729]:
- Similar to R3-231728, but with different TDoc number. Describes behavior of S-NG-RAN node if Trace Activation IE includes MDT Activation IE and MDT Location Information IE in MDT Configuration IE
- If MDT Activation IE is set to Immediate MDT and Trace, initiate trace session and MDT session as described in TS 32.422
- If MDT Activation IE is set to Immediate MDT Only or Logged MDT Only, initiate MDT session as described in TS 32.422 and ignore Interfaces To Trace IE and Trace Depth IE
- Store and take into account MDT Location Information IE if supported
- If Mobility Information IE is provided in HANDOVER REQUEST message, target NG-RAN node should store if supported

Example snippets from the original TDoc that support the differences highlighted are as follows:

- [TDoc R3-231727]: "Issue 2: The presence of the area scope IE is optional which is not aligned to NGAP and to S1/X2 in LTE MDT."
- [TDoc R3-231727]: "If stage 2 text in TS 32.422 is correct, it means that changing the area scope to optional in S1/X2 and NG is needed since Rel-10."
- [TDoc R3-231727]: "In section 9.2.56, TS 36.423, it shows that the area scope IE is mandatory when forwarding the MDT Configuration IE over X2 interface."
- [TDoc R3-231728]: "If the Trace Activation IE includes - the MDT Activation IE set to 'Immediate MDT and Trace', and if the S-NG-RAN node is a gNB, it shall, if supported, initiate the requested trace session and MDT session as described in TS 32.422[23]."
- [TDoc R3-231728]: "If the Mobility Information IE is provided in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information."
- [TDoc R3-231729]: "If the Trace Activation IE includes - the MDT Activation IE set to 'Immediate MDT and Trace', and if the S-NG-RAN node is a gNB, it shall, if supported, initiate the requested trace session and MDT session as described in TS 32.422[23]."

Technical Differences among TDocs R3-231685, R3-231686, and R3-231687:

1. TDoc R3-231685 and R3-231686 are related to a change in the ResourceStatusFailure element, while TDoc R3-231687 is related to the Inter-system Resource Status Request element.
- Example from TDoc R3-231685: "ResourceStatusFailure PRESENCE"
- Example from TDoc R3-231686: "ResourceStatusFailure PRESENCE"
- Example from TDoc R3-231687: "Inter-system Resource Status Request"

2. TDoc R3-231685 and R3-231686 have identical contents.
- Example from TDoc R3-231685: "Direction: gNB-CU-UP gNB-CU-CP."
- Example from TDoc R3-231686: "Direction: gNB-CU-UP gNB-CU-CP."

3. TDoc R3-231687 is related to the ReportType element within the Inter-system Resource Status Request.
- Example from TDoc R3-231687: "ReportType"

4. TDoc R3-231685 and R3-231686 are related to the CriticalityDiagnostics element.
- Example from TDoc R3-231685: "{ ID id-CriticalityDiagnostics CRITICALITY ignore TYPE CriticalityDiagnostics PRESENCE optional},"
- Example from TDoc R3-231686: "{ ID id-CriticalityDiagnostics CRITICALITY ignore TYPE CriticalityDiagnostics PRESENCE optional},"

5. TDoc R3-231685 and R3-231686 are related to the Cause element.
- Example from TDoc R3-231685: "{ ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory}|"
- Example from TDoc R3-231686: "{ ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory}|"

6. TDoc R3-231687 includes a new section on the Inter-system Resource Status Request element.
- Example from TDoc R3-231687: "9.3.3.59 Inter-system Resource Status Request"

7. TDoc R3-231685 and R3-231686 have identical titles.
- Title of TDoc R3-231685: "Apr 2023 Online"
- Title of TDoc R3-231686: "Apr 2023 Online"

8. TDoc R3-231687 includes a description of the Inter-system Resource Status Request element.
- Example from TDoc R3-231687: "This IE contains information on the requested Inter-system Load Reporting reporting."

9. TDoc R3-231685 and R3-231686 are related to the ResourceStatusFailure element.
- Example from TDoc R3-231685: "ResourceStatusFailure"
- Example from TDoc R3-231686: "ResourceStatusFailure"

10. TDoc R3-231687 is related to the Inter-system Load Reporting reporting.
- Example from TDoc R3-231687: "requested Inter-system Load Reporting reporting."

Technical Differences:

1. TDoc R3-231267 defines MobilityChangeRequest as a more detailed message that includes optional and mandatory elements for mobility parameter modification. It also includes the proposed mobility parameters information for both NG-RAN node1 and NG-RAN node2.

Example from TDoc R3-231267:
- { ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory}
- { ID id-NG-RANnode2ProposedMobilityParameters CRITICALITY reject TYPE MobilityParametersInformation PRESENCE Direction: NG-RAN node1 NG-RAN node2.}

2. TDoc R3-231268 defines MobilityChangeRequest as a message that includes optional and mandatory elements for mobility parameter modification. It does not include the proposed mobility parameters information for both NG-RAN node1 and NG-RAN node2.

Example from TDoc R3-231268:
- { ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory}
- { ID id-SSBOffsets-List CRITICALITY ignore TYPE SSBOffsets-List PRESENCE optional}

3. TDoc R3-231268 includes figures for successful and unsuccessful operation of Mobility Settings Change procedure.

Example from TDoc R3-231268:
- Figure 8.4.9.2-1: Mobility Settings Change, successful operation
- Figure 8.4.9.3-1: Mobility Settings Change, unsuccessful operation

4. TDoc R3-231268 includes a section for Elements for XnAP Communication, which defines the message functional definition and content for global procedures.

Example from TDoc R3-231268:
- 9.1.3.22 MOBILITY CHANGE REQUEST: This message is sent by NG-RAN node1 to NG-RAN node2 to initiate adaptation of mobility parameters. The procedure uses non UE-associated signalling.

3GPP-R3-119-bis-e    Agenda Item 9.2.2 : MBS

TDoc R3-231114 highlights technical differences in scenarios where the gNB is unable to configure the UE with an actual value for the initialRX-DELIV at multicast MRB establishment. RAN2 notes that if the COUNT of the received PDCP PDU is less than the initialRX_DELIV, the UE discards the PDCP PDU without updating the PDCP state variables. PDCP HFN/SN should be synchronised between the UE and the gNB.

TDoc R3-231293 discusses the Handover procedure for the UE with additions for moving to another MBS service area of the MBS session. The MBS session information is provided in the path switch request acknowledge message for location-dependent multicast sessions, while it is provided in subsequent PDU session modification messages for local multicast sessions.

TDoc R3-231295 outlines that the 5GC infers from the presence or absence of the "MBS-support" indicator from gNB in the Path Switch Request message or Handover Request Acknowledge message whether to switch to 5GC Individual MBS or 5GC Shared MBS traffic delivery. The gNB-CU-UP provides the MRB configuration to the gNB-CU-CP in case the MRB configuration requested by the gNB-CU-CP and the available MRB configuration of the shared NG-U termination are different.

TDoc R3-231392 notes that for the first joined UE for inactive session or active session which has no data for a period of time, the NG-RAN will not be able to configure the MRB for the involved UEs as it is unable to configure the initialRX-DELIV IE. The solution that the gNB configure the new MRB with an incorrect initial value of RX_DELIV cannot work.

TDoc R3-231401 discusses a RAN3 solution where the CU UP should be able to build the multicastHFN-AndRefSN IE towards the CU CP in order to not delay the MRB configuration setup for joined UEs. When the CU UP receives the first multicast packets, it can send the multicastHFN-AndRefSN IE towards the CU CP in the MC Bearer Context Modification Required so that the CU CP can initialize the UE.

TDoc R3-231404 highlights that the PDCP COUNT would suddenly restart to zero from the current value if the MB-UPF resets the MBS QFI SN but two conditions can solve this problem: when the MB-UPF resets the MBS QFI SN the gNB performs release/add of the MRB to reinitialize the MRB PDCP COUNT.

TDoc R3-231461 delves into the issue of PDCP count "wrap around" and how it cannot be solved by implementation. This paper focuses on what action a gNB should take in order to prevent the PDCP count of an MRB from incrementing beyond its maximum number. As long as the gNB-CU-CP cannot instruct the gNB-CU-UP to perform the distinguishing between the packets with high count and low count, the "network implementation" cannot be performed.

Technical Differences among TDoc:

1. Additional Redundant NG-U UP TNL Information:
- This feature is present in TDoc R3-231294.
- It allows ignoring the redundant NG-U UP TNL information provided in the Path Switch Request Transfer IE.
- The corresponding UPF endpoint for split PDU session is identified using NG-RAN node endpoint of the NG-U transport bearer.
- Example snippet from the original TDoc: "9.3.2.11 NG-RAN node endpoint of the NG-U transport bearer for the redundant transmission indicated in the Path Switch Request Transfer IE and the corresponding UPF endpoint for split PDU session."

2. Criticality Assigned Criticality UL NG-U UP TNL Information:
- This feature is present in TDoc R3-231294.
- It assigns criticality to UL NG-U UP TNL Information.
- Example snippet from the original TDoc: "9.3.2.2 UPF endpoint of the NG-U transport bearer corresponding to the DL NG-U UP TNL Information IE received in the Path Switch Request Transfer IE."

3. Security Indication:
- This feature is present in TDoc R3-231294.
- It provides a security indication.
- Example snippet from the original TDoc: "9.3.1.27 - Security Indication O"

4. Redundant UL NG-U UP TNL Information:
- This feature is present in TDoc R3-231294.
- It allows ignoring the redundant UL NG-U UP TNL information.
- The corresponding UPF endpoint for delivery of UL PDUs for the redundant transmission is identified using NG-U transport bearer.
- Example snippet from the original TDoc: "9.3.2.2 UPF endpoint of the NG-U transport bearer, for delivery of UL PDUs for the redundant transmission."

5. Range Bound Explanation maxnoofQoSFlows:
- This feature is present in TDoc R3-231296.
- It is an action item for SA2 group to clarify if MBS session information can always be sent in the path switch request acknowledge message for both local or location dependent multicast sessions.
- Example snippet from the original TDoc: "ACTION: RAN3 kindly ask SA2 to clarify if the MBS session information cannot be always sent in the path switch request acknowledge message for both local or location dependent multicast sessions."

6. MBSNGUInformationAt5GC:
- This feature is present in TDoc R3-231389.
- It is a choice in MBSNGUInformationAt5GC that can include multicast or choice-extension ProtocolIE-SingleContainer.
- Example snippet from the original TDoc: "MBSNGUInformationAt5GC ::= CHOICE { multicast MBSNGUInformationAt5GC-Multicast, choice-extension ProtocolIE-SingleContainer {{MBSNGUInformationAt5GC-ExtIEs}} }"

7. BCBearerContextToSetup:
- This feature is present in TDoc R3-231389.
- It is a sequence containing snssai, BCBearerContextNGU-TNLInfoat5GC, BCMRBSetupConfiguration, requestedAction RequestedAction4AvailNGUTermination OPTIONAL, iE-Extensions ProtocolExtensionContainer { {BCBearerContextToSetup-ExtIEs} } OPTIONAL.
- Example snippet from the original TDoc: "BCBearerContextToSetup ::= SEQUENCE { snssai SNSSAI, bcBearerContextNGU-TNLInfoat5GC BCBearerContextNGU-TNLInfoat5GC, bcMRBToSetupList BCMRBSetupConfiguration, requestedAction RequestedAction4AvailNGUTermination OPTIONAL, iE-Extensions ProtocolExtensionContainer { {BCBearerContextToSetup-ExtIEs} } OPTIONAL, ... }"

1. Redundant PDU Session Information IE:
- The target NG-RAN node may set up redundant user plane for concerned PDU session if Redundant PDU Session Information IE is included in PDU Session Resource To Be Setup List IE in HANDOVER REQUEST message.
- TDoc R3-231806 [7] supports this.

2. Source DL Forwarding IP Address IE:
- If included within Data Forwarding and Offloading Info from source NG-RAN node IE in PDU Session Resources To Be Setup List IE in HANDOVER REQUEST message, it may be stored by target NG-RAN node and used as part of its ACL functionality configuration actions, if such ACL functionality is deployed.
- TDoc R3-231806 [7] supports this.

3. Estimated Arrival Probability IE:
- If contained in Conditional Handover Information Request IE in HANDOVER REQUEST message, target NG-RAN node may use it to allocate necessary resources for incoming CHO.
- TDoc R3-231806 [7] supports this.
- If contained in Conditional Intra-DU Mobility Information IE in UE CONTEXT MODIFICATION REQUEST message, gNB-DU may use it to allocate necessary resources for UE.
- TDoc R3-231834 [48] supports this.

4. BH Information IE:
- If included in UL UP TNL Information to be setup List IE or Additional PDCP Duplication TNL List IE for a DRB, gNB-DU may use indicated BAP Routing ID and BH RLC channel for transmission of corresponding GTP-U packets to IAB-donor.
- TDoc R3-231834 [48] supports this.

5. Handling of PDCP re-establishment of an AM MRB:
- For MBS multicast session, gNB may have to configure a random value for initial PDCP variables before first packet from CN.
- When first packet arrives, gNB may reconfigure initialRX-DELIV based on SN of the packet.
- Network controlled behavior is recommended only when no data is available in first-joined gNB.
- RAN2 introduces reconfiguration of initialRX-DELIV for the issue spotted by RAN3.
- TDoc R3-231860 summarizes this.

6. PDCP COUNT wrap-around of multicast MRB:
- There is a strong requirement for PDCP COUNT in AS layer for uniqueness and in order delivery.
- RAN2 has discussed the questions raised by RAN3 and answered that UE will discard PDCP PDU without updating PDCP state variables if COUNT of received PDCP PDU is less than initialRX_DELIV.
- TDoc R3-231891 [6] discusses this.

Observations:
1. If measObjectToRemoveList IE is included in MeasConfig IE, gNB-DU will ignore it.
2. It is up to network implementation to prevent PDCP COUNT wrap-around of multicast MRB.

Technical Differences among the TDocs:

1. TDoc R3-231391:
- Defines the BroadcastContextModificationResponse sequence with ProtocolIE-Container that has BroadcastContextModificationResponseIEs.
- BroadcastContextModificationResponseIEs are defined with ID, CRITICALITY, TYPE, and PRESENCE.
- Example snippet: ID id-BroadcastMRBs-SetupMod-List CRITICALITY reject TYPE BroadcastMRBs-SetupMod-List PRESENCE.

2. TDoc R3-231393:
- Defines the MBS-QoSFlowsToBeSetupList sequence with MBS-QoSFlowsToBeSetupItem.
- MBS-QoSFlowsToBeSetupItem is defined with mBSqosFlowIdentifier, mBSqosFlowLevelQosParameters, and ProtocolExtensionContainer with MBS-QoSFlowsToBeSetupItem-ExtIEs.
- Example snippet: MBS-QoSFlowsToBeSetupItem-ExtIEs NGAP-PROTOCOL-EXTENSION.

3. TDoc R3-231462:
- Defines the MCMRBSetupModifyConfiguration sequence with MCMRBSetupModifyConfiguration-Item.
- MCMRBSetupModifyConfiguration-Item is defined with mrb-ID, f1uTNLatDU, sdap-config, mbs-pdcp-config, qoS-Flow-QoS-Parameter-List, mrbQoS, MBS-PDCP-COUNT-Req, and ProtocolExtensionContainer with MCMRBSetupModifyConfiguration-Item-ExtIEs.
- Example snippet: MCMRBSetupModifyConfiguration-Item-ExtIEs E1AP-PROTOCOL-EXTENSION.

4. TDoc R3-231391:
- Defines constant definitions for different ProtocolIE-IDs.
- Example snippet: id-MBSSessionReleaseResponseTransfer ProtocolIE-ID ::= 358.

Supporting Example Snippets:

1. Example from TDoc R3-231391:
- ID id-BroadcastMRBs-SetupMod-List CRITICALITY reject TYPE BroadcastMRBs-SetupMod-List PRESENCE.
- This snippet supports the technical difference that BroadcastContextModificationResponseIEs are defined with ID, CRITICALITY, TYPE, and PRESENCE.

2. Example from TDoc R3-231393:
- MBS-QoSFlowsToBeSetupItem-ExtIEs NGAP-PROTOCOL-EXTENSION.
- This snippet supports the technical difference that MBS-QoSFlowsToBeSetupItem is defined with ProtocolExtensionContainer that has MBS-QoSFlowsToBeSetupItem-ExtIEs.

3. Example from TDoc R3-231462:
- MCMRBSetupModifyConfiguration-Item-ExtIEs E1AP-PROTOCOL-EXTENSION.
- This snippet supports the technical difference that MCMRBSetupModifyConfiguration-Item is defined with ProtocolExtensionContainer that has MCMRBSetupModifyConfiguration-Item-ExtIEs.

4. Example from TDoc R3-231391:
- id-MBSSessionReleaseResponseTransfer ProtocolIE-ID ::= 358.
- This snippet supports the technical difference that TDoc R3-231391 defines constant definitions for different ProtocolIE-IDs.

3GPP-R3-119-bis-e    Agenda Item 9.2.3 : SCG and CPAC

3GPP-R3-119-bis-e    Agenda Item 10.1 : General

TDoc R3-231127:
- Collecting statistics of inter-system ping-pong occurrences
- Performing coverage verification to check if the mobility to other system was inevitable
- Using HANDOVER REPORT message or UPLINK RAN CONFIGURATION TRANSFER message to indicate potential ping-pong cases to the source NG-RAN node
- Evaluating measurement reports received during inter-system HO procedure to decide if an inter-system unnecessary HO report should be sent to the gNB in the source system
- Performing admission control for load balancing handovers

Example from TDoc R3-231127: "Coverage verification is performed to check if the mobility to other system was inevitable."

TDoc R3-231128:
- Storing received Redundant PDU Session Information IE and using it for redundant PDU session setup
- Performing requested location reporting functionality for UE if Location Reporting Request Type IE is included in HANDOVER REQUEST message or INITIAL CONTEXT SETUP REQUEST message
- Storing QoS Monitoring Reporting Frequency IE and using it for RAN part delay reporting

Example from TDoc R3-231128: "If the HANDOVER REQUEST message contains the Redundant PDU Session Information IE associated with a given PDU session within the Handover Request Transfer IE, the target NG-RAN node shall, if supported, store the received information in the UE context and use it for redundant PDU session setup."

TDoc R3-231789:
- RAN3 takes lead of specification enhancement of SON features and MDT for network signalling
- RAN2 takes lead of specification enhancement of MDT, L2 measurements, and specific L2/L3 changes needed to fulfill SON functionalities over the Uu interface
- All WGs will involve other WGs on some aspects when needed

Example from TDoc R3-231789: "RAN2 will have to trigger RAN3 on network aspects for MDT."

Overall, TDoc R3-231127 focuses on inter-system ping-pong occurrences and admission control for load balancing handovers, while TDoc R3-231128 focuses on storing and using various types of information for UE and RAN part delay reporting. TDoc R3-231789 outlines the roles of RAN3 and RAN2 in enhancing SON features and MDT, and highlights the need for collaboration among all WGs when necessary.

3GPP-R3-119-bis-e    Agenda Item 10.2.1 : SHR and SPR

• TDoc R3-231200 proposes Option 1 for UE context retrieval, where Mobility Information is sent to the UE along with T310/T312 threshold configuration, and UE includes Mobility Information in the inter-RAT SHR.

Example snippet: "Option 1: The Mobility Information is sent to the UE together with the T310/T312 threshold configuration."

• TDoc R3-231200 lists several pieces of information that are sent to the UE along with the Mobility Information in Option 1.

Example snippet: "Source NR cell information, Target LTE cell information, Measurement results for source, target and neighbours, Cause to indicate which inter-RAT SHR triggering condition was met, UE location Information."

• TDoc R3-231200 notes that CHO related information in intra-NR SHR is not applicable for inter-RAT SHR.

Example snippet: "RAN3 thinks that all CHO related information in intra-NR SHR (e.g., time from CHO configuration to execution) is not applicable for inter-RAT SHR."

• TDoc R3-231269 discusses including several pieces of information in the inter-RAT SHR from NR to LTE, including Source NR cell information, Target LTE cell information, Measurement results for source, target and neighbours, Cause to indicate which inter-RAT SHR triggering condition was met, and UE location Information.

Example snippet: "In RAN3#117bis e-meeting, it was agreed to consider the following information into the inter-RAT SHR from NR to LTE: Source NR cell information, Target LTE cell information, Measurement results for source, target and neighbours, Cause to indicate which inter-RAT SHR triggering condition was met, UE location Information."

• TDoc R3-231269 raises the question of whether the presence of Target C-RNTI IE in inter-RAT SHR is related to the decision on supporting T304 trigger.

Example snippet: "FFS whether the presence of Target C-RNTI IE in inter-RAT SHR is related to the decision on supporting T304 trigger."

• TDoc R3-231269 notes that for inter-RAT HO from NR to LTE, the source NR node will receive both inter-RAT NR SHR and LTE RLF report in case the SHR is triggered and RLF occurs shortly after successful HO.

Example snippet: "For the inter-RAT HO from NR to LTE, the source NR node will receive both inter-RAT NR SHR and LTE RLF report in case that the SHR is triggered and RLF occurs shortly after successful HO."

Overall, the two TDocs discuss similar topics related to inter-RAT SHR, but TDoc R3-231200 focuses more on UE context retrieval and lists more specific pieces of information sent in Option 1, while TDoc R3-231269 discusses the inclusion of information in inter-RAT SHR from NR to LTE and raises the question of the Target C-RNTI IE's relevance to T304 trigger support.

In TDoc R3-231339, Proposal 21 suggests two options for identifying UE context in the old target SN when SPR is forwarded for T304 related SPR optimizations. Option 1 involves the UE including the C-RNTI allocated by the old target SN and the time between PSCell change and SPR retrieval. Option 2 involves the old MN identifying the UE context and sending the stored SN Mobility Information together with SPR to the old target SN.

In the same TDoc, Proposal 6 suggests using the same forwarding mechanism for SHR collected during intra-NR HO as agreed for inter-RAT HO. The UE collects both the NR SHR and the SHR triggered by the inter-RAT HO. The target gNB can identify the intra-NR SHR and NR RLF Report generated in the same HO procedure for the same UE.

TDoc R3-231708, Discussion 2.1.1 discusses the forwarding mechanism for inter-RAT SHR. The document suggests taking Option 3 as the baseline for SHR forwarding mechanism in Rel-18. During the Secondary Node Addition procedure, the SN node provides SPR trigger configuration to the MN. The UE may generate both SHR and RLF report for the same handover procedure.

In TDoc R3-231791, Proposal 4 suggests the UE reporting the correlation related information between NR SHR and LTE RLF report for inter-RAT HO from NR to LTE. This includes a correlation indication of NR SHR and RLF report, indicating whether there is an RLF shortly after a successful inter-RAT HO from NR to LTE. Proposal 5 suggests the receiving node forwarding the correlation related information between NR SHR and LTE RLF report to source NR node for root cause analysis. Furthermore, correlation in target eNB could bring the LTE specification impact.

Overall, the TDocs highlight technical differences in the identification of UE context, forwarding mechanism for SHR, and correlation related information between NR SHR and LTE RLF report for inter-RAT HO from NR to LTE. These differences are addressed through various proposals and agreements within the documents.

1. MN-initiated classic PSCell change/CPC:
- MN configures T310/T312 trigger to UE
- MN performs root cause analysis
- Inter-RAT SHR preferred to be encoded into NR format
- Open issue on which node should decide SPR triggers and perform root cause analysis
- RAN2 also discussing content of inter-RAT SHR in parallel

2. Inter-RAT SHR from NR to LTE:
- Mainly to optimize RLM/BFD configurations in source NR node
- No tight correlation needed between NR node configuration and RLF in target eNB node
- Correlation mechanism not needed in SHR report from UE
- Source gNB uses different correlation mechanism from Rel-17 intra-NR SHR
- Proposal to augment SHR with RACH attempts and contention flag for successful handover
- Proposal to enhance inter-RAT SHR configuration with triggering condition for number of random access attempts toward LTE cell

3. SHR retrieval:
- Some companies argue inter-RAT SHR should be stored in UE until network fetches it
- Proposal to enhance SHR configuration with triggering condition for number of RA attempts at HO execution toward LTE cell
- New node forwards SPR to original MN

Example snippets from TDoc:
- "Therefore the inter-RAT SHR is preferred to be encoded into NR format" (MN-initiated classic PSCell change/CPC)
- "No correlation needed" (Inter-RAT SHR from NR to LTE)
- "Proposal 4: It is infeasible for network to store UE context for SHR analysis" (Proposal 4 for inter-RAT handover from NR to LTE)
- "To enable logging of these information in the SHR, we propose to enhance the SHR configuration with a triggering condition for the number of RA attempts" (SHR retrieval)
- "New node forwards the SPR to the original MN" (SHR retrieval)

- Proposal 11 suggests adding PCell information, CPC information, time between CPC execution and report retrieval, and C-RNTI to the Successful PSCell Change Report in case of MN initiated PSCell change.
- Proposal 1 mentions that the objective of SPR triggered by T304 is to optimize RACH access issue as part of PSCell change configuration optimization during mobility.
- The source SN node should inform MN of the updated T310/312 configurations if they cancel or change them.
- Proposal 1 suggests that for MN-initiated classic PSCell change or CPC, the MN node decides the T310/T312 trigger threshold and performs root cause analysis when SPR is triggered due to T310/T312 trigger threshold fulfillment.
- Proposal 1 of TDoc R3-231792 suggests that the MN node that initiates the procedure should decide the T310/T312 triggers and perform root cause analysis for related parameters and configuration optimization, for MN-initiated classic PSCell change / CPC.
- Observation 2 highlights that although Option2 of letting the source SN node decide the T310/T312 triggers and perform root cause analysis can simplify the generation of T310/T312 triggers condition for MN-initiated classic PScell change /CPC, other issues arising from Option2 need to be taken into account.

Example snippets from the TDoc:

- "Proposal 11: FFS whether to also include the following in Successful PSCell Change Report: PCell information, in case of MN initiated PSCell change/CPC Information that PSCell change was MN-initiated or SN-initiated Time between CPC execution and report retrieval C-RNTI (MN, target SN, source SN)"
- "Proposal 1: For the trigger T304, the objective of SPR is to optimize the RACH access issue as part of PSCell change configuration optimization during mobility."
- "When the source SN decides to cancel or change the configurations of T310/312, the source SN node should inform MN of the updated ones."
- "Proposal 1: For MN-initiated classic PSCell change or CPC, the MN node decides the T310/T312 trigger threshold, and the MN node performs root cause analysis when SPR is triggered due to T310/T312 trigger threshold is fulfilled."
- "Proposal 1: For MN-initiated classic PScell change /CPC, the MN node which initiates the procedure should decide the T310/T312 triggers and perform root cause analysis for the related parameters and configuration optimization."
- "Observation 2: Although Option2 (the source SN node decides the T310/T312 triggers and performs root cause analysis) can simplify the generation of T310/T312 triggers condition for MN-initiated classic PScell change /CPC, other issues arising from Option2 need to be taken into account."

3GPP-R3-119-bis-e    Agenda Item 10.2.2 : MRO

- TDoc R3-231201:

1. Too Late CPC Execution: UE receives CPC configuration, but an SCG failure occurs before CPC execution condition is satisfied; a different PSCell is found based on reported measurements.
- Example: "UE receives a CPC configuration command, but an SCG failure occurs before CPC execution condition is satisfied. The UE reports measurements to the network, and a suitable PSCell different from the source PSCell is selected based on these measurements."
2. Too Early CPC Execution: UE receives CPC configuration, and CPC execution condition is satisfied, but execution fails or an SCG failure occurs shortly after; source PSCell remains suitable.
- Example: "UE receives CPC configuration, and CPC execution condition is satisfied. However, CPC execution fails or an SCG failure occurs shortly after a successful CPC execution. The source PSCell is still the suitable PSCell based on measurements reported from the UE."
3. CPC Execution to wrong PSCell: CPC execution occurs to the wrong candidate cell, either from the initiating node's list or selected by the target node.
- Example: "CPC execution occurs to the wrong candidate cell. This can happen if the wrong candidate cell is provided in the initiating node's list, or if the target node selects the wrong candidate cell."

- TDoc R3-231202:

1. Inter-system inter-RAT handover from NR to E-UTRAN fails, and no suitable E-UTRAN cell can be selected for voice fallback; UE reverts to source PCell and initiates RRC re-establishment in NR.
- Example: "After a failure of inter-system inter-RAT handover from NR to E-UTRAN for voice fallback, no suitable E-UTRAN cell can be selected. The UE reverts back to the configuration of the source PCell and initiates RRC re-establishment procedure in NR."
2. Failure indication can be sent to the last serving node when NG-RAN node fetches RLF REPORT from UE via Failure Indication procedure over Xn or Uplink/Downlink RAN Configuration Transfer procedure over NG.
- Example: "A failure indication may be sent to the node last serving the UE when the NG-RAN node fetches the RLF REPORT from UE by triggering the Failure Indication procedure over Xn or the Uplink/Downlink RAN Configuration Transfer procedure over NG."

- TDoc R3-231271:

1. Upon reception of SCGFailureInformation, MN indicates the set of SN mobility information, including initial recommended SN mobility info and latest SN mobility info, to source SN via SCGFailureInformationReport to ensure sufficient CPAC configuration information for MRO analysis.
- Example: "Upon reception of SCGFailureInformation, MN indicates the set of SN mobility information, including initial recommended SN mobility info and latest SN mobility info, to the source SN via SCGFailureInformationReport to ensure that the source SN has sufficient CPAC configuration information to perform MRO analysis, such as wrong PSCell selection."
2. Initiating node performs initial analysis to identify the node that caused the CPAC-related SCG failure and informs possible problem candidate SN to MN.
- Example: "The initiating node performs initial analysis to identify the node that caused the CPAC-related SCG failure and informs the possible problem candidate SN to MN."

- TDoc R3-231425:

1. UE reports time elapsed between SCG failure in source SCG and latest CPC configuration received in SCG Failure Information message to enable network to decide if CPC execution condition or candidate PSCell(s) are configured properly.
- Example: "To enable the network to decide whether the CPC execution condition or candidate PSCell(s) are configured properly or not, it is necessary for the UE to report the time elapsed between the SCG failure in the source SCG and the latest CPC configuration received in the SCG Failure Information message."
2. Time elapsed since CPAC execution towards target PSCell until SCG failure is needed for CPAC MRO, and MN performs initial analysis to identify the node that caused the failure.
- Example: "The time elapsed since the CPAC execution towards the target PSCell until the SCG failure is needed for MRO for CPAC. MN performs initial analysis to identify the node that caused the failure."

1. PSCell change problem: There is a possible problem where the PSCells prepared for CPC are marginally appropriate for the UE, resulting in connection failure.

- Proposal 2: RAN3 shall consider if the initiating node can support the Target SN in selecting the right target PSCell(s).
- The MN may use the SCG Failure Information Report procedure to verify whether intra-SN PSCell change has been triggered in the last serving SN and stores the SCG Failure Information for the time needed to receive possible response from the last serving SN.
- Proposal 1: RAN3 agrees the above update of the definition of the CPC Execution to wrong PSCell and adds it to the BL CR to the TS 37.340.
- Proposal 4: The additional information may comprise of a prioritisation of certain PSCells over others and/or the probability that a given PSCell was the correct one in the past.

2. T316 timer: The MN can inform the SN about the value of the T316 timer configured in the UE for SRB3 resources to be reserved for possible MCG recovery.

- Proposal 2.1: When the MN requests SRB3 resources to be reserved for the possible MCG recovery, it can also inform the SN about the value of the T316 timer configured in the UE.

3. Signalling delay: Addressing prolonged delays in signalling.

- The signalling delay is longer than the time the UE waits for the response (T316 expired).
- However, the report is not necessary to detect that the MCG recovery failed due to the inactivity of SCG.

4. Fast MCG recovery: Investigating other cases and necessary information to be reported for fast MCG recovery.

- Proposal 1: Last but not least, for case e, when subsequent failure happens, the legacy MRO failure operations can still be used. No other case should be included for the MRO for fast MCG recovery.
- Proposal 2: RAN3 shall study the benefit of reporting the RLF type from the UE to the MN or not.
- Proposal 3: RAN3 agrees to the additional information to be reported in the MCGFailureInformation.

Technical Differences and Examples from TDoc R3-231340, R3-231426, R3-231554, and R3-231585:

1. Proposal 6 in TDoc R3-231340 suggests including an indication for voice fall back in LTE RLF Report if there is an RLF in the target LTE cell immediately after a successful inter-system HO for voice fall back.
- Example: "Include an indication for voice fall back in LTE RLF Report."

2. Observation 2 in TDoc R3-231340 highlights that the current definition of too early inter-system HO only covers the direction from LTE NR and not from NR LTE.
- Example: "Current definition of too early inter-system HO is only for the direction from LTE NR and doesn't cover the direction from NR LTE."

3. Proposal 7 in TDoc R3-231340 proposes extending the current definition of too early inter-system HO to also cover NR LTE.
- Example: "Extend the current definition of Too early inter-system HO to also cover NR LTE."

4. Proposal 8 in TDoc R3-231340 suggests including a voice fall back indication in Inter-system HO Report over NG and S1.
- Example: "Include a voice fall back indication in Inter-system HO Report over NG and S1."

5. Proposal 9 in TDoc R3-231340 proposes optimizing the set of candidate PSCells and execution conditions during CPA/CPC by eliminating case c, case d, and case e in Rel-18.
- Example: "There is no need to consider case c, case d and case e in Rel-18."

6. Observation 3 in TDoc R3-231340 highlights that there are two possible scenarios for back-to-back MCG failures and SCG failures and the importance of optimizing the set of candidate PSCells and execution conditions during CPA/CPC.
- Example: "There are two possible scenarios for back-to-back MCG failures and SCG failures...It is therefore important to optimize the set of candidate PSCells and execution conditions during CPA/CPC."

7. Proposal 1 in TDoc R3-231426 suggests sending the NR RLF report to the connected NG-RAN node when a suitable E-UTRAN cell is selected after HOF of inter-system inter-RAT handover from NR to E-UTRAN for voice fallback.
- Example: "When the UE is back to a NG-RAN node, the UE may send the NR RLF report to the connected NG-RAN node."

8. TDoc R3-231554 proposes enhancing RLF report to recode Time between MCG failure and SCG failure and SN status and clarifying that it includes the case of PScell change/addition before MCG failure.
- Example: "Enhance RLF report to recode Time between MCG failure and SCG failure and SN status should be clarified that it includes the case of PScell change/addition before MCG failure."

9. TDoc R3-231585 highlights the detection mechanisms for Too Late Inter-system Handover and Too Early Inter-system Handover when the last serving node is an NG-RAN node.
- Example: "The detection mechanisms for Too Late Inter-system Handover Too Early Inter-system Handover are carried out through the following."

- Report of fast MCG recovery failure should be included in RLF-Report for network to modify corresponding parameters for MRO purpose.
- Different indications are needed to distinguish Case a and Case f1 regarding fast MCG recovery failure.
- UE does not need to keep and report time-related information during CPA/CPC procedures as network is already aware of every time point.
- For CHO candidate PSCell list and execution conditions, network can keep them and it is not necessary for UE to keep and report them.
- RRCReconfigurationComplete message is initiated from UE to network during CPA/CPC execution to indicate the selected PSCell.
- UE should report information of CPA/CPC event trigger condition in case of MCG RLF before CPA/CPC execution.
- Information about the elapsed time between SCG failure and latest CPC configuration is received by UE in case of SCG failure before CPC execution.
- UE can report the elapsed T316 timer for MDT enhancement optimization of fast MCG recovery in near failure scenario.

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

- "It is beneficial for the UE to report this failure type of fast MCG recovery failure in the RLF-Report" (TDoc R3-231427)
- "an indication concerning whether the T316 is running upon SCG failure or SCG deactivation or other cases that SCG is not available is needed to be reported" (TDoc R3-231427)
- "Since network is aware of the every time point during CPA/CPC procedures, it is not needed for UE to keep and report time related information" (TDoc R3-231553)
- "For CHO candidate PSCell list and execution conditions, network can keep them and it is not needed for UE to keep and report them" (TDoc R3-231553)
- "RRCReconfigurationComplete message which includes selectedCondRRCReconfig field is initiated from UE to network to indicate the selected PSCell" (TDoc R3-231790)
- "UE reports the information of the CPA/CPC event trigger condition, e.g. no configured CPA/CPC event triggered, and only one of the CPA/CPC events triggered when there are multiple events configured for CPA/CPC in RLF report" (TDoc R3-231790)
- "UE should report the following information in the SCGFailureInformation message The time elapsed between the SCG failure in source SCG and the latest CPC configuration is received" (TDoc R3-231800)
- "UE can report some information, e.g., the elapsed T316 timer, that is, the time between transmitting MCGFailureInformation and receiving RRC reconfiguration or release message" (TDoc R3-231800)

3GPP-R3-119-bis-e    Agenda Item 10.2.3 : RACH Enhancements

1. The first TDoc (R3-231112) mentions that RAN2 agreed to have a list of SN RA report entries as a single NR container (i.e. NR RA-ReportList).

Example snippet: "RAN2 made the following agreements: 1: To have 'a list of SN RA report entries as a single NR container (i.e. NR RA-ReportList).'"

2. The second TDoc (R3-231587) discusses two alternatives proposed by RAN2 on how the UE includes the PSCell identities in the report, i.e. including unique PSCell identities or the last PSCell identity.

Example snippet: "RAN2 discusses the following alternatives regarding how the UE includes the PSCell identities: - Alt 1: Includes unique PSCell identities, i.e. if a PSCell occurs more than once in NR RA-ReportList, it is recorded only once in the list of PSCell identities - Alt 2: Includes the last PSCell identity (in NR RA-ReportList)"

3. RAN3 prefers alternative 2b over alternative 1 discussed in the third TDoc (R3-231741), as it needs less network signaling to forward the SN RA report.

Example snippet: "RAN3 discusses the two alternatives in the LS, and achieves the following agreements: RAN3 prefers alternative 2b because 2b needs less network signalling to forward the SN RA report."

4. The third TDoc (R3-231741) highlights that it is not supported in R18 that UE reports NR RACH Report to LTE cell when UE is in standalone LTE. RAN3 proposes RAN2 to revise it and consider supporting the NR RACH Report to LTE in SA LTE case.

Example snippet: "Furthermore, RAN3 notices and discusses the following RAN2 agreement: => It is not supported in R18 that UE reports NR RACH Report to LTE cell when the UE is in standalone LTE...RAN3 proposes RAN2 to revise it and consider supporting the NR RACH Report to LTE in SA LTE case."

5. RAN3 also proposes that the UE should record and report the PCell ID associated with the PSCell ID to assist the SN RA Report forwarding between MNs in the same TDoc.

Example snippet: "For support of inter-MN handover with SN change, the UE shall record and report the PCell ID associated to the PSCell ID to assist the SN RA Report forwarding between MNs."

In TDoc R3-231300, the technical differences are related to RA report enhancements and RACH partitioning. Some proposals drawn from the analysis include the addition of two parameters into the RA report, which are the feature or feature combination that triggered the RACH and used feature combination. Network configured parameters are not necessary to be included in the RA report. A Retrieve UE Context-like procedure, with a UE ID included to identify the UE, can be used to retrieve these configuration information from the old gNB.

In TDoc R3-231341, the technical differences are related to two alternatives for sending NR RA Report to EPC. Alt 1 includes unique PSCell identities, while Alt 2 includes the last PSCell identity. The drawbacks of Alt 1 compared to Alt 2 are highlighted, and a proposal is made to send a reply LS to RAN2 clarifying that Alt 1 is not preferred from RAN3 perspective. Since RAN2 deprioritized the scenario that UE reports NR RA Report to LTE cell when UE is in standalone LTE, “last PSCell identity” will always be the current serving PSCell and hence there is no need for UE to include any PSCell identity in RA-Report.

In TDoc R3-231555, the technical differences are related to the load of Alt 1 and Alt 2 from the Uu interface perspective. Alt 1 includes unique PSCell identities, while Alt 2 includes the last PSCell identity. Proposal 4 is made to indicate the PScell ID of such SN and optionally forward NR container or the RACH entry related to this PScell to MN in case there is no interface between SNs for Alt2.

In TDoc R3-231740, the technical differences are related to RA report retrieval and inter-MN handover with SN change. A proposal is made for alternative 2b to support SN RA report forwarding in case of inter-MN handover with SN change, where the UE needs to report the PCell ID outside RA report container to identify the correct connecting MN.

1. Technical differences in TDoc R3-231586:

- The TDoc includes various information elements (IEs) such as SRSPosRRCInactiveConfig, SDTBearerConfigurationQueryIndication, SDTBearerConfigurationInfo, PosSItypeList, DAPS-HO-Status, UuRLCChannelID, UplinkTxDirectCurrentTwoCarrierListInfo, UlTxDirectCurrentMoreCarrierInformation, SRSPosRRCInactiveQueryIndication, MC-PagingCell-Item, and FROM F1AP-IEs.
- These IEs are identified by their respective IDs, such as id-SRSPosRRCInactiveConfig, id-SDTBearerConfigurationQueryIndication, id-SDTBearerConfigurationInfo, id-PosSItypeList, id-DAPS-HO-Status, id-SRBMappingInfo, id-UplinkTxDirectCurrentTwoCarrierListInfo, id-UlTxDirectCurrentMoreCarrierInformation, and id-SRSPosRRCInactiveQueryIndication.
- The TDoc also mentions some parameters such as maxCellingNBDU, maxnoofCandidateSpCells, maxnoofDRBs, and maxnoofErrors.
- The receiving node is allowed to extract only the required information and reject the rest.

Example snippet from the TDoc: "The UE sends the SDTBearerConfigurationQuery message to the network when it is required to obtain the bearer configurations of one or more secondary eNBs for the SDAP layer."

2. Technical differences in TDoc R3-231628:

- The TDoc discusses the network-based method for estimating RA report availability.
- It mentions that when a UE performs successful random access attempts (which are only known by the gNB-DU), the gNB-DU may inform the gNB-CU about the occurrences of successful random access procedures via a RACH indication.
- The TDoc also talks about PSCell identities for NR RA container in EN-DC/(NG)EN-DC scenario.

Example snippet from the TDoc: "When the gNB-DU detects the RA success, it sends a RACH Indication to the gNB-CU to inform the occurrence of successful RA procedures in the gNB-DU."

3GPP-R3-119-bis-e    Agenda Item 10.2.4 : SON/MDT Enhancements for Non-Public Networks

Technical Differences and Example Snippets from TDocs:

1. Redundant PDU Session Information:
- If the Redundant PDU Session Information IE is included in the PDU Session Resource To Be Setup List IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the received information in the UE context and set up the redundant user plane for the concerned PDU session.
- Example: "If the Redundant PDU Session Information IE is included in the PDU Session Resource To Be Setup List IE contained in the HANDOVER REQUEST message, then the target NG-RAN node may configure the user plane for the concerned PDU session to be redundant as specified in TS 23.501."

2. Source DL Forwarding IP Address:
- If for a given QoS Flow the Source DL Forwarding IP Address IE is included within the Data Forwarding and Offloading Info from source NG-RAN node IE in the PDU Session Resources To Be Setup List IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information and use it as part of its ACL functionality configuration actions, if such ACL functionality is deployed.
- Example: "If for a given QoS Flow the Source DL Forwarding IP Address IE is included within the Data Forwarding and Offloading Info from source NG-RAN node IE in the PDU Session Resources To Be Setup List IE contained in the HANDOVER REQUEST message, then the target NG-RAN node may use this information as part of its ACL functionality configuration actions, if such ACL functionality is deployed."

3. Estimated Arrival Probability:
- If the Estimated Arrival Probability IE is contained in the Conditional Handover Information Request IE included in the HANDOVER REQUEST message, then the target NG-RAN node may use the information to allocate necessary resources for the incoming CHO.
- Example: "If the Estimated Arrival Probability IE is contained in the Conditional Handover Information Request IE included in the HANDOVER REQUEST message, then the target NG-RAN node may use this information to allocate necessary resources for the incoming CHO."

4. MDT area scope and MDT measurement retrieval:
- The whole SNPN ID, which is a combination of PLMN ID and Network identifier (NID), needs to be included in the MDT Configuration-NR IE to configure an area scope for SNPN.
- UE should not discard the MDT measurement when moving out of a SNPN, and UE can report the MDT measurement to other networks if the SNPN service customer gives consent to share the results.
- Only the SNPN operator and service customer can obtain the MDT measurement collected in that SNPN and the UEs are not allowed to report the collected MDT measurement to other networks.
- Example: "Considering SA2 is working on supporting equivalent SNPN, the whole SNPN ID, which is a combination of PLMN ID and Network identifier (NID), needs to be included in the MDT Configuration-NR IE to configure an area scope for SNPN." "UE can report the MDT measurement to other networks if the SNPN service customer gives consent to share the results." "Since there is a possibility that a SNPN service customer is interested in measuring network performance in specific SNPN(s), it is beneficial to request UEs around the interested area(s) perform measurements and then report the measurement results."

TDoc R3-231337:

- A complex combination of two IEs (choice and new outside IE) is used to configure the NPN MDT area scope.
- The description needs to be clear to avoid confusion.
- The new choice of PNI-NPN based is used to indicate the CAG list if only CAG cells are measured.
- Without NPN information in UE report, self-optimization is done as normal MRO.
- Semantics descriptions can be divided into two categories.
- Add semantics description “If PNI-NPN Area Scope of MDT IE is present, it covers non-CAG cells only” to old choices.

TDoc R3-231342:

- The max number of SNPNs in the SNPN list is limited to 1 in Rel-18 to avoid configuring SNPNs other than the registered SNPN for MDT collection.
- MDT collection in the SNPN should not be allowed if the SNPN ID indicated by the OAM in the Trace Activation Request doesn’t match any SNPN ID broadcasted by the NG-RAN node or the UE is registered in a different SNPN.
- Rel-18 should enable collection of MDT measurements from specific cells or TAs of the registered SNPN.
- Enable collection of MDT measurements in the SNPN where the UE is registered.

TDoc R3-231556:

- No need to introduce a separate IE for supporting Area Scope of MDT in SNPN to avoid redundancy.
- MDT’s measurement result is almost the cell quality instead of some private information, so there’s no need to add this semantics description.
- Without UE context, the network cannot identify the difference between UE0 and UE1 or UE2 and UE3.

TDoc R3-231588:

- NPN cells/frequencies can be included in the Area Scope of Neighbour Cells, and it’s up to the operator to allow for collection of measurements in such frequencies/cells.
- The specifications could enable the inclusion of NPN cells/frequencies in the Area Scope of Neighbour Cells.
- The user consent framework in place for MDT should not apply to SNPN networks.

Example snippets from TDoc R3-231337:

- “Since we use a complex combination of two IEs (choice and new outside IE) to configure the NPN MDT area scope, the description needs to be very clear and cannot lead to the mis-understanding or confusion.”
- “If only CAG cells are measured, the new choice of PNI-NPN based is used to indicate the CAG list.”
- “Without NPN information in UE report, the self-optimization is done as the normal MRO, so the node may recognize that this is a bad HO and do the related update.”
- “Semantics description 1: add semantics description “If PNI-NPN Area Scope of MDT IE is present, it covers non-CAG cells only” to the Old Choices.”

Example snippets from TDoc R3-231342:

- “In order to avoid OAM configuring SNPNs other than the registered SNPN for MDT collection in Rel-18, we can limit the max number of SNPNs in the SNPN list to 1 in Rel-18.”
- “If the SNPN ID indicated by the OAM in the Trace Activation Request doesn’t match any SNPN ID broadcasted by the NG-RAN node or the UE is registered in a different SNPN, then MDT collection in the SNPN should not be allowed.”
- “Rel-18 should enable collection of MDT measurements from specific cells or TAs of the registered SNPN.”
- “Use Case 3: Enable collection of MDT measurements in the SNPN where the UE is registered.”

Example snippets from TDoc R3-231556:

- “No need to introduce a separately IE for supporting Area Scope of MDT in SNPN, which may make the structure looks redundancy.”
- “MDT’s measurement result is almost the cell quality instead of some private information, no need to add this Semantics description.”
- “Without UE context, network cannot identify the difference between UE0 and UE1 according to current specification.”

Example snippets from TDoc R3-231588:

- “This would leave to the operator control of whether to exclude PNI-NPN information in the UHI, should such information be sensitive and non-disclosable.”
- “NIDs added to the choice structure should be a list of NIDs together with PLMN IDs to allow collection of MDT measurements in equivalent SNPNs as shown in the appendix.”
- “The specifications could enable the inclusion of NPN cells/frequencies in the Area Scope of Neighbour Cells and that it can be up to the operator to configure whether to allow for collection of measurements in such frequencies/cells.”

Summary of Technical Differences in TDoc R3-231185 and R3-231629:

TDoc R3-231185:

- Provides three use cases for MDT measurements in specific PNI-NPNs and SNPN.
- Proposes the addition of a CAG list for MDT Area Scope.
- Focuses on discussions for addressing MDT Area Scope for specific cells or TAs of an SNPN.

Example snippet: "Use Case 1: Enhanced area scope information should allow collection of MDT measurements in specific PNI-NPNs, i.e. MDT measurements should be collected only within specific CAGs."

TDoc R3-231629:

- Addresses editor's notes on Semantics Descriptions and compatibility of newly added information with configuration of MDT measurements and MDT Area Scope.
- Proposes indicating the SNPN for TAI-based MDT Area Scope and the cell for cell-based MDT Area Scope.
- Mentions the legacy MDT area scope containing a PLMN-wide option.

Example snippet: "Proposal 2: For TAI-based MDT area scope for SNPN, indicate which SNPN the TA belongs to."

3GPP-R3-119-bis-e    Agenda Item 10.2.5 : SON for NR-U

Technical differences among the TDocs can be summarized as follows:

1. TDoc R3-231228 highlights the impact of waiting time on MRO analysis, particularly in relation to mobility related RLFs that could be wrongly added to MRO KPI statistics if failure was induced by channel access delays due to LBT. The solution proposed is to split waiting time in DL and UL, as delays due to LBT during the mobility procedure impact both uplink and downlink transmissions.

Example snippet from TDoc R3-231228 to support the difference: "Observation 2: Delays due to LBT during the mobility procedure are impacting both uplink and downlink transmissions. As demonstrated in Figure 1 from [1], each RRC signalling message which needs to be exchanged between UE and network has to follow the LBT rule, i.e., the measurement event reporting is affected as well as RRCReconfiguration message for preparation, and the handover execution where also both the uplink RACH message and the downlink RACH Response (RAR) message have to be deferred as long as medium is busy, and results in spoiling the timing of the mobility process."

2. TDoc R3-231302 discusses the configuration of UE with the absolute maximum EDT value and the offset to the default maximum EDT value. The objective is to help the network better understand the failure case and adjust the threshold to a reasonable one, particularly in relation to UL transmission where a UE can use an EDT which is less than or equal to the maximum EDT value and the network has no knowledge of the actual EDT value that the UE used when performing channel-sensing.

Example snippet from TDoc R3-231302 to support the difference: "For UL transmission, a UE can use an EDT which is less than or equal to the maximum EDT value and the network has no knowledge of the actual EDT value that the UE used when performing channel-sensing. Considering the threshold configuration is per channel, we suggest that, in the RLF report, UE reports the used EDT value also per channel."

3. TDoc R3-231343 highlights the issues with reporting the exact value of EDT used for each LBT attempt, as it reveals UE implementation details and is also cumbersome to report for each LBT attempt. It also suggests that waiting time in UL due to LBT RSSI in RLF report is sufficient.

Example snippet from TDoc R3-231343 to support the difference: "Observation 3: Even if UE reports the average value of the EDT in each LBT attempt, it is not clear how this is useful at the gNB, considering different UE implementations might report different averaged EDT value and taking an average of these averaged EDT values doesn’t give much knowledge to the gNB Proposal 2: There is no need for UE to report any EDT value (exact value or average value) for optimizing UL LBT Waiting time in UL due to LBT RSSI in RLF report is sufficient."

TDoc R3-231204:

- Observation 1: COT of neighbour cells can reuse the existing COT IE, and corresponding semantics description needs to update.
- Proposal 10: Channel Occupancy Time Percentage By Neighbour Cells is a good option to transmit the NR-U resource status of neighbour cells for NR-U.
- Proposal 11: Agree the TP in Section 5.
- FFS whether to add in F1AP within the RESOURCE STATUS UPDATE message, a Channel Occupancy Time Percentage UL IE and/or an Energy Detection Threshold UL IE as sub-IEs of NR-U Channel Item IE.

(TP in Section 5 refers to the technical proposal in Section 5 of the TDoc)

TDoc R3-231690:

- Proposal 3: Add the measured RSSI and indication of SCG failure due to consistent LBT failure in the SCG failure information.
- Proposal 1: Add the average value of EDT in UL from the UE with consistent LBT failure in the RLF report.
- Proposal 2: Add the number of the LBT failure per BWP per RA procedure in the RA report.

TDoc R3-231743:

- Whether Cell B and Cell C can use a same NR-U channel depends on the UE LBT result and the UE distribution in the two cells.
- According to clause 5.21.2 of TS 38.321, the MAC entity detects the consistent LBT failure per UL BWP, via counting LBT failure indications for all UL transmissions from the low layers.
- Annex – TP for SON BLCR for XnAP: To exchange radio resource status and CAC per NR-U channel over Xn.
- The RLF report should include the LBT configurations.

Overall, these TDocs discuss various technical proposals related to optimizing the use of NR-U resources in cellular networks. Some of the key differences among the proposals include:

- Whether to include additional information (such as COT or EDT) in existing IEs or create new ones
- How to report failures related to LBT (listen-before-talk) procedures
- How to exchange radio resource status and CAC (call admission control) information between different nodes in the network
- Whether to allow multiple cells to use the same NR-U channel based on UE LBT results and distribution.

TDoc R3-231428:

- The receiving node may transfer the RLF report to the source node for MRO analysis
- Failure cause analysis and modification can be executed as legacy
- Including number of LBT failures in the RLF report can benefit network understanding of uplink channel situation

Example: "For the case that handover failure occurred due to BT failure, to enable network better know the uplink channel situation and detailed information of LBT process, it is beneficial to include number of LBT failures e.g. per RACH attempt or per RA procedure in the RLF report."

TDoc R3-231557:

- Some companies think it is useful for UE to send its own EDT in UL to network in order to optimize
- One bit indicator in RLF Report is already introduced to indicate the failure is caused by NR-U
- Open issue related to RLF report includes further enhancements for RLF report: addition of indications of number of consistent LBT failures and at which granularity

Example: "further enhancements for RLF report: addition to RLF report of indications of number of consistent LBT failures and at which granularity (e.g., per BWP)."

TDoc R3-231589:

- Radio Resource Status per NR-U Channel can help understand consumed radio resources for individual NR-U Channels
- Proposal to add new NR-U load metric, a Radio Resource Status IE per NR-U Channel

Example: "we propose to add as new NR-U load metric, a Radio Resource Status IE per NR-U Channel."

TDoc R3-231594:

- Proposal to extend the RLF report to include the average applied EDT value
- UE logs an RLF report when Random Access fails towards the target cell
- RLF report contains the same RA-InformationCommon IE that is also present in the RA report
- Proposal to address open point related to RLF report enhancement: “addition to RLF report of indications of number of consistent LBT failures and at which granularity (e.g., per BWP)”

Example: "we propose to extend the RLF report to include the average applied EDT value...it seems natural to address the open point related to RLF report enhancement: “addition to RLF report of indications of number of consistent LBT failures and at which granularity (e.g., per BWP)”, in a similar way as for the RA report enhancement."

TDoc R3-231590:

- Direction: NG-RAN node2 NG-RAN node1.
- SEQUENCE { nR-U-ChannelID NR-U-ChannelID, channelOccupancyTimePercentageDL ChannelOccupancyTimePercentage, energyDetectionThresholdDL EnergyDetectionThreshold, iE-Extension ProtocolExtensionContainer { {NR-U-Channel-Item-ExtIEs} } OPTIONAL, ... }
- NR-U-Channel-Item-ExtIEs XNAP-PROTOCOL-EXTENSION ::= { ... }
- TP for XnAP - Radio Resource Status per NR-U Channel
- NR-U-Channel-List ::= SEQUENCE (SIZE (1..maxnoofNR-UChannelIDs))

Example snippets:

- "Direction: NG-RAN node2 NG-RAN node1."
- "SEQUENCE { nR-U-ChannelID NR-U-ChannelID, channelOccupancyTimePercentageDL ChannelOccupancyTimePercentage, energyDetectionThresholdDL EnergyDetectionThreshold, iE-Extension ProtocolExtensionContainer { {NR-U-Channel-Item-ExtIEs} } OPTIONAL, ... }"
- "NR-U-Channel-Item-ExtIEs XNAP-PROTOCOL-EXTENSION ::= { ... }"
- "TP for XnAP - Radio Resource Status per NR-U Channel"
- "NR-U-Channel-List ::= SEQUENCE (SIZE (1..maxnoofNR-UChannelIDs))"

TDoc R3-231591:

- NR-U-Channel-List ::= SEQUENCE (SIZE (1..maxnoofNR-UChannelIDs)) OF NR-U-Channel-Item
- NR-U-Channel-Item ::= SEQUENCE { nR-U-ChannelID INTEGER(1..maxnoofNR-UChannelIDs), channelOccupancyTimePercentageDL ChannelOccupancyTimePercentage, energyDetectionThreshold EnergyDetectionThreshold, iE-Extensions ProtocolExtensionContainer { { NR-U-Channel-Item-ExtIEs} } OPTIONAL, ... }
- NR-U-Channel-Item-ExtIEs F1AP-PROTOCOL-EXTENSION ::= { ... }
- Direction: gNB-DU gNB-CU.

Example snippets:

- "NR-U-Channel-List ::= SEQUENCE (SIZE (1..maxnoofNR-UChannelIDs)) OF NR-U-Channel-Item"
- "NR-U-Channel-Item ::= SEQUENCE { nR-U-ChannelID INTEGER(1..maxnoofNR-UChannelIDs), channelOccupancyTimePercentageDL ChannelOccupancyTimePercentage, energyDetectionThreshold EnergyDetectionThreshold, iE-Extensions ProtocolExtensionContainer { { NR-U-Channel-Item-ExtIEs} } OPTIONAL, ... }"
- "NR-U-Channel-Item-ExtIEs F1AP-PROTOCOL-EXTENSION ::= { ... }"
- "Direction: gNB-DU gNB-CU."

TDoc R3-231592:

- NR-U-Channel-List ::= SEQUENCE (SIZE (1..maxnoofNR-UChannelIDs)) OF NR-U-Channel-Item
- NR-U-Channel-Item ::= SEQUENCE { nR-U-ChannelID NR-U-ChannelID, channelOccupancyTimePercentageDL ChannelOccupancyTimePercentage, energyDetectionThreshold EnergyDetectionThreshold, iE-Extension ProtocolExtensionContainer { {NR-U-Channel-Item-ExtIEs} } OPTIONAL, ... }
- NR-U-Channel-Item-ExtIEs XNAP-PROTOCOL-EXTENSION ::= { ... }
- Direction: NG-RAN node2 NG-RAN node1.
- TP for SON BL CR for XnAP in relation to NR-U metrics.

Example snippets:

- "NR-U-Channel-List ::= SEQUENCE (SIZE (1..maxnoofNR-UChannelIDs)) OF NR-U-Channel-Item"
- "NR-U-Channel-Item ::= SEQUENCE { nR-U-ChannelID NR-U-ChannelID, channelOccupancyTimePercentageDL ChannelOccupancyTimePercentage, energyDetectionThreshold EnergyDetectionThreshold, iE-Extension ProtocolExtensionContainer { {NR-U-Channel-Item-ExtIEs} } OPTIONAL, ... }"
- "NR-U-Channel-Item-ExtIEs XNAP-PROTOCOL-EXTENSION ::= { ... }"
- "Direction: NG-RAN node2 NG-RAN node1."
- "TP for SON BL CR for XnAP in relation to NR-U metrics."

3GPP-R3-119-bis-e    Agenda Item 10.2.6 : MDT Enhancements

3GPP-R3-119-bis-e    Agenda Item 11.1 : General

Technical Differences among TDocs

1. Option 3 vs Option 4:
- Option 3 allows the UE to continue measurements for only one configuration for a service type supported in LTE during HO from NR to LTE/5GC
- Option 4 allows the UE to keep and continue measurements for the ongoing configuration for a service type supported in NR during HO from LTE/5GC to NR
(TDoc R3-231110)

2. QoE Continuity:
- QoE continuity during HO between LTE/5GC and NR is done in the AS layer rather than APP layer, which may impact QoE measurement continuity in the application layer (TDoc R3-231110)

3. RAN Visible QoE Measurement:
- The gNB-CU may forward RAN visible QoE measurement reports from the UE to the gNB-DU in split gNB architecture (TDoc R3-231130)
- RAN visible QoE measurements are configured to the UE by the gNB, and a subset of configured QoE metrics is reported from the UE to the gNB as an explicit IE readable by the gNB (TDoc R3-231132)
- Multiple simultaneous RAN visible QoE measurement configurations and reports can be supported, and each is identified by the same RRC identifier as the QoE measurement configuration and measurement report (TDoc R3-231132)
- The PDU session ID(s) and the QoS Flow IDs corresponding to the service that is subject to QoE measurements can also be reported by the UE along with the RAN visible QoE measurement results (TDoc R3-231132)
- The UE Application layer can measure the RAN visible QoE metrics based on this reporting periodicity (TDoc R3-231132)

4. QoE Measurement Configuration:
- For Option 4, the target NR node decides whether to keep the ongoing QoE measurement and configures it in the NR RRC reconfiguration message included in MobilityFromNRCommand message
- For Option 3, the source NR node sends all the signalling based QoE measurement configuration container to target LTE node. When UE moves back to NR node, LTE node sends back all the signalling based QoE measurement configuration container to NR node. The target LTE node decides which QoE measurement will be kept and informs the source NR node of the decision. NR node then informs UE to release other QoE measurement and all the RAN visible QoE measurement in the NR format in MobilityFromNRCommand message. The target LTE node configures the QoE measurement to be kept in the LTE RRC connection reconfiguration message included in MobilityFromNRCommand message. (TDoc R3-231764)

Examples:
- According to TDoc R3-231110, Option 4 allows the UE to keep and continue measurements for the ongoing configuration for a service type supported in NR during HO from LTE/5GC to NR.
- TDoc R3-231132 states that multiple simultaneous RAN visible QoE measurement configurations and reports can be supported, and each is identified by the same RRC identifier as the QoE measurement configuration and measurement report.
- TDoc R3-231764 explains that for Option 3, the target LTE node decides which QoE measurement will be kept and informs the source NR node of the decision.

1. Difference: The source ng-NB provides QoE Configurations to the target gNB for inter-RAT QoE continuity indication.

- TDoc R3-231422: "The source ng-NB provides QoE Configurations to the target gNB [...] in XnAP Handover Request message."
- Impact on TS 38.331: "For the QoE measurement, the gNB provides the inter-RAT QoE continuity indication [...] received from OAM system or CN."

2. Difference: The target NR node configures QoE measurement in the NR RRC reconfiguration message to maintain QoE measurement.

- TDoc R3-231763: "For the QoE measurement to be kept, the target NR node configure this QoE measurement in the NR RRC reconfiguration message included in MobilityFromNRCommand message 5."
- TDoc R3-231775: "if one UE with an ongoing LTE QoE session handovers to a gNB, how would the application layer continue to collect the measurement results [...] since the XML file and AT command in LTE and NR are not encoded in the same way."

3. Difference: NR node informs UE to release other QoE measurement and all the RAN visible QoE measurement in the NR format.

- TDoc R3-231763: "NR node informs UE to release other QoE measurement and all the RAN visible QoE measurement in the NR format in MobilityFromNRCommand message."
- TDoc R3-231775: "Option B: Go straightly to the details we would handle, with the assumption that other WGs would provide the support for the QoE continuity of configuration/reporting and measurement in APP layer."

4. Difference: Option B suggests going straight to the details of QoE measurement without waiting for support for QoE continuity in APP layer.

- TDoc R3-231775: "At this meeting, it is better we decide whether to wait until further progress from other groups, or to go straightly to the details we would handle, with the assumption that other WGs would provide the support for the QoE continuity of configuration/reporting and measurement in APP layer."

3GPP-R3-119-bis-e    Agenda Item 11.3 : Support QoE for NR-DC

- TDoc R3-231217 proposes that if SRB3 is not configured when the SN receives a request to configure a UE with m-based QoE, the QoE configuration container should be included in the message to allow MN to send configuration information via SRB1.
- TDoc R3-231626 highlights a lack of clarity in the agreements regarding MN behavior when SN is interested in configuring a UE with m-based QoE measurement configuration and proposes RAN3 to clarify and adapt the agreements accordingly.
- TDoc R3-231776 proposes defining a new class-2 procedure between MN and SN to allow QoE configuration transfer and to inform SN of a UE configured with m-based QoE. It also proposes that a gNB can only configure QoE for a UE if it receives a request from the peer node in NR-DC.
- TDoc R3-231818 suggests that the network needs to send the QoE measurement ID to indicate the reporting leg of corresponding QoE measurement results will be switched. It also proposes that the node that configures the UE with QoE measurements should indicate the RRC ID to the peer node to consider when the peer node may receive QoE reports from the UE and forward them to the MCE.

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

- TDoc R3-231217: "In case SRB3 is still not configured [...] the SN should include the QoE configuration container also in the message so that MN is able to send the configuration information to the UE via SRB1."
- TDoc R3-231626: "the MN does not indicate explicitly to SN that it should not configure the UE."
- TDoc R3-231776: "Define a new class-2 procedure between MN and SN [...] to let MN inform SN a UE is configured with an m-based QoE."
- TDoc R3-231818: "For the switch, the network needs to send UE the QoE measurement ID."
- TDoc R3-231818: "the node that has configured the UE with QoE measurements should indicate the RRC ID to the peer node."

Technical Differences:

1. Proposal 12:
- A node configured with UE QoE measurements can indicate MCE IP address to the node receiving QoE reports from the UE and forwarding them to MCE.
- Supports direct forwarding of QoE reports to MCE.

2. Proposal 13:
- Only one common RVQoE measurement can be configured for the same QoE configuration by MN and SN.
- MN and SN can coordinate to configure a UE with an m-based QoE measurement.

3. Proposal 14:
- SN can send RVQoE configuration to UE via MN or SRB1.
- Stage-3 signaling for SN-initiated coordination needs discussion.

4. QoE Reference:
- MN can decide how to send the configuration information to the UE.
- SN can send configuration information to the UE directly or via MN inside a container.

5. WID Update:
- MN needs to notify SN how to send configuration information to the UE.
- Coordination procedure for UE configuration with an m-based QoE measurement.

6. Proposal 1:
- MN should inform SN about a UE configured with m-based QoE measurement via SN Addition Request or Modification Request message.

7. Proposal 7:
- SN can include QoE configuration and reporting configuration in RRC Transfer message if MN should send the QoE configuration.

Example Snippets from TDoc:

- "If a node has configured the UE with QoE measurements, and the other node is receiving the QoE reports from the UE and forwarding them directly to the MCE, then the node that has configured the UE with QoE measurements can indicate the MCE IP address to the node that receives the reports." (Proposal 12)

- "MN and SN can only configure one common (a single) RVQoE measurement for the same QoE configuration." (Proposal 13)

- "SN can send the RVQoE configuration to the UE as follows: Option 1: SN can send SN generated RVQoE configuration to MN over XnAP and MN sends a common RVQoE configuration over SRB1 to the UE Option 2: SN can send the RVQoE configuration over SRB3 after coordinating with MN." (Proposal 14)

- "For an m-based QoE configuration in the case SN is interested in configuring a UE with an m-based QoE measurement configuration, the MN can decide and notify the SN whether: The MN shall send the configuration information to the UE, or The SN should send the configuration to the UE directly, or The SN should send the configuration information to the UE via the MN (inside a container)." (QoE Reference)

- "MN needs to notify SN whether: The MN shall send the configuration information to the UE, or The SN should send the configuration to the UE directly, or The SN should send the configuration information to the UE via the MN (inside a container)." (WID Update)

- "MN should inform the SN that a UE is configured with m-based QoE measurement once it’s configured in the UE via SN Addition Request message, SN Modification Request message." (Proposal 1)

- "SN can include the QoE configuration including the reporting configuration from SN in RRC Transfer message." (Proposal 7)

Technical Differences Among TDocs:

1. Proposal 4: The SN may send the command via SRB3 or SRB1 vs. Proposal 5: Both MN and SN can command the UE to switch the reporting leg based on its overload status

- TDoc R3-231319 states that the SN may send the command to switch the reporting leg via SRB3 or SRB1, while Proposal 5 from the same TDoc suggests that both MN and SN can command the UE to switch the reporting leg based on its overload status.

Example snippet: "The SN may send the switching command to UE via SRB3 or SRB1" (TDoc R3-231319)

2. MN and SN Configuration for QoE Measurements and Radio Related Measurements

- TDoc R3-231319 and TDoc R3-231320 discuss the different configurations for QoE measurements and radio related measurements in NR-DC. The MN can decide and notify the SN whether the configuration information should be sent by MN, SN, or via MN inside a container. The SN can configure the UE for its received M-based QMC from OAM and inform the SN about the configuration without RRC ID. The MN then responds with the accept decision on the SN configuration with the allocated RRC ID.

Example snippet: "SN can configure the UE for its received M-based QMC from OAM and inform the SN about the configuration without RRC ID" (TDoc R3-231319)

3. RV-QoE Configuration Coordination

- TDoc R3-231320 and TDoc R3-231830 discuss the coordination of RV-QoE configuration between MN and SN, including sending RVQoE metrics to the other node during the RVQoE configuration coordination. The coordination procedure between MN and SN should be supported when MN and SN overload, the node which is overload should initiate the coordination procedure, and the peer node can admit the QoE measurements report according to its own uplink resource status.

Example snippet: "For NR-DC scenario, both the MN and SN need to generate the RVQoE configurations, so the available RVQoE metrics should be sent to the other node during the RVQoE configuration coordination" (TDoc R3-231830)

4. QoE Start/Stop Indication

- TDoc R3-231777 discusses the use of QoE start/stop indication to manage the start/end of MDT measurement collection, to achieve the time alignment of MDT and QoE. The UE can send QoE start/stop indication to both the MN and the SN in the case that the m-based MDT measurements in both the MN and the SN are to be aligned with the same QoE measurement.

Example snippet: "For the case that the MDT measurements in both the MN and the SN are to be aligned with the same QoE measurement job, the UE can send QoE start/stop indication to both nodes" (TDoc R3-231777)

Overall, the TDocs highlight the various configurations and coordination procedures for QoE measurements and radio related measurements in NR-DC, as well as the use of QoE start/stop indication to achieve time alignment of MDT and QoE.

3GPP-R3-119-bis-e    Agenda Item 11.4 : Left-over from R17

Summary of technical differences among TDocs:

- Event-based RVQoE reporting trigger: TDoc R3-231489 discusses the possibility of configuring the UE to send RVQoE metrics around the same time as radio events occur, which could be used to optimize mobility decisions. It also suggests options for stopping trigger-based RVQoE reporting. TDoc R3-231762 discusses the granularity of priority for QoE measurements and the possibility of introducing event-based triggers, but notes that the benefit may not be worth the additional complexity. TDoc R3-231779 suggests that DU, as the consumer of RVQoE reports, should have a say in the configuration of RVQoE and proposes that assistance information for QoE reporting upon RAN overload should include priorities for different QoE measurement configurations.
- OAM assistance information: TDoc R3-231779 and TDoc R3-231831 both discuss the handling of QoE reporting upon RAN overload and suggest that assistance information should be sent to the RAN together with QoE measurement configuration. TDoc R3-231779 proposes that the OAM generates the assistance information, while TDoc R3-231831 notes the importance of considering different service types and slices when configuring QoE reporting priority.
- QoE reporting priority: TDoc R3-231831 emphasizes the importance of guaranteeing high priority users and slices when network resources are scarce and suggests that QoE reporting priority can be used to control QoE reporting storage and transfer.

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

- TDoc R3-231489: "If the gNB could configure the UE to also send the RVQoE metrics observed in the 'time vicinity' of one of the above radio related events...the gNB could use this information as a tool for optimizing the mobility decisions based on such events." "In case of threshold-based trigger, RAN sends to the UE (in the RVQoE configuration) some parameter that will guide the UE to stop sending RVQoE reports."
- TDoc R3-231762: "Setting the granularity of priority as such can avoid mess and confusion when there are multiple consumers." "We still don’t think the benefit of introducing such triggers is overwhelming, considering the additional complexity it will introduce and the small size of QoE report." "The assistance information is the priority for each QoE measurement."
- TDoc R3-231779: "For the RVQoE configuration and reporting, it is reasonable that DU, as the consumer of the RVQoE report, can have a say on the configuration of RVQoE." "In R18, the assistance information is the priorities of different QoE measurement configurations, and it could be generated by the OAM and sent to RAN node."
- TDoc R3-231831: "The network should guarantee the high priority users and slices when the network resource are scarcely." "As the QoE measurement configuration is initiated by OAM, gNB can transfer the QoE reporting according to service priority to guarantee the QoE reporting transfer for high priority QoE measurements as much as possible." "QoE reporting priority can be used to control the QoE reporting storage and QoE reporting."

Technical differences among the TDoc snippets:

1. TDoc R3-231123 discusses the concepts, use cases, and requirements for quality of experience (QoE) measurement collection, as well as specific functions that have been approved for management-based and signaling-based QoE measurement collection in NR. It also includes information on available RAN visible QoE metrics and alignment of MDT information.
Example from TDoc R3-231123: "The functions that are approved are: Management Based QoE Measurement Collection (QMC) for NR including attributes for activation and Deactivation of QMC."

2. TDoc R3-231123 references 3GPP TS 28.405, which covers control and configuration of QoE measurement collection.
Example from TDoc R3-231123: "3GPP TS 28.405: 'Telecommunication management; Quality of Experience (QoE) measurement collection; Control and configuration'."

3. TDoc R3-231627 proposes two options for sending deactivation indications for QoE information transfer via the gNB-DU and gNB-CU in the F1 interface. It also includes information on unsuccessful operation and how to respond with appropriate cause values.
Examples from TDoc R3-231627: "Option 1: The gNB-DU sends deactivation indication using the F1 Setup procedure." "Upon reception of the deactivation indication from the gNB-DU, the gNB-CU, will not trigger the F1AP QoE Information Transfer procedure for the concerned F1-C interface instance." "If the gNB-CU cannot accept the setup, it should respond with a F1 SETUP FAILURE and appropriate cause value."

4. TDoc R3-231627 proposes deactivation of RAN visible QoE information transfer via F1 and includes an introduction to the proposal.
Example from TDoc R3-231627: "Introduce the deactivation of RAN visible QoE information transfer via F1."

Technical Differences among TDocs:

1. Triggering of RVQoE reporting based on buffer level can be handled by either APP layer or AS layer.
- RAN2 prefers APP layer handling.
- With AS layer triggering, APP layer provides RVQoE measurements reports to AS layer according to the configured reporting periodicity, and the AS layer reports to gNB.
- With APP layer triggering, APP layer provides RVQoE measurements reports to AS layer when the measured buffer level satisfies a buffer level threshold, and the AS layer reports to gNB the RVQoE measurements received from the APP layer.

2. Discussion on using a class-1/class-2 message and whether to reuse an existing message or define a new message for gNB-DU participation in assembling the RVQoE configuration.
- gNB-DU would participate in assembling the RVQoE configuration by proposing periodicity for RVQoE reporting or the list of interested RVQoE metrics.
- gNB-CU would have the final say in the RVQoE configuration.

3. Event-based triggers for RAN visible QoE would introduce higher UE complexity.
- Proposal to not introduce event-based triggers and report RVQoE only during handover or when radio quality is less than a threshold.

4. gNB-CU can decide whether to deactivate the QoE information transfer based on the need information from gNB-DU.
- Proposal for gNB-CU to take control of deactivating QoE information transfer instead of gNB-DU.
- Introduction of a class 2 procedure of QoE information requirement status initiated by gNB-DU to indicate whether or not QoE information is needed.
- Introduce deactivation of RAN visible QoE information transfer via F1.

Examples from the original TDocs:

- "RAN2 prefers APP layer handling."
- "gNB-DU would participate in assembling the RVQoE configuration by proposing periodicity for RVQoE reporting or the list of interested RVQoE metrics."
- "Proposal to not introduce event-based triggers and report RVQoE only during handover or when radio quality is less than a threshold."
- "Proposal for gNB-CU to take control of deactivating QoE information transfer instead of gNB-DU."
- "Introduce deactivation of RAN visible QoE information transfer via F1."

3GPP-R3-119-bis-e    Agenda Item 12.1 : General

3GPP-R3-119-bis-e    Agenda Item 12.2.1 : Stage2 Related

• The TDoc proposes a new procedure over Xn for reporting AI/ML related information, such as predicted information.
• The procedure should be based on a requested way, similar to the resource status report procedure.
• The proposed wording for the procedure is "data type agnostic," meaning that the intended use of the requested data should not be indicated in the procedure.
• Proposal 1 suggests reformulating the WA to state that the intended use of the data should not obstruct its usage for any AI/ML purpose the requesting node considers appropriate.
• There are two ways to indicate the start and end time of the prediction information - an explicit and implicit manner.
• The requesting node can send an AI/ML INFORMATION REQUEST message with the Registration Request IE set to "start" to indicate the start time of the prediction information.
• The end time of the prediction information can be based on the implementation of the requesting node, and the requesting node can send another AI/ML INFORMATION REQUEST message with the Registration Request IE set to "stop" to stop transmission after sufficient duration.
• If the requesting node decides to reject the prediction information, it can indicate initiation failure of the agreed new class 1 procedure with the AI/ML INFORMATION FAILURE.
• The requested node can be configured in the AI/ML INFORMATION REQUEST to stop transmission after transferring the prediction information that meets the requested time.
• The prediction accuracy can only be calculated by obtaining the ground truth in the prediction time.
• The TDoc mentions "predicted beam index," but it is not clear how it differs from other examples in the document.

- Proposal 1 suggests that procedures used for AI/ML support in the NG-RAN should be "data type agnostic" and not indicate the purpose for which data is requested.
- Model training and inference at the NG-RAN and OAM/RAN differ only in the procedures for exchanging training and feedback data.
- Procedures used for AI/ML support in the NG-RAN should be use case agnostic.
- The new procedure over Xn used for AI/ML information should be use case agnostic and data type agnostic.
- The main open issue with the new procedure is what other information can be included/transferred, in addition to predicted information.
- The same procedure flow is used for AI/ML training, inference, and transfer of predicted and feedback information.
- The procedures used for AI/ML support in the NG-RAN shall be "data type agnostic," meaning there is no need to distinguish AI/ML related data types with separate procedures.
- Proposal 3 suggests clarifying in TS38.300 that the new agreed procedure can be used to request predicted or feedback information as input, output, and feedback.

Examples from the TDoc to support these differences include discussion of open issues related to the new procedure for exchanging AI/ML information, the distinction between model training and inference procedures used at different nodes, and the need for use case and data type agnostic procedures for AI/ML support. Additionally, there is discussion of the flow of procedures used for AI/ML training, inference, and feedback transfer, and the need to clarify the use of the new procedure in TS38.300.

3GPP-R3-119-bis-e    Agenda Item 12.2.2 : Stage3 Related

3GPP-R3-119-bis-e    Agenda Item 12.2.2.1 : LB and Xn procedures

- The node only needs to collect UE performance a period of time after handover, no need for periodical reporting (R3-231205).
- Accuracy parameter provided as reference for receiving node to adjust decision-making (R3-231205).
- Requested node can indicate which part of the request prediction item it can provide in response message (R3-231205).
- Trigger indication in HO request message to request UE performance feedback after HO completion (R3-231205).
- Measurement ID used as common identifier between Class1 AI/ML message and Handover Request message (R3-231260).
- Requesting NG-RAN node indicates required prediction accuracy, with corresponding accuracy provided for each required resource status indicator prediction (R3-231433).
- Periodicity value and time window conveyed in prediction request message to indicate validity time of requested periodic prediction information (R3-231433).
- Indication needed in UE performance feedback request message for neighbour gNB to understand information should be collected after handover, not immediately (R3-231434).
- Time and periodicity for prediction reporting should be supported (R3-231465).
- Accuracies are ideally not constants (R3-231465).
- Node performing model training needs to constantly decide whether to retrain and update AI model based on real-time performance feedback (R3-231515).
- Validity time of prediction information can be deduced from timing information provided in request message, no need to explicitly indicate validity time (R3-231515).

Examples:
- "E,g. for the HO-ed UEs due to AI/ML related energy saving decision, the node only needs to collect the UE performance a period of time after the HO, so there is no need to request the periodical reporting." (R3-231205)
- "Regarding to the procedure, after receiving the request from requesting node, the requested node finds it can only provide part of the request prediction item and it can indicate the item which it can provide in the response message." (R3-231205)
- "Introduce a trigger indication in the HO request message to indicate that UE performance feedback is requested after HO completion." (R3-231205)
- "Measurement ID to be used as a common identifier between Class1 AI/ML message requesting feedback and in the Handover Request message." (R3-231260)
- "A periodicity value together with a time window (e.g., represented by start/end time stamps) could be conveyed in the prediction request message to indicate the validity time of the requested periodic prediction information." (R3-231433)
- "In the UE performance feedback request message, i.e., AI/ML INFORMATION REQUEST, an indication is needed for the neighbour gNB to understand the requested information should be collected after some UE is handed over to the neighbour gNB, instead of immediately after the neighbour gNB responds to the request (e.g., Energy Cost or Resource Status Prediction)." (R3-231434)
- "Assume that the time to report prediction is and the periodicity is , Either of the following two bullets should be supported: - In addition to the one for till , the one for till or even further is also provided; - The validity duration is longer than the period, e.g. the prediction is for till ." (R3-231465)
- "Once a AI model is trained, its accuracy rate on the data set is unchanged, but over time, the model's performance in real scenario may deteriorate (due to real-time data changes, resulting in a larger gap with the test set), so for the node performing model training (e.g. NG-RAN or OAM), it needs to constantly decide whether to retrain and update the AI model based on the real time performance feedback." (R3-231515)

Technical Differences:

1. Successful Operation

In TDoc R3-231209 and R3-231469, successful operation is described in the same way. The NG-RAN node1 initiates the AI/ML Information Reporting Initiation procedure by sending an AI/ML INFORMATION REQUEST message to NG-RAN node2. If NG-RAN node2 is capable of providing the requested information, it responds with an AI/ML INFORMATION RESPONSE message.

Example from TDoc R3-231469: "If NG-RAN node2 is capable to provide of requested information, it shall initiate the AI/ML related information reporting as requested by NG-RAN node1 and respond with the AI/ML INFORMATION RESPONSE message."

2. Abnormal Conditions

In both TDoc R3-231209 and R3-231469, abnormal conditions are described as FFS (Future Feature Support). No further details or examples are provided.

Example from TDoc R3-231209: "8.4.AA.4 Abnormal Conditions FFS"

3. Reporting of AI/ML Information

TDoc R3-231209 introduces a procedure called AI/ML Information Reporting Initiation, which is initiated by an NG-RAN node to start AI/ML related information reporting and stop AI/ML related information reporting. TDoc R3-231469 further elaborates that if all the requested AI/ML related information reporting cannot be initiated, NG-RAN node2 sends an AI/ML INFORMATION FAILURE message with an appropriate cause value.

Example from TDoc R3-231209: "Figure 8.4.AA.2-1: AI/ML Information Reporting Initiation, successful operation"

Example from TDoc R3-231469: "If all of the requested AI/ML related information reporting cannot be initiated, NG-RAN node2 shall send the AI/ML INFORMATION FAILURE message with an appropriate cause value."

4. Partial Reporting of AI/ML Information

TDoc R3-231209 introduces a document titled "TP to 38.423 for partial reporting of AI/ML information." No further details or examples are provided in this TDoc.

Example from TDoc R3-231209: "Title: TP to 38.423 for partial reporting of AI/ML information"

5. Cause IE

TDoc R3-231681 introduces the Cause IE, which indicates the reason for a particular event for the XnAP protocol.

Example from TDoc R3-231681: "9.2.3.2 Cause The purpose of the Cause IE is to indicate the reason for a particular event for the XnAP protocol."

6. Small Data Transmission Procedures

TDoc R3-231209 introduces the Small Data Transmission procedures, which enable the exchange of information between NG-RAN nodes for SDT transmission without anchor relocation.

Example from TDoc R3-231209: "6.2.12 Small data transmission procedures - Partial UE Context Transfer: enables exchange of information between NG-RAN nodes for SDT transmission without anchor relocation"

7. QMC Support Procedures

TDoc R3-231209 mentions that QMC support procedures also support small data transmission, but no further details or examples are provided.

Example from TDoc R3-231209: "6.2.13 QMC support procedures"

8. UE Slice-Maximum Bit Rate List IE

TDoc R3-231796 introduces the UE Slice-Maximum Bit Rate List IE, which is contained in HANDOVER REQUEST messages. The target NG-RAN node stores the received UE Slice Maximum Bit Rate List in the UE context, and uses the received UE Slice Maximum Bit Rate value for each S-NSSAI for the concerned UE as specified in TS 23.501.

Example from TDoc R3-231796: "If the UE Slice-Maximum Bit Rate List IE is contained in HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the received UE Slice Maximum Bit Rate List in the UE context, and use the received UE Slice Maximum Bit Rate value for each S-NSSAI for the concerned UE as specified in TS 23.501 [7]."

Proposal 2 suggests exchanging predicted radio parameters, including TNL capacity indicator, slice available capacity, and composite available capacity group, between neighboring NG-RANs in predicted resource status information. This was discussed in RAN3#118 and can be reported in the new procedure for AI/ML Related Information. Proposal 3 allows OAM to configure the threshold for triggering predicted radio status reporting, which requires a higher level of node to configure the NG-RAN.

If the Source DL Forwarding IP Address IE is included in the Data Forwarding and Offloading Info from source NG-RAN node IE in the PDU Session Resources To Be Setup List IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall store and use it as part of its ACL functionality configuration actions. The target NG-RAN node may also forward the UP transport layer information to the target S-NG-RAN node if the Additional UL NG-U UP TNL Information List IE is included in the PDU Session Resources To Be Setup List IE, and may use the Estimated Arrival Probability IE to allocate resources for incoming CHO.

UE performance feedback configuration can be done by AI/ML information request message, with the bit in Report Characteristics IE used as implicit indication. It can also support partial reporting if the measured/predicted information request and UE performance feedback are configured in the same message. Proposals 2 and 3 can be used together, with the requested node transferring specific UE performance measurement data to the requesting node in the agreed new class 2 procedure (AI/ML INFORMATION UPDATE message), with partial reporting support implicitly indicated through the set of successfully performed measurements.

- Proposal to add an Event Index IE in the AI/ML INFORMATION REQUEST message to identify the handover events that trigger UE Performance Feedback reporting
- Partial reporting mechanism to allow successful procedure even if reporting node cannot provide all requested information or configuration
- Introduction of Request Type IE in request message to clarify if feedback information after UE handover is needed
- Indication of model invalidity and possibility of sending predicted information through new model
- Proposal to include timing information in prediction requests, including start time and end time or start time and duration
- Proposal to provide prediction accuracy to requesting node for better decision-making

3GPP-R3-119-bis-e    Agenda Item 12.2.2.2 : ME and Xn procedures

Technical Differences Highlighted in TDoc Snippets:

- The current status based decision cannot accurately predict UE performance, and instead, the node should select a target cell that can provide equal or better QoS performance than the UE application requires.
- Exchanging predicted UE traffic information can help the node accurately predict traffic volume and improve resource allocation during mobility.
- UE trajectory feedback should be sent to the source cell when the serving and source NG-RAN nodes do not have an Xn interface, and the actual time of stay should be included in the feedback message to optimize the UE AI/ML model.
- After successful handover, the source gNB only needs to maintain identification information of the concerned UE to understand the future UE trajectory provided by the target gNB.
- It is proposed to include the time length during which the source NG-RAN keeps UE context in the handover request message when triggering UE performance feedback.
- A new introduced class-1 message can be used to pre-configure required information to candidate target nodes and confirm in response whether the peer node can provide the requested information.
- UE history information can be used to check the correctness of trajectory predictions.
- Even with strict data management policies, certain similarities between training and testing datasets from the same source can impact prediction accuracy.
- Each RAN node employing predictions from other sources should compute the performance of the predictions.
- The presence of the predicted time of stay of a UE in a cell is not guaranteed.
- The target NG-RAN node may use the Estimated Arrival Probability IE to allocate necessary resources for incoming CHO.
- The source NG-RAN node should not prepare more candidate target cells for a CHO for the same UE toward the target NG-RAN node than the number indicated in the Maximum Number of CHO Preparations IE.

Overall, these snippets highlight technical differences related to UE performance prediction, UE trajectory feedback, handover execution timing, and prediction accuracy. They also suggest proposals to optimize UE AI/ML models and improve handover decisions, such as pre-configuration of required information and computation of prediction performance.

Technical Differences among TDocs:

1. Observation on UE Trajectory Prediction:
- TDoc R3-231658 highlights that input data on a cell-level are sufficient to train the ML model for UE Trajectory prediction.
- TDoc R3-231799 mentions that the feedback of actual UE Trajectory is useful to test and update a model.

2. Cell-Based UE Trajectory:
- TDoc R3-231658 proposes cell-based UE Trajectory prediction, provided as a list of cells into the future, each with an expected time of stay into the cell.
- TDoc R3-231799 states that with the information of both predicted cell ID and time stay in the cell, the target node could better prepare resources for the upcoming UE.

3. Accuracy of Predicted UE Trajectory:
- TDoc R3-231683 mentions two methods for the source NG-RAN node to understand the accuracy of its predicted UE trajectory.
- TDoc R3-231799 states that without the information of predicted time of stay in a cell, the value of predicted UE trajectory information is limited.

4. UE Context Implementation:
- TDoc R3-231683 proposes an implementation to keep the UE context between the source and target NG-RAN nodes, if the UE trajectory feedback is requested from the source NG-RAN node.
- The procedure mentioned in TDoc R3-231825 uses UE-associated signalling and includes various IE (Information Elements) in the HANDOVER REQUEST message.

Example Snippets from the Original TDocs:

- TDoc R3-231658: "Since UE Trajectory prediction is calculated as a sequence of cells into the future, input data on a cell-level are sufficient to train the ML model."
- TDoc R3-231658: "Cell-based UE Trajectory prediction, provided as a list of cells into the future, each of which is indicated together with an expected time of stay into the cell, can be sent in Handover Request message for AI/ML Mobility Optimization."
- TDoc R3-231683: "The source NG-RAN node can directly obtain the accuracy value from the target NG-RAN node, which is calculated by the target node based on the received UE trajectory."
- TDoc R3-231799: "Majority companies deemed the feedback of actual UE Trajectory is useful to test and update a model."
- TDoc R3-231825: "If the Index to RAT/Frequency Selection Priority IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall store this information and use it as defined in TS 23.501."

TDoc R3-231468:

- iABResourceCoordination, retrieveUEContextConfirm, and cPCCancel are XNAP-ELEMENTARY-PROCEDUREs with different PROCEDURE CODEs and CRITICALITY levels.
- iABResourceCoordination has a mandatory PRESENCE, while the other two procedures have optional PRESENCE.
- UEContextRefAtSN-HORequest has a TYPE of UEContextRefAtSN-HORequest and a CRITICALITY of ignore, with optional PRESENCE.
- CHOinformation-Req has a TYPE of CHOinformation-Req and a CRITICALITY of reject, with optional PRESENCE.
- NRV2XServicesAuthorized has a CRITICALITY of ignore and optional PRESENCE.
- LTEV2XServicesAuthorized has a CRITICALITY of optional and optional PRESENCE.

[TDoc R3-231468] Example snippets:

- "iABResourceCoordination XNAP-ELEMENTARY-PROCEDURE ::={ INITIATING MESSAGE IABResourceCoordinationRequest SUCCESSFUL OUTCOME IABResourceCoordinationResponse PROCEDURE CODE id-iABResourceCoordination CRITICALITY reject }"
- "retrieveUEContextConfirm XNAP-ELEMENTARY-PROCEDURE ::={ INITIATING MESSAGE RetrieveUEContextConfirm PROCEDURE CODE id-retrieveUEContextConfirm CRITICALITY ignore }"
- "cPCCancel XNAP-ELEMENTARY-PROCEDURE ::={ INITIATING MESSAGE CPCCancel PROCEDURE CODE id-cPCCancel CRITICALITY ignore }"
- "{ ID id-UEContextRefAtSN-HORequest CRITICALITY ignore TYPE UEContextRefAtSN-HORequest PRESENCE optional }"
- "{ ID id-CHOinformation-Req CRITICALITY reject TYPE CHOinformation-Req PRESENCE optional }"
- "{ ID id-NRV2XServicesAuthorized CRITICALITY ignore TYPE NRV2XServicesAuthorized PRESENCE optional }"
- "{ ID id-LTEV2XServicesAuthorized CRITICALITY ignore TYPE LTEV2XServicesAuthorized PRESENCE optional }"

[TDoc R3-231651]:

- PriorityLevelQoS is an INTEGER with a range of 1 to 127 and beyond.
- The example snippet does not provide any technical differences from other TDdocs.

[TDoc R3-231651] Example snippet:

- "PriorityLevelQoS ::= INTEGER (1..127, ...)"

3GPP-R3-119-bis-e    Agenda Item 12.2.2.3 : ES and Xn procedures

Summary of Technical Differences among TDoc:

1. Energy Efficiency vs Energy Cost: The TDoc R3-231207 introduces the concept of Energy Cost (EC) as an AI/ML metric to be shared over the Xn interface among gNBs, replacing the Energy Efficiency metric. This is done to evaluate the actual energy consumption of neighbor nodes and realize global evaluation.

2. Requesting Additional Energy Cost: To support the procedure of requesting additional energy cost, the source gNB should also indicate the associated additional traffic load to the target gNB. The target gNB CU can coordinate with the corresponding DU to better understand the current situation and make better inferences.

3. Providing Cell Level Information: Providing cell level information to the neighbor gNB helps in better inferring the additional energy cost. This is because if the network energy saving decision is to switch off one cell of source gNB and handover UEs to another cell of target gNB, the inferred additional energy cost is essentially about the increased energy cost of that cell.

4. Useless AI/ML Method: The TDoc R3-231466 highlights that AI/ML is useless and inaccurate for the offloading target node to generate the predicted delta EC before offloading takes place, as the offloading target node has too little information on what sessions are to be offloaded.

Examples from TDoc:

1. TDoc R3-231207: "The energy saving cell can not set the decision or evaluate the decision based on such node-level info, since the main factor to affect the energy efficiency is coming from the not-in-neighbour cells."

2. TDoc R3-231437: "To support above mentioned procedure, when requesting the additional energy cost, the source gNB should also indicate the associated additional traffic load to the target gNB."

3. TDoc R3-231437: "On the other hand, we see some benefits to provide cell level information for the neighbour gNB to better infer the additional energy cost."

4. TDoc R3-231466: "Observation 1: AI/ML is useless and as inaccurate as non-AI/ML method for the offloading target node to generate the predicted delta EC before the offloading take place, because the offloading target node has too little information on what sessions are to be offloaded."

TDoc R3-231617:

- Proposes that inferred energy consumption related to an additional load consists of the node level predicted EC the NG-RAN node would have if the additional load was added to its current load.
- Introduces the notion of offloading traffic from NG-RAN node 1 to NG-RAN node 2 as a ratio or percentage of the load currently sustained by the source cell.
- Supports a procedure in which an NG-RAN node can indicate a planned energy saving action and request another NG-RAN node to report the expected EC subject to the execution of that action.
- Figure 1 illustrates the basic principle of exchanging predicted energy cost assuming an additional load will be transferred from one NG-RAN node to another.

TDoc R3-231620:

- Introduces the AI/ML INFORMATION REQUEST message as part of the AI/ML Information Reporting Initiation procedure.
- Describes the event configuration and event reporting configuration in the context of AI/ML information reporting.
- Provides a baseline for further work.

TDoc R3-231801:

- Proposes that if a source node sends an additional load value, the target can provide a predicted value based on its inference on the increased energy consumption value if it takes the additional load from the source node.
- Introduces the metric of energy cost (EC) as the AI/ML metric to be shared over the Xn interface among gNBs.
- Proposes option 4 to deliver both data volume and energy consumption over RAN interfaces to let the requesting node calculate the overall DV and over EC of the specific area and thereby drive the overall EE.

TDoc R3-231812:

- Notes that simply exchanging ECs on the Xn interface does not allow us to evaluate how much impact the AI/ML energy saving function affected on reducing the total energy consumption of neighboring nodes.
- Discusses the need for the core network to generate the policy for normalization of EC and how to evaluate the total performance of the energy saving function.
- Describes the three AI/ML models needed for the energy saving function and provides a diagram illustrating the AI/ML energy saving procedure.

- The Energy Efficiency metric should take into account the cell performance, which is the accumulation of all UEs in this cell, e.g. total UL/DL throughput, total packet delay and total packet loss.
- Introducing the metric of Energy Cost (EC) as the AI/ML metric to be shared over the Xn interface among gNBs.
- The NG-RAN node should exchange the total UE performance over Xn interface to the neighbour NG-RAN node.
- The target NG-RAN node shall store the received UE Slice Maximum Bit Rate List in the UE context if supported.
- Node-level EC metric may not be capable of accurately reflecting the impacts of an AI/ML Energy Saving action at a network node.
- Introducing the metric of energy cost (EC) as the AI/ML metric to be shared over the Xn interface among gNBs.
- Providing the current/predicted energy to the node who generate the energy decision directly can improve the accuracy of AI/ML based energy decision.
- The EC metric can be either an energy consumption value resulting from an AI/ML inference and related to an additional load that a certain NG-RAN node is requested to manage or an actual energy consumption value from a neighbour node related to the current or additional load that such node is handling.

Example snippets from the original TDoc to support the difference highlighting:
- "Regarding the UE performance (e.g, UL/DL throughput, packet delay, packet loss), since the AI/ML focuses on the network energy saving efficiency, the Energy Efficiency metric should take into account the cell performance."
- "Introduce the metric of Energy Cost (EC) as the AI/ML metric to be shared over the Xn interface among gNBs."
- "The NG-RAN node should exchange the total UE performance over Xn interface to the neighbour NG-RAN node."
- "If the UE Slice-Maximum Bit Rate List IE is contained in HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the received UE Slice Maximum Bit Rate List in the UE context."
- "Node-level EC metric may not be capable to accurately reflect the impacts of an AI/ML Energy Saving action at a network node."
- "To push the progress of AI/ML based energy saving and avoid discuss the sensitive information over Xn interface, it was agreed to introduce the metric of energy cost (EC) as the AI/ML metric to be shared over the Xn interface among gNBs."
- "Providing the current/predicted energy to the node who generate the energy decision directly can improve the accuracy of AI/ML based energy decision."
- "The EC metric can be either an energy consumption value resulting from an AI/ML inference and related to an additional load that a certain NG-RAN node is requested to manage, or an actual energy consumption value from a neighbour node related to the current or additional load that such node is handling in a certain point in time."

3GPP-R3-119-bis-e    Agenda Item 12.2.2.4 : Other interfaces

3GPP-R3-119-bis-e    Agenda Item 12.3 : Others

- Proposal 1 suggests focusing on necessary information (i.e. UE location) from MDT instead of all measurements to avoid unnecessary burden for the UE.
- The existing mechanism does not support transferring logged info from connected gNB to the last serving gNB.
- WA from RAN3 119 meeting states that there are benefits in enabling UEs to continuously collect MDT measurement across RRC states for AI/ML training/retraining.
- Observation 6 notes a time gap between logged MDT collection and immediate MDT collection when the UE transitions from idle to connected state.
- Observation 2 states that continuous collection of MDT traces across RRC states is not beneficial in RAN because it lacks the ability to identify the UE across RRC state transition from idle to connected.
- TDoc R3-231355 suggests that the existing framework allows OAM to use signalling-based MDT to configure immediate and logged MDT towards the same UE respectively for different trace sessions.
- Some companies argue that consecutive MDT data series are needed for successful AI/ML (re-)training.
- No new parameters over Uu interface are identified yet during SI phase for AI/ML (re-)training, so existing MDT procedure parameters can already satisfy required input.
- For proper AI model training to predict future UE trajectory, the training data set should include the actual UE trajectory in the future.
- For monitoring cell level UE trajectory prediction, it's enough to send the list of cells UE camped on during RRC inactive/idle to the old NG-RAN node.
- Inter-gNB future UE trajectory prediction benefits from old NG-RAN node understanding visited cells of UE during RRC inactive/idle state.
- Source gNB can provide UE trajectory prediction result in HANDOVER REQUEST message to target gNB during handover procedure.

Examples from TDoc R3-231208:
- "The existing mechanism does not support the logged info transferring from connected gNB to the last serving gNB."
- "WA: There are the benefits in enabling UEs to continuously collect MDT measurement across RRC states and to provide to the network such continuous time series of data for the purpose of AI/ML Training/Retraining."
- "The existing MDT configuration contains report interval, report amount."

Examples from TDoc R3-231261:
- "Observation 6: With or without continuous MDT indication carried by the UE, there is a time gap between logged MDT collection and immediate MDT collection during which MDT is not logged by the UE, when the UE transitions to connected state from idle."
- "Observation 2: As RAN lacks the ability to identify the UE across RRC state transition from Idle to Connected, continuous collection of MDT traces across RRC states will not be beneficial in RAN."

Examples from TDoc R3-231355:
- "This is not the truth, however, since the existing framework already allows OAM to use the signalling-based MDT to configure both immediate MDT and logged MDT towards the same UE respectively with different trace sessions (see TS 32.421), where immediate MDT takes effect for active state while logged MDT for inactive/idle state."
- "During the SI phase, there had been some discussions on whether new parameters over Uu interface are needed for model (re-)training, but no new parameters have been identified yet, which means that the existing parameters collected via the MDT procedure can already satisfy the required input for AI/ML model (re-)training."

Examples from TDoc R3-231439:
- "For monitoring the cell level UE trajectory prediction, it’s enough to send the list of cells UE camped on during RRC Inactive/Idle to the old NG-RAN node."
- "Besides, during handover procedure, the source gNB can provide the UE trajectory prediction result in the HANDOVER REQUEST message to the target gNB."

TDoc R3-231604:

- The AI/ML training function must interpret measurements from different UEs with respect to the capabilities of the UE that generates them.
- Measurements from two UEs under the same conditions may report different values, which creates a problem at model training level.
- The UE can indicate to the RAN to configure it with Immediate MDT.

Example from TDoc: "This indication can be flagged by the UE when the UE moves to RRC Connected again, so to give the possibility to the RAN to configure the UE with Immediate MDT."

TDoc R3-231660:

- Cell-based UE trajectory prediction is used instead of detailed location information.
- The MDT framework enables continuous measurement series by linking Immediate MDT data and Logged MDT data across RRC states.
- Data collection may pose signaling overhead in a network.

Example from TDoc: "If a UE is transitioning among RRC connected and RRC idle/inactive states within the same NG-RAN node, based on the provided MDT session references, the current MDT framework therefore enables the network to constitute a continuous (uninterrupted) measurement series by linking the Immediate MDT data and the Logged MDT data."

TDoc R3-231676:

- Companies propose configuring Immediate MDT and Logged MDT together to support continuous MDT.
- The management MDT may not be suitable for AI purposes.

Example from TDoc: "According to the above analyze, we slightly prefer the option 1, which have less impact and can support the multiple MDT configurations propagation. But from our understanding, the intention of management MDT is to collect the measurement result for a specified area scope. The intention of management MDT is to collect the measurement result for a specified area scope, may not suitable for AI purpose."

TDoc R3-231842:

- The current MDT mechanism is unable to collect input information for AI/ML model training and inference.
- Incorporating fine-grained input information, such as UE geographic location, would improve UE trajectory prediction accuracy.
- Introducing an indication in the logged MDT measurement configuration to indicate UE to let UE collect measurement across various RRC state is a simple solution.

Example from TDoc: "Proposal 7: Introducing an indication in the logged MDT measurement configuration to indicate UE to let UE collect measurement across various RRC state is the most straightforward and simple solution with minor standard impact."

The technical differences between TDoc R3-231605 and TDoc R3-231843 are as follows:

1. Purpose:
- TDoc R3-231605 is focused on defining constant definitions.
- TDoc R3-231843 is focused on enhancing MDT (Minimization of Drive Tests) configuration for continuous data collection.

Example snippet from TDoc R3-231605: "9.4.7 Constant Definitions"

Example snippet from TDoc R3-231843: "9.3.1.169 MDT Configuration-NR"

2. Content:
- TDoc R3-231605 includes constant definitions for various protocol IE-IDs such as target home ENB ID, early measurement, and beam measurements report configuration.
- TDoc R3-231843 includes MDT configuration parameters for NR (New Radio) such as measurement event trigger, measurement quantity, and reporting criteria.

Example snippet from TDoc R3-231605: "id-TargetHomeENB-ID ProtocolIE-ID ::= xxx"

Example snippet from TDoc R3-231843: "This IE defines the MDT configuration parameters of NR."

3. Referenced documents:
- TDoc R3-231605 does not reference any other documents.
- TDoc R3-231843 references another document titled "Discussion on MDT enhancement for AI/ML data collection" and mentions ZTE, Lenovo, and Samsung as the source for the TP (Technical Proposal) for AI/ML (Artificial Intelligence/Machine Learning) BLCR (Baseline Change Request) to TS38.413 (5G NR measurement procedures).

Example snippet from TDoc R3-231843: "References R3-231842, 'Discussion on MDT enhancement for AI/ML data collection', ZTE, Lenovo, Samsung TP for AI/ML BL CR for TS38.413"

4. Structure:
- TDoc R3-231605 includes an "END -- ASN1STOP" tag at the end of the constant definitions section, indicating the end of the changes made.
- TDoc R3-231843 includes an "End of Changes" tag after the MDT configuration parameters section, indicating the end of the changes made.

Example snippet from TDoc R3-231605: "END -- ASN1STOP <<<<<<<<<<<<<<<<<<<< End of the 4th set of Changes >>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<< End of Changes >>>>>>>>>>>>>>>>>>>> <<<<< End of Changes >>>>>>>>>>>>>>>>>>>>"

Example snippet from TDoc R3-231843: "End of Changes >>>>>>>>>>>>>>>>>>>>"

Overall, TDoc R3-231605 and TDoc R3-231843 have different purposes, content, referenced documents, and structure, indicating that they are addressing different aspects of the 5G NR technology.

- TDoc R3-231607 proposes the concept of Continuous MDT for NG-RAN, which enables UEs to provide a continuous time series of data that can be used for AI/ML model training/re-training.
- Management Based Immediate and Logged MDT configurations are used to achieve Continuous MDT data collection during transitions from RRC_Idle/Inactive to RRC_Connected.
- The NG-RAN selects and configures UEs with the Management Based immediate MDT measurements and Logged MDT configuration.
- UEs provide a “Continuous MDT Indication” to the NG-RAN as soon as they move to RRC_Connected, enabling the selection of the same UE (previously configured with Logged MDT) for following Immediate MDT measurement configuration.
- Details of the Continuous MDT solution in RAN3 are for further study.
- TDoc R3-231844 proposes an enhancement to MDT to support the continuous AI/ML related information reporting from UE.
- The enhancement introduces an indication in the logged MDT measurement configuration to indicate UE whether to collect continuous information across various RRC states (connect, inactive, idle).
- RAN3 acknowledges that current existing MDT mechanisms can be worked as the baseline for AI/ML data collection.
- The measurement periodicity extension and measurement duration are included as MDT configuration to enhance existing MDT mechanisms for continuous information collection.
- RAN3 asks RAN2 and SA5 for feedback on the feasibility of the MDT enhancement.

Example snippet from TDoc R3-231607: "A number of companies identified benefits with Continuous MDT, due to the possibility for UEs to provide a continuous time series of data, which can be of use for AI/ML model training/re-training."

Example snippet from TDoc R3-231607: "Management Based Immediate and Logged MDT configurations using different Trace Sessions. The NG-RAN selects and configures UEs with the Management Based immediate MDT measurements and Logged MDT configuration."

Example snippet from TDoc R3-231607: "UEs provide a “Continuous MDT Indication” to the NG-RAN as soon as they move to RRC_Connected, enabling the selection of the same UE (previously configured with Logged MDT) for following Immediate MDT measurement configuration."

Example snippet from TDoc R3-231844: "Introducing an indication in the logged MDT measurement configuration to indicate UE whether to collect continuous information across various RRC state (connect, inactive, idle)."

Example snippet from TDoc R3-231844: "The measurement periodicity extension and measurement duration are included as MDT configuration to enhance existing MDT mechanisms for continuous information collection."

3GPP-R3-119-bis-e    Agenda Item 13.1 : General

TDoc R3-231307:

- Potential complexity related to multi-hop backhauling for mobile IAB should be discussed in RAN2 and RAN3.
- Objective focuses on the impact on the UE connected to or camping on a mobile IAB-node cell.
- Mitigation of interference due to IAB-node mobility should be explored, including PCI collision avoidance and revision of assumptions on minimum distance.
- Inter-donor migration of the entire IAB-node (full migration) to be discussed in RAN3.

Example snippets:

- "Aspects of the potential complexity related to multi-hop backhauling should be briefly discussed at the beginning of the WI in RAN2 and RAN3."
- "This objective primarily focuses on the impact on the UE connected to or camping on a mobile IAB-node cell."
- "For mobile IAB-nodes, the assumption on the minimum distance and the implications on power control, receiver dynamic range, etc. need to be revised."
- "Inter-donor migration of the entire IAB-node (full migration): RAN3 can be expected to take the lead in this effort."

TDoc R3-231308:

- NRPPa messages to the LMF and F1AP positioning messages to the gNB carrying TRP information need to be enhanced to include mIAB-MT ID, current geolocation and velocity of TRP.
- AMF serving the UE should include mIAB-MT's cell ID into a location request for the UE to the LMF.
- NRPPa and F1AP messages carrying measurement information for a specific TRP towards the LMF should also include mIAB-MT's cell ID.

Example snippets:

- "All NRPPa messages to the LMF and all F1AP positioning messages to the gNB that carry TRP information need to be enhanced to optionally include the following information for mobile TRP: mIAB-MT ID, e.g., the GPSI as defined in TS 29.571, The current geolocation of the TRP (the IE is defined in TS 37.355 itself), The current velocity of TRP (the IE can be copied from TS 37.355)."
- "Proposal 2d: RAN3 to expect that SA2/CT will capture on normative stage that AMF serving the UE includes the mIAB-MT’s cell ID into a location request for this UE to the LMF."
- "This further includes the NRPPa and F1AP messages that carry measurement information for a specific TRP toward the LMF, which are: NRPPa MEASUREMENT RESPONSE, TRP INFORMATION RESPONSE."

Technical Differences Highlighted in TDoc R3-231356, R3-231482, R3-231522, and R3-231532:

1. Mobile IAB-MT serving cell ID and UE's ULI sent via NGAP message upon change of serving cell ID:

TDoc R3-231356 proposes that the serving cell ID of the mobile IAB-MT is sent along with UE’s ULI via UE associated NGAP message for all the UEs served by the mobile IAB node upon the change of the serving cell ID of the mobile IAB-MT.

2. Mobile IAB authorization information included in NGAP and UE context messages:

During RAN3#119 meeting, it was agreed that NGAP Initial Context Setup Request, UE Context Modification Request and HO Request messages are enhanced to include mobile IAB authorization info. This is crucial for the support of services that rely on the cell ID to infer the UE locations, e.g. emergency services.

3. NRPPa triggered procedure for LMF to obtain MBSR location information as an alternative to GMLC based MT-LR solution:

For point#6 (regarding KI#5), based on the SA2 study, NRPPa triggered procedure for the LMF to obtain MBSR location information i.e., location and velocity at a specific scheduled time could be a good alternative to the GMLC based MT-LR solution. In the solution provided by SA2, the serving cell ID of the mobile IAB-MT needs to be provided along with UE’s ULI via NGAP message to the AMF.

4. Mobile IAB-MT UE ID included in TRP Type IE when TRP Type is MBSR:

TDoc R3-231532 proposes that the Mobile IAB-MT UE ID IE is included in the TRP Type IE when the TRP Type is MBSR, so that LMF knows the UE ID of the IAB-MT associated with the mobile TRP and triggers the procedures defined in TS 23.273 to determine its updated location (Option 2).

5. Mobile IAB-MT's serving cell ID related to additional ULI that is unknown by F1 terminating CU initially:

Referring to TS 38.413, the ULI of NR UE includes the following contents: Some contents may not applicable for the mobile IAB-MT. For the scenario that the mobile IAB-MT and mobile IAB-DU connects to different donor CU, the additional ULI is related to the mobile IAB-MT’s serving cell (e.g., cell ID of the mobile IAB-MT), and is unknown by the F1 terminating CU initially.

6. TRP measurement result enhanced to provide updated location and velocity information of mobile TRP:

If Network Assisted procedure (i.e. UL related positioning) is used, as in 6.11.2, the NG-RAN may provide the mobile TRP’s updated location and velocity information to the LMF in the TRP measurement result so that the LMF can calculate the correct UE location based on the actual location of the mobile TRP when it performs the measurement, and this indicates the purpose to enhance TRP measurement result is that LMF needs to be aware of the updated location of the TRP at mobile IAB-node when positioning measurement is performed.

7. LMF learns whether a TRP in the gNB is mobile and learns the mIAB-MT UE ID from the F1 and NRPPa response of the TRP Information Exchange procedures:

Based on the SA2 agreement, during the determination of the NG-RAN’s TRPs positioning capabilities, the LMF learns whether a TRP in the gNB is mobile and learns the mIAB-MT UE ID from the F1 and NRPPa response of the TRP Information Exchange procedures. The geo-coordinates are already a part of the NRPPa and F1AP TRP Information Exchange signalling.

3GPP-R3-119-bis-e    Agenda Item 13.2 : Support IAB-node mobility

The gNB ID and XnAP UE ID of the target CU for mIAB-MT should be informed to mIAB-DU’s CU. [TDoc R3-231275]

The source logical DU informs the source logical DU’s CU about the successful F1 setup and cell IDs served by the target logical DU. [TDoc R3-231275]

mIAB-MT’s source CU should inform mIAB-DU’s CU about mIAB-MT’s migration. [TDoc R3-231275]

NGAP User Location Information IE needs to be enhanced to include the gNB ID of the IAB-donor-CU serving mobile IAB-MT. [TDoc R3-231309]

Target logical mIAB-DU’s CU should perform IAB Transport Migration Management procedure towards mIAB-MT’s CU before initiating UE Context Setup procedure to the target mIAB-DU. [TDoc R3-231329]

XnAP ID allocated by DU’s donor needs to be sent from MT’s source donor to DU’s donor. [TDoc R3-231357]

UL traffic sent from two logical DUs needs to be transferred to its connected IAB donor via the MT’s donor DU. [TDoc R3-231357]

Target logical mIAB-DU’s CU needs to be informed about target mIAB-MT’s CU ID and mIAB-MT ID before initiating TMM procedures towards target mIAB-MT’s CU. [TDoc R3-231479]

Proposal 1a suggests including target CU’s gNB ID and optionally CU’s IP address as well as its outer IP address for the use of IPsec tunnel mode when triggering the F1 Setup procedure. [TDoc R3-231309]

The IAB-node can inform the source logical mIAB-DU’s CU via F1AP about the successful F1 Setup with the target logical mIAB-DU’s CU and include the IDs of the cells activated by the target logical mIAB-DU’s CU. [TDoc R3-231329]

Proposal 4 suggests target logical mIAB-DU’s CU perform IAB Transport Migration Management procedure towards mIAB-MT’s CU before initiating UE Context Setup procedure to the target mIAB-DU. [TDoc R3-231329]

Option 2 is proposed as a suitable option for informing the target F1 donor-CU about identification information related to the non-F1 donor-CU, such as mIAB-MT’s CU ID and mIAB-MT ID. [TDoc R3-231479]

- The TDocs discussed issues related to multiple consecutive partial migrations without inter-donor migration of mobile IAB-DUs.
- The mobile IAB-MT ID and the target node ID are reported by the source IAB-donor-CU of the mobile IAB-MT to the mobile IAB’s F1-terminating IAB-donor-CU after the completion of mobile IAB-MT handover.
- In the case of consecutive partial migration, the UE XnAP ID allocated by source IAB-donor or F1-terminating IAB-donor for mobile IAB-node is informed from the source IAB-donor to the F1-terminating IAB-donor to identify the mobile IAB-MT’s handover.
- To design a common solution for the IAB-MT handover and IAB-DU migration over the IAB TMM message, UE XnAP ID of the mobile IAB-MT is preferred.
- Different migration cases are supported if F1 connection can be set up between second mobile IAB-DU and target IAB-donor-CU via the topology of another IAB-donor.
- Before IAB-DUb initiates F1 setup with target IAB-donor, IAB-DUb needs to be OAM configured with appropriate DU parameters.
- When triggering the F1 Setup procedure on the mIAB-node, the source logical mIAB-DU’s CU includes the information of the target logical mIAB-DU’s CU (e.g. IP address, gNB-ID).
- IAB sends a request to the OAM server, requesting the DU parameters to be used for F1 with IAB-donor2-CU.
- The OAM server configures IAB for the related DU parameters, e.g. NCGI(s) to be used by IAB-DUb’s cell(s), IP address of target IAB-donor CU, SeGW information, etc.
- Based on the configured information, the donor of the mIAB-DU can request the IAB-DUb to set up F1 with the target IAB-donor.

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

- In the procedure mentioned in TDoc R3-231330, step 16 and step 17 are used for the Xn procedure for the source IAB-donor-CU of the mobile IAB-MT to inform the F1-terminating donor-CU of the mobile IAB node on the above-mentioned notifications.
- TDoc R3-231440 proposes that in case of consecutive partial migration, the F1-terminating IAB-donor needs to be indicated from the source IAB-donor with a UE XnAP ID allocated by the target IAB-donor over the Xn interface between the F1-terminating IAB-donor and the target IAB-donor.
- TDoc R3-231441 discusses migration cases where the IAB-MT HOs from IAB-donor A to IAB-donor B and the IAB-DU stays connected to IAB-donor C.
- Case 4 in TDoc R3-231441 discusses a scenario where the IAB-DU migrates from IAB-donor A to IAB-donor B, and the IAB-MT stays connected to IAB-donor B.
- TDoc R3-231470 describes the process where the source logical mIAB-DU’s CU includes the information of the target logical mIAB-DU’s CU when triggering the F1 Setup procedure on the mIAB-node.

Technical Differences:

1. Partial migration:

- mIAB-MT may perform multiple consecutive partial migrations.
- The source donor-CU of the IAB-MT should indicate donor-CU of IAB-DU.
- The mIAB-MT ID sent by the mIAB-MT’s source donor CU to the mIAB-DU’s donor CU is the XnAP UE ID.

Supporting Example from TDoc: Issue 1 - "the mIAB-MT ID sent by the mIAB-MT’s source donor CU to the mIAB-DU’s donor CU is the XnAP UE ID."

2. DU migration:

- All the signaling needed to support migrating the mIAB-DU to a donor CU different than the donor CU of the mIAB-MT either already exists or has been agreed.
- The second logical mIAB-DU informs the target donor CU for mIAB-DU migration about the gNB ID of the donor CU serving the mIAB-MT and the ID(s) of the mIAB-MT.

Supporting Example from TDoc: Figure 1 - "The second logical mIAB-DU informs the target donor CU for mIAB-DU migration about the gNB ID of the donor CU serving the mIAB-MT and the ID(s) of the mIAB-MT."

3. Additional ULI:

- For the case that the IAB-MT and IAB-DU are connected to the same IAB-donor-CU, the serving IAB-donor-CU of mobile IAB can provide the IAB-MT’s ULI as additional ULI of the UEs served by mobile IAB-node via UE associated NGAP message.

Supporting Example from TDoc: "Regarding how to support additional ULI for UE served by mobile IAB, we think two cases can be further considered."

4. DU migration preparation notification to IAB-MT source donor:

- It is necessary for IAB-MT’s source donor to know the information on IAB-DU migration, such as TNL address of the mIAB-DU and TNL address and ID of the IAB-DU’s target donor.
- Therefore, the mIAB node or the IAB-DU’s source donor can initiate the procedure for releasing the source logical mIAB-DU’s F1AP association.

Supporting Example from TDoc: Issue 2 - "It is necessary for IAB-MT’s source donor to know the information on IAB-DU migration, such as TNL address of the mIAB-DU and TNL address and ID of the IAB-DU’s target donor."

5. Multiple Partial Migration:

- The information on admission result of the offloaded traffic can be used by the source non-F1 terminating donor CU to decide the selected target non-F1 terminating donor CU.
- The source non-F1 terminating donor CU sends an indication to the source F1 terminating donor CU, which indicates the completion of the mIAB-MT HO.

Supporting Example from TDoc: Figure 8.17.x.x - "The information on admission result of the offloaded traffic can be used by the source non-F1 terminating donor CU to decide the selected target non-F1 terminating donor CU."

3GPP-R3-119-bis-e    Agenda Item 13.3 : Mobility Enhancements

TDoc R3-231358:

- Mobile IAB-MT can obtain TAC by reading the system information of parent cell.
- If TAC is configured by MT's donor via RRC signaling, no Xn/NG enhancement is needed.
- If TAC is configured by DU's donor via F1, more standardization effort and spec impact is needed.
- LS should be sent to RAN2 to trigger corresponding work.

Example snippet from TDoc: "If the TAC broadcast by the mobile IAB cell is configured by MT’s donor via RRC, RRC signaling needs to be enhanced to include TAC configuration for mobile IAB cell, while no Xn/NG enhancement is needed since no coordination between MT’s donor and DU’s donor is needed."

TDoc R3-231525:

- IAB-DU1 can release UE context without further indication from IAB-donor-CU.
- UE context release in IAB-DU1 should be informed to IAB-donor-CU to avoid triggering F1 UE context release procedures.
- Core network can assign RA appropriately taking RA of IAB-MT into account.
- RAU will not be triggered as newly broadcasted TA is already configured in RA of UE.

Example snippet from TDoc: "So, in our view, the signalling in step 11 and step 12 can be saved, since IAB-DU1 can know whether all the UEs access to the IAB-DU2, and IAB-DU1 can release the UE context without the further indication from IAB-donor-CU."

Proposal 1:

- RAN3 agrees that IAB-DU1 can release UE context by knowing UE's successful access to IAB-DU2.

Example snippet from TDoc: "Proposal 1, RAN3 agree that the IAB-DU1 can release the UE context by knowing the UE’s successful access to the IAB-DU2."

Technical Differences:
1. OAM Functions:
- The OAM server for RAN is responsible for Configuration Management (CM) in the current network.
- CM allows operators to configure and reconfigure RAN network devices to meet short and long-term requirements.
- The OAM server enhances the network or upgrades the equipment in response to incidents such as traffic load requirements, performance, capacity, and customer satisfaction.
- The OAM server configures IAB with the right DU related parameters and the FQDN/IP address of the SeGW/IAB-donor-CU to the IAB once IAB-MT reports its parent cell information.
- IAB reports its location to Source OAM.

2. mIAB-DU Configuration:
- RAN3 discusses how the mobile IAB-DU's parameters are reconfigured for mIAB-DU migration and partial migration.
- If the target cell belongs to an mIAB node, UE can have good service if it becomes an onboard UE of mIAB node.
- If UE is fixed or has different trajectories with mIAB node, UE may perform a handover procedure again when the mIAB node moves far away from UE.
- It is helpful for the source CU to know that the target cell considered for UE handover belongs to an mIAB node.
- In general, the mobile IAB-DU's parameters can be configured by OAM.

Examples from TDoc:
- "Configuration Management (CM), which allows operator to install/configure/reconfigure a RAN network device to meet short/long-term requirements, e.g. to react to incidents such as traffic load requirements, performance, capacity, and customer satisfaction through the enhancement of the network or equipment up-grade" (TDoc R3-231472).
- "If the target cell belongs to mIAB node, the following scenarios may happen: Scenario 1: UE moves with mIAB node, e.g. UE becomes an onboard UE of mIAB node, then UE can have a good service if UE handovers to the target cell; Scenario 2: If UE is fixed or have different trajectories with mIAB node, then the UE may perform handover procedure again when mIAB node moves far away from UE" (TDoc R3-231719).
- "It is helpful for source CU to know that the target cell considered for UE handover belongs to a mIAB node" (TDoc R3-231719).

1. Proposal 6 allows the mIAB-DU's CU to indicate the new TAC to the AMF(s) via an existing message, which means BH link and traffic transport for the mIAB-node within the topology of the donor CU for the mIAB-MT can remain unchanged during the mIAB-DU migration. OAM is not preferred to configure mIAB-DU during movement of mIAB-node. [TDoc R3-231276]
2. The mIAB-DU can be configured with a lookup table of all area-specific configurations in case the mIAB-node is expected to travel over a large distance, and autonomously apply the appropriate configuration based on its current location. OAM-based configuration and/or pre-configuration can be applied to all those mIAB-DU parameters that are not expected to change while the mIAB-DU is traveling across the network. [TDoc R3-231310]
3. For served UEs of the mobile IAB-node, pre-configuration at the IAB-DU may not be feasible as the target IAB-donor-CU may be unpredictable due to the random mobility of the mobile IAB-node. Configuration for IAB-DU's parameters pre-configuration at the mobile IAB-node may have some advantages to reduce latency during IAB-DU migration or full migration, especially for the case of regular trajectory or predictable trajectory of mobile IAB-node. [TDoc R3-231442]
4. The mIAB-DU may be pre-configured with a list of OAM systems and the information needed for establishing a connection to each of them. The mIAB-DU can then update the TAC/RANAC in SIB1 and could use legacy F1AP signalling to inform its serving donor CU about the new TAC/RANAC. This approach is more aligned with the legacy way of acquiring configurations for the DU. [TDoc R3-231536]

Example snippets from the original TDocs:
- "When the TAC/RANAC broadcasted by the mIAB-DU needs to be changed, the F1-terminating donor-CU can transfer the updated TAC/RANAC value which reflects the physical location of mIAB-node via F1AP message to the mIAB-DU." [TDoc R3-231276]
- "Among the parameters reported in F1 Setup Request, the following parameters may be subject to change on a short-time scale or have fine location granularity, so that CU-based reconfiguration needs to be supported: NCGI and NR Cell Identity." [TDoc R3-231310]
- "However, for the mobile IAB-node, the target IAB-donor-CU may be unpredictable due to the random mobility of mobile IAB-node, and in this case, pre-configuration at the IAB-DU may not feasible." [TDoc R3-231442]
- "Given that there may exist several OAM systems in a network (but this number is generally not large, since every OAM system covers a large area within a country), the mIAB-DU may be pre-configured with a list of OAM systems and the information needed for establishing a connection to each of them." [TDoc R3-231536]

3GPP-R3-119-bis-e    Agenda Item 13.4 : Mitigation of interference

Technical Differences Highlighted in TDoc R3-231473, R3-231485, R3-231526, and R3-231537:

1. Dual-DU approach for PCI change migration: The PCI change can utilize the dual-DU approach for smooth transition (HO) of UEs between the old cell and the changed new cell with the changed PCI. (R3-231473)

2. Handover of connected UEs between cells: PCI change on the IAB-node can be supported via handover of connected UEs between cells using old and new PCI, respectively. (R3-231473)

3. Detection of colliding PCIs: The RAN serving the mobile IAB-nodes will be aware of the mobile IAB locations and the mobility history to detect or estimate the probability of colliding PCIs of two mobile IAB-nodes. (R3-231473)

4. PCI reconfiguration via F1AP message: F1-terminating IAB-donor can reconfigure PCI for the cell of mobile IAB-DU via existing F1AP message to avoid PCI collision. (R3-231473)

5. PCI reconfiguration in case of different OAMs: FFS for the PCI reconfiguration in case of IAB-donor and IAB-node with different OAMs to avoid PCI collision. (R3-231473)

6. Pre-configured candidate PCI list: If the candidate PCI list can pre-configured to the mobile IAB node, the IAB-node can pick a new PCI if the PCI collision or potential PCI collision is detected. (R3-231485)

7. Absence of Xn interface: If there is no Xn interface between the F1 terminating CU and the target CU of the mobile IAB-MT, the F1 terminating CU may not be able to obtain the full PCI lists controlled by the target CU. (R3-231485)

8. Information transfer between mobile IAB-node and IAB-donor: The pre-configurations PCI list in the mobile IAB-node and the IAB-node movement info should be transferred from the mobile IAB-node to IAB-donor of mobile IAB-DU if it’s IAB-donor of mobile IAB-DU to assign the new PCI. (R3-231526)

9. PCI collision detection indication and cell configuration transfer: The PCI collision detection indication and the cell configuration of the neighbours should be transferred from IAB-donor of mobile IAB-DU to the mobile IAB-node if the mobile IAB node (or it’s OAM) assign the new PCI. (R3-231526 and R3-231537)

10. Massive PCI reconfigurations: Allowing the mIAB-node to reconfigure PCI without donor involvement may cause massive PCI reconfigurations across the network, and it is incompatible with existing standardized solutions, which are gNB/CU-centric. (R3-231537)

Examples from the TDoc to support the difference highlighting:

- "The RAN serving the mobile IAB-nodes will be aware of the mobile IAB locations and the mobility history at least on the cell resolution which will be in normal cases enough to detect or estimate the probability of colliding PCIs of two mobile IAB-nodes." (R3-231473)

- "If the candidate PCI list can pre-configured to the mobile IAB node (maybe as part of the pre-configurations which will be activated when some specific condition is met, as also discussed in our paper [3]), the IAB-node can pick a new PCI if the PCI collision or potential PCI collision is detected." (R3-231485)

- "The pre-configurations PCI list in the mobile IAB-node and the IAB-node movement info should be transferred from the mobile IAB-node to IAB-donor of mobile IAB-DU if it’s IAB-donor of mobile IAB-DU to assign the new PCI." (R3-231526)

- "Allowing the mIAB-node to reconfigure PCI without donor involvement may cause massive PCI reconfigurations across the network, and it is incompatible with existing standardized solutions, which are gNB/CU-centric." (R3-231537)

3GPP-R3-119-bis-e    Agenda Item 14.1 : General

3GPP-R3-119-bis-e    Agenda Item 14.2 : Signaling Support for L1/L2 based Inter-Cell Mobility

1. Transmission of TA value(s) from candidate DU to serving DU:
- Option 1: Candidate DUs transmit TA values to serving DU before LTM triggering, serving DU maintains values.
- Option 2: Serving DU requests target DU to transmit latest TA value before sending LTM command.
- TDoc R3-231326

2. Conditional Intra-DU Mobility Information IE in UE CONTEXT MODIFICATION REQUEST message:
- gNB-DU includes received SpCell ID IE as Requested Target Cell ID IE in UE CONTEXT MODIFICATION FAILURE message.
- Potential impact on RAN3 specs.
- TDoc R3-231382

3. BH Information IE in UL UP TNL Information to be setup List IE or Additional PDCP Duplication TNL List IE for DRB:
- gNB-DU uses indicated BAP Routing ID and BH RLC channel for transmission of corresponding GTP-U packets to IAB-donor if supported.
- TDocs R3-231511, R3-231848

4. CG-Config IE in CU to DU RRC Information IE in UE CONTEXT MODIFICATION REQUEST message:
- gNB-DU may initiate low layer parameters coordination taking this information into account for DC operation.
- UE Context Setup Procedure not used to configure SRB0.
- TDocs R3-231511, R3-231848

5. Delay Critical IE in Dynamic 5QI Maximum:
- TDoc R3-231848

Supporting Examples:
- TDoc R3-231326: "The candidate DUs shall transmit the TA values to the serving DU by F1 interface through the CU."
- TDoc R3-231382: "If the Conditional Intra-DU Mobility Information IE was included in the UE CONTEXT MODIFICATION REQUEST message and set to 'CHO-initiation', the gNB-DU shall include the received SpCell ID IE as the Requested Target Cell ID IE in the UE CONTEXT MODIFICATION FAILURE message."
- TDocs R3-231511, R3-231848: "If the BH Information IE is included in the UL UP TNL Information to be setup List IE or the Additional PDCP Duplication TNL List IE for a DRB, the gNB-DU shall, if supported, use the indicated BAP Routing ID and BH RLC channel for transmission of the corresponding GTP-U packets to the IAB-donor, as specified in TS 38.340"
- TDocs R3-231511, R3-231848: "For DC operation, if the gNB-CU includes the CG-Config IE in the CU to DU RRC Information IE that is included in the UE CONTEXT MODIFICATION REQUEST message, the gNB-DU may initiate low layer parameters coordination taking this information into account."
- TDoc R3-231848: "If the Delay Critical IE is included in the Dynamic 5QI Maximum."

Technical Differences Among TDocs:

1. Inter-gNB-DU L1/L2 Triggered Mobility:
- Procedure used for UE movement within the same gNB-CU during NR operation
- Candidate gNB-DU responds to gNB-CU with UE CONTEXT SETUP RESPONSE message
- gNB-CU sends UE CONTEXT SETUP REQUEST message to candidate gNB-DU
- UE sends lower layer measurement result to source gNB-DU
- [TDoc R3-231679]

2. Inter-CU-UP LTM:
- CU-CP initiates E1 bearer context modification to retrieve latest PDCP status and exchange data forwarding information
- CU-CP initiates E1 bearer context modification for DL tunnel ID per DRB and security keys for target cell
- gNB-CU-CP decides to initiate LTM configuration
- [TDoc R3-231746]

3. Sequential LTM:
- gNB-CU informs candidate cells to gNB-DU for sequential LTM without RRCReconfiguration
- Notification of candidate cell configuration to source serving gNB-DU for inter-DU LTM case
- Another UE Context Modification procedure may be triggered to reconfigure serving cell and provide LTM candidate cells to UE
- Intention to help source gNB-DU generate content of PDCCH order for candidate cell in inter-gNB-DU LTM
- [TDoc R3-231747]

4. DL RRC MESSAGE TRANSFER in L1/L2 Triggered Mobility:
- gNB-CU sends DL RRC MESSAGE TRANSFER message to source gNB-DU with generated RRCReconfiguration message
- gNB-DU signals UE CONTEXT MODIFICATION REQUIRED message to gNB-CU to indicate initiation of L1/L2 triggered mobility command to UE including Target cell ID
- Source gNB-DU responds to gNB-CU with UE CONTEXT RELEASE COMPLETE message
- Source gNB-DU sends LTM command to UE
- [TDoc R3-231849]

Example snippets from the original TDocs:

- "The gNB-CU sends a message to the source gNB-DU, which includes the generated RRCReconfiguration message with the L1/L2 triggered mobility configuration. The source gNB-DU signals the gNB-CU about the initiation of the L1/L2 triggered mobility command to the UE including the Target cell ID." [TDoc R3-231679]
- "For inter-CU-UP LTM, the CU-CP initiates E1 bearer context modification to the source CU-UP for retrieving the latest PDCP status at the source CU-UP and exchanging the data forwarding information to target CU-UP." [TDoc R3-231746]
- "Before that, the gNB-CU and gNB-DU may trigger another UE Context Modification procedure to, e.g., reconfigure the serving cell of the UE, provide LTM candidate cell(s) configured to the UE and the corresponding configurations for each candidate cell." [TDoc R3-231747]
- "The gNB-CU sends a DL RRC MESSAGE TRANSFER message to the source gNB-DU, which includes the generated RRCReconfiguration message with the L1/L2 triggered mobility configuration. The gNB-DU signalssends the UE CONTEXT MODIFICATION REQUIRED message to the gNB-CU aboutto indicate the initiation of the L1/L2 triggered mobility command to the UE including the Target cell ID." [TDoc R3-231849]

Technical differences among the TDoc snippets include:

1. LTM Configuration Response:
- If the gNB-DU accepts the request of LTM configuration, it responds to the gNB-CU with a UE CONTEXT MODIFICATION RESPONSE message including the generated lower layer RRC configurations for the accepted target candidate cell(s).
- Example: "If the candidate gNB-DU accepts the request of LTM configuration, it responds to the gNB-CU with a UE CONTEXT SETUP RESPONSE message including the generated lower layer RRC configuration for the accepted target candidate cell(s)."

2. Subsequent LTM:
- For initial LTM, there is a configuration preparation procedure by UE CONTEXT SETUP or UE CONTEXT MODIFICATION procedure.
- Example: "For initial LTM, RAN3 agreed to have a configuration preparation procedure by UE CONTEXT SETUP or UE CONTEXT MODIFICATION procedure as captured in the approved BLCR."

3. LTM Release:
- For intra-DU L1/L2 mobility, the gNB-CU may use the UE Context Modification procedure to modify or release the prepared cells resources in the gNB-DU without any further pre-configuration steps.
- Example: "At RAN3#117bis meeting, there is a FFS, i.e. “FFS For intra-DU L1/L2 mobility, the gNB-CU may use the UE Context Modification procedure to modify or release the prepared cells resources in the gNB-DU (incl. message)without any further pre-configuration steps."

4. Estimated Arrival Probability IE:
- If the Estimated Arrival Probability IE is contained in the Conditional Intra-DU/Inter-DU Mobility Information IE included in the UE CONTEXT MODIFICATION/SETUP REQUEST message, then the gNB-DU may use the information to allocate necessary resources for the UE.
- Example: "If the Estimated Arrival Probability IE is contained in the Conditional Intra-DU/Inter-DU Mobility Information IE included in the UE CONTEXT MODIFICATION/SETUP REQUEST message, then the gNB-DU may use the information to allocate necessary resources for the UE."

5. Access Success:
- Upon reception of the ACCESS SUCCESS message, the gNB-CU shall consider that the UE successfully accessed the cell indicated by the included NR CGI IE in this gNB-DU and consider all the other CHO preparations or conditional PSCell addition or conditional PSCell change preparations accepted for this UE under the same UE-associated signaling connection in this gNB-DU as cancelled.
- Example: "Upon reception of the ACCESS SUCCESS message, the gNB-CU shall consider that the UE successfully accessed the cell indicated by the included NR CGI IE in this gNB-DU and consider all the other CHO preparations or conditional PSCell addition or conditional PSCell change preparations accepted for this UE under the same UE-associated signaling connection in this gNB-DU as cancelled."

6. Positioning Context Reservation Indication IE:
- If the Positioning Context Reservation Indication IE is included in the UE CONTEXT RELEASE COMMAND message, the gNB-DU shall not release the positioning context including the SRS configuration for the UE.
- Example: "If the Positioning Context Reservation Indication IE is included in the UE CONTEXT RELEASE COMMAND message, the gNB-DU shall not release the positioning context including the SRS configuration for the UE. Successful operation."

7. Handover Completion:
- For intra-DU case, when CU obtains the UE successful access the target cell, some candidate cell configured to UE may be not suitable for future handover since cells are not in direction of UE movement.
- Example: "For intra-DU case, when CU obtains the UE successful access the target cell, some candidate cell configured to UE may be not suitable for future handover since cells are not in direction of UE movement."

8. UE Context Release Command:
- For inter-DU case, if subsequent LTM procedure is not supported, gNB-CU may send the UE CONTEXT RELEASE COMMAND message to the source gNB-DU to release the resources of all prepared cells.
- Example: "For inter-DU case, if subsequent LTM procedure is not supported, gNB-CU may send the UE CONTEXT RELEASE COMMAND message to the source gNB-DU to release the resources of all prepared cells."

9. UE Context Modification:
- For inter-DU case, if subsequent LTM procedure is supported, gNB-CU may send the UE CONTEXT MODIFICATION message to source gNB-DU to release the resources of some prepared cells after the LTM handover completion.
- Example: "For inter-DU case, if subsequent LTM procedure is supported, gNB-CU may send the UE CONTEXT MODIFICATION message to source gNB-DU to release the resources of some prepared cells after the LTM handover completion."

10. PDCCH Ordered RACH:
- If the RAR or TA is sent from the serving cell after the LTM decision, the source DU needs to obtain the RAR or TA in coordination between source and target DU.
- Example: "If the RAR or TA is sent from the serving cell, after the LTM decision (i.e. after the target cell decision), the source DU needs to obtain the RAR or TA in coordination between source and target DU, thus approach 2 should be applied."

In conclusion, the TDoc snippets highlight various technical differences in the LTM procedure, including LTM Configuration Response, Subsequent LTM, LTM Release, Estimated Arrival Probability IE, Access Success, Positioning Context Reservation Indication IE, Handover Completion, UE Context Release Command, UE Context Modification, and PDCCH Ordered RACH. These differences are important for understanding the specific requirements and procedures involved in LTM for 5G networks.

3GPP-R3-119-bis-e    Agenda Item 14.3 : Support CHO in NR-DC

Technical Differences:

1. MR-DC Resource Coordination Information IE:
- When the E-UTRA Coordination Assistance Information IE or the NR Coordination Assistance Information IE is contained in the MR-DC Resource Coordination Information IE, the S-NG-RAN node shall use the information to determine further coordination of resource utilization between the S-NG-RAN node and the M-NG-RAN node.
- If the E-UTRA Coordination Assistance Information IE or the NR Coordination Assistance Information IE is contained in the MR-DC Resource Coordination Information IE, the M-NG-RAN node shall use the information to determine further coordination of resource utilization between the M-NG-RAN node and the S-NG-RAN node.
- If the S-NODE MODIFICATION REQUIRED message contains the MR-DC Resource Coordination Information IE, the M-NG-RAN node may use it for the purpose of resource coordination with the S-NG-RAN node.

2. Direct Data Forwarding:
- In Scenario 1, the data forwarding path is S-SN -> S-MN -> T-SN.
- If the T-MN knows that there is a direct path between the T-SN and the S-MN, it can include the address provided from the T-SN to the S-MN in HO Request ACK for early data forwarding of SN terminated bearers, and the direct data forwarding between the S-MN and the T-SN can be realized.
- If the target side can provide the used configuration type to S-MN, and S-MN then can provide it to S-SN in CHO+CPAC or CHO+MR-DC, S-SN will know the configuration type of the target side, and T-MN1/MN2 doesn’t need to assign indirect data forwarding tunnel.

Examples from TDoc:

1. MR-DC Resource Coordination Information IE
- "If the E-UTRA Coordination Assistance Information IE or the NR Coordination Assistance Information IE is contained in the MR-DC Resource Coordination Information IE, the S-NG-RAN node shall, if supported, use the information to determine further coordination of resource utilisation between the S-NG-RAN node and the M-NG-RAN node."
- "If the E-UTRA Coordination Assistance Information IE or the NR Coordination Assistance Information IE is contained in the MR-DC Resource Coordination Information IE, the M-NG-RAN node shall, if supported, use the information to determine further coordination of resource utilisation between the M-NG-RAN node and the S-NG-RAN node."
- "If the S-NODE MODIFICATION REQUIRED message contains the MR-DC Resource Coordination Information IE, the M-NG-RAN node may use it for the purpose of resource coordination with the S-NG-RAN node."

2. Direct Data Forwarding
- "To support scenaio1, if the T-MN knows that there is a direct path between the T-SN and the S-MN, it can include the address provided from the T-SN to the S-MN in HO Request ACK for early data forwarding of SN terminated bearers, and the direct data forwarding between the S-MN and the T-SN can be realized."
- "According to the existing specification, T-SN can obtain the S-SN node ID in SN Addition Request message."
- "Therefore, in CHO+CPAC or CHO+MR-DC, if the target side can provide the used configuration type to S-MN, and S-MN then can provide it to S-SN, S-SN will know the configuration type of the target side. So the T-MN1/MN2 doesn’t need to assign indirect data forwarding tunnel."

Technical differences among the TDocs:

- TDoc R3-231317 includes separate indications of direct forwarding paths available to the source SN and the source MN in the SN Addition Request Ack response message.
- TDoc R3-231322 proposes adding an indicator to indicate whether the Data Forwarding Info from a target NG-RAN node is already provided for the same data forwarding address in a CHO with multiple SCGs.
- TDoc R3-231449 suggests that the source MN may trigger the MN-initiated SN Modification procedure to retrieve the current SCG configuration before sending the SN Addition Request message in a CHO with/without SN change.
- TDoc R3-231575 highlights the need for an indicator in SN reconfigurations to inform the MN whether the reconfiguration impacts the conditional target configuration or not.

Examples from the original TDocs:

- TDoc R3-231317: "In the response message SN Addition Request Ack, the candidate SN includes separate indications of whether it has direct forwarding paths available to the source SN and the source MN."
- TDoc R3-231322: "Proposal 2: Add indicator to indicate whether the Data Forwarding Info from target NG-RAN node is already provided for the same data forwarding address."
- TDoc R3-231449: "In case of the CHO with/without SN change, the source MN may trigger the MN-initiated SN Modification procedure (to the source SN) to retrieve the current SCG configuration, if configured, before step 1."
- TDoc R3-231575: "To make the network signaling exchange more efficient, the SN should tell explicitly the MN whether the reconfiguration impacts the conditional target configuration or not, for instance, by an indicator."

Technical Differences between TDoc R3-231305 and R3-231306:

1. Approach to CHO Configuration Update:
- R3-231305 proposes a lighter approach by getting consultation from candidate target nodes to determine if the update of CHO configurations is necessary, assuming that S-SN cannot determine the impact of the intra-S-SN reconfiguration on CHO configurations.
- R3-231306 does not address this approach.

2. Intra-S-SN Configuration Update:
- R3-231305 proposes that S-SN always informs S-MN of its intra-S-SN configuration update with the UE, regardless of whether SRB3 was already used or SRB1 has to be used via MN, via the SN-initiated SN modification procedure (including the updated CG-Config).
- R3-231306 does not address this proposal.

3. CHO Response Message:
- R3-231306 proposes that in the CHO response message from T-MN, T-MN should be able to deliver multiple admission results of PDU session resources setup (and their data forwarding related information), reflecting different admission results over T-MN with multiple candidate T-SNs.
- R3-231305 does not address this proposal.

Example snippets supporting the differences:

1. Approach to CHO Configuration Update:
- R3-231305: "[3] also proposed a lighter approach by getting consultation from those candidate target node(s) whether the update of CHO(+NR-DC/CPAC) configurations is necessary or not, based on the assumption that S-SN is not able to tell if the intra-S-SN reconfiguration would impact on those CHO(+NR-DC/CPAC) configurations (which is different to the assumption of the Solutions 1/4 camp)."
- No corresponding snippet in R3-231306.

2. Intra-S-SN Configuration Update:
- R3-231305: "Proposal 1: RAN3 to agree that S-SN (who is aware of CHO) always informs S-MN of its intra-S-SN configuration update with the UE, regardless of whether SRB3 was already used or SRB1 has to be used via MN, via the SN-initiated SN modification procedure (including the updated CG-Config)."
- No corresponding snippet in R3-231306.

3. CHO Response Message:
- R3-231306: "As a result, in the CHO response message from T-MN, T-MN should be able to deliver multiple admission results of PDU session resources setup (and their data forwarding related information), reflecting different admission results over T-MN with multiple candidate T-SNs."
- No corresponding snippet in R3-231305.

3GPP-R3-119-bis-e    Agenda Item 14.4 : Others

- Proposal 1 suggests transferring reference configuration and indication of usage between MN and SN using inter-node RRC message instead of explicit IE in Xn message.
- Observation 1 highlights that RAN2 agreed to support SCG selective activation for scenarios like CPA, MN-initiated CPC, SN-initiated inter-CPC, and SN-initiated intra-SN CPC.
- Observation 2 emphasizes that the reference configuration will be used in the CPC scenarios.
- Proposal 4 proposes studying how to manage the early data forwarding path among candidate SNs to avoid setting up the path during every SN change.
- TDoc R3-231316 mentions that upon receiving RRCReconfigurationComplete from UE, MN provides the data forwarding addresses needed for the procedure to source SN and candidate SNs using Xn-U Address Indication messages.
- TDoc R3-231316 also highlights that MN prepares the initial RRC reconfiguration message containing the configuration for SCG selective activation.
- In TDoc R3-231316, either the source MN or source SN can initiate the procedure for SCG selective activation assumption.
- TDoc R3-231316 outlines the steps involved in Source MN initiating the preparation procedure based on UE measurement reports and transmitting SN Addition Request to a candidate SN that includes a set of suggested candidate PSCells and associated UE measurements.
- TDoc R3-231383 reminds about the new indicator in S-NODE ADDITION REQUEST to indicate the SN adding includes the purpose of the Selective Activation of Cell Group.
- TDoc R3-231383 proposes indicating the MN or SN to hold the candidate SCG configuration, even if the candidate PSCells are in loaded situation, to ensure that later it can be resumed.

- The target/new serving SN should be informed via Xn message by MN about the information of the already configured CPC, including at least the identifications of candidate Cells and the corresponding execution conditions.
- Based on the accepted candidate cell and the associated execution conditions, the MN generates the RRCReconfiguration message which is used to provide the CPC configuration to UE.
- Upon the reception of RRCReconfigurationComplete message from UE, the MN informs the source SN that the CPC has been configured via Xn-U Address Indication message to enable source SN to initiate potential early data forwarding.
- For Selective Activation, during subsequent PSCell change procedure, the source SN may change then the delta configuration cannot be used anymore, therefore, RAN2 propose to use reference configuration and agreed that the MN should provide the reference configuration to all candidate T-SNs (in order to generate the T-SN candidate configuration) for inter-SN CPC case.
- The candidate SN should include an indication in SN Addition Request Acknowledge message to indicate whether the associated SCG configuration is a delta with respect to the reference SCG configuration.
- For SN-initiated CPC, the S-SN generate the corresponding SCG configurations and decide whether to trigger the selective activation mechanism.
- With the activation/deactivation mechanism, UE only needs to evaluate the candidate PSCells in the activated state for the subsequent CPC procedure.
- If the candidate PSCell is selected for the subsequent, it is set in activated state, otherwise it is set in deactivated state, which is the mechanism of activation and deactivation of candidate PSCells.
- The NW needs to indicate activation/deactivation of the candidate cell to the UE by signaling other than RRCReconfiguration, however this is up to RAN2.
- RAN3 can support this function by adding indication of the candidate cell to be activated/deactivated in the SN Modification Required message.
- RAN3 needs to add a new indication to the Xn message indicating whether or not each candidate cell should be maintained.
- Further check the activation/deactivation of candidate PSCells for NR Selective Activation.

Example snippet from TDoc R3-231460:
"For SN initiated inter-SN SCG selective activation, the target/new serving SN should be informed via Xn message by MN about the information of the already configured CPC, including at least the identifications of candidate Cells and the corresponding execution conditions."

Example snippet from TDoc R3-231512:
"For Selective Activation, during subsequent PSCell change procedure, the source SN may change then the delta configuration cannot be used anymore, therefore, RAN2 propose to use reference configuration and agreed that the MN should provide the reference configuration to all candidate T-SNs (in order to generate the T-SN candidate configuration) for inter-SN CPC case."

Example snippet from TDoc R3-231816:
"The NW needs to indicate activation/deactivation of the candidate cell to the UE by signaling other than RRCReconfiguration, however this is up to RAN2."

Summary of Technical Differences among TDoc:

1. Use of Estimated Arrival Probability IE:
- If the Estimated Arrival Probability IE is contained in the CHO Information SN Addition IE included in the S-NODE ADDITION REQUEST message, then the S-NG-RAN node may use the information to allocate necessary resources for the UE.
- If the Estimated Arrival Probability IE is contained in the Conditional PSCell Addition Information Request IE included in the S-NODE ADDITION REQUEST message, then the candidate target S-NG-RAN node may use the information to allocate necessary resources for the incoming CPAC procedure.
- If the Estimated Arrival Probability IE is contained in the CHO Information SN Addition IE included in the S-NODE ADDITION REQUEST message, then the S-NG-RAN node may use the information to allocate necessary resources for the UE.

2. Use of Source NG-RAN Node ID IE:
- If the Source NG-RAN Node ID IE is included in the S-NODE ADDITION REQUEST message, the S-NG-RAN node shall, if supported, use it to decide the direct data path availability with the indicated source NG-RAN node, and if the direct data forwarding path is available, include the Direct Forwarding Path Availability IE in the S-NODE ADDITION REQUEST ACKNOWLEDGE message.

3. Use of CG-CandidateList:
- If the CG-CandidateList is included in the S-NG-RAN node to M-NG-RAN node Container IE in the S-NODE ADDITION REQUEST ACKNOWLEDGE message, the M-NG-RAN node shall, if supported, use it for the purpose of CPAC.

4. Use of S-NG-RAN node UE Slice Maximum Bit Rate IE:
- If the S-NG-RAN node UE Slice Maximum Bit Rate IE for a specific S-NSSAI is included in the S-NODE ADDITION REQUEST message, the S-NG-RAN node shall, if supported, store and use the received S-NG-RAN node UE Slice Maximum Bit Rate for all PDU sessions associated with the S-NSSAI for the concerned UE.

5. Use of QoS Mapping Information IE:
- For each DRB configured as MN-terminated split bearer/SCG bearer, if the QoS Mapping Information IE is included in the DRBs Admitted List IE in the PDU Session Resource Setup Response Info – MN terminated IE of the S-NODE ADDITION REQUEST ACKNOWLEDGE message, the M-NG-RAN node shall, if supported, use it to set DSCP and/or IPv6 flow label fields for the downlink IP packets which are transmitted from M-NG-RAN node to S-NG-RAN node through the GTP tunnels indicated by the UP Transport Layer Information IE.

6. Use of Coordination Assistance Information IE:
- If the E-UTRA Coordination Assistance Information IE or the NR Coordination Assistance Information IE is contained in the MR-DC Resource Coordination Information IE, the S-NG-RAN node shall, if supported, use the information to determine further coordination of resource utilisation between the S-NG-RAN node and the M-NG-RAN node.

Example Snippets from TDoc:
- "If the Estimated Arrival Probability IE is contained in the CHO Information SN Addition IE included in the S-NODE ADDITION REQUEST message, then the S-NG-RAN node may use the information to allocate necessary resources for the UE." [TDoc R3-231193]
- "If the Source NG-RAN Node ID IE is included in the S-NODE ADDITION REQUEST message, the S-NG-RAN node shall, if supported, use it to decide the direct data path availability with the indicated source NG-RAN node, and if the direct data forwarding path is available, include the Direct Forwarding Path Availability IE in the S-NODE ADDITION REQUEST ACKNOWLEDGE message." [TDoc R3-231193]
- "If the CG-CandidateList is included in the S-NG-RAN node to M-NG-RAN node Container IE in the S-NODE ADDITION REQUEST ACKNOWLEDGE message, the M-NG-RAN node shall, if supported, use it for the purpose of CPAC." [TDoc R3-231384]
- "If the S-NG-RAN node UE Slice Maximum Bit Rate IE for a specific S-NSSAI is included in the S-NODE ADDITION REQUEST message, the S-NG-RAN node shall, if supported, store and use the received S-NG-RAN node UE Slice Maximum Bit Rate for all PDU sessions associated with the S-NSSAI for the concerned UE." [TDoc R3-231384]
- "For each DRB configured as MN-terminated split bearer/SCG bearer, if the QoS Mapping Information IE is included in the DRBs Admitted List IE in the PDU Session Resource Setup Response Info – MN terminated IE of the S-NODE ADDITION REQUEST ACKNOWLEDGE message, the M-NG-RAN node shall, if supported, use it to set DSCP and/or IPv6 flow label fields for the downlink IP packets which are transmitted from M-NG-RAN node to S-NG-RAN node through the GTP tunnels indicated by the UP Transport Layer Information IE." [TDoc R3-231513]
- "If the E-UTRA Coordination Assistance Information IE or the NR Coordination Assistance Information IE is contained in the MR-DC Resource Coordination Information IE, the S-NG-RAN node shall, if supported, use the information to determine further coordination of resource utilisation between the S-NG-RAN node and the M-NG-RAN node." [TDoc R3-231513]
- "If the Estimated Arrival Probability IE is contained in the CHO Information SN Addition IE included in the S-NODE ADDITION REQUEST message, then the S-NG-RAN node may use the information to allocate necessary resources for the UE." [TDoc R3-231576]
- "For each DRB configured as MN-terminated split bearer/SCG bearer, if the QoS Mapping Information IE is included in the DRBs Admitted List IE in the PDU Session Resource Setup Response Info – MN terminated IE of the S-NODE ADDITION REQUEST ACKNOWLEDGE message, the M-NG-RAN node shall, if supported, use it to set DSCP and/or IPv6 flow label fields for the downlink IP packets which are transmitted from M-NG-RAN node to S-NG-RAN node through the GTP tunnels indicated by the UP Transport Layer Information IE." [TDoc R3-231576]

3GPP-R3-119-bis-e    Agenda Item 15.1 : General

3GPP-R3-119-bis-e    Agenda Item 15.2 : Support for MBS reception in RAN sharing scenarios

Technical differences between TDoc R3-231187 and TDoc R3-231197:

TDoc R3-231187:

- gNB-CU transfers MBS session information to gNB-DU if all network identifiers support the MBS service in SIB1.
- gNB-CU-CP allocates the same MRB for different MBS sessions delivering the same broadcast content in case of shared CU and DU.
- CU-CP provides assistance information to both DU for MRB resource usage in dis-aggregated gNB architecture.
- CU-CP provides OAM configured service-id(s) to DU during F1-AP Broadcast Context Setup procedure for determining TMGIs from different PLMNs supporting RAN sharing.
- MCCH is populated with multiple PLMN TMGIs associated with common MRB configuration.
- BROADCAST CONTEXT SETUP REQUEST messages have different TMGIs and same MBS RAN Sharing efficiency Information.

Example snippets from TDoc R3-231187:

- "gNB-CU transfers the information provided by 5GC which is used to identify the MBS sessions aimed at the same MBS service to gNB-DU if network provide all network identifiers (PLMNs, SNPNs) which support the MBS service in SIB1"
- "gNB-CU-CP allocates the same MRB for the different MBS session delivering the same broadcast content in case both CU and DU are shared."
- "CU-CP will provide this assistance information to both the DU to make it aware of which MRB resources are used for a given MBS Session ID in case of MBS RAN Sharing."
- "During the F1-AP Broadcast Context Setup procedure in DU, CU-CP has to provide OAM configured service-id(s) to DU to enable DU to determine which TMGIs from different PLMNs are supporting the RAN sharing and DU populates MCCH with multiple PLMN TMGIs associated with common MRB configuration."
- "BROADCAST CONTEXT SETUP REQUEST messages with different TMGIs and same MBS RAN Sharing efficiency Information."

TDoc R3-231197:

- Option 2 establishes a new GTP-U tunnel over F1 for sending data from a new selected NG-U tunnel in case of failure in user plane of selected NG-U tunnel.
- Option 2 only needs to establish one GTP-U tunnel over F1 for all NG-U tunnels to send data from a selected NG-U tunnel.
- NG-RAN node implementation handles different S-NSSAI received for the same shared service from different PLMNs in MOCN.

Example snippets from TDoc R3-231197:

- "If the failure happens in the user plane of the selected NG-U tunnel, a new GTP-U tunnel over F1 is set up for sending the data from a new selected NG-U tunnel."
- "For option 2, only one GTP-U tunnel over F1 for all NG-U tunnel is set up to send the data from a selected NG-U tunnel."
- "For MOCN, it is up to the NG-RAN node implementation on how to handle different S-NSSAI received for the same shared service from different PLMNs (i.e. same Associated Session ID)."

Technical differences among the TDocs are as follows:

- Solution 1: The AF may provide Associated Session ID additionally to the NG-RAN nodes via 5GC so that shared NG-RAN nodes can determine that multiple broadcast MBS sessions are transmitting the same content for the same MBS service. (Soln#2 and Soln#7 SSM option)
- Solution 2: The association of MBS session identifiers may be configured in NG-RAN, where there is no requirement on AF to provide associated session identifier. Shared DU selects the MRB PDCP configuration received from different gNB-CUs over F1 interface, in order to correlate the three Broadcast Session Request messages, each CU-CP should send the Associated Session ID to the shared-DU.
- MOCN: It is up to the NG-RAN node implementation on how to handle different S-NSSAI received for the same shared service from different PLMNs (i.e. same Associated Session ID).
- NGAP supports a resource sharing efficient scheme for broadcast delivery in RAN sharing.
- It is possible that different Area Session ID are configured for the same MBS data from different PLMNs, since the Area Session ID is allocated by the MB-SMF. Alternatively, the association of MBS session identifier may be configured in NG-RAN where there is no requirement on AF to provide associated session identifier. If the MBS Service Area IE is included in the BROADCAST CONTEXT SETUP REQUEST message, the gNB-DU shall take this information into account for shared F1-U tunnel assignment.
- The handling of different area session IDs allocated from different PLMNs and whether and how to handle different service areas associated with the area session IDs for local independent MBS session.
- The PDCP configuration coordination between gNB-CUs in case of multiple cell-ID sharing case were discussed.
- Whether the Associated Session ID is sufficient for the NG-RAN to identify multiple broadcast MBS Sessions via different CNs delivering the same content for location dependent broadcast service.
- For the first PLMN that is to create context in gNB-DU, it should follow the legacy procedure, with MBS Session ID1. For later joined PLMN, gNB-CU modifies the context by adding a list of MBS Session IDs additionally.
- Associated Session ID together with the MBS Session ID is used to help gNB to identify the same content of the different MBS broadcast session from different PLMNs. The Broadcast Session Modification Required procedure is used to notify the AMF on the Broadcast Session context modification, e.g., DL tunnel information at NG-RAN node side, for a broadcast MBS session.

Examples from the TDocs to support the difference highlighting are as follows:

- TDoc R3-231283: "The AF may provide Associated Session ID (e.g. SSM used by AF) additionally to the NG-RAN nodes via 5GC so that the shared NG-RAN nodes can determine that the multiple broadcast MBS sessions are transmitting same content for the same MBS service (i.e., Soln#2 and Soln#7 SSM option), or"
- TDoc R3-231283: "The association of MBS session identifiers may be configured in NG-RAN, where there is no requirement on AF to provide associated session identifier. Shared DU selecting the MRB PDCP configuration received from different gNB-CUs Over F1 interface, in order to correlate the three Broadcast Session Request messages, each CU-CP should send the Associated Session ID to the shared-DU."
- TDoc R3-231445: "It would be possible that the MBS Area Session IDs of different PLMNs are different allocated. BROADCAST CONTEXT SETUP REQUEST messages with different TMGIs and the same associated session ID to the gNB-DU."
- TDoc R3-231503: "Associated Session ID together the MBS Session ID is used to help gNB to identify the same content of the different MBS broadcast session from different PLMNs."

3GPP-R3-119-bis-e    Agenda Item 15.3 : Support for RRC_INACTIVE state

Option 1 for PTM configuration is supported, and group paging may be used to inform UE of network changes in PTM configurations. (TDoc R3-231188)

NG-RAN signaling supports service continuity for multicast session data in RRC_INACTIVE state, and UE can continue multicast reception without RRC state transitioning if configuration is available. (TDoc R3-231188)

During UE context retrieval, anchor gNB sends MBS UE context information and expected Multicast RRC_INACTIVE assistance information. (TDoc R3-231188)

The gNB-DU makes the decision on multicast reception in RRC_INACTIVE state per multicast session. (TDoc R3-231198)

QoS information, UE capability information, and UE request for multicast reception in RRC_INACTIVE state must be provided over F1 from gNB-CU to gNB-DU. (TDoc R3-231198)

Same or different PTM configurations can be used for multicast sessions in both RRC_CONNECTED and RRC_INACTIVE states. (TDoc R3-231198)

UE ID list and PTM configurations must be sent over F1 from gNB-DU to gNB-CU for multicast sessions in RRC_INACTIVE state. (TDoc R3-231198)

The PTM configuration of a multicast session can be applied to a certain area, and gNB-DU determines the PTM configuration. (TDoc R3-231198)

UE sends Resume Request message to NG-RAN when there is no signaling and data transmission in new NG-RAN, and last serving NG-RAN transfers UE context to new NG-RAN. (TDoc R3-231335)

If UE is first user in new NG-RAN, old NG-RAN transfers UE context to new NG-RAN in Retrieve UE context procedure. (TDoc R3-231335)

gNB-CU indicates gNB-DU to keep PTM transmission. (TDoc R3-231335)

MBS assistance information for MBS session consists of indication that UE is preferred to be kept in connected when receiving related MBS session data. (TDoc R3-231379)

UE is able to continue multicast reception without RRC state transitioning after cell reselection in RRC_INACTIVE state if configuration is available. (TDoc R3-231379)

gNB-DU should be configured to schedule PTM all the time for MBS session in accordance with support of RRC_INACTIVE UE, and releases all UE context including UE MRB when receiving UE CONTEXT RELEASE COMMAND message. (TDoc R3-231379)

Technical differences among TDocs:

1. Multicast CU to DU RRC Information: The gNB-CU should provide multicast CU to DU RRC Information, including the PDCP configuration of the MRB, similar to broadcast.

Example snippet from TDoc R3-231444: "Additionally, similar with broadcast, a Multicast CU to DU RRC Information should also be provided from the gNB-CU to the gNB-DU, which at least includes the PDCP configuration of the MRB."

2. Handover related enhancement: When the target cell is congested and the UE has only a multicast session ongoing, the target gNB can build a handover command directly moving the UE to RRC_INACTIVE and providing the PTM configuration. The gNB-CU needs to indicate whether MCCH is used for a multicast session.

Example snippet from TDoc R3-231444: "Since both RRC_INACTIVE and RRC_CONNECTED UEs are supported, the gNB-CU needs to indicate whether MCCH is used for a multicast session."

3. NG-RAN node may keep the UE in RRC_CONNECTED state: When MBS assistance information for a multicast session is received, the NG-RAN node may keep the UE in RRC_CONNECTED state when receiving the related MBS session data of the multicast session. This allows the UE to request unicast reception of the service before moving to a cell not providing the MBS broadcast service(s) using PTM transmission.

Example snippet from TDoc R3-231444: "In the stage 2, we add a sentence as ‘when receives MBS assistance information for a multicast session, the NG-RAN node may keep the UE in RRC_CONNECTED state when receiving the related MBS session data of the multicast session’."

4. Core Network Assistance Information for RRC INACTIVE IE: If the Core Network Assistance Information for RRC INACTIVE IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the NG-RAN node shall, if supported, store this information in the UE context and use it for the RRC_INACTIVE state decision and RNA configuration for the UE and RAN paging if any for a UE in RRC_INACTIVE state.

Example snippet from TDoc R3-231504: "Also in the procedural text of, it says (take PSRA for example) which validates our previous observation: If the Core Network Assistance Information for RRC INACTIVE IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the NG-RAN node shall, if supported, store this information in the UE context and use it for the RRC_INACTIVE state decision and RNA configuration for the UE and RAN paging if any for a UE in RRC_INACTIVE state."

5. Preferential treatment within the multicast group: This IE indicates that the UE requires preferential treatment within the multicast group, guaranteeing steady and prompt provision of system resources for data transmission and reception. It is up to NG-RAN implementation to decide whether or not to release UE to RRC_INACTIVE.

Example snippet from TDoc R3-231504: "We suggest considering the following two possible options to describe this IE in semantic description like (that complies with existing spec, SA2 guidance and RAN's implementation flexibility): • This IE indicates that the UE requires preferential treatment within the multicast group, guaranteeing steady and prompt provision of system resources for data transmission and reception; it is up to NG-RAN implementation to decide whether or not to release UE to RRC_INACTIVE."

6. MCCH is used to deliver the updated PTM configuration for multicast reception in RRC_INACTIVE: The gNB implementation uses MCCH to deliver the updated PTM configuration for multicast reception in RRC_INACTIVE state.

Example snippet from TDoc R3-231504: "MCCH is used to deliver the updated PTM configuration for multicast reception in RRC_INACTIVE. gNB implementation. RRC_INACTIVE state."

7. Service continuity for UEs receiving multicast session data in RRC_INACTIVE: NG-RAN signaling supports service continuity for UEs receiving multicast session data in RRC_INACTIVE. UE will keep receiving multicast session data in RRC_INACTIVE to support service continuity through monitoring MCCH after cell reselection based on the premise that the configuration of the new cell is available for the UE.

Example snippet from TDoc R3-231809: "After checking the conclusions from RAN2#120 meeting, they give their answer on this issue and the conclusions are as follows: We will have a mixed approach and we start with the following: When NW configures UE to continue the multicast reception in INACTIVE state, NW provides the PTM configuration for the activated multicast session via the RRC dedicated signaling, at least for the serving cell (FFS other cases). Combined the conclusion of RAN2 and RAN3, UE will keep receiving multicast session data in RRC_INACTIVE to support service continuity through monitoring MCCH after cell reselection based on the premise that the configuration of the new cell is available for the UE. Optionally, Multicast MCCH configuration for the serving cell can also be provided in dedicated signaling."

TDoc R3-231284:

- Differences in the Target Cell ID field, which is either optional or mandatory depending on the use case
- The presence of DRBs to QoS Flows Mapping List for inter-system handovers to 5G
- The identification of the TNL address used by the source SN node for direct data forwarding towards the target NG-RAN node

Example snippets:
- "9.3.1.73 - Index to RAT/Frequency Selection Priority O"
- "9.3.1.34 - E-RAB Information List 0..1 For inter-system handovers to 5G."
- "9.3.2.4 Identifies the TNL address used by the source SN node for direct data forwarding towards the target NG-RAN node"

TDoc R3-231398:

- The use of SEQUENCE (SIZE(1..maxnoofMBSSessions)) OF MBS-SessionInformation-Item for a specific use case
- The inclusion of optional fields such as mBS-Area-Session-ID, active-MBS-SessioInformation, and iE-Extensions
- The use of ProtocolExtensionContainer for additional custom fields

Example snippets:
- "SEQUENCE (SIZE(1..maxnoofMBSSessions)) OF MBS-SessionInformation-Item"
- "mBS-Area-Session-ID MBS-Area-Session-ID OPTIONAL"
- "iE-Extensions ProtocolExtensionContainer { { MBS-SessionInformation-Item-ExtIEs} } OPTIONAL"

3GPP-R3-119-bis-e    Agenda Item 16.1 : General

3GPP-R3-119-bis-e    Agenda Item 16.3 : Support Service Continuity Enhancements

1. Inter-gNB direct-to-indirect/indirect-to-indirect path switching:
- Proposal 1: In inter-gNB direct to indirect path switching, the source gNB indicates a candidate relay UE list with a decreasing order of preference to the target gNB via the HANDOVER REQUEST message.

- Proposal 4: In inter-gNB indirect-to-indirect path switching, the HO preparation between Source gNB and Target gNB is performed in the same way as inter-gNB direct to indirect path switching, without additional RAN3 spec impact.

2. N2 based inter-gNB d2i path switch procedure:
- The N2 HO required message from S-gNB to S-AMF and HO request message from T-AMF to T-gNB should be enhanced to include the remote UE L2 ID and a list of candidate relay UE IDs of a target cell.

- The reconfiguration to target U2N Relay UE is performed among target U2N Relay UE, the target gNB-DU, and the target gNB-CU, if the target U2N Relay UE is in RRC_CONNECTED state.

- The target gNB allocates a local ID for the remote UE and provides the path switch configuration, PC5 relay RLC channel configuration, and bearer mapping configuration to the remote UE in the HandoverCommand message.

- The Uu measurement configuration and measurement report signaling is performed between U2N Remote UE and source gNB-CU to evaluate both relay link measurement and Uu link measurement.

3. Measurement results for a list of candidate relay UEs:
- Proposal 1: Measurement results for a list of candidate relay UEs included in the handover request can be provided to the target gNB to assist in selecting the target relay UE.

- Option 2: target gNB is allowed to select a candidate relay UE not included in the list. If no candidate relay UE in the list is selected and another relay UE cannot be selected (option 1 is agreed), the target gNB may transmit the handover preparation failure message to the source gNB.

- During direct-to-indirect and indirect-to-indirect path switch procedures, the source gNB sends a list of candidate relay UEs belonging to the same target cell in the HO REQ message.

4. XnAP HANDOVER REQUEST message enhancement:
- Per the RAN3 agreement, the XnAP HANDOVER REQUEST message needs to be enhanced to include the remote-UE ID and a list of candidate relay-UE IDs.

- Similar to Xn-handover, target gNB can include the assigned local ID, target Relay-UE ID, and SRAP configuration in the RRC container, so there is no impact to the NGAP HANDOVER REQUEST ACKNOWLEDGE message, and HANDOVER COMMAND message.

- To minimize the impact on the AMF, the Remote UE L2 ID and Relay UE L2 ID can be added in the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE.

- Upon the reception of the XnAP HANDOVER REQUEST message including a list of candidate Relay-UEs, target gNB selects the target Relay-UE, generates the SRAP configuration, and encapsulates it in the HandoverCommand message.

- For example, the source gNB may rank the candidate Relay UEs based on the sidelink measurement reported by the UE.

1. Timing of RRC reconfiguration for release of source relay UE during intra-gNB indirect-to-indirect path switching can vary based on gNB implementation.
- "RRC reconfiguration message for release for source relay UE can be sent any time after source gNB sends RRC reconfiguration message to remote UE based on gNB implementation" (Observation 2, TDoc R3-231558)

2. Potential packet loss in UL data during inter-gNB i2d/i2i path switch/HO scenario.
- "RAN2 consider that lossless data delivery in the inter-gNB i2x cases needs to be addressed" (Agreement 2.2, TDoc R3-231558)
- "the remote UE may not re-transmit all the un-successfully delivered PDCP SDUs to the target gNB, even the PDCP status report from the target gNB" (Observation 5, TDoc R3-231558)

3. Use of Estimated Arrival Probability IE in HANDOVER REQUEST message for resource allocation by target NG-RAN node.
- "If the Estimated Arrival Probability IE is contained in the Conditional Handover Information Request IE included in the HANDOVER REQUEST message, then the target NG-RAN node may use the information to allocate necessary resources for the incoming CHO" (TDoc R3-231571)

4. Ability for target NG-RAN node to store Redundant PDU Session Information IE for each PDU session and set up redundant user plane if supported.
- "the target NG-RAN node shall, if supported, store the received information in the UE context and set up the redundant user plane for the concerned PDU session" (TDoc R3-231571)

5. Use of MRB ID IE and MRB Progress Information IE in MBS Mapping and Data Forwarding Request Info from source NG-RAN node IE for data forwarding and resource establishment by target NG-RAN node.
- "the target NG-RAN node shall use the MRB ID IE and, if included, the MRB Progress Information IE which includes the highest PDCP SN of the packet which has already been delivered to the UE for the MRB, to decide whether to apply data forwarding for that MRB and to establish respective resources" (TDoc R3-231571)

6. Unclear details on supporting Option 2a in direct/indirect-to-indirect path switch procedures, including inclusion of Remote UE L2 ID, serving cell of candidate relay UEs, and list of candidate target relay UE IDs in HANDOVER REQUEST message.
- "the stage 3 details on how to support Option 2a in direct/indirect-to-indirect path switch procedures (e.g., how to include the Remote UE L2 ID, serving cell of the candidate relay UEs and a list of candidate target relay UE IDs in the HANDOVER REQUEST message) need to be further discussed" (Observation, TDoc R3-231693)

7. Application of L2 U2N Remote UE switching procedure for direct to indirect path switch with RRCReconfiguration message sent from gNB to L2 U2N Relay UE after it enters RRC_CONNECTED state.
- "the procedure for L2 U2N Remote UE switching to indirect path in Figure 16.12.6.2-1 can be also applied for the case that the selected L2 U2N Relay UE for direct to indirect path switch is in RRC_IDLE or RRC_INACTIVE with the exception that the RRCReconfiguration message is sent from the gNB to the L2 U2N Relay UE after the L2 U2N Relay UE enters RRC_CONNECTED state" (Observation, TDoc R3-231693)

8. Sending of list of candidate relay UEs belonging to the same target cell in the HO REQUEST message during inter-gNB handover for direct to indirect and indirect to indirect path switch procedures.
- "During direct to indirect and indirect to indirect path switch procedures, the source gNB sends a list of candidate relay UEs belonging to the same target cell in the HO REQ message" (Agreement, TDoc R3-231793)
- "when the HO is performed, target gNB may retransmit the data packets reference to the PDCP status report from the remote UE" (Agreement, TDoc R3-231793)

Overall, the technical differences among the TDocs involve various aspects of handover procedures and inter-gNB path switching, including timing and details of RRC reconfiguration, potential for packet loss, use of certain IEs for resource allocation and redundancy, and inclusion of candidate relay UEs in HO REQUEST message.

3GPP-R3-119-bis-e    Agenda Item 16.4 : Multi-path Support

- In Rel-17, the path switch procedure is distinguished from the indirect path addition procedure by including an indirect path addition indication in the message that contains the relay UE ID, remote UE local ID, and timer(s) for multi-path establishment.
- The gNB-CU needs to indicate the relay UE's gNB-DU about the path addition Proposal 9 in the indirect path addition procedure.
- Depending on the radio bearer type, gNB-CU will indicate gNB-DU1 to provide the Uu RLC bearer configurations and/or indicate gNB-DU2 to provide the PC5 relay RLC channel configuration for a radio bearer in the path addition procedure.
- F1AP needs to be enhanced to inform the gNB-DU about the addition of 2nd path, or modifying/removal of a specific path.
- The direct path and indirect path cannot be configured for a remote UE simultaneously in this release, depending on RAN2 decision.
- The UE Context Release procedure may be performed before the UE Context Setup procedure.
- The Uu measurement configuration and measurement report signalling is performed between remote UE and gNB-CU to evaluate both relay link measurement and Uu link measurement.
- In addition, based on the measurement configuration and results, the gNB can configure the change of the direct path to a different cell of the same gNB and keep the indirect path.

Example snippets from the TDoc:

- "To distinguish with the path switch procedure in Rel-17, gNB-CU should also contain the indirect path addition indication in the message, which includes the relay UE ID, remote UE local ID and the timer(s) needed for multi-path establishment."
- "Depending on the radio bearer type, gNB-CU will indicate gNB-DU1 to provide the Uu RLC bearer configurations and/or indicate gNB-DU2 to provide the PC5 relay RLC channel configuration for a radio bearer in the path addition procedure."
- "F1AP need to be enhanced to inform the gNB-DU about the addition of 2nd path, or modifying/removal of a specific path."
- "The Uu measurement configuration and measurement report signalling is performed between remote UE and gNB-CU to evaluate both relay link measurement and Uu link measurement."
- "In addition, based on the measurement configuration and results, the gNB can configure: Either the change of the direct path to a different cell of the same gNB and keep the indirect path."

The technical differences among the TDocs are as follows:

1. Inter-DU paths: TDoc R3-231507 describes a scenario where gNB has two inter-DU paths (i.e. indirect and direct paths) with the remote UE. When the channel condition of either path deteriorates, gNB may switch from the worse path to a new path with good channel condition from a different gNB-DU. This is not mentioned in the other TDocs.

Example from TDoc R3-231507: "gNB may switch from the worse indirect path to a new indirect path with good channel condition from a different gNB-DU."

2. U2N Relay UE reconfiguration: TDoc R3-231507 mentions that reconfiguration to target U2N Relay UE is performed among the target U2N Relay UE, the gNB-DU3, and gNB-CU if the target U2N Relay UE is in RRC_CONNECTED state. This is not mentioned in the other TDocs.

Example from TDoc R3-231507: "The reconfiguration to target U2N Relay UE is performed among the target U2N Relay UE, the gNB-DU3 and gNB-CU, if the target U2N Relay UE is in RRC_CONNECTED state."

3. UE CONTEXT SETUP REQUEST: TDoc R3-231507 mentions that gNB-CU sends the UE CONTEXT SETUP REQUEST message for the U2N Remote UE to gNB-DU3, which contains the path switch configuration at least. This is not mentioned in the other TDocs.

Example from TDoc R3-231507: "gNB-CU sends the UE CONTEXT SETUP REQUEST message for the U2N Remote UE to gNB-DU3, which contains the path switch configuration at least."

4. Intra-gNB-DU scenario: TDoc R3-231694 mentions that the procedure for the intra-gNB-DU scenario, where both direct and indirect paths are served by the same gNB-DU, is the same as the direct path addition procedure as defined in clause 8.xx.1-1, but the UE Context Modification procedure is used in Steps 3 and 4. This is not mentioned in the other TDocs.

Example from TDoc R3-231694: "The procedure for the intra-gNB-DU scenario, where both direct and indirect path are served by the same gNB-DU, is the same as the direct path addition procedure as defined in clause 8.xx.1-1 but the UE Context Modification procedure is used in Steps 3 and 4."

5. UE CONTEXT MODIFICATION RESPONSE: TDoc R3-231794 mentions that gNB-DU responses with the UE CONTEXT MODIFICATION RESPONSE message to gNB-CU, which contains the configurations used for indirect path and direct path. This is not mentioned in the other TDocs.

Example from TDoc R3-231794: "gNB-DU responses with the UE CONTEXT MODIFICATION RESPONSE message to gNB-CU, which contains the configurations used for indirect path. gNB-DU responses with the UE CONTEXT MODIFICATION RESPONSE message to gNB-CU, which contains the configurations used for direct path."

6. Uu logical channels: TDoc R3-231694 mentions that for Scenario 2, different Uu logical channels are configured for identification of data directed to/originating from the relay UE and data relayed from/to the remote UE over the Uu link of the indirect path, as in Rel-17. However, gNB should identify the association between the 2 UEs before the indirect path adding. This is not mentioned in the other TDocs.

Example from TDoc R3-231694: "For Scenario 2, different Uu logical channels are configured for identification of data directed to/originating from the relay UE and data relayed from/to the remote UE over the Uu link of the indirect path, as in Rel-17. However, gNB should identify the association between the 2 UEs before the indirect path adding."

3GPP-R3-119-bis-e    Agenda Item 17 : NR NTN enhancements WI