QoS LEVEL INDICATORS (E.G., VIA IPv6 FLOW LABELS) IN A QoS API, AND USE THEREOF FOR INDICATING QoS LEVELS OF APPLICATION FLOW PACKETS FOR DIFFERENT APPLICATION FLOWS OF AN APPLICATION

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

QoS LEVEL INDICATORS (E.G., VIA IPv6 FLOW LABELS) INA QoS API, AND USE THEREOF FOR INDICATING QoS LEVELS OF APPLICATION FLOW PACKETS FOR DIFFERENT APPLICATION FLOWS OF AN APPLICATIONTechnical Field

[0001] The present disclosure relates to a mobile network and, more specifically, to enabling different Quality of Service (QoS) levels within a mobile network for different application flows of an application for which application flow traffic is communicated over the mobile network.Background

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

[0003] This background is structured as following:• Section 1 describes background information about the 3GPP 5G system;• Section 2 describes QoS principles in 3GPP 4G and 5G systems;• Section 3 describes Traffic Classification;• Section 4 describes Virtual Private Network (VPN) solutions;• Section 5 describes the main principles of Apple Private Relay, as an example of a VPN solution;• Section 6 describes the main principles for Service Exposure, Aggregators, and related Network Application Programming Interfaces (APIs); and• Section 7 introduces Internet Protocol version 6 (IPv6) packets and the IPv6 Flow Label.1 5G Background

[0004] Standardization work has been ongoing on the 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

[0005] Figure 1 shows the 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

[0006] 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 , 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.2 QoS Principles2.1 QoS in Evolved Packet System (EPS)

[0007] QoS is managed in the 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

[0008] 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 UE and the eNB for the uplink.

[0009] Many services and subscribers share the same radio and network resources. Real-time services (voice, video etc.) share the same resources as non-real-time services (Internet browsing, file download, etc.). One challenge in this area is how to ensure QoS (bit rates, packet delays, packet loss) 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:• Traffic Separation: Different traffic types receive different treatment (queuing, etc.) in network;• 3GPP provides for both relative QoS and absolute QoS (using Guaranteed Bit Rates);• GBR (Guaranteed Bit Rate) based admission control is used to reserve resources before traffic is admitted into the network or rejected otherwise;• Policy (PCC) may determine what treatment to apply to the traffic streams.

[0010] 3GPP defines the concept of a PDN, i.e., a Packet Data Network. 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, where each name is defined in a string referred to as an Access Point Name (APN). The PDN GW (PGW) is a gateway towards one or more PDNs. A User Equipment (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.

[0011] Every PDN connection consists of one or more bearers. See 3GPP 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 identifier (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.

[0012] 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 awildcard. An n-tuple is also known as an IP flow. An example of an n-tuple is a 5-tuple. An example of a 5-tuple is (dst IP=83.50.20.110, src IP=145.45.68.201 , dst port=80, src port=*, prot=TCP). This 5-tuple defines a source and destination IP address, a source and destination port, and a protocol. The source port is a wildcard. Traffic matching this 5-tuple filter would be all Transmission Control Protocol (TCP) traffic from IP=145.45.68.201 to IP=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.

[0013] 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-GBR bearers using Aggregate Maximum Bit Rates (AMBR) (APN-AMBR defined per subscriber and Access Point Name, and UE-AMBR defined per subscriber).

[0014] 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).2.2 QoS Principles in the 5G Systems (5GS)

[0015] 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 5

[0016] Figure 4 and 5 give an overview of the QoS framework in 5GS (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). QoS Flows including a QoS Profile are set up between the User Plane Function (UPF) in the 5GC and the UE.

[0017] 5GS has defined a new term called a Protocol Data Unit (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 General Packet Radio Service (GPRS) Tunneling Protocol (GTP) User plane, i.e., 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.

[0018] 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 in Section 2.1.

[0019] 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 value 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.2.3 Reflective QoS

[0020] Reflective QoS exists on two different levels in the 5GS as standardized today. Both levels are based on the UE side reflecting the actions taken by the network.

[0021] Non-Access Stratum (NAS) Level: Map uplink (UL) user plane traffic flows to QoS Flows without packet core network provided QoS rules (5-tuple to QFI). The solution is based on that the network first performs mapping from application traffic flows to QoS Flows. The UE derives QoS rules for the UL based on received downlink (DL) traffic. The DL traffic is received associated with a QFI. The QoS rules created contain one UL Packet filter and the QFI. The solution applies both for IP and Ethernet based PDU sessions. For the IP PDU sessions, the UL QoS rules derivation is defined for IP, TCP, User Datagram Protocol (UDP), and Encapsulating Security Payload (ESP) based protocols and 5-tuple kind of logic. UE stores the derived QoS rule containing UL Packet Filter and QFI and applies the derived QoS rule later for UL traffic (in case there is match in the UL Packet Filter).

[0022] Access Stratum (AS) Level: Map UL QoS Flows to Radio bearers without RAN provided mapping rules (QFI to RB). RAN performs mapping of QoS Flows to Radio Bearers in the downlink. This is based on information received in the control plane from the Session Management Function (SMF) in the 5GC (e.g., 5QI, ARP, etc.), information configured in the RAN, and the QFI received from the UPF for each user plane packet. RAN may signal the mapping of QoS Flows to Radio Bearers for the UE for usage in the UL. In addition to the signaled mapping, an alternative has been standardized as the UE reflecting the RAN provided DL mapping in the UL. In this case, the UE monitors the QFIs received on each Radio Bearer in the downlink, stores the mapping and then applies it for uplink traffic.3 Traffic ClassificationFigure 6

[0023] 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). Such network resources may have separate 5G QoS parameters and characteristics associated to them (see Figure 6).

[0024] 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.

[0025] NI-QoS has been standardized in 3GPP for a long time and is used in commercial operation mainly for Voice over LTE (VoLTE)ZIMS. NI-QoS is an excellent basis for Network 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 has 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 the Over-The-Top (OTT) level over the mobile networks, e.g. due to end-user privacy needs.4 Virtual Private Network (VPN) solutions

[0026] A Virtual Private Network (VPN) extends a private network across a public network and enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network. The benefits of a VPN include increases in functionality, security, and management of the private network. It provides access to resources that are inaccessible on the public network and is typically used for remote workers. Encryption is common, although not an inherent part of a VPN connection. A VPN is created by establishing a virtual point-to-point connection through the use of dedicated circuits or with tunneling protocols over existing networks. A VPN available from the public Internet can provide some of the benefits of a Wide Area Network (WAN). From a user perspective, the resources available within the private network can be accessed remotely.5 Main Principles of Apple Private Relay (as an example of a VPN solution)Figure 7

[0027] Apple Private Relay is used here as an example of a VPN solution. Private Relay is a new internet privacy service that's built into Apple's iCloud service, allowing users to connect to and browse the web in a moresecure and private way (see Figure 7). When browsing with Safari, Private Relay ensures all traffic leaving a user's device is encrypted, so no one between the user and the website they are visiting can access and read the traffic, not even Apple or the user's network provider. All the user's requests are then sent through two separate internet relays. The first assigns the user an anonymous IP address that maps to their region but not their actual location. The second decrypts the web address they want to visit and forwards them to their destination. This separation of information protects the user's privacy because no single entity can identify both who a user is and which sites they visit.

[0028] Figure 8

[0029] Figure 8 shows Private Relay in more detail. For example, Figure 8 shows the encrypted ingress tunnel between the UE and the Ingress Proxy. The Ingress Proxy will allocate a new IP address for the UE and thereby hide the real UE IP address both from the Egress Proxy and from the Application Servers. The encrypted Egress tunnel is between the UE and the Egress Proxy. The Egress proxy decrypts the destination Application Server (or web server) name and address. This means that the Ingress Proxy is not aware of the destination of the UE traffic. Finally, an application flow is shown between an App Client-X on the UE and an App Server-X. In the application flow, App Server-X communicates unencrypted with Egress Proxy that in turn uses the encrypted tunnel to further communicate with the UE via the Ingress Proxy. This means that the Ingress Proxy is not aware of the App Server-X name and address, since that is encrypted by the Egress Proxy.6 Main Principles for Service Exposure, Related Network APIs, and Aggregators

[0030] Service 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 processes across organizational, technology, business- to-business (B2B) and other borders, thereby avoiding costly manual handling.

[0031] There are three main types of service exposure in a telecom environment:• Network monitoringExamples include network publishing information as real-time statuses, 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.• Pay load interfacesExamples include messaging and local breakout to interact with the data streams through local breakout for optimization.

[0032] The functional architecture for service exposure is built around four customer scenarios. 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 business-to-consumer (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 business-to-business-to-anyone (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.

[0033] 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.

[0034] The abstraction and resource layer are 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.

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

[0036] The exposed service execution APIs and exposed management layer are 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.

[0037] An aggregator consumes services from the onboarded CSPs, aggregates them, and exposes services over APIs towards developers and enterprises.

[0038] This enables multiple potentially larger communities including, e.g. developers and API consumers to start leveraging these more advanced CSP APIs.

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

[0040] Figure 10 illustrates the Aggregator interfaces A, C, and Z. The A, C, and Z interfaces are:7 Introduction to IPv6 Packets and Ipv6 Flow LabelFigure 11

[0041] The Ipv6 protocol is specified in RFC 8200, and the protocol header is shown in Figure 11. The Flow Label field is defined as follows (in RFC 6437 referenced by RFC 8200):The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a node to label packets of a flow. A Flow Label of zero is used to indicate packets that have not been labeled. Packet classifiers can use the triplet of Flow Label, Source Address, and Destination Address fields to identify the flow to which a particular packet belongs. Packets are processed in a flow-specific manner by nodes that are able to do so in a stateless manner or that have been set up with flow-specific state. The nature of the specific treatment and the methods for flow state establishment are out of scope for this specification.Summary

[0042] Systems and methods are disclosed for uniquely identifying traffic for applications and application flows for different User Equipments (UEs) in a mobile network, e.g., when a Virtual Private Network (VPN), or VPN-like, solutions are applied over the mobile network in an Over-The-Top (OTT) fashion. The main purpose for the VPN and VPN-like solutions is to protect privacy of the end users and hide information about the end user's activities (e.g., which web sites the end users are visiting) from the Communication Service Providers (CSPs). When using existing mechanisms, this also means that traffic management, like Quality of Service (QoS) management, will not be possible to perform by the CSP in the mobile network, not on any fine-granular level at least. Systems and methods are disclosed for enabling the identification of traffic of the applications and application flows in the mobile network even when VPN, or VPN-like, solutions are used, thereby enabling traffic management, such as QoS management, in the mobile network on an application flow level.Brief Description of the Drawing FiguresThe 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 a 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;Figures 4 and 5 give an overview of the QoS framework in 5GS;Figure 6 illustrates traffic classification;Figures 7 and 8 illustrate Apple® Private Relay;Figure 9 illustrates a functional view of network exposure;Figure 10 illustrates aggregator interfaces;Figure 11 illustrates the IPv6 header including the IPv6 Flow Label;Figures 12 and 13 illustrate a problem with the existing QoS framework;Figure 14 illustrates one example of a system in which embodiments of the present disclosure may be implemented; Figure 15 illustrates a procedure in which the Application Server requests activation of QoS for multiple application flows, in accordance with one example embodiment of the present disclosure;Figure 16 illustrates a procedure for the traffic part for a solution, in the downlink direction from the Application Server to the "Application Client in the UE, in accordance with an example embodiment of the present disclosure;Figure 17 illustrates a procedure for the traffic part for a solution, in the uplink direction from the Application Client in the UE to the Application Server, in accordance with an example embodiment of the present disclosure;Figure 18 illustrates another example of a procedure performed by the system of Figure 14, in accordance with an embodiment of the present disclosure.Figures 19 and 20 illustrate example embodiments of a network node in which aspects of embodiments of the present disclosure may be implemented; andFigure 21 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

[0043] 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.

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

[0045] 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.

[0046] 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 nodeimplementing 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.

[0047] 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.

[0048] 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, 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 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.

[0049] 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.

[0050] 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.

[0051] There currently exist certain problems. The main problem is how to uniquely identify applications and application flows for different UEs in a mobile network when Virtual Private Network (VPN), or VPN-like, solutions encrypting the application traffic are applied in an OTT (Over-The-Top) fashion over the mobile network. The application / application flow identification could be used, for example, for traffic management in the mobile network, e.g. for differentiated Quality of Service (QoS) handling.

[0052] A key component for Network Initiated-QoS (NI-QoS) is the Downlink and Uplink Packet Filters (PFs) (in 5GS) and Traffic Flow Templates (TFTs) (in EPS). These can be installed in the network for a specific UE, and in the UE, either based on Network Application Programming Interfaces (APIs) or Application Traffic Detection functionality. For this problem description, the actual mechanisms for how PFs / TFTs are installed in the network are not important.Figure 12

[0053] Figure 12 shows an example of the situation before VPN or VPN-like solutions are deployed. The network is configured to support three different levels of QoS in a PDU session: Default QoS level, QoS level 1 and QoS level 2. The levels are implemented as a combination of QoS flows and Radio Bearers. In the downlink, the Downlink PFs / TFTs in the UPF map the different application flows to QoS Flows. This mapping is based on information visible in the Internet Protocol (IP) headers e.g., as PFs based on 5-tuple information. The information about identified QoS Flows is forwarded to the RAN for mapping of QoS Flows to Radio Bearers. Similar actions are done in the uplink at the UE modem side, i.e. information similar to 5-tuples is used to map the application flows to QoS Flows.

[0054] The key information here is that as long as there is no VPN, or VPN-like, solution encrypting the application traffic, the Downlink and Uplink PFs and TFTs can be used identify QoS Flows. Further in Figure 12 it is shown how the Application (App) Client-2 establishes two different applications flows that can be mapped to the Default QoS level and QoS level 2.Figure 13

[0055] Figure 13 shows the impact when VPN, or VPN-alike, solutions encrypting the application traffic are applied in an OTT (Over-The-Top) fashion over the mobile network. The VPN is, for example, supported by a VPN-client in the UE Operating System (OS)-level and a VPN Server outside the CSP network. The VPN-client encrypts the application flows in the uplink, and the VPN-server decrypts these flows. Similar but opposite actions apply for the downlink.

[0056] The key here is that OTT encryption means that the Downlink and Uplink PFs / TFTs no longer can be used to identify QoS Flows. This is due to the initial application traffic being encrypted and the only visible part being so called external or outer tunneling information, e.g., outer IP headers in case of IPSec tunnel mode.

[0057] This means that, in Figure 13, the two different application flows established by the App Client-2 are transported using the VPN tunnel. Then, the Uplink PFs / TFTs are only able to map the VPN tunnel to the Default QoS level, which leads to the two applications flows established by the App Client-2 also getting mapped the Default QoS level. To be very clear, it is not possible to identify any QoS Flows using PFs / TFTs nor it is possible to apply the different levels of QoS configured in the network.

[0058] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Systems and methods are disclosed herein that enable usage of different levels of QoS configured in the network for different applications and applications flows for a specific UE even when VPN, or VPN-like, OTT solutions are used. In one embodiment, an application server (or alternatively an application client at the UE), sends a request to the mobile network (e.g., to a NF in the core network), for different levels of QoS for different application flows for an associated application. The network assigns a QoS Level Identifier, e.g. an IPv6 Flow Label, for each requested level of QoS. The application server and / or application client uses the QoS Level Identifiers for their application flows. Further, the QoS Level Identifier is made accessible for the network even when VPN, or VPN-like, OTT solutions are used. This enables the usage of the QoS Level Identifiers assigned to thedifferent application flows of the application in the network to provide the different respective levels of QoS (e.g., by using the QoS Level Identifiers in PFs and / or TFTs, e.g., in the network (e.g., at the UPF) in the case of downlink and / or at the UE in the case of uplink).

[0059] 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.

[0060] The main advantage, for mobile network operators and vendors, is the possibility to enable different levels of QoS in the mobile networks even when VPN, or VPN-like, OTT solutions are used. This is seen as key for new monetization possibilities. Another key advantage is that the solution also supports end user privacy as the mobile network does not need to be aware of which applications are actually using the different QoS levels.

[0061] Application flow specification support is also needed for specialized services (e.g., European Union (EU) Open Internet Regulations term for services that are not publicly available over the Internet), which may become mandatory in the future (disaster handling services for instance). This solution makes it possible to support these without disclosing the actual service used (as the identifier is dynamically chosen).

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

[0063] Figure 14 illustrates one example of a system 1400 in which embodiments of the present disclosure may be implemented. As illustrated, the system includes a UE 1402, a mobile network 1404, an aggregator 1406 (optional), a VPN server 1408 and a VPN client 1409 (at the UE1402) that operate to provide a VPN, or VPN-like, OTT solution, and Application Client(s) 1410-1 to 1410-x (App Client-1 to App Client-x at the UE 1402) and Application Server(s) 1412-1 to 1412-x (App Server-1 to App Server-x) that operate to provide respective applications (App-1 to App-x). Note that the Application Clients 1410-1 to 1410-x are generally referred to herein collectively as Application Clients 1410 and individually as 1410. Likewise, the Application Servers 1412-1 to 1412-x are generally referred to herein collectively as Application Servers 1412 and individually as Application Server 1412. In this example, the Application Servers 1412 are connected to the mobile network 1404 via the aggregator 1406, to request different levels of QoS from the mobile network 1404. The aggregator 1406 is to be seen as an optional entity, and the Application Servers 1412 could alternatively be connected directly to the mobile network 1404.

[0064] The UE 1402 is shown as including three main parts: an Applications layer 1414, an OS 1416, and a modem 1418. The Applications layer 1414 is exemplified with the Application Clients 1410. The OS is exemplified with a socket layer 1420 for communication, the VPN client 1409, and a TCP / IP stack 1422. The modem 1418 is exemplified with a driver 1424 for the EPS / 5GS related communication, with the main part for the present disclosure being Uplink PFs / TFTs 1426.

[0065] The mobile network 1404 includes a RAN 1428, Packet Core 1430 (also referred to herein as a core network), and a Network Exposure 1432 (e.g., a NEF in the case of 5GS). The mobile network 1404 is configured, in this example, to support three different levels of QoS in a PDU session: Default QoS level, QoS level 1 and QoS level2. In the Packet Core 1430, the main entities for purposes of the present disclosure are the connection to the network exposure, PCF 1434, SMF 1436, and UPF (not explicitly show) configured with Downlink PFs / TFTs 1438.

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

[0067] The VPN, or VPN-like, solution (hereinafter simply referred to as "VPN-like solution”) is shown as a VPN-tunnel between the VPN Server 1408 and the VPN Client 1409 in the OS 1416 of the UE 1402. In one embodiment, the VPN tunnel is initially mapped to the Default QoS level in the mobile network 1404. Embodiments of the present disclosure enable different application flows for the same application carried over the VPN tunnel to be mapped to different QoS levels configured in the mobile network 1404.

[0068] The additional details of the proposed solution are shown in the following figures and related description as following:• API part - Activation of QoS for multiple application flows of an application (see, e.g., Figure 15),• Traffic part - usage of the QoS in DL (see, e.g., Figure 16), and• Traffic part - usage of the QoS in UL (see, e.g., Figure 17).Figure 15

[0069] Figure 15 illustrates a procedure in which the Application Server 1412-2 requests activation of QoS for multiple application flows, in accordance with one example embodiment of the present disclosure. The different steps shown in Figure 15 are described below.

[0070] Step 1 : Application-specific logic, e.g. in the Application Server 1412-2, is aware of the needed traffic and QoS characteristics for a set of application flows that are part of the application.

[0071] Step 2: The Application Server 1412-2 sends a request to the aggregator 1406 for activation of desired QoS levels for the application flows in the set of application flows that are part of the application. The request contains a UE identifier that identifies the UE 1402 for which the request is made. Examples of UE identifiers are International Mobile Subscriber Identity (IMSI), Mobile Subscriber Integrated Services Digital Network (ISDN) Number (MSISDN), and / or an IP-address. The request also contains a set of requested QoS levels, i.e. one requested QoS level for QoS needs for each application flow. In one example embodiment, the requested QoS level is in the request (e.g., in the API used for the request) described in generic terms (e.g., Low Latency or High Bandwidth). In another embodiment, when, e.g., a specific Service Level Agreement (SLA) has been made, the requested QoS level may be a specific identifier for one of a set of predefined QoS levels (e.g., one of a set of predefined QoS levels in the SLA).

[0072] Note that, in one embodiment, Step 2 can also include authentication and identification of the application (e.g., the Application Server 1412-2) in question.

[0073] Step 3: The Aggregator 1406 identifies the mobile network 1404 to which the UE 1402 indicated in the request is connected based on the UE identifier contained in the request of Step 2. The Aggregator 1406 forwards the received request to the Network Exposure function 1432 in the identified mobile network 1402. To preserve enduser privacy, in one embodiment, the Aggregator 1406 does not forward any information about the application in question to the Network Exposure function 1432.

[0074] Step 4: The mobile network 1404 performs internal actions to prepare the requested QoS Level(s) for the UE 1402. The UE 1402 is identified with the received UE identifier. The mobile network 1404 (e.g., the PCF 1434 or some other associated network function) allocates the QoS Level Identifier, e.g. an IPv6 Flow Label, for each QoS level requested by the Application Server 1412-2 via the Aggregator 1406. Optionally, the mobile network 1404 (e.g., the PCF 1434 or some other associated network function) may decide whether to approve the requested QoS levels and allocates QoS Level Identifiers (e.g., IPv6 Flow Labels) only for the approved, requested QoS levels. Note that this decision may be based on the subscription of the UE 1402 (i.e., does the subscription of the UE 1402 allow the requested QoS levels or allow such requests) and / or based on a current traffic load in the mobile network 1404 (e.g., can the requested QoS levels be allowed considering the current network load). In one embodiment, the QoS Level Identifiers (e.g., IPv6 Flow Labels) uniquely assigned each time a request is received in such a manner that different QoS Level Identifiers may be allocated for the same QoS Level for different requests from the same UE and / or for requests from different UEs. The mobile network 1404 (e.g., the PCF 1434) creates PFs or TFS (denoted herein as "PFs / TFTs”) for the UE 1402 that define the relation, or mapping, between the allocated QoS Level Identifiers (e.g., the allocated IPv6 Flow Labels) for the requested QoS levels and corresponding QoS flows (within a PDU Session of the UE 1402) within the mobile network 1404, and the PCF 1434 installs the created PFs / TFTs in the mobile network 1404, e.g. as part of Downlink PFs / TFTs 1438 in the UPF at which the UE's PDU Session is anchored and / or as part of the uplink PFs / TFTs 1426 at the UE 1402. The mobile network 1404 may also activate the QoS Flows in this step, or activate the QoS flows later when the traffic using the QoS Level Identifiers (e.g., IPv6 Flow Labels) is detected (for this UE 1402).

[0075] Step 5: The mobile network 1404 (e.g., the Network Exposure function 1432) replies to the request received in step 3 from the Aggregator 1406. In one embodiment, this reply contains the UE identifier and, for each approved QoS level, the allocated QoS Level Identifier (e.g., IPv6 Flow Label). In another embodiment in which the mobile network 1404 may approve or deny each requested QoS level, the reply contains the UE identifier and the allocated QoS Level Identifier(s) (e.g., allocated IPv6 Flow Label(s)) for the approved QoS level(s). For example, the reply may include the UE identifier and, for each approved QoS level, the combination of the Requested QoS level and the allocated QoS Level Identifier (e.g., IPv6 Flow Label) parameters.

[0076] Step 6: The aggregator 1406 forwards the reply received from the mobile network 1402 to the Application Server 1412-2.

[0077] For the description of Figures 16 and 17, the allocated QoS Level Identifiers for the requested QoS levels (associated to respective application flows of the same application) are IPv6 Flow Labels. However, embodiments of the present disclosure are not limited to IPv6 Flow Labels. Other similar IP header fields (e.g., of the IP header in future versions) may be used.Figure 16

[0078] Figure 16 illustrates a procedure for the traffic part for a solution, in the downlink direction from the Application Server 1412-2 to the "Application Client 1410-2 in the UE 1402, in accordance with an example embodiment of the present disclosure. The different steps shown in Figure 16 are described below.

[0079] Step 7: The Application Server 1412-2 uses the IPv6 Flow Labels allocated by the mobile network 1404 for each Requested QoS level for the application flows towards the Application Client 1410-2. The Application Server 1412-2 is aware of the application flow needs and can therefore map the combinations of [Requested QoS level, IPv6 Flow Label] to the different application flows of the application. Note that, in this example, the IPv6 Flow Labels are obtained via the procedure of Figure 15; however, the present disclosure is not limited thereto. For example, in one alternative embodiment, the Application Client 1410-2 at the UE 1402 obtains the IPv6 Flow Labels (allocated by the mobile network 1404) for the different QoS levels (or analogously for the different application flows for which the different QoS levels are desired), and the Application Client 1410-2 at the UE 1402 sends the allocated IPv6 Flow Labels for the different QoS Levels to the Application Server 1412-2. The Application Client 1410-2 at the UE 1402 may obtain the IPv6 Flow Labels for the different QoS levels by requesting IPv6 flow labels for the different QoS levels from the mobile network 1404 (e.g., via the Aggregator 1406, via the Network Exposure 1432, or otherwise). In another alternative embodiment, the Application Client 1410-2 at the UE 1402 obtains the IPv6 Flow Labels (allocated by the mobile network 1404) for the different QoS levels (or analogously for the different application flows for which the different QoS levels are desired), and the Application Client 1410-2 at the UE 1402 sends application flow packets with the allocated IPv6 Flow Labels for the different QoS Levels to the Application Server 1412-2. The Application Server 1412-2 may then detect which IPv6 Flow Labels are being used for the different application flows and use those IPv6 Flow Labels for downlink application flow packets for the same application flows.

[0080] Step 8: The Application Server 1412-2 sends a downlink application flow packet (i.e., a packet for one of the application flows of the application) towards the Application Client 1410-2. The packet contains the IPv6 Flow Label indicating the Requested QoS level for this application flow. The packet is forwarded to the VPN Server 1408. Although the VPN Server 1408 and the Application Server 1412-2 are shown as separate entities, it is possible to combine these entities to have the VPN-like solution included in the Application Server 1412-2. Note that, in a similar manner, although the VPN client 1409 and the Application Client 1410 are shown as separate entities, it is possible to combine these entities to have the VPN-like solution included in the Application Client 1410.

[0081] Step 9: The VPN Server 1408 encrypts the application flow packet. This encryption depends on mechanisms specific to the particular VPN technology being used. Different mechanisms may be used for different VPN technologies. These encryption mechanisms are outside the scope of the present disclosure. In addition, the VPN Server 1408 copies the IPv6 Flow Label contained in the application flow packet to the outer and external IPv6 header of the encrypted application flow packet. The application flow packet contained within the encrypted application flow packet (i.e., the information contained in the application flow packet) is no longer readable after encryption. However, information contained in the external IPv6 header, including the IPv6 Flow Label coped to the external IPv6 header, is readable.

[0082] Step 10: The VPN Server 1408 forwards the encrypted application flow packet to the UPF in the mobile network 1404.

[0083] Step 11 : The UPF uses the visible IPv6 Flow Label in the external IPv6 header to match a downlink PF / TFT in the installed downlink PFs / TFTs 1438, in step 4, for this UE 1402. A match is detected and the QoS Flow for this IPv6 Flow Label is activated in the mobile network (in case the activation was not already performed in step 4).

[0084] Step 12: The encrypted application flow packet is forwarded to the RAN 1428 including the indication of the detected QoS Flow (i.e. , the QoS Flow mapped to the IPv6 Flow Label via the matching downlink PF / TFT).

[0085] Step 13: The RAN 1428 uses the indication of the detected QoS Flow to map the encrypted application flow packet to a radio bearer.

[0086] Step 14: The encrypted application flow packet is sent to the UE 1402 over the selected radio bearer. The packet is forwarded within the UE 1402 to the VPN client 1409.

[0087] Step 15: The VPN Client 1409 decrypts the received encrypted application flow packet.

[0088] Step 16: The original, and decrypted, downlink application flow packet is forwarded to the ApplicationClient 1410-2.Figure 17

[0089] Figure 17 illustrates a procedure for the traffic part for a solution, in the uplink direction from the Application Client 1410-2 in the UE 1402 to the Application Server 1412-2, in accordance with an example embodiment of the present disclosure. The different steps shown in Figure 17 are described below.

[0090] Step 17: In this example embodiment, the procedure of Figure 17 follows that of Figure 16, and the Application Client 1410-2 applies "reflective QoS” for the uplink direction. The Application Client 1410-2 at the UE 1402 uses the received IPv6 Flow Label in a specific downlink application flow packet for uplink packets for the same application flow.

[0091] Step 18: The Application Client 1410-2 sends an uplink application flow packet towards the VPN Client 1409 in the UE 1402. The packet contains the IPv6 Flow Label reflected from a received downlink application flow packet for the same application flow.

[0092] Step 19: The VPN Client 1409 encrypts the uplink application flow packet, e.g., using mechanisms specific for the particular VPN technology being used. In addition, the VPN Client 1409 copies the IPv6 Flow Label contained in the received uplink application flow packet to the outer and external IPv6 header of the encrypted packet. The received uplink application flow packet is no longer readable in the encrypted packet. However, the IPv6 Flow Label in the external IPv6 header is readable.

[0093] Step 20: The encrypted application flow packet is forwarded to the driver 1424 in the modem 1418, and especially to the Uplink PFs / TFTs 1428 part of the driver 1424.

[0094] Step 21 : The Uplink PFs / TFTs 1426 use the IPv6 Flow Label contained in the outer IP header of the received encrypted application flow packet to match an uplink PF / TFT to select a specific QoS Flow. A matchingPF / TFT is found for the received IPv6 Flow Label, and a QoS Flow is identified by the matching PF / TFT. Existing mechanisms are used to map the identified QoS Flow to a radio bearer.

[0095] Step 22: The encrypted uplink application flow packet is sent from the UE 1402 to the RAN 1428 over the selected radio bearer.

[0096] Step 23: The encrypted uplink application flow packet is sent from the RAN 1428 to the UPF.

[0097] Step 24: The encrypted uplink application flow packet is sent from the UPF to the VPN Server 1408.

[0098] Step 25: The VPN Server 1408 decrypts the received encrypted application flow packet.

[0099] Step 26: The original, and decrypted, uplink application flow packet is forwarded to the ApplicationServer 1412-2. Again, while shown separately, the functionality of the VPN Server 1408 may alternatively be combined with into the Application Server 1412-2.

[0100] The baseline description above can be extended in different ways, for example:• The API part may (e.g., the Aggregator 1406 and / or the Network Exposure function 1432 may, via an API) also contain deactivation of one or more of the QoS Levels (e.g., previously requested in steps 2 and 3 of Figure 15) for the UE 1402 and application in question. This means that the network removes any related configuration in the network, like QoS Flows, PFs and TFTs. This may also mean that the allocation of the corresponding QoS Level Identifier(s) (e.g., IPv6 Flow Identifier(s)) may be removed (e.g., the corresponding QoS Level Identifiers(s) (e.g., IPv6 Flow Identifier(s)) may be added back to a pool of unallocated QoS Level Identifiers that can be subsequently allocated to other application flows for the same or different applications for the same or different UEs).• For long-lived applications, the API may also be extended to dynamic change of the IPv6 flow label. This can be done in different ways. One example is that the above-described APIs are extended with a time validity indicator in steps 5 and 6 of Figure 15. This time validity indicator would imply how long the QoS reservation will be active and when the application needs to re-request or reactivate it again, i.e. trigger steps 1 and 2 of Figure 15 again.• The aggregator shown between the mobile network(s) 1404 and the Application Servers 1412 are to be seen as an optional arrangement. The described functionality can also be used for the case when no such aggregators are included, i.e. when the Application Servers 1412 would be directly connected to the mobile network(s) 1404.• The baseline embodiments described as network side APIs can also be applied to UE-side APIs. This means that, e.g., the Application Client 1410 would instead access Network APIs directly or via another entity. The other entity can be any network side functionality that has access to the mobile network APIs, including the Application Server(s) 1412. The Application Client 1410 would receive information about the QoS Level Identifier reserved by the mobile network 1404 for the different QoS levels. The main impact on the baseline description is that the uplink and downlink handling are reversed, and that the reflective QoS is performed for the downlink in UPF.Figure 18

[0101] Figure 18 illustrates a procedure performed by the system 1400 of Figure 14 in accordance with an embodiment of the present disclosure. This procedure is substantially the same as that described above and, as such, the details described above regarding various steps of the procedure of Figure 18 are equally applicable here to the procedure of Figure 18. As illustrated, two different application flows having different QoS requirements are transmitted from the application client 1410-2 to the application server 1412-2 over the mobile network 1404 using a VPN, or VPN-like, solution applied in an OTT fashion over the mobile network 1404 (step 1 and 2). The mobile network 1404 allocates a unique IPv6 Flow Label for each application flow (denoted in Figure 18 as IPv6 Flow Label- 1 and IPv6 Flow Label-2), based on received QoS requirements (e.g., received from the application server 1412-2 via aggregator 1406), and communicates these IPv6 flow labels to the application server 1412-2 (step 3). Note that step 3 may be performed before steps 1 and 2. The mobile network 1404 creates radio bearers and QoS flows and installs the needed packet filters for IPv6 Flow Label-1 and IPv6 Flow Label-2 (step 4). The application server 1412-2 includes these IPv6 Flow Labels in the corresponding packets sent to the VPN server 1408 for those application flows (step 5). For each packet for each application flow, the VPN server 1408 copies the IPv6 Flow Label to the VPN tunnel header of the corresponding encrypted packet (step 6) and sends the encrypted packet to the mobile network 1404. At the mobile network 1404, the installed packet filters are used to direct the encrypted packets to the appropriate QoS flow within the PDU session of the UE (step 7). Upon receiving the packets for the different application flows, the application client 1410-2 performs uplink handling based on reflective QoS, as described above (step 8). In other words, the application client 1410-2 determines the IPv6 Flow Label to be used for each application flow based on the corresponding IPv6 Flow Labels contained in the received packets for those application flows and then uses the same IPv6 Flow Labels for the uplink packets for those application flows.Figure 19

[0102] Figure 19 is a schematic block diagram of a network node 1900 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 1900 may be, for example, a network node that implements the functionality of the Application Server 1412, a network node that implements the functionality of the VPN Server 1408, a network node that implements the functionality of the Aggregator 1406, a network node that implements the functionality of the Network Exposure function 1432, a network node that implements the functionality of a network function in the Packet Core 1430 (e.g., the PCF 1435 or the UPF), or the like. As illustrated, the network node 1900 includes a control system 1902 that includes one or more processors 1904 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1906, and a network interface 1908. The one or more processors 1904 are also referred to herein as processing circuitry. The one or more processors 1904 operate to provide one or more functions of the network node 1900 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 someembodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1906 and executed by the one or more processors 1904.Figure 20

[0103] Figure 20 is a schematic block diagram that illustrates a virtualized embodiment of the network node 1900 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 1900 in which at least a portion of the functionality of the network node 1900 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 1900 includes one or more processing nodes 2000 coupled to or included as part of a network(s) 2002. Each processing node 2000 includes one or more processors 2004 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 2006, and a network interface 2008. In this example, functions 2010 of the network node 1900 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) are implemented at the one or more processing nodes 2000 or distributed across the two or more processing nodes 2000 in any desired manner. In some particular embodiments, some or all of the functions 2010 of the network node 1900 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) 2000.

[0104] 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 1900 or a node (e.g., a processing node 2000) implementing one or more of the functions 2010 of the network node 1900 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 21

[0105] Figure 21 is a schematic block diagram of a wireless communication device 2100 (e.g., the UE 1402) according to some embodiments of the present disclosure. As illustrated, the wireless communication device 2100 includes one or more processors 2102 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 2104, and one or more transceivers 2106 each including one or more transmitters 2108 and one or more receivers 2110 coupled to one or more antennas 2112. The transceiver(s) 2106 includes radio-front end circuitry connected to the antenna(s) 2112 that is configured to condition signals communicated between the antenna(s) 2112 and the processor(s) 2102, as will be appreciated by on of ordinary skill in the art. The processors 2102 are also referred to herein as processing circuitry. The transceivers 2106 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 2100 (or UE) (e.g., the functionality of the Application Clients 1410, the VPN client 1409, and the driver 1424 including the uplink PFs / TFTs 1426) may be fully or partially implemented in software that is, e.g., stored in the memory 2104 and executed by the processor(s) 2102. Note that the wirelesscommunication device 2100 may include additional components not illustrated in Figure 21 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 2100 and / or allowing output of information from the wireless communication device 2100), a power supply (e.g., a battery and associated power circuitry), etc.

[0106] 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 2100 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).

[0107] 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.

[0108] 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.).Some of the embodiments that have been described above can be summarized in the following manner1 . A method performed by one or more network functions (1432, 1434) in a mobile network (1404), the method comprising: receiving (Fig. 15, step 3), from a requesting entity (1406, 1412), a request for activation of one or more requested Quality of Service, QoS, levels for application flows that are part of an application utilized by a User Equipment, UE, (1402); andsending (Fig. 15, step 5) a response to the requesting entity, the response comprising a QoS level identifier allocated by the mobile network (1404) for the UE (1402) for identifying each of at least one of the one or more requested QoS levels for the application flows that are part of the application utilized by the UE (1402).2. The method of embodiment 1 , wherein, for each of the at least one of the one or more requested QoS levels, the QoS level identifier is an IPv6 flow label.3. The method of embodiment 1 or 2, wherein the response comprises a QoS level identifier for each of the one or more requested QoS levels.4. The method of embodiment 1 or 2, wherein the response comprises a QoS level identifier for each of at least one of the one or more requested QoS levels approved by the mobile network (1404).5. The method of any of embodiments 1 to 4, wherein the request comprises a UE identifier of the UE (1402) and information that indicates the one or more QoS levels requested to be activated.6. The method of any of embodiments 1 to 5, wherein the one or more requested QoS levels comprise two or more requested QoS levels.7. The method of any of embodiments 1 to 6, further comprising allocating (Fig. 15, step 4) the QoS level identifier for each of the at least one of the one or more requested QoS levels.8. The method of embodiment 7, wherein for each requested QoS level of the at least one of the one or more requested QoS levels, the QoS level indicator allocated by the mobile network (1404) for the requested QoS level is uniquely allocated for the requested QoS level for the UE (1402).9. The method of embodiment 7 or 8, further comprising, for each requested QoS level of the at least one of the one or more requested QoS levels: creating (Fig. 15, step 4) one or more PFs / TFTs that define a relation between the QoS level indicator allocated for the requested QoS level and a corresponding QoS flows within a PDU session of the UE (1402); and installing (Fig. 15, step 4) the one or more PFs / TFTs in the mobile network (1404) and / or in the UE (1402).10. The method of any of embodiments 1 to 9, wherein the requesting entity is an aggregator function (1406).11 . The method of any of embodiments 1 to 9, wherein the requesting entity is an application server of the application.12. The method of any of embodiments 1 to 9, wherein the requesting entity is an application client of the application, the application client being implemented at the UE (1402).13. A system comprising one or more network functions for mobile network, the one or more network functions adapted to perform the method of any of embodiments 1 to 12.14. A method performed by a VPN server, comprising: receiving (Fig. 16, step 8) an application flow packet from an application server, the application flow packet comprising a QoS level indicator; encrypting (Fig. 16, step 9) the application flow packet to provide an encrypted packet; storing (Fig. 16, step 9) the QoS level indicator in an outer, unencrypted header of the encrypted packet; and sending (Fig. 16, step 10) the encrypted packet to a mobile network.15. The method of embodiment 14, wherein the QoS level indicator is an IPv6 flow label.16. The method of embodiment 14 or 15, wherein the QoS level indicator is allocated by the mobile network.17. A VPN server adapted to perform the method of any of embodiments 14 to 16.18. A method performed by a VPN client at a UE, comprising: receiving (Fig. 17, step 18) an application flow packet from an application client, the application flow packet comprising a QoS level indicator; encrypting (Fig. 17, step 19) the application flow packet to provide an encrypted packet; storing (Fig. 17, step 19) the QoS level indicator in an outer, unencrypted header of the encrypted packet; and sending (Fig. 17, step 20) the encrypted packet to a modem of the UE for transmission via a mobile network.19. The method of embodiment 18, wherein the QoS level indicator is an IPv6 flow label.20. The method of embodiment 18 or 19, wherein the QoS level indicator is allocated by the mobile network.21. A User Equipment, UE, comprising a VPN client adapted to perform the method of any of embodiments 18 to 20.

Claims

ClaimsWhat is claimed is:1 . A method performed by one or more network functions (1432, 1434) in a mobile network (1404), the method comprising: receiving (Fig. 15, step 3), from a requesting entity (1406, 1412), a request for activation of one or more requested Quality of Service, QoS, levels for application flows that are part of an application utilized by a User Equipment, UE, (1402); and sending (Fig. 15, step 5) a response to the requesting entity, the response comprising a QoS level identifier allocated by the mobile network (1404) for the UE (1402) for identifying each of at least one of the one or more requested QoS levels for the application flows that are part of the application utilized by the UE (1402).

2. The method of claim 1 , wherein, for each of the at least one of the one or more requested QoS levels, the QoS level identifier is an IPv6 flow label.

3. The method of any of claim 1 or 2, wherein the response comprises a QoS level identifier for each of the one or more requested QoS levels.

4. The method of any of claim 1 or 2, wherein the response comprises a QoS level identifier for each of at least one of the one or more requested QoS levels approved by the mobile network (1404).

5. The method of any of claim 1 to 4, wherein the request comprises a UE identifier of the UE (1402) and information that indicates the one or more QoS levels requested to be activated.

6. The method of any of claim 1 to 5, wherein the one or more requested QoS levels comprise two or more requested QoS levels.

7. The method of any of claim 1 to 6, further comprising allocating (Fig. 15, step 4) the QoS level identifier for each of the at least one of the one or more requested QoS levels.

8. The method of claim 7, wherein for each requested QoS level of the at least one of the one or more requested QoS levels, the QoS level indicator allocated by the mobile network (1404) for the requested QoS level is uniquely allocated for the requested QoS level for the UE (1402).

9. The method of claim 7 or 8, further comprising, for each requested QoS level of the at least one of the one or more requested QoS levels:creating (Fig. 15, step 4) one or more PFs / TFTs that define a relation between the QoS level indicator allocated for the requested QoS level and a corresponding QoS flows within a PDU session of the UE (1402); and installing (Fig. 15, step 4) the one or more PFs / TFTs in the mobile network (1404) and / or in the UE (1402).

10. The method of any of claim 1 to 9, wherein the requesting entity is an aggregator function (1406).11 . The method of any of claim 1 to 9, wherein the requesting entity is an application server of the application.

12. The method of any of claim 1 to 9, wherein the requesting entity is an application client of the application, the application client being implemented at the UE (1402).

13. A system comprising one or more network functions for mobile network, the one or more network functions adapted to perform the method of any of claim 1 to 12.

14. A method performed by a VPN server, comprising: receiving (Fig. 16, step 8) an application flow packet from an application server, the application flow packet comprising a QoS level indicator; encrypting (Fig. 16, step 9) the application flow packet to provide an encrypted packet; storing (Fig. 16, step 9) the QoS level indicator in an outer, unencrypted header of the encrypted packet; and sending (Fig. 16, step 10) the encrypted packet to a mobile network.

15. The method of claim 14, wherein the QoS level indicator is an IPv6 flow label.

16. The method of claim 14 or 15, wherein the QoS level indicator is allocated by the mobile network.

17. A VPN server adapted to perform the method of any of claim 14 to 16.

18. A method performed by a VPN client at a UE, comprising: receiving (Fig. 17, step 18) an application flow packet from an application client, the application flow packet comprising a QoS level indicator; encrypting (Fig. 17, step 19) the application flow packet to provide an encrypted packet; storing (Fig. 17, step 19) the QoS level indicator in an outer, unencrypted header of the encrypted packet; and sending (Fig. 17, step 20) the encrypted packet to a modem of the UE for transmission via a mobile network.

19. The method of claim 18, wherein the QoS level indicator is an IPv6 flow label.

20. The method of claim 18 or 19, wherein the QoS level indicator is allocated by the mobile network.

21. A User Equipment, UE, comprising a VPN client adapted to perform the method of any of claim 18 to 20.

Images