EP4646876A1

EP4646876A1 - Method of handling handover for extended reality and media services for 5g systems

Info

Publication number: EP4646876A1
Application number: EP24712650.1A
Authority: EP
Inventors: Ching-Yu Liao; Chih-Hsiang Wu
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2023-02-10
Filing date: 2024-02-09
Publication date: 2025-11-12
Also published as: CN120858614A; WO2024168211A1

Abstract

Methods and devices in a wireless network wireless communication are directed to coordinating extended reality and/or media (XRM) service capabilities across a user equipment, UE, (102) a target radio access network (RAN node), and a core network (CN), when a handover of the UE occurs. The target RAN node (104) sends (1001 ) to the CN, when a handover procedure is initiated, a message including an indication associated with the target RAN node extended reality and/or media, XRM, service capabilities. The RAN node enables (1022) a packet data unit, PDU, set based quality- of-service (QoS) handling of XRM data communicated with the CN and forwards (1026) the XRM data, through a PDU session between the UE and the CN, according to the PDU set based QoS handling.

Description

METHOD OF HANDLING HANDOVER FOR EXTENDED REALITY AND MEDIA SERVICES FOR 5G SYSTEMS

FIELD OF THE DISCLOSURE

[0001] This document generally describes methods and devices operating in wireless communication systems such as (but not limited to) the ones described in 5G standard documents, known as 3^rd Generation Partnership Project (3GPP) communication systems.

BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the context of the disclosure and the technical problems. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] In wireless communications, 5G networks are configured to support a variety of services with highly variable Quality-of-Service (QoS) requirements. This flexibility makes the 5G networks suitable for a myriad of extended reality (XR) and/or media (XRM) services, which were not previously possible. Currently, for the XRM data traffic, between a user equipment (UE) and a core network (CN) device, a session management function (SMF) hosted by the CN element determines whether to enable a packet data unit (PDU) set based QoS handling, based on policy and charging control (PCC) rules that contain PDU set based QoS parameters.

[0004] However, it is not clear how to provision QoS for the PDU set, when a source radio access network (RAN) node, serving the UE, initiates a handover procedure of the UE to a target RAN node and the handover is based on an Xn interface or Ng interface. Also, it is not clear how to handle the QoS for the PDU set when the target and source RAN nodes differ in terms of their PDU set based handling capabilities. SUMMARY

[0005] According to an embodiment, when the source RAN node hands over the UE to the target RAN node, the target RAN node is configured to send to the SMF an indication associated with target RAN node XRM service capabilities. This indication may be part of a path switch request message, which is exchanged between the target RAN node and the SMF, for an Xn interface based handover. Based on this indication, which may indicate whether the target RAN node supports (or does not support) an XRM service or PDU set based QoS handling, the SMF enables or modifies QoS parameters for a PDU session, providing XRM service supported by the source RAN node, transferred to the target RAN node. Thus, the CN element is configured to handle (by turning on or off PDU set based handling at the RAN nodes) an XRM data traffic during an Xn based handover procedure when one of the source RAN node and the target RAN node does not support XRM data traffic and the other supports the XRM data traffic.

[0006] According to another embodiment, when the source RAN node hands over the UE to the target RAN node, the target RAN node is configured to send, to an access and mobility management function (AMF), which is hosted by the CN element, an indication associated with target RAN node XRM’s service capabilities or PDU set based QoS handling. This indication may be part of a handover request acknowledgment message, which is exchanged between the target RAN node and the AMF during an Ng interface based handover. Based on this indication, the AMF informs the SMF whether or not the target RAN node can provide XRM service (or PDU set based QoS handling) to the UE as the source RAN node does. The SMF then enables or modifies QoS parameters for a PDU session, initiated at the source RAN node and continued at the target RAN node. Thus, the CN (which hosts the AMF, SMF, and other functionalities) is configured to handle XRM data exchange during an Ng based handover procedure even when one of the source RAN node and the target RAN node does not support XRM data traffic and the other one supports the XRM data traffic. [0007] For each of the above embodiments, the SMF may activate the PDU set based QoS parameters based on a 5G system (5GS) registration, i.e. , whether the UE moves from a non-5GS system to the 5GS system or vice versa.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments.

[0009] FIG. 1 is a block diagram of a wireless communication system in which a UE and CN perform methods according to various embodiments.

[0010] FIG. 2 is a signal diagram indicating how the CN configures a source RAN node supporting XRM service capabilities for PDU set based QoS handling.

[0011] FIG. 3 is a signal diagram indicating how the CN configures a source RAN node not supporting XRM service capabilities for PDU set based QoS handling.

[0012] FIG. 4 is a signal diagram for Xn based handover that leverages RAN node XRM service capabilities according to an embodiment.

[0013] FIG. 5 is a signal diagram for Xn based handover in which the target RAN node indicates XRM capabilities in a path switch request message according to an embodiment.

[0014] FIG. 6 is a signal diagram for Xn based handover in which the target RAN node does not indicate XRM capabilities according to an embodiment.

[0015] FIG. 7 is a signal diagram for N2 based handover that leverages RAN node XRM service capabilities according to an embodiment.

[0016] FIGs. 8A to 8C are signal diagrams for UE registration to a non-5GS system according to an embodiment.

[0017] FIGs. 9A to 9B are signal diagrams for UE registration to a 5GS system according to an embodiment.

[0018] FIG. 10 is a flow chart of a target RAN node based method reporting XRM service capabilities according to an embodiment.

[0019] FIG. 11 is a flow chart of a CN based method receiving XRM service capabilities according to an embodiment. DETAILED DESCRIPTION

[0020] Methods and devices described in this section embody techniques related to XRM services in a wireless communication system when a source RAN node hands over a UE to a target RAN node. The embodiment descriptions in this section refer to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The detailed descriptions do not preclude other embodiments within the scope of the appended claims, for example, applying one or more methods to future RAN nodes that might not be an NG-RAN node. The embodiments are not limited to the described configurations but may be extended to other arrangements. [0021] Reference throughout this section to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

[0022] Currently, the 5G system (5GS) lacks established procedures for some aspects of the interaction between the system and XRM applications, for example, provisioning QoS for UEs using XRM services when a source RAN node performs a handover procedure to a target RAN node and the support of XRM service capabilities for the PDU Set based QoS handling, between the source and target RAN nodes, may be different (e.g., one RAN node supports XRM traffic and the other does not). Various working groups of 3GPP develop procedures for the 5G system to support advanced media services, e.g., High Data Rate Low Latency (HDRLL) services, ARA/R/XR services, and tactile/multi-modality communication services. The objectives of these working groups include, among others, enhancements to the network exposure procedures to support interaction between 5GS and XRM applications, and enhancements of QoS and policy for XRM service transmission.

