Patent ID: 12255780

DETAILED DESCRIPTION

As will be explained below a user plane based exposure mechanism is provided which allows a content provider to exchange information in an efficient way with a network operator. As the content providers application traffic always goes through the user plane, the user plane entity or user plane function, the user plane function could be used as entry point in the operator's network instead of the network exposure function as it is currently the case for a control plane based approach. In the present context exposure means an exposure operating mode in which a content provider operating the application entity informs the cellular network about the policy to be applied to the data packet flow in the cellular network.

In the following the terms entity or function are used interchangeably. Accordingly, the application function can be considered as application entity, the policy control function as policy control entity or the user plane entity as user plane function.

The situation is shown inFIG.3. In the area of the network operator the network exposure function15is provided, wherein the control plane entity user plane is schematically shown in the operator-based area. The user plane could be implemented by the user plane entity200. The content provider is located in the OTT, over the top, area and an application entity controlled by the content provider provides a data packet flow to a user equipment not shown inFIG.3.

As shown inFIG.3the exposure mechanism, the management of the policies etc. is carried out in the user plane and not in the control plane.

The application covers two main aspects:

the first aspect is the discovery of the user plane entity. Here, a mechanism is proposed for the application entity or the application client provided on the user equipment to discover the user plane entity which handles the data packet session such as the PDU session for the user equipment in the cellular network. To this end, it is proposed to extend the architecture with a service-based operator DNS, Domain Name Server, or translating entity, which offers an Ndns interface and with a service-based user plane entity which office an Nupf interface. The DNS server is also named as translating entity hereinafter as the translating entity is configured to translate the name of the application entity to the address of the application entity.

A second aspect covered by the present application is the exposure itself meaning the mechanism proposed at application level. The exposure information is exchanged between the content provider and the network operator and does not have any impact on the UE itself, mainly the application provided on the UE may carry out the steps mentioned below in which the UE is involved. At the content provider it is the application client or the application layer at the UE and/or the application server on the sending or receiving side to expose the information to the user plane entity or from the user plane entity.

FIG.4shows the new architecture with the entities involved. As will be explained below the user equipment100, the user plane entity200, the PCF300and the DNS server or translating entity700are amended by the present approach. The other functions are entity as shown inFIG.4may correspond to the entities or functions discussed above in connection withFIG.1or may also be amended in order to communicate with the entities mentioned above, namely, the UE100, the user plane entity200, the policy control entity300, or the translating entity700.

In the following a sequence diagram is discussed in more detail as shown inFIGS.5and6which illustrates an example use case where a content provider such as an application at the UE having the name of example.com requests policies to be enforced by the network operator.

One present assumption is that there is a service level agreement, SLA, between the content provider and the network operator. Accordingly, a user plane exposure mechanism is used for the content provider to exchange information with the network operator, especially for the content provider to request policies regarding the content provider's applications to be enforced by the network operator.

At the network operator the knowledge is pre-provisioned at the UDR database on a per subscriber basis as part of the subscriber policy. Alternatively, the above can be pre-provisioned on a per group of subscribers, on a per slice basis and/or on a per global basis. Furthermore, at the content provider the application client at the UE is pre-provisioned with the network operator's DNS server information such as the IP address or the FQDN, Fully Qualified Domain Name, of the network operator's DNS server.

Reference is now made toFIGS.5and6:

in the example below the steps are explained for a 4G or 5G implementation. It should be understood that the method can be implemented in any other cellular network.

Steps S1and S2) At PFCP Association procedure between UPF and SMF entities, it is proposed to extend the existing mechanism to report UPF capabilities with a new capability (EXPU, see table below in bold). This would allow SMF to know which UPFs support this capability and thus can influence on UPF selection. (a possible 5G implementation would be PFC Association Request, UPF capabilities: EXPU; PFCP Association Response)

