Patent Description:
3GPP SA2 has an ongoing study item specific to Edge Computing related problems and corresponding solutions as part of 3GPP Release-<NUM>. As part of this, several identified technical issues and solutions are accepted in 3GPP TR <NUM>.

An application function (AF) may influence traffic routing on a PDU Session as defined in 3GPP TS <NUM>, § <NUM>. <NUM>, and in 3GPP TS <NUM>, § <NUM>. Namely, AF may use Nnef_TrafficInfluence_Create/Update messages providing traffic influence request information to 5GC. Thus, AF issues rules (via a NEF API) that may target one (or multiple) UE(s), a group of UEs identified by a Group ID, or any UE, as defined in 3GPP TS <NUM>, Table <NUM>. <NUM>-<NUM>. An excerpt of the table defining traffic influence request information is shown in Table <NUM>. A traffic influence request information may be related to one PDU session or to plural PDU sessions (e.g. in case it is related to plural UEs).

Further cited prior art documents are 3GPP TR23. <NUM> and <CIT> showing a method for checking change in wireless connection type terminal in third-party application server.

It is an object of the present invention to improve the prior art.

According to aspects of the invention, there are provided apparatuses and methods according to the respective claims.

According to some embodiments of the invention, at least one of the following advantages may be achieved:.

Further details, features, objects, and advantages are apparent from the following detailed description of some implementations of the present invention which is to be taken in conjunction with the appended drawings, wherein:.

Herein below, certain arrangementsare described in detail with reference to the accompanying drawings, wherein the features of the implementationscan be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain arrangementsis given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

Some of the solutions accepted in 3GPP TR <NUM>, e.g. solution <NUM>, assume deployment scenarios where more than one Application Function provides input (i.e., a traffic influence request information, which may have a format as shown in Table <NUM> as an example) to SMF via PCF to influence traffic routing, PSA selection etc. and where the input of these multiple AFs may target the same PDU Session and possibly the same application traffic within that PDU Session. Also, in Release-<NUM> specification e.g. 3GPP TS <NUM>, there are some procedures defined that require multiple AFs.

If an AF (e.g. a source AF) provides input to SMF via PCF to influence traffic routing and subsequently (an)other AF(s) (e.g. a target AF) provides input to SMF via PCF in order to influence traffic routing for the same application traffic, it is not specified how the following example use cases are addressed:
The "source" AF provides via PCF to SMF information (i.e. a request) to influence SMF routing decisions for traffic of PDU Sessions for "any UE", and another AF (e.g. a target AF) also provides a request to influence SMF routing decision for an "externalgroupID" (certain UEs may belong to group/any UE). Additionally, or subsequently, another AF (e.g. another target AF) provides information for a particular UE to influence SMF routing decisions for the same traffic of the PDU Session targeted by the request of the source AF.

That is, the following example questions are not yet answered:.

Some example arrangements provide a solution to these questions. Namely, some example arrangements provide a new functionality at NEF, UDR, PCF, and/or AF, along with corresponding procedures enhancements. They allow deployment scenarios with multiple AFs influencing traffic routing on a PDU session. For example, source AF may provide input to PCF to influence traffic routing, and subsequently another AF(s) (e.g. target AF) provides input to SMF via PCF in order to influence traffic routing for the same application traffic. As another example, plural AFs may provide substantially simultaneously (i.e., the PCF receives the second input before the PCF instructs SMF with new PCC rules based on the first input) input to SMF via PCF to influence the traffic routing. With the procedure enhancements, along with a new priority indication, PCF may (or may not) update PCC rules and provide them to SMF for traffic routing based on the input from an appropriate AF. The same applies correspondingly to any other user plane management purposes and notification services for the PDU session.

Some example arrangements provide a priority indication along with the traffic influence request information. Depending on the implementation or configuration, the traffic influence request information may comprise the priority indication as an additional element ("prioritized traffic influence request information"), or the priority indication is provided in a separate information element.

Hereinafter, some example arrangements are described at greater detail with reference to <FIG> and <FIG>. <FIG> is related to a case that the AFs are owned by the network operator (or at least that the network operator trusts the AFs), while <FIG> is related to a case where the network operator does not trust the AFs (typically because they are not owned by the network operator).

