Supporting pdu sessions for access networks of a cellular communication system

Abstract

A node of a core network (CN) receives, from a user equipment (UE), a request to establish or update a protocol data unit (PDU) session; determines an access type for the UE; and enables or disables, for the PDU session and based on the access type, PDU Set handling.

Description

SUPPORTING PDU SESSIONS FOR ACCESS NETWORKS OF A CELLULAR COMMUNICATION SYSTEMCROSS-REFERECE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 519,229 entitled “PDU Session with Access Network Support for XR and Media Services in a Communication System,” filed on August 11, 2023 and U.S. provisional U.S. Patent Application No. 63 / 541,444 entitled “PDU Session with Access Network Support for XR and Media Services in a Communication System,” filed on September 29, 2023. The entire contents of the provisional applications are hereby expressly incorporated herein by reference.FIELD OF THE DISCLOSURE

[0001] This disclosure relates generally to wireless communications and, more particularly, to managing user consent for analytic and event monitoring operations in a cellular communication networks.BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the context of the disclosure. 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] Generally speaking, a base station operating a cellular radio access network (RAN) communicates with a user equipment (UE) using a certain radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of a RAT provides transport channels to the Medium Access Control (MAC) sublayer, which in turn provides logical channels to the Radio Link Control (RLC) sublayer, and the RLC sublayer in turn provides data transfer services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer is disposed above the PDCP sublayer. A Service Data Adaptation Protocol (SDAP) layer, disposed above the PDCP layer, supports Packet Data Units(PDU) sessions, which include one or more quality-of-service (QoS) flows. A core network (CN) communicates data with the UE via the RAN using multiple layers of a protocol stack.

[0004] Some of the services fifth-generation systems (5GS) require a high data rate and low- latency transmissions. One example of such services is extended Reality (XR), which includes Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR). In virtual reality applications, the user is fully immersed in a virtual environment that fully replaces the real, physical environment, typically by wearing a head-mounted device. In augmented reality, an application augments the perception of the real environment by overlaying virtual elements on the perception of the real environment. Augmented reality recently became the foundation of a widely popular game in which players seek out and interact with virtual creatures superimposed onto a real-time video stream of the real world. Finally, mixed reality is an extension of AR, where real and virtual elements can interact in real time.

[0005] XR games and other applications often run on cloud platforms that include remote servers, and generally do not require games consoles, high-spec CPUs, or high-spec GPUs. Cloud gaming involves streaming a game similar to streaming a video, and the game responds to the gamer’s commands and controls in real time.

[0006] To better support high-data-rate, low-latency services such as XR, the 3rd Generation Partnership Project (3GPP) recently proposed to group certain Packet Data Units (PDUs) into sets of multiple PDUs carrying the payload of one unit of information generated at the application level (e.g., frames or video slices). The PDUs in a PDU Set can have the same importance for the application level. The 3GPP further proposed to support PDU set-based quality of service (QoS) requirements.

[0007] A RAN can handle PDU Sets according to PDU Set QoS parameters and PDU Set information in the header of a General Packet Radio Service (GPRS) Tunnelling Protocol (GTP)- U packet, dedicated to GTP user data. A PDU Session Anchor (PSA) User Plane Function (UPF), operating in the core network, provides the PDU Set information. In the CN, a Session Management Function (SMF) performs QoS flow binding based on a service data flow, configures the UPF with rules for PDU Set identification and marking via the GTP-U header, and provides QoS profiles including PDU Set QoS parameters to the RAN over the N2 interface.More particularly, the SMF can provide the UPF with a protocol description indicating the header (e.g., RTP / SRTP) and payload type (e.g. H.264) of the service data flow(s) of a media stream from the application server.

[0008] The PSA UPF can receive a downlink (DL) PDU from a data network (DN) over the N6 interface and, when PDU Set handling applies, apply the rules for PDU Set identification and provide, in the GTP-U header, PDU Set Information for the RAN. If the RAN receives PDU Set QoS Parameters and supports such parameters, the RAN enables PDU Set-based QoS handling and applies PDU Set QoS parameters.

[0009] Generally speaking, PDU Set Identification and marking is resource- and timeintensive operation at the UPF. However, currently it is not clear how the UPF and / or other CN nodes should handle PDU Set QoS provisioning in view of support or non-support of PDU Set handling at an access network. For example, when the UE moves between 3 GPP access and non- 3 GPP access, it is not clear how the SMF can determine whether to activate or deactivate PDU Set identification and marking at the UPF PDU Set handling. This problem can apply at least to the following cases: (i) a handover of a PDU Session from Non-3GPP access to 3GPP access, and (ii) handover of a PDU Session from 3 GPP access to non-3GPP access.

[0010] Further, services such as XR Services and Media services (“XRM services”) require high bandwidth and low latency. However, a UE may not subscribe to certain RAT type(s) of 3GPP access, or a certain RAT type may not be suitable for XRM services, or operator policies may not allow the RAT type. It is not clear how the SMF can determine whether to activate / or deactivate PDU Set identification and marking at the UPF when the UE is registered to 3GPP access via a specific RAT type, e.g. NR. This problem can apply at least to the following cases: (i) a handover of a PDU Session from Non-3GPP access to 3GPP access with a RAT that supports (or does not support) PDU Set handling, and (ii) handover of a PDU Session from 3GPP access with a RAT that supports (or does not support) PDU Set handling to non-3GPP access.

[0011] Still further, A UE capable of Access Traffic Steering, Switching and Splitting (ATSSS) may request a Multiple Access (MA) PDU Session, or the network may determine to change the PDU Session type to a MA PDU Session type so as to allow the UE to select, switch,or steer the traffic between two registered access types. However, it is not clear whether the system can activate or deactivate PDU Set handling at the UPF for a MA PDU session. This problem can apply at least to the following cases: (i) a UE capable of ATSSS requests MA PDU Session to select, switch, or steer the traffic between two registered access types, (ii) the network determines to change a PDU Session to the MA PDU session type, so that the UE can register for non-3GPP access, 3 GPP access, or both for the MA PDU Session, and the 3 GPP access may be associated with a RAT type that supports (or does not support) PDU Set handling, and (iii) the network determines to deregister non-3GPP access from a MA PDU session, and the 3GPP access may be associated with a RAT type that supports (or does not support) PDU Set handling.SUMMARY

[0012] An example embodiment of the techniques of this disclosure is method implemented in a node of a CN. The node receives, from a user equipment (UE), a request to establish or update a protocol data unit (PDU) session, determines an access type for the UE, and enables or disables, for the PDU session and based on the access type, PDU Set handling.