FeatureOctet/BitFeatureInterfaceDescription5/1BUCPSxa, N4Downlink Data Buffering in CP function is supportedby the UP function.5/2DDNDSxa, N4The buffering parameter ‘Downlink Data NotificationDelay’ is supported by the UP function.5/3DLBDSxa, N4The buffering parameter ‘DL Buffering Duration’ issupported by the UP function.5/4TRSTSxb, Sxc, N4Traffic Steering is supported by the UP function.5/5FTUPSxa, Sxb, N4F-TEID allocation/release in the UP function issupported by the UP function.5/6PFDMSxb, Sxc, N4The PFD Management procedure is supported bythe UP function.5/7HEEUSxb, Sxc, N4Header Enrichment of Uplink traffic is supported bythe UP function.5/8TREUSxb, Sxc, N4Traffic Redirection Enforcement in the UP function issupported by the UP function.6/1EMPUSxa, Sxb, N4Sending of End Marker packets supported by the UPfunction.6/2PDIUSxa, Sxb, Sxc, N4Support of PDI optimised signalling in UP function(see clause 5.2.1A.2).6/3UDBCSxb, Sxc, N4Support of UL/DL Buffering Control6/4QUOACSxb, Sxc, N4The UP function supports being provisioned with theQuota Action to apply when reaching quotas.6/5TRACESxa, Sxb, Sxc, N4The UP function supports Trace (see clause 5.15).6/6FRRTSxb, N4The UP function supports Framed Routing (seeIETF RFC 2865 [37] and IETF RFC 3162 [38]).6/7PFDESxb, N4The UP function supports a PFD Contents includinga property with multiple values.6/8EPFARSxa, Sxb, Sxc, N4The UP function supports the Enhanced PFCPAssociation Release feature (see clause 5.18).7/1DPDRASxb, Sxc, N4The UP function supports Deferred PDR Activationor Deactivation.7/2ADPDPSxa, Sxb, Sxc, N4The UP function supports the Activation andDeactivation of Pre-defined PDRs (see clause 5.19).7/3UEIPN4The UPF supports allocating UE IP addresses orprefixes (see clause 5.21).7/4SSETN4UPF support of PFCP sessions successivelycontrolled by different SMFs of a same SMF Set(see clause 5.22).7/5MNOPSxa, Sxb, Sxc, N4UPF supports measurement of number of packetswhich is instructed with the flag ‘Measurement ofNumber of Packets’ in a URR. See also 5.2.2.2.1.7/6MTEN4UPF supports multiple instances of Traffic EndpointIDs in a PDI.7/7BUNDLSxa, Sxb, Sxc, N4PFCP messages bunding (see clause 6.5) issupported by the UP function.7/8GCOMN4UPF support of 5G VN Group Communication. (Seeclause 5.23)8/1MPASN4UPF support for multiple PFCP associations to theSMFs in an SMF set (see clause 5.22.3).8/2RTTLN4The UP function supports redundant transmission attransport layer.8/3VTIMESxb, N4UPF support of quota validity time feature.8/4EXPUSxb, Sxc, N4UP Exposure is supported by the UP function.Feature Octet/Bit: The octet and bit number within the Supported-Features IE, e.g. “5.1”.Feature: A short name that can be used to refer to the octet/bit and to the feature.Interface: A list of applicable interfaces to the feature.Description: A clear textual description of the feature.

Steps S3and S4) UE triggers PDU session establishment, by means of sending a N1 PDU Session Establishment Request to AMF. AMF selects an SMF to manage the PDU session, wherein the SMF selection function in the AMF selects an SMF instance based on the available SMF instances obtained from NRF or on the configured SMF information in the AMF and triggers Nsmf PDU Session Create Request. The sequence diagram inFIG.5does not include all the signaling messages involved in the PDU Session Establishment procedure. The relevant signaling messages are described in subsequent steps. (N1 PDU Session Establishment Request; Nsmf PDU Session Create Request)

Step S5) SMF triggers towards PCF a Npcf_SMPolicyControl_Create Request message to retrieve SM policies for the user PDU session. (Npct_SMPolicyControl_Create Request)

Step S6) PCF triggers towards UDR a Nudr_Query Request message to retrieve the policy data for this user's PDU session. (Nudr_Query Request)

Step S7) UDR answers PCF with Nudr_Query Response message including the Subscriber Policy Data, which includes (as Subscriber Policy Data) an indication (e.g. flag) to activate the UP Exposure mechanism. (Nudr_Query Response, {Subscriber Policy Data including UP Exposure})

Steps S8and S9) Based on the above Subscriber Policy Data, PCF decides to activate the UP Exposure mechanism for this PDU session. In order to do that, PCF triggers Npcf_SMPolicyControl_Create Response message with an indication to activate the UP Exposure mechanism. (PCF requests activation of the UP Exposure mechanism for this PDU session; Npcf_SMPolicyControl_Create Response, {UP Exposure})

Step S10) Based on the above indication, SMF selects a UPF supporting the UP Exposure mechanism (EXPU) capability. (SMF selects a UPF supporting EXPU capability)

Step S11) SMF triggers PFCP Session Establishment Request message with an indication to activate the UP Exposure mechanism. It is proposed to do this via installing/activating a PDR with appId=“UP Exposure”, which indicates UPF to detect UP Exposure related messages (e.g. messages where the destination IP address is the one of the UPF). (PFCP Session Establishment Request; {UP Exposure})