[0023] As part of these developments, a PDU set was defined as including one or more PDUs carrying an application layer payload, which is associated with one unit of information, such as, for example, a video frame or video slice. A QoS flow with PDU Set based QoS parameters may be enabled with a PDU set based QoS handling by the RAN node. All the PDUs of a PDU set are transmitted with the same QoS flow. The PDU set QoS parameters (e.g., PDU set delay budget, PDU set error rate, etc.) are used to support PDU set based QoS handling in the RAN node. At least one PDU Set QoS parameter shall be sent to the RAN node to enable PDU set based QoS handling. [0024] A PDU set based QoS handling by the RAN node is determined by the PDU set QoS parameters (which are included in the QoS profile of the QoS flow, as specified in 3GPP Technical Specification (TS) 23.501 ) and PDU set information in the GTP-U header (GTP-U is a protocol employed by 5G for the user plane data transfer) provided by the PDU session anchor (PSA) user plane function (UPF). Note that the PSA UPF is typically the last UPF in the chain of UPFs that connect the UE to a data network (DN). The SMF instructs the UPF to perform PDU set identification and marking and may provide the UPF with the Protocol Description indicating the header (e.g., real time transport protocol (RTP)/secure RTP (SRTP)) and payload type (e.g. H.264) used by the service data flow(s) of a media stream from the application server. Based on the instructions from the SMF, for each downlink (DL) PDU received on an N6 interface for which PDU set based QoS handling should be performed, the PSA UPF applies the rules for PDU set identification and provides PDU set information, which is available to the RAN node in the GTP-U header.

[0025] To achieve XRM services support for PDU set based QoS handling in a 5G system, the RAN node needs to be aware of XRM services provided by the CN and vice versa. The RAN node can be configured to handle PDU sets based on PDU set QoS parameters in the QoS profile if the SMF provides this info to the RAN node, over the N2 interface. Also, the RAN node needs to receive the PDU set information from the UPF, over the N3 interface, for the downlink XRM traffic, or to receive this information from the UE, over the Uu interface, for the uplink XRM traffic.

[0026] The 5G core (5GC) handles QoS provisioning based on the RAN node’s XRM services capabilities support for PDU set based QoS handling. The SMF performs QoS flow binding based on a service data flow, configures the UPF with rules for PDU set identification and marking, and provides QoS profiles, including QoS parameters, to the RAN node. Thus, the SMF needs to be aware of the RAN node’s XRM service capabilities support for PDU set based QoS handling. In addition, when mobility events happen, which result in a RAN node change, e.g., handover from the source RAN node to the target RAN node, the SMF requires assistance information for adapting to the change of the serving RAN node.

[0027] Before discussing various solutions to the problems noted above, a possible 5GS 100 is introduced, as illustrated in FIG. 1. Wireless communication system 100 includes a UE 102, a first base station (BS) 104, a second BS 106, and a CN element 110. The BSs 104 and 106 may operate in a RAN 105 connected to the CN element 110. The CN element 110 may be implemented as an evolved packet core (EPC) 111 (i.e. , non-5G system) or a 5G core (5GC) 160, for example. The CN element 110 may also be implemented as a sixth generation (6G) core in another example. [0028] The first BS 104 covers a first cell 124 and a second cell 125, and the second BS 106 covers a cell 126 in this example. If the first BS 104 is a gNB, the cells

124 and 125 are an NR cell. If the first BS 104 is an ng-eNB or eNB, the cells 124 and

125 are an evolved universal terrestrial radio access (E-UTRA) cell. The same is valid for the second BS 106. The cells 124, 125, and 126 may be in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, the RAN 105 can include any number of BSs, and each of the BSs can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the BSs 104 and 106. Each of the BSs 104, 106 may connect to the CN element 110 via an interface (e.g., S1 or Ng interface, i.e., CN-based interface). The BSs 104 and 106 may also be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting RAN node nodes (i.e., RAN node to RAN node interface).

[0029] Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. SGW 112 in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management Function (AMF) 164, and/or a Session Management Function (SMF) 166. Each of these functions may be hosted by a corresponding processor or a common processor. Among other functionalities, UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., AMF 164 is configured to manage authentication, registration, paging, and other related functions, and SMF 166 is configured to manage PDU sessions.

[0030] Because cells 124, 125, and 126 can partially overlap, the UE 102 can select, reselect, or hand over from one of the cells 124, 125, and 126 to another. To directly exchange messages or information (e.g., related to the handover procedure), the first BS 104 and second BS 106 may support an X2 or Xn interface, i.e. , a dedicated protocol for exchanging messages between the BSs without involving the CN element 110. In addition, the BSs are connected through Ng interfaces to the CN element 110, which may connect to any suitable number of BSs supporting NR cells and/or EUTRA cells.

[0031] The first BS 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example implementation includes a processor 132 to process data that the first BS 104 will transmit in the downlink (DL) direction, or process data received by the BS 104 in the uplink (UP) direction. The processing hardware 130 can also include a transmitter 136 configured to transmit data in the DL. The processing hardware further can include a receiver 134 configured to receive data in the uplink direction. The processing hardware 130 can also include a storage media 138 for storing instructions that are executed by the processor 132. CN element 110 can include generally similar components. In particular, components 140, 142, 144, 146, and 148 of the CN element 110 can be similar to the components 130, 132, 134, 136, and 138, respectively. [0032] The UE 102 is equipped with processing hardware 150 that can include one or more general-purpose processors such as CPUs and non-transitory computer- readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units. The processing hardware 150 may include a processor 152 to process data that the UE 102 will transmit in the UP, or process data received by UE 102 in the DL. The processing hardware 150 may also include a transmitter 156 configured to transmit data in the DL. The processing hardware may further include a receiver 154 configured to receive data in the UP. The processing hardware 150 may also include a storage media 158 for storing instructions that are executed by the processor 152.

[0033] Mechanisms for dealing with the XRM data traffic situations discussed above are disclosed, based on system 100, in the following embodiments. The embodiments include a case in which the UE handover is from a source RAN node, which supports PDU set based QoS handling, to a target RAN node, which does not support PDU set based QoS handling. The embodiments further include a case in which the UE handover is from a source RAN node, which does not support PDU set based QoS handling, to a target RAN node, which supports PDU set based QoS handling. In another embodiment, a case in which the UE deregisters from a 5GS and registers to a non-5G system (or vice versa) is disclosed.

[0034] Thus, the following embodiments discuss mechanisms to address the abovementioned XRM data traffic related issues for the 5GS during handover, to provision PDU set based QoS to the UE based on the UE’s XRM services capabilities and RAN node’s XRM services capabilities for PDU set based QoS handling. In one embodiment, the SMF is configured to determine whether to activate/deactivate the PDU set based QoS handling at the PSA UPF, based on one or more of the following criteria: 5GS registration, access type is 3GPP access, PDU session type is internet protocol (IP), PDU session request type is ‘Initial request’ or ‘existing PDU Session’, non-roaming and local breakout, and/or UE state transition, e.g., between connection management (CM)-ldle and CM-Connected states, between radio resource control (RRC)-lnactive and RRC-Connected states. [0035] While disclosing the various features proposed for the 5GC, the following conditions/scenarios are assumed to be true: the RAN node may or may not support RAN node’s XRM services capabilities for PDU set based QoS handling, the UE may or may not support UE’s XRM services capabilities for the PDU set based QoS handling, and XRM includes XR and/or media services.