[0013] Another example embodiment of these techniques is a node in a CN comprising processing hardware and configured to implement the method above.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Fig. l is a block diagram of an example wireless communication system in which a user equipment unit (UE) can access a core network via 3 GPP access or non-3GPP access, and a node in CN can determine whether to activate PDU Set handling for the UE depending on the access type;

[0015] Fig. 2 is a block diagram of an example protocol stack according to which the UE of Fig. 1 can communicate with the RAN of Fig. 1;

[0016] Fig. 3 is a service-based representation of a CN architecture, including the overall nonroaming reference architecture of the policy and charging control framework for a cellular communication system;

[0017] Fig. 4 is a reference-point based representation of the CN architecture, including overall non-roaming reference architecture of the policy and charging control framework of the cellular communication system;

[0018] Fig. 5 illustrates a reference procedure for establishing, modifying, and releases resources for, a PDU session, which can be implemented in the system of Fig. 1;

[0019] Fig. 6A is a messaging diagram of an example scenario in which the SMF determines, based on one or more parameters such as access type, whether to activate PDU Set handling;

[0020] Fig. 6B is a messaging diagram of an example scenario in which the RAN provides, to the SMF, an indication of support or lack of support of PDU Set handling prior to the SMF performing the UPF selection and configuration;

[0021] Fig. 6C is a messaging diagram of an example scenario in which the RAN provides, to the SMF, an indication of support or lack of support of PDU Set handling in an N2 PDU session response message;

[0022] Fig. 7 is a flow diagram of an example method for determining whether to activate PDU Set handling, which a CN node of Fig. 1 can implement;

[0023] Fig. 8A is a messaging diagram of an example scenario including a handover of a PDU session from untrusted non-3GPP access to 3 GPP access;

[0024] Fig. 8B is a messaging diagram of an example scenario including a handover of a PDU session from 3GPP access to non-3GPP access;

[0025] Fig. 9A a messaging diagram of an example scenario in which a UE registers for 3GPP access, non-3GPP access, or both, and establishes an MA PDU session;

[0026] Fig. 9B a messaging diagram of an example scenario in which a UE registers for 3 GPP access only and establishes a PDU session;

[0027] Fig. 9C a messaging diagram of an example scenario in which a UE registers for both 3GPP access and non-3GPP access and establishes a PDU session; and

[0028] Fig. 10 is a flow diagram of an example method for determining whether to activate PDU Set handling based on access type, which a CN node of Fig. 1 can implement.DETAILED DESCRIPTION OF THE DRAWINGS

[0029] In at least some of the scenarios discussed below, a UE and a CN support PDU Set based handling (or simply “PDU Set handling”) of data, where a PDU Set includes one or more PDUs carrying the payload of one unit of information. A device can generate a PDU Set at the application level. An application can transmit the PDUs of a PDU Set within the same QoS Flow and can use such PDU Set parameters as a PDU Set Delay Budget (PSDB), a PDU Set Error Rate (PSER), and a PDU Set Integrated Handling Information (PSIHI). For example, a PDU Set can correspond to a frame or video slice for XR Services and Media services, collectively referred to as “XRM services.” In some cases, the application generates and transmits multiple PDUs within a relatively short period of time as a data burst, which can include one or several PDU Sets.

[0030] The RAN in some cases supports PDU Set handling, but in other cases does not support PDU Set handling. The techniques discussed with reference to Figs. 1-10 allow the cellular system to provision QoS flows in view of one or more of such factors as access type of the UE (3GPP, non-3GPP, both), RAT type of the RAN, PDU Set handling capability of the RAN, etc. In an example scenario, PDU Set based QoS provisioning applies only when the UE registers for 3GPP access, or only when the UE registers for 3GPP access using an applicable RAT type.

[0031] To consider for example XRM services, during the registration procedure, the AMF can determine whether the UE is authorized to use XRM services based on the XRM Service Capability and the XRM Service Authorization, which the Unified Data Management (UDM) provides to the AMF as a part of the subscription data for the UE. The UE of the examples below supports XRM services capabilities for PDU Set handling.

[0032] Referring first to Fig. 1, an example wireless communication system 100 can implement one or more of the techniques of this disclosure for handling PDU sessions that require PDU Set handling. A UE 102 can access a CN 110 using one of several access types: via a RAN 105, via a non-3GPP access network 107, or both. One or more nodes operating in the CN 110 can determine whether to activate or deactivate PDU Set handling based, at least in part, on the access type.

[0033] The RAN 105 includes a base station 104, which provides service in a cell 124, and a base station 106, which provides service in a cell 126. When the base station 104 is implemented as a gNB, the cell 124 is an NR cell. When the base station 124 is implemented as an ng-eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell.Similarly, when the base station 106 is implemented as a gNB, the cell 126 is an NR cell, and when the base station 126 is implemented as an ng-eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. The cells 124 and 126 can partially overlap, so that the UE 102 can select, reselect or hands over from one of the cells 124 and 126 to the other. In general, the RAN 105 can include any number of base stations, and each of the base stations 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”) air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an appropriate interface (e.g., SI or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0034] The CN 110 can include a Policy Control Function (PCF) 160, an Access and Mobility Management Function (AMF) 164, a User Plane Function (UPF) 170, and a Session Management Function (SMF 166). A Non-3GPP Interworking Function (N3IWF) 167 provides an interface between the AMF 164 and the UPF 170 operating in the CN 110 and the non-3GPP access network 107. For example, the non-3GPP access network 107 can include a device 108 (e.g., a wireless local area network (WLAN) access point), and the UE 102 can access the CN 110 via the device 108 and the N3IWF 167. Example implementation of the CN 110 is discussed in more detail with reference to Figs. 3 and 4.

[0035] While not depicted in Fig. 1 to avoid clutter, the CN 110 can include processing hardware such as 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 can include special-purpose processing units. The processing hardware can be configured to implement the techniques of this disclosure for supporting PDU sessions.

[0036] Each of the base stations 104 and 106 can be equipped with processing hardware 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 can include special-purpose processing units. The base stations 104 and 105 also include transceivers to communicate with UEs such as the UE 102 over a radio interface.

[0037] The UE 102 is equipped with processing hardware 130A 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 UE 102 also includes a transceiver 132A to communicate with the RAN 105 over a radio interface. Further, the CN 110 can implement a PDU Set controller 180A (e.g., in the AMF 164 and / or the SMF 166), and the UE 102 can implement a PDU Set controller 180A.

[0038] In operation, the AMF 164 can determine the access type and the RAT type for the UE 102 using for example the procedure described in TS 23.501, clause 5.3.2.3 (related to Registration Area management).

[0039] Fig. 2 illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB / ng-eNB 230 or a gNB 232 (e.g., one or more of the base stations 104, 106). In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA REC sublayer 206A in turn provides RLC channels to a EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2). The UE 102A, 102B, or 102C, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2, to support handover between EUTRA and NR base stations and / or to supportDC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102A or 102B can support layering of NR PDCP 210 over EUTRA RLC 206 A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0040] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