Step S12) UPF runs the following logic:Activates the UP Exposure channel for this PFCP session This is basically listening to policy request messages from the content provider. As mentioned in previous step, UPF will detect incoming packets and look for a match with the PDR with appId=“UP Exposure” (where appId=“UP Exposure” is locally configured at UPF to match any message where the destination IP address is the one of the UPF).Retrieves the UPF instance identifier (UPFId) handling the PDU session, which could be simply the UPF IP address of the interface that will be used as destination address for policy request messages from the content provider. Other identifiers are possible (e.g. FQDN).

(UPF activates UP Exposure and stores the UPF instance (UPFId) for the UE (UEId) in UDR)

Step S13) UPF stores in UDR the UPF instance (UPFId) handling the PDU session. In order to do this, UPF triggers a Nudr_Store request message including both the UEId and the UPFId. This assumes an SBA based UPF which is able to directly access UDR. (Nudr_Store Request, {UEId, UPFId})

Steps S14and S15) UDR stores the association between the UEId and the UPFId and answers back UPF with a successful response (200 OK). (UDR Stores the association between the UEId and the UPFId; 200 OK)

Step S16) UPF answers back to SMF with a successful PFCP Session Establishment Response message. (PFCP Session Establishment Response)

Step S17) SMF answers the Nsmf PDU Session Create Request in Step4with a Nsmf PDU Session Create Response to AMF. (Nsmf PDU Session Create Response)

Step S18) AMF answers the N1 PDU Session Establishment Request in Step S3with a N1 PDU Session Establishment Response to UE. (N1 PDU Session Establishment Response)

Steps S19and S20) An application (e.g. example.com) with support of UP Exposure is started. The application client triggers UPF discovery by sending a DNS Query message towards Operator DNS Server (see preconditions on how UE application gets the identity of the Operator DNS Server). The DNS Query includes as parameters:FQDN (e.g. operatorX.upf.com) indicating request for the UPF instance handling the PDU sessionUEId which identifies the UE (and/or subscriber)

(An application (e.g. example.com) with support of UP Exposure is started. The application client triggers UPF discovery; DNS Query, {FQDN=operator.upf.com, UEId})

Step S21) Operator DNS Server triggers a Nudr_Query request message towards UDR in order to find the UPF instance handling the PDU session for this UE (UEId). (Nudr Query Request, {UEId, UPF})

Steps S22and S23) UDR looks for the UPF instance (UPFId) associated to UEId, and answers back to Operator DNS Server with a Nudr_Query response message including the UPF instance (UPFId). (UDR looks for the UPF instance (UPFId) associated to UEId; Nudr_Query Response, {UPFId})

Step S24) Operator DNS Server answers UE application client with a DNS Answer message including the UPF instance identifier (UPFId). (DNS Answer, {UPDFId})

Steps S25and S26) UE application client stores the UPF instance identifier (UPFId) handling the PDU session (e.g. UPF IP address, that will be used as destination IP address for any UP Exposure message during this user's PDU session). The UE application client sets up the exposure channel towards the discovered UPF (UPFId). In order to do this, UE application client triggers a Nupf_Policy request (HTTPS POST) including as parameters:appId=example.comflowInformation, which includes the flow information, e.g. 5-tuple/s, that will allow the network operator to identify the traffic which corresponds to the above appId.policyInformation, indicating the requested policy for the application, e.g. Sponsored data or a certain QoS handling.

(The application client setups the exposure channel towards the discovered UPF; Nupf_Policy request (HTTPS POST), {appId=example.com, flowinformation, policyinformation)

Steps S27and S28) UPF detects the above message (which matches the PDR with appId=“UP Exposure” referred in Step S11above) and stores the flowInformation and triggers a policy request to PCF by sending a Npcf_Policy request (HTTPS POST) message including as parameters:appId=example.compolicyInformation, indicating the requested policy for the application, e.g. Sponsored data or a certain QoS handling.

(UPF stores the flowInformation and triggers a policy request to PCF; Npct_Policy request (HTTPS POST), {appId=example.com, policyInformation})

Steps S29and S30) PCF checks if the requested policy is allowed. If so, it answers back to UPF with a successful response (200 OK). (PCF checks if the requested policy is allowed; 200 OK)

Step S31) UPF answers the message in Step26above with a successful response (200 OK). (200 OK)

Steps S32, S33and S34) UPF detects and classifies application (example.com) traffic by matching it against the flowInformation and applies the corresponding policies indicated in policyInformation (e.g. Sponsored data and/or QoS handling). (example.com traffic; UPF detects and classifies application (example.com) traffic by matching it against the flowInformation and applies the corresponding policies indicated in policyInformation; example.com traffic)

