Patent Description:
Quick User Datagram Protocol (UDP) Internet Connections (QUIC) is a general-purpose transport layer network protocol. While it may be referred to as the acronym for Quick User Datagram Protocol (UDP) Internet Connections, some organizations (e.g., Internet Engineering Task Force, IETF) refer to QUIC as the name of the protocol without treating it as an acronym. QUIC may be viewed as similar to Transmission Control Protocol (TCP) + enhancement such as Transport Layer Security (TLS) and/or Hypertext Transfer Protocol <NUM> (HTTP/<NUM> or HTTP/<NUM>) but implemented on top of UDP. QUIC is therefore a UDP based stream-multiplexed and secure transport protocol with integrity protected header and encrypted payload. Yet unlike the traditional transport protocol stack with TCP (Transmission Control Protocol), which resides in the operating system kernel, QUIC can easily be implemented in the application layer. Consequently, this improves flexibility in terms of transport protocol evolution with implementation of new features, congestion control, deployment, and adoption. QUIC uses Transport Layer Security (TLS) for security handshake by default. TLS exchanges the necessary keying material in the protocol's handshake. The use of TLS (defined in IETF Request for Comments (RFC) <NUM>) or Datagram TLS (DTLS) (under discussion, see <NPL>) is very common as a transport security solution independent from the underlying transport protocol being TCP or UDP. Note that HTTP-over-QUIC is sometimes referred to as HTTP/<NUM> as approved by IETF.

While QUIC standardization efforts started less than <NUM> years ago, presently it represents nearly <NUM>% of the Internet traffic pushed by large Internet domains. QUIC is becoming a main transport protocol in the Internet's user plane. Many applications running today over HTTP/HTTPS may migrate to QUIC, driven by QUIC's latency improvements and stronger security. Notably, encryption in QUIC covers both the transport protocol headers as well as the payload, as opposed to TLS over TCP (e.g., HTTPS), which protects only the payload.

A proxy is an intermediary program/software (or hardware such as a network node implementing such intermediary program/software) acting as a server, a client, or a combination of the server or client for some functionalities as the proxy may create or simply relay requests on behalf of other entities. The proxy may be implemented on a path between a server and a client. Note that each of the client, server, and proxy may be implemented in one or more network nodes such as client nodes, server nodes, and intermediate (on-path) nodes, respectively. Each of a server or client node may be referred to as an endpoint node.

Requests are serviced internally or by passing them on, with possible translation, to other servers. There are several types of proxies, including the following: (<NUM>) A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification; (<NUM>) A "non-transparent proxy" is a proxy that modifies the request or response to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering; (<NUM>) A "reverse proxy" basically is a proxy that pretends to be the actual server (as far as any client or client proxy is concerned), but it passes on the request to the actual server that is usually sitting behind another layer of firewalls; and (<NUM>) A "performance enhancement proxy" (PEP) is used to improve the performance of protocols on network paths (e.g., where native performance suffers due to characteristics of a link or subnetwork on the path).

A Collaborative Performance Enhancement (COPE) node or function is an entity which resides between two endpoints, usually in a client and server setup but also in a peer to peer communication setup, that use encrypted communication. The communicating parties (usually the client) explicitly contact the proxy in order to request a network-support service. This service at a minimum always includes forwarding of the encrypted traffic to a specific server, e.g. also in cases where the server is otherwise not directly reachable. In addition, the endpoints can share traffic information with the COPE entity such that the COPE entity can execute a requested performance enhancement function to improve the QoS of the traffic as well as optimize operations within the network. Alternatively, also the COPE node can provide additional information about the network which enables the endpoint to optimize its data transfer, e.g. use a more optimized congestion control or delay pre-fetching activities.

Usually it is expected that a client learns about the existence of a COPE service either directly from the access network or by other communication with a peer. When a COPE node is detected, the client can open a connection to it, for example a QUIC connection when QUIC is used as a transport protocol and request a service. The communication with the server is realized by an inner transport connection that is encrypted end-to-end between the client and the server.

A COPE node or function (the COPE node/function may also be referred to as a COPE entity) may be implemented in a network device containing a QUIC proxy and/or performance/traffic enhancement features/functions, and the COPE node is an intermediate/on-path node (referred to as a COPE node for it implementing the COPE functions) between two endpoints, usually in a client and server setup but also in a peer to peer communication setup, that use encrypted communication.