[0041] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide data radio bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0042] Next, Fig. 3 illustrates a service-based representation 300 of an example CN architecture, which the CN 110 of Fig. 1 can implement. In the representation 300, the overall non-roaming reference architecture of the policy and charging control (PCC) framework for the 5GS includes components illustrated using solid lines, and the other components are illustrated using dashed lines. According to this representation, network functions enable other authorized network functions to access their services. The components that are outside the PCC framework include a Network Slicing Selection Function (NSSF) 302, a Network Repository Function (NRF) 306, a UDM 353, an Edge Application Server Discovery Function (EASDF) 310, a Network Slice Specific Authentication and Authorization Function (NSSAAF) 312, an Authentication Server Function (AUSF) 314, a Service Communication Proxy (SCP) 316, and a Network Slice Admission Control Function (NSACF) 318. The non-PCC architecture further includes the UE 102 and access networks such as the RAN 105.

[0043] The PCC framework in the architecture 300 includes a Unified Data Repository (UDR) 352, a Network Exposure Function (NEF) 354, a network data analytics function (NWDAF) 356,an Application Function (AF) 358, a PCF 360, a Charging Function (CHF) 362, an AMF 364, an SMF 366, and a UPF 370.

[0044] A N3IWF 367 can access the non-3GPP access network 107 via the Y2 interface, and access the UPF 370 via the N3 interface, similar to the RAN 105.

[0045] The AMF 364 is generally configured to manage registration, connection, and mobility of a UE (such as the UE 102A or 102B) and provide transport for session management (SM) messages between the UE 102A or 102B and the SMF 366. In some implementations, the AMF 364 is configured to generate logical interface IDs. The SMF 366 is generally configured to manage sessions, allocate IP addresses for UEs, and provides downlink (DL) notifications. In some implementations, the SMF 366 also includes following functionalities for PIN service: providing per-QoS flow non-3GPP QoS assistance information to the UE (e.g. PEGC), and supporting IP address allocation to UE and PDR configuration with packet filter set for PIN to UPF for framed routing based on PIN group information from the UDM 353.

[0046] The UDM 353 is generally configured to handle user identification, access authorization based on subscription data, and subscription management. In some implementations, the UDM 308 is configured to generate or change logical interface IDs, as will be described below in detail. In some implementations, the UDM 353 supports the functionality of PIN group management handling. The UDR 352 is generally configured to store subscription- related information, such as subscription data, policy data, structured data for exposure, and application data.

[0047] The UPF 370 is generally configured to handle packet routing and forwarding. Further, the NEF 354 is configured to expose the capabilities and services of the network to authorized third-party applications. As illustrated in Fig. 3, the UPF 370 can provide UEs with access to a data network 330 and, conversely, allow one or more application servers in the data network 330 to establish PDU sessions with the UE 102.

[0048] The AF 358 in some deployment operates in a trusted domain or outside the trusted domain, i.e., in a non-trusted domain. The trusted domain is generally internal to the CN and includes such components as the UDM 353, the UDR 352, the PCF 360, the AMF 364, the SMF 366, and the UPF 370. Generally speaking, an AF operating outside the trusted domain (such asoperated by an authorized third-party entity) can access the network functions of the CN only via the NEF 354, whereas an AF operating within the trusted domain can access at least some of the network functions of the CN directly, or may access these functions via the NEF 354 in some deployments.

[0049] Fig. 4 is a reference-point based representation 400 of an example CN architecture. In Fig. 4, the non-roaming reference architecture of the PCC framework is illustrated as blocks and connections with solid lines, and components and connections outside the PCC framework are illustrated using dashed lines.

[0050] The communication system shown Figs. 1-4 in may include additional, fewer, and / or alternative devices or functionalities, and may be configured to perform additional, fewer, or alternate actions, including functionalities / actions described herein.

[0051] Next, Fig. 5 illustrates a reference scenario 500 in which a UE establishes and modifies a PDU session, which can be implemented in the system of Fig. 1. During the registration procedure, the AMF can determines 501 whether the UE 102 is authorized to use XRM services based on the XRM Service Capability of the UE and the XRM Service Authorization included in the subscription data received from UDM as specified in TS 23.501 clause 5.7, for example.

[0052] After successful registration, the UE 102 requests 510 for PDU Session Establishment procedure, and the RAN 105 capable of XRM services can perform PDU Set handling for the QoS flows in a PDU Session based on the XRM service authorization and information received from the SMF 366 via N2 message and GTP-U header via N3 interface from the UPF 370. The PDU Session Establishment Procedure can be implemented as described in TS 23.502 clause 4.3.2.2, for example.

[0053] The UE 102 or the network can initiate 570 a PDU Session Modification Procedure for the existing PDU Session. The PDU Session Modification Procedure can be implemented as described in TS 23.502 clause 4.3.3.2 and 4.3.3.3, for example. The UE 102 may repeat 504 the PDU Session Establishment procedure for multiple PDU Sessions associated with the same or different data network name (DNN) and single network slice selection assistance information (S- NSSAI).

[0054] The 102 and the network can perform 508 a PDU Session Release procedure for an existing PDU Session as described in TS 23.502 clause 4.3.4, for example. Further, the UE 102 and the network can perform 571 a deregistration procedure to release all of the existing PDU sessions, as described in TS 23.502, clause 4.2.2.3, for example.

[0055] When the PLMN provides homogeneous RAN support of PDU Set handling, the reference 500 procedure can include the modifications briefly discussed next, in order to support PDU Set based QoS. The PCF 360 can provide PCC rules for an application service flow as defined in TS 23.503 clause 6.1.3.27.4, for example. The application service flow can include PDU Set QoS parameters (e.g., PSER, PSDB and PSIHI) and the Protocol Description. The SMF 366 can determine a QoS Profile for a QoS flow, based on the received PCC rules or a preconfiguration. The PSA UPF 360 can identify PDUs that belong to a PDU Set using the Protocol Description and the received Packet Detection Rule (PDR). Further, the PSA UPF 360 can mark the GTP-U header for PDU Set information as described in TS 23.501 clause 5.37.5.2. Still further, the PSA UPF 360 can generate PDU Set based parameters based on the QoS Enforcement Rule (QER).

[0056] Next, several approaches to configuring PDU sessions, particularly PDU Set based handling, are considered in connection with the messaging diagrams Fig. 6A-C and 8A-9C as well as the flow diagrams of Fig. 7 and Fig. 10. Generally speaking, similar events in Figs. 6A- 10 are labeled with similar reference numbers that share two least significant digits, with differences discussed below where appropriate.

