Dynamic API for URSP traffic categories

Abstract

Systems and methods are disclosed for enabling the identification of traffic of the applications and application flows in the mobile network even when Virtual Private Network (VPN), or VPN-like, solutions are used, thereby enabling traffic management, such as Quality of Service (QoS) management, in the mobile network on an application flow level.

Description

DYNAMIC API FOR URSP TRAFFIC CA TEGORIESTechnical Field

[0001] The present disclosure relates to the configuration and use of User Equipment (UE) Route Selection Policies (URSPs) and traffic categories in a mobile network.Background

[0002] The current invention disclosure is related to providing new functionality in existing (4thGeneration (4G), 5thGeneration (5G), etc.) and future Mobile Networks (6thGeneration (6G), etc.). The area of functionality is about enabling wider usage of Quality of Service (QoS) in the 3rdGeneration Partnership Project (3GPP) defined mobile networks.5G Background

[0003] Standardization work has been ongoing on Next Generation Radio Access Network (NG-RAN) and 5G Core (5GC) as new radio access and new packet core network since 3GPP Rel-15 (see 3GPP Technical Specifications (TS) 23.501 and 23.502 for stage-2 descriptions).Figure 1

[0004] Figure 1 shows 5G System architecture using service-based representation as described in 3GPP TS 23.501 V18.3.0. In particular, Figure 1 corresponds to Figure 4.2.3-1 from 3GPP TS 23.501 V18.3.0.Figure 2

[0005] Figure 2 shows the internal architecture for a gNodeB (gNB) i.e. a base station supporting New Radio (NR) Radio Access Technology (RAT) in the (R)AN of Figure 1, which is referred to as NG-RAN in this case (see 3GPP TS 38.401 for stage-2 description of NG-RAN). Figure 2 assumes that both Higher Layer Split (HLS) and Control Plane (CP) and User Plane (UP) split (CP-UP split) have been adopted within the gNB.QoS Principles

[0006] In regard to QoS in the Evolved Packet System (EPS), QoS is managed in EPS on a per bearer level from the Core Network (CN). The evolved NodeB (eNB) (i.e., the base station for the Long Term Evolution (LTE) RAT) is responsible for setting up the radio bearers, radio resource management, and enforcing QoS according to the bearer QoS Profile - over the radio (e.g. LTE-Uu) interface in the downlink and over the transport network in the uplink.Figure 3

[0007] Figure 3 gives an overview of the QoS framework in EPS. Bearers including a QoS Profile are set up from the Packet Data Network (PDN) Gateway (GW) in the CN, and QoS is enforced in the PDN GW and in the eNB for the downlink, and in the User Equipment (UE) and the eNB for the uplink.Applicant’s Ref. P110404W0012

[0008] Many services and subscribers share the same radio and network resources. Real-time services (voice, video etc.) are sharing the same resources as non-real-time services (Internet browsing, file download etc.). One challenge in this area is how to ensure QoS (e.g., bit rates, packet delays, packet loss, bounded latency) for Real Time Services. 3GPP EPS (i.e. both Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and Evolved Packet Core (EPC)) provides efficient QoS mechanisms to ensure that the user experience of different services sharing the same resources is acceptable. Examples of such mechanisms provided in 3GPP are:1 . Traffic Separation: Different traffic types receive different treatment (queuing, etc.) in network2. 3GPP provides for both relative QoS and absolute QoS (using Guaranteed Bit Rates)3. GBR (Guaranteed Bit Rate) based admission control is used to reserve resources before traffic is admitted into the network or rejected otherwise4. Policy and Charging Control (PCC) may determine what treatment to apply to the traffic streams

[0009] 3GPP defines the concept of a Packet Data Network (PDN). A PDN is in most cases an Internet Protocol (IP) network, e.g. Internet or an operator IP Multimedia Subsystem (IMS) service network. A PDN has one or more names; each name is defined in a string called APN (Access Point Name). The PDN Gateway (PGW) is a gateway towards one or more PDNs. A UE may have one or more PDN connections. A PDN connection is a logical IP tunnel between UE and PGW, providing the UE access to a PDN. The setup of a PDN connection is initiated from the UE.

[0010] Every PDN connection consists of one or more bearers. See TS 23.401 section 4.7.2 for a description of the bearer concept. A bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and a PGW. Each bearer on a particular access has a unique bearer Identity (ID). On the 3GPP access, the bearer is end-to-end between UE and PGW. Every PDN connection has at least one bearer, and this bearer is called the default bearer. All additional bearers on the PDN connection are called dedicated bearers.

[0011] A bearer carries traffic in the form of IP packets or non-IP packets. Which traffic is carried on a bearer is defined by filters i.e. how to map different applications and their corresponding application flows from a specific UE to different bearers in the network. A filter is an n-tuple where each element in the tuple contains a value, a range, or a wildcard. An n-tuple is also known as an IP flow. An example of a 5-tuple is (dst IP=83.50.20.110, srcIP=145.45.68.201, dst port=80, src port=*, prot=TCP). This 5-tuple defines a source and a destination IP address, a source and a destination port, and a protocol. The source port is a wildcard. Traffic matching this 5-tuple filter would be all TCP traffic from IP=145.45.68.201 to I P=83.50.20.110 and port=80. A Traffic Flow Template (TFT) contains one or more filters. Every bearer has a TFT. One bearer within a PDN connection and access may lack an explicit TFT (this bearer is typically the default bearer). Implicitly such bearer has a TFT with a single filter matching all packets.

[0012] There are two types of bearers: GBR and non-GBR bearers. Every EPS bearer is associated with the following QoS parameters: QoS Class Identifier (QCI) and Allocation and Retention Priority (ARP). GBR bearers are in addition associated with bit rate parameters for Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR). Non- GBR bearers do not have bearer-level bit rate parameters. Instead, there is aggregate enforcement of all non-GBRbearers using Aggregate Maximum Bit Rates (AMBR) (APN-AMBR: defined per subscriber and Access Point Name, and UE-AMBR: defined per subscriber).

[0013] The QCI is signalled from the CN to the eNB and defines specific characteristics to be applied for all traffic on this bearer. These characteristics may include: resource type (GBR or Non-GBR), priority, Packet Delay Budget (PDB), Packet Error Loss Rate, Maximum Burst Size (for some GBR QCIs) and Data rate Averaging Window (for some GBR QCIs).

[0014] In regard to QoS principles in 5G System (5GS), QoS is managed in 5GS on a per QoS Flow level from the CN. The NG-RAN (i.e. gNB or next generation eNB (ng-eNB)) is responsible for setting up the radio bearers for QoS Flows, radio resource management, and enforcing QoS according to the QoS Flow Profile - over the radio interface in the downlink and over the transport network in the uplink. QoS Flows are identified by a QoS Flow ID (QFI).Figures 4 and 5Figure 4 and Figure 5 give an overview of the QoS framework in 5GS. QoS Flows including a QoS Profile are set up between the User Plane Function (UPF) in the 5GC and the UE. Figure 5 gives an overview of 5GS QoS framework (Figure 5.7.1.5-1 from 3GPP TS 23.501 V17.7.0: The principle for classification and User Plane marking for QoS Flows and mapping to AN Resources).

[0015] 5GS has defined a new term called a "PDU session” that is very similar to a PDN connection in the earlier mobile generations. One difference is that there is normally only a single N3 / NG-U tunnel (a GTP-U tunnel) for each PDU session between the UPF and NG-RAN. This means that the mapping of different traffic / QoS flows to radio bearers is performed in the NG-RAN, for example a radio bearer can carry one or more QoS Flows. A QoS Flow is the finest granularity of QoS differentiation in a PDU session. Each QoS Flow is associated with QoS parameters that are used to enforce the correct traffic forwarding treatment. Each packet belongs to a QoS Flow and one PDU session can carry one or several QoS Flows.

[0016] The mapping of different applications and their corresponding application flows from a specific UE to QoS flows is done by using Packet Filters (PFs). PFs in 5GS are similar to the TFTs in EPS as described above.

[0017] The QoS Flow level QoS Parameters can be either non-dynamic or dynamic. The Non-dynamic case is very similar to the QCI concept in EPS but is referred to as 5G QoS Identifier (5QI). The 5QI is a scalar that is a part of the 5G QoS parameters, and it is used as a reference to standardized (i.e. pre-configured) 5G QoS characteristics that control QoS forwarding treatment for the QoS Flow (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), see 3GPP TS 23.501 clause 5.7.2 and particularly clause 5.7.2.1. This means that the 5QI is signaled from 5GC to NG-RAN and defines the main characteristics for the QoS Flow. The dynamic case is somewhat different as in this case actual 5G QoS characteristics are also signaled from 5GC to NG-RAN. These signaled characteristics may include Priority Level, Packet Delay Budget, Packet Error Rate, Delay Critical, Averaging Window and Maximum Data Burst Volume, see 3GPP TS 23.501 clause 5.7.2.1 and particularly clause 5.7.3.Traffic Classification

[0018] Traffic classification is about how to map different applications and their corresponding application flows from a specific UE to different network resources (e.g. network slices, PDU sessions, QoS flows and Radio Bearers) in both uplink (UL) and downlink (DL).Figure 6

[0019] Such network resources may have separate 5G QoS parameters and characteristics associated to them (see Figure 6). Network I nitiated-Quality of Service (NI-QoS) and UE Route Selection Policy (URSP) are examples of traffic classification mechanisms with different control points. Traffic classification is an essential functionality for any QoS support in mobile networks. It is however important to understand that additional functionality is needed when networks are planned and deployed with QoS support in mind. Examples of additional functionality needed are Service Level Agreement (SLA) and SLA assurance support. Most applications use multiple application flows with different requirements. This puts demands on a mechanism to map individual application flows to the different network resources. In many cases, mapping at application-level will not be enough.

[0020] NI-QoS has been standardized in 3GPP for a long time and is used in commercial operation mainly for Voice over LTE (VoLTE)ZIMS to establish for example dedicated bearers. NI-QoS is an excellent basis for Network Application Programming Interface (API) as it provides dynamic and fine-granular application-flow-level traffic differentiation within a PDU session. NI-QoS is orthogonal to network slicing but can be used in combination with it. The main hurdle with wider adoption of NI-QoS to any applications have been the complicated integration between Communication Service Providers (CSPs) and Application Service Providers (ASPs) (mainly the many-to-many problem with thousands / millions of ASPs and hundreds of CSPs), and all initiatives to encrypt traffic at Over-The-Top (OTT) level over the mobile networks e.g. due to end-user privacy needs.Solution for URSP Traffic Categories (TC)

[0021] Traffic Categories (TC) are needed to communicate QoS needs in a simple and generic way such as low latency and different levels of bandwidth requirements. Traffic categorization is therefore a variant of the traffic classification discussed in the section above, i.e. all applications and application flows indicating the same traffic category from one UE would be classified to the same network resources.

[0022] URSP is standardized by 3GPP for a UE connected to multiple network slices and / or PDU Sessions. The 3GPP standards define multiple different types of traffic descriptors such as Data Network Name (DNN), domain, IP and application descriptors that would in principle allow both application and application flow level mapping to network resources (see 3GPP TS 23.503 chapter 6.6.2). Some device Operating System (OS) vendors have taken their own initiative on interpreting the App-ID field (i.e. the "Application descriptors” in table 6.6.2.1-2 of 3GPP TS 23.503) in the URSP rules. Instead of identifying an application, they put in a TC that the application could specify when setting up the communication. These TCs were not controlled by the operator, instead the operator is supposed to define a matching subscription and map to this with the aid of the TCs. One vendor has defined three categories: "Low Latency”, "High Bandwidth”, and "Reliability”. Another vendor has defined two categories for consumersubscriptions (in addition to the "default” Internet one), these are for "bandwidth” and "low latency. 3GPP Rel-18 contains work to standardize the TCs as part of Connection Capabilities (as defined in table 6.6.2.1 -2 of 3GPP TS 23.503). Amongst others, this activity contains the classes "On demand downlink streaming” (mapping well to "High Bandwidth”), "Real time interactive traffic” (mapping well to "Reliability”), and "Critical communications” (that maps well to "Low Latency”).Figure 7

[0023] Figure 7 shows one example of how URSP TCs are used. The different steps shown in the figure are described below. The steps shown in Figure 7 are as follows:1 . URSP rules are sent to the UE (i.e. UE modem) from the Policy Control Function (PCF) (not explicitly shown in the figure).As an example, the URSP rules contain the following 3 rules:Default / Best Effort: when no other rules match, pointing to the DNN Selection field in the Route Selection component with the value: "Internet PDU Session, best effort”Low Latency: URSP Traffic Category "LOW LATENCY”, pointing to the DNN Selection field in the Route Selection component with the value: "Internet PDU Session, low latency”Background: URSP Traffic Category "BACKGROUND”, pointing to the DNN Selection field in the Route Selection component with the value: "Internet PDU Session, background”2. URSP rules are read into the OS URSP rule cache.3. App Client-X is requesting a socket and indicates also a specific Traffic Category.As an example, the indicated Traffic Category is "LOW LATENCY”.4. OS parses the URSP rules in the URSP rule cache.5. OS request based on the parsed URSP rules the modem to create the relevant PDU session for the requested Traffic Category based on the parsed URSP rules (if needed i.e. when that PDU Session is not already established).Note that in Figure 7, 3 different PDU sessions are already shown as established.As an example, the relevant PDU session is "Internet PDU Session, low latency”.6. The socket requested by App Client-X is bound to the source IP for the PDU Session associated with the requested Traffic Category and the socket is ready for use.Figure 8

[0024] Figure 8 shows how three different URSP TCs are used by the App Client-X. The App Client-X has performed the steps in Figure 7 for three different application flows, each requesting a specific Traffic Category. The three application flows are sent over three different PDU Sessions, and with the possibility to associate separate QoS for these.Main Principles for Service Exposure, Related Network APIs and Aggregators

[0025] Service exposure, sometimes also called as network exposure, will be critical to the success of solutions that rely on edge computing, network slicing, and distributed cloud. The key benefit of service exposure in this respect is that it makes it possible to use Application Programming Interfaces (APIs) to connect automation flows and processes across organizational, technology, business-to-business (B2B) and other borders, thereby avoiding costly manual handling.

[0026] There are three main types of service exposure in a telecom environment:• Network monitoringExamples include network publishing information as real-time status, event streams, reports, statistics, analytic insights and so on• Network control and configurationInvolves requesting control services that directly interact with the network traffic or request configuration changes.• Payload interfacesExamples include messaging and local breakout to interact with the data streams through local breakout for optimizationFigure 9

[0027] The functional architecture for service exposure is built around four customer scenarios (see the upper part of Figure 9). In the case of internal consumers, applications for monitoring, optimization, and internal information sharing operate under the control and ownership of the enterprise itself. In the case of B2C, consumers directly use services via web or app support. B2C examples include call control and self-service management of preferences and subscriptions. The B2B scenario consists of partners that use services such as messaging and loT communication to support their business. The B2B2X scenario is made up of more complex value chains such as mobile virtual network operators, web scale, gaming, automotive and telco cloud through web-scale APIs.

[0028] The functional architecture for service exposure is divided into three layers that each act as a framework for the realization. Domain-specific functionality and knowledge are applied and added to the framework as configurations, scripts, plug-ins, models and so on. For example, the access control framework delivers the building blocks for specializing the access controls for a specific area.

[0029] The abstraction and resource layer is responsible for communicating with the assets. If some assets are located outside the enterprise - at a supplier or partner facility in a federation scenario, for example - B2B functionality will also be included in this layer.

[0030] The business and service logic layer is responsible for transformation and composition - that is, when there is a need to raise the abstraction level of a service to create combined services.

[0031] The exposed service execution APIs and exposed management layer is responsible for making the service discoverable and reachable for the consumer. This is done through the API gateway, with the support of portal, SDK and API management.Figure 10

[0032] Aggregators, see Figure 10, are important to accelerate the development and availability of network services and APIs, onboarding CSPs and exposing APIs to application developers and ASPs (Application Service Providers) as well as to enterprises. An aggregator consumes services from the onboarded CSPs, aggregates them, and exposes services over APIs towards developers and enterprises. This enables multiple potentially larger communities including, e.g. developers and API consumers to start leveraging these more advanced CSP APIs.

[0033] Examples of early services are predicted to be QoS handling, increased capacity for limited periods or a simplified but fully adequate identification service.

[0034] The A, C and Z interfaces illustrated in Figure 10 are:Summary

[0035] Systems and methods related to dynamic User Equipment (UE) Route Selection Policy (URSP) Traffic Categories (TCs) are disclosed. In one embodiment, a method performed by one or more network nodes of a mobile network comprises any one or more of the following: receiving, from an application server directly or via an aggregator, a request to activate a set of requested Quality of Service (QoS) levels for a certain UE, the set of requested QoS levels comprising one or more requested QoS levels; determining that a requested QoS level from among the set of requested QoS levels can be served with a new performance level; selecting a new URSP TC that is to be mapped to the new performance level for the certain UE; and sending one or more URSP rules to the certain UE, the one or more URSP rules comprising at least one URSP rule that comprises the URSP TC that is mapped to the new performance level for the certain UE.

[0036] In one embodiment, the method further comprises sending a response to the application server directly or via the aggregator, the response comprising, for each requested QoS level in the set of requested QoS levels, a URSP TC mapped to the requested QoS level.

[0037] In one embodiment, each requested QoS level from among the set of requested QoS levels is defined in generic terms.

[0038] In one embodiment, at least one requested QoS level from among the set of requested QoS levels is defined in generic terms.

[0039] In one embodiment, at least one requested QoS level from among the set of requested QoS levels indicated via a predefined identifier.

[0040] In one embodiment, receiving the request to activate the set of QoS levels comprises receiving the request to activate the set of QoS levels at a network exposure function of the mobile network via an Application Programming Interface (API).

[0041] Corresponding embodiments of a system comprising one or more network nodes for a mobile network are also disclosed. In one embodiment, the one or more network nodes comprise any one or more of the following: a PCF, an SMF, an AMF, a UPF, a RAN node, and a network exposure function.

[0042] Embodiments of a method performed by an application client at a UE are also disclosed. In one embodiment, a method performed by an application client at a UE comprises one or more of the following: obtaining (e.g., from an application server), information about a set of QoS levels and corresponding URSP TCs, wherein at least one QoS level from the set and the corresponding URSP TC corresponds to a new performance level; and using the obtained information.Brief Description of the Drawings

[0043] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure. Figure 1 shows the 5G System architecture using service-based representation as described in 3GPP TS 23.501 V18.3.0;Figure 2 shows the internal architecture for a gNodeB (gNB), i.e. a base station supporting the New Radio (NR) Radio Access Technology (RAT) in the (R)AN of Figure 1;Figure 3 gives an overview of the QoS framework in EPS;Figure 4 provides an overview of 5GS QoS framework;Figure 5 provides an overview of 5GS QoS framework (Figure 5.7.1.5-1 from 3GPP TS 23.501 V18.3.0: The principle for classification and User Plane marking for QoS Flows and mapping to AN Resources);Figure 6 illustrates traffic classification;Figure 7 illustrates usage of URSP TCs;Figure 8 illustrates application usage of multiple URSP TCs;Figure 9 illustrates a network exposure functional view;Figure 10 illustrates aggregator-related interfaces;Figure 11 illustrates an exemplary system in which embodiments of the present disclosure may be implemented;Figure 12 illustrates a procedure for activation of a new innovative performance level, in accordance with an embodiment of the present disclosure;Figures 13 and 14 illustrate example embodiments of a network node in which aspects of embodiments of the present disclosure may be implemented; andFigure 15 illustrates an example embodiment of a wireless communication device (e.g., a UE) in which aspects of embodiments of the present disclosure may be implemented.Detailed Description

[0044] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0045] Radio Node: As used herein, a "radio node” is either a radio access node or a wireless communication device.

[0046] Radio Access Node: As used herein, a "radio access node” or "radio network node” or "radio access network node” is any node in a Radio Access Network (RAN) of a mobile network that operates to wirelessly transmit and / or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

[0047] Core Network Node: As used herein, a "core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0048] Communication Device: As used herein, a "communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer- comprised, or vehicle-mounted mobile device, enabled to communicate voice and / or data via a wireless or wireline connection.

[0049] Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (I ,e. , is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smartphone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and / or data via a wireless connection.

[0050] Network Node: As used herein, a "network node” is any node that is either part of the RAN or the core network of a mobile network.

[0051] Note that the description given herein focuses on a 3GPP mobile network and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP mobile network.

[0052] There currently exist certain problems. The UE Route Selection Policy (URSP) technology is an excellent way for the Communication Service Providers (CSPs) to start offering different performance levels to their customers, e.g. consumers (Business-to-Consumer (B2C)), enterprises (Business-to-Business (B2B)), or also as Business-to-Business-to-Everyone (B2B2X). The currently known solutions are based on pre-defined, but device vendor specific, URSP Traffic Categories (TCs). The currently known URSP TCs can also be seen as static and are well-known for the different players. For example, a device vendor may have defined three Traffic Categories as following: "Low Latency”, "High Bandwidth”, and "Reliability” (see Background section above).

[0053] The CSPs can sell the different performance levels either as part of subscriptions, or as part of more dynamic one-time activation of (a) specific performance level(s). For the URSP technology, the subscription play means that a set of URSP TCs are included in the subscription. The one-time activation is instead about dynamic activation of (a) specific URSP TC(s) for a specific subscriber, activated with the network APIs (e.g., see the network APIs described in the Background section above).

[0054] The known solutions can be improved in a more dynamic way of defining operator specific URSP TCs, and therefore allowing the CSPs to innovate in how they are offering the different performance levels to their customers. A natural way to use these dynamic URSP TCs will be via the network APIs.

[0055] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. The proposed solution enables the CSPs to dynamically define new performance levels and use these based on the URSP technology. For each new performance level, at least one new URSP TC is defined. The applications request, via a network API, different levels of Quality of Service (CoS) for the different application flows from the CSP network, either directly or via an aggregator. The CSP network maps each requested CoS level to a new or existing performance level and assigns either a new URSP TC or existing URSP TC for each requested CoS level. Information about the URSP TC for each requested level of CoS is provided to the application client (exactly how depends on which part of the application triggered the CoS request initially). The CSPnetwork sends the updated URSP rules to the relevant UE. The application clients in the UE start using the URSP TCs for their application flows.

[0056] Embodiments of the present disclosure relate to a CSP dynamically defining new performance levels (e.g., new QoS levels) and activating these based on URSP and network APIs. For each new performance level, a new URSP TC is defined. For an existing performance level, an existing URSP TC may be indicated. The URSP TCs are returned to the application clients as part of the network APIs requesting different levels of QoS for the different application flows from the CSP network, either directly or via an aggregator.

[0057] While not limited to or by any particular advantage, embodiments of the present disclosure may provide a number of advantages over existing technology. These advantages may include any one or more of the following. The main advantage is that the embodiments of the solution disclosed herein may enable CSPs to innovate with new performance levels based on the URSP technology that is starting to happen in the CSP networks now. This means that a single base technology (URSP and network slicing) can be used for both well-known and static performance levels, and new and innovative performance levels.

[0058] Now, the description will turn to a more detailed description of some example embodiments of the present disclosure.Figure 11

[0059] Figure 11 illustrates one example of a system 1100 in which embodiments of the present disclosure may be implemented. As illustrated, the system 1100 includes UE 1102, mobile network 1104 (also referred to herein as a CSP network), aggregator 1106 (optional), and Applications (App-1 to App-x), which are shown as Application Clients 1108-1 to 1108-x (also referred to herein as App Client 1 to App Client x) in the UE 1102 and Application Servers 1110-1 to 1110-x (also referred to herein as App Server 1 to App Server x). Note that the Application Clients 1108-1 to 1108-x are generally referred to herein collectively as Application Clients 1108 and individually as Application Client 1108. Likewise, the Application Servers 1110-1 to 1110-x are generally referred to herein collectively as Application Servers 1110 and individually as Application Server 1110. In this example, the Application Servers 1110 are connected to the mobile network 1104 via the aggregator 1106, to request different levels of QoS (i.e., different QoS levels) from the mobile network 1104. The aggregator 1106 is to be seen as an optional entity, and the Application Servers 1110 could alternatively be connected directly to the mobile network 1104. It will also be described that the Application Clients 1108 can be directly connected to the mobile network 1104.

[0060] The UE 1102 is shown as including three main parts: Applications layer 1112, an Operating System (OS) 1114, and a modem 1116. The Applications layer 1112 is exemplified with the Application Clients 1108-1 to 1108-x. The OS 1114 is exemplified with a socket layer 1118 for communication with URSP cache 1120 and Transmission Control Protocol (TCP) / lnternet Protocol (IP) stack 1122. The modem 1116 is exemplified with a driver 1124 for the mobile network related communication (e.g., EPS related communication in the case of the mobile network 1104 being an EPS or 5GS related communication in the case of the mobile network 1104 being a 5GS), with the main part for the present disclosure being a URSP database (DB) 1126.

[0061] The mobile network 1104 includes a Radio Access Network (RAN) 1128, a Packet Core 1130 (also referred to herein as a core network), and a Network Exposure 1132 (e.g., a Network Exposure Function (NEF)). In this example, the mobile network 1104 is configured to support four different levels of QoS in different Protocol Data Unit (PDU) sessions: new innovative QoS level (in bold outline) for a new performance level, a best effort QoS level, a low latency QoS level, and a background QoS level. The last three QoS levels are seen as using static and well- known URSP TCs while the first QoS level (i.e., the new innovative level (in bold outline)) is the main focus of the present disclosure. The CSP defines the new performance level in the mobile network 1104. This includes for example dimensioning and configuration of all needed nodes in the CSP network including the needed RAN, transport, and packet core resources. The new performance level may differ from the existing known performance levels in any of QoS characteristics described earlier. Examples of these include the following characteristics in UL and DL: bitrate, packet delays, packet loss, bounded latency. Once the new performance level is created in the CSP network, the application's requests on QoS may be mapped to this new performance level. The CSP defines a new URSP TC for the new performance level. This enables that also the known URSP TCs, e.g. low latency, background, can also still be used in the CSP network, simultaneously with the new URSP TC. Note that, while only one new innovative QoS level (and thus one corresponding URSP TC) is shown in Figure 11 and used in much of the description herein, there may be any number of one or more new performance / QoS levels with corresponding URSP TCs. The four PDU sessions are all shown in Figure 11 as being established for the UE 1102 i.e. kind of showing the final active state. This is only due to simplicity and the different steps describing embodiments of the present disclosure will show for example how and when the PDU session for the new innovative level is established. In the Packet Core 1130, some key parts are the connection to the network exposure 1132, AMF 1134, PCF 1136, SMF 1138, and UPFs 1140 (which may more specifically be referred to as UPFs 1140-1 to 1140-X).

[0062] The aggregator 1106 can be placed between the mobile network(s) 1104 and the Application Servers 1110. The key functionality of the aggregator 1106 is to aggregate the mobile network exposed network APIs. The aggregator 1106 can also solve the many-to-many problem with thousands / millions of ASPs and hundreds of CSPs, as each Application Server 1110 and mobile network 1104 need to only be connected and integrated to the aggregator 1106.Figure 12

[0063] Embodiments of the present disclosure relate to the Network API part for activation of existing performance level(s) and / or new innovative performance level (s). In this regard, Figure 12 illustrates a procedure by which, in this example, the application server 1110-2 requests activation of QoS for multiple application flows, in accordance with one example embodiment of the present disclosure.

[0064] The steps of the procedure of Figure 12 are as follows:1 . The Application-specific logic, e.g. in the Application Server 1110-2, is aware of the needed traffic and QoS characteristics for the set of application flows that are part of the application.2. The Application Server 1110-2 requests activation of the needed QoS levels from the Aggregator 1106. In other words, the Application Server 1110-2 sends a request to the Aggregator 1106 for activation of theneeded QoS levels. The request contains a UE identifier to identify the UE 1102 for which the request is provided. Examples of the UE identifier include, but are not limited to, International Mobile Subscriber Identifier (I MSI), Subscription Permanent Identifier (SUPI), Mobile Station (MS) International PSTN / ISDN Number (MSISDN), and / or an IP-address. The request also contains information that indicates or defines a set of requested QoS levels, i.e. one requested QoS level for each needed QoS level (e.g., one requested QoS level for the QoS needs for each application flow). The requested QoS level is, in one embodiment, in the API described in generic terms (e.g. Low Latency or High Bandwidth), but when a specific Service Level Agreement (SLA) has been given it may be a specific identifier for the QoS level.In one embodiment, Step 2 also includes authentication and identification of the application in question.3. The Aggregator 1106 identifies the mobile network 1104 where the UE 1102 in question (i.e., the UE 1102 identified by the UE identifier included in the request of Step 2) is connected to based on the received UE identifier. The Aggregator 1106 forwards the received request to the Network Exposure 1132 in the identified mobile network 1104. To preserve end user privacy, the aggregator 1106 may not forward, or may decide to not forward, any information about the application in question. Note that, in an alternative embodiment where the Aggregator 1106 is not used, the Application Server 1110-2 sends the request of Step 2 directly to the mobile network 1104 (e.g., directly to the network exposure 1132 of the mobile network 1104).4. The mobile network 1104 determines if any of the requested QoS levels from the set of requested QoS levels can be served with any of the preconfigured new performance levels for the UE 1102. The UE 1102 is identified with the received UE identifier. The determining may contain verifying that the subscription on the UE 1102 is allowed to activate a new performance level. The determining may also contain comparing the QoS characteristics in the requested QoS levels from the set of requested QoS levels with the QoS characteristics of the new performance levels. Examples of these QoS characteristics may include the following characteristics in UL and DL: bitrate, packet delays, packet loss, bounded latency. The mobile network 1104 identifies that one of the requested QoS levels can be served with the new innovative performance level. The mobile network 1104 selects a new URSP TC that is mapped to the new innovative performance level for this UE 1102. In another embodiment, the new URSP TC is defined already when the new performance level is created in the CSP network. The actions of Step 4 may be performed by, e.g., the PCF 1136, the SMF 1138, the AMF 1134, the network exposure function 1132, or any combination thereof.5. The mobile network 1104 triggers the sending of updated URSP rules to the UE 1102. The new URSP TC is included in the updated URSP rules. This part uses the existing and known way for how to send URSP rules to any UE.6. The mobile network 1102 replies to the request received in step 3 from the Aggregator 1106. This reply contains the UE identifier and, for each approved QoS level, the combination of [Requested QoS level, new or existing URSP TC] parameters.7. The aggregator 1106 forwards the reply received from the mobile network 1102 to the Application Server 1110-2.8. The Application Server 1110-2 informs the Application Client 1108-2 about the combination of [Requested QoS level, new or existing URSP TC] parameters. This step is typically application specific signaling.9. (Optional) The UE 1102 uses the URSP rules (including the new URSP TC(s)). For example, as described below, the UE 1102 may use the URSP rules in accordance with known principles. For instance,• The Application Client 1108, e.g. the Application Client 1108-2, in the UE 1102 has become aware of the new URSP TC to be used for the new QoS level, supported via the new performance level in the CSP network (e.g., as a result of step 8).• The Application Client 1108-2 requests a socket for the new QoS level and indicates the new URSP TC.• OS 1114 at the UE 1102 parses the URSP rules in the URSP rule cache 1120.• OS 1114 requests, based on the parsed URSP rules, the modem 1116 to create the relevant PD U session for the requested Traffic Category based on the parsed URSP rules (if needed i.e. when that PDU Session is not already established). The new PDU session for the new innovative performance level is created.• The socket requested by the Application Client 1108-2 for the new QoS level is bound to the source IP for the PDU Session associated with the new URSP TC and the socket is ready for use by the Application Client 1108-2.

[0065] The above logic is based on the Application Server 1110-2 initiating the requests for the activation of the needed QoS levels. Other alternatives are also possible, without changing the main principles of the present disclosure:• The baseline idea described as network side APIs can also be applied to UE-side APIs. This means that an Application Client 1108, e.g. the Application Client 1108-2, would instead access Network APIs directly or via another entity. The Application Client 1108 would then directly receive information about the new and existing URSP TCs for the different QoS needs.• In the direct access to the Network APIs, the Application Client 1108-2 would send the request directly to the Network Exposure 1132.• In still another example of direct access to the Network APIs, the Application Client 1108-2 would send the request directly to a specific functionality in the UE Modem-Driver that would contact the mobile network 1104 using NAS (Non Access Stratum) signaling, e.g. directly to the SMF 1138 or PCF 1136.• The other entity can be any network side functionality that has access to the mobile network APIs, including the Application Server(s) 1110 or any possible aggregator 1106. As an example, the initial trigger can be from the Application Client 1108-2 to the Application Server 1110-2, for example as part of the above Step 1 of Figure 12, or as a step before Step 1 of Figure 12.• The aggregator 1106 shown between the mobile network(s) 1104 and the Application Servers 1110 are to be seen as an optional arrangement (as also written earlier). The described functionality can also be used for the case when no such aggregators 1106 are included, i.e. when the Application Servers 1110 would be directly connected to the mobile network(s) 1104.

[0066] The use of the URSP rules at the UE 1102 is according to the known URSP TC principles. To summarize:• The Application Client 1108, e.g. the Application Client 1108-2, in the UE 1102 has become aware of the new URSP TC to be used for the new QoS level, supported via the new performance level in the CSP network (e.g., as a result of the procedure of Figure 12).• The Application Client 1108-2 requests a socket for the new QoS level and indicates the new URSP TC.• OS 1114 at the UE 1102 parses the URSP rules in the URSP rule cache 1120.• OS 1114 requests, based on the parsed URSP rules, the modem 1116 to create the relevant PDU session for the requested Traffic Category based on the parsed URSP rules (if needed i.e. when that PDU Session is not already established). The new PDU session for the new innovative performance level is created.• The socket requested by the Application Client 1108-2 for the new QoS level is bound to the source IP for the PDU Session associated with the new URSP TC and the socket is ready for use by the Application Client 1108-2.Figure 13

[0067] Figure 13 is a schematic block diagram of a network node 1300 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 1300 may be, for example, a network node that implements the functionality of the Application Server 1110 (e.g., Application Server 1110-2), a network node that implements the functionality of the aggregator 1106, a network node that implements the functionality of the Network Exposure 1132, a network node that implements the functionality of a network function in the Packet Core 1130 (e.g., the PCF 1136, SMF 1138, or UPF 1140), or the like. As illustrated, the network node 1300 includes one or more processors 1304 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1306, and a network interface 1308. The one or more processors 1304 are also referred to herein as processing circuitry. The one or more processors 1304 operate to provide one or more functions of the network node 1300 as described herein (e.g., one or more functions of the Application Server 1412, the VPN Server 1408, the Aggregator 1406, the Network Exposure function 1432, a network function in the Packet Core 1430 (e.g., the PCF 1435 or the UPF), or the like, as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1306 and executed by the one or more processors 1304.Figure 14

[0068] Figure 14 is a schematic block diagram that illustrates a virtualized embodiment of the network node 1300 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a "virtualized” network node is an implementation of the network node 1300 in which at least a portion of the functionality of the network node 1300 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, the network node 1300 includes one or more processing nodes 1400 coupled to or included as part of a network(s) 1402. Each processingnode 1400 includes one or more processors 1404 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1406, and a network interface 1408. In this example, functions 1410 of the network node 1300 described herein (e.g., one or more functions of the Application Server 1110, the Aggregator 1106, the Network Exposure function 1132, a network function in the Packet Core 1130 (e.g., the PCF 1136, the SMF 1138, or the UPF 1140), or the like, as described herein) are implemented at the one or more processing nodes 1400 or distributed across the two or more processing nodes 1400 in any desired manner. In some particular embodiments, some or all of the functions 1410 of the network node 1300 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1400.

[0069] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 1300 or a node (e.g., a processing node 1400) implementing one or more of the functions 1410 of the network node 1300 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).Figure 15

[0070] Figure 15 is a schematic block diagram of a wireless communication device 1500 (e.g., the UE 1102) according to some embodiments of the present disclosure. As illustrated, the wireless communication device 1500 includes one or more processors 1502 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1504, and one or more transceivers 1506 each including one or more transmitters 1508 and one or more receivers 1510 coupled to one or more antennas 1512. The transceiver(s) 1506 includes radio-front end circuitry connected to the antenna(s) 1512 that is configured to condition signals communicated between the antenna(s) 1512 and the processor(s) 1502, as will be appreciated by one of ordinary skill in the art. The processors 1502 are also referred to herein as processing circuitry. The transceivers 1506 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 1500 (or UE) (e.g., the functionality of the UE 1102 such as, e.g., that of one or more of the Application Clients 1108, the functionality of the OS 1114, the functionality of the modem 1116, the functionality of the driver 1124, or the like) may be fully or partially implemented in software that is, e.g., stored in the memory 1504 and executed by the processor(s) 1502. Note that the wireless communication device 1500 may include additional components not illustrated in Figure 15 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the wireless communication device 1500 and / or allowing output of information from the wireless communication device 1500), a power supply (e.g., a battery and associated power circuitry), etc.

[0071] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 1500 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising theaforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0072] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0073] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).EmbodimentsSome of the embodiments that have been described above may be summarized in the following manner:1 . A method performed by one or more network nodes (1132; 1138, 1136; 1140; 1128) of a mobile network (1104), the method comprising any one or more of the following: receiving (Fig. 12, step 3) a request sent by an application server (1110), possibly via an aggregator (1106), to activate a set of requested Quality of Service, QoS, levels for a certain User Equipment, UE, (1102), the set of requested QoS levels comprising one or more requested QoS levels; determining (Fig. 12, step 4) that a requested QoS level from among the set of requested QoS levels can be served with a new performance level; selecting (Fig. 12, step 4) a new User Equipment, UE, Route Selection Policy, URSP, Traffic Category, TC, that is to be mapped to the new performance level for the certain UE (1102); sending (Fig. 12, step 5) one or more URSP rules to the certain UE (1102), the one or more URSP rules comprising at least one URSP rule that comprises the URSP TC that is mapped to the new performance level for the certain UE (1102).2. The method of embodiment 1, further comprising sending (Fig. 12, step 6) a response to the application server (1110), possibly via the aggregator (1106), the response comprising, for each requested QoS level in the set of requested QoS levels, a URSP TC mapped to the requested QoS level.3. The method of embodiment 1 or 2, wherein each requested QoS level from among the set of requested QoS levels is defined in generic terms.4. The method of embodiment 1 or 2, wherein at least one requested QoS level from among the set of requested QoS levels is defined in generic terms.5. The method of embodiment 1 or 2, wherein at least one requested QoS level from among the set of requested QoS levels indicated via a predefined identifier.6. The method of any of embodiments 1 to 5, wherein receiving (Fig. 12, step 3) the request to activate the set of QoS levels comprises receiving (Fig. 12, step 3) the request to activate the set of QoS levels at a network exposure function (1132) of the mobile network (1104) via an Application Programming Interface, API.7. A system comprising one or more network nodes (1132; 1138, 1136; 1140; 1128) for a mobile network (1104), the system adapted to perform the method of any of embodiments 1 to 6.8. The system of embodiment 7, wherein the one or more network nodes comprise any one or more of the following: a PCF, an SMF, an AMF, a UPF, a RAN node, and a network exposure function.9. A method performed by an application client (1108-2) at a User Equipment, UE, (1102), the method comprising any one or more of the following: obtaining (Fig. 12, step 8) (e.g., from an application server (1110)), information about a set of Quality of Service, QoS, levels and corresponding UE Route Selection Policy, URSP, Traffic Categories, TCs, wherein at least one QoS level from the set and the corresponding URSP TC corresponds to a new performance level; using (Fig. 12, step 9) the obtained information.

Claims

ClaimsWhat is claimed is:1 . A method performed by one or more network nodes (1132; 1138, 1136; 1140; 1128) of a mobile network (1104), the method comprising any one or more of the following: receiving (Fig. 12, step 3) a request sent by an application server (1110), possibly via an aggregator (1106), to activate a set of requested Quality of Service, QoS, levels for a certain User Equipment, UE, (1102), the set of requested QoS levels comprising one or more requested QoS levels; determining (Fig. 12, step 4) that a requested QoS level from among the set of requested QoS levels can be served with a new performance level; selecting (Fig. 12, step 4) a new User Equipment, UE, Route Selection Policy, URSP, Traffic Category, TC, that is to be mapped to the new performance level for the certain UE (1102); sending (Fig. 12, step 5) one or more URSP rules to the certain UE (1102), the one or more URSP rules comprising at least one URSP rule that comprises the URSP TC that is mapped to the new performance level for the certain UE (1102).

2. The method of claim 1, further comprising sending (Fig. 12, step 6) a response to the application server (1110), possibly via the aggregator (1106), the response comprising, for each requested QoS level in the set of requested QoS levels, a URSP TC mapped to the requested QoS level.

3. The method of claim 1 or 2, wherein each requested QoS level from among the set of requested QoS levels is defined in generic terms.

4. The method of claim 1 or 2, wherein at least one requested QoS level from among the set of requested QoS levels is defined in generic terms.

5. The method of claim 1 or 2, wherein at least one requested QoS level from among the set of requested QoS levels indicated via a predefined identifier.

6. The method of any one of claim 1 to 5, wherein receiving (Fig. 12, step 3) the request to activate the set of QoS levels comprises receiving (Fig. 12, step 3) the request to activate the set of QoS levels at a network exposure function (1132) of the mobile network (1104) via an Application Programming Interface, API.

7. A system comprising one or more network nodes (1132; 1138, 1136; 1140; 1128) for a mobile network (1104), the system adapted to perform the method of any of embodiments 1 to 6.

8. The system of claim 7, wherein the one or more network nodes comprise any one or more of the following: a PCF, an SMF, an AMF, a UPF, a RAN node, and a network exposure function.

9. A method performed by an application client (1108-2) at a User Equipment, UE, (1102), the method comprising any one or more of the following: obtaining (Fig. 12, step 8) (e.g., from an application server (1110)), information about a set of Quality of Service, QoS, levels and corresponding UE Route Selection Policy, URSP, Traffic Categories, TCs, wherein at least one QoS level from the set and the corresponding URSP TC corresponds to a new performance level; using (Fig. 12, step 9) the obtained information.

Images