Supporting PDU sessions for access networks of cellular communication systems

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; determining the access type of the UE; and enabling or disabling PDU set handling for the PDU session and based on the access type.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit on the filing dates of U.S. Provisional Patent Application No. 63 / 519,229, filed August 11, 2023, entitled "PDU Session with Access Network Support for XR and Media Services in a Communication System," and U.S. Provisional Patent Application No. 63 / 541,444, filed September 29, 2023, entitled "PDU Session with Access Network Support for XR and Media Services in a Communication System." The entire contents of these provisional applications are hereby expressly incorporated by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and more specifically to user consent for managing analytics and event monitoring operations in cellular communication networks. Background Technology

[0004] This background description is provided for the purpose of presenting the general context of this disclosure. The work of the currently attributed inventors (to the extent described in this background section) and aspects of the specification that might not have been considered prior art at the time of filing are neither expressly nor impliedly acknowledged as prior art to this disclosure.

[0005] Generally, base stations operating a cellular radio access network (RAN) use a radio access technology (RAT) and multiple layers of a protocol stack to communicate with user equipment (UE). For example, the physical layer (PHY) of the RAT provides a transport channel to the Media Access Control (MAC) sublayer, which in turn provides a logical channel to the Radio Link Control (RLC) sublayer, which in turn provides data delivery services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer sits above the PDCP sublayer. The Serving Data Adaptation Protocol (SDAP) layer, situated above the PDCP layer, supports Packet Data Unit (PDU) sessions comprising one or more Quality of Service (QoS) streams. The core network (CN) uses multiple layers of the protocol stack to transmit data to the UE via the RAN.

[0006] Some services of the fifth-generation system (5GS) require high data rates and low latency transmission. An example of such services is extended reality (XR), which includes augmented reality (AR), virtual reality (VR), and mixed reality (MR). In virtual reality applications, users are typically fully immersed in a virtual environment that completely replaces the real physical environment by wearing a headset. In augmented reality, applications enhance the perception of the real environment by overlaying virtual elements onto it. Augmented reality has recently become the basis for a popular game where players find and interact with virtual creatures superimposed on a live video stream of the real world. Finally, mixed reality is an extension of AR where real and virtual elements can interact in real time.

[0007] XR games and other applications typically run on cloud platforms that include remote servers and generally do not require game consoles, high-spec CPUs, or high-spec GPUs. Cloud gaming involves streaming games similar to streaming video, with the game responding to player commands and controls in real time.

[0008] To better support high data rate, low latency services such as XR, the 3rd Generation Partnership Project (3GPP) recently proposed grouping certain Packet Data Units (PDUs) into sets of multiple PDUs. These PDUs carry the payload of a single information unit (e.g., a frame or video slice) generated at the application level. PDUs within a set can be equally important to the application level. 3GPP further proposed supporting Quality of Service (QoS) requirements based on PDU sets.

[0009] The RAN can process PDU sets based on the PDU set QoS parameters and PDU set information in the header of the General Packet Radio Service (GPRS) Tunneling Protocol (GTP)-U packets dedicated to GTP user data. This PDU set information is provided by the PDU Session Anchor (PSA) User Plane Function (UPF) operating in the core network. In the CN, the Session Management Function (SMF) performs QoS flow binding based on the service data flow, configures the UPF via the GTP-U header using rules for PDU set identification and labeling, and provides the RAN with a QoS profile including the PDU set QoS parameters through the N2 interface. More specifically, the SMF can provide the UPF with a protocol description indicating the service data flow header (e.g., RTP / SRTP) and payload type (e.g., H.264) of the media flow originating from the application server.

[0010] The PSA UPF can receive downlink (DL) PDUs from the data network (DN) via the N6 interface. When PDU set processing is applied, rules for PDU set identification are applied, and PDU set information is provided to the RAN in the GTP-U header. If the RAN receives PDU set QoS parameters and supports such parameters, the RAN enables PDU set-based QoS processing and applies the PDU set QoS parameters.

[0011] Generally, PDU set identification and marking are resource- and time-intensive operations at the UPF. However, it is currently unclear how the UPF and / or other CN nodes should handle PDU set QoS provisioning, depending on whether the access network supports or does not support PDU set handling. For example, when a UE moves between 3GPP and non-3GPP access, it is unclear how the SMF can determine whether to activate or deactivate PDU set identification and marking during UPF PDU set handling. This issue applies at least to the following scenarios: (i) switching a PDU session from non-3GPP access to 3GPP access, and (ii) switching a PDU session from 3GPP access to non-3GPP access.

[0012] Furthermore, 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 types for 3GPP access, or a certain RAT type may not be suitable for XRM services, or operator policies may not allow a particular RAT type. It is currently unclear how the SMF can determine whether to activate or deactivate the PDU set identifier and tag at the UPF when a UE registers to 3GPP access via a specific RAT type (e.g., NR). This issue applies at least to the following scenarios: (i) switching a PDU session from a non-3GPP access to a 3GPP access with a RAT that supports (or does not support) PDU set processing, and (ii) switching a PDU session from a 3GPP access to a non-3GPP access with a RAT that supports (or does not support) PDU set processing.

[0013] Furthermore, UEs capable of Access Traffic Directing, Handover, and Offloading (ATSSS) can request a Multiple Access (MA) PDU session, or the network can determine to change the PDU session type to an MA PDU session type to allow the UE to select, handover, or direct traffic between two registered access types. However, it is currently unclear whether the system can activate or deactivate PDU set handling at the UPF for the MA PDU session. This issue applies at least to the following scenarios: (i) a UE capable of ATSSS requests an MA PDU session to select, handover, or direct traffic between two registered access types; (ii) the network determines to change the PDU session to an MA PDU session type such that the UE can register non-3GPP access, 3GPP access, or both for the MA PDU session, and the 3GPP access can 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 the MA PDU session, and the 3GPP access can be associated with a RAT type that supports (or does not support) PDU set handling. Summary of the Invention

[0014] An example embodiment of the technology disclosed herein is a method implemented in a node of a CN. The node receives a request from a user equipment (UE) to establish or update a Protocol Data Unit (PDU) session, determines the UE's access type, and enables or disables PDU set processing for the PDU session based on the access type.

[0015] Another example embodiment of these technologies is a node in a CN that includes processing hardware and is configured to implement the methods described above. Attached Figure Description