[0036] According to an embodiment, the registration procedure used by the UE to connect to the 5GS may be used/modified/adapted/configured to provide XRM service capabilities. For example, during the registration procedure, the AMF determines whether the UE is authorized to use XRM services, based on UE's XRM service capability and/or the XRM service authorization. This information may be included in the subscription data received by the AMF from the unified data management (UDM), as specified in 3GPP TS 23.501. If the registration procedure is successful, the UE can request a PDU session establishment procedure and an RAN node capable of XRM services, i.e. , an RAN node that can perform PDU set based QoS handling for QoS flows, during a PDU session which is based on the XRM service authorization and information received from the SMF via N2 interface and GTP-U header received via N3 interface, from the UPF.

[0037] The following embodiment discloses modifications to an existing PDU session establishment procedure in the context of XRM data handling. After the CN registered the UE to enable XRM services, the UE may request a PDU session establishment procedure and an RAN node capable of XRM services may perform PDU set based QoS handling for the QoS flows in an established PDU session.

[0038] If the UE context stored by the RAN node include the UE authorization for XRM service, the RAN node may indicate, according to this embodiment, its XRM service capability for PDU Set based QoS handling to the SMF, via AMF, in the PDU session establishment or modification procedures. In other words, the PDU session establishment or modification procedures are modified to report the RAN node service capability for PDU Set based QoS handling to the SMF. Note that the currently used PDU session establishment procedure and the PDU session modification procedure are defined in 3GPP TS 23.502. [0039] According to this embodiment, the RAN node’s XRM service capability for PDU Set based QoS handling is shared with the SMF, via AMF, using two options. For the first option, the SMF queries the RAN node’s XRM service capability for PDU Set based QoS handling at the AMF and subscribes to the AMF notification for RAN node’s XRM service capability for PDU Set based QoS handling in the event that the serving RAN node is changed for the UE. For the second option, the SMF directly queries the RAN node’s XRM service capability for PDU Set based QoS handling at the RAN node, via AMF, using, for example, a Namf_N2lnfoSubscribe message. In a respond message, the RAN node sends the XRM service capabilities for PDU Set based QoS handling in, for example, Namf_N2lnfoNotify message to the SMF, via AMF.

[0040] FIG. 2 illustrates a situation for which the RAN node supports XRM service capabilities for PDU set based QoS handling while FIG. 3 illustrates a situation for which the RAN node does not support XRM service capabilities for PDU set based QoS handling. More specifically, FIG. 2 shows the message flows 200 between the UE 102, first BS 104 (the terms BS and RAN node are used interchangeably in the following embodiments), and the CN element 110. The first BS 104 sends 202 a BS-to- CN message to CN element 110, e.g., using a non-UE associated or UE-associated N2 message. Different from the existing PDU establishment procedure, the BS-to-CN message is modified to include the RAN node’s XRM service capabilities for PDU set based QoS handling or a related indication for indicating the first BS support for PDU set based QoS handling. UE 102 communicates 204 with CN element 110 via the first BS 104, e.g., for registration request procedure. UE 102 initiates 206 PDU session establishment request procedure or PDU session modification request procedure with the CN element 110.

[0041] In response to the session-related request in 206, the first BS 104 may determine to enable/disable PDU Set based QoS handling by additionally taking into account UE’s XRM service capabilities for PDU Set based QoS handling. The first BS 104 may obtain the information of UE’s XRM service capabilities for PDU set based QoS handling from the CN element 110, which optionally sends 208 a CN-to-BS message to the first BS 104. This message, different from the existing procedures, includes UE’s XRM service capabilities for PDU set based QoS handling (which are provided, for example, by the UE to the CN element during the registration procedure). Alternatively, the first BS 104 may obtain the UE’s XRM service capabilities for PDU Set based QoS handling from optionally sending 210 a UE capability enquiry to UE 102, and the UE 102 replies 212 with the UE capability information.

[0042] Continuing with FIG. 2, CN element 110 sends 214 PDU session resource setup/modify request message to the first BS 104, including CN tunnel info for uplink user plane traffic transmission between the first BS 104 and CN element 110, and PDU set QoS information, e.g., QoS profiles with QoS flow ID, and downlink/uplink PDU set based QoS parameters, to set up corresponding data radio bearers (DRBs) for the given UE 102. BS 104 sends 216 RRC reconfiguration message to the UE 102 to reconfigure the UE to establish the necessary RAN node resources related to the QoS rules for the PDU session request and the UE replies 218 with a RRC reconfiguration complete message to indicate the completion of this process. The first BS 104 replies 220 to CN element 110 with PDU session resource setup/modify response message to provide RAN node’s XRM service capabilities for PDU Set based QoS handling and access network (AN) tunnel info for DL user plane traffic transmission between the first BS 104 and CN element 110.

[0043] Both CN element 110 and first BS 104 enable 222, 224 PDU set based QoS handling for XRM data communication in the downlink direction based on RAN node’s XRM services capabilities for downlink PDU Set based QoS handling and optional UE’s XRM capabilities. UE 102 communicates/exchanges 226 XRM data with the CN element 110 via the first BS 104, where each of CN element 110 and first BS 106 performs a PDU set based QoS handling for QoS flows associated with XRM services for the downlink direction. For the uplink direction, the first BS 104 enables 222 PDU set based QoS handling for XRM data communication based on RAN node’s XRM services capabilities for uplink PDU set based QoS handling and optional UE’s XRM capabilities. The steps 202 to 226 shown in FIG. 2 are part of an XRM data communication procedure 290.

[0044] For the case 300 in which the first BS 104 does not support XRM data transmission, which is illustrated in FIG. 3, the first BS 104 sends 301 a BS-to-CN message to CN element 110, e.g., using non-UE associated or UE-associated N2 message, and the message either does not include RAN node’s XRM service capabilities for PDU set based QoS handling or includes an indication that XRM service capabilities for PDU set based QoS handling are not supported by the RAN node 104. Steps 204 to 212 are similar to those shown in FIG. 2.

[0045] In the downlink direction, CN element 110 sends 315 a PDU session resource setup/modify request message to the first BS 104, including CN tunnel info for uplink user plane traffic transmission between the first BS 104 and CN element 110, and PDU set QoS information, e.g., QoS profiles with QoS flow ID, and PDU set based QoS parameters, to setup corresponding DRBs for the given UE 102. Steps 216 and 218 are similar to those shown in FIG. 2. The first BS 104 replies 220 to CN element 110 with PDU session resource setup/modify response message that does not include the first BS’s XRM service capabilities for PDU set based QoS handling or includes an indicator that expresses that the first BS’s XRM service capabilities do not support PDU set based QoS handling. Accordingly, CN element 110 disables 325 the PDU set based QoS handling for QoS flows of XRM services based on the RAN node’s lack of support for XRM services, and UE 102 communicates 327 XRM data with the CN element 110 via the first BS 104 without PDU Set based QoS handling. The steps illustrated in FIG. 3 form the XRM data communication procedure 391.