[0057] Further, the examples scenarios of Figs. 6A-C are discussed with reference to the AMF 364, the UDM 353, and SMF 366, the UPF 370, the PCF 250, and the DN 330. However, in these scenarios, the AMF 164 can operate similar to the AMF 364, the SMF 166 can operate similar to the SMF 366, the PCF 160 can operate similar to the PCF 360, and the UPF 170 can operate similar to the UPF 370.

[0058] According to some approaches, the CN 110 determines whether to activate PDU Set Handling for a PDU session associated with a certain DNN and S-NSSAI based on one or several of the following conditions: PDU Set based QoS parameters, protocol description, a listof subscribed DNN and S-NSSAI values for XRM service, access type, RAT type, or PDU session request type (e.g. initial request, existing PDU Session, MA PDU Session).

[0059] In a scenario 600A of Fig. 6A, the SMF 366 determines whether to activate PDU Set identification and marking at the PSA UPF 370 for the PDU Session with the specific DNN and S-NSSAI. More specifically, the devices in the scenario 600A enhance the PDU session establishment or modification procedure as follows: the RAN 105 provides, to the SMF 166 via the AMF 164, a certain cause value for the rejected QoS flow identifier(s) (QFI). The SMF 166 determines whether to enable PDU Set handling at the RAN 105, when supported, by requesting PDU Set QoS parameters for the QoS flow(s) of the PDU Session.

[0060] The UE 102 first transmits 610, to the AMF 364, a PDU Session Establishment Request message including a PDU Session ID, a DNN, and an S-NSSAI. The DNN and the S- NSSAI can be associated with a certain XRM service. The PDU Session Establishment Request message can indicate a request type such as initial request, existing PDU Session, or MA PDU session. The AMF 364 then performs 612 SMF selection based on the DNN and S-NSSAI. If the DNN and S-NSSAI are associated with an application that requires a PDU Set based QoS, the AMF 364 can select a specific SMF capable of PDU Set handling, e.g., the SMF 366.

[0061] Next, the AMF 364 transmits 614, to the selected SMF 366, an Nsmf_PDU Session CreateSMContext Request message including the PDU session ID, the DNN, and the S- NSSAI, access type, RAT type, and request type. The AMF 164 can determines the access type and the RAT type as described in TS 23.502, clause 4.2.2.2.1, for example. The AMF 164 can store between the S-NSSAI(s), the DNN, the PDU session ID, the SMF ID as well as the access type of the PDU Session.

[0062] The SMF 366 can retrieve 616, for the UE 102 and based on the DNN and the S- NSSAI, subscription data related to XRM. The SMF 366 transmits 618, to the AMF 364, an Nsmf_PDU Session_CreateSMContext Response message in response to receiving 614 the Nsmf_PDU Session_CreateSMContext Request message. The SMF 366 then performs 620 a PDU Session authentication / authorization procedure with the DN 330, using the user credential information the UE 102 provided for the connection to the DN 330.

[0063] Further, the SMF 366 performs 644A a UPF selection and determines whether to activate (or enable) PDU Set identification and marking at the PSA UPF 370 for the PDU session associated with the DNN and the S-NSSAI. To this end and when necessary, the SMF 366 queries 645 the PCF 360 to retrieve and / or update the PCC policies. The SMF 366 can determine 644A whether to activate PDU Set identification and marking based on one or more of the following factors and / or conditions: (i) PDU Set based QoS parameters, (ii) the Protocol Description, (iii) the list of subscribed DNN and S-NSSAI for the XRM service, (iv) the access type (e.g., 3GPP access, Non-3GPP access, or both), (v) the RAT type, (e.g. NR, LTE-M, Satellite, etc.), or the (vi) the PDU session request type (e.g. initial request, existing PDU Session, MA PDU Session).

[0064] When the PDU Set handling applies, the SMF 266 can instruct the PSA UPF 370 to activate PDU Set identification and marking for the PDU Session with the corresponding DNN and S-NSSAI.

[0065] Although Fig. 6A illustrates the event 645 occurring the event 644A, it will be understood that the events 644A can overlap in time at least partially. When the SMF 366 determines that the PCC policies require PDU Set handling, the SMF 366 instructs the PSA UPF 360 to activate PDU Set identification and marking for the PDU session corresponding to the DNN and the S-NSSAI.

[0066] With continued reference to Fig. 6A, if the SMF 366 determines to activate PDU Set handling for the PDU Session of the UE 102, the SMF 366 transmits 647, to the AMF 364, a Namf_Communication_NlN2MessageTransfer message including PDU Set QoS parameters, so as to enable (or activate) the PDU Set handling at the RAN 105. The AMF 364 forwards 650, to the RAN 105, the NAS message in a N2 PDU Session request message.

[0067] The RAN 105 then performs 652 an RRC Reconfiguration procedure of the UE 102. In particular, the RAN 105 transmits 652 a PDU Session Establishment Accept message for an AN-specific resource setup at the UE 102. The RAN 105 also indicates 654 to the AMF 364 whether the RAN 105 accepted or rejected the PDU Set based QoS parameters for the QoS flows of the PDU Session. More particularly, the RAN 105 transmits 654, to the AMF 364, an N2PDU Session Response including the PDU Session ID, a cause, a list of accepted and / or rejectedQFI(s)) message. Each QFI is a QoS flow identifier of a respective QoS flow. The RAN 105 can include 654 the appropriate cause value for a rejected QFI(s), which can be non-support of PDU Set handling at the RAN 105 (due to the S-NSSAI, the DNN, lack of radio resources, etc.). The AMF 364 next transmits 656, to the SMF 366, a Nsmf PDUSessi on Update SMContext Request message including the PDU session ID, he cause, the list of accepted and / or rejected QFI(s)).

[0068] The SMF 366 can modify 680 the N4 session for the accepted and / or rejected QoS flows of the PDU Session. The modification 680 can apply to the UPF 370. For example, based on the cause value, the SMF 366 can determine to deactivate the PDU Set handling for the PDU Session at the UPF 370, or deactivate PDU Set identification and marking only for the rejected QoS flows. If the RAN 105 rejects QoS flows, the SMF 366 can instruct the UPF 370 to release the rejected QoS flows but maintain PDU Set handling for the accepted QoS flows. Requesting QoS parameters without PDU Set handling at the RAN 105 can require an additional signaling overhead.

[0069] The SMF 366 transmits 690 an Nsmf PDUSession UpdateSMContext Response message to the AMF 364, which then transmits 692 a PDU SessionEstablishment Response message to the UE 102.

