WO2018065632A1

WO2018065632A1 - Policy coordinator function for distributed policy control

Info

Publication number: WO2018065632A1
Application number: PCT/EP2017/075696
Authority: WO
Inventors: Filipe LEITAO; Marco Liebsch
Original assignee: NEC Laboratories Europe GmbH
Priority date: 2016-10-07
Filing date: 2017-10-09
Publication date: 2018-04-12

Abstract

A communication system is disclosed in which a common network function supports policy control via a plurality of secondary level network functions, by coordinating dynamic policy control by providing information relevant for supporting policy decisions by at least one secondary level network function. One or more network functions are provided which are configurable to operate as a secondary level network function. When operating as a secondary level network function, each network function obtains appropriate information from the common network function and performs dynamic policy control based on the obtained information.

Description

POLICY COORDINATOR FUNCTION FOR DISTRIBUTED POLICY CONTROL

The present invention relates to a communication system. The invention has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (also including 4G and 5G). The invention has particular although not exclusive relevance to policy control.

In today's cellular mobile communication systems (e.g. Long Term Evolution (LTE) / Enhanced Packet Core (EPC) networks), mainly two types of Data-Plane gateways are deployed on top of a transport network to handle the mobile subscribers' Data-Plane. These are the Packet Data Network Gateway (PGW) and the Serving Gateway (SGW). These gateways receive policies regarding how to treat a registered subscriber's Data- Plane packets, in terms of Quality-of-Service (QoS) differentiation, metering as well as triggering and monitoring the generation of charging data records. As described in 3GPP Technical Specification (TS) 23.203 v14.0.0 ("Policy and charging control architecture", Release 14, June 2016), in 3GPP networks, a single point of policy control, the Policy and Charging Rules Function (PCRF), is in charge of a subscriber's profile and determines policies to be enforced in the subscriber's currently assigned PGW and SGW. The PCRF can be seen as a centralized policy decision point. The main component of the PCRF is the policy engine that decides to apply a rule considering the co-related context: e.g. user location; credit situation; congestion; service requests.