[0046] While the embodiments discussed with regard to FIGs. 2 and 3 disclosed modifications to a CN-to-BS message (e.g., 214, 315), between the serving RAN node and the CN element, depending on BS’s indication on whether the RAN node supports or not XRM service capabilities for PDU set based QoS handling, the next embodiments address a handover procedure, i.e., when a mobility event happens, as the UE changes its radio connection from a source RAN node to a target RAN node. For this case, the SMF and/or a policy control function (PCF) of the CN element may rely on RAN node’s indication of its XRM service capabilities for PDU set based QoS handling to determine whether to modify QoS flows of the PDU session for enabling or disabling the PDU set based QoS handling for the XRM traffic. In this document, the PDU set based QoS handling is also called “XRM service capabilities” or “PDU set based QoS handling support.” [0047] For example, based on an event exposure subscription from the PCF/SMF, the AMF may send a notification about the RAN node’s XRM service capabilities for PDU set based QoS handling to the PCF/SMF. Alternatively, if the event exposure subscription is from the SMF, the AMF may include the RAN node’s XRM service capability for PDU Set based QoS handling in, for example, a Nsmf_PDUSession_UpdateSMContextRequest message to the SMF. For another example, the AMF receives the RAN node’s XRM service capabilities for PDU set based QoS handling in the path switch request message 401 b/501 and forwards it to the SMF when the mobility event happens, as a part of an Xn based handover procedure for UE (FIG. 4 illustrates a traditional handover procedure), which is modified as illustrated in FIGs. 5 and 6. The current Xn based handover procedure illustrated for reference in FIG.

4, is defined in 3GPP TS 38.300 and TS 23.502. More specifically, the source RAN node 104 initiates 400 a handover preparation phase for either immediate or conditional handover, followed by a handover execution phase 490, which provides 401 a RAN usage data report (N2 SM Information (Secondary RAT usage data)), and the target RAN node sends the path switch request message 401 b/501 to the AMF 164.

[0048] The target RAN node 106 sends 401 b an N2 path switch request message to the AMF 164 to inform the AMF that the UE 102 has moved to a new target cell and provides a list of PDU sessions to switch and the RAN node’s XRM service capability for PDU Set based QoS handling. The AMF 164 sends 402 an N2 SM information by invoking, for example, the Nsmf_PDUSession_UpdateSMContext request service operation for each PDU session in the list(s) of PDU sessions received in the N2 path switch request.

[0049] For PDU sessions that are modified by the target RAN node, the SMF 166 sends 403 an N4 session modification request message to the UPF 162. The SMF 166 may notify the UPF 162 that originated the data notification to discard downlink data for the PDU Sessions and/or to not provide further Data Notification messages. For the PDU sessions that are switched, the UPF 162 returns 404 an N4 session modification response message to the SMF 166 after requested PDU sessions are switched.

[0050] In order to assist the reordering function in the target RAN node, the UPF 162 sends 405 one or more "end marker" packets for each N3 tunnel on the old path immediately after switching the path. The UPF 162 starts sending downlink packets to the target RAN node 106 for forwarding to the UE 102. The SMF 166 sends 407a, for example, an Nsmf_PDUSession_UpdateSMContext response (N2 SM Information) to the AMF 164 for PDU sessions which have been switched successfully. After the Nsmf_PDUSession_UpdateSMContext response is received from all the SMFs 166, the AMF 164 aggregates received CN tunnel info and sends 407b this aggregated information as a part of N2 SM information in an N2 path switch request ack to the target RAN node 106. By sending 408 a release resources message to the source RAN node 104, the target RAN node 106 confirms success of the handover. The UE may initiate 409 a mobility registration update procedure if one of the triggers for registration procedure applies.

[0051] The embodiments discussed next modify the traditional handover procedure illustrated in FIG. 4 based on a couple of options. According to the first option, the handover decision is based on the RAN node’s XRM service capabilities for PDU set based QoS handling and the Xn based handover procedure can be changed as follows. The source (S)-RAN node 104 determines 400A (see FIG. 5) a target (T)-RAN node 106 based on the XRM service capabilities of the T-RAN node for PDU set based QoS handling in at least one of the following cases:

• for case 1 , when there is any PDU set QoS flow parameter included in the PDU session(s) for the UE, or

• for case 2, when the T-RAN node obtains UE XRM Service authorization/indication from the AMF.

[0052] According to the second option, the handover decision is not based on the RAN node’s XRM service capabilities for PDU set based QoS handling. For this option, the Xn based handover procedure in FIG. 5 may be enhanced by modifying a communication between the S-RAN node and the T-RAN node so that the S-RAN node includes an "XRM service indication" in the XnAP handover request message to the T- RAN node when one the following cases is present:

• for case 1 , if any PDU session with the QoS profile(s) including PDU set QoS parameters is stored in the RAN node UE context, or for case 2, if the "XRM authorized" information is included in the RAN node UE context.

[0053] Further, step 401b in FIG. 4, i.e. , the message exchange between T-RAN node and AMF, may be modified as follows. If the T-RAN node receives an "RAN node XRM capability indication" for PDll Set based QoS handling from the S-RAN node and the support of the "RAN node XRM capability indication" for PDll Set based QoS handling between the S-RAN node and T-RAN node is different, the T-RAN node sends the "RAN node XRM capability indication" for PDll Set based QoS handling, which can be set as supported or not supported, to the AMF in the path switch request message.

[0054] According to the third option, the handover decision is not based on the RAN node’s XRM service capabilities for PDll set based QoS handling. For this option, the Xn based handover procedure can be modified so that in step 501 in FIG. 5, the T-RAN node sends the "RAN node XRM capability indication", which can be set as supported or not supported, to the AMF in the path switch request message, when one of the following cases A or B is true:

• for case A, if there is any PDll session with the QoS profile(s) including PDU set QoS parameters stored in the RAN node UE context, and

• for case B, if the "XRM service authorized" information is included in the RAN node UE context.

[0055] In one example, based on option 2, considering a UE handover from a S- RAN node, which is not capable of XRM services, to a T-RAN node, which is capable of XRM services and because there is a change of XRM service capabilities for PDU set based QoS handling between the S-RAN node and T-RAN node, the T-RAN node includes a "RAN node XRM capability indication", which is set as supported, to the AMF, in the path switch request message 501 . Based on the T-RAN node’s XRM service capability received from the AMF, the SMF/PCF/UPF may start PDU set based QoS handling for the new and/or existing XRM traffic.

[0056] In another example, based on option 2, considering a UE handover from a S-RAN node, which is capable of XRM services, to a T-RAN node, which is not capable of XRM services, and because there is a change of XRM service capabilities for PDU set based QoS handling between the S-RAN node and the T-RAN node, the T-RAN node sends 601 the "RAN node XRM capability indication", which is set as not supported, to the AMF in the path switch request message. Based on the T-RAN node’s XRM service capability received at the AMF, the SMF/PCF/UPF may stop the PDU set based QoS handling for the existing/new XRM data traffic.

[0057] In yet another example, based on option 2, considering a UE handover from a S-RAN node, which is capable of XRM services, to a T-RAN node, which is also capable of XRM services, and because there is no change of XRM service capabilities for PDU set based QoS handling between the S-RAN node and the T-RAN node, the T-RAN node does not need to send the “RAN node XRM capability indication” to the AMF in the path switch request message.