[0070] Next, Fig. 6B is illustrates an example scenario 600B in which the RAN 105 provides, to the SMF 366 via the AMF 158, an indication of support or lack of support of PDU Set handling prior to the SMF performing the UPF selection and configuration. Here, the SMF 366 requests PDU Set QoS parameters for the one or more QoS flow(s) of the PDU Session and uses the PCC policies and the support indication to determine whether to request activation of PDU Set handling at the RAN 105. The AMF 364 obtains information related to the support of PDU Set handling at the RAN 105 using a non-UE-specific N2 procedure. The AMF 364 then stores the RAN 105 capabilities related to supporting PDU Set handling.

[0071] In the scenario 600B, the RAN 105 also provides a support indication to the SMF 366 via the AMF 364. In particular, during the PDU Session Establishment Request procedure, the AMF 364 provides an indication of supporting PDU Set handling at the RAN 105, as discussed below. During the PDU Session Modification Request procedure, the AMF 364 can transmit, tothe SMF 366, an indication of supporting PDU Set handling at the RAN 105. The SMF 366 can determine whether to activate or deactivate PDU Set handling at the UPF 370 based on the indication of support (or non-support) of PDU Set handling at the RAN 105 as well as one or several of the conditions discussed above with reference to Fig. 6A: PDU Set based QoS parameters, the Protocol Description, the list of subscribed DNN and S-NSSAI for the XRM service, the access tyle, the RAT type, or the PDU Session request type.

[0072] More specifically, the RAN 105 and the AMF 364 can exchange 602 RAN configuration information, and the RAN 105 provides 602, to the AMF 364, an indication of support or non-support of PDU Set handling at the RAN 105. The RAN 105 and the AMF 364 can use a non-UE specific N2 message or procedure. The AMF 364 can store the RAN 105 capabilities of supporting PDU Set handling.

[0073] The UE 102 then transmits 610, to the AMF 364, a PDU Session Establishment Request message including a PDU Session ID, a DNN, and an S-NSSAI, as discussed above with reference to Fig. 6A. The AMF 364 then performs 612 SMF selection based on the DNN and S-NSSAI, also as in the scenario 600A.

[0074] The AMF 364 transmits 615, to the to the SMF 366, an Nsmf_PDU Session_CreateSMContext Request message including a PDU session ID, the DNN, the S- NSSAI, and also an indication whether the RAN 105 supports PDU Set handling. In some implementations, the AMF 364 provides 615, to the SMF 366, an indication of whether the RAN 105 supports PDU Set handling only if the DNN and S-NSSAI are associated with an application that requires a PDU Set based QoS. Further, the AMF 364 can store the indication of support (or non-support) of PDU Set handling at the RAN 105, which can have a certain RAN ID, such as the Global RAN Node ID associated with the N2 interface. Events 616, 618, and 620 can proceed as discussed above with reference to Fig. 6A.

[0075] The SMF 366 performs 644B a UPF selection and determines whether to activate (or enable) PDU Set identification and marking at the PSA UPF 370 for the PDU session associated with the DNN and the S-NSSAI. To this end and when necessary, the SMF 366 queries 645 the PCF 360 to retrieve and / or update the PCC policies. The operation 644B is generally similar tothe operation 644A, but here the SMF 366 also considers the indication of support or nonsupport of the PDU Set handling at the RAN received 615 from the AMF 364.

[0076] Thus, the SMF 366 can determine 644B whether to activate PDU Set identification and marking based on whether the RAN 105 supports PDU Set handling and one or more of the following factors and / or conditions: (i) PDU Set based QoS parameters, (ii) the Protocol Description, (iii) the list of subscribed DNN and S-NSSAI for the XRM service, (iv) the access type (e.g., 3GPP access, Non-3GPP access, or both), (v) the RAT type, (e.g. NR, LTE-M, Satellite, etc.), or the (vi) the PDU Session request type (e.g. initial request, existing PDU Session, MA PDU Session). Upon determining that PDU Set handling is needed, the SMF 366 can instruct the PSA UPF 370 to activate PDU Set identification and marking for the PDU Session with the specific DNN and S-NSSAI. Using the indication of whether the RAN 105 supports PDU Set handling, the SMF 366 reduces the chances the RAN 105 will reject one or more QoS flows due to the PDU Set based handling requirement, which would result in additional signaling overhead associated with requesting QoS parameters.

[0077] For example, the SMF 266 can activate PDU Set handling at the UPF 370 in response to receiving an indication that the RAN 105 supports PDU Set handling, that the PCC policies include PDU Set based QoS parameters for QoS flows, that access type is 3GPP access, and that the RAT type is NR.

[0078] Events 645, 647, 650, 652, 654, 656, 690, and 692 can proceed as discussed with reference to Fig. 6A. Also similar to Fig. 6A, the SMF 366 can modify 680 the N4 session for the accepted and / or rejected QoS flows of the PDU Session. In some implementations, the SMF 366 activates PDU Set identification and marking for the accepted PDU Set based QoS flows.

[0079] Fig. 6C illustrates example scenario 600C in which the RAN provides, to the SMF, an indication of support or lack of support of PDU Set handling in an N2 PDU session response message. The RAN 105, the AMF 364, and the SMF 366 perform an enhanced PDU session establishment or modification procedure that includes the RAN 105 indicating support or nonsupport of PDU Set handling. In particular, the SMF 366 can determine whether to enable PDU Set handling for the PDU Session of the UE 102 based on the conditions discussed above with reference to Figs 6A and 6B (PDU Set based QoS parameters, the Protocol Description, the listof subscribed DNN and S-NSSAI for the XRM service, the access tyle, the RAT type, or the PDU Session request type). If the SMF 366 determines to enable the PDU Set handling, the SMF 366 requests PDU Set QoS parameters for the one or more QoS flow(s) of the PDU Session.

[0080] The RAN 105 in the scenario 600C provides an indication of support or non-support of PDU Set handling to the SMF 366 via the AMF 364. During the PDU session establishment request procedure, and after the RAN 105 transmits, to the AMF 364, an N2 PDU Session response including an indication of whether the RAN 105 supports PDU Set handling, the AMF 364 further transmits, to the SMF 366, an Nsmf PDU Session CreateSMContext Request including the indication of whether the RAN 105 supports PDU Set handling. During the PDU session modification request procedure, and after the RAN 105 transmits, to the AMF 364, an N2 PDU Session response message including an indication of whether the RAN 105 supports PDU Set handling, the AMF 364 further transmits, to the SMF 366, an Nsmf PDU Session_UpdateSMContext Request message including the indication of whether the RAN 105 supports PDU Set handling. The SMF 366 further can determine whether to modify the N4 session for activating or deactivating PDU Set handling after receiving the indication of whether the RAN 105 supports PDU Set handling, and receiving the accepted and / or rejected QoS flows.