As shown in <FIG>, AF1 may provide traffic influence request information downstream to PCF via NEF. As an alternative option (not shown), AF1 may provide the traffic influence request information directly to PCF, in particular if it is related to a single UE. For example, the traffic influence request information may indicate"any UE" with anyUeInd (as defined in TABLE <NUM> clause <NUM>) as target, triggering PCF to accordingly provide PCC rules to SMF. In addition, one or more AFs may provide traffic influence request information for a particular UE. The particular UE belongs to the anyUeInd.

Along with the traffic influence request information, the AFs provide a priority indication indicating a priority of the respective traffic influence request information. The priority indications enable PCF to accordingly consider the traffic influence request information as input information for PCC rule generation and further provide them downstream to SMF (or not).

An example of a potential usage of this priority information is as follows, wherein the targeted UEs are used as a parameter to determine the priority:.

, the higher the definiteness of the parameter used to determine the priority, the higher the priority of the traffic influence request information. Of course, depending on the needs, the relative priorities may be inverse to those of the above example.

Some example arrangements implement sub-priorities as well, for example in deployments where there are multiple AFs providing inputs to a particular UE.

Another example of priority determination is that an AF rule targets any traffic towards FQDN = *. application-providerX. com and another (more specialized) AF rule targets any traffic towards FQDN = *. application-providerX.

In this example, again, the higher the definiteness of the parameter used to determine the priority, the higher the priority of the traffic influence request information. Of course, depending on the needs, the relative priorities may be inverse to those of the above example.

While these examples are based on a single parameter, the AFs may use a set of plural parameters (e.g. a combination of the above mentioned parameters) to determine the priority.

As an example, AF1 and AF2 may provide rules which both apply to any UE and where DNAI1 and DNAI2 may apply in the same geographical area) :.

PCF has to know which DNAI to use for traffic that maps both range1 and range2?.

In this example, rule <NUM> may be sent to PCF (e.g. via NEF and UDR) by AF1 of the operator and the rule <NUM> may be sent to PCF (e.g. via NEF and UDR) by AF2 of a 3rd party with agreement with the operator (i.e., AF2 is a trusted AF, too).

The operator may decide to give Rule <NUM> the highest priority for a reduced set of users (all users with bronze subscription) and with a broader address range.

On the other hand, rule <NUM> might be split into rule <NUM>' and rule <NUM>".

In some examples, Rules from AF2 may have higher priority (because the operator has a specific agreement with this 3rd party owning AF2) than specific Rule1 of the operator. On the other hand, the rules from the operator (Rule <NUM>) may have a higher priority than rules from a 3rd party without an agreement with the operator.

The decision which of the received traffic influence request information has a higher priority (i.e., the comparison of the priorities) is met at PCF, based on the priority indications received from NEF (via UDR). Since the priority indications are available downstream from NEF regardless of whether the AFs are trusted or non-trusted, all the involved AFs may be trusted AFs (as shown in <FIG>), or all the involved AFs may be non-trusted AFs (as shown in <FIG>), or some of the involved AFs may be trusted AFs and some of the involved AFs may be non-trusted AFs.

The message flow in <FIG> is as follows:.

In this case, based on the priority indication, the PCF decides which rule to apply. If the later received traffic influence request information (i. e, the traffic influence request information from AF-<NUM>) has higher priority, PCF may replace the PCC rule provided to SMF by a PCC rule corresponding to the traffic influence request information received from AF2. If the traffic influence request information from AF-<NUM> has the higher priority, PCF may either send the corresponding PCC rule again to SMF, or may not send any PCC rule to SMF.

Hereinafter, it is assumed that the traffic influence request information from AF-<NUM> has the higher priority.

Action <NUM>: corresponds to Action <NUM>, with the PCC rule corresponding to the traffic influence request information from AF2.

Action <NUM> is not always needed. It corresponds to 3GPP TS <NUM>, § <NUM>. As the PCC rule has changed, SMF may have to do user plane reconfiguration, e.g. UPF/PSA relocation, change traffic routing for some UP flows and so on. It may also update (i.e. change) the URI of the AF to notification.

Actions <NUM>-<NUM>: If the AF-<NUM> had subscribed to user plane management event notifications, SMF sends, via NEF, a notification to the AF-<NUM> (instead of notification to AF1, based on the received PCC rule which indicates new notification URI).