[0016] Figure 1 This is a block diagram of an example wireless communication system in which a User Equipment Unit (UE) can access the core network via 3GPP access or non-3GPP access, and nodes in the CN can determine whether to activate PDU set processing for the UE based on the access type.

[0017] Figure 2 yes Figure 1 The UE can be based on its relationship with Figure 1 A block diagram of an example protocol stack for RAN communication;

[0018] Figure 3 It is a service-based representation of the CN architecture, including the overall non-roaming reference architecture of the cellular communication system's policy and charging control framework;

[0019] Figure 4 It is a reference point-based representation of the CN architecture, including the overall non-roaming reference architecture of the cellular communication system's policy and charging control framework;

[0020] Figure 5 It can be shown that Figure 1 The reference procedures implemented in the system for establishing, modifying, and releasing PDU sessions;

[0021] Figure 6A This is a message passing diagram of an example scenario in which SMF determines whether to activate PDU set processing based on one or more parameters such as access type;

[0022] Figure 6B This is a message passing diagram of an example scenario in which the RAN provides the SMF with an indication of support or lack thereof for the handling of the PDU set before the SMF performs UPF selection and configuration;

[0023] Figure 6C This is a message passing diagram of an example scenario in which the RAN provides the SMF with an indication of support or lack of support for PDU set processing in the N2 PDU session response message;

[0024] Figure 7 This is a flowchart of an example method for determining whether to activate PDU set disposal. Figure 1 The CN node can implement this method;

[0025] Figure 8A This is a message passing diagram that includes an example scenario of switching a PDU session from an untrusted non-3GPP access to a 3GPP access.

[0026] Figure 8B This is a message passing diagram that includes an example scenario of switching a PDU session from 3GPP access to non-3GPP access;

[0027] Figure 9A This is a message passing diagram for an example scenario where a UE registers for 3GPP access, non-3GPP access, or both and establishes an MA PDU session.

[0028] Figure 9B This is a message passing diagram for an example scenario where a UE registers for 3GPP access only and establishes a PDU session;

[0029] Figure 9C This is a message passing diagram for an example scenario where a UE registers with both 3GPP access and non-3GPP access and establishes a PDU session; and

[0030] Figure 10 This is a flowchart of an example method for determining whether to activate PDU set processing based on access type. Figure 1 The CN node can implement this method. Detailed Implementation

[0031] In at least some of the scenarios discussed below, the UE and CN support PDU set-based data processing (or simply "PDU set processing"), where a PDU set comprises one or more PDUs carrying a payload of one information element. The apparatus can generate PDU sets at the application level. Applications can transmit PDUs of a PDU set within the same QoS stream and can use PDU set parameters such as PDU set delay budget (PSDB), PDU set error rate (PSER), and PDU set integrated processing information (PSIHI). For example, a PDU set may correspond to a frame or video slice of an XR service and a media service (collectively, "XRM service"). In some cases, the application generates and transmits multiple PDUs as a data burst within a relatively short time period, which may include one or more PDU sets.

[0032] RAN supports PDU set processing in some cases, but not in others. (See reference) Figures 1 to 10 The techniques discussed allow cellular systems to configure QoS flows based on one or more factors, such as the UE's access type (3GPP, non-3GPP, or both), the RAN's RAT type, and the RAN's PDU set processing capabilities. In the example scenario, PDU set-based QoS configuration applies only when the UE registers for 3GPP access, or only when the UE registers for 3GPP access using the applicable RAT type.

[0033] To consider services such as XRM, during the registration process, the AMF can determine whether a UE is authorized to use the XRM service based on XRM service capabilities and XRM service authorization. The Unified Data Management (UDM) provides this XRM service capability and XRM service authorization to the AMF as part of the UE's subscription data. The UE in the example below supports XRM service capabilities for PDU set processing.

[0034] First refer to Figure 1 The example wireless communication system 100 may implement one or more of the techniques disclosed herein for handling PDU sessions requiring PDU set processing. The UE 102 may access CN 110 using one of several access types: via RAN 105, via a non-3GPP access network 107, or both. One or more nodes operating in CN 110 may determine whether to activate or deactivate PDU set processing, at least in part, based on the access type.

[0035] RAN 105 includes base station 104 providing service in cell 124 and base station 106 providing service in cell 126. When base station 104 is implemented as a gNB, cell 124 is an NR cell. When base station 124 is implemented as an ng-eNB, cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, when base station 106 is implemented as a gNB, cell 126 is an NR cell, and when base station 126 is implemented as an ng-eNB, cell 126 is an E-UTRA cell. Cells 124 and 126 may be located in the same Radio Access Network Notification Area (RNA) or different RNAs. Cells 124 and 126 may partially overlap, allowing UE 102 to select, reselect, or switch from one cell to the other. Generally, RAN 105 may include any number of base stations, and each base station may cover one, two, three, or any other suitable number of cells. UE 102 can at least support a 5G NR (or simply "NR") air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 can be connected to CN 110 via a suitable interface (e.g., an S1 or NG interface). Base stations 104 and 106 can also be interconnected via an interface used to interconnect NG RAN nodes (e.g., an X2 or Xn interface).

[0036] CN 110 may include Policy Control Function (PCF) 160, Access and Mobility Management Function (AMF) 164, User Plane Function (UPF) 170, and Session Management Function (SMF) 166. Non-3GPP Interoperability Function (N3IWF) 167 provides an interface between AMF 164 and UPF 170 operating in CN110 and the non-3GPP access network 107. For example, the non-3GPP access network 107 may include device 108 (e.g., a wireless local area network (WLAN) access point), and UE 102 may access CN 110 via device 108 and N3IWF 167. Reference Figure 3 and Figure 4 The example implementation of CN 110 will be discussed in more detail.

[0037] Although not in order to avoid clutter Figure 1 As depicted herein, CN 110 may include processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable storage medium for storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include dedicated processing units. The processing hardware may be configured to implement the techniques disclosed herein for supporting PDU sessions.

[0038] Each of base stations 104 and 106 may be equipped with processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable storage of instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include dedicated processing units. Base stations 104 and 105 also include transceivers for communicating with a UE, such as UE 102, via a radio interface.

[0039] UE 102 is equipped with processing hardware 130A, which may include one or more general-purpose processors such as a CPU and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units. UE 102 also includes a transceiver 132A for communicating with RAN 105 via a radio interface. Furthermore, CN 110 may implement PDU set controller 180A (e.g., in AMF 164 and / or SMF 166), and UE 102 may implement PDU set controller 180A.