[0081] Referring specifically to Fig. 6C, events 610 and 612 proceed as discussed with reference to Fig. 6B; event 614 proceeds as discussed with reference to Fig. 6A; events 616, 618, and 620 proceed as discussed with reference to Fig. 6B; and events 644A, 645, 647, 650, and 652 proceed as discussed with reference to Fig. 6A.

[0082] The RAN 105 indicates 655 whether the RAN 105 accepts or rejects the PDU Set based QoS parameters for the QoS flows of the PDU Session. In particular, the RAN 105 can transmit 655, to the AMF 364, an N2 PDU Session Response message including a PDU Session ID, a cause, a list of accepted and / or rejected QFI(s), and an indication of whether the RAN 105 supports PDU Set handling. Similar to the examples above, a QFI identifies a particular QoS Flow.

[0083] When the RAN 105 activates PDU Set handling for the accepted QFI(s), the RAN 105 includes an indication of supporting PDU Set handling in the response message include the RAN105 transmits to the SMF 366 via the AMF 364. Further, the RAN 105 can include a suitable cause value for the rejected QFI(s) (if any), e g., lack of support of PDU Set handling due to the S-NSSAI, the DNN, lack of radio resources, etc.

[0084] The AMF 364 transmits 657 an Nsmf PDUSession Update SMContext Request message to the SMF 366. The PDUSession Update SMContext Request message can include the PDU session ID, the cause, the list of accepted and / or rejected QFI(s), and the indication of whether the RAN 105 supports PDU Set handling.

[0085] The SMF 366 then modifies 681 the N4 session for the accepted and / or rejected QoS flows of the PDU Session. For example, if the SMF 366 previously activated 644A PDU Set handling at the UPF 370, and the RAN 105 does not provide an indication of support of PDU Set handling (or provides an indication of non-support of PDU Set handling), the SMF 366 can instruct the UPF 370 to deactivate the PDU Set identification and marking for the accepted QoS flows. In this case, the RAN 105 does not activate PDU Set handling at the RAN 105, and the accepted QoS flows can ignore the PDU Set based QoS parameters. As another example, if the SMF 366 previously activated 644A PDU Set handling at the UPF 370, and the RAN 105 provides an indication of support of PDU Set handling (or does not provide an indication of nonsupport of PDU Set handling), the SMF 366 can instruct the UPF 370 to modify the N4 session to release resources for the rejected QFI(s) only. Events 690 and 692 can proceed as discussed with reference to Fig. 6A or Fig. 6B.

[0086] Now referring to Fig. 7, a node a CN, such as the PSA UPF 370, can implement a method 700 to determine whether to activate PDU Set handling.

[0087] At block 701, the CN node receives a registration message from the UE, to register for 3GPP access or (untrusted or trusted) non-3GPP access (see, e.g., event 501). At block 781, the CN node determines whether the access type is 3GPP Access or non-3GPP access. If yes, the flow proceeds to block 783, where the CN node activates PDU Set handling, as discussed above with reference to Figs. 6A-C. Otherwise, if the access type is non-3GPP access, the flow proceeds to block 874, where the CN node does not activate PDU Set handling.

[0088] Further, and referring generally to Figs. 8A-9C, when the UE changes its registration from one access type to another access type, the network needs to to move the PDU Session(s)from the first access (platform) to the second access (platform). Because only the RAN 105 can support PDU Set based handling, the SMF 166 must be able to properly instruct the UPF 370 whether to activate or deactivate PDU Set identification and marking. In particular, RAN 105 105 and one or more CN nodes can support at least the following four cases: (1) handover of a PDU session from non-3GPP access to 3GPP access, (2) handover of a PDU session from 3GPP access to non-3GPP access, (3) handover of a PDU session from non-3GPP access to 3GPP access with a RAT type that supports (or does not support) PDU Set handling, and (4) handover of a PDU session from 3 GPP access with a RAT type that supports (or does not support) PDU Set handling to non-3GPP access.

[0089] Referring first to Fig. 8A, an example scenario 800A involves a handover of a PDU session from untrusted non-3GPP access to 3GPP access. The UE 102 first registers 801 via non- 3GPP access and establishes a PDU session with a certain DNN and S-NSSAI. The PDU session also has a certain PDU session ID, by which the UE 102 and CN nodes can identify the PDU session. When performing 801 the PDU session establishment procedure, the SMF 166 does not request activation for PDU Set handling for the PDU session (because the access type was non-3GPP access).

[0090] The UE 102 then performs 802 a registration procedure via 3GPP access. Next, the UE 102 performs 810 a PDU Session Establishment procedure for the PDU session, which is moving from non-3GPP access to 3GPP access. The SMF 166 can operate as discussed above with reference to events 644A and 644B. As discussed above, the SMF 166 can determine whether to activate PDU Set identification and marking based on a set of conditions. In the case of Fig. 8A, the applicable conditions can be that (i) the PCC policies include PDU Set based QoS parameters for QoS flows and the Protocol Description, (ii) the requested DNN and S-NSSAI can be included in the list of subscribed DNN and S-NSSAI for XRM services, (iii) the received access type is 3GPP access, and (iv) the received RAT type is applicable based on the operator policies per the SMF configuration or the PCC policies for the UE 102. The SMF 166 then can send all the QFI(s) and QoS Profile(s) for the QoS Flow(s) that are applicable to the PDU Session for the target 3 GPP access to the AMF 164 (see event 647). TheNamf_Communication_NlN2MessageTransfer message to the N3IWF 167 via the AMF 164 caninclude a request to release the resources over the source non-3GPP access. The SMF 166 and the RAN 105 can maintain the existing PDU Session by not sending the PDU Session Release Command to the UE 102 and the maintain the SM context between the AMF 164 and the SMF 166. The CN nodes, the RAN 105, and the UE 102 can repeat the procedures 810 and 800 for all PDU Sessions that require moving from non-3GPP access to 3GPP access.

[0091] Fig. 8B is a messaging diagram of an example scenario 800B that involves a handover of a PDU session from 3GPP access to non-3GPP access. The UE 102 first registers 802 via 3 GPP access.

[0092] The UE 102 then establishes 811 a PDU with a certain DNN and S-NSSAI using the techniques discussed with reference to Fig. 6A-C. During the PDU Session Establishment procedure, the SMF 166 can operate as discussed above with reference to events 644A and 644B. As discussed above, the SMF 166 can determine whether to activate PDU Set identification and marking based on a set of conditions. In the case of Fig. 8B, the applicable conditions can be that (i) the PCC policies include PDU Set based QoS parameters for QoS flows and Protocol Description, (ii) the requested DNN and S-NSSAI is in the list of subscribed DNN and S-NSSAI for XRM services, (iii) the access type is 3GPP access, and (iv) the RAT Type is applicable based on the operator's policies per the SMF configuration or the PCC policies for the UE 102.