[0058] For example, based on option 3, case A, considering a UE handover from S- RAN node, which is not capable of XRM services, to a T-RAN node, which is capable of XRM services, and because there is no PDU session with the QoS profile(s) including PDU set QoS parameters, in the step 491 of forwarding the data (i.e. , S-RAN node->T- RAN node) in FIG. 4, the S-RAN node indicates its lack of support of XRM service capabilities for PDU set based QoS handling to the T-RAN node.

[0059] In another example, based on option 3, case A, considering a UE handover from a S-RAN node, which is capable of XRM services, to a T-RAN node, which is not capable of XRM services, and because there is a PDU session with the QoS profile(s) including PDU set QoS parameters, the S-RAN node indicates its support of RAN node’s XRM service capabilities for PDU set based QoS handling to the T-RAN node.

[0060] In yet another example, based on option 3, case A, considering a UE handover from a S-RAN node, which is capable of XRM services, to a T-RAN node, which is also capable of XRM services, and because there is a PDU session with the QoS profile(s) including PDU set QoS parameters, the S-RAN node indicates its support of RAN node’s XRM service capabilities for PDU set based QoS handling to the T-RAN node.

[0061] In still another embodiment, based on option 3, case A or case B, considering a UE handover from a S-RAN node, which is capable of XRM services, to a T- RAN node, which is also capable of XRM services, the T-RAN node always needs to send the "RAN node XRM capability indication", which is set as supported, to the AMF in the path switch request message. In this case, the AMF determines whether to send a notification to the PCF/SMF, based on a subscribed event procedure, of the RAN node’s XRM service capability, when the serving RAN node is changed for the UE. Based on the T-RAN node’s XRM service capability and XRM service authorization, the SMF/PCF/UPF may continue the PDU set based QoS handling for the existing/new XRM data traffic.

[0062] One or more of the examples discussed above are exemplified based on the signal diagram illustrated in FIG. 5. This figure illustrates an Xn based handover procedure (note that Xn stands for any RAN node to RAN node interface in this embodiment) 500 that considers the UE and the source and/or target RAN node XRM service capabilities for PDU set based QoS handling. The figure shows the first BS 104, which corresponds to the S-RAN node and the second BS 106, which corresponds to the T-RAN node. The CN element 110 in the figure includes one or more of the AMF, SMF, and/or PCF discussed above with regard to FIG. 4. For this embodiment, the T-RAN node has XRM service capabilities for PDU set based QoS handling.

[0063] The XRM data communication procedure is established 290/391 between the UE 102, the first BS 104 (S-RAN node), and the CN element 110. In this situation, the S-BS 104 may either support (FIG. 2) or lack support (FIG. 3) for PDU set based QoS handling. The T-BS 106 of FIG. 5, however, supports PDU set based QoS handling. The first BS 104 is configured to forward the XRM data from the UE to the CN for the uplink direction and from the CN to the UE for the downlink direction. FIG. 5 and FIG. 6 provides the example of XRM data transmission for the downlink direction such that the PSA UPF enables/disables PDU Set handling according to RAN node’s XRM capability for downlink PDU Set based QoS handling. For the uplink direction, which is omitted in the Figure for simplicity, if supported, the UE enables/disables PDU set handling according to RAN node’s XRM capability for uplink PDU Set based QoS handling. During the handover preparation 400, the first BS 104 determines 400A to handover the UE using a N2 based handover mechanism. Following this determination, the first BS 104 sends 400B a handover request message including UE context that may contain PDU Set based QoS parameters for QoS flows to the second BS 106. The second BS 106 returns 400C a handover request acknowledgement message to the first BS 104, in response to the handover request message in 400C. In one embodiment, a handover decision is independent of the XRM capabilities of the target RAN node and the PDU set based handling is based on quality-of-service, QoS, parameters.

[0064] As part of handover execution 490, the first BS 104 sends 510 an RRC reconfiguration to the UE 102 to reconfigure the UE, i.e., to prepare the UE for the new radio resources of the second BS 106. UE 102 replies 514 with an RRC reconfiguration complete message. The first BS 104 optionally sends 512 an SN status transfer to the second BS 106. Next, the second BS 106 sends 501 a path switch request message to the AMF 164 (AMF 164 is shown in FIG. 4) in CN element 110, including the second BS’s XRM service capabilities for PDU set based QoS handling. The AMF in CN element 110 sends 507 a path switch request acknowledgment to the second BS 106.

[0065] The second BS 106 enables 522 PDU set QoS handling for XRM data communication, and the CN element 110 also enables 524 PDU set QoS handling for XRM data communication. UE 102 communicates 526 XRM data with the CN element 110 via the second BS 106, because both CN element 110 and second BS 106 perform PDU set QoS handling for QoS flows of XRM services for the downlink direction. The second BS 106 sends 508 a UE context release message to the first BS 104 for releasing radio resources for the UE. For the uplink direction, the first BS 104 enable PDU set based QoS handling for XRM data communication based on RAN node’s XRM services capabilities for uplink PDU set based QoS handling and optional UE’s XRM capabilities.

[0066] FIG. 6 illustrates a similar Xn based handover procedure 600, but the T-RAN node BS 106 does not support XRM services for PDU set based QoS handling. In this case, it is assumed that UE 102 supports XRM services for PDU set based QoS handling. The XRM data communication procedure is established 290/391 between the UE 102, first BS 104, and CN element 110. The first BS 104 determines 400A to handover the UE 102 using an N2 based handover mechanism. Steps 400B to 514 are similar to the corresponding steps in FIG. 5, and thus, their detailed description is omitted here. The second BS 106 sends 601 a path switch request message to the AMF in CN element 110 and this message does not include the second BS’s XRM service capabilities for PDU set based QoS handling or includes an indicator that expresses that the second BS’s XRM service capabilities do not support PDU set based QoS handling. AMF in CN element 110 sends 507 a path switch request ack to the second BS 106. The second BS 106 may disable (if it was previously enabled) PDU set based QoS handling forXRM data communication and CN element 110 disables 625 PDU set based QoS handling for XRM data communication. UE 102 communicates 526 the XRM data with the CN element 110 via the second BS 106, although neither CN element 110 nor second BS 106 performs PDU set based QoS handling for QoS flows of XRM services. The second BS 106 (which acts as the T-RAN node) sends 508 a UE context release message to the first BS 104 (which acts as the S-RAN node) for releasing radio resources for the UE. For the uplink direction, the first BS 104 enable PDU set based QoS handling for XRM data communication based on RAN node’s XRM services capabilities for uplink PDU set based QoS handling and optional UE’s XRM capabilities.