[0040] In operation, AMF 164 may use, for example, the procedures described in Clause 5.3.2.3 of TS 23.501 (related to registration area management) to determine the access type and RAT type of UE 102.

[0041] Figure 2 An example protocol stack 200 is illustrated in a simplified manner, which UE 102 can use to communicate with an eNB / ng-eNB 230 or gNB 232 (e.g., one or more of base stations 104, 106). In the example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then be routed to the Service Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer. Figure 2 (Not shown in the image) provides data transmission services. In some implementations, UE102A, 102B, or 102C supports, for example... Figure 2The EUTRA and NR stacks shown are designed to support handover between EUTRA and NR base stations and / or support DCs via the EUTRA and NR interfaces. Further, as... Figure 2 As shown, UE 102A or 102B can support the layering of NR PDCP 210 on top of EUTRA RLC 206A, and the layering of SDAP sublayer 212 on top of NR PDCP sublayer 210.

[0042] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 receive packets that may be referred to as Service Data Units (SDUs) (e.g., from Internet Protocol (IP) layers that are directly or indirectly layered on PDCP layers 208 or 210), and output packets that may be referred to as Protocol Data Units (PDUs) (e.g., to RLC layers 206A or 206B). Except where the difference between SDU and PDU is relevant, for simplicity, this disclosure refers to both SDU and PDU as “packets”.