[0093] The UE 102 then performs 801 a registration procedure for non-3GPP access. Next, the UE 102 performs 817 a PDU session establishment procedure for the PDU session moving to the non-3GPP access. In particular, the SMF 166 needs to disable PDU Set handling and deactivate PDU Set Identification and marking at the UPF 170 (see events 644A and 644B). The SMF 166 can send, to the AMF 164, all the QFI(s) and QoS Profile(s) for the QoS Flow(s) that are applicable to the PDU Session for the target non-3GPP access (see event 647). To disable PDU Set handling, the SMF 166 can perform the following: (1) according to one implementation, request QoS based parameters from the N3IWF 167, without PDU Set QoS parameters, and (ii) according to another implementation, including a certain indication for the N3IWF 167, so that the N3IWF 167 knows to ignore the PDU Set based QoS parameters without rejecting the QoS flows moving to the other access type.

[0094] To release 880 the non-3GPP resources, the SMF 166 can transmit an Namf_Communication_NlN2MessageTransfer (enclosing an N2 resource release request) to the RAN 105 via the AMF 164, to release resources at the RAN 105. This message can include a request to release the resources over the source 3 GPP access. The SMF 166 and the RAN 105 can maintain the existing PDU Session by not sending the PDU Session Release Command to the UE 102. In particular, the SMF 166 can omit the N1 SM container from the Namf_Communication_NlN2MessageTransfer message. Further, the SMF 166 and the RAN 105 can maintain the SM context between the AMF 164 and the SMF 166. The CN nodes, the RAN 105, and the UE 102 can repeat the procedures 817 and 880 for all PDU Sessions that require moving across the access types.

[0095] Referring next to Figs. 9A-C, the UE 102 in some cases can register to 3GPP Access or (untrusted or trusted) non-3GPP access. If the UE has ATSSS capability, the UE 2102 can establish a Multiple Access (MA) PDU Session which allow the UE 1092 to select, switch, or steer the traffic between 3GPP access and non-3GPP access.

[0096] Because only NG-RAN can support PDU Set based handling, the network needs to deactivate PDU Set handling at the UPF 170, as long as the UE 102 has the MA PDU Session and is registered for non-3GPP access. The SMF 166 may need to instruct the UPF 170 to activate or deactivate the PDU Set identification and marking at the UPF 170 in the following cases: (1) when the UE 102 capable of ATSSS requests MA PDU Session that allows the UE 102 to select, switch, or steer the traffic between two registered accesses; (2) when the network determines to change a PDU Session to be of MA PDU Session type, so that the UE 102 may register for non-3GPP access, 3GPP access, or both for the MA PDU Session, and the 3GPP access may have the RAT type that supports (or does not support PDU Set handling); and (3) when the network determines to deregister non-3GPP access from a certain MA PDU Session.

[0097] The scenarios 900A-C illustrate the SMF 166 activating or deactivating, at the UPF 170, PDU Set handling.

[0098] Fig. 9A a messaging diagram of an example scenario 900A in which a UE registers for 3GPP access, non-3GPP access, or both, and establishes an MA PDU session. Here, the UEregisters 903A to either 3GPP access or non-3GPP access, or both, and establishes 910 an MA PDU Session using a PDU Session Establishment procedure.

[0099] The UE 102 indicates 905 A the request type as “MA PDU Request: in the UL NAS Transport message for the PDU Session Establishment Request, to establishing an MA PDU Session. The SMF 914A determines not to enable PDU Set handling for the MA PDU Session because the request type is MA PDU Session. The SMF 166 then performs 993 the actions 616, 618, 620, ... 652.

[0100] Fig. 9B a messaging diagram of an example scenario 900B in which the UE 102 registers for 3 GPP access only and establishes a PDU session. The AMF 164 can determine to change the PDU Session to be MA PDU Session, which results in the SMF 166 disabling PDU Set handling for the MA PDU Session. Here, the SMF 166 subscribes 923 to the AMF event exposure service, for notifications of changes of the PDU session request type of the UE for a specific PDU Session ID. In some implementations, a dedicated event ID is defined for the AMF notification service.

[0101] As illustrated in Fig. 9B, the UE 102 registers 903B to 3GPP access. The UE 905 requests to establish a PDU session as discussed above with reference to Figs. 6A-C, but here the SMF 166 also subscribes 923 to the AMF event exposure service for notifications of the change of the PDU Session Request type of the UE 102. The AMF 164 then notifies 994 the SMF 166 of the change of the PDU session request type, indicating the change of the PDU session request type for the associated PDU Session ID. The SMF can determine 995 to deactivate PDU Set handling for the MA PDU session, similar to the scenario of Fig. 9A.

[0102] Fig. 9C a messaging diagram of an example scenario 900C, in which a UE registers for both 3 GPP access and non-3GPP access and establishes a PDU session. The AMF 164 may determine to remover or deregister the non-3GPP access from the MA PDU Session, which may allow the SMF 166 to determine whether to enable PDU Set handling for the MA PDU Session with only registered 3 GPP access.

[0103] In particular, the UE registers 903C to both 3GPP access and non-3GPP access. The UE 102 then requests 910C to establish an MA PDU Session. The SMF 166 does not enable PDU Set handling is not enabled for the PDU session, similar to the scenario 900A of Fig. 9A,with the following additional step: the SMF 166 subscribe 923 to the AMF event exposure service for notification of the change of the access type of the UE.

[0104] The AMF 164 then deregisters 927 non-3GPP access from the MA PDU Session. The AMF 164 notifies 994C the SMF 166, if the SMF 166 is currently subscribed to the AMF service for the notifications, with the change of access type corresponding to the PDU Session ID. The SMF 166 can determine 996 to activate PDU Set handling for the MA PDU Session as discussed above with reference to events 644A and 644B, based on the following conditions or factors: (i) the PCC policies include PDU Set based QoS parameters for QoS flows and the Protocol Description, (ii) the requested DNN and S-NSSAI is in the list of subscribed DNN and S-NSSAI for XRM services, (iii) the access type is 3GPP access only, and (iv) the RAT Type is applicable based on the operator policies per the SMF 166 configuration or the PCC policies for the UE 102.

[0105] As yet another example, the UE 192 can register to 3GPP access only and establishes a PDU Session. The approach of Fig. 9C can apply if the AMF 164 determines to change the PDU session to be an MA PDU Session, which may result in the SMF 166 maintaining the activated PDU Set handling for the MA PDU Session until the UE 102 registers for non-3GPP access.