<FIG> shows another message flow according to some arrangements. This arrangement is specific to use cases where Application Function (AF) is deployed by a third party. In this case AF provides traffic influence request information (and receives notification) to 5GC via NEF.

In the example arrangements of <FIG>, the priority of the traffic influence request information was set by the AFs. However, if the AF is third party deployed, AF based priority solution may not be sufficient (not acceptable for the network operator) because:.

To address these problems, in some arrangements, NEF is enhanced with new functionality to handle incoming AF request to traffic influence. Thus, AF may send traffic influence request information as usual (e.g. as defined in 3GPP TS <NUM>, clause <NUM>. <NUM>), to 5GC via NEF. The AF may or may not send a priority indication along with the traffic influence request information. NEF, on receipt of AF request applies rules to determine the priority before forwarding the traffic influence request information and the priority indication to PCF (via UDM/UDR).

As another implementation, PCF may determine the priorities based on the same principles as explained further below for NEF. However, typically, implementing the determination of the priorities in the NEF is advantageous because the NEF anyhow has policies per external AF, e.g. to determine the target DNN, slice, traffic steering policy etc.. of an AF request. This also allows to keep PCF unaware of whether it is an internal or external AF and avoids PCF to need to know information on AF business relationship (e.g. Service Level Agreement) that the NEF holds anyhow.

In some example implementations, PCF may receive some priorities from AF (via NEF and UDR) or NEF (via UDR) and determine some priorities itself.

As a still further option, NEF may determine not only the priorities of traffic influence request information from external AFs but also the priorities of traffic influence request information from operator-owned AFs.

Some example rules to determine the priority are explained. The operator may configure such rules. For example, NEF may apply lower priority to certain specific <NUM>rd party AFs w. t operator's deployed AFs. Alternatively or additionally, NEF (or PCF) may be configured to apply the following rule set to determine the priority of a traffic influence request information:.

, the higher the definiteness of the target, the higher the priority.

<FIG> shows a message flow for a case that an external AF (3rd party or non-trusted AF deployment) requests to influence traffic routing according to some example arrangements. In the example, the priorities are determined by NEF.

Action <NUM>: Application Function AF1 decides to send AF request, e.g. based on certain trigger conditions.

Action <NUM>: AF1 sends to 5GC via NEF, Nnef_TrafficInfluence_Create service operation with traffic influence request information, such as that specified by 3GPP TS <NUM>, § <NUM>.

Action <NUM>: NEF, on receipt of the request from AF, applies specific rules, such as those explained above, to determine the priority of the traffic influence request information. Subsequently, NEF creates or updates corresponding information in the UDM/UDR together with the rules and provides them to PCF in step <NUM>.

Action <NUM> is the same as action <NUM> of <FIG>. , PCF provides PCC rules to SMF.

Action <NUM>: Some time later, e.g. based on certain trigger conditions, AF-<NUM> decides to provide traffic influence information to PCF via NEF, using service operation Nnef_TrafficInfluence_Create. An example of such a trigger may be due to UE mobility, i.e. UE is at a new location. Also, in the present example, AF-<NUM> is not aware of AF-<NUM> traffic influence request information earlier provided to 5GC.

Action <NUM>: same as the above Action <NUM>, with the specific rules applied to AF-<NUM> request message.

Actions <NUM>-<NUM>: Same as actions <NUM> to <NUM> in <FIG>.

<FIG> shows an apparatus according to an example arrangement. The apparatus may be a policy control function or an element thereof. <FIG> shows a method according to an example arrangement. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for receiving <NUM>, means for deciding, <NUM>, means for generating <NUM>, and means for providing <NUM>. The means for receiving <NUM>, means for deciding, <NUM>, means for generating <NUM>, and means for providing <NUM> may be a receiving means, deciding means, generating means, and providing means, respectively. The means for receiving <NUM>, means for deciding, <NUM>, means for generating <NUM>, and means for providing <NUM> may be a receiver, decider, generator, and provider, respectively. The means for receiving <NUM>, means for deciding, <NUM>, means for generating <NUM>, and means for providing <NUM> may be a receiving processor, deciding processor, generating processor, and providing processor, respectively.