Finally, the solution described in this application does not only apply to 5G network architecture, but the same mechanisms can be applied to 4G, just by replacing:PCF by PCRFSMF by PGW-C or TDF-CUPF by PGW-U or TDF-U.

FIG.7summarizes some of the steps carried out by the user equipment100in the method discussed above in connection withFIGS.5and6. In step S71the user equipment transmits a request to the translating entity to identify the user plane entity. This request requests the translating entity to identify the user plane entity which can handle the data packet flow in the cellular network as discussed above in step S20. Furthermore, the user equipment receives a response from the translating entity comprising the identifier of the user plane entity as mentioned above in step S24.

Furthermore, a policy request is transmitted to the identified user plane entity which informs the user plane entity of the policy to be applied to the data packet flow. This was discussed above in step S26.

FIG.8summarizes some of the steps carried out at the user plane entity in the method mentioned inFIGS.5to6. In a first step S81the user plane entity receives a policy request which comprises a flow identifier which helps to identify the data packet flow in the cellular network. This policy request, also named first policy request, additionally comprises the policy information indicating the policy to be applied to the data packet flow in the network. This was discussed above in step S26. The user plane entity then transmits a policy request to the policy control entity300wherein this policy request, also comprises the flow identifier and the policy information. This was discussed above in connection with step S28. Furthermore, in step S83a confirmation is received from the policy control entity that the transmitted policy is allowed as discussed above in connection with step S30.

FIG.9summarizes the steps for the policy control entity. In step S91the policy control entity receives the policy request from the user plane entity. This step describes the receiving side from step S82discussed inFIG.8and step S28ofFIG.6. In step S92the policy control entity checks if the requested policy is allowed as discussed in step S29above. In step S93the policy control entity then transmits a response to the user plane entity that the policy as received from the user plane entity is allowed. This was discussed above in step S30.

FIG.10summarizes the steps carried out at the translating entity or DNS server. In step S101the translating entity receives the request from the UE which requests an identification of the user plane entity configured to handle the data packet flow in the present scenario. This was discussed above inFIG.6in connection with step S20. In step S102the translating entity transmits a request to a subscriber database to identify the user plane entity which can handle the data packet flow. This was discussed above in connection with step S21. The translating entity then receives a response in step S103, wherein this response comprises the user plane identifier identifying the user plane entity. Finally, in step S104the translating entity transmits the information about the user plane entity to the user equipment as mentioned in step S24above.

FIG.11shows a schematic architectural view of a user equipment100involved in the different method steps above. The user equipment100comprises an interface or input/output110which is provided for transmitted user data or control messages to other entities as mentioned above and which is provided for receiving user data such as the data packet flow or control messages from other entities. The interface or input/output is especially configured to exchange the messages discussed above inFIGS.5and6in which the user equipment is involved. The user equipment furthermore comprises a processing unit120which is responsible for the operation of the user equipment. The processing unit120can comprise one or more processors and can carry out instructions stored on a memory130, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk, or the like. The memory can furthermore include suitable program code to be executed by the processing unit120so as to implement the above described functionalities in which the user equipment is involved.

FIG.12shows another example schematic architectural view of a user equipment400which comprises a first module configured to transmit the request to the translating entity wherein this request requests the identification of the user plane entity as mentioned above in step S20. The user equipment400comprises a second module420configured to receive a response to the first request wherein this response comprises an identifier of the user plane entity as mentioned above in step S24. Another module430is provided which is configured to transmit a policy request to the identified user plane entity wherein this policy request already indicates the policy to be applied to the data packet flow as discussed above in step S26.

FIG.13shows an example schematic architectural view of a user plane entity200which can handle the data packet flow and which can operate as mentioned above. The user plane entity200comprises an interface or input/output210provided for transmitting user data or control messages to other entities and configured to receive user data or control messages from other entities. The user plane entity especially handles data packet flow and also the control messages discussed above. The user plane entity comprises a processing unit220which is responsible for the operation of the user plane entity200. The processing unit220comprises one or more processors and can carry out instructions stored on a memory230, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk, or the like. The memory can furthermore include suitable program code to be executed by the processing unit220so as to implement the above described functionalities in which the user plane entity200is involved.

FIG.14shows another schematic architectural view of a user plane entity500which can operate as discussed above in connection withFIGS.3to6. The user plane entity comprises a first module510configured to receive a policy request which comprises a flow identifier and which comprises policy information indicating the policy to be applied to the data packet flow. Module510can be implemented in order to carry out step S26discussed above. A second module520is provided which is configured to transmit a policy request to the policy control entity module520is configured to carry out especially step S28mentioned above. A third module530is provided which is configured to receive the confirmation that the policy is allowed as mentioned above in step S13.