Figure 1 presents the overall E-UTRAN non-roaming architecture as defined in 3GPP TS 23.401 v14.0.0 ("General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", Release 14, June 2016). Figure 1 schematically illustrates a mobile (cellular) telecommunication network 1 in which users of mobile devices 3 (denoted 'UE' in Figure 1 ) can communicate with each other and other users via E-UTRAN base stations 5 and a core network using an appropriate radio access technology (RAT), e.g. an Evolved Universal Terrestrial Radio Access (E-UTRA) technology. However, it will be appreciated that the radio access technology is not limited to E-UTRA, and may comprise any suitable access technology in accordance with one or more of the following standards: LTE, Universal Mobile Telecommunications System (UMTS), General Packet Radio Service (GPRS), Wi-Fi (IEEE 802.1 1 family of standards), Worldwide Interoperability for Microwave Access (WiMAX), and/or the like. The mobile device 3 and the base station 5 are connected via an LTE air interface, the so-called "Uu" interface. The base station 5 (and hence the mobile device 3) is coupled to the core network via an appropriate interface (in this example, an 'S1 ' interface, which includes the 'S1 -MME' interface for control-plane and the 'S1 -IT interface for user-plane). The network is configured to keep track of the location of its subscribers / UEs 3 using at least one of a serving general packet radio service support node (SGSN) 7a and a Mobility Management Entity (MME) 7b. A home subscriber server (HSS) 8 is also provided in order to store subscription related information and configuration, and to provide such information to other nodes (e.g. SGSN/MME) when needed. In this network 1 , the Policy and Charging Control (PCC) architecture 10 includes, amongst others, a Policy and Charging Enforcement Function (PCEF) 12 (typically included in the PGW), a Policy Control and Charging Rules Function (PCRF) 13, and a Service Capability Exposure Function (SCEF) 14 (not shown in Figure 1 ).

In this context, the PCRF 13 is the network's Policy Decision Point (PDP) that builds policy rules that are to be enforced mainly on the PGW via the Gx Reference Point. In some cases, the PCRF 13 determines few subscriber-specific policies, which are to be enforced on the SGW 1 1 and service-related detection filters to be enforced on the Traffic Detection Function (TDF). The Subscriber Profile Repository (SPR) 15 is a database with UE's 3 subscription information to be taken into account by the PCRF 13 on its decision: e.g. subscriber group services' white/black lists, and/or the like. As PDP, the PCRF 13 makes use of such a SPR 15 to retrieve subscriber-specific attributes/values, which are needed to determine the policies which are to be enforced on the gateways. Such attributes/values include, for example, the maximum aggregated bandwidth per Access Point Name (APN) and per device, supported QoS for dedicated bearers, charging- related aspects for the subscriber (pre-payed Online Charging or contracted Offline Charging). Finally, the PCRF 13 may also be triggered through the Rx reference point (also shown in Figure 1 ) by external application or correspondent services of the subscriber to impact policy decisions.

A PCRF 13 offers additional reference points to connect to external functions, which can have impact to a determined policy for a particular subscriber. In some cases, the external function can query policies for enforcement. Some of the most important reference points and external functions are depicted in Figure 2 and they are summarized below.

The PCRF 13 has a reference point to an Application Function (AF) 17, which enables a service, being used by a subscriber (UE 3), to request particular settings or changes in policies that are determined in the PCRF's PDP and enforced in the subscriber's currently used gateways (in this example, SGW 1 1 and PGW 12). The AF 17 can be seen as a logical representation of external application functions (or intermediate interworking nodes in the SCEF 14 case) that may send specific QoS or service access related requests during an ongoing UE session.

The PCRF 13 offers a further reference point to a Traffic Steering Service Function (TSSF) 19, which enables the PCRF 13 to provide policies to a Data-Plane Controller, such as an SDN Controller, to classify and forward a subscriber's traffic though a single or a chain of concatenated functions in the Packet Data Network, where the mobility gateways (SGW 1 1 , PGW 12) are not involved in packet forwarding anymore. The TSSF 19 is a traffic steering controller node (e.g. SDN Controller) that is stimulated by the PCRF 13, typically to re-configure the path within the SGi-Lan domain. This allows the operator to dynamically tailor a sub-set of services to be provided to the UE 3.

A further reference point is standardized to connect a Traffic Detection Function (TDF) 18, which is deployed on Data-Plane nodes, to the centralized PCRF 13. After detection of unknown traffic at the TDF 18, the TDF 18 can query rules from the PCRF 13 how to treat the packets. Such function can be used for Deep Packet Inspection (DPI) or Gating Control/Enforcement. The TDF 18 is a policy enforcement point placed at the user plane layer, specialized in application/service detection (and further notification to the PCRF 13). The TDF 18 is typically a Deep Packet Inspection (DPI) box, which is capable of some enforcement actions including e.g. gating control and/or the like.

These aspects are captured in Figure 2, representing the Policy and Charging Control (PCC) architecture as defined by 3GPP, where the PCRF 13 is the central decision point for a subscriber's polices with the Policy and Charging Enforcement Function (PCEF) 12 in a gateway as main consumer of the determined subscriber policies. The PCEF 12 is the main policy enforcement point, responsible for the QoS enforcement (bearer creation and management), charging control, gating, reporting, etc. of the subscriber session. It is dependent on the PCRF 13 decision (policy rules), although it also informs the PCRF 13 of session related info obtained through GTP headers, e.g. location, RAT-Type, etc. Current trends for an evolution towards Next Generation fixed/mobile converged Core Network adopt technologies of Software Defined Networking (SDN) to abstract the Data- Plane details towards the Control-Plane and adopt tools for Network Function Virtualization to dynamically adapt network functions' capacity to the current load/demand by scaling features, which may quickly add or remove instances of a particular Network Function to/from the system, e.g. as described in M. Liebsch, F.Z. Yousaf, "Virtualized EPC - Runtime Offload for Fast Data-Plane Scaling", In Proceedings of IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC) 2016. Different Network Functions (NF) of particular types or flavours can be grouped and isolated from other groups, hence building so-called 'network slices'. In addition, modularization of the architecture's network functions is considered to instantiate and build isolated groups of selected/required network functions (network slices) to serve a particular type of device or offer a tailored service (e.g. simplistic, optimised, ultra-reliable) to suit a particular use case (e.g. Internet-of-Things, Mobile Edge Computing, Tactile Internet, etc.).

Figure 3 presents an example of such network evolution; with NFs being distributed and potentially instantiated on-demand do enable a particular network deployment. It is based on the assumption of the NFs being split between User-Plane and Control-Plane functions. These NFs can exchange information with each other and can also be decomposed in smaller sub-functions. This concept was being studied as part of the 5G/NextGen core development captured in Section 6.7 of 3GPP TR 23.799 vO.7.0 ("Study on Architecture for Next Generation System", Release 14, August 2016).