[0043] For example, on the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide signal transmission radio bearer (SRB) or RRC sublayer ( Figure 2 (Not shown in the diagram) to exchange RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide data radio bearers (DRBs) to support data exchange. The data exchanged on NRPDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

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

[0045] The PCC framework in Architecture 300 includes Unified Data Repository (UDR) 352, Network Open Function (NEF) 354, Network Data Analysis Function (NWDAF) 356, Application Function (AF) 358, PCF 360, Charging Function (CHF) 362, AMF 364, SMF 366, and UPF 370.

[0046] The N3IWF 367 can access the non-3GPP access network 107 via the Y2 interface and access the UPF370 via the N3 interface, similar to RAN 105.

[0047] The AMF 364 is typically configured to manage the registration, connectivity, and mobility of UEs (such as UE 102A or 102B) and to provide the transmission of session management (SM) messages between 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 typically configured to manage sessions, assign IP addresses to UEs, and provide downlink (DL) notifications. In some implementations, the SMF 366 also includes the following functionalities for PIN services: providing non-3GPP QoS assistance information per QoS flow to UEs (e.g., PEGCs), and supporting IP address allocation for UEs and PDR configuration with a packet filter set for PIN to UPF for frame routing based on PIN group information from the UDM 353.

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

[0049] UPF 370 is typically configured to handle packet routing and forwarding. Additionally, NEF 354 is configured to expose network capabilities and services to authorized third-party applications. For example... Figure 3 As shown, UPF 370 can provide the UE with access to data network 330, and conversely, allow one or more application servers in data network 330 to establish PDU sessions with UE 102.

[0050] In some deployments, the AF 358 operates either within a trusted domain or outside a trusted domain—that is, in an untrusted domain. A trusted domain is typically located within a CN and includes components such as UDM 353, UDR 352, PCF 360, AMF 364, SMF 366, and UPF 370. Generally, an AF operating outside a trusted domain (such as by an authorized third-party entity) can only access the CN's network functions via NEF 354, while an AF operating within a trusted domain can directly access at least some of the CN's network functions, or in some deployments, can access these functions via NEF 354.

[0051] Figure 4 This is a reference-point-based representation of the example CN architecture, number 400. Figure 4 In the diagram, the non-roaming reference architecture of the PCC framework is shown as blocks and connections using solid lines, while components and connections outside the PCC framework are shown using dashed lines.

[0052] Figures 1 to 4 The communication system shown may include additional, fewer, and / or alternative means or functions, and may be configured to perform additional, fewer, or alternative actions, including the functions / actions described herein.

[0053] Next, Figure 5 The example shown is a reference scenario 500 in which the UE establishes and modifies a PDU session. This scenario can be implemented in... Figure 1 This is implemented in the system. During the registration process, the AMF can determine whether the UE is authorized to use XRM services based on the UE's XRM service capabilities and the XRM service authorization included in the subscription data received from the UDM (e.g., as specified in Clause 5.7 of TS 23.501).

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

[0055] UE 102 or the network can initiate a 570 PDU session modification procedure for an existing PDU session. For example, the PDU session modification procedure can be implemented as described in clauses 4.3.3.2 and 4.3.3.3 of TS23.502. UE 102 can repeat the 504 PDU session establishment procedure for multiple PDU sessions associated with the same or different Data Network Names (DNNs) and Single Network Slice Selection Auxiliary Information (S-NSSAI).

[0056] For example, UE 102 and the network can perform the 508 PDU session release procedure on existing PDU sessions, for example, as described in Clause 4.3.4 of TS 23.502. Furthermore, UE 102 and the network can perform the 571 deregistration procedure to release all existing PDU sessions, for example, as described in Clause 4.2.2.3 of TS 23.502.

[0057] When the PLMN provides homogeneous RAN support for PDU set processing, the Reference 500 procedure may include modifications briefly discussed below to support PDU set-based QoS. For example, the PCF 360 may provide PCC rules for application service flows as defined in Clause 6.1.3.27.4 of TS 23.503. Application service flows may include PDU set QoS parameters (e.g., PSER, PSDB, and PSIHI) and a protocol description. The SMF 366 may determine the QoS profile for the QoS flow based on the received PCC rules or pre-configuration. The PSA UPF 360 may use the protocol description and the received Packet Detection Rules (PDR) to identify PDUs belonging to the PDU set. Furthermore, the PSA UPF 360 may use a GTP-U header that tags PDU set information as described in Clause 5.37.5.2 of TS 23.501. Additionally, the PSA UPF 360 may generate PDU set-based parameters based on QoS Enforcement Rules (QER).

[0058] Next, combined Figures 6A to 6C and Figures 8A to 9C Message passing diagram and Figure 7 and Figure 10 The flowchart considers several methods for configuring PDU sessions, especially the handling of PDU sets. Generally speaking, Figures 6A to 10 Similar events in the figure are marked with similar figure labels that share two least significant figures, and the differences are discussed below where appropriate.

[0059] In addition, refer to AMF 364, UDM 353, SMF 366, UPF 370, PCF 250 and DN 330 for discussion. Figures 6A to 6CExamples of scenarios are provided. However, in these scenarios, AMF 164 can function similarly to AMF 364, SMF 166 can function similarly to SMF 366, PCF 160 can function similarly to PCF 360, and UPF 170 can function similarly to UPF 370.

[0060] According to some methods, CN 110 determines whether to activate PDU set processing for a PDU session associated with a certain DNN and S-NSSAI based on one or more of the following conditions: QoS parameters of the PDU set, protocol description, a list of DNN and S-NSSAI values ​​for subscriptions to XRM services, access type, RAT type, or PDU session request type (e.g., initial request, existing PDU session, MA PDU session).

[0061] exist Figure 6A In scenario 600A, SMF 366 determines whether to activate PDU set identification and marking at PSA UPF 370 for a PDU session with a specific DNN and S-NSSAI. More specifically, the apparatus in scenario 600A enhances the PDU session establishment or modification process as follows: RAN 105 provides SMF 166 with a reason value for the rejected QoS Flow Identifier (QFI) via AMF 164. SMF 166 determines whether to enable PDU set handling (if supported) at RAN 105 by requesting the PDU set QoS parameters for the QoS flow used in the PDU session.

[0062] UE 102 first sends a 610 PDU session establishment request message to AMF 364, which includes the PDU session ID, DNN, and S-NSSAI. The DNN and S-NSSAI can be associated with a specific XRM service. The PDU session establishment request message can indicate the request type, such as an initial request, an existing PDU session, or an MA PDU session. AMF 364 then performs a 612 SMF selection based on the DNN and S-NSSAI. If the DNN and S-NSSAI are associated with an application that requires QoS based on the PDU set, AMF 364 can select a specific SMF capable of PDU set processing, such as SMF 366.

[0063] Next, AMF 364 sends a 614 Nsmf_PDU Session_CreateSMContext request message to the selected SMF 366, including the PDU session ID, DNN and S-NSSAI, access type, RAT type, and request type. For example, AMF 164 can determine the access type and RAT type as described in Clause 4.2.2.2.1 of TS 23.502. AMF 164 can store the S-NSSAI, DNN, PDU session ID, SMF ID, and access type of the PDU session.

[0064] SMF 366 can retrieve subscription data related to XRM (616) for UE 102 based on DNN and S-NSSAI. In response to receiving the 614 Nsmf_PDU Session_CreateSMContext request message, SMF 366 sends a 618 Nsmf_PDU Session_CreateSMContext response message to AMF 364. Then, SMF 366 uses the user credentials provided by UE 102 for the connection to DN330 to perform the PDU session authentication / authorization process (620) between DN330 and DN330.

[0065] In addition, SMF 366 performs 644A UPF selection and determines whether to activate (or enable) PDU set identification and marking for PDU sessions associated with DNN and S-NSSAI at PSA UPF 370. To this end, and if necessary, SMF 366 queries 645 PCF 360 to retrieve and / or update PCC policies. SMF 366 may determine whether to activate PDU set identification and marking in 644A based on one or more of the following factors and / or conditions: (i) QoS parameters based on the PDU set, (ii) protocol description, (iii) a list of DNN and S-NSSAI for subscription to XRM services, (iv) access type (e.g., 3GPP access, non-3GPP access, or both), (v) RAT type (e.g., NR, LTE-M, satellite, etc.), or (vi) PDU session request type (e.g., initial request, existing PDU session, MA PDU session).

[0066] When PDU set processing is applicable, SMF 266 can instruct PSA UPF 370 to activate PDU set identification and marking for PDU sessions with corresponding DNN and S-NSSAI.

[0067] although Figure 6AIt is shown that event 645 occurs after event 644A, but it should be understood that event 644A may overlap at least partially in time. When the SMF 366 determines that the PCC policy requires PDU set processing, the SMF 366 instructs the PSA UPF 360 to activate the PDU set identifier and tag for the PDU session corresponding to the DNN and S-NSSAI.

[0068] Continue to refer to Figure 6A If SMF 366 determines that PDU set processing should be activated for a PDU session of UE 102, SMF 366 sends a 647 Namf_Communication_N1N2MessageTransfer message, which includes PDU set QoS parameters, to AMF 364 to enable (or activate) PDU set processing at RAN 105. AMF 364 then forwards a 650 NAS message to RAN 105 in an N2 PDU session request message.

[0069] RAN 105 then performs the RRC reconfiguration procedure for UE 102 (652). Specifically, RAN 105 sends a PDU session establishment accept message (652) for AN-specific resource settings at UE 102. RAN 105 also instructs AMF 364 (654) on whether RAN 105 accepts or rejects QoS parameters based on the PDU set for the PDU session. More specifically, RAN 105 sends an N2 PDU session response (654) to AMF 364, including the PDU session ID, reason, and a list of accepted and / or rejected QFI messages. Each QFI is a QoS flow identifier for the corresponding QoS flow. RAN 105 may include an appropriate reason value for the rejected QFIs (654), which could be a lack of support for the PDU set handling at RAN 105 (due to S-NSSAI, DNN, lack of radio resources, etc.). AMF 364 then sends an Nsmf_PDUSession_Update_SMContext request message (656) to SMF 366, which includes the PDU session ID, reason, and a list of accepted and / or rejected QFIs.

[0070] SMF 366 can modify session 680 (N4) for accepted and / or rejected QoS flows of a PDU session. Modification 680 can be applied to UPF 370. For example, based on the cause value, SMF 366 can determine whether to deactivate PDU set processing for the PDU session at UPF 370, or only deactivate PDU set identifiers and tags for rejected QoS flows. If RAN 105 rejects a QoS flow, SMF 366 can instruct UPF 370 to release the rejected QoS flow, but maintain PDU set processing for accepted QoS flows. Requesting QoS parameters at RAN 105 without PDU set processing may incur additional signaling overhead.

[0071] SMF 366 sends a 690 Nsmf_PDUSession_UpdateSMContext response message to AMF 364, which then sends a 692 PDU session establishment response message to UE 102.

[0072] Next, Figure 6B Example scenario 600B is shown where RAN 105 provides an indication of support for or lack of support for PDU set processing to SMF 366 via AMF 158 before SMF performs UPF selection and configuration. Here, SMF 366 requests PDU set QoS parameters for one or more QoS flows used in a PDU session and uses PCC policies and support indications to determine whether to request activation of PDU set processing at RAN 105. AMF 364 uses a non-UE-specific N2 procedure to obtain information related to support for PDU set processing at RAN 105. AMF 364 then stores RAN 105 capabilities related to supporting PDU set processing.

[0073] In scenario 600B, RAN 105 also provides support indications to SMF 366 via AMF 364. Specifically, during the PDU session establishment request process, AMF 364 provides indications for supporting PDU set processing at RAN 105, as discussed below. During the PDU session modification request process, AMF 364 may send indications for supporting PDU set processing at RAN 105 to SMF 366. SMF 366 can then base its indications on whether or not PDU set processing is supported at RAN 105, as well as the above references. Figure 6A One or more conditions are discussed to determine whether to activate or deactivate PDU set handling at UPF 370: based on the QoS parameters of the PDU set, protocol description, list of DNN and S-NSSAI for subscription to XRM service, access type, RAT type, or PDU session request type.

[0074] More specifically, RAN 105 and AMF 364 can exchange RAN configuration information (602), and RAN 105 provides AMF 364 with an indication (602) of whether it supports or does not support PDU set processing at RAN 105. RAN 105 and AMF 364 can use non-UE-specific N2 messages or procedures. AMF 364 can store the capability of RAN 105 to support PDU set processing.

[0075] Then, UE 102 sends a 610 PDU session establishment request message to AMF 364, which includes the PDU session ID, DNN, and S-NSSAI, as referenced above. Figure 6A The AMF 364 then performs 612 SMF selection based on DNN and S-NSSAI, as in scenario 600A.

[0076] The AMF 364 sends an Nsmf_PDU Session_CreateSMContext request message (615) to the SMF 366, which includes the PDU session ID, DNN, S-NSSAI, and an indication of whether RAN 105 supports PDU set handling. In some implementations, the AMF 364 only provides the SMF 366 with the 615 indication of whether RAN 105 supports PDU set handling if the DNN and S-NSSAI are associated with an application requiring PDU set-based QoS. Furthermore, the AMF 364 can store an indication of support (or lack thereof) for PDU set handling at RAN 105, which may have a RAN ID, such as the global RAN node ID associated with the N2 interface. Events 616, 618, and 620 can be referenced as above. Figure 6A Proceed as discussed.

[0077] SMF 366 performs 644B UPF selection and determines whether to activate (or enable) PDU set identification and tagging for the PDU session associated with the DNN and S-NSSAI at PSA UPF 370. To do this, and if necessary, SMF 366 queries 645PCF 360 to retrieve and / or update the PCC policy. Operation 644B is generally similar to operation 644A, but here SMF 366 also considers indications of support or lack thereof for PDU set disposal at the RAN receiving 615 from AMF 364.

[0078] Therefore, SMF 366 can determine whether to activate the PDU set identifier and tag for 644B based on whether RAN 105 supports PDU set handling and one or more of the following factors and / or conditions: (i) QoS parameters based on the PDU set, (ii) protocol description, (iii) a list of DNNs and S-NSSAIs for subscriptions to XRM services, (iv) access type (e.g., 3GPP access, non-3GPP access, or both), (v) RAT type (e.g., NR, LTE-M, satellite, etc.), or (vi) PDU session request type (e.g., initial request, existing PDU session, MA PDU session). When it is determined that PDU set handling is required, SMF 366 can instruct PSAUPF 370 to activate the PDU set identifier and tag for PDU sessions with a specific DNN and S-NSSAI. By indicating whether RAN 105 supports PDU set processing, SMF 366 reduces the likelihood that RAN 105 will reject one or more QoS flows due to PDU set-based processing requests, which would result in additional signaling overhead associated with the requested QoS parameters.

[0079] For example, in response to receiving an indication that RAN 105 supports PDU set processing, the PCC policy includes PDU set-based QoS parameters for QoS flows, the access type is 3GPP access, and the RAT type is NR, SMF 266 can activate PDU set processing at UPF 370.

[0080] Events 645, 647, 650, 652, 654, 656, 690, and 692 can be found as follows: Figure 6A Proceed as discussed. Also with Figure 6A Similarly, SMF 366 can modify the 680 N4 session for accepted and / or rejected QoS flows of the PDU session. In some implementations, SMF 366 activates PDU set identifiers and tags for accepted PDU-based QoS flows.

[0081] Figure 6C Example scenario 600C is shown where the RAN provides an indication to the SMF in the N2 PDU session response message regarding support or lack of support for PDU set processing. RAN 105, AMF 364, and SMF 366 perform an enhanced PDU session establishment or modification procedure, which includes RAN 105 indicating whether or not support for PDU set processing is provided. Specifically, SMF 366 can base its instructions on the above reference... Figure 6A and Figure 6BThe conditions discussed (QoS parameters based on the PDU set; protocol description, list of DNN and S-NSSAI for XRM service subscriptions, access type, RAT type, or PDU session request type) determine whether PDU set processing is enabled for UE 102's PDU session. If SMF 366 determines that PDU set processing is enabled, SMF 366 requests the PDU set QoS parameters for one or more QoS flows used in the PDU session.

[0082] In scenario 600C, RAN 105 provides an indication of whether or not it supports PDU set processing to SMF 366 via AMF 364. During the PDU session establishment request process, and after RAN 105 sends an N2 PDU session response to AMF 364 including an indication of whether RAN 105 supports PDU set processing, AMF 364 further sends an Nsmf_PDU Session_CreateSMContext request to SMF 366 including an indication of whether RAN 105 supports PDU set processing. During the PDU session modification request process, and after RAN 105 sends an N2 PDU session response message to AMF 364 including an indication of whether RAN 105 supports PDU set processing, AMF 364 further sends an Nsmf_PDU Session_UpdateSMContext request message to SMF 366 including an indication of whether RAN 105 supports PDU set processing. SMF 366 can further determine whether to modify the N4 session to activate or deactivate PDU set processing after receiving an indication of whether RAN 105 supports PDU set processing and after receiving accepted and / or rejected QoS flows.

[0083] For details, please refer to the following: Figure 6C For events 610 and 612, please refer to... Figure 6B Proceed as discussed; Event 614 as referenced Figure 6A Proceed as discussed; events 616, 618, and 620 are as referenced. Figure 6B Proceed as discussed; and events 644A, 645, 647, 650, and 652 are as referenced. Figure 6A Proceed as discussed.

[0084] RAN 105 indicates whether it accepts or rejects QoS parameters based on the PDU set for a QoS flow used in a PDU session. Specifically, RAN 105 may send a 655 N2 PDU session response message to AMF 364, which includes the PDU session ID, reason, a list of accepted and / or rejected QFIs, and an indication of whether RAN 105 supports PDU set handling. Similar to the example above, the QFI identifies a specific QoS flow.

[0085] When RAN 105 activates PDU set processing for an accepted QFI, RAN 105 includes an indication of support for PDU set processing in its response message, which RAN 105 sends to SMF 366 via AMF 364. Additionally, RAN 105 may include an appropriate reason value (if any) for the rejected QFI, such as a lack of support for PDU set processing due to S-NSSAI, DNN, lack of radio resources, etc.

[0086] AMF 364 sends a 657 Nsmf_PDUSession_Update_SMContext request message to SMF 366. The PDUSession_Update_SMContext request message may include the PDU session ID, the reason, a list of accepted and / or rejected QFIs, and an indication of whether RAN 105 supports PDU set handling.

[0087] Then, SMF 366 modifies session 681 N4 for accepted and / or rejected QoS flows of the PDU session. For example, if SMF 366 previously activated 644A PDU set processing at UPF 370, and RAN 105 does not provide an indication of support for PDU set processing (or provides an indication of non-support for PDU set processing), SMF 366 can instruct UPF 370 to deactivate the PDU set identifier and tag for accepted QoS flows. In this case, RAN 105 does not activate PDU set processing at RAN 105, and accepted QoS flows can ignore QoS parameters based on the PDU set. As another example, if SMF 366 previously activated 644A PDU set processing at UPF 370, and RAN 105 provides an indication of support for PDU set processing (or does not provide an indication of non-support for PDU set processing), then SMF 366 can instruct UPF 370 to modify the N4 session to release resources only for the rejected QFI. Events 690 and 692 can be referenced as follows. Figure 6A or Figure 6B Proceed as discussed.

[0088] Now for reference Figure 7 Node CN (such as PSA UPF 370) can implement method 700 to determine whether to activate PDU set processing.

[0089] At box 701, the CN node receives a registration message from the UE for registering 3GPP access or (untrusted or authorized) non-3GPP access (see, for example, event 501). At box 781, the CN node determines whether the access type is 3GPP access or non-3GPP access. If so, the process proceeds to box 783, where the CN node activates PDU set processing, as referenced above. Figures 6A to 6C The discussion continues. Otherwise, if the access type is non-3GPP access, the process proceeds to frame 874, where the CN node does not activate PDU set processing.

[0090] In addition, it is usually referenced Figures 8A to 9C When a UE changes its registration from one access type to another, the network needs to move the PDU session from the first access (platform) to the second access (platform). Since only RAN 105 can support PDU set-based processing, SMF 166 must be able to correctly instruct UPF 370 whether to activate or deactivate the PDU set identifier and tag. Specifically, RAN 105 and one or more CN nodes can support at least the following four scenarios: (1) switching a PDU session from a non-3GPP access to a 3GPP access; (2) switching a PDU session from a 3GPP access to a non-3GPP access; (3) switching a PDU session from a non-3GPP access to a 3GPP access with a RAT type that supports (or does not support) PDU set processing; and (4) switching a PDU session from a 3GPP access with a RAT type that supports (or does not support) PDU set processing to a non-3GPP access.

[0091] First refer to Figure 8A Example scenario 800A involves switching a PDU session from an untrusted non-3GPP access point to a 3GPP access point. UE 102 first registers via non-3GPP access (801) and establishes a PDU session with a DNN and S-NSSAI. The PDU session also has a PDU session ID, which UE 102 and the CN node can use to identify the PDU session. During the 801 PDU session establishment process, SMF 166 does not request activation of PDU set processing for the PDU session (because the access type is non-3GPP access).

[0092] Then, UE 102 performs the 802 registration procedure via 3GPP access. Next, UE 102 performs the 810 PDU session establishment procedure for PDU sessions moving from non-3GPP access to 3GPP access. SMF 166 operates as discussed in reference events 644A and 644B above. As mentioned above, SMF 166 can determine whether to activate the PDU set identifier and tag based on a set of conditions. Figure 8A In the following cases, the applicable conditions may be: (i) the PCC policy includes QoS parameters and protocol descriptions based on the PDU set for QoS flows; (ii) the requested DNN and S-NSSAI may be included in the list of DNNs and S-NSSAIs for subscriptions to XRM services; (iii) the received access type is 3GPP access; and (iv) the received RAT type is applicable based on the operator policy configured according to the SMF or the PCC policy for UE 102. The SMF 166 may then send all QFIs and QoS profiles for the PDU session applicable to the target 3GPP access to the AMF 164 (see Event 647). The Namf_Communication_N1N2MessageTransfer message sent via the AMF 164 to the N3IWF 167 may include a request to release resources through resource non-3GPP access. SMF 166 and RAN 105 can maintain existing PDU sessions and the SM context between AMF 164 and SMF 166 by not sending a PDU session release command to UE 102. CN node, RAN 105 and UE 102 can repeat procedures 810 and 800 for all PDU sessions that need to be moved from non-3GPP access to 3GPP access.

[0093] Figure 8B This is a message passing diagram for example scenario 800B, which includes switching a PDU session from 3GPP access to non-3GPP access. UE 102 first registers via 3GPP access 802.

[0094] Then, UE 102 uses reference Figures 6A to 6C The discussed technique establishes an 811 PDU with a certain DNN and S-NSSAI. During the PDU session establishment process, the SMF 166 can operate as discussed in reference events 644A and 644B above. As mentioned above, the SMF 166 can determine whether to activate the PDU set identifier and tag based on a set of conditions. Figure 8BIn the case of (i) the PCC policy includes QoS parameters and protocol descriptions based on the PDU set for QoS flows, (ii) the requested DNN and S-NSSAI are in the list of DNN and S-NSSAI for subscriptions for XRM services, (iii) the access type is 3GPP access, and (iv) the RAT type is applicable based on the operator policy configured according to SMF or the PCC policy for UE 102.

[0095] Then, UE 102 performs the 801 registration procedure for non-3GPP access. Next, UE 102 performs the 817 PDU session establishment procedure for PDU sessions moving to non-3GPP access. Specifically, SMF 166 needs to disable PDU set handling and deactivate the PDU set identifier and tag at UPF 170 (see events 644A and 644B). SMF 166 can send all QFIs and QoS profiles for QoS flows applicable to the PDU session of the target non-3GPP access to AMF 164 (see event 647). To disable PDU set handling, SMF 166 can do the following: (i) according to one implementation, request QoS-based parameters from N3IWF 167, excluding PDU set QoS parameters, and (ii) according to another implementation, include an indication for N3IWF 167 that N3IWF 167 knows to ignore PDU set-based QoS parameters and not reject QoS flows moving to other access types.

[0096] To release non-3GPP resources (880), SMF 166 can send a Namf_Communication_N1N2MessageTransfer (containing an N2 resource release request) to RAN 105 via AMF 164 to release the resources at RAN 105. This message can include a request to release resources via the source 3GPP access. SMF 166 and RAN 105 can maintain existing PDU sessions by not sending a PDU session release command to UE 102. Specifically, SMF 166 can omit the N1 SM container from the Namf_Communication_N1N2MessageTransfer message. Furthermore, SMF 166 and RAN 105 can maintain the SM context between AMF 164 and SMF 166. The CN node, RAN 105, and UE 102 can repeat procedures 817 and 880 for all PDU sessions requiring movement across access types.

[0097] Next reference Figures 9A to 9CIn some cases, UE 102 can register to a 3GPP access or a (untrusted or trusted) non-3GPP access. If the UE has ATSSS capability, UE 2102 can establish a multiple access (MA) PDU session, which allows UE 1092 to select, hand over, or redirect traffic between 3GPP and non-3GPP access.

[0098] Because only NG-RAN can support PDU set-based processing, the network needs to deactivate PDU set processing at UPF 170 as long as UE 102 has an MA PDU session and is registered as a non-3GPP access. SMF 166 may instruct UPF 170 to activate or deactivate PDU set identifiers and tags at UPF 170 in the following situations: (1) when UE 102, which is capable of ATSSS, requests permission for UE 102 to select, switch, or redirect traffic to an MA PDU session between two registered accesses; (2) when the network determines to change the PDU session type to MA PDU session type so that UE 102 can register a non-3GPP access, 3GPP access, or both for the MA PDU session, and the 3GPP access can have a RAT type that supports (or does not support) PDU set processing; and (3) when the network determines to deregister a non-3GPP access from an MA PDU session.

[0099] Scene 900A-C shows the processing of SMF 166 activating or deactivating the PDU set at UPF 170.

[0100] Figure 9A This is a message passing diagram for example scenario 900A, where a UE registers with 3GPP access, non-3GPP access, or both, and establishes an MA PDU session. Here, the UE registers with 3GPP access, non-3GPP access, or both, and establishes a 910 MA PDU session using the PDU session establishment procedure.

[0101] UE 102 sets the request type indicator 905A as "MA PDU Request" in the UL NAS transport message for a PDU session establishment request to establish an MA PDU session. SMF 914A determines that PDU set processing is not enabled for an MA PDU session because the request type is MA PDU session. Then, SMF 166 performs 993 actions 616, 618, 620, ... 652.

[0102] Figure 9BThis is a message passing diagram for example scenario 900B where UE 102 registers for 3GPP-only access and establishes a PDU session. AMF 164 can determine that the PDU session will be changed to an MA PDU session, which will cause SMF 166 to disable PDU set processing for the MA PDU session. Here, SMF 166 subscribes to the 923 event open service from the AMF to notify the UE of the change in PDU session request type for a specific PDU session ID. In some implementations, a dedicated event ID is defined for the AMF notification service.

[0103] like Figure 9B As shown, UE 102 registers 903B to 3GPP access. UE 905 requests to establish a PDU session, as referenced above. Figures 6A to 6C As discussed, SMF 166 also subscribes to the 923 event open service from the AMF to notify UE 102 of the PDU session request type change. Then, AMF 164 notifies SMF 166 of the 994 PDU session request type change, indicating the PDU session request type change for the associated PDU session ID. The SMF can determine 995 for deactivating the PDU set handling for the MA PDU session, similar to... Figure 9A The scene.

[0104] Figure 9C This is a message passing diagram for example scenario 900C where the UE registers both 3GPP access and non-3GPP access and establishes a PDU session. AMF 164 can determine whether to remove or deregister non-3GPP access from the MA PDU session, which allows SMF 166 to determine whether to enable PDU set processing for MA PDU sessions that have only registered 3GPP access.

[0105] Specifically, the UE registers 903C with both 3GPP and non-3GPP access providers. Then, UE 102 requests 910C to establish a MAPDU session. SMF 166 does not enable PDU set processing for PDU sessions, similar to... Figure 9A In scenario 900A, the following additional steps are involved: SMF 166 subscribes to the 923 event open service from AMF to notify the UE of the access type change.

[0106] AMF 164 then cancels 927 non-3GPP access from the MA PDU session. If SMF 166 is currently subscribing to the service notified by AMF, AMF 164 notifies SMF 166 of the access type change corresponding to the PDU session ID in case 994C. SMF 166 may determine 996's PDU set activation for the MA PDU session discussed in reference events 644A and 644B above based on the following conditions or factors: (i) the PCC policy includes QoS parameters and protocol descriptions based on the PDU set for QoS flows, (ii) the requested DNN and S-NSSAI are in the list of DNNs and S-NSSAIs for the XRM service subscription, (iii) the access type is 3GPP-only access, and (iv) the RAT type is applicable based on the operator policy configured according to SMF 166 or the PCC policy for UE 102.

[0107] As another example, UE 192 can register to 3GPP-only access and establish a PDU session. If AMF 164 determines to change the PDU session to an MA PDU session, then Figure 9C The method may be applicable, which may result in SMF 166 maintaining an active PDU set for the MA PDU session until UE 102 registers non-3GPP access.

[0108] Figure 10 This is a flowchart of an example method for determining whether to activate PDU set processing based on access type. Figure 1 The CN node can implement this method. At box 1010, the CN node receives a request from the UE to establish or update a PDU session. At box 1021, the CN node determines the access type for the UE (e.g., 3GPP access, non-3GPP access). At box 1080, the CN node enables or disables PDU set processing for the PDU session and based on the access type (see events 644A, 644B, 680).

[0109] The following list of examples illustrates various embodiments explicitly contemplated in this disclosure.

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

[0111] Example 2. The method as described in Example 1, wherein the request to establish or update the PDU session is received via the RAN.

[0112] Example 3. The method as described in Example 1 or 2, wherein enabling or disabling includes disabling the PDU set handling when the access type is a non-3GPP access.

[0113] Example 4. The method described in Example 3, wherein the PDU session was previously established when the UE accessed the CN using 3GPP access.

[0114] Example 5. The method described in Example 4, wherein disabling the PDU set processing includes sending a request from the SMF to the UPF to disable the PDU set processing for the PDU session.

[0115] Example 6. The method as described in Example 5, wherein the request to disable the processing of the PDU set for the PDU session includes instructions to deactivate the PDU set identifier and tag for the accepted QoS flow.

[0116] Example 7. The method as described in Example 5 or 6, wherein disabling the PDU set handling includes the SMF requesting QoS parameters of the QoS flows included in the PDU session from the N3IWF, including avoiding requesting the PDU set QoS parameters.

[0117] Example 8. The method as described in Example 5 or 6, wherein disabling the PDU set comprises sending an indication from the SMF to the N3IWF to (i) ignore the PDU set QoS parameters and (ii) not reject QoS flows in the PDU session.

[0118] Example 9. The method as described in Example 1 or 2, wherein enabling or disabling includes enabling the PDU set processing when the access type is 3GPP access.

[0119] Example 10. The method as described in Example 9, wherein the PDU session was previously established when the UE accessed the CN using non-3GPP access.

[0120] Example 11. The method of Example 9 further includes 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 is in response to deregistering the non-3GPP access from the MA PDU session.

[0121] Example 12. The method of Example 11 further includes opening the service at the SMF to the Access and Mobility Management Function (AMF) subscription event; wherein the enabling of the PDU set disposal is in response to receiving an indication from the AMF that the MA PDU session has been changed to a single-address access PDU session.

[0122] Example 13. The method as described in Example 1 or 2, wherein enabling or disabling includes disabling the PDU set processing when the PDU session is an MA PDU session associated with both 3GPP access and non-3GPP access.

[0123] Example 14. The method as described in Example 13 further includes establishing a PDU session having an access type corresponding to 3GPP-only access; and wherein the enabling of the PDU set is in response to registering a non-3GPP access for the PDU session.

[0124] Example 15. The method of Example 14 further includes opening the service to the AMF subscription event at the SMF; wherein the disabling of the PDU set disposal is in response to receiving an instruction from the AMF to change the PDU session to the MA PDU session.

[0125] Example 16. The method as described in Example 13, wherein the disabling of the PDU set is in response to receiving a request from the AMF at the SMF to create a context for the PDU session, the request including a request type indicating the MA PDU session.

[0126] Example 17. The method as described in any one of Examples 1 to 4 or 9 to 16, wherein determining the access type of the UE comprises: receiving a request from the AMF at the SMF to create a context for the PDU session, the request indicating the access type.

[0127] Example 18. The method as described in Example 15, wherein the request includes an indication of a Radio Access Technology (RAT) type for the Radio Access Network (RAN); and the enabling or disabling is further based on the indication of that RAT type.

[0128] Example 19. The method as described in any one of Examples 1 to 17, wherein the enabling or disabling is further based on whether the RAN supports PDU set processing.

[0129] Example 20. A node in a CN, including processing hardware and configured to implement the method as described in any of the preceding examples.

[0130] Additional considerations

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

[0132] User devices that implement the technologies disclosed herein (e.g., UE 102) can be any suitable device capable of wireless communication, such as smartphones, tablets, laptops, mobile game consoles, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media streaming dongles or other personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, or broadband routers. Furthermore, in some cases, the user device can be embedded in electronic systems such as a vehicle's main unit or an advanced driver assistance system (ADAS). Even further, the user device can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

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

[0134] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof are intended to cover non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, unless expressly stated otherwise, “or” means inclusive or not exclusive. For example, condition A or B is satisfied by either: A is true (or exists) and B is false (or does not exist); A is false (or does not exist) and B is true (or exists); and both A and B are true (or exist).

[0135] When implemented in software, the technology can be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software can be executed by one or more general-purpose processors or one or more dedicated processors.

Claims

1. A method implemented in a node of a core network (CN), the method comprising: Receive a request from the user equipment (UE) to establish or update a Protocol Data Unit (PDU) session; Determine the access type of the UE; as well as Enable or disable PDU set processing for the PDU session and based on the access type.

2. The method of claim 1, wherein enabling or disabling includes: When the access type is a non-3GPP (3rd Generation Partnership Project) access, the processing of the PDU set is disabled.

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

4. The method of claim 3, wherein disabling the PDU set comprises: The Session Management Function (SMF) sends a request to the User Plane Function (UPF) to disable the processing of the PDU set for the PDU session.

5. The method of claim 4, wherein the request to disable the PDU set processing for the PDU session includes an instruction to deactivate the PDU set identifier and tag for the accepted Quality of Service (QoS) flow.

6. The method of claim 1, wherein enabling or disabling includes: When the access type is 3GPP (3rd Generation Partnership Project) access, the PDU set processing is enabled.

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

8. The method of claim 1, wherein enabling or disabling includes: The PDU set processing is disabled 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: Establish the PDU session with the access type corresponding to 3GPP-only access; and The activation of the PDU set processing is in response to: Register a non-3GPP access for the PDU session.

10. The method of claim 9, further comprising: Open the service to AMF subscription events at the SMF; The aforementioned disabling of the PDU set is in response to receiving an indication from the AMF that the PDU session has been changed to the MAPDU session.

11. The method of claim 8, wherein the disabling of the PDU set is in response to: At the SMF, a request to create a context for the PDU session is received from the AMF, the request including a request type indicating the MAPDU session.

12. The method according to any one of claims 1 to 3, 6, 7 or 8, wherein: Determining the access type of the UE includes receiving a request from the AMF at the SMF 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 the type of Radio Access Technology (RAT) used for the Radio Access Network (RAN); and The enable or disable is further based on the indication of the RAT type.

14. The method according to any one of claims 1 to 12, wherein: The enabling or disabling is further based on whether the RAN supports PDU set processing.

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

Images