FIG.15shows an example schematic architectural view of the policy control entity300which can carry out the policy control as mentioned above in connection withFIGS.3to6. The policy control entity comprises an interface or input/output310configured to transmit user data or control messages and configured to receive user data and control messages. The policy control entity comprises a processing unit320which is responsible for the operation of the policy control entity300. The processing unit320comprises one or more processors and can carry out instructions stored on a memory330, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk or the like. The memory furthermore includes suitable program code to be executed by the processing unit320so as to implement the above described functionalities in which the policy control entity is involved.

FIG.16shows another example schematic architectural view of the policy control entity600which comprises a first module610configured to receive the policy request including the policy for the data packet flow wherein the policy request is received from the user plane entity and module610is especially configured to carry out step S28discussed above. The policy control entity furthermore comprises a second module620which is configured to determine that the policy as received is accepted. This was discussed above in connection with step S29. The policy control entity600furthermore comprises a third module630configured to transmit an answer to the user plane entity that the policy is accepted as mentioned above in step S30.

FIG.17shows an example schematic architectural view of the translating entity700which can operate as discussed above in connection withFIGS.3to6. The translating entity comprises an interface or input output710configured to receive user data or control messages and configured to transmit user data or control messages. The interface710is especially configured to receive the query from the UE as mentioned in step S20and is configured to transmit an answer to the UE as mentioned in step S24. The translating entity furthermore comprises a processing unit720which is responsible for the operation of the translating entity. The processing unit720can comprise one or more processors and can carry out instructions stored on a memory730, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk or the like. The memory can furthermore include suitable program code to be executed by the processing unit720so as to implement the above-described functionalities in which the translating entity is involved.

FIG.18shows another example schematic architectural view of the translating entity which can operate as discussed above in connection withFIGS.3to6. The translating entity comprises a first module810configured to receive the request from the UE wherein the request requests an identification of the user plane entity. A second module820is provided configured to transmit the request to a subscriber database to identify the user plane entity as mentioned above in step S21. A module830is provided configured to receive the response with the identity of the user plane entity as mentioned in step S23. A module840is provided configured to inform the UE about the user plane entity as mentioned in step S24.

From the above said some general conclusions can be drawn:

As far as the operation of the user equipment is concerned the first request such as the request transmitted in step S20comprises a user identifier identifying the user equipment and the name of the application entity.

As far as the policy request such as the request of step S26is concerned, this policy request furthermore comprises the name of the application entity.

Furthermore, the policy request as the request transmitted in step S26can furthermore comprise a quality of service parameter to be applied to the data packet flow in the cellular network or an information whether a subscriber of the user equipment should be charged for the transmission of the data packet flow through the cellular network. The network operator and the content provider may have agreed upon the fact that the subscriber is not subscribed for traffic coming from the application of the content provider.

As far as the user plane entity200is concerned before the first policy request is received such as the request of step S26, the session management entity of the cellular network may be informed of the fact that the user plane entity is configured to operate in the exposure operating mode in which the content provider operating the application function informs the cellular network about the policy to be applied to the data packet flow in the network. This was discussed above in step S1. In the same way, before the policy request of step S26is received a session establishment request may be received from the session management entity of the network. This session establishment requests to activate the exposure operating mode in which the content provider operating the application entity informs the cellular network about the policy to be applied to the data packet flow. This was implemented above in step S11.

Furthermore, the session establishment request may indicate to the user plane entity to detect messages related to the exposure operating mode.

Furthermore it is possible that before the policy request is received, a subscriber database of the cellular network is informed of a user identifier which identifies the user equipment and of identifier of the user plane entity as mentioned in step S13above.

As far as the policy control entity is concerned, before the policy control entity receives the policy request a query message may be received from a subscriber database including an indication to activate an exposure operating mode in which the content provider operating the application entity informs the cellular network about the policy to be applied to the data packet flow. This was discussed above in connection with step S7.

Furthermore, in response to the query message the policy control entity can activate the exposure operating mode and a session management entity is requested to activate the exposure operating mode as mentioned above in steps S8and S9.

Summarizing, the present application provides an efficient mechanism to exchange information between the content provider and the network operator. It avoids the use of the network exposure function which is a complex network function not supported by all of the network operators.

Furthermore it provides a simple correlation between the exposure channel and the user plane application traffic.

Furthermore, the exposure information exchanged between the content provider and the network operator does not have any impact on the UE modem.

Furthermore, the service based user plane entity is aligned with the latest 3GPP implementations.