[0106] Fig. 10 is a flow diagram of an example method for determining whether to activate PDU Set handling based on access type, which a CN node of Fig. 1 can implement. At block 1010, the CN node receives, from a UE, a request to establish or update a PDU session. At block 1021, the CN node determines the access type for the UE (e.g., 3GPP access, non-3GPP access). At block 1080, the CN node enables or disables, for the PDU session and based on the access type, PDU Set handling (see events 644A, 644B, 680).

[0107] The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure.

[0108] Example 1. A method implemented in a node of a CN, the method comprising: receiving, from a UE, a request to establish or update a PDU session; determining an access type for the UE; and enabling or disabling, for the PDU session and based on the access type, PDU Set handling.

[0109] Example 2. The method of example 1, wherein the request to establish or update the PDU session is received via a RAN.

[0110] Example 3. The method of example 1 or 2, wherein the enabling or disabling includes disabling the PDU Set handling when the access type is non-3GPP access.

[0111] Example 4. The method of example 3, wherein the PDU session was previously established when the UE accessed the CN with 3GPP access.

[0112] Example 5. The method of example 4, wherein the disabling of the PDU Set handling includes transmitting, from an SMF to a UPF, a request to disable the PDU Set handling for the PDU session.

[0113] Example 6. The method of example 5, wherein the request to disable the PDU Set handling for the PDU session includes an instruction to deactivate PDU Set identification and marking for accepted QoS flows.

[0114] Example 7. The method of example 5 or 6, wherein the disabling of the PDU Set handling includes requesting, by the SMF from an N3IWF, QoS parameters for QoS flows included in the PDU session, including refraining from requesting PDU Set QoS parameters.

[0115] Example 8. The method of example 5 or 6, wherein the disabling of the PDU Set handling includes transmitting, from the SMF to a N3IWF, an indication to (i) ignore PDU Set QoS parameters and (ii) not reject QoS flows in the PDU session.

[0116] Example 9. The method of example 1 or 2, wherein the enabling or disabling include enabling the PDU Set handling when the access type is 3 GPP access.

[0117] Example 10. The method of example 9, wherein the PDU session was previously established when the UE accessed the CN with non-3GPP access.

[0118] Example 11. The method of example 9, further comprising establishing the PDU Session as a multiple-access MA PDU session associated with both 3GPP access and non-3GPP access; and wherein the enabling of the PDU Set handling is in response to deregistering the non- 3GPP access from the MA PDU session.

[0119] Example 12. The method of example 11, further comprising subscribing, at an SMF, to an Access and Mobility Management Function (AMF) event exposure service; wherein the enabling of the PDU Set handling is response to receiving, from the AMF, an indication of a change of the MA PDU session to a single-access PDU session.

[0120] Example 13. The method of example 1 or 2, wherein the enabling or disabling includes disabling the PDU Set handling when the PDU session is a MA PDU session associated with both 3GPP access and non-3GPP access.

[0121] Example 14. The method of example 13, further comprising establishing the PDU Session with an access type corresponding to 3 GPP access only; and wherein the enabling of the PDU Set handling is in response to additionally registering non-3GPP access for the PDU session.

[0122] Example 15. The method of example 14, further comprising subscribing, at an SMF, to an AMF event exposure service; wherein the disabling the PDU Set handling is response to receiving, from the AMF, an indication of a change of the PDU session to the MA PDU session.

[0123] Example 16. The method of example 13, wherein the disabling the PDU Set handling is response to receiving, at an SMF from an AMF, a request to create a context for the PDU session, the request including a request type indicating the MA PDU session.

[0124] Example 17. The method of any of examples 1-4 or 9-16, wherein the determining of the access type for the UE includes receiving, at an SMF from an AMF, a request to create a context for the PDU session, the request indicating the access type.

[0125] Example 18. The method of example 15, wherein the request includes an indication of a radio access technology (RAT) type for a radio access network (RAN); and the enabling or disabling is further based on the indication of the RAT type.

[0126] Example 19. The method any of examples 1-17, wherein the enabling or disabling is further based on whether a RAN supports PDU Set handling.

[0127] Example 20. A node in a CN comprising processing hardware and configured to implement a method of any of the preceding examples.Additional considerations

[0128] The following additional considerations apply to the foregoing discussion.

[0129] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0130] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code stored on non- transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0131] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed orinherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0132] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more specialpurpose processors.

Claims

What is claimed is:

1. A method implemented in a node of a core network (CN), the method comprising: receiving, from a user equipment (UE), a request to establish or update a protocol data unit (PDU) session; determining an access type for the UE; and enabling or disabling, for the PDU session and based on the access type, PDU Set handling.

2. The method of claim 1, wherein the enabling or disabling includes: disabling the PDU Set handling when the access type is non- 3rd Generation Partnership Project (3GPP) access.

3. The method of claim 2, wherein: the PDU session was previously established when the UE accessed the CN with 3GPP access.

4. The method of claim 3, wherein the disabling of the PDU Set handling includes: transmitting, from a Session Management Function (SMF) to a User Plane Function(UPF), a request to disable the PDU Set handling for the PDU session.

5. The method of claim 4, wherein the request to disable the PDU Set handling for the PDU session includes an instruction to deactivate PDU Set identification and marking for accepted quality-of-service (QoS) flows.

6. The method of claim 1, wherein the enabling or disabling includes: enabling the PDU Set handling when the access type is 3rd Generation Partnership Project (3GPP) access.

7. The method of claim 6, wherein: the PDU session was previously established when the UE accessed the CN with non- 3 GPP access.

8. The method of claim 1, wherein the enabling or disabling includes: disabling the PDU Set handling when the PDU session is a multiple access (MA) PDU session associated with both 3GPP access and non-3GPP access.

9. The method of claim 8, further comprising: establishing the PDU Session with an access type corresponding to 3GPP access only; and wherein the enabling of the PDU Set handling is in response to: additionally registering non-3GPP access for the PDU session.

10. The method of claim 9, further comprising: subscribing, at an SMF, to an AMF event exposure service; wherein the disabling the PDU Set handling is response to receiving, from the AMF, an indication of a change of the PDU session to the MA PDU session.

11. The method of claim 8, wherein the disabling the PDU Set handling is response to: receiving, at an SMF from an AMF, a request to create a context for the PDU session, the request including a request type indicating the MA PDU session.

12. The method of any of claims 1-3, 6, 7, or 8, wherein: the determining of the access type for the UE includes receiving, at an SMF from an AMF, a request to create a context for the PDU session, the request indicating the access type.

13. The method of claim 10, wherein:the request includes an indication of a radio access technology (RAT) type for a radio access network (RAN); and the enabling or disabling is further based on the indication of the RAT type.

14. The method any of claims 1-12, wherein: the enabling or disabling is further based on whether a RAN supports PDU Set handling .

15. A node in a core network (CN) comprising processing hardware and configured to implement a method of any of the preceding claims.

Images