The means for receiving <NUM> receives a first traffic influence request information related to a PDU session (S10). Furthermore, the means for receiving <NUM> receives a second traffic influence request information related to the PDU session (S12).

S10 and S12 may be performed in an arbitrary sequence. They may be performed fully or partly in parallel.

The means for deciding <NUM> decides, based on a first priority and a second priority , which of the first traffic influence request information and the second traffic influence request information has a higher priority (S20). The first priority is related to the first traffic influence request information. The second priority is related to the second traffic influence request information. For example, the first and second priorities may be received in first and second priority indications received along with the first and second traffic influence request information, respectively, or the apparatus may generate the first and second priorities.

If the means for deciding <NUM> decides that the first traffic influence request information has the higher priority, the means for generating <NUM> generates a first policy based on the first traffic influence request information (S30).

If the means for deciding <NUM> decides that the second traffic influence request information has the higher priority, the means for generating <NUM> generates a second policy based on the second traffic influence request information (S32).

The means for providing <NUM> provides the one of the first policy and the second policy generated by the means for generating <NUM> to a session management function associated to the PDU session (S40).

<FIG> shows an apparatus according to an examplearrangement. The apparatus may be a repository function such as a UDR or an element thereof, an exposure function such as a NEF or an element thereof, or an application function such as a AF or an element thereof. <FIG> shows a method according to an example arrangement. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for providing <NUM>. The means for providing <NUM> may be a providing means. Means for providing <NUM> may be a provider. The means for providing <NUM> may be a providing processor.

The means for providing <NUM> provides a traffic influence request information related to a PDU session and a priority indication to a downstream network function (S110). The priority indication indicates a priority of the traffic influence request information. For example, a prioritized traffic influence request information may comprise both the traffic influence request information and the priority indication. If the apparatus is comprised in a UDR, the downstream network function may be a PCF. If the apparatus is comprised in a NEF, the downstream network function may be a UDR. If the apparatus is comprised in an AF, the downstream network function may be a NEF.

<FIG> shows an apparatus according to an arrangement. The apparatus comprises at least one processor <NUM>, at least one memory <NUM> including computer program code, and the at least one processor <NUM>, with the at least one memory <NUM> and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to <FIG> and <FIG> and related description.

Some example arrangementsare explained with respect to a <NUM> network. However, implementations may not be limited to <NUM>. It may be used in other networks, too, e.g. in previous or forthcoming generations of 3GPP networks such as <NUM>, <NUM>, <NUM>, <NUM>, etc..

The format of the traffic influence request information is not limited to that of Table <NUM>. Any format suitable to provide information to influence at least one of traffic routing on a PDU session, notifications of the PDU session, and anchor selection of the PDU session may be selected.

Names of network elements, network functions, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or network functions and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. Each of the entities described in the present description may be deployed in the cloud.

According to the above description, it should thus be apparent that arrangements may provide, for example, a network function of core network, such as PCF, UDR, NEF, or AF, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. Each of the entities described in the present description may be embodied in the cloud.

Claim 1:
Policy control function (PCF) comprising:
one or more processors (<NUM>) and memory (<NUM>) storing instructions that, when executed by the one or more processors, cause the apparatus to perform:
receiving (S10), from a first application function (AF-<NUM>), a first traffic influence request information related to a protocol data unit session;
receiving (S12), from a second application function (AF-<NUM>), a second traffic influence request information related to the protocol data unit session;
wherein at least one of
first priority information is received along with the first traffic influence request information;
second priority information is received along with the second traffic influence request information
and wherein at least one of
the first traffic influence request information comprises an indication of the first priority; and
the second traffic influence request information comprises an indication of the second priority;
deciding (S20), based on the first priority and the second priority, which of the first traffic influence request information and the second traffic influence request information has a higher priority, wherein the first priority is related to the first traffic influence request information, and the second priority is related to the second traffic influence request information;
generating (S30) a first policy based on the first traffic influence request information if it is decided that the first traffic influence request information has the higher priority;
generating (S32) a second policy based on the second traffic influence request information if it is decided that the second traffic influence request information has the higher priority;
providing (S40) the generated one of the first policy and the second policy to a session management function associated to the protocol data unit session.