Furthermore, trends in research and standardization of a next generation of mobile communication architecture consider way more different types and a varying number of instances per type of network function on the mobile Control- and Data-Plane. This poses issues in the number of different reference points in between a single PCRF 13 and a larger number of network functions types 22, 23, 24, which need to receive function- specific policies to serve a particular mobile subscriber. On top, it is assumed that in the context of such architecture model, like exemplified in Figure 3, each NF may have its own sub-function dedicated to policy control or enforcement, depending on the use case need and the NF placement. It may happen then that some of these policy-related sub- functions include some control and decision functionalities (like policies rules management and selection). This paradigm makes the 3GPP-based policy and charging control architecture (shown at Figure 2), which relies on a central PCRF 13 performing policy control, impractical to be applied and hard to control (auto-sustainable) NFs. The increased deployment complexity would require the PCRF 13 to compute policies for different NF types and different deployment flavours. For example, given the abstraction and isolation aspects brought by network slicing paradigm, the inventors have realised that it would be hard for a centralised PDP (such as the PCRF 13) to keep track of the different policy enforcement aspects within the different network slice instances.

Dealing with the different semantics used by the different NFs could also be a problem to a centralised Policy Enforcement Point (PEP) like the PCRF 13. With distributed NFs instantiating several PEPs managed by different protocol and control semantics, the PCRF 13 would need to support and maintain a number of Reference Points; a situation that at a certain point may be hard to scale.

Network slicing also brings dynamicity to the network deployments. While scaling to adapt to the slice/tenant needs, different NFs would be constantly connecting/disconnecting to the PCRF 13, increasing its load capacity need and management complexity.

Concluding, having distributed PEPs along the instantiated among several NFs and/or PDPs as part of the NFs sub-functions, is a policy control scenario difficult to manage and scale. In the end this brings tremendous difficulties to operators at the time of defining end-user (either loT-based or end-user commercial subscribers) commercial offers that require coordinated policy-based management of different NFs.

In view of the above, the inventors have identified the following issues:

• increased complexity at the PCRF may be required for computing policies for different distributed network function types and flavours;

· distributed network functions may cause significant (policy control related) network load to a centric PCRF;

• reference points and semantics may differ per distributed network function type/flavour;

• need to handle dynamicity in number of network functions connecting to and/or disconnecting from the PCRF during scaling; and

• difficult to take policy decisions at a single PCRF in case instances of Network Functions belong to different network slices or even different tenants such as, for example, in one or more of the following scenarios:

Network Functions which enforce policies may belong to different administrative instances/owners;

Network Functions which enforce policies may be instantiated in different infrastructures e.g. different Cloud Infrastructures; and

Network Functions which enforce policies may be instantiated on different network slices. Accordingly, preferred embodiments of the present invention aim to provide methods and apparatus which overcome or at least partially alleviate the above issues.

In one aspect, the invention provides a method performed by a common network function for supporting policy control via a plurality of secondary level network functions in a cellular communication system, the method comprising: coordinating dynamic policy control (e.g. at a user equipment level) by providing information relevant for supporting policy decisions by at least one secondary level network function.

In another aspect, the invention provides a method performed by a network function configurable to operate as a secondary level network function in a cellular communication system, the method comprising: obtaining, from a common network function, information relevant for supporting policy decisions by at least one secondary level network function; and performing dynamic policy control (e.g. at a user equipment level) based on the obtained information.

The invention also provides a node configured as common network function for supporting policy control via a plurality of secondary level network functions in a cellular communication system, the node comprising: a controller and a transceiver, wherein the controller is operable to: coordinate dynamic policy control by providing information relevant for supporting policy decisions by at least one secondary level network function.

The invention also provides a network function configurable to operate as a secondary level network function in a cellular communication system, the network function comprising: a controller operable to obtain, from a common network function, information relevant for supporting policy decisions by at least one secondary level network function, and perform dynamic policy control based on the obtained information.

Aspects of the invention extend to corresponding systems and computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the apparatus recited in any of the claims. Each feature disclosed in this specification (which term includes the claims) and/or shown in the drawings may be incorporated in the invention independently (or in combination with) any other disclosed and/or illustrated features. In particular but without limitation the features of any of the claims dependent from a particular independent claim may be introduced into that independent claim in any combination or individually.

Exemplary embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which:

Figure 1 illustrates a mobile (cellular) telecommunication system of a type to which embodiments of the invention are applicable;

Figure 2 illustrates an exemplary policy and charging control architecture;

Figure 3 illustrates an exemplary system employing distributed network functions representing separated control-plane and data-plane functions;

Figure 4 illustrates an exemplary policy coordinator function for distributed policy control; Figure 5 illustrates some of the basic functionalities of the policy coordinator function shown in Figure 4;

Figure 6 illustrates an exemplary service tailoring repository data model that may be used by the policy coordinator function shown in Figure 4;

Figure 7 is a general representation of the internal structure of an exemplary policy decision point to which embodiments of the present invention are applicable;

Figures 8 and 9 are exemplary timing diagrams illustrating methods performed by components of the mobile telecommunication system of Figure 4 whilst carrying out embodiments of the invention;

Figure 10 is an exemplary block diagram illustrating the main functionalities of a PCF of the system shown in Figure 4; and

Figure 1 1 is an exemplary block diagram illustrating the main functionalities of a network function of the system shown in Figure 4.

Overview

Figures 4 to 6 illustrate various aspects of a communication architecture, in which a single Policy Decision Point (PDP), like the PCRF 13 per today's architecture (e.g. as shown in Figures 1 and 2), is distributed into a number N of Network Function-specific PDP subcomponents (referred to as PDP' in the following description and in Figures 4 to 6). Therefore, in this system, a common (i.e. main or primary) policy coordination node or function is used instead of a central PCRF 13 to enable distributed policy control. This common node or function is herein referred to as a Policy Coordinator Function (PCF). The PCF may thus replace (e.g. when working together with a number of PDP's) the conventional PCRF 13 used in other systems. However, some of the functionalities of a conventional PDP (PCRF) are performed by other (lower level or 'secondary') policy control nodes (herein using the label PDP' to differentiate them from the central PDP). Each Network Function (NF) type or 'flavour' of a type has co-located its own PDP' to determine a portion of applicable policies, which are relevant for the NF's operation. In this exemplary system, therefore, the PDP's are distributed across the network, although it will be appreciated that one or more of such PDP's may also be co-located with a central policy coordination node or function (e.g. PCF/PCRF).

This paradigm, for example, enables offloading computational load from a PDP (such as the PCRF 13) and network load from the reference points in between a PDP (such as the PCRF 13) and the many distributed NFs by embedding an NF-specific PDP' with each NF. Furthermore, in case of federated NFs, where sub-groups of network functions may be owned and operated by different administrative instances, a PDP' function being collocated with a specific NF enables full access and control to the NF and associated means for the function-specific enforcement of policies. This avoids the need to enable and grand access and full control rights of a single PDP (such as the PCRF 13) to the federated NFs, which need to collaborate to enable end-to-end services or build a network- and service slide, but each NF is administered by a different owner and may even be placed in a different network infrastructure.

Managing the PDP is typically a task for Operation and Maintenance (OAM) systems. However in the traditional Policy and Charging Control (PCC) architecture (e.g. as defined in 3GPP TS 23.203), the PDP (such as the PCRF 13) is configured and instantiated in a static way, considering the centralised placement of this type of PDP. In the distributed architecture described, a PDP' can be instantiated jointly with an associated NF, on- demand, and consequently is configured, at once, when the PDP' is instantiated. NFV management systems (e.g. ETSI MANO) may be able to instantiate the PDP' instance in the corresponding NF, but they are not prepared to provide the subscriber/service related information required to configure, setup and operate the new PDP' instance.

In order to solve or at least partially alleviate the issues highlighted above, the network 1 beneficially includes a so-called Policy Coordinator Function (PCF) 26. Specifically, the PCF 26 (which is generally illustrated in Figure 4) is configured to serve a number of distributed PDP's within distributed NFs crossing a network architecture. As seen in Figure 4, PDP's may be distributed among nodes in one or more of the UE domain (e.g. UE 3), the access domain, and the core network domain. The NFs 22 providing PDP' functionality in the access domain may comprise a base station and/or the like, and may be referred to as NF (AN) 22, in order to distinguish them from other NFs having PDP' functionality. Network Functions providing PDP' functionality in the core network domain may be associated with the Control-Plane (e.g. NF (CP) 23 shown in Figure 4) and/or the User-Plane (e.g. NF (UP) 24 shown in Figure 4).

In this example, each distributed PDP' function components are configured and coordinated by the PCF 26 through a common-syntax interface, named as "PCx" for simplification. Through this interface, the PCF 26 is able to push network function-specific policy decision processing mechanisms to each network function. The PCF 26 coordinates the collection, classification, grouping and distribution of Policy Decision- Relevant information (PDRI) to the PDP's 22, 23, 24 (of which there may be several) appropriately, in accordance with a corresponding use case. In the case of federated NFs, which are administered by different owners, the PCF 26 may be used to provide PDRI semantics to distributed PDP' function components associated with the federated NFs. This mitigates the need for the centralised PDP (e.g. PCRF 13) to have full control to each of the distributed and federated NFs which, for example, all together build a network slice to enable end-to-end services in a network with multiple tenants.

In some deployments, an NF may have more than a single PDP' associated. This may be useful, for example, when the NF is shared between multiple network slices and policies on the NF need to be created according to the slice for which the NF performs a task.

Further deployments are possible, such as multiple instances of a network function of the same type or flavour, which share a single instance of a PDP'. This leaves space for flexible association and deployment of the PDP' and associated NFs. In effect therefore, for example, an NF deconstructs into an instance of a PDP' component and one or multiple instances of a network function component (NFC).

The PDP' exposes policy decisions to the NF or NFC. The NF or NFC can then enforce the policy decision or provide it to one or multiple policy enforcement points with or without having processed the policy decision further.

It can be seen, therefore, that this approach is consistent with the evolution of telecommunications architectures towards 5G points to scenarios where various Network Functions (NFs) may be dynamically instantiated and may have increased decision autonomy, fundamentally enabled by network functions virtualization (NFV) and modularization of the network. In this context, the above changes to the currently used Policy Framework, from a centralized PDP (e.g. 3GPP PCRF), towards a more distributed architecture (where each NF instantiates a PDP sub-function, tailored to the NF specificity) provides a number of advantages. The so-called Policy Coordination Function (PCF) introduced above provides a framework that advantageously exposes PDRI (and/or Policy Decision Environment (PDE)) to each of the distributed PDP components thereby helping to harmonise the end-to-end decision flow. Basic Functionalities of the Policy Coordination Function

To be able to coordinate and maintain a status of all the distributed PDP's the PCF 26 includes, in this example, the following functionalities:

• a Service Tailoring Repository (STR) 27: which stores information regarding the PDP' per NF, including its instantiation status, NF discovery related info, service- /subscriber-related polices; and

• a Tailoring Engine (TE) 28: which digests the information/requests received from external sources, the STR 27 and takes the decision of instantiate/update/remove a PDP' or set of PDP's.

The proposed architecture for the PCF 26 also enables a central coordination point of directives/requests from external functions, such as an Application Function (AF) placed in the operator's domain or in an external domain (external service's data centre). Details about the AF 17 are described in 3GPP TS 23.203, and omitted herein for simplicity.

Another alternative, although following the same analogy, to having a connection to the

AF 17, is having a connection to a Service Capability Exposure Function (SCEF) 14. Further details of the SCEF 14 are described in 3GPP TS 23.682 v13.3.0 ("Architecture enhancements to facilitate communications with packet data networks and applications",

Rel. 13, September 2015).

Within its operational functions, the PCF 26 may be triggered by (non-exhausting list): an OAM system updating the STR 27 and TE 28 when necessary; the PDP's where the PCF 26 is connected to; and a 3rd party service (e.g. through an AF 17 or SCEF 14). The PCF 26 may also contact the node/data base holding subscriber information (e.g. HSS 8, HLR, or SPR 15) and the AAA-related note to gather authorisation/authentication procedures (e.g. AAA).

The proposed architecture (and its set of sub-functions) enables new functions to expose data points (relevant information) to the PCF 26 for classification, grouping and distribution to relevant PDP' components. This scheme is represented in Figure 5. Service Tailoring Repository Data Model

The STR 27 of this example beneficially aids the PCF 26 by providing information relevant to the procedures related to instantiating/updating/removing PDP's within the relevant Network Functions. This information, may be provided in accordance with an exemplary Data Model (a graphical representation of which is shown in Figure 6). As seen in Figure 6, in this example, the Data Model provides the PCF 26 with the following information (although it will be appreciated that the listed information is purely exemplary and non-exhaustive):

• Location of the PDP': NF instance, reachability information, network/datacenter, underlying network function virtualization infrastructure, etc;

• Status of the PDP': enabled/not enabled;

• Policy Decision-Relevant information (PDRI): input information like for example the subscription information, service-related information, or session information, etc, plus the potential output information like for example a set of policies, etc;

· Policy Decision Environment (PDE): set of rules that could be represented, for example, by a sub-set of executional code or algorithm for taking policy decisions, shaped for the specific Network Function where the PDP' is instantiated; and

• Type of the PDP': selection of PDRI and PDE per PDP' which enables a certain use case. The Data Model shown in Figure 6 beneficially allows the PCF 26 to associate NF-specific rules and policies to a corresponding NF 22, 23, 24. This generic approach makes the PCF 26 to be NF-independent whilst still centralising the information for better flexibility and elasticity of the core.

The rules and policies that are pushed to each involved PDP' are, beneficially, specific to the NF where the PDP' is being instantiated. This means that a major functionality of the PCF 26 is to push NF-specific PDRI and PDE information to the appropriate NF(s) 22, 23, 24. Figure 7 represents graphically some of the information, relevant to the PDP' instantiation, that may be aggregated as PDRI and PDE.

The proposed way of working enables each NF 22, 23, 24 to instantiate / operate as a PDP' that is specific to that particular NF functionality. To enable that, the PCF 26 is configured to decide which information should be sent as PDRI and/or PDE, tailored to the NF specific needs. Operation

A number of exemplary procedures that may be implemented using the PCF framework described above will now be described with reference to associated call flows. It will be appreciated that, in the following examples, Network Functions (NF) can be associated with the Control-Plane (e.g. NF (CP) 23), the User-Plane (NF (UP) 24) or, in general, with the Access Network (NF (AN) 22).

Figure 8 illustrates an exemplary policy decision point instantiation process, including:

1 ) Detecting an NF armed trigger (in this example, by NF 23-1 ). For example, the NF was just instantiated in the network, or there were changes in the NF configuration due to, for example, network elasticity.

2) As the new instantiation is detected, the NF 23-1 has an internal configuration that mandates the NF to inform/consult the PCF 26 to potentially get a new PDP' configuration or update an existing one.

3) The PCF 26 receives the request from the NF 23-1 and analyses it, considering all the information it can get access to, both internal and external (for example: subscription-related NFs, the information sent by the request in Step 2 as the NF type or subset of serving subscribers, etc.). As result of this analysis, the PCF 26 identifies the PDP's to be configured or re-configured as consequence of Step 1. For each PDP' instantiated in different NFs (or in the same NF in the case where a NF has more than one PDP') the PCF 26 identifies the collection of information to be used as input for the PDP' and consequently the defined output of the PDP' - the collection of the input information and output possibilities defines the PDRI of each NF/PDP' - and identifies the decision mechanisms specific for each PDP' that will make use of the PDRI information sent to make a policy decision - this collection of specific decision mechanisms for each NF/PDP' defines the PDE.

4) The PCF 26 generates and sends appropriately formatted configuration and/or reconfiguration requests to each of the PDP' identified in Step 3. The requests sent include specific PDRI and PDE information tailored specifically to the target PDP'. It will be appreciated that the PDRI/PDE information may be included in the request in the form of one or more appropriately formatted information elements.

5) If all the previous steps were successful (e.g. upon receipt of an appropriate confirmation/acknowledgement, or in the absence of an error response, from the relevant target PDP's), the PCF 26 is configured to send an acknowledgment to the origin NF that triggered the configuration or re-configuration procedures. This acknowledgment message includes the specific PDRI and PDE information tailored specifically to the target PDP'. It will be appreciated that the PDRI and PDE information may be included in the acknowledgment message in the form of one or more appropriately formatted information elements.

In a further example, an exemplary process is described in which the PCF 26 receives an indication to update session management policies for UEs 3 in the proximity of a certain network region (and/or any other appropriate criteria).

Figure 9 illustrates an exemplary procedure for updating Policy Decision Point logic, and includes the following steps:

1 ) Due to an overloaded network region (and/or any other appropriate criteria), the OAM system 30 initiates temporary re-configuration of policy decisions associated with default QoS, e.g. the default bearer's aggregated maximum bitrate (AMBR).

2) The PCF 26 identifies one or more relevant NFs, which are associated with session management.

3) The PCF 26 loads updated PDRI and PDE information to the relevant NFs' PDP' (e.g. by generating and sending appropriately formatted configuration and/or reconfiguration requests including one or more information elements). Effectively, in this example, the updated PDE results in different QoS policy decisions being applied for the UEs 3 which attach/connect from a certain geographical or topological region.

4) The PCF 26 confirms to the OAM system 30 that updating of the relevant Session Management policies has been completed (e.g. by generating and sending an appropriately response to the message received in Step 1 ).

Summary

Beneficially, the above described exemplary embodiments include, although they are not limited to, one or more of the following functionalities:

• de-composing a centralized PDP (e.g. 3GPP PCRF, BBF BPCF) into multiple and different network function-specific PDP' components;

• co-locating/assigning a PDP' component with/to associated network functions;

• offloading network function-specific policy decision processing from PCRF to each network function;

• coordinating the collection, classification, grouping and/or distribution of policy decision-relevant information (PDRI) and/or Policy Decision Environment (PDE) information at a PCF;

• enabling central coordination of directives/requests from external functions, such as an Application Function or SCEF, at a single point - the PCF; and • enabling new functions to expose data points (relevant information) to the PCF for subsequent classification, grouping and/or distribution, to relevant PDP' components.

It can be seen that the above embodiments describe an exemplary method for policy coordination in a network with distributed network functions, the method beneficially comprising one or more of the following:

1 ) de-composing a centralized PDP into multiple and different network function- specific PDP' components and co-locating/assigning PDP' component with/to associated network functions;

2) performing network function-specific policy decision processing at each network function;

3) coordinating the collection, classification, grouping and distribution of policy decision-relevant information (PDRI) and Policy Decision Environment (PDE) information, at the PCF; and

4) PDE comprising a set of rules or code that can modify the algorithm for taking network function specific policy decisions at a PDP'.

Benefits

It can be seen that the above embodiments provide a number of benefits, including (but not limited to):

1 ) service tailoring at a single, centralized PCF to enable distribution of policy decision-relevant information to the correct network function and its associated, possibly co-located PDP';

2) processing policy decision-relevant information on a network function-specific policy decision point which is associated and co-located with each instance of network function in a distributed set of network functions;

3) maintaining a single, centralized function (PCF) to aggregate policy decision- relevant information and expose relevant information to a policy decision point of a network function;

4) enabling full access to and control on each one of a distributed set of network functions by taking policy decisions on each network function;

5) mitigating the decision load and the need for policy control semantics on an interface between a single, centralized policy controller (e.g. PCRF 13) and multiple distributed network functions; and

6) easing policy control on distributed but federated network functions in networks with distributed network function, in particular if network function virtualization, network slicing and/or multi-tenancy is supported. Separate and distribute the tasks associated with the retrieval and collection of policy decision-relevant information from the logic that takes policy decisions. This mitigates the load and need of control semantics on interfaces between a central policy decision point and distributed network functions. In a system and mechanism per the present paper, policy decision points are co-located with each function that requires policies, hence the policy decision point can operate locally and has full control on the function, which either implies also the policy enforcement point or utilises a further reference point to enforce policy decisions in a separate function.

Policy coordination function (PCF)

Figure 10 is a block diagram illustrating the main components of the PCF 26. As shown, the PCF 26 includes a transceiver circuit 31 which is operable to transmit signals to and to receive signals from the connected node(s) via a network interface 33 (e.g. PCx, Sp', and Rx'). A controller 35 controls the operation of the transceiver circuit 31 in accordance with software stored in a memory 37. The software includes, among other things, an operating system 39 and a communication control module 41 having at least a transceiver control module 43. In the example shown in Figure 10, the communication control module 41 is operable to control, for example, the distribution of policy decision relevant information to the correct network function 22, 23, 24 and the aggregation of policy decision relevant information and exposure of relevant information to an appropriate policy decision point in the network (e.g. one or more network functions). The communication control module 41 (using its transceiver control sub-module 43) is responsible for handling (generating/sending/receiving) signaling between the PCF 26 and connected nodes, such as the network functions 22, 23, 24, the OAM 30, the AF 17 / service, and the subscriber and AAA management entities 29. Although not shown in Figure 10, an appropriate Service Tailoring Repository (STR) module 27 and/or a Tailoring Engine (TE) module 28 may also be provided, depending on the configuration of the PCF 26.

Network function (NF)

Figure 1 1 is a block diagram illustrating the main components of an exemplary network function 22, 23, 24. As shown, the network function includes a transceiver circuit 51 which is operable to transmit signals to and to receive signals from connected node(s) via a network interface 53 (e.g. PCx). A controller 55 controls the operation of the transceiver circuit 51 in accordance with software stored in a memory 57. The software includes, among other things, an operating system 59 and a communication control module 61 having at least a transceiver control module 63. Although not shown in Figure 1 1 , it will be appreciated that an appropriate PDP (PDP') module may also be provided. The communication control module 61 is operable to obtain, from the PCF 26, information relevant to policy decision. The obtained information is used by the PDP/PDP' module, depending on the configuration of the network function. The communication control module 61 (using its transceiver control sub-module 63) is responsible for handling (generating/sending/receiving) signalling between the network function and other nodes (e.g. the PCF 26).

Modifications and Alternatives

Detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.

In the above description, the PCF and the network function are described for ease of understanding as having a number of discrete modules (such as the communication control modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these. Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like.

In the above embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un- compiled form and may be supplied to the PCF and the network function as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the PCF and the network function node in order to update their functionalities. The specific relevant information may comprise at least one of: subscription information; service-related information; and session information. The information relevant for supporting policy decisions may comprise information relevant for at least one UE (e.g. a single UE or a group of UEs). The policy control may comprise distributed policy control. The above method may comprise coordinating dynamic policy control at a user equipment (UE) level by providing UE specific information relevant for supporting policy decisions by at least one secondary level network function for a given UE.

The method may comprise storing information for tailoring the policy control via a plurality of secondary level network functions in a dedicated repository. In this case, the information for tailoring the policy control may comprise respective information for each secondary level network function relating to at least one of: instantiation status; network function discovery; and service-/subscriber-related polices for that secondary level network function.

The step of coordinating dynamic policy control may comprise determining to perform at least one of: instantiating; updating; and removing a secondary level network function or set of secondary level network functions.

The information relevant for supporting policy decisions may comprise a script or code to be executed by the at least one secondary level network function.

The method may further comprise determining a secondary level network function to be configured based on a trigger for that secondary level network function (e.g. a trigger indicating that the secondary level network function has been instantiated/reconfigured, and/or other network changes involving that secondary level network function).

The step of coordinating policy control for a particular mobile device may comprise configuring the at least one network function to operate as a secondary policy control function for at least one of: a particular network slice; a particular service; and a particular session associated with the mobile device.

The at least one of the common network function and the secondary level network functions may provide the functionality of a policy decision point (PDP) (e.g. a Policy Control and Charging Rules Function (PCRF)). Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

Claims

A method performed by a common network function for supporting policy control via a plurality of secondary level network functions in a cellular communication system, the method comprising: coordinating dynamic policy control by providing information relevant for supporting policy decisions by at least one secondary level network function.

The method according to claim 1 , wherein the information comprises at least one of: subscription information; service-related information; and session information.

The method according to claim 1 or 2, wherein the information relevant for supporting policy decisions comprises information relevant for at least one user equipment (UE) (e.g. a single UE or a group of UEs).

The method according to any of claims 1 to 3, comprising coordinating dynamic policy control at a user equipment (UE) level by providing UE specific information relevant for supporting policy decisions by at least one secondary level network function for a given UE.

The method according to any of claims 1 to 4, wherein the policy control comprises distributed policy control.

The method according to any of claims 1 to 5, comprising storing information for tailoring the policy control via a plurality of secondary level network functions in a dedicated repository.

The method according to claim 6, wherein said information for tailoring the policy control comprises respective information for each secondary level network function relating to at least one of: instantiation status; network function discovery; and service-/subscriber-related polices for that secondary level network function.

The method according to any of claims 1 to 7, wherein the coordinating dynamic policy control comprises determining to perform at least one of: instantiating; updating; and removing a secondary level network function or set of secondary level network functions.

9. The method according to any of claims 1 to 8, wherein the information relevant for supporting policy decisions comprises a script or code to be executed by the at least one secondary level network function.

10. The method according to any of claims 1 to 9, further comprising determining a secondary level network function to be configured based on a trigger for that secondary level network function (e.g. a trigger indicating that the secondary level network function has been instantiated/reconfigured, and/or other network changes involving that secondary level network function).

1 1 . The method according to any of claims 1 to 10, wherein coordinating policy control for a particular mobile device comprises configuring the at least one network function to operate as a secondary policy control function for at least one of: a particular network slice; a particular service; and a particular session associated with the mobile device.

12. The method according to any of claims 1 to 1 1 , wherein at least one of the common network function and the secondary level network functions provides the functionality of a policy decision point (PDP) (e.g. a Policy Control and Charging Rules Function (PCRF)).

13. A method performed by a network function configurable to operate as a secondary level network function in a cellular communication system, the method comprising: obtaining, from a common network function, information relevant for supporting policy decisions by at least one secondary level network function; and performing dynamic policy control based on the obtained information.

14. A node configured as common network function for supporting policy control via a plurality of secondary level network functions in a cellular communication system, the node comprising: a controller and a transceiver, wherein the controller is operable to: coordinate dynamic policy control by providing information relevant for supporting policy decisions by at least one secondary level network function.

15. A network function configurable to operate as a secondary level network function in a cellular communication system, the network function comprising: a controller operable to obtain, from a common network function, information relevant for supporting policy decisions by at least one secondary level network function, and perform dynamic policy control based on the obtained information.

16. A system comprising the node according to claim 14, a mobile device, and at least one network function configurable to operate as a secondary level network function for the mobile device.

17. A computer program product comprising computer implementable instructions for causing a programmable computer device to perform the method of any of claims 1 to 13.