Application identification in access service steering, switching and splitting (ATSSS) rules

Abstract

Embodiments include a method for a policy control function (PCF) of a communication network. This method includes: during establishment of a packet data unit (PDU) session of a user equipment UE, determining one or more UE application descriptors corresponding to a network application identifier (AppId) of a service data flow (SDF) template for the PDU session. Each UE application descriptor includes a first identifier (OSId) of an operating system (OS) supported by the UE and a second identifier (OSAppId) for an application of the OS supported by the UE identified by the first identifier. This method includes sending policy rules for the PDU session to a session management function (SMF) of the communication network. The policy rules include UE application descriptors. Other embodiments include supplementary methods for the SMF and a PCF and SMF configured to perform this method.

Description

Technical Field

[0001] The present application relates generally to the field of communication networks, and more particularly to techniques for determining and / or preconfiguring policies and / or rules for applications in a communication network. Background Art

[0002] Currently, fifth generation ("5G") cellular systems, also known as New Radio (NR), are being standardized within the 3rd Generation Partnership Project (3GPP). NR is designed for maximum flexibility to support multiple and essentially different use cases. These use cases include enhanced mobile broadband (eMBB), machine type communications (MTC), ultra-reliable low latency communications (URLLC), sidelink device-to-device (D2D), and several others. The present disclosure generally relates to 5G, but similar principles can be applied to earlier generations of Long Term Evolution (LTE) networks.

[0003] LTE is a generic term for the so-called fourth generation (4G) radio access technologies developed within the 3rd Generation Partnership Project (3GPP) and initially standardized in Release 8 (Rel-8) and Release 9 (Rel-9), also known as Evolved UTRAN (E-UTRAN). LTE targets various licensed frequency bands and is accompanied by improvements to non-radio aspects, which are generally referred to as System Architecture Evolution (SAE), including the Evolved Packet Core (EPC) network. LTE continues to evolve through subsequent releases.

[0004] Figure 1 An overall exemplary architecture of a network including LTE and SAE is shown in FIG. E-UTRAN 100 includes one or more evolved Node Bs (eNBs) (e.g., eNBs 105, 110, and 115) and one or more user equipments (UEs) (e.g., UE 120). As used in 3GPP standards, "user equipment" or "UE" refers to any wireless communication device (e.g., a smartphone or computing device) capable of communicating with network equipment compliant with 3GPP standards, including E-UTRAN as well as UTRAN and / or GERAN, as third generation ("3G") and second generation ("2G") 3GPP RANs are well known.

[0005] According to 3GPP regulations, E-UTRAN 100 is responsible for all radio-related functions in the network, including radio bearer control, radio admission control, radio mobility control, scheduling, and dynamic allocation of resources to UEs on uplink and downlink, as well as security of communication with UEs. These functions reside in eNBs, such as eNBs 105, 110, and 115. Each of the eNBs can serve a geographical coverage area including more than one cell, including cells 106, 111, and 116 served by eNBs 105, 110, and 115, respectively.

[0006] The eNBs in the E-UTRAN communicate with each other via the X2 interface. Figure 1 The eNB is also responsible for the E-UTRAN interface to the EPC 130, in particular to the Mobility Management Entity (MME) and the Serving Gateway (SGW) (in Figure 1 The S-GW is collectively referred to as the S1 interface of the MME / S-GW 134 and 138 in the eNB. In general, the MME / S-GW handles the overall control of the UE and the data flow between the UE and the rest of the EPC. More specifically, the MME handles the signaling (e.g., control plane) protocols between the UE and the EPC, which are called non-access stratum (NAS) protocols. The S-GW handles all Internet Protocol (IP) data packets (e.g., data or user plane) between the UE and the EPC and acts as a local mobility anchor for data bearers as the UE moves between eNBs (e.g., eNBs 105, 110, and 115).

[0007] The EPC 130 may also include a Home Subscriber Server (HSS) 131 that manages user and subscriber related information. The HSS 131 may also provide support functions in mobility management, call and session establishment, user authentication, and access authorization. The functions of the HSS 131 may be related to the functions of the traditional Home Location Register (HLR) and Authentication Center (AuC) functions or operations.

[0008] HSS 131 may communicate with MMEs 134 and 138 via respective S6a interfaces and may communicate with a User Data Repository (UDR) via a Ud interface. Figure 1 The HSS 131 may communicate with the EPC-UDR 135-labeled in the HSS 131. The EPC-UDR 135 may store the user credentials after they are encrypted by the AuC algorithm. These algorithms are not standardized (i.e., vendor-specific), so that the encrypted credentials stored in the EPC-UDR 135 cannot be accessed by any vendor other than the vendor of the HSS 131.

[0009] In addition, S-GWs 134 and 138 may communicate with a packet gateway (P-GW) 139 via respective S5 interfaces. P-GW 135 provides access to external packet data networks (PDNs) (e.g., Figure 1 140). For example, for UE 120, PDN 140 can be the point of entry (or exit) EPC 130 for traffic. However, if UE 120 has multiple data sessions to multiple PDNs, UE 120 can be connected to multiple P-GWs, but will still be served by only one SGW (e.g., 134 or 138). In some cases, P-GW 135 can also act as an Internet Protocol (IP) router, supporting mobile dedicated tunnels and signaling protocols. In some deployments, PDN 140 can include an IP Multimedia Subsystem (IMS).

[0010] P-GW 135 also communicates with a policy and charging rules function (PCRF) 138 via an S7 interface. PCRF 138 provides policy control decisions and charging control functions for users (e.g., UE 120) operating in the LTE network. PCRF 138 also provides network control of service data flow detection, gating, quality of service (QoS), and flow-based charging (in addition to credit management). PCRF 138 performs these functions (collectively referred to as "Policy and Charging Control" or PCC) in conjunction with a Policy Control Enforcement Function (PCEF), which may be part of P-GW 135. For example, PCRF 138 may communicate with PCEF via a Gx interface, such as Figure 1 More generally, these functions are part of the PCC architecture defined in 3GPP TS 23.203 (for EPC / LTE).

[0011] For example, when a packet data (e.g., IMS) session is being established, signaling (e.g., SIP signaling) containing media requirements is exchanged between UE 120 and PDN 140. At some time during the session establishment process, PCRF 138 receives these requirements from the PDN (e.g., IMS P-CSCF) and makes a decision based on network operator rules. Such a decision may include: allowing or denying the media request, using a new or existing packet data context for the media request, and checking the allocation of new resources against the maximum value authorized for UE 120. PCRF 138 communicates with PDN 140 over the RXi interface.

[0012] Users can use the online charging system (OCS) or the offline charging system (OFCS) (in Figure 1The main difference is that online charging can affect the real-time provision of services to users, while offline charging is applied after the service is provided and therefore does not affect the real-time provision. Figure 1 As shown, PCRF 138 communicates with OCS / OFCS 150 via corresponding Gy / Gz interfaces.

[0013] Figure 2 A high-level view of an exemplary 5G network architecture including a next generation radio access network (NG-RAN) 299 and a 5G core (5GC) 298 is shown. As shown, the NG-RAN 299 may include gNBs 210 (e.g., 210a, 210b) and ng-eNBs 220 (e.g., 220a, 210b) interconnected to each other via respective Xn interfaces. The gNBs and ng-eNBs are also connected to the 5GC 298 via NG interfaces, more specifically to AMFs (Access and Mobility Management Functions) 230 (e.g., AMFs 230a, 230b) via respective NG-C interfaces and to UPFs (User Plane Functions) 240 (e.g., UPFs 240a, 240b) via respective NG-U interfaces. In addition, the AMF 230a, 230b can communicate with one or more policy control functions (PCFs, such as PCFs 250a, 250b) and network exposure functions (NEFs, such as NEFs 260a, 260b). The AMF, UPF, PCF, and NEF are further described below.

[0014] Each of the gNBs 210 may support an NR radio interface, including frequency division duplex (FDD), time division duplex (TDD), or a combination thereof. In contrast, each of the ng-eNBs 220 may support an LTE radio interface, but may be different from a conventional LTE eNB (e.g., Figure 1 Each of the gNB and ng-eNB can serve a geographical coverage area including more than one cell, such as Figure 2 211a-211b and 221a-221b are exemplarily shown in FIG. Depending on the specific cell in which the UE 205 is located, the UE 205 can communicate with the gNB or ng-eNB serving the specific cell via the NR or LTE radio interface, respectively.

[0015] In 5G networks (e.g., in 5GC), conventional peer interfaces and protocols (e.g., in LTE / EPC networks) are modified by a so-called service-based architecture (SBA), in which a network function (NF) provides one or more services to one or more service consumers. For example, this can be done through a hypertext transfer protocol / representational state transfer (HTTP / REST) ​​application programming interface (API). Typically, various services are self-contained functions that can be changed and modified in an isolated manner without affecting other services. In addition, services consist of various "service operations", which are finer-grained divisions of the entire service functionality. In order to access a service, both the service name and the target service operation must be indicated. The interaction between a service consumer and a provider can be of the "request / response" or "subscription / notification" type.

[0016] 3GPP specifications define the Access Service Steering, Switching and Splitting (ATSSS) feature, which implements a Multiple Access (MA) Packet Data Unit (PDU) connection service, in which the UE can exchange PDUs with the data network by using one 3GPP access network and one non-3GPP access network simultaneously. As defined in Section 5.32.2 of 3GPP TS 23.501 (v16.4.0), the Session Management Function (SMF) in the 5GC informs the PCF in the 5GC of the ATSSS capabilities (e.g., steering mode and steering capabilities) of the UE MA PDU session.

[0017] The SMF creates ATSSS rules for the UE using the MA PDU session control information in the PCC rules. When a MA PDU session is created or updated by the SMF / PCF, the ASSSS rules are sent to the UE. This is described in more detail in 3GPP TS 23.501 (v16.4.0) and 23.502 (v16.4.0). The ATSSS rules sent by the SMF to the UE include various types of service descriptor information. However, certain aspects of the service descriptors are not directly available to the SMF, which can cause various problems, difficulties and / or difficulties. Summary of the invention

[0018] Embodiments of the present disclosure provide certain improvements in the management of policies and / or rules for using applications in a communication network, for example, by facilitating solutions for overcoming the exemplary problems summarized above and described in more detail below.

[0019] Exemplary embodiments include methods (e.g., processes) for a policy control function (PCF) for a communication network (e.g., EPC, 5GC). The PCF may be hosted and / or provided by one or more network nodes in or associated with the communication network.

[0020] These exemplary methods may include: during establishment of a PDU session for a UE, determining one or more UE application descriptors corresponding to a network application identifier (AppId) of a service data flow (SDF) template for the PDU session. Each UE application descriptor includes a first identifier (OSId) of an operating system (OS) supported by the UE and a second identifier (OSAppId) for an application of the OS supported by the UE identified by the first identifier. These exemplary methods may also include: sending a policy rule for the PDU session to a session management function (SMF) of a communication network. The policy rule includes the UE application descriptor.

[0021] In some embodiments, these exemplary methods may further include: receiving a request for a policy rule for a PDU session from an SMF. In such an embodiment, the request may include an SDF template, the SDF template including a network application identifier (AppId). The policy rule may be sent in response to the request. In some embodiments, the request also includes an indication that the requested policy rule is for a multi-access (MA) PDU session, and the policy rule includes access service steering, switching and splitting (ATSSS) information.

[0022] In some embodiments, these example methods may further include determining, during registration of the UE in the communication network, identifiers of one or more OS supported by the UE, and storing the determined identifiers in a user data repository (UDR) of the communication network.

[0023] In some of these embodiments, determining the identifier may include one of: receiving the identifier from the UE; or deriving the identifier based on a permanent equipment identifier (PEI) of the UE, the permanent equipment identifier (PEI) obtained from an access and mobility management function (AMF) of the communication network.

[0024] In some embodiments, determining a UE application descriptor may include various operations, including: mapping a network application identifier to one or more OS identifiers and corresponding one or more OS-specific application identifiers; obtaining identifiers of one or more OSs supported by the UE; selecting a mapped OS identifier that matches the obtained identifier of the OS supported by the UE as a first identifier; and selecting a mapped OS-specific application identifier corresponding to the selected first identifier as a second identifier.

[0025] In some of these embodiments, obtaining the identifier can be further represented by various sub-operations, including: obtaining identifiers of one or more OS supported by the UE from a user data repository (UDR) of the communication network; when the identifier cannot be obtained from the UDR, determining the identifier based on the permanent equipment identifier (PEI) of the UE obtained from the SMF; and when the identifier cannot be determined based on the PEI, selecting an identifier of an OS commonly supported by UEs operating in the communication network.

[0026] In some of these embodiments, these exemplary methods may also include the following additional operations: locally storing identifiers of one or more OS supported by the UE obtained from the UDR; subsequently receiving a request for updated policy rules for the PDU session from the SMF, wherein the request includes the updated network application identifier; determining one or more updated UE application descriptors based on the updated network application identifier and the locally stored identifier; and sending the updated policy rules to the SMF, wherein the updated policy rules include the updated UE application identifier.

[0027] In some embodiments, the UE application description (eg, included in the transmitted policy rules) may not include the identified versions of the OS supported by the UE and the identified versions of the applications.

[0028] Other embodiments include methods (e.g., processes) for a session management function (SMF) of a communication network (e.g., 5GC). The SMF may be hosted and / or provided by one or more network nodes in or associated with the communication network.

[0029] These exemplary methods may include: sending a second request for policy rules for a PDU session for a UE to a PCF of a communication network. The second request includes a service data flow (SDF) template, which includes a network application identifier (AppId) associated with the PDU session. These exemplary methods may include: receiving policy rules for the PDU session from the PCF. The policy rules may include one or more UE application descriptors corresponding to the network application identifier. Each UE application descriptor includes a first identifier (OSId) of an operating system (OS) supported by the UE and a second identifier (OSAppId) for an application of the OS supported by the UE identified by the first identifier. These exemplary methods may also include: sending a PDU session rule including one or more UE application descriptors to the UE. In some embodiments, the PDU session rules are used for access service steering, switching and splitting (ATSSS).

[0030] In some embodiments, the UE application description (eg, included in the received policy rules) may not include the identified versions of the OS supported by the UE and the identified versions of the applications.

[0031] In some embodiments, these exemplary methods may further include: receiving a first request to establish a PDU session for the UE. The first request includes an indication that the requested PDU session is a multiple access (MA) PDU session. In such an embodiment, the second request includes an indication that the policy rule is for an MA PDU session.

[0032] In some embodiments, these exemplary methods may also include: sending a third request for updated policy rules for the PDU session to the PCF, wherein the third request includes the updated network application identifier; and receiving the updated policy rules from the PCF, wherein the updated policy rules include one or more updated UE application identifiers corresponding to the updated network application identifier.

[0033] Other embodiments also include PCFs and SMFs configured to perform operations corresponding to any of the exemplary methods described herein (e.g., using processing circuitry). Other embodiments also include non-transitory computer-readable media storing computer-executable instructions that, when executed by processing circuitry associated with such PCFs and SMFs, configure the PCFs and SMFs to perform operations corresponding to any of the exemplary methods described herein.

[0034] These and other described embodiments facilitate a single configuration point in the network for application descriptor (e.g., OSId+OSAppId) information associated with the UE. For example, the mapping of AppId to OSAppId is centralized in the PCF. Another benefit is that the application descriptor included in the ATSSS rules delivered to the UE matches the OS requirements of the UE, so that the UE is neither under-provisioned nor over-provisioned.

[0035] These and other objects, features and advantages of the embodiments of the present disclosure will become apparent upon reading the following detailed description taken in conjunction with the accompanying drawings which are briefly described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 is a high-level block diagram of an exemplary architecture of a Long Term Evolution (LTE) Evolved-UTRAN (E-UTRAN) and Evolved Packet Core (EPC) network standardized by 3GPP.

[0037] Figure 2 An exemplary high-level view of a 5G network architecture is shown.

[0038] Figure 3An exemplary non-roaming 5G reference architecture with service-based interfaces and various network functions (NFs) in the core network is shown, as further described in 3GPP TS 23.501 (v16.1.0).

[0039] Figure 4 A flowchart of an exemplary process for policy control in 5GC according to various exemplary embodiments of the present disclosure is shown.

[0040] Figure 5 An exemplary method (e.g., process) of a policy control function (PCF) for a communication network (e.g., 5GC, EPC) according to various exemplary embodiments of the present disclosure is illustrated.

[0041] Figure 6 An exemplary method (e.g., process) of a session management function (SMF) for a communication network (e.g., 5GC, EPC) according to various exemplary embodiments of the present disclosure is illustrated.

[0042] Figure 7 An exemplary embodiment of a wireless network according to various exemplary embodiments of the present disclosure is shown.

[0043] Figure 8 An exemplary embodiment of a UE according to various exemplary embodiments of the present disclosure is shown.

[0044] Fig. 9 is a block diagram illustrating an exemplary virtualization environment that can be used to implement various embodiments described herein. DETAILED DESCRIPTION

[0045] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided merely as examples to convey the scope of the subject matter to those skilled in the art.

[0046] Generally, unless clearly given and / or different meanings are implied from the context, all terms used in this article will be interpreted according to their common meaning in the relevant technical field. Unless otherwise clearly stated, all references to "one / an / element, equipment, component, device, step, etc." should be openly interpreted as referring to at least one example in element, equipment, component, device, step, etc. Unless a step must be clearly described as after or before another step and / or implicitly a step must be after or before another step, the steps of any method and / or process disclosed herein do not have to be performed in the exact order disclosed. Where appropriate, any feature of any embodiment disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment may be applicable to any other embodiment, and vice versa. By the following description, other purposes, features and advantages of the attached embodiments will be apparent.

[0047] Furthermore, the following terms are used throughout the description given below:

[0048] • Radio node: As used herein, a "radio node" may be a "radio access node" or a "wireless device".

[0049] Radio access node: As used herein, a "radio access node" (or equivalently, a "radio network node", "radio access network node" or "RAN node") may be any node in a radio access network (RAN) of a cellular communication network that operates to wirelessly send and / or receive signals. Some examples of radio access nodes include, but are not limited to, base stations (e.g., new radio (NR) base stations (gNBs) in 3GPP fifth generation (5G) NR networks or enhanced or evolved Node Bs (eNBs) in 3GPP LTE networks), base station distributed components (e.g., CUs and DUs), high power or macro base stations, low power base stations (e.g., micro base stations, pico base stations, femto or home base stations, etc.), integrated access backhaul (IAB) nodes, transmission points, remote radio units (RRUs or RRHs), and relay nodes.

[0050] Core network node: As used herein, a "core network node" is any type of node in the core network. Some examples of core network nodes include, for example, mobility management entity (MME), serving gateway (SGW), PDN gateway (P-GW), policy and charging rules function (PCRF), access and mobility management function (AMF), session management function (SMF), user plane function (UPF), charging function (CHF), policy control function (PCF), authentication server function (AUSF), etc.

[0051] Wireless device: As used herein, a "wireless device" (or "WD" for short) is any type of device that accesses a cellular communication network (i.e., is served by it) by wirelessly communicating with a network node and / or other wireless devices. Wireless transmission may include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information through the air. Unless otherwise specified, the term "wireless device" may be used interchangeably with "user equipment" (or "UE" for short) herein. Some examples of wireless devices include, but are not limited to, smart phones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), mobile communication (MTC) devices, Internet of Things (IoT) devices, vehicle-mounted wireless terminal devices, etc.

[0052] Network node: As used herein, a "network node" is any node that is part of a radio access network (e.g., a radio access node or equivalent names discussed above) or part of a core network (e.g., a core network node discussed above) of a cellular communication network. Functionally, a network node is a device that is capable, configured, arranged and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or devices in a cellular communication network to enable and / or provide wireless access to a wireless device and / or perform other functions (e.g., management) in a cellular communication network.

[0053] Note that the description given herein focuses on 3GPP cellular communication systems and therefore often uses 3GPP LTE terminology or terminology similar to 3GPP LTE terminology. However, the concepts disclosed herein are not limited to 3GPP systems.

[0054] In this disclosure, the term "service" is generally used to refer to a set of data associated with one or more applications, which is to be transmitted via a network with certain specific transmission requirements that need to be met in order for the application to be successful. In this disclosure, the term "component" is generally used to refer to any component required to deliver a service. Examples of components are RAN (e.g., E-UTRAN, NG-RAN, or parts thereof, such as eNB, gNB, base station (BS), etc.), CN (e.g., EPC, 5GC, or parts thereof, including various types of links between RAN and CN entities), and cloud infrastructure with associated resources (e.g., computing and storage). Typically, each component can have a "manager", a term generally used to refer to an entity that can collect historical information about the utilization of resources and provide information about the current availability and expected future availability of resources associated with the component (e.g., RAN manager).

[0055] As briefly described above, access service steering, switching, and splitting (ATSSS) rules for multiple access (MA) PDU sessions sent by the SMF to the UE may include various types of service descriptor information. However, certain aspects of the service descriptors are not directly available to the SMF, which can create various issues, problems, and / or difficulties. This will be discussed in more detail following the description of the 5G network architecture below.

[0056] Figure 3 An exemplary non-roaming 5G reference architecture with service-based interfaces and various 3GPP-defined network functions (NFs) within the control plane (CP) is shown. They include:

[0057] Application Function (AF, with Naf interface), interacts with 5GC to provide information to the network operator and subscribe to specific events occurring in the operator's network. AF provides applications with services delivered in a layer different from the layer that has requested the service (i.e., the transport layer), controlling flow resources according to what has been negotiated with the network. AF transmits dynamic session information to PCF (via N5 interface), including a description of the media to be delivered by the transport layer.

[0058] · Policy Control Function (PCF, with Npcf interface), supports a unified policy framework to manage network behavior by providing PCC rules (e.g., regarding the processing of each service data flow under PCC control) to the SMF via the N7 reference point. In addition, the PCF provides the Access Network Discovery and Selection Policy (ANDSP), UE Routing Selection Policy (URSP), and Vehicle to Anything Policy (V2XP) to the UE via the AMF (N15 interface). Similar to the LTE PCRF, the PCF provides policy control decisions and flow-based charging control (including service data flow detection, gating, QoS) and flow-based charging (in addition to credit management) to the SMF. The PCF receives session and media-related information from the AF and notifies the AF of service (or user) plane events.

[0059] User Plane Function (UPF) with Nupf interface – supports processing of user plane traffic based on rules received from SMF, including packet inspection and different execution actions (e.g., event detection and reporting).

[0060] Session Management Function (SMF, with Nsmf interface), interacts with the decoupled service (or user) plane, including creating, updating, and removing protocol data unit (PDU) sessions and managing session contexts through the user plane function (UPF), such as for event reporting. For example, SMF performs data flow detection (based on filter definitions included in PCC rules), online and offline charging interactions, and policy enforcement.

[0061] Charging Function (CHF, with Nchf interface), responsible for merging online and offline charging functions. The charging function provides quota management (for online charging), re-authorization triggers, rating conditions, etc., and is informed about usage reports from the SMF. Quota management involves granting a specific number of units (e.g., bytes, seconds) for a service. The CHF also interacts with the charging system.

[0062] Access and mobility management function (AMF, with Namf interface), terminates the RAN CP interface and the IS involved in the registration management, connection management, reachability management and mobility management of the UE (similar to the MME in EPC). AMF also forwards the UE policy from the PCF to the served UE and reports the UE status to the PCF.

[0063] Network Exposure Function (NEF) with Nnef interface – serves as an entry point into the operator network by securely exposing network functions and events provided by 3GPP NFs to the AF and by providing a means for the AF to securely provide information to the 3GPP network.

[0064] Network Repository Function (NRF) with Nnrf interface – provides service registration and discovery, enabling NFs to identify appropriate services available from other NFs.

[0065] Network Slice Selection Function (NSSF) with Nnssf interface – A “network slice” is a logical partition of a 5G network that provides specific network capabilities and features, e.g., to support a specific service. A network slice instance is a set of NF instances and network resources (e.g., compute, storage, communication) that provide the capabilities and features of a network slice. NSSF enables other NFs (e.g., AMF) to identify a network slice instance that is suitable for the service desired by the UE.

[0066] Authentication Server Function (AUSF) with NAUSF interface – Based on the user’s home network (HPLMN), it performs user authentication and derives security key material.

[0067] Figure 3 The unified data management (UDM) functionality shown is similar to the HSS in the LTE / EPC network discussed above. UDM supports the generation of 3GPP authentication credentials, user identity handling, access authorization based on subscription data, and other user-related functions. To provide this functionality, UDM uses data stored in Figure 3 Subscription data (including authentication data) in the 5GC Unified Data Repository (UDR) shown. The UDR (with Nudr interface) supports the PCF to store and retrieve policy data, and the NEF to store and retrieve application data. Application data can also be put into the UDR by an external AF via the Network Exposure Function (NEF) to make it available to whichever 5G NF needs – and is authorized to request – subscriber-related information.

[0068] PCF control of the ATSSS for detected service data flows (SDFs) is achieved by including Multi-Access PDU (MA PDU) session control information in the relevant PCC rules. This allows the PCF to control the following capabilities:

[0069] Steering pattern, which is used to steer / switch / split the detected service data flows (SDFs), i.e. the rules for allocating traffic between accesses;

[0070] - Bootstrapping function for detected SDF, i.e. method for sending services matching the SDF template on an MA PDU session;

[0071] Charging information, depending on the type of access used by the detected SDF; and

[0072] • Use monitoring information, depending on the type of access used by the detected SDF.

[0073] The other information in the PCC rules applies to the SDF itself and is generally independent of the access type used for the packets. The SMF uses the MA PDU session control information in the PCC rules to create the ASSS rules for the UE. The ASSS rules are sent to the UE when a MA PDU session is created or updated by the SMF / PCF. This is described in more detail in 3GPP TS 23.501 and 23.502.

[0074] According to 3GPP TS 23.503, the services to be split / switched / directed are identified by SDF templates in PCC rules. SDF templates are identified by a list of SDF filters or application identifiers (AppId) that reference corresponding application detection filters to detect service data flows.

[0075] According to Section 5.32.8 of 3GPP TS 23.501, the ATSSS rules sent to the UE include service descriptor information, which may include at least one of the following descriptors:

[0076] One or more application descriptors (identifying the service generating the service),

[0077] IP descriptor (a 5-tuple identifying the destination of Internet Protocol traffic) or

[0078] • Non-IP descriptors (descriptors identifying the destination of Ethernet traffic).

[0079] Further specifying that the application descriptor includes the following information:

[0080] Operating System Identifier (OSId): an identifier for the operating system (OS); and

[0081] OS-specific application identifier (OSAppId): an identifier associated with a specific application and uniquely identifies the application within the UE for a specific operating system.

[0082] The UE may check the received OSId to determine if the information matches the OS installed in the UE. However, it is not specified how the SMF obtains the OSId and OSAppId to be provided as part of the service descriptor information in the ATSSS rule. Also, note that the OSAppId is different from the AppId that may be included in the SDF template for the PCC rule. The OSAppId is intended to be used by the UE, while the AppId is intended to be used by the network.

[0083] The policy information provided from the PCF to the UE may include the following policies:

[0084] Access Network Discovery and Selection Policy (ANDSP), used by the UE to select a non-3GPP access network;

[0085] UE Routing Selection Policy (URSP), used by the UE to determine how to route outgoing traffic (e.g., via an established PDU Session, offload to a non-3GPP access outside of a PDU Session, or trigger establishment of a new PDU Session); and

[0086] V2X Policy (V2XP), which includes configuration parameters for UEs to conduct V2X communications.

[0087] When the PCF determines to send any of these policies containing an application descriptor to the UE, it will check if the UE's OSId is known. To determine the UE's operating system, the PCF may use the UE's permanent equipment identifier (PEI) provided by the AMF and / or the OSId provided by the UE. These parameters may be received from the UE from the AMF in the UE policy container (e.g., OSId) in the Npcf_UEPolicyControl_Create response message. If the PEI or OSId is available to the PCF, the PCF stores them in the UDR using Nudr_DM_Create including the data set "Policy Data" and the data subset "UE Context Policy Control Data".

[0088] If the PCF determines the operating system of the UE and if the PCF should transmit a UE policy containing an application descriptor, the service descriptor of such a UE policy includes an OSAppID associated with the operating system determined by the PCF for the UE. On the other hand, if the PCF cannot determine the UE operating system and if the PCF should transmit a UE policy containing an application descriptor, the service descriptor includes multiple OSAppIDs, each OSAppID being associated with a different UE operating system supported by the network operator implementation.

[0089] The PCF selects ANDSP, URSP and V2X policies applicable to each UE based on local configuration and operator policy. The UE policy is provided from the PCF to the AMF via the N15 / Namf interface, and then from the AMF to the UE via the N1 interface, as described in Section 4.2.4.3 of 3GPP TS23.502. The AMF should not change the information provided by the PCF.

[0090] When the service descriptor refers to an application descriptor, the SMF will include the OSId and OSAppld as part of the ATSSS rules provided to the UE. However, the OSId and OSAppld are not available at the SMF. Instead, the SMF will get the AppId configured in the PCF, which is provided as part of the SDF template in the PCC rules. This AppId provided as part of the SDF template is a reference to the corresponding application detection filter used to detect the service data flow.

[0091] In order to provide the required information to the UE, the SMF deployed in the network will need to have a mapping table between AppId and OSId and OSAppld included in the PCC rule SDF template. Since the UE can handle different operating systems, the mapping relationship can be one-to-many. This is inefficient because it requires configuration information in both the PCF and the SMF, i.e., the PCF needs to configure the AppId value, and the SMF needs to configure the AppId to one or more OSAppId values. In addition, the configured mapping tables in all deployed SMFs with ATSSS capabilities are synchronized with the information about the mapping relationship between AppId and OSAppId.

[0092] Furthermore, if the UE's OSId is unclear or ambiguous, current solutions require the SMF to provide an ATSSS rule with one or more application descriptors, each with one possible OSAppId corresponding to the AppId. Based on this information, the UE must resolve the supported application identifiers for its supported OSes among all received OSAppIds. This process may be inefficient and / or demanding in terms of processing requirements on the UE and various NFs (particularly the SMF).

[0093] Therefore, embodiments of the present disclosure provide techniques that facilitate a single configuration point in a network for OSId+OSAppId information associated with a UE. In addition, embodiments facilitate a PCF selected for processing SM policy context associations to obtain accurate OSId+OSAppId of a registered UE from a common storage point, thereby avoiding over-preconfiguration of the UE with ATSSS rule information that will never be called by the UE. In other words, the application descriptor included in the ATSSS rules transmitted to the UE matches the OS requirements of the UE. In addition, embodiments remove the following requirement for an ATSSS-capable SMF: maintaining an updated configuration mapping table with a relationship between the AppId in the SDF template and the corresponding OSId / OSAppId. In other words, the mapping of AppId to OSAppId is centralized in the PCF.

[0094] Various embodiments enable the PCF to provide OSId and OSAppId information as part of the PCC rules following a high-level procedure as described below. According to the current procedure, during UE registration, the PCF checks whether the OSId is provided by the UE. If not, the PCF checks whether a Permanent Equipment Identifier (PEI) can be used as a basis for deriving the OSId. If the OSId is obtained from the UE or PEI, the PCF stores it in the UDR using a Nudr DM Create including the data set "Policy Data" and the data subset "UE Context Policy Control Data".

[0095] During PDU session establishment, and if the ATSSS feature is supported, the PCF will check whether PCC rules including ASSSS policies should be provided (e.g., as defined in 3GPP TS 29.512 Section 4.2.2.17). If so, and if the corresponding traffic descriptor refers to an application descriptor, the PCF performs various operations as part of PCC rule export in addition to the current process for PCC rule export. First, the PCF obtains a list of OSIds associated with the UE from the UDR by using a Nudr_DM_Query including the data set "Policy Data" and the data subset "UE Context Policy Control Data". Secondly, for the obtained OSId, the PCF obtains the configured OSAppId corresponding to the AppId included in the SDF template, and the PCF includes the list of OSId+OSAppId within the PCC rule being exported.

[0096] On the other hand, if the list of OSIds is not available in the UDR and the PCF cannot derive the OSIds from the PEI, the PCF may include configuration information within the PCC rules about the available OSIds / OSAppIds corresponding to the AppIds included in the SDF template. When the SMF receives PCC rules related to the ATSSS policy from the PCF, it shall derive the ATSSS rules based on the OSId+OsAppId obtained directly from the PCC rules. The SMF shall send all combinations received in the PCC rules to the UE as part of the ASSSS rules.

[0097] The following explanation also illustrates the high-level operations of various embodiments. The PCF may store the OSAppId associated with the OSId in the UDR when the UE registers. In addition, using the Npcf_SMPolicyControl_Create operation, the PCF may obtain a configuration list of OSId+AppId associated with the UE and an OSId associated with the UE. However, if the information is not available in the UDR in response to the Npcf_SMPolicyControl_Create operation, the PCF may derive the necessary OSId from the PEI provided by the SMF and obtain the OSAppId associated with the OSId. In addition, based on operator policy, the PCF may decide to send a configuration list of OSId and OSAppId for the UE instead of the information obtained from the UDR. The PCF may include the OSId and OSAppId in the PCC rules as part of the MA PDU session control information. In addition, the SMF may include the application descriptor information in the PCC rules received from the PCF in the ATSSS rules sent to the UE.

[0098] Figure 44 is a flowchart of an exemplary process for ATSS policy control in 5GC according to various exemplary embodiments of the present disclosure. The exemplary process involves various operations of UE 410, AMF 420, SMF 430, PCF(UE) 440 (including PCF(UE) and PCF(SM) parts) and UDR 450 and the interactions between them. For the sake of brevity, in the following description, these devices, nodes or functions will be referred to without their reference numerals. Although Figure 4 Numbered operations are shown, but these numbers are intended to facilitate description and neither require nor imply a particular order of operations. Figure 4 The operations shown in may be performed in an order different from that shown and may be combined and / or divided into operations different from that shown.

[0099] In operation 1, the AMF calls the Npcf_UEPolicy-Control_Create request when the UE registers, and includes the PEI and UE policy request (UEPolicyRequest) container transmitted by the UE in the request. The UE policy request container may include UEOSId.

[0100] In operation 2, the PCF (UE) interacts with the UDR via Nudr_DataRepository to obtain UE policy set information, which may include UE OSId. The PCF uses the obtained information to derive UE policy for transmission to the UE. The PCF may determine the application information included in the derived UE policy based on the following information:

[0101] The obtained UE OSId, so that only the OSId+OSAppId information related to the UE OSId is included in the application descriptor;

[0102] If UE OSId is not available, the received PEI such that only OSId+OSAppId information related to the OSId derived from the PEI is included in the application descriptor; and

[0103] If UE OSId is not available and cannot be derived from PEI, PCF configures information about well-known OSId+AppId for network deployment (eg, according to operator policy).

[0104] In the case where the PCF obtains the OSId in operation 1, the PCF may also store the obtained UE OSId in the UP policy set in the UDR.

[0105] In operation 3, the PCF responds to the request of the AMF in operation 1 using the Npcf_UEPolicyControl_Create response operation. Subsequently, an end-to-end process for transmitting the UE policy to the UE is performed, as shown in the dashed box, followed by the AMF finally transmitting the UE policy to the UE. After the UE requests to establish an MA PDU session (shown in a dashed box after the policy is transmitted), in operation 4, the SMF sends an Npcf_SMPolicyControl_Create request message to the PCF, including an indication that the PDU session is for an MA PDU session. In operation 5, the PCF uses Nudr_DataRepository_Query to obtain session management (SM) data from the UDR, and determines the PCC rules in combination with the internal policy to transmit to the UE.

[0106] In operation 6, when the exported PCC rule includes ATSSS information and the SDF template of the PCC rule includes AppId, the PCF performs the following operations to provide the application descriptor to the SMF for inclusion in the ATSSS rule. First, the PCF obtains the mapping of AppId to one or more OSId+OSAppId combinations from the internal configuration. Based on the operator policy, the PCF calls the Nudr_DataRepository_Query request to obtain the UE OSId stored at the UDR in operation 2 from the UE policy set. Next, if the UE OSId information is available from the UDR, the PCF includes an OSId+OSAppId pair that matches the obtained UE OSId in the PCC rule. Alternatively, if the UE OSId information is not available from the UDR, the PCF may derive the OSId from the PEI and include an OSId+OSAppId pair that matches the derived UE OSId in the PCC rule. However, if the UE OSId cannot be obtained or derived from the PEI, or if required by operator policy, the PCF includes in the PCC rules the list of OSId+OSAppId pairs obtained in operation 2 regarding the UE policy.

[0107] In operation 7, the PCF sends an Npcf_SMPolicyControl_Create response to the SMF, including the ATSSS information in the corresponding PCC rule. For the PCC rule including the AppId in the SDF template, the PCC rule also includes the corresponding application descriptor (OSId+OSAppId). Subsequently, the PCC ATSSS rule is transmitted to the UE for use during the MA PDU session.

[0108] For example, a PCC rule update may be required due to an MA PDU session modification (shown as a dashed box). In operation 8, the SMF sends an NPCF_SMPolicyControl_Update_Request to the PCF(SM), which has cached or stored information previously obtained from the UDR. If necessary, the PCF(SM) then derives new / modified PCC rules with ATSSS information including the application description. These can be derived in the same manner as discussed above with respect to operation 6. In operation 9, the PCF transmits the updated PCC rules to the SMF via an NPCF_SMPolicyControl_Update_Response, and the updated PCCATSSS rules are transmitted to the UE in the same manner as discussed above.

[0109] although Figure 4 An exemplary process involving 5GC is shown, but similar principles can be used for EPC ATSSS policy control process. For example, Figure 4 The signal flow shown can also be applied to EPC, where PCF is replaced by PCRF, AMF is replaced by MME, SMF is replaced by PCEF (or by PGW-C when the control plane and user plane are split), UDR is replaced by EPC-UDR, etc. Figure 1 Exemplary arrangements of these elements are shown.

[0110] Various aspects of the techniques described herein may also be embodied in the context of 3GPP specifications.The following exemplary text of 3GPP TS 23.502 (Rel-16) relates to certain aspects of the various embodiments described above.

[0111] ***BEGIN PROPOSED TEXT FOR 3GPP TS 23.502***

[0112] 6.1.3.20 Access service guidance, switching and splitting

[0113] As specified in TS 23.501 [2], the Access Service Steering, Switching and Splitting (ATSSS) feature is an optional feature that can be supported by the UE and the 5GC network. The ATSSS feature supports multi-access PDU connection services, which can exchange PDUs between the UE and the data network by using a 3GPP access network and a non-3GPP access network simultaneously.

[0114] The PCF is informed by the SMF of the ATSSS capabilities of the MA PDU Session as defined in section 5.32.2 of TS 23.501 [2]. The ATSSS capabilities are both bootstrapping mode and bootstrapping functionality.

[0115] PCF control of access traffic steering, switching and splitting of detected service data flows (SDFs) is achieved by including multiple access PDU (MA PDU) session control information in the PCC rules. This allows the PCF to control:

[0116] - The bootstrap mode used for bootstrapping / switching / splitting the detected SDF. The available bootstrap modes are defined in TS 23.501 [2].

[0117] - The bootstrapping functionality for the detected SDF, e.g. the MPTCP functionality or the ATSSS-LL functionality defined in TS 23.501 [2].

[0118] -Charging information, depending on the access type used by the detected SDF.

[0119] -Use monitoring information, depending on the type of access used by the detected SDF.

[0120] The rest of the information in the PCC rules applies natively to the SDF and is independent of the access type used by the packet.

[0121] The SMF uses the MA PDU session control information in the PCC rules to create N4 rules applicable to the UPF and ASSS rules applicable to the UE, as described in TS 23.501[2]. When an MA PDU session is created or updated by the SMF / PCF, the ASSS rules are sent to the UE via NAS, as described in TS 23.501[2] and TS 23.502[3].

[0122] When the MA PDU session control information is provided to the SMF within the PCC rules, the (H-)PCF provides a service data flow template to identify the service data flow in the UPF, and if the service data flow template includes an application identifier, it also includes OSAppId and associated OSId to identify the application service in the UE.

[0123] The (H-)PCF can use the OSid stored in the UDR as the data set "Policy Data" and the data subset "UE Context Policy Control Data" to determine the OSAppId supported by the OSid. If no OSid is available in the UDR; the (H-)PCF can use the PEI to determine the OSid supported by the UE.

[0124] If the (H-)PCF has not determined the OSIds supported by the UE, the (H-)PCF may provide multiple instances of each OSAppId, each OSAppId being associated with a supported OSId according to operator policy in the (H-)PCF.

[0125] The (H-)SMF includes the OSId and OSAppId received from the PCF as part of the MA PDU session information in the PCC rule in the service descriptor in the ATSSS rule. If the OSId and OSAppId are not provided in the MAPDU session control information in the PCC rule, the (H-)SMF includes the SDF template as a service descriptor in the ATSSS rule.

[0126] The PCF may also provide the UE with URSP rules to instruct the UE to establish an MA PDU session as described in clause 6.6.2.

[0127] PCF control of PDU session level usage monitoring depending on the access type used to bear the service is achieved by providing usage monitoring control related information for each access in the policy control information associated with the PDU session (as described in clause 6.4).

[0128] If an MA PDU session is capable of MPTCP and ATSSS-LL with any bootstrap mode in the downlink and MPTCP and ATSSS-LL with active standby mode in the uplink, the PCF shall provide a PCC rule for non-MPTCP traffic. The PCC rule contains a "match all" SDF template, lowest priority, bootstrap function set to "ATSSS-LL" and bootstrap mode set to "active standby" for the uplink direction, and a bootstrap function set to "ATSSS-LL" and bootstrap mode set to any supported bootstrap mode for the downlink direction.

[0129] If the MA PDU session is capable of MPTCP and ATSSS-LL with "active standby" in both uplink and downlink, the PCF shall provide a PCC rule for non-MPTCP traffic. The PCC rule contains a "match all" SDF template, lowest priority, a steering function set to "ATSSS-LL" for both uplink and downlink directions, and a steering mode set to "active standby".

[0130] The SMF uses these PCC rules to generate ATSSS rules for the UE and N4 rules for the UPF to route non-MPTCP traffic for the MA PDU session in uplink and downlink directions respectively.

[0131] NOTE: PCF can also use the ATSSS capability of MA PDU Session to provide PCC rules containing SDF templates for some specific non-MPTCP services instead of PCC rules containing "match all" SDF templates. This allows operators to apply different policies, such as charging keys for non-MPTCP services other than non-MPCTP services that match the "match all" PCC rules.

[0132] ***END OF PROPOSED TEXT FOR 3GPP TS 23.502***

[0133] In conjunction with the above description, the following exemplary entries together with the subsequent exemplary descriptions may be added to Table 6.3.1 in Section 6.3.1 of 3GPP TS 23.502.

[0134] ***BEGIN PROPOSED TEXT FOR 3GPP TS 23.502***

[0135]

[0136] …

[0137] Note x: OSId does not include the OS version number. OSAppId does not include the application version number.

[0138] …

[0139] The application descriptor provides one or several instances of OSId and OSAppId combination. The UE uses it to identify the application service to apply the bootstrapping function and bootstrapping mode.

[0140] ***END OF PROPOSED TEXT FOR 3GPP TS 23.502***

[0141] The above-mentioned embodiment can be described as follows Figure 5 to Figure 6 For example, the features of the various embodiments discussed above are included in Figure 5 to Figure 6 Although these exemplary methods are shown in a particular order through specific blocks, the operations corresponding to the blocks may be performed in an order different from the order shown, and may be combined and / or divided into blocks and / or operations having different functions than shown. Figure 5 to Figure 6 The exemplary methods shown in the examples can be used in conjunction with (e.g., with each other and / or with other exemplary methods (e.g., Figure 4 Optional boxes and / or operations are indicated by dashed lines.

[0142] Specifically, Figure 5An exemplary method (e.g., process) of a policy control function (PCF) for a communication network (e.g., 5GC) according to various exemplary embodiments of the present disclosure is shown. The PCF may be hosted and / or provided by one or more network nodes (e.g., as described elsewhere herein) in or associated with the communication network.

[0143] The exemplary method may include the operation of block 540, wherein the PCF may determine one or more UE application descriptors corresponding to a network application identifier (AppId) of a service data flow (SDF) template for the PDU session during establishment of the UE's PDU session. Each UE application descriptor includes a first identifier (OSId) of an operating system (OS) supported by the UE and a second identifier (OSAppId) for an application of the OS supported by the UE identified by the first identifier. The exemplary method may also include the operation of block 550, wherein the PCF may send a policy rule for the PDU session to a session management function (SMF) of the communication network. The policy rule includes the UE application descriptor.

[0144] In some embodiments, the exemplary method may also include the operation of block 530, where the PCF may receive a request for a policy rule for a PDU session from the SMF. In such an embodiment, the request may include an SDF template that includes a network application identifier (AppId). The policy rule may be sent (e.g., in block 540) in response to the request. In some embodiments, the request also includes an indication that the requested policy rule is for a multi-access (MA) PDU session, and the policy rule (e.g., sent in block 550) includes access service steering, switching, and splitting (ATSSS) information.

[0145] In some embodiments, the exemplary method may further include operations of blocks 510 to 520. In block 510, the PCF may determine identifiers of one or more OSs supported by the UE during registration of the UE in the communication network. In block 520, the PCF may store the determined identifiers in a user data repository (UDR) of the communication network.

[0146] In some of these embodiments, determining the identifier in block 510 may include operations of sub-block 511 or sub-block 512. In sub-block 511, the PCF may receive the identifier from the UE. In sub-block 512, the PCF may derive the identifier based on a permanent equipment identifier (PEI) of the UE, the PEI obtained from an access and mobility management function (AMF) of the communication network.

[0147] In some embodiments, determining the UE application descriptor in box 540 may include operations of subboxes 541 to 545. In subbox 541, the PCF may map the network application identifier to one or more OS identifiers and corresponding one or more OS-specific application identifiers. In subbox 542, the PCF may obtain identifiers of one or more OSs supported by the UE. In subbox 543, the PCF may select the mapped OS identifier that matches the obtained identifier of the OS supported by the UE as the first identifier. In subbox 544, the PCF may select the mapped OS-specific application identifier corresponding to the selected first identifier as the second identifier.

[0148] In some of these embodiments, the obtaining operation of sub-box 542 may be further represented by sub-operations 542a to 542c. In 542a, the PCF may obtain identifiers of one or more OS supported by the UE from a user data repository (UDR) of the communication network. In 542b, when the identifier cannot be obtained from the UDR, the PCF may determine the identifier based on the permanent equipment identifier (PEI) of the UE obtained from the SMF. In 542c, when the identifier cannot be determined based on the PEI, the PCF may select an identifier of an OS commonly supported by the UE operating in the communication network.

[0149] In some of these embodiments, the exemplary method may also include operations of boxes 560 to 590. In box 560, the PCF may locally store identifiers of one or more OS supported by the UE obtained from the UDR (e.g., in 542a). In box 570, the PCF may then receive a request for updated policy rules for the PDU session from the SMF, wherein the request includes the updated network application identifier. In box 580, the PCF may determine one or more updated UE application descriptors based on the updated network application identifier and the locally stored identifier. In box 590, the PCF may send the updated policy rules to the SMF, the updated policy rules including the updated UE application identifier.

[0150] In some embodiments, the UE application description (eg, included in the policy rules sent in block 550) may not include (eg, not contain) the identified versions of the OS supported by the UE and the identified versions of the applications.

[0151] also, Figure 6 An exemplary method (e.g., process) of a session management function (SMF) for a communication network (e.g., 5GC) according to various exemplary embodiments of the present disclosure is shown. The SMF may be hosted and / or provided by one or more network nodes (e.g., as described elsewhere herein) in or associated with the communication network.

[0152] An exemplary method may include operations of blocks 620 to 640. In block 620, the SMF may send a second request for policy rules for a PDU session for a UE to a PCF of a communication network. The second request includes a service data flow (SDF) template, which includes a network application identifier (AppId) associated with the PDU session. In block 630, the PCF may receive policy rules for the PDU session from the PCF. The policy rules may include one or more UE application descriptors corresponding to the network application identifier. Each UE application descriptor includes a first identifier (OSId) of an operating system (OS) supported by the UE and a second identifier (OSAppId) for an application of the OS supported by the UE identified by the first identifier. In block 640, the SMF may send a PDU session rule including one or more UE application descriptors to the UE. In some embodiments, the PDU session rule is used for access service steering, switching, and splitting (ATSSS).

[0153] In some embodiments, the UE application description (eg, included in the policy rules received in block 630) may not include (eg, contain) the identified versions of the OS supported by the UE and the identified versions of the applications.

[0154] In some embodiments, the exemplary method may also include the operation of block 610, where the SMF may receive a first request to establish a PDU session for the UE. The first request includes an indication that the requested PDU session is a multiple access (MA) PDU session. In such an embodiment, the second request (e.g., sent in block 620) includes an indication that the policy rule is for an MA PDU session.

[0155] In some embodiments, the exemplary method may further include operations of blocks 650 to 660. In block 650, the SMF may send a third request for updated policy rules for the PDU session to the PCF, wherein the third request includes the updated network application identifier. In block 660, the SMF may receive the updated policy rules from the PCF, the updated policy rules including one or more updated UE application identifiers corresponding to the updated network application identifiers.

[0156] Although the subject matter described herein may be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein are directed to wireless networks (e.g. Figure 7 For simplicity, Figure 7The wireless network of FIG. 7 depicts only network 706, network nodes 760 and 760b, and wireless devices (WD) 710, 710, 710b, and 710c. In practice, the wireless network may also include any additional elements suitable for supporting communication between wireless devices or between a wireless device and another communication device (e.g., a landline phone, a service provider, or any other network node or terminal device). In the illustrated components, network node 760 and WD 710 are depicted in additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate wireless devices to access and / or use services provided by or via the wireless network.

[0157] A wireless network may include and / or interface with any type of communication, telecommunication, data, cellular and / or radio network or other similar type of system. In some embodiments, a wireless network may be configured to operate according to a particular standard or other type of predefined rules or procedures. Thus, a particular embodiment of a wireless communication network may implement communication standards such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards such as IEEE 802.11 standards; and / or any other suitable wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, and / or ZigBee standards.

[0158] The network 706 may include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

[0159] The network node 760 and the WD 710 include various components described in more detail below. These components work together to provide network node and / or wireless device functions, such as providing wireless connections in a wireless network. In different embodiments, the wireless network may include any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals (whether via a wired connection or via a wireless connection).

[0160] Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, NodeBs, evolved NodeBs (eNBs), and NR NodeBs (gNBs)). Base stations can be classified based on the amount of coverage they provide (or in other words, based on their transmit power levels), so they can also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station can be a relay node or a relay host node that controls a relay. A network node can also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU) (sometimes referred to as a remote radio head (RRH)). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio. Portions of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0161] Other examples of network nodes include multi-standard radio (MSR) equipment (e.g., MSR BS), network controllers (e.g., radio network controllers (RNC) or base station controllers (BSC)), base transceiver stations (BTS), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCE), core network nodes (e.g., MSC, MME, S-GW, M-GW, etc.), core network functions (e.g., PCEF, PCRF, AMF, UPF, NEF, SMF, PCF, etc.), application functions (AF) associated with the core network, O&M nodes, OSS nodes, SON nodes, positioning nodes (e.g., E-SMLC), and / or MDT. As another example, a network node may be a virtual network node, as described in more detail below. However, more generally, a network node may represent any suitable device (or device group) or function as follows: the device (or device group) or function is capable of, configured, arranged and / or operable to implement and / or provide access to a wireless network to a wireless device, or to provide a certain service to a wireless device that has accessed a wireless network.

[0162] exist Figure 7 In FIG. 7 , the network node 760 includes a processing circuit 770, a device readable medium 780, an interface 790, an auxiliary device 784, a power supply 786, a power supply circuit 787, and an antenna 762. Figure 7The network node 760 shown in the example wireless network of can represent a device including a combination of the hardware components shown, but other embodiments can include network nodes with different combinations of components. It should be understood that the network node includes any suitable combination of hardware and / or software required to perform the tasks, features, functions and methods and / or processes disclosed herein. In addition, although the components of the network node 760 are depicted as a single box located within a larger box or nested within multiple boxes, in reality, the network node may include multiple different physical components that constitute a single illustrated component (for example, the device readable medium 780 may include multiple separate hard drives and multiple RAM modules).

[0163] Similarly, the network node 760 may be composed of multiple physically separated components (e.g., NodeB components and RNC components, or BTS components and BSC components, etc.), each of which may have its own corresponding components. In certain scenarios where the network node 760 includes multiple separated components (e.g., BTS and BSC components), one or more of these separated components may be shared between several network nodes. For example, a single RNC may control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may be considered as a single separate network node in some instances. In some embodiments, the network node 760 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be replicated (e.g., separate device-readable media 780 for different RATs), and some components may be reused (e.g., the same antenna 762 may be shared by RATs). The network node 760 may also include multiple groups of various components shown for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies) integrated into the network node 760. These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 760 .

[0164] The processing circuit 770 may be configured to perform any determination, calculation, or similar operation (e.g., certain obtaining operations) described herein as being provided by the network node. Such operations performed by the processing circuit 770 may include processing information obtained by the processing circuit 770 by, for example, converting the obtained information to other information, comparing the obtained information or the converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or the converted information and making a determination based on the results of the processing.

[0165] The processing circuit 770 may include a combination of one or more of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or encoded logic that is operable, alone or in combination with other network node 760 components (e.g., device readable medium 780), to provide various functions of the network node 760. Such functions may include any of the various wireless features, functions, or benefits discussed herein.

[0166] For example, the processing circuit 770 may execute instructions stored in the device-readable medium 780 or in a memory within the processing circuit 770. In some embodiments, the processing circuit 770 may include a system on a chip (SOC). As a more specific example, the instructions (also referred to as a computer program product) stored in the medium 780 may include instructions that, when executed by the processing circuit 770, may configure the network node 760 to perform operations corresponding to the various exemplary methods (e.g., processes) described herein.

[0167] In some embodiments, processing circuitry 770 may include one or more of radio frequency (RF) transceiver circuitry 772 and baseband processing circuitry 774. In some embodiments, radio frequency (RF) transceiver circuitry 772 and baseband processing circuitry 774 may be located on separate chips (or chipsets), boards, or units (e.g., a radio unit and a digital unit). In alternative embodiments, part or all of RF transceiver circuitry 772 and baseband processing circuitry 774 may be on the same chip or chipset, board, or unit.

[0168] In certain embodiments, some or all of the functions described herein as provided by a network node, base station, eNB, or other such network device may be performed by a processing circuit 770 that executes instructions stored on a device-readable medium 780 or a memory within the processing circuit 770. In alternative embodiments, some or all of the functions may be provided by the processing circuit 770, for example, in a hardwired manner, without executing instructions stored on a separate or discrete device-readable medium. In any of these embodiments, the processing circuit 770 may be configured to perform the described functions, whether or not instructions stored on a device-readable storage medium are executed. The benefits provided by such functionality are not limited to the processing circuit 770 or to other components of the network node 760, but are enjoyed by the network node 760 as a whole and / or by end users and the wireless network as a whole.

[0169] The device-readable medium 780 may include any form of volatile or non-volatile computer-readable memory, including, but not limited to, permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disk (CD) or digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data and / or instructions that can be used by the processing circuit 770. The device-readable medium 780 may store any suitable instructions, data or information, including computer programs, software, applications including one or more of logic, rules, codes, tables, etc., and / or other instructions that can be executed by the processing circuit 770 and used by the network node 760. The device-readable medium 780 may be used to store any calculations made by the processing circuit 770 and / or any data received via the interface 790. In some embodiments, the processing circuit 770 and the device-readable medium 780 may be considered to be integrated.

[0170] Interface 790 is used for wired or wireless communication of signaling and / or data between network node 760, network 706 and / or WD 710. As shown, interface 790 includes port / terminal 794, for example, sending data to network 706 and receiving data from network 706 through wired connection. Interface 790 also includes radio front-end circuit 792, which can be coupled to antenna 762, or is a part of antenna 762 in some embodiments. Radio front-end circuit 792 includes filter 798 and amplifier 796. Radio front-end circuit 792 can be connected to antenna 762 and processing circuit 770. Radio front-end circuit can be configured to adjust the signal communicated between antenna 762 and processing circuit 770. Radio front-end circuit 792 can receive digital data, which will be sent to other network nodes or WDs through wireless connection. Radio front-end circuit 792 can use the combination of filter 798 and / or amplifier 796 to convert digital data into radio signals with suitable channel and bandwidth parameters. Radio signals can then be sent through antenna 762. Similarly, when receiving data, antenna 762 may collect radio signals, which may then be converted to digital data by radio front end circuitry 792. The digital data may be passed to processing circuitry 770. In other embodiments, the interface may include different components and / or different combinations of components.

[0171] In certain alternative embodiments, the network node 760 may not include a separate radio front end circuit 792, and instead, the processing circuit 770 may include the radio front end circuit and may be connected to the antenna 762 without a separate radio front end circuit 792. Similarly, in some embodiments, all or some of the RF transceiver circuit 772 may be considered part of the interface 790. In other embodiments, the interface 790 may include one or more ports or terminals 794, the radio front end circuit 792, and the RF transceiver circuit 772 as part of a radio unit (not shown), and the interface 790 may communicate with the baseband processing circuit 774 as part of a digital unit (not shown).

[0172] Antenna 762 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals. Antenna 762 may be coupled to radio front-end circuit 790 and may be any type of antenna capable of wirelessly sending and receiving data and / or signals. In some embodiments, antenna 762 may include one or more omnidirectional, sector or flat panel antennas operable to send / receive radio signals between, for example, 2 GHz and 66 GHz. Omnidirectional antennas may be used to send / receive radio signals in any direction, sector antennas may be used to send / receive radio signals to / from devices in a specific area, and flat panel antennas may be line of sight antennas for sending / receiving radio signals in a relatively straight line. In some cases, using more than one antenna may be referred to as MIMO. In some embodiments, antenna 762 may be separated from network node 760 and may be connected to network node 760 via an interface or port.

[0173] Antenna 762, interface 790 and / or processing circuit 770 can be configured to perform any receiving operation and / or certain obtaining operation described herein as being performed by a network node. Any information, data and / or signal can be received from a wireless device, another network node and / or any other network device. Similarly, antenna 762, interface 790 and / or processing circuit 770 can be configured to perform any sending operation performed by a network node described herein. Any information, data and / or signal can be sent to a wireless device, another network node and / or any other network device.

[0174] The power circuit 787 may include a power management circuit or be coupled to a power management circuit, and is configured to provide power to the components of the network node 760 to perform the functions described herein. The power circuit 787 may receive power from a power supply 786. The power supply 786 and / or the power circuit 787 may be configured to provide power to the various components of the network node 760 in a form suitable for each component (e.g., at the voltage and current level required by each corresponding component). The power supply 786 may be included in the power circuit 787 and / or the network node 760 or outside the power circuit 787 and / or the network node 760. For example, the network node 760 may be connected to an external power source (e.g., a power outlet) via an input circuit or an interface such as a cable, whereby the external power supply supplies power to the power circuit 787. As another example, the power supply 786 may include a power source in the form of a battery or a battery pack, which is connected to or integrated in the power circuit 787. If the external power supply fails, the battery can provide backup power. Other types of power supplies, such as photovoltaic devices, may also be used.

[0175] Alternative embodiments of network node 760 may include beyond Figure 7 , which may be responsible for providing certain aspects of the functionality of the network node, including any of the functionality described herein and / or any functionality required to support the subject matter described herein. For example, the network node 760 may include a user interface device to allow and / or facilitate the input of information into the network node 760 and to allow and / or facilitate the output of information from the network node 760. This may allow and / or facilitate a user to perform diagnostic, maintenance, repair, and other management functions with respect to the network node 760.

[0176] In addition, the various network functions (NFs, such as SMF, PCF, UDR, AMF, etc.) described herein may be implemented by and / or hosted by different variants of the network node 760 (including the variants described above).

[0177] In some embodiments, wireless devices (WD, such as WD 710) can be configured to send and / or receive information without direct human interaction. For example, WD can be designed to send information to the network with a predetermined schedule when triggered by an internal or external event, or in response to a request from the network. Examples of WD include, but are not limited to, smart phones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), mobile communication (MTC) devices, Internet of Things (IoT) devices, vehicle-mounted wireless terminal devices, etc.

[0178] WD can support device-to-device (D2D) communication, vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, vehicle-to-anything (V2X) communication, for example, by implementing the 3GPP standard for sidelink communication, and in this case can be referred to as a D2D communication device. As another specific example, in the Internet of Things (IoT) scenario, WD can represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another WD and / or network node. In this case, WD can be a machine-to-machine (M2M) device, which can be referred to as an MTC device in the 3GPP context. As a specific example, WD can be a UE that implements the 3GPP narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices (e.g., electric meters), industrial machines, or household or personal devices (e.g., refrigerators, televisions, etc.), personal wearable devices (e.g., watches, fitness trackers, etc.). In other scenarios, WD can represent a vehicle or other device that can monitor and / or report its operating status or other functions associated with its operation. As mentioned above, WD can represent the end point of wireless connection, in which case, the device can be referred to as a wireless terminal. In addition, as mentioned above, WD can be mobile, in which case, it can also be referred to as a mobile device or a mobile terminal.

[0179] As shown, WD 710 includes antenna 711, interface 714, processing circuit 720, device-readable medium 730, user interface device 732, auxiliary device 734, power supply 736, and power supply circuit 737. WD 710 may include multiple groups of one or more of the components shown for different wireless technologies supported by WD 710 (e.g., GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention a few). These wireless technologies may be integrated into the same or different chips or chipsets as other components within WD 710.

[0180] Antenna 711 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals, and is connected to interface 714. In some alternative embodiments, antenna 711 can be separated from WD 710 and can be connected to WD 710 through an interface or port. Antenna 711, interface 714 and / or processing circuit 720 can be configured to perform any receiving or sending operation described herein as being performed by WD. Any information, data and / or signal can be received from a network node and / or another WD. In some embodiments, radio front-end circuit and / or antenna 711 can be considered as an interface.

[0181] As shown, the interface 714 includes a radio front-end circuit 712 and an antenna 711. The radio front-end circuit 712 includes one or more filters 718 and an amplifier 716. The radio front-end circuit 714 is connected to the antenna 711 and the processing circuit 720, and can be configured to adjust the signal transmitted between the antenna 711 and the processing circuit 720. The radio front-end circuit 712 can be coupled to the antenna 711 or be a part of the antenna 711. In some alternative embodiments, the WD 710 may not include a separate radio front-end circuit 712; instead, the processing circuit 720 may include a radio front-end circuit and may be connected to the antenna 711. Similarly, in some embodiments, some or all of the RF transceiver circuit 722 can be considered as part of the interface 714. The radio front-end circuit 712 can receive digital data, which will be sent out to other network nodes or WDs via a wireless connection. The radio front-end circuit 712 can use a combination of filters 718 and / or amplifiers 716 to convert the digital data into a radio signal with suitable channel and bandwidth parameters. The radio signal can then be sent through the antenna 711. Similarly, when receiving data, antenna 711 may collect radio signals, which may then be converted to digital data by radio front end circuit 712. The digital data may be passed to processing circuit 720. In other embodiments, the interface may include different components and / or different combinations of components.

[0182] Processor circuit 720 may include one or more of a combination of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or encoded logic operable to provide WD 710 functionality alone or in combination with other WD 710 components (e.g., device readable medium 730). Such functionality may include any of the various wireless features or benefits discussed herein.

[0183] For example, processing circuit 720 may execute instructions stored in device-readable medium 730 or in a memory within processing circuit 720 to provide the functionality disclosed herein. More specifically, instructions (also referred to as computer program products) stored in medium 730 may include instructions that, when executed by processing circuit 720, may configure WD 710 to perform operations corresponding to the various exemplary methods (e.g., processes) described herein.

[0184] As shown, the processing circuit 720 includes one or more of the RF transceiver circuit 722, the baseband processing circuit 724, and the application processing circuit 726. In other embodiments, the processing circuit may include different components and / or different combinations of components. In some embodiments, the processing circuit 720 of the WD 710 may include a SOC. In some embodiments, the RF transceiver circuit 722, the baseband processing circuit 724, and the application processing circuit 726 may be on a separate chip or chipset. In an alternative embodiment, a part or all of the baseband processing circuit 724 and the application processing circuit 726 may be combined into one chip or chipset, and the RF transceiver circuit 722 may be on a separate chip or chipset. In another alternative embodiment, a part or all of the RF transceiver circuit 722 and the baseband processing circuit 724 may be on the same chip or chipset, and the application processing circuit 726 may be on a separate chip or chipset. In other alternative embodiments, a part or all of the RF transceiver circuit 722, the baseband processing circuit 724, and the application processing circuit 726 may be combined in the same chip or chipset. In some embodiments, RF transceiver circuitry 722 may be part of interface 714. RF transceiver circuitry 722 may condition RF signals for processing circuitry 720.

[0185] In some embodiments, some or all of the functions described herein as being performed by the WD may be provided by a processing circuit 720 that executes instructions stored on a device-readable medium 730, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by the processing circuit 720, for example, in a hardwired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these specific embodiments, the processing circuit 720 may be configured to perform the described functions, regardless of whether instructions stored on a device-readable storage medium are executed. The benefits provided by such functionality are not limited to the processing circuit 720 or to other components of the WD 710, but are enjoyed by the WD 710 as a whole and / or by the end user and the wireless network as a whole.

[0186] Processing circuit 720 may be configured to perform any determination, calculation, or similar operation (e.g., certain acquisition operations) described herein as being performed by WD. Such operations performed by processing circuit 720 may include processing information obtained by processing circuit 720 by, for example, converting the obtained information to other information, comparing the obtained information or the converted information to information stored by WD 710, and / or performing one or more operations based on the obtained information or the converted information and making a determination based on the results of the processing.

[0187] The device-readable medium 730 is operable to store computer programs, software, applications including one or more of logic, rules, codes, tables, etc., and / or other instructions executable by the processing circuit 720. The device-readable medium 730 may include a computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), a mass storage medium (e.g., a hard disk), a removable storage medium (e.g., a compact disk (CD) or a digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that may be used by the processing circuit 720. In some embodiments, the processing circuit 720 and the device-readable medium 730 may be considered to be integrated.

[0188] The user interface device 732 may include components that allow and / or facilitate human users to interact with the WD 710. This interaction may have a variety of forms, such as visual, auditory, tactile, etc. The user interface device 732 is operable to generate output to the user and allow and / or facilitate the user to provide input to the WD 710. The type of interaction may vary depending on the type of user interface device 732 installed in the WD 710. For example, if the WD 710 is a smart phone, the interaction may be performed via a touch screen; if the WD 710 is a smart meter, the interaction may be performed by providing a screen for usage (e.g., the number of gallons used) or a speaker that provides an audible alarm (e.g., if smoke is detected). The user interface device 732 may include input interfaces, devices and circuits, and output interfaces, devices and circuits. The user interface device 732 may be configured to allow and / or facilitate information to be input into the WD 710, and is connected to the processing circuit 720 to allow and / or facilitate the processing circuit 720 to process the input information. The user interface device 732 may include, for example, a microphone, proximity or other sensor, key / button, touch display, one or more cameras, USB port or other input circuit. The user interface device 732 is also configured to allow and / or facilitate information output from WD 710, and allow and / or facilitate processing circuit 720 to output information from WD 710. The user interface device 732 may include, for example, a speaker, display, vibration circuit, USB port, headphone jack or other output circuit. By using one or more input and output interfaces, devices and circuits of the user interface device 732, WD 710 can communicate with end users and / or wireless networks, and allow and / or facilitate them to benefit from the functions described herein.

[0189] Auxiliary device 734 is operable to provide more specific functions that may not normally be performed by a WD. This may include specialized sensors for measuring for various purposes, interfaces for other types of communications such as wired communications, etc. The inclusion and type of components of auxiliary device 734 may vary depending on the embodiment and / or scenario.

[0190] In some embodiments, the power supply 736 may be in the form of a battery or a battery pack. Other types of power supplies may also be used, such as an external power supply (e.g., a power outlet), a photovoltaic device, or a battery cell. The WD 710 may also include a power supply circuit 737 for delivering power from the power supply 736 to various parts of the WD 710, and the various parts of the WD 710 require power from the power supply 736 to perform any function described or indicated herein. In some embodiments, the power supply circuit 737 may include a power management circuit. The power supply circuit 737 may additionally or alternatively be operable to receive power from an external power supply; in this case, the WD 710 may be connected to an external power supply (e.g., a power outlet) through an input circuit or an interface such as a power cable. In some embodiments, the power supply circuit 737 may also be operable to deliver power from an external power supply to the power supply 736. For example, this may be used for charging the power supply 736. The power supply circuit 737 may perform any conversion or other modification on the power from the power supply 736 to make it suitable for supplying to various components of the WD 710.

[0191] Figure 8 One embodiment of a UE in accordance with various aspects described herein is shown. As used herein, a "user equipment" or "UE" may not necessarily have a "user" in the sense of a human user who owns and / or operates the associated device. Alternatively, a UE may represent a device that is intended to be sold to or operated by a human user but may not or may not initially be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended to be sold to or operated by an end user but may be associated with or operated for the benefit of a user (e.g., a smart meter). UE 800 may be any UE identified by the Third Generation Partnership Project (3GPP), including a NB-IoT UE, a Machine Type Communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. As Figure 8 As shown, UE 800 is an example of a WD configured for communication according to one or more communication standards promulgated by the Third Generation Partnership Project (3GPP), such as 3GPP's GSM, UMTS, LTE, and / or 5G standards. As previously mentioned, the terms WD and UE may be used interchangeably. Therefore, although Figure 8 It is UE, but the components discussed in this article are also applicable to WD and vice versa.

[0192] exist Figure 8In the embodiment, UE 800 includes a processing circuit 801, which is operably coupled to an input / output interface 805, a radio frequency (RF) interface 809, a network connection interface 811, a memory 815 including a random access memory (RAM) 817, a read-only memory (ROM) 819, and a storage medium 821, a communication subsystem 831, a power supply 833, and / or any other components, or any combination thereof. The storage medium 821 includes an operating system 823, an application 825, and data 827. In other embodiments, the storage medium 821 may include other similar types of information. Some UEs may use Figure 8 All components shown in the UE may be used, or only a subset of these components may be used. The level of integration between components may vary from one UE to another. In addition, some UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0193] exist Figure 8 , processing circuit 801 may be configured to process computer instructions and data. Processing circuit 801 may be configured to implement any sequential state machine operable to execute machine instructions stored as a machine-readable computer program in a memory, such as: one or more hardware-implemented state machines (e.g., implemented in discrete logic, FPGA, ASIC, etc.); programmable logic together with appropriate firmware; one or more stored programs, general-purpose processors (e.g., microprocessors or digital signal processors (DSPs)) together with suitable software; or any combination of the above. For example, processing circuit 801 may include two central processing units (CPUs). Data may be information in a form suitable for use by a computer.

[0194] In the depicted embodiment, the input / output interface 805 may be configured to provide a communication interface to an input device, an output device, or an input and output device. The UE 800 may be configured to use an output device via the input / output interface 805. The output device may use an interface port of the same type as the input device. For example, a USB port may be used to provide input to and output from the UE 800. The output device may be a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, a transmitter, a smart card, another output device, or any combination thereof. The UE 800 may be configured to use an input device via the input / output interface 805 to allow and / or facilitate a user to capture information into the UE 800. The input device may include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a touchpad, a scroll wheel, a smart card, etc. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from the user. The sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, another similar sensor, or any combination thereof. For example, the input device can be an accelerometer, a magnetometer, a digital camera, a microphone, and an optical sensor.

[0195] exist Figure 8 In the embodiment of the present invention, the RF interface 809 can be configured to provide a communication interface to RF components such as transmitters, receivers, and antennas. The network connection interface 811 can be configured to provide a communication interface to the network 843a. The network 843a can include a wired and / or wireless network, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 843a can include a Wi-Fi network. The network connection interface 811 can be configured to include a receiver and a transmitter interface, and the receiver and transmitter interface are used to communicate with one or more other devices through a communication network according to one or more communication protocols (e.g., Ethernet, TCP / IP, SONET, ATM, etc.). The network connection interface 811 can implement receiver and transmitter functions suitable for communication network links (e.g., optical, electrical, etc.). The transmitter and receiver functions can share circuit components, software, or firmware, or alternatively can be implemented separately.

[0196] RAM 817 can be configured to interface with processing circuit 801 via bus 802 to provide storage or caching of data or computer instructions during execution of software programs such as operating systems, applications, and device drivers. ROM 819 can be configured to provide computer instructions or data to processing circuit 801. For example, ROM 819 can be configured to store unchanged low-level system code or data for basic system functions stored in non-volatile memory, such as basic input and output (I / O), startup, or reception of keystrokes from a keyboard. Storage medium 821 can be configured to include memory, such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable tape cartridge, or flash drive.

[0197] In one example, the storage medium 821 may be configured to include an operating system 823, an application 825 such as a web browser application, a widget or gadget engine or another application, and a data file 827. The storage medium 821 may store any one of a variety of operating systems or a combination of operating systems for use by the UE 800. For example, the application 825 may include executable program instructions (also referred to as a computer program product) that, when executed by the processor 801, may configure the UE 800 to perform operations corresponding to the various exemplary methods (e.g., processes) described herein.

[0198] The storage medium 821 may be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), a floppy drive, a flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disk (HD-DVD) optical drive, a built-in hard drive, a Blu-ray optical drive, a holographic digital data storage (HDDS) optical drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, a smart card memory such as a user identity module or a removable user identity (SIM / RUIM) module, other memory or any combination thereof. The storage medium 821 may allow and / or facilitate the UE 800 to access computer executable instructions, applications, etc. stored on a temporary or non-temporary storage medium to unload data or upload data. Articles such as articles utilizing a communication system may be tangibly embodied in the storage medium 821, which may include a device-readable medium.

[0199] exist Figure 8In the embodiment of the present invention, the processing circuit 801 can be configured to communicate with the network 843b using the communication subsystem 831. The network 843a and the network 843b can be one or more identical networks or one or more different networks. The communication subsystem 831 can be configured to include one or more transceivers for communicating with the network 843b. For example, the communication subsystem 831 can be configured to include one or more transceivers for communicating with another device (e.g., another WD, UE) or one or more remote transceivers of a base station of a radio access network (RAN) capable of wireless communication according to one or more communication protocols (e.g., IEEE 802.8, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, etc.). Each transceiver can include a transmitter 833 and / or a receiver 835 to respectively implement a transmitter or receiver function (e.g., frequency allocation, etc.) suitable for a RAN link. In addition, the transmitter 833 and the receiver 835 of each transceiver can share circuit components, software or firmware, or can be implemented separately instead.

[0200] In the illustrated embodiment, the communication functions of the communication subsystem 831 may include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication (such as use of a global positioning system (GPS) for determining location), another similar communication function, or any combination thereof. For example, the communication subsystem 831 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 843b may include a wired and / or wireless network, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 843b may be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 813 may be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE 800.

[0201] The features, benefits and / or functions described herein may be implemented in one of the components of UE 800, or divided between multiple components of UE 800. In addition, the features, benefits and / or functions described herein may be implemented in any combination of hardware, software or firmware. In one example, the communication subsystem 831 may be configured to include any components described herein. In addition, the processing circuit 801 may be configured to communicate with any such components via bus 802. In another example, any such component may be represented by a program instruction stored in a memory, and when executed by the processing circuit 801, the program instruction performs the corresponding function described herein. In another example, the function of any such component may be divided between the processing circuit 801 and the communication subsystem 831. In another example, the non-computationally intensive functions of any such component may be implemented with software or firmware, and the computationally intensive functions may be implemented with hardware.

[0202] Fig. 9 is a schematic block diagram illustrating a virtualized environment 900 in which the functions implemented by some embodiments may be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device, which may include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization may be applied to a node (e.g., a virtualized base station or a virtualized radio access node) or a device (e.g., a UE, a wireless device, or any other type of communication device) or a component thereof, and relates to an implementation in which at least a portion of the functions are implemented as one or more virtual components (e.g., by one or more applications, components, functions, virtual machines, or containers executed on one or more physical processing nodes in one or more networks).

[0203] In some embodiments, some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 900 hosted by one or more hardware nodes 930. Furthermore, in embodiments where the virtual nodes are not radio access nodes or do not require radio connectivity (e.g., core network nodes), the network nodes may be fully virtualized at this point.

[0204] These functions may be implemented by one or more applications 920 (which may alternatively be referred to as software instances, virtual devices, network functions, application functions, virtual nodes, virtual network functions, etc.), which are operable to implement some features, functions, and / or benefits of some embodiments disclosed herein. The applications 920 (including, for example, network functions and / or application functions) run in a virtualized environment 900, which provides hardware 930 including processing circuits 960 and memory 990. The memory 990 contains instructions 9125 executable by the processing circuits 960, whereby the applications 920 are operable to provide one or more features, benefits, and / or functions disclosed herein.

[0205] The virtualized environment 900 may include a general or special purpose network hardware device (or node) 930, which includes a set of one or more processors or processing circuits 960, which may be commercial off-the-shelf (COTS) processors, application-specific integrated circuits (ASICs), or any other type of processing circuit including digital or analog hardware components or special purpose processors. Each hardware device may include a memory 990-1, which may be a non-permanent memory for temporarily storing instructions 9125 or software executed by the processing circuit 960. For example, the instructions 9125 may include program instructions (also referred to as computer program products) that, when executed by the processing circuit 960, may configure the hardware node 920 to perform operations corresponding to the various exemplary methods (e.g., processes) described herein. Such operations may also be attributed to the virtual node 920 hosted by the hardware node 930.

[0206] Each hardware device may include one or more network interface controllers (NICs) 970, also referred to as network interface cards, which include physical network interfaces 980. Each hardware device may also include a non-transitory, permanent machine-readable storage medium 990-2 having stored therein software 9125 and / or instructions executable by the processing circuitry 960. The software 9125 may include any type of software, including software for instantiating one or more virtualization layers 950 (also referred to as hypervisors), software for executing virtual machines 940, and software that enables them to perform the functions, features, and / or benefits described in connection with some of the embodiments described herein.

[0207] The virtual machines 940 include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be run by a corresponding virtualization layer 950 or hypervisor. Different embodiments of instances of the virtual device 920 may be implemented on one or more of the virtual machines 940, and the implementation may be done in different ways.

[0208] During operation, processing circuitry 960 executes software 9125 to instantiate a hypervisor or virtualization layer 950, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer 950 may present a virtual operating platform that appears to virtual machine 940 as networked hardware.

[0209] like Fig. 9 As shown, hardware 930 can be an independent network node with common or specific components. Hardware 930 can include antenna 9225 and some functions can be implemented through virtualization. Alternatively, hardware 930 can be part of a larger hardware cluster (e.g., in a data center or customer premises equipment (CPE)), where many hardware nodes work together and are managed by management and coordination (MANO) 9100, which oversees the life cycle management of application 920, etc.

[0210] In some contexts, virtualization of hardware is referred to as network function virtualization (NFV). NFV can be used to unify numerous network equipment types onto industry-standard high-capacity server hardware, physical switches, and physical storage that can be located in data centers and customer premises equipment.

[0211] In the context of NFV, a virtual machine 940 may be a software implementation of a physical machine that runs programs as if they were executed on a physical, non-virtualized machine. Each virtual machine 940 and the portion of hardware 930 that executes the virtual machine (which may be hardware dedicated to the virtual machine and / or hardware shared by the virtual machine and other virtual machines in virtual machines 940) form a separate virtual network element (VNE).

[0212] Still in the context of NFV, a virtual network function (VNF) is responsible for handling specific network functions running in one or more virtual machines 940 on top of the hardware network infrastructure 930 and corresponds to Fig. 9 Application 920.

[0213] In some embodiments, one or more radio units 9200, each including one or more transmitters 9220 and one or more receivers 9210, may be coupled to one or more antennas 9225. The radio unit 9200 may communicate directly with the hardware node 930 via one or more suitable network interfaces, and may be used in conjunction with a virtual component to provide a virtual node with radio capabilities, such as a radio access node or base station. Nodes arranged in this manner may also communicate with one or more UEs, such as described elsewhere herein.

[0214] In some embodiments, some signaling may be performed via control system 9230 , which may alternatively be used for communications between hardware node 930 and radio unit 9200 .

[0215] The various network functions (NFs, such as SMF, PCF, UDR, AMF, etc.) described herein may be implemented in a virtualized environment 900 , for example, as NF 920 running on hardware 930 .

[0216] As described herein, the device and / or apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module including such a chip or chipset; however, this does not exclude the possibility of implementing the functions of the device or apparatus (rather than hardware implementation) as a software module such as a computer program or a computer program product, which includes an executable software code portion for execution or operation on a processor. In addition, the functions of the device or apparatus may be implemented by any combination of hardware and software. The device or apparatus may also be considered as a combination of multiple devices and / or apparatuses, whether functionally cooperating with each other or independent of each other. In addition, the devices and apparatus may be implemented in a distributed manner throughout the system, as long as the functions of the device or apparatus are retained. Such principles and similar principles are considered to be known to technicians.

[0217] In addition, the functions performed by a wireless device or network node described herein may be distributed across multiple wireless devices and / or network nodes. In other words, it is contemplated that the functions of the network nodes and wireless devices described herein are not limited to being performed by a single physical device and may in fact be distributed across several physical devices.

[0218] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by ordinary technicians in the field to which the present disclosure belongs. It will be understood that the terms used herein should be interpreted as consistent with their meanings in the context of this specification and the relevant technology, and are not interpreted as ideal or overly formal meanings, unless so clearly defined herein.

[0219] In addition, some terms used in the present disclosure (including specification, drawings and exemplary embodiments thereof) may be used synonymously in some cases, including but not limited to, for example, data and information. It should be understood that, although these words and / or other words that may be synonymous with each other may be used synonymously in this article, in some cases, such words may not be intended to be used synonymously. In addition, to the extent that prior art knowledge has not been explicitly incorporated herein by reference above, it is explicitly incorporated herein in its entirety. All disclosures cited are incorporated herein by reference in their entirety.

[0220] As used herein, unless expressly stated otherwise, the phrases "at least one of" and "one or more of" followed by a concatenated list of enumerated items (e.g., "A and B," "A, B, and C") are intended to mean "at least one of the items, each of which is selected from the list, the list including" the enumerated items. For example, "at least one of A and B" is intended to mean any of the following: A; B; A and B. Similarly, "one or more of A, B, and C" is intended to mean any of the following: A; B; C; A and B; B and C; A and C; A, B, and C.

[0221] As used herein, unless expressly stated otherwise, the phrase "plurality" followed by a concatenated list of enumerated items (e.g., "A and B," "A, B, and C") is intended to mean "plurality of items, each of which is selected from the list, the list including" the enumerated items. For example, "plurality A and B" is intended to mean any of the following: more than one A; more than one B; or at least one A and at least one B.

[0222] The foregoing merely illustrates the principles of the present disclosure. In view of the teachings herein, various modifications and changes to the described embodiments will be apparent to those skilled in the art. Therefore, it will be appreciated that those skilled in the art will be able to design many systems, devices and processes that, although not explicitly shown or described herein, embody the principles of the present disclosure and may therefore be within the spirit and scope of the present disclosure. As will be appreciated by those of ordinary skill in the art, the various exemplary embodiments may be used together and interchangeably with each other.

[0223] Example embodiments of the techniques and apparatus described herein include, but are not limited to, the following examples:

[0224] E1. A method for a policy control function (PCF) of a communication network, the method comprising:

[0225] during registration of a user equipment (UE) in the communication network, determining one or more first identifiers of respective one or more operating systems (OS) supported by the UE;

[0226] storing the first identifier in a user data repository (UDR) of the communication network;

[0227] During establishment of a PDU session of the UE and based on an application identifier in a service data flow (SDF) template associated with the PDU session, determining one or more second identifiers of an OS supported by the UE and associated with the application identifier; and

[0228] Sending a policy rule for the PDU session to a session management function (SMF) of the communication network, wherein the policy rule includes the second identifier and one or more third identifiers corresponding to the respective second identifier and associated with the application identifier.

[0229] E2. The method of embodiment E1, further comprising receiving a request for a policy rule for the PDU session from the SMF, wherein:

[0230] The request includes an SDF template, the SDF template including the application identifier; and

[0231] The policy rules are sent in response to the request.

[0232] E2a. The method of embodiment E2, wherein the request further comprises an indication that the requested policy rule is for a multiple access (MA) PDU session.

[0233] E3. The method of any one of embodiments E1 to E2a, wherein the third identifier is additional application identifiers, each additional identifier being associated with a specific second identifier of the second identifiers of the OS supported by the UE.

[0234] E4. The method of any one of embodiments E1 to E3, wherein determining the second identifier comprises obtaining the first identifier from the UDR, wherein the second identifier is included in the first identifier.

[0235] E5. The method of embodiment E4, wherein determining the second identifier further comprises: when the first identifier cannot be obtained from the UDR:

[0236] determining the second identifier based on an identifier of the UE; and

[0237] When the second identifier cannot be determined based on the identifier of the UE, the second identifier is determined based on a predetermined relationship between the application identifier and the OS identifier.

[0238] E6. A method for a session management function (SMF) of a communication network, the method comprising:

[0239] receiving a first request to establish a PDU session of a user equipment (UE);

[0240] sending a second request for policy rules for the PDU session to a policy control function (PCF) of the communication network, wherein the second request includes a service data flow (SDF) template, the SDF template including an application identifier associated with the PDU session;

[0241] receiving, from the PCF, a policy rule for the PDU session, wherein the policy rule comprises:

[0242] one or more second identifiers of operating systems (OS) associated with the application identifier and supported by the UE, and

[0243] one or more third identifiers corresponding to respective second identifiers and associated with the application identifier; and

[0244] A PDU session rule including the second identifier and the third identifier is sent to the UE.

[0245] E7. The method according to embodiment E1, further comprising:

[0246] The first request includes an indication that the requested PDU session is a multiple access (MA) PDU session; and

[0247] The second request includes an indication that the policy rule is for an MA PDU session.

[0248] E8. The method of any one of embodiments E1 to E2, wherein the third identifier is additional application identifiers, each additional identifier being associated with a specific second identifier of the second identifiers of the OS supported by the UE.

[0249] E9. A method according to any one of embodiments E6 to E8, wherein the PDU session rule is used for access service steering, switching and splitting (ATSSS).

[0250] E10. A policy control function (PCF) for a communication network, the PCF comprising:

[0251] an interface circuit configured to communicate with at least a session management function (SMF) and a user data repository (UDR) of the communication network; and

[0252] A processing circuit is operably coupled to the interface circuit, whereby the processing circuit and the interface circuit are configured to perform operations corresponding to any method of embodiments E1 to E5.

[0253] E11. A policy control function (PCF) for a communication network, the PCF being arranged to perform operations corresponding to any method of embodiments E1 to E5.

[0254] E12. A non-transitory computer-readable medium storing computer-executable instructions which, when executed by a processing circuit associated with a policy control function (PCF) for a communication network, configure the PCF to perform operations corresponding to any of the methods of embodiments E1 to E5.

[0255] E13. A computer program product comprising computer executable instructions which, when executed by processing circuitry associated with a policy control function (PCF) for a communication network, configure the PCF to perform operations corresponding to any of the methods of embodiments E1 to E5.

[0256] E14. A session management function (SMF) for a communication network, the SMF comprising:

[0257] an interface circuit configured to communicate with at least a user equipment (UE) and a policy control function (PCF) of the communication network; and

[0258] A processing circuit is operably coupled to the interface circuit, whereby the processing circuit and the interface circuit are configured to perform operations corresponding to any method of embodiments E6 to E9.

[0259] E15. A session management function (SMF) for a communication network, the SMF being arranged to perform operations corresponding to any of the methods of embodiments E6 to E9.

[0260] E16. A non-transitory computer-readable medium storing computer-executable instructions which, when executed by a processing circuit associated with a session management function (SMF) for a communication network, configure the SMF to perform operations corresponding to any of the methods of embodiments E6 to E9.

[0261] E17. A computer program product comprising computer executable instructions which, when executed by a processing circuit associated with a session management function (SMF) for a communication network, configure the SMF to perform operations corresponding to any of the methods of embodiments E6 to E9.

Claims

1. A method for a policy control function (PCF) of a communication network, the method comprising: During establishment of a packet data unit (PDU) session of a user equipment (UE), one or more UE application descriptors corresponding to a network application identifier (AppId) of a service data flow (SDF) template for the PDU session are determined (540), wherein each of the one or more UE application descriptors comprises: a first identifier, OSId, of the operating system OS supported by the UE, and a second identifier OSAppId for an application of the OS supported by the UE identified by the first identifier; and The policy rules for the PDU session are sent (550) to a session management function (SMF) of the communication network, wherein the policy rules include the one or more UE application descriptors.

2. The method according to claim 1, further comprising receiving (530) a request for policy rules for the PDU session from the SMF, wherein: The request includes the SDF template, the SDF template includes the network application identifier; and The policy rules are sent in response to the request.

3. The method according to claim 1, further comprising receiving (530) a request for policy rules for the PDU session from the SMF, wherein: The request includes an indication that the requested policy rule is for a multiple access MA PDU session; as well as The policy rules sent to the SMF include access service guidance, switching and splitting ASSS information.

4. The method according to claim 1, further comprising: During registration of the UE in the communication network, determining (510) an identifier of an OS supported by the UE; as well as The determined identifier is stored (520) in a user data repository UDR of the communication network.

5. The method according to claim 1, wherein: Determining (540) the one or more UE application descriptors includes: mapping (541) the network application identifier to one or more OS identifiers and corresponding one or more OS-specific application identifiers; Obtaining (542) identifiers of one or more OSs supported by the UE; selecting (543) the mapped one or more OS identifiers matching the obtained identifiers of the one or more OSs supported by the UE as the first identifier; and The mapped OS-specific application identifier corresponding to the selected first identifier is selected (544) as the second identifier.

6. The method according to claim 1, wherein: Determining (540) the UE application descriptor includes: Acquire (542a) a first identifier of an OS supported by the UE from a user data repository UDR of the communication network; When the first identifier cannot be obtained from the UDR, the first identifier is determined (542b) based on a permanent equipment identifier PEI of the UE.

7. The method according to claim 6, further comprising: When the first identifier is not available from the UDR and cannot be determined based on the PEI, selecting (542c) an identifier of an OS commonly supported by UEs operating in the communication network; The identifier is included as the first identifier in a UE application descriptor to the SMF.

8. A method for a session management function (SMF) of a communication network, the method comprising: sending (620) a second request for a policy rule for a packet data unit, PDU, session of a user equipment, UE, to a policy control function, PCF, of the communication network, wherein the second request comprises an indication that the requested policy rule is for a multiple access, MA, PDU session; Policy rules for the PDU session are received (630) from the PCF, wherein: The policy rule includes one or more UE application descriptors corresponding to the network application identifier, and Each UE application descriptor includes: a first identifier, OSId, of the operating system OS supported by the UE, and a second identifier OSAppId for an application of the OS supported by the UE identified by the first identifier; and Access service steering, handover and split ASSS rules including the one or more UE application descriptors are sent (640) to the UE.

9. The method according to claim 8, further comprising: A service data flow SDF template is included in the second request, and the service data flow SDF template includes a network application identifier AppId associated with the PDU session.

10. The method of claim 8, further comprising receiving (610) a first request to establish a PDU session for the UE, wherein: The first request comprises an indication that the requested PDU session is a Multi-Access MA PDU session.

11. A non-transitory computer-readable medium (780, 990) storing computer-executable instructions which, when executed by a processing circuit (770, 960) associated with a policy control function (PCF) (250, 440, 760, 920) of a communication network (298), configure the PCF to perform a method comprising: During establishment of a packet data unit (PDU) session of a user equipment (UE), a UE application descriptor corresponding to a network application identifier (AppId) of a service data flow (SDF) template for the PDU session is determined (540), wherein the UE application descriptor comprises: a first identifier, OSId, of the operating system OS supported by the UE, and a second identifier OSAppId for an application of the OS supported by the UE identified by the first identifier; and At least one policy rule for the PDU session is sent (550) to a session management function, SMF, of the communication network, wherein the at least one policy rule comprises the UE application descriptor.

12. The non-transitory computer readable medium of claim 11 storing instructions which, when executed, configure the PCF to further perform the step of receiving (530) a request from the SMF for at least one policy rule for the PDU session, wherein: The request includes the SDF template, the SDF template includes the network application identifier; and The policy rules are sent in response to the request.

13. The non-transitory computer readable medium of claim 11 storing instructions that when executed configure the PCF to further perform the step of receiving (530) a request for one or more policy rules for the PDU session from the SMF, wherein: The request includes an indication that the requested one or more policy rules are for a multiple access MA PDU session; as well as The one or more policy rules sent to the SMF include access service guidance, switching and splitting ASSS information.

14. The non-transitory computer readable medium of claim 11 storing instructions that when executed configure the PCF to further perform the following steps: During registration of the UE in the communication network, determining (510) an identifier of an OS supported by the UE; and The determined identifier is stored (520) in a user data repository UDR of the communication network.

Images