[0067] While the embodiments discussed above with regard to FIGs. 5 and 6 addressed an Xn based modified handover procedure, the embodiment discussed now, with regard to FIG. 7, addresses the preparation phase of an N2 modified handover procedure. Note that N2 stands for an interface between the RAN node and the CN node in this embodiment, i.e. , a first RAN node does not directly communicate with a second RAN node, as in the Xn case, but the communication passes via the CN element). In this embodiment, during the handover procedure, the SMF/PCF determines, based on source and target RAN nodes’ XRM service capabilities for PDU set based QoS handling (also called for the remainder of this document “XRM service capabilities” or PDU set based QoS handling support), whether to modify QoS flows of the PDU session for enabling or disabling the PDU set based QoS handling for the XRM traffic. For example, based on an event exposure subscription of the AMF to the PCF/SMF, the AMF may send a notification of the RAN nodes’ XRM service capabilities for PDU set based QoS handling to the PCF/SMF. Alternatively, if the event exposure subscription is from the SMF, the AMF may include RAN nodes’ XRM service capabilities in, for example, a Nsmf_PDUSession_UpdateSMContextRequest message to the SMF.

[0068] For the modified handover procedure illustrated in FIG. 7, the AMF 164 performs an N2 based handover procedure for UE 102, as defined in 3GPP TS 23.502, but with one or more changes, which are now discussed as options 1 to 3. The S-RAN node decides 730 to handover the UE 102 to another node, via N2 and then sends 731 a handover required message to the source AMF. The source AMF selects 732 a new AMF 164. New AMF 164 sends 733, for example, a Nsmf_PDUSession_UpdateSMContext request message to the associated SMF 166. SMF 166 checks 734 whether the UE is in the service area of the UPF connecting to RAN node. If not, SMF selects a new intermediate UPF.

[0069] If the SMF selects a new UPF to act as intermediate UPF for the PDU session and a different CN tunnel info need to be used, the SMF sends 735a an N4 session modification request message to UPF (PSA) 162. The UPF (PSA) 162 sends 735b an N4 session modification response message to the SMF 166. SMF 166 sends 736, for example, a Nsmf_PDUSession_UpdateSMContext response message to AMF 164. AMF 164 supervises 737 the Nsmf_PDUSession_UpdateSMContext response messages from the involved SMFs. AMF 164 sends 738 a handover required message to T-RAN node 106, and T-RAN node responds 739 with handover request acknowledge message. The message 739 may include the T-RAN node’s XRM service capabilities for PDU set based QoS handling or includes an indicator that expresses that the T-RAN node’s support of XRM service capabilities for PDU set based QoS handling. If the message does not include the T-RAN node’s XRM service capabilities for PDU set based QoS handling or includes an indicator that expresses that the T-RAN node does not support PDU set based QoS handling.

[0070] AMF 164 then sends 740, for example, a Nsmf_PDUSession_UpdateSMContext request message to SMF 166, which optionally sends 741a an N4 session modification request to UPF 162. UPF sends 741 b a session modification response. SMF 166 sends 742 a Nsmf_PDUSession_UpdateSMContext response message back to AMF 164.

[0071] According to the first option (731 , 737), the AMF selects T-RAN node for the handover decision based on the RAN node’s XRM Service capabilities for PDU set based QoS handling and the N2 based handover procedure can be enhanced as follows:

• the S-RAN node 104 indicates 731 the RAN node’s XRM service capabilities of the T-RAN node in the handover required message to the AMF 164 when there is a PDU set QoS flow included in the PDU session(s) for the UE, and • the AMF 164 selects 737 a T-RAN node 106 based on the RAN node’s XRM Service capabilities and UE’s authorization to use XRM services.

[0072] For the second option, the AMF selects 737 T-RAN node for handover decision not based on the RAN node’s XRM service capabilities. The N2 based handover procedure can be modified as follows:

• if the UE is authorized to use XRM services, then a target AMF 164 sends 738 the "XRM service indication" information to the T-RAN node 106 in the next generation application protocol (NGAP) handover request message, and

• if receiving 738 the "XRM service indication" from the AMF 164, the T-RAN node includes 739 an RAN node XRM service capability for PDU Set based QoS handling indication in the NGAP handover acknowledge message to the AMF 164.

[0073] For the third option, the AMF selects T-RAN node for the handover decision not based on the RAN node’s XRM service capabilities for PDU set based QoS handling. The N2 based handover procedure is modified so that, if the “XRM service authorized” information is included in the RAN node UE context, the T-RAN node includes an RAN node XRM service capability indication in the NGAP handover ack message in step 739, to the AMF.

[0074] In one example, for the first option, the SMF/PCF may be aware of the RAN node’s XRM service capabilities based on stored information of XRM service capabilities for S-RAN node and T-RAN node. Thus, the AMF determines whether to send a notification to the PCF/SMF based on the subscribed event of RAN node’s XRM service capability when the serving RAN node is changed for the UE.

[0075] In another example, for the second option, the SMF/PCF may be aware of the RAN node’s XRM service capabilities from the AMF based on one of the following mechanisms:

• the AMF sends the XRM service indication to the T-RAN node if the UE has XRM services authorization, and/or

• the T-RAN node, after receiving the XRM service indication from the AMF, indicates its support of the XRM service capability for PDU set based QoS handling, and/or • based on the stored information of XRM service capabilities for S-RAN node and T- RAN node, the AMF determines whether to send a notification to the PCF/SMF based on a subscribed event related to RAN node’s XRM service capability when the serving RAN node is changed for the UE.

[0076] Considering the UE handover from a S-RAN node, which is not capable of XRM services, to a T-RAN node, which is capable of XRM services, the SMF/PCF/UPF may start, based on the T-RAN node’s XRM service capabilities and XRM service authorization, a PDU set based QoS handling for the new and/or existing XRM traffic.

[0077] Considering the UE handover from a S-RAN node, which is capable of XRM services, to a T-RAN node, which is not capable of XRM services, the SMF/PCF/UPF may, based on the T-RAN node’s XRM service capability and XRM service authorization, disable the PDU set based QoS handling for the existing/new XRM traffic.

[0078] According to an embodiment, after the UE handover from the S-RAN node to the T-RAN node, if the T-RAN node supports XRM service capabilities for PDU set based QoS handling, the T-RAN node and CN enables the PDU set based QoS handling for the PDU sessions of the XRM services. However, if the T-RAN node does not support XRM service capabilities for the PDU set based QoS handling, the CN disables the PDU set based QoS handling for the PDU sessions of the XRM services.

[0079] Thus, the CN behavior for the mobility event may depend on the RAN node’s XRM service capabilities for PDU set based QoS handling. More specifically, if the PCF has an active subscription to the AMF’s notification for RAN node’s XRM service capabilities for PDU set based QoS handling, the AMF notifies PCF about the T-RAN node’s XRM service capabilities. The PCF configures the PCC rules for PDU set based QoS handling and sends them to the SMF based on the RAN node’s XRM service capability and XRM service authorization.

[0080] Then, the SMF configures UPF for PDU set based QoS handling and PDU set identification and marking, based on the PCC rules, for performing QoS flow binding, using related procedures, for example, PDU session establishment procedure or PDU session modification procedure as defined in TS 23.502, and/or setting up an application function (AF) session with required QoS procedure as defined in TS 23.502. [0081] If the SMF has a subscription to the AMF’s notification for RAN node’s XRM service capabilities for PDU set based QoS handling, the AMF notifies SMF about the T- RAN node’s XRM service capabilities with, for example, a Nsmf_PDUSession_UpdateSMContext request message. Based on the RAN node’s XRM service capability and PCC rules, the SMF(s) performs QoS flow binding and configures UPF for PDU set based QoS handling and marking, based on one or more of the following related procedures: PDU session establishment procedure, PDU session modification procedure, and/or AF session with required QoS procedure.

[0082] According to another embodiment, the SMF may determine (for any of the previous embodiments) whether to activate the PDU set based QoS handling at PSA UPF based on one of the following events (or triggers) occurring at the UE: 5GS registration, access type is 3GPP access, PDU session type as IP, PDU session request type as ‘Initial request’ or ‘existing PDU Session’, and state transition, e.g., from CM-idle to CM- connected states, or from RRC-inactive to RRC-connected states.

[0083] For example, the SMF does not enable PDU set based QoS handling at PSA UPF or deactivates the active PDU set based QoS handling at PSA UPF (e.g., if it is already activated before the scenario was changed) in the following scenarios: when the UE is registered to EPS or moves from 5GS to EPS, when the UE is registered to non- 3GPP access or moves from 3GPP access to non-3GPP access, or when the PDU Session type is not IP, or when the PDU session request type is MA PDU Session, or when the UE enters CM-idle or when the UE enters RRC-inactive or when the UE enters CM-connected state from CM-ldle and the serving RAN node does not support PDU Set based QoS handling or when the UE enters RRC-connected state from RRC-inactive and the serving RAN node does not support PDU Set based QoS handling.

[0084] Two scenarios are now discussed in more detail. According to an embodiment, a 5GS to EPS handover for single-registration mode with N26 interface is considered. This scenario is illustrated in FIGs. 8A to 8C with FIG. 8A illustrating the handover preparation phase and FIGs. 8B and 8C illustrating the handover execution phase. Original step 852b of this procedure is modified to address the PDU set based QoS handling in step 865. A PDU session and QoS flow setup in 5GS is first established 850 between the various RAN nodes and elements of the CN element 110. The T-RAN node decides that the UE should be handed over to the E-UTRAN 820 and thus, the T-RAN node requests 731 a handover to AMF 164. The AMF determines 852a-852c that the type of handover is handover to E-UTRAN and AMF selects an MME as described in 3GPP TS 23.401.

[0085] If the SMF and control plane of Packet Data Network (PDN) Gatewaycontrol (PGW-C), called SMF+PGW-C 834, determines that EPS Bearer Context can be transferred to EPS and the CN Tunnel Info for EPS bearer(s) have not been allocated, the SMF+PGW-C sends 852b an N4 session modification to the user plane of PGW (PGW- U)+UPF 836 to establish the CN tunnel for each EPS bearer and provides 852c EPS Bearer Contexts to AMF 164. Step 852b is modified in this embodiment so that the SMF+PGW-C 834 deactivates the PDU set based QoS handling at PGW-U+UPF 836 (e.g., if PDU set based QoS handling was activated when the UE was registered to 5GS). [0086] The AMF sends 853 a forward relocation request to the MME 822 followed by sending 854 a create session request and receiving 855 a create session response as discussed in 3GPP TS 23.401 . MME 822 sends 856 a handover required message to E- UTRAN 820, and E-UTRAN 820 acknowledges 857 the handover required message. Then MME 822 creates 858 an indirect data forwarding tunnel using a request/response message pair and sends 859 a relocation response to AMF 164. If data forwarding applies, the AMF 164 sends 860a, for example, the

Nsmf_PDUSession_UpdateSMContext request (data forwarding information) to the SMF+PGW-C 834. If indirect data forwarding applies, the SMF+PGW-C may select 860b an intermediate PGW-U+UPF 836 for data forwarding. The SMF+PGW-C 834 returns 860c an Nsmf_PDUSession_UpdateSMContext response to the AMF 164.

[0087] Continuing to FIG. 8B, the AMF 164 sends 861a the Handover Command to the source RAN node 104, which in turn sends 861 b the handover command to the UE 102. The handover is completed 862a to 862e as discussed in 3GPP TS 23.401 , followed by modifying 863 and 864 bearers, session modification 865, and modify bearer responses 866 and 867.

[0088] Then, the UE initiates 868 a Tracking Area Update (TAU) procedure and if PCC is deployed, the PGW-U and UPF 836 may decide 869 to provide the previously removed PCC rules to the SMF+PGW-C 834 again, thus triggering the SMF+PGW-C 834 (K and W) to initiate a dedicated bearer activation procedure. The indirect data forwarding tunnel is deleted 870 at MME 822 (E and Q) and SGW 826 (F and R) and deleted 871a at a visited-SMF (V-SMF) 830 (H and T) and visited-UPF (V-UPF) 832 (I and U). An optional final session modification 871b occurs between SMF+PGW-C 834 (K and W) and PGW- C+UPF 836 (L and X) in the EPS network and the AMF 164 (D and P) sends 871c a UE Context Release Command message to the source NG RAN 104 (C and O). The source NG RAN releases its resources related to the UE and responds with a UE Context Release Complete message.

[0089] Contrasting with the first N2 handover scenario of FIG. 8A/B/C, according to the second N2 handover scenario, the UE experiences a handover from EPS to 5GS using N26 interface, which is illustrated in FIGs. 9A and 9B. Step 989a is modified to account for PDU set based QoS handling as now discussed. Note that the following steps are part of the handover preparation phase.

[0090] E-UTRAN 820 determines 851 a handover initiation and sends 982 a handover required message to the MME 822, which in turn sends 983 a forward relocation request to an initial AMF 164. The initial AMF 164 invokes 984, for example, the Nsmf_PDUSession_CreateSMContext service operation on the SMF identified by the SMF+PGW-C 834 address. If dynamic PCC is deployed, the SMF+ PGW-C 834 may initiate 985 SMF initiated SM Policy Modification towards the home PCF 942 as shown in FIG. 9B. The SMF+PGW-C 834 requests 986 the PGW-U+UPF 836 to allocate the CN Tunnel Info for PDU Session as shown in FIG. 9B. The SMF+PGW-C 834 sends 987, for example, a Nsmf_PDUSession_CreateSMContext response to the initial AMF 164. The default V-SMF 830 selects 988 a default v-UPF 832 and initiates an N4 Session Establishment procedure with the selected default v-UPF. The default V-SMF provides the default v-UPF with packet detection, enforcement, and reporting rules to be installed on the UPF for this PDU Session, including H-CN Tunnel Info.

[0091] Based on info received from the SMF+PGW-C 834, the initial AMF 164 may reselect 988a a target AMF 913 as described in 3GPP TS 23.501 and sends the Namf_Communication_RelocateUEContext request to the selected target AMF. The target AMF 913 sends 989a a handover request message to the RAN node 104, which responds 989b with a Handover Request Acknowledge message to the target AMF 913. [0092] The RAN node 104 is configured, different from the original procedure, to include the PDU set based QoS handling support indication in the N2 SM information in step 989b. If the N2 SM information includes the PDU set based QoS handling support indication, the SMF 834 may determine 992 to configure PSA UPF to perform PDU set information marking for the QoS flow.

[0093] The target AMF 913 sends 991 , for example, an Nsmf_PDUSession_UpdateSMContext request message to the SMF 834 for updating N3 tunnel information. SMF+PGW-C 834 performs 992 preparations for N2 handover by indicating N3 user plane address and Tunnel ID of RAN node to the UPF if N2 handover is accepted by the T-RAN node 104. SMF+PGW-C 834 sends 993, for example, an Nsmf_PDUSession_UpdateSMContext response to target AMF 913. The data forwarding information is included in the EPS Bearer Setup List. The target AMF 913 sends 994 a Forward Relocation Response message to MME 822. The target AMF 913 sends 995, for example, a Namf_Communication_RelocateUEContext response to the initial AMF 164 if step 988a had been performed. The target AMF indicates whether the Relocate UE Context (handover) succeeded or failed. MME 822 sends 996 an indirect data forwarding tunnel request/response to SGW 826 if the source MME determines that indirect data forwarding applies.

[0094] Based on one or more of the embodiments discussed above, a wireless communication method 1000, which is illustrated in FIG. 10, is performed by an RAN node and includes sending 1001 (501 , 601 ) to a CN element, when a handover procedure is initiated, a message including an indication associated with target RAN node extended reality and/or media, XRM, service capabilities, enabling 1022 (522, 622) a PDU set based (QoS) handling of XRM data communicated with the CN, and forwarding 1026 (526, 626) the XRM data, through a PDU session between a UE and the CN, according to the PDU set based (QoS) handling. In one variation of this embodiment, the PDU set based handling relies on QoS parameters.

[0095] Based on one or more of the embodiments discussed above, a wireless communication method 1100, which is illustrated in FIG. 11 , is performed by one or more functions of the CN, and includes receiving 1101 (501 , 601 ), when a handover procedure is initiated, a message from an RAN node, the message including an indication associated with target RAN node extended reality and/or media, XRM, service capabilities, enabling 1124 (524, 624) a packet data unit, PDU, set based handling, of XRM data for the target RAN node, and receiving 1126 (526, 626) the XRM data from a UE, through the target RAN node, according to the PDU set based handling within a PDU session. In one variation of this embodiment, the PDU set based handling relies on QoS parameters.

[0096] Numerical adjectives “first”, “second”, and “third” do not imply any order (are not ordinals) but are markers to distinguish separate instances of similar elements.

References to the singular (e g., “a” or “an”, “the”) should include the plural unless clearly indicated otherwise.

[0097] As used herein, a phrase referring to “at least one of’ or “one or more of’ a list of items refers to any combination of those items, including single members. For example, “at least one of: a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0098] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

WHAT IS CLAIMED IS:

1 . A wireless communication method (1000) performed by a target radio access network, RAN node, (106), the method comprising: sending (1001 ) to a core network, CN, element (110), when a handover procedure is initiated, a message including an indication associated with target RAN node extended reality and/or media, XRM, service capabilities; enabling (1022) a packet data unit, PDU, set based quality-of-service, QoS, handling of XRM data communicated with the CN element (110); and forwarding (1026) the XRM data, through a PDU session between a user equipment, UE, (102) and the CN element (110), according to the PDU set based QoS handling.

2. The method of Claim 1 , further comprising: receiving a handover request, for the UE (102), from a source RAN node, through a RAN node-to-RAN node interface, the handover request including an UE context including PDU set based QoS parameters for QoS flows to the source RAN node.

3. The method of any of Claims 1 or 2, wherein the sending comprises: transmitting the indication associated with the target RAN node XRM service capabilities for the PDU set based QoS handling to an access and mobility management function, AMF, of the CN element, in a path switch request message, wherein the indication specifies whether the target RAN node supports the PDU set based handling.

4. The method of Claim 3, further comprising: receiving, from a source RAN node, an indication of source RAN node XRM service capabilities for the PDU set based QoS handling when the source RAN node initiates the handover procedure of the UE to the target RAN node.

5. The method of Claim 1 , further comprising: receiving a handover request, for the UE (102), from a source RAN node, through a CN-based interface.

6. The method of Claim 5, further comprising: sending the indication associated with the target RAN node XRM service capabilities for the PDU set based QoS handling to an access and mobility management function, AMF, of the CN element, via a handover request acknowledgment, wherein the indication specifies whether the target RAN node supports the PDU set based QoS handling.

7. The method of any of Claims 1 to 6, further comprising: including an XRM service indication in a handover request message from a serving radio access network, RAN node to a target RAN node, when a PDU session includes a QoS profile having PDU set QoS parameters stored in a radio access network, RAN, node UE context.

8. The method of any of Claims 1 to 7, further comprising: disabling the PDU set based QoS handling when the indication is associated with lack of XRM service capabilities.

9. The method of any of Claims 7 or 8, wherein the PDU set based QoS handling depends on QoS parameters in the handover request message.

10. A wireless communication method (1100) performed by a core network, CN, element (110), the method comprising: receiving (1101 ), when a handover procedure is initiated, a message from a target radio access network, RAN node, (106), the message including an indication associated with target RAN node extended reality and/or media, XRM, service capabilities; enabling (1124) a packet data unit, PDU, set based quality-of-service, QoS, handling, of XRM data for the target RAN node (106); and receiving (1126) the XRM data from a user equipment, UE, (102), through the target RAN node (106), according to the PDU set based QoS handling within a PDU session.

11 . The method of Claim 10, wherein the receiving comprises: acquiring, at an access and mobility management function, AMF, of the CN element, in a path switch request message, the indication associated with the target RAN node XRM service capabilities for PDU set based QoS handling, wherein the indication specifies whether the target RAN node supports the PDU set based QoS handling; and disabling the PDU set based QoS handling when the indication is associated with lack of XRM service capabilities.

12. The method of any of Claims 10 or 11 , further comprising: receiving at an access and mobility management function, AMF, from a source RAN node, an indication of source RAN node XRM service capabilities support when initiating the handover procedure of the UE to the target RAN node; and sending the indication from the AMF to a session management function, SMF, of the CN element for the PDU set based QoS handling.

13. The method of any of Claims 10 to 12, further comprising: modifying, at a session management function, SMF, QoS flows of the PDU session, based on the target RAN node’s XRM service capabilities for the PDU set based QoS handling.

14. The method of any of Claims 10 to 13, further comprising: receiving at an access and mobility management function, AMF, of the CN element, via a handover request acknowledgment, the indication associated with the target RAN node XRM service capabilities for PDU set based QoS handling, wherein the indication specifies whether the target RAN node supports the PDU set based handling; and disabling the PDU set based QoS handling when the indication is associated with the target RAN node lack of XRM service capabilities.

15. The method of any of Claims 10 to 14, wherein a handover decision is independent of the XRM capabilities of the target RAN node and the PDU set based QoS handling is based on QoS parameters.

16. The method of any of Claims 10 to 15, further comprising: activating at a session management function, SMF, of the CN element, the PDU set based QoS handling, upon a 5G system, 5GS, registration.

17. A wireless communication device (102, 106) comprising a transceiver (134, 136, 144, 146), a processor (132, 142), and computer-readable storage media (148,

158) storing executable instructions for the processor to perform any one of methods recited in claims 1 -16, using the transceiver.