One communicating parties (e.g., a client) may explicitly contact an on-path COPE entity in order to request a network-support service. This service, at a minimum, always includes forwarding of the encrypted traffic to a specific server (e.g., when the server is otherwise not directly reachable). In addition, the endpoints can share traffic information with the COPE entity such that the COPE entity can execute a requested enhancement function to improve the QoS of the traffic as well as optimize operations within the network. Alternatively, the COPE entity may provide additional information about the network that enables the endpoint to optimize its data transfer, e.g., use a more optimized congestion control or delay pre-fetching activities.

<FIG> shows a placement of proxy node (e.g. UPF, COPE) <NUM> in a wireless network per one embodiment of the disclosure. A UE <NUM> (e.g., a QUIC client) may learn about the existence of the proxy node <NUM> either directly from an access network <NUM> or by another communication with a peer. The proxy node may provide one or more enhancement functions between the client <NUM> and server <NUM>. In one embodiment, the proxy node implements a COPE entity. When the proxy node <NUM> is detected, the client <NUM> may open a connection to it. For example, when QUIC is used as a transport protocol, a QUIC connection is opened to request a service. The QUIC connection between the client <NUM> and proxy node <NUM> uses an outer connection <NUM> and can exchange information through a stream of that outer QUIC connection. The communication with a server <NUM> (e.g., a QUIC server) is realized by an inner transport connection <NUM> that is encrypted end-to-end between the client <NUM> and the server <NUM> through a core network <NUM>. The inner transport connection is sent within one stream of the outer QUIC connection. In some embodiments, the proxy that provides the enhancement functions may be implemented between two peer nodes as well. The enhancement functions may assist the client <NUM> in its session with the server <NUM>.

In this disclosure, the outer connection <NUM> between the UE and proxy node (e.g. UPF, COPE) is also referred to as communication channel between the UE and proxy node (e.g. UPF, COPE).

The outer connection <NUM> may be at application level or at network level. Network level refers to the tunneling protocols in the mobile network, for example General Packet Radio Service (GPRS) Tunneling Protocol (GTP) protocol. Application level refers to the traffic that is tunneled using those network level protocols, for example Quick User Datagram Protocol (UDP) Internet Connections (QUIC) protocol.

If the communication channel <NUM> is established at application level, the data session between the UE <NUM> and the Application Server (AS) <NUM> is at application level, and the proxy node (e.g. UPF, COPE) <NUM> acts as application level proxy in the communication between the UE and the AS.

If the communication channel <NUM> is established at network level, the data session between the UE <NUM> and the proxy node (e.g. UPF, COPE) <NUM> is at network level. The end-to-end traffic between the UE <NUM> and the AS <NUM> is tunneled in said network-level data session and the proxy node (e.g. UPF, COPE) <NUM> acts as a network level gateway in the end-to-end communication between the UE and the AS.

<FIG> further shows the network entities in a wireless network per one embodiment of the disclosure. In a wireless network, the UE <NUM> communicates with application and/or media server <NUM> through a set of network entities. Each of the application servers <NUM> may provide one or more services to the application clients in the UE <NUM>. The UE <NUM> accesses the wireless network through an access network, which includes a base station <NUM> (e.g., eNodeB). The base station <NUM> may include a radio network controller (RNC), a base station controller (BSC), and/or other entities. There are a number of Core Network entities <NUM> within a core network of the wireless network. For example, the SMF <NUM> may provide management functions for sessions between the applicant clients in the UE <NUM> and the application servers <NUM>. The PCF <NUM> provides functions about policy and charging control rules for the sessions, and the UPF <NUM> monitors the user plane traffic based on the rules received from SMF. The COPE entity <NUM> may provide enhancement functions for the sessions.

Today's networks do more than just forwarding traffic. It is common practice for a network operator to capture traffic traversing its network for monitoring, inspection and/or classification, so that necessary measures can be taken to ensure good network health and/or user experience. When unencrypted application and/or transport protocols (such as HTTP, partially HTTPS or TCP) are used, network operators usually do not require close collaboration with service providers. However, as service providers are deploying encrypted protocols (such as HTTP/<NUM> or QUIC) at a fast pace, it is becoming more difficult for network operators to use traffic for network monitoring or application optimization purposes in a non-collaborative/transparent way. To use network functions that optimize traffic or provide differential treatment when traffic is encrypted, the network operator and the Over-the-Top (OTT) service provider need to collaborate. Through this kind of collaboration, they can discover, negotiate and configure the existence of a proxy, e.g. a QUIC proxy or a QUIC performance enhancement function, and generally applicable to other protocols as Collaborative Performance Enhancement (COPE) proxy.

OTT services are provided by the service provider across one or multiple IP networks, namely, the Internet. The service provider here is solely responsible for content controlling and distribution and they usually do it by bypassing telecommunication, Internet Service Providers (ISPs) or broadcast channels; treating the Internet as black box. Even though the basic principle of operation is "best effort" both service and network providers deploy many techniques to support QoS guarantees. These include Content Delivery Network (CDN), caching, proxying, load balancing, transport protocol optimization for cellular and satellite networks and other traffic engineering.

3GPP supports an exposure framework between Content Provider(s) and Network Operator(s), which is based on control plane signaling (which is an out-of-band channel separated from the user's data traffic). This framework allows content providers to cooperate with the network operator on policy enforcement and quality assurance. However, one of the reasons this architecture is not used from the beginning of the deployment of an OTT service is, that it requires particular Service Layer Agreements (SLAs) to be signed between multiple, if not all, parties involved.

A problematic aspect is that 3GPP supports a policy (PCC) framework, where the policy controller (PCF) indicates to SMF (and UPF) the policies to be applied for the user's PDU session with a per application granularity, but it does not currently support an efficient mechanism for the content provider to request policies to be applied by the network operator to their applications. The current 5GC policy authorization mechanism is described in 3GPP TS <NUM> and is based on a communication between the PCF and an external Application Function (AF), where the AF requests are conveyed through the NEF. This requires an AF on the content provider side that needs to maintain connectivity to the NEF, and extensive session states based on 5GC exposure functions to the external AF to inform about the application started, UE location, network conditions, etc., and it is therefore not a widely deployed mechanism.

Patent application <CIT> discloses methods by which User Plane (UP) management information is exchanged between an Application Function (AF) supporting one or more applications and a Slice Management Function (SMF) configured to manage traffic flows in a given slice of the network.

3GPP draft S4-<NUM> discloses a solution related to Conditional and Dynamic Policies for Application Instances involving the NEF and PCF nodes.

Patent application <CIT> discloses a policy control function determining a policy and charging control rule comprising one or more Ethernet source MAC addresses and a quality of service policy. The policy control function may send the policy and charging control rule to a session management function to provide an Ethernet PDU session for a wireless device.

<NPL>) discloses the general 3GPP <NUM> system architecture and procedures.

The invention is defined by the independent claims that accompany this disclosure. Any examples and embodiments of the description not falling within the scope of the claims do not form part of the invention as defined by the independent claims.

An object of the invention is to enable the provision of policy rules from a User Equipment to a mobile communication system, being the policy rule applicable to a data session between the UE and an Application Server (AS) and enforceable at a User Plane (UP) entity.

A first aspect of the invention relates to a method performed by a UE for providing a policy rule from the UE to a mobile communication system. The method includes establishing a communication channel with the UP entity of the mobile communication system and sending the policy rule through the communication channel to the UP entity. In an embodiment of the method, the policy rule is sent together with information for identifying and classifying at the UP entity the traffic of the data session between the UE and the AS, particularly wherein the information is one of an application identifier, an AS identifier and a traffic filter. In an embodiment of the method, the communication channel is established at application level, the data session between the UE and the AS is at application level, and the UP entity acts as application level proxy in the communication between the UE and the AS. In an embodiment of the method, the communication channel protocol corresponds to Quick User Datagram Protocol (UDP) Internet Connections (QUIC) protocol, and the data session corresponds to a QUIC connection. In an embodiment of the method, the communication channel is established at network level, the data session between the UE and the AS is at network level, and the UP entity acts as a network level gateway in the communication between the UE and the AS. In an embodiment of the method, the communication channel protocol corresponds to General Packet Radio Service (GPRS) Tunneling Protocol (GTP) protocol, and the data session corresponds to a Packet Data Unit, PDU, session. The method further includes receiving from the UP entity, an indication of whether the policy rule is accepted or rejected by the mobile communication system.

A second aspect of the invention relates to a method performed by a User Plane (UP) entity for handling a policy rule sent from a UE to a mobile communication system, being the policy rule applicable to a data session between the UE and an AS and enforceable at the UP entity. The method includes establishing a communication channel with the UE and receiving the policy rule through the communication channel from the UE. In an embodiment of the method, the policy rule is received together with information for identifying and classifying at the UP entity the traffic of the data session between the UE and the AS, particularly wherein the information is one of an application identifier, an AS identifier and a traffic filter. In an embodiment of the method, the communication channel is established at application level, the data session between the UE and the AS is at application level, and the UP entity acts as application level proxy in the communication between the UE and the AS. In an embodiment of the method, the communication channel protocol corresponds to Quick User Datagram Protocol (UDP) Internet Connections (QUIC) protocol, and the data session corresponds to a QUIC connection. In an embodiment of the method, the communication channel is established at network level, the data session between the UE and the AS is at network level, and the UP entity acts as a network level gateway in the communication between the UE and the AS. In an embodiment of the method, the communication channel protocol corresponds to General Packet Radio Service (GPRS) Tunneling Protocol (GTP) protocol, and the data session corresponds to a Packet Data Unit, PDU, session. The method further includes sending to the UE, an indication of whether the policy rule is accepted or rejected by the mobile communication system. The method further includes authorizing the application of the policy rule for the data session between the UE and the AS. In an embodiment of the method, the authorizing step comprises sending to a Control Plane (CP) entity an authorization request for the policy rule for the data session between the UE and the AS and receiving the corresponding authorization response from the CP entity. In an embodiment of the method, the CP entity is a Session Management Function, SMF. The method further includes sending to a Control Plane (CP) entity an authorization request for the policy rule for the data session between the UE and the AS.

A third aspect of the invention relates to a method performed by a Control Plane (CP) entity for authorizing a policy rule for a data session between a User Equipment (UE) and an Application Server (AS). The method includes receiving from a mobile communication entity an authorization request for the policy rule for the data session between the UE and the AS, authorizing the policy rule for the data session between the UE and the AS and sending to the mobile communication entity an authorization response indicating whether the policy rule for the data session between the UE and the AS is accepted or rejected. In an embodiment of the method, the CP entity is a session management entity, the mobile communication entity is a User Plane (UP) entity, the authorizing step comprises sending to a second CP entity an authorization request for the policy rule for the data session between the UE and the AS, and the authorizing step comprises receiving from the second CP entity an authorization response indicating whether the application of the policy rule for the data session between the UE and the AS is accepted or rejected. In an embodiment of the method, the CP entity is a policy control entity, the mobile communication entity is a second CP entity, the authorizing step comprises retrieving from a user data repository the policy rules that apply for the data sessions between the UE and the AS, and the authorizing steps comprises comparing the policy rule with the policy rules retrieved from the user data repository.

Other aspects of the invention relate to mobile network nodes, particularly a UE, a UP entity and a CP entity, each configured to perform the respective methods as described herein. Other aspects of the invention relate to computer program and computer program products.

In some embodiments of these aspects, the UP entity is a User Plane Function (UPF), a COPE entity, or a UPF including a COPE entity. In some embodiments of these aspects, the CP entity is a Session Management Function (SMF) or a Policy Control Function (PCF).

In some embodiments, a policy API sits between the COPE client (at UE) and the COPE entity (at the Core Network) in order to allow the content provider to request policies to the network operator relative to content provider's application traffic.

Advantageously, the solution disclosed herein enables a mechanism for the content provider to request user plane policy rules to be enforced by the network operator relative to the traffic of the content provider's applications, which is quicker and involves less signaling load than existing solutions, since the policy rules can be sent directly from the UE and subsequently authorized and enforced at the UP entity handling the UP connections for that UE.

Further advantageously, the solution disclosed herein enables a mechanism for the content provider to request user plane policy rules to be enforced by the network operator relative to the traffic of the content provider's applications, when the network operator does not support north bound interfaces in the Control Plane for applications to make such policy requests, for example, those interfaces exposed by a Network Exposure Function (NEF).

The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate particular embodiments of the invention. In the drawings:.

The invention will now be described in detail hereinafter with reference to the accompanying drawings, in which examples of embodiments or implementations of the invention are shown. The invention may, however, be embodied or implemented in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present invention to those skilled in the art.

It will be appreciated that example embodiments described herein arise in the context of a telecommunications network, including but not limited to a telecommunications network that conforms to and/or otherwise incorporates aspects of a fifth generation (<NUM>) architecture. <FIG> is an example networked system <NUM> in accordance with example embodiments of the present disclosure. <FIG> specifically illustrates User Equipment (UE) <NUM>, which may be in communication with a (Radio) Access Network (RAN) <NUM> and Access and Mobility Management Function (AMF) <NUM> and User Plane Function (UPF) <NUM>. The AMF <NUM> may, in turn, be in communication with core network services including Session Management Function (SMF) <NUM> and Policy Control Function (PCF) <NUM>. The core network services may also be in communication with an Application Server/ Application Function (AS/AF) <NUM>. Other networked services also include Network Slice Selection Function (NSSF) <NUM>, Authentication Server Function (AUSF) <NUM>, User Data Management (UDM) <NUM>, Network Exposure Function (NEF) <NUM>, Network Repository Function (NRF) <NUM> and Data Network (DN) <NUM>. In some example implementations of embodiments of the present disclosure, an AMF <NUM>, SMF <NUM>, UPF <NUM>, PCF <NUM>, AUSF <NUM>, NRF <NUM>, UDM <NUM>, NEF <NUM>, AF <NUM>, and NSSF <NUM> are each considered to be an NF. It will be appreciated that one or more additional network functions (NF) may be incorporated into the networked system.

The solution described herein aims to allow policy requests from the UE side. The use of such a solution may be for content providers to request policies to the communications network by means of a client application installed in the UE. Examples of such policy requests may be for example the enforcement of specific Quality of Service parameters, or the application of specific traffic routing rules.

To achieve such object, this disclosure provides a method performed by a User Equipment (UE) <NUM>, a User Plane (UP) entity <NUM>, and Control Plane (CP) entities <NUM>. In some embodiments, the UP entity is a UPF <NUM>. In some embodiments, the Control Plane (CP) entities are an SMF <NUM>, PCF <NUM> and UDR <NUM>. Another entity taking part of the solution is an Application Server (AS) <NUM>.

The method comprises establishing a communication channel from the UE with the UP entity of a mobile communication system; and sending a policy rule through the communication channel from the UE to the UP entity. In some embodiments of the method, the policy rule is sent together with information for identifying and classifying at the UP entity the traffic of the data session between the UE and the AS, particularly wherein the information is one of an application identifier, an AS identifier and a traffic filter. In some embodiments of the method, the communication channel is established at application level, the data session between the UE and the AS is at application level, and the UP entity acts as application level proxy in the communication between the UE and the AS. In some embodiments of the method, the communication channel protocol corresponds to Quick User Datagram Protocol, UDP, Internet Connections, QUIC, protocol, and the data session corresponds to a QUIC connection. In some embodiments of the method, the communication channel is established at network level, the data session between the UE and the AS is at network level, and the UP entity acts as a network level gateway in the communication between the UE and the AS. In some embodiments of the method, the communication channel protocol corresponds to General Packet Radio Service, GPRS, Tunnelling Protocol, GTP, protocol, and the data session corresponds to a Packet Data Unit, PDU, session. In some embodiments the method further comprises receiving at the UE from the UP entity, an indication of whether the policy rule is accepted or rejected by the mobile communication system. In some embodiments the method further comprises authorizing from the UP entity the application of the policy rule for the data session between the UE and the AS. In some embodiments of the method, the authorizing step comprises sending to a Control Plane, CP, entity an authorization request for the policy rule for the data session between the UE and the AS. In some embodiments of the method, the CP entity is a Session Management Function, SMF. In some embodiments the method further comprises receiving from the CP entity an authorization response indicating whether the application of the policy rule for the data session between the UE and the AS is accepted or rejected. In some embodiments the method further comprises sending from the UP entity to the UE, an indication of whether the policy rule is accepted or rejected by the mobile communication system. In some embodiments the method further comprises receiving at the CP entity from a mobile communication entity an authorization request for the policy rule for the data session between the UE and the AS; authorizing the policy rule for the data session between the UE and the AS; and sending to the mobile communication entity an authorization response indicating whether the policy rule for the data session between the UE and the AS is accepted or rejected. In some embodiments of the method, the CP entity is a session management entity, the mobile communication entity is a User Plane, UP, entity, the authorizing step comprises sending to a second CP entity an authorization request for the policy rule for the data session between the UE and the AS, and the authorizing step comprises receiving from the second CP entity an authorization response indicating whether the application of the policy rule for the data session between the UE and the AS is accepted or rejected. In some embodiments of the method, the CP entity is a policy control entity, the mobile communication entity is a second CP entity, the authorizing step comprises retrieving from a user data repository the policy rules that apply for the data sessions between the UE and the AS, and the authorizing steps comprises comparing the policy rule with the policy rules retrieved from the user data repository.

This disclosure also provides mobile network nodes, particularly a User Equipment (UE) <NUM>, a User Plane (UP) entity <NUM>, and Control Plane (CP) entities <NUM> and <NUM>, each configured to perform their respective methods as described in this disclosure. This disclosure also provides the corresponding computer program and computer program products comprising code, for example in the form of a computer program, that when run on processing circuitry of the mobile network nodes causes the mobile network nodes to perform the disclosed methods.

In some embodiments the mobile network incorporates a COPE. In some embodiments, the COPE is a proxy at network operator premises. Different deployments for the proxy may be an implementation at UPF/PGW-U, for example as a service assuming a service based UPF, as a module, or as a library, as an embedded SF (Service Function) in a service chaining architecture, as an external SF (Service Function) in a service chaining architecture or as an AF (Application Function).

In some embodiments, a policy API sits between the COPE client/server (at content provider) and the COPE entity (at network operator) in order to allow the content provider to request policies to the network operator relative to content provider's application traffic. Some embodiments may include a mechanism (at network operator) to authorize the requested policies.

In some embodiments, the policy API terminates at UPF. That is, the COPE entity at UPF terminates the policy API. In some embodiments, the policy API terminates at SMF. That is, the Policy API is terminated at SMF by configuring UPF to forward to SMF the original policy request message from the content provider. In some embodiments, the UPF decrypts the policy request before forwarding it to SMF. In some embodiments, the PFCP protocol is extended, specifically the FAR to include a (new) Decrypt IE. In some embodiments, the policy API terminates at a separate SF. In this scenario, the COPE is implemented as a separate SF that may be still embedded in the UPF to leverage on some internal service communication capabilities.

In some embodiments, the requested policies are forwarded from the UP entity to a CP entity. In some embodiments, the requested policies are forwarded from UPF to SMF by extending PFCP protocol with a PFCP Session Modification Request message triggered by UPF.

In some embodiments, the requested policies are forwarded from SMF to PCF by extending Npcf with a (new) Npcf_Policy request triggered by SMF. In some embodiments, the requested policies are pre-authorized by CP, e.g. UPF or SMF could have preconfigured policies in order to avoid interaction with PCF.

In some embodiments, the requested policies (by the client) are further conveyed on the CP towards the PCF using Npcf_PolicyAuthorization and then PCF updates the session policies (through SMF). This scenario assumes that the COPE proxy acts as an internal AF towards the PCF potentially discovering the PCF through the BSF.

The solution disclosed herein enables a mechanism for the content provider to request user plane policy rules to be enforced by the network operator relative to the traffic of the content provider's applications, which is quicker and involves less signaling load than existing solutions, since the policy rules can be sent directly from the UE and subsequently authorized and enforced at the UP entity handling the UP connections for that UE.

The solution disclosed herein enables a mechanism for the content provider to request user plane policy rules to be enforced by the network operator relative to the traffic of the content provider's applications, when the network operator does not support north bound interfaces in the Control Plane for applications to make such policy requests, for example, those interfaces exposed by a Network Exposure Function (NEF).

Hereinafter, drawings showing examples of embodiments of the solution are described in detail.

<FIG> is a signaling diagram illustrating a procedure for providing a policy rule from a User Equipment (UE) <NUM> to a mobile communication system, wherein the policy rule is applicable to a data session between the UE and an Application Server (AS) <NUM> and is enforceable at a User Plane, UP, entity <NUM>. The policy rule is authorized by a mechanism performed by Control Plane (CP) entities <NUM>. The UP entity is a UPF <NUM>. The CP entities are an SMF <NUM>, PCF <NUM> and UDR <NUM>. The policy API is terminated at UPF and requested policies are forwarded from UP to CP for authorization. An example of a UE application (e.g. YouTube) is used for requesting policies to be enforced by the network operator for the application's traffic. Prior to the execution of this procedure, the content provider may have an SLA in place with the network operator, the UE's PDU session shall be already established and the application client/server (e.g. QUIC client/server) has already established inner and outer connections to the COPE (e. QUIC proxy), as indicated in <FIG>. The COPE is assumed to be integrated in UPF. In some other embodiments, the COPE is an AF or a SF (which could be an embedded SF or external SF to UPF).

At step <NUM>, the UE opens the application (e.g. YouTube) using QUIC as transport protocol.

At step <NUM>, before starting the application traffic (e.g. YouTube traffic), the UE's application entity (e.g. YouTube app), acting as QUIC client, uses the inner QUIC connection with the COPE (acting as QUIC Proxy) at UPF to trigger a Policy Activation Request message, including the following information: appId=YouTube, to identify the application; flowlnformation (which includes the flow information, e.g. <NUM>-tuple/s, that will allow the network operator to identify the traffic which corresponds to the above appld); and policylnformation (which includes the policies requested by the content provider to be enforced by the network operator for application's traffic). The policies could be for example a certain QoS or Charging treatment.

At step <NUM>, UPF stores the flowlnformation and triggers a policy request to SMF.

At step <NUM>, the UPF sends to SMF a PFCP Session Modification Request including the following information: appId=YouTube, to identify the application; policylnformation (which includes the policies requested by the content provider to be enforced by the network operator for application's traffic). The policies could be for example a certain QoS or Charging treatment.

At step <NUM>, SMF triggers a policy request to PCF by means of a Npcf_Policy request message including the following information: appId=YouTube, to identify the application; policylnformation (which includes the policies requested by the content provider to be enforced by the network operator for application's traffic). The policies could be for example a certain QoS or Charging treatment.

At step <NUM>, based on the received appId, PCF sends to UDR a request for any potential default policy for the appId for this subscriber. PCF triggers a Nudr_Query request message to UDR including the following information: susbcriberld, to identify the subscriber; appId=YouTube, to identify the application.

At step <NUM>, UDR looks for the subscriber's default policy for the requested application.

At step <NUM>, UDR replies to PCF with a Nudr_Query response message including defaultPolicylnformation.

At step <NUM>, PCF checks if the requested policy (policylnformation) is allowed (possibly considering the defaultPolicylnformation). In this embodiment it is allowed (e.g. as per SLA).

At step <NUM>, PCF replies to SMF with a Npcf_Policy response message (indicating successful operation).

At step <NUM>, SMF answers UPF with a PFCP Session Modification Response message indicating successful operation.

At step <NUM>, UPF responds to the message in step <NUM> by triggering a Policy Activation Response (indicating successful operation) to the UE's application entity (YouTube app), acting as QUIC client, using the inner QUIC connection.

At step <NUM>, the UE's application (YouTube app) starts sending application (YouTube) traffic.

At step <NUM>, UPF detects and classifies application (YouTube) traffic by matching it against the flowInformation (previously stored in Step <NUM>) and applies the corresponding policies indicated in policylnformation.

At step <NUM>, UPF forwards the application's traffic towards the Application Server (AS).

In some embodiments, at PDU session establishment, PCF could activate a predefined PCC rule for the application (e.g. appId=YouTube), to indicate SMF (and UPF) that it is allowed for the UE's application client to request certain policies (preconfigured at UPF), so they do not need to be checked by PCF and they can be enforced directly. UPF will check the UE's application client requested policies based on this local configuration.

<FIG> is a flowchart illustrating a method performed by a UE for providing a policy rule to a mobile communication system, wherein the policy rule is applicable to a data session between the UE and an Application Server, AS, and is enforceable at a UP entity. In some embodiments, the UP, entity is a UPF.

At step <NUM>, the UE establishes a communication channel with the UP entity of the mobile communication system.

At step <NUM>, the UE sends the policy rule through the communication channel to the UP entity.

At step <NUM>, the UE receives from the UP entity, an indication of whether the policy rule is accepted or rejected by the mobile communication system.

<FIG> is a flowchart illustrating a method performed by a UP entity for handling a policy rule sent from a UE to a mobile communication system, wherein the policy rule is applicable to a data session between the UE and an Application Server (AS) and is enforceable at the UP entity. In some embodiments, the UP, entity is a UPF.

At step <NUM>, the UP entity establishes a communication channel with the UE.

At step <NUM>, the UP entity receives the policy rule through the communication channel from the UE.

At step <NUM>, the UP entity may authorize the application of the policy rule for the data session between the UE and the AS. In some embodiments, the UP entity already has the proper authorization rules to perform this step without interacting with other entities.

At step <NUM>, the UP entity may send to a Control Plane (CP) entity an authorization request for the policy rule for the data session between the UE and the AS and receives the corresponding authorization response from the CP entity. In some embodiments this step is performed by sending to a Control Plane (CP) entity an authorization request for the policy rule for the data session between the UE and the AS, and subsequently receiving the corresponding authorization response. In some embodiments, the CP entity is an SMF.

At step <NUM>, the UP entity sends to the UE an indication of whether the policy rule is accepted or rejected by the mobile communication system.

<FIG> is a flowchart illustrating a method performed by a CP entity for authorizing a policy rule for a data session between a UE, and an Application Server (AS). The authorization request is received from a mobile communication entity. To authorize the policy rule, the CP entity sends a further authorization request to a second CP entity. In some embodiments, the CP entity is a SMF, the mobile communication entity is a UPF, and the second CP entity is a PCF. In some embodiments, the CP entity is a PCF, the mobile communication entity is a SMF and the second CP entity is a UDR.

At step <NUM>, the CP entity receives from the mobile communication entity an authorization request for the policy rule for the data session between the UE and the AS.

At step <NUM>, the CP entity authorizes the policy rule for the data session between the UE and the AS.

In some embodiments, the CP entity is a session management entity, the mobile communication entity is a UP entity, the authorizing step comprises sending to a second CP entity an authorization request for the policy rule for the data session between the UE and the AS, and the authorizing step comprises receiving from the second CP entity an authorization response indicating whether the application of the policy rule for the data session between the UE and the AS is accepted or rejected. In some embodiments the session management entity is a SMF. In some embodiments, the second CP entity is a PCF.

In some embodiments, the CP entity is a policy control entity, the mobile communication entity is a second CP entity, the authorizing step comprises retrieving from a user data repository the policy rules that apply for the data sessions between the UE and the AS, and the authorizing steps comprises comparing the policy rule with the policy rules retrieved from the user data repository. In some embodiments the policy control entity is a PCF. In some embodiments, the user data repository is a UDR.

At step <NUM>, the CP entity sends to the mobile communication entity an authorization response indicating whether the policy rule for the data session between the UE and the AS is accepted or rejected.

<FIG> is a block diagram illustrating elements of a mobile network node <NUM> of a communication network configured to provide cellular communication according to some embodiments. As shown, the mobile network node may include network interface circuitry <NUM> (also referred to as a network interface) configured to provide communications with other nodes of the core network and/or the network. The mobile network node may also include a processing circuitry <NUM> (also referred to as a processor) coupled to the network interface circuitry, and memory circuitry <NUM> (also referred to as memory) coupled to the processing circuitry. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that a separate memory circuitry is not required.

As discussed herein, operations of the mobile network node may be performed by processing circuitry <NUM> and/or network interface circuitry <NUM>. For example, processing circuitry <NUM> may control network interface circuitry <NUM> to transmit communications through network interface circuitry <NUM> to one or more other network nodes and/or to receive communications through network interface circuitry from one or more other network nodes. Moreover, modules may be stored in memory <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to core network nodes).

In some embodiments, the mobile network node <NUM> is a UPF.

In some embodiments, the mobile network node <NUM> is a SMF. In some embodiments, the mobile network node <NUM> is a PCF.

<FIG> is a block diagram illustrating elements of a UE <NUM> (also referred to as a communication device, a mobile terminal, a mobile communication terminal, a wireless device, a wireless communication device, a wireless terminal, mobile device, a wireless communication terminal, user equipment, UE, a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of the disclosure. As shown, communication device UE may include an antenna <NUM>, and transceiver circuitry <NUM> (also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with a base station(s) (also referred to as a RAN node) of a radio access network. The UE may also include processing circuitry <NUM> (also referred to as a processor) coupled to the transceiver circuitry, and memory circuitry <NUM> (also referred to as memory, e.g. corresponding to device readable medium) coupled to the processing circuitry. The memory circuitry <NUM> may include computer readable program code, such as application client <NUM>, that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that separate memory circuitry is not required. The UE <NUM> may also include an interface (such as a user interface) coupled with processing circuitry <NUM>, and/or the UE may be incorporated in a vehicle.

Claim 1:
A method for providing a policy rule from a User Equipment, UE, (<NUM>) to a mobile communication system (<NUM>), wherein the policy rule is applicable to a data session between the UE (<NUM>) and an Application Server, AS, (<NUM>) and is enforceable at a User Plane, UP, entity (<NUM>); the method being performed by the UE (<NUM>) and comprising:
establishing a communication channel with the UP entity of the mobile communication system; and
sending (<NUM>) the policy rule through the communication channel to the UP entity.