WO2010060478A1

WO2010060478A1 - Methods and apparatuses for improved policy control and charging architecture based on use of policy templates

Info

Publication number: WO2010060478A1
Application number: PCT/EP2008/066250
Authority: WO
Inventors: Ruo Yuan Zhang
Original assignee: Nokia Siemens Networks Oy
Priority date: 2008-11-26
Filing date: 2008-11-26
Publication date: 2010-06-03

Abstract

There is provided an improved policy control (and charging) architecture, which is based on the use of policy templates. At one policy control entity, a service access request may be received, an appropriate policy template for the requested service may be determined, and a proper policy for the requested service may be set up based on the determined appropriate policy template, user profile information and service description information. At another policy control entity, a request for an appropriate policy template for a requested service may be received, an appropriate policy template for the requested service may be generated based on user profile information and service description information, and the generated policy template may be deployed together with the user profile information and the service description information to a requesting policy control entity.

Description

Title of the invention

METHODS AND APPARATUSES FOR IMPROVED POLICY CONTROL AND CHARGING ARCHITECTURE BASED ON USE OF POLICY TEMPLATES

Field of the invention

The present invention generally relates to an improved policy control architecture. In particular, the present invention relates to improved and simplified policy control for the convergence of fixed and mobile telecommunication networks.

Background of the invention

In general, policy control is a known process in networks such as communication networks, whereby usually a policy control entity indicates to a policy enforcement entity e.g. how to control bearer resources. In an IP-based (IP: Internet Protocol) network environment, such as an IP Connectivity Access Network (IP-CAN), the IP-CAN bearer may be controlled by way of policy control. Policy control may include QoS (quality of service) control, gating control and the like. Sometimes, policy control is also referred to as policy and charging control.

In traditional second generation (2G) mobile networks, circuit-switched core networks and packet-switched core networks, the user data is controlled by another control plane. The establishing of the users' data sessions and allocating of the network resources are all under the control of this plane. With the transition of networks from circuit switching to IP technology, i.e. packet switching, this methodology of separated control plane and data plane is inherited in the operator's IP-based data networks .

As an example, the IP Multimedia Subsystem (IMS) is defined to control the multimedia services in the core of IP networks with this philosophy. In the IMS architecture, the policy concepts are introduced to control data sessions with the coordination of different network elements. A Policy Decision Function (PDF) entity is defined to generate and deploy policies through different reference points. A Policy Enforcement Point (PEP) entity, which could be collocated in the access network gateway (e.g. the Gateway GPRS Serving Node GGSN) , is responsible for enforcing the policies of QoS, security, gating, NAT (network address translation) and other controls for the specified data flows. Here, the data session is the higher layer concept representing the logical connectivity between applications running in both ends. The data flow is a network layer concept representing the layer 3 connectivity between the two TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports of the two ends.

In the current release of the 3GPP (Third Generation Partnership Project) standards, a more comprehensive policy architecture called Policy Control and Charging (PCC) architecture is proposed to perform the control and charging functions based on the policy concept. In this PCC architecture, there is an entity in the control plane named as Policy and Charging Rules Function (PCRF) which is responsible for making the decision of policies and charging rules. In the user data plane, it is necessary to have an enforcement entity to execute the policies, which is called Policy Charging Enforcement Function (PCEF) . The PCRF has interfaces with other entities, such as a Subscription Profile Repository (SPR) and an Application Function (AF) , to obtain the necessary information to make the policy decision. Especially, when the Application Function provides some service to the user, it will first inform the PCRF of the policy requirements of this service through the Rx interface. Then, when the policy for the traffic flow of this service is determined, this policy will be deployed into corresponding PCEF' s by the PCRF through the Gx interfaces. One example of an Application Function is the Proxy Call Session Control Function (P-CSCF) in the IMS architecture. For other applications, in theory, if the Application Function (AF) , sometimes also referred to as Application Server (AS) , has the control capabilities defined on the Rx interface, it also could talk to PCRF to utilize the PCC system to ensure the delivery of their services .

Figure 1 shows a schematic block diagram of a basic architecture of policy and charging control according to current 3GPP standards. For details of this architecture and the functions of the individual entities, reference is made to the specification 3GPP TS 23.203 V7.1.0, in particular to sections 5 (on pages 14-16), 6.2 (on pages 21-29), and 7 (on pages 33-41) thereof.

By the means of above-outlined policy scheme, it might be believed that networks could be managed to ensure the transferring of different services according to specific requirements in terms of QoS, admission control, monitoring, charging, etc. However, in the environment of many different network domains, there should be another layer of function for the coordination between different PCRF' s in different domains, which may be called horizontal coordination. Hence, the above-outlined policy scheme is still required to be evolved to adapt to the fast-changing demands of current and future networks, providing high quality transferring and other functions.

With the trend of convergence of fixed and mobile telecommunication networks, most of the services in the future, especially the content-related services, are believed to come from the Internet. If the paradigm of the above-outlined policy concept is to be applied to services in/from the Internet based on the current PCC architecture according to Figure 1, it would infer much complexity to the service provider in terms of control signaling. For example, if the web-like Internet services would like to use the PCC system to guarantee the QoS, the web servers are required to implement the complex signaling capability to interact with the PCRF entity. Therefore, there might be some difficulties for the services in the Internet to utilize the PCC system. However, this challenge will have to be embraced by operators to open the network capability.

So, a major factor for service providers e.g. in the Internet for using the capability of networks will be, for example, the ease of use and the efficiency in terms of complexity.

In the following, several shortcomings of the current PCC architecture according to Figure 1 are discussed, upon which the present invention as described below is based.

A first point is the complexity of signaling between Application Function AF and Policy and Charging Rules Function PCRF. Actually, the above-outlined PCC architecture stems from the IP Multimedia Subsystem (IMS) architecture, in which the main service is real time conversation, such as voice. In order to keep the property of real-time characteristic, the PCC system is designed to ensure each session of traffic. Thus, for each session or traffic flow, there is one policy generated to control the data traffic. The Application Function in IMS is a (P-) CSCF, which is responsible for processing SIP (Session Initiation Protocol) signaling to manage the sessions between end users. So, for each conversation, there would be one interaction between the (P-) CSCF and the PCRF to exchange the requirements of policy. The rationale behind this is that a strict quality-of-service is required to be ensured for the real-time services provided in the IMS. Thus, a separated control plane and dedicated devices are required for the signaling functionality.

However, for services in/from the Internet, the application functions or servers are outside of the domains of the network or service operators who provide the connectivity to the users. These servers should have the signaling interface to utilize the policy system, which would bring in the extra complexity for the service providers. For example, the application servers should have the Diameter capability to find out the address of PCRF' s and to transfer the messages to them. In the case of the traffic flows crossing multiple network domains, it is difficult for the service provider to find out all the involved PCRF' s in the path and exchange the information with them. Even more, the data path could be changed due to a network links failure, so that the application server should follow the update of the involved PCEF' s along the path, which is an additional difficulty of dynamicity. Moreover, the control in the fine granularity of each flow may bring remarkable burden to the control plane. For some services with short session duration, the conventional concept of a policy per session is not an efficient approach, which could cause non-negligible signaling traffic from the application functions or servers. Especially, when a service only needs a simple QoS insurance, such as marking the traffic as a coarse QoS class, the application functions or servers still need to send out the signaling to require the deployment of the policy for each data session.

A second point is the complexity between Policy and Charging Rules Function PCRF and Policy Control Enforcement Function PCEF.

Based on the definition of PCC in 3GPP, as outlined above, the PCEF could also give some information of bearer attributes to the PCRF as the input for the policy decision. When the PCRF obtains the information about a service flow from the Application Function AF, the Subscription Profile Repository SPR and the Policy Control Enforcement Function PCEF, the PCRF would decide what policy shall be applied to this specific flow. Then, this policy will be deployed to the according PCEF' s for the actual enforcement. Therefore, there would be heavy load of signaling about policies between PCRF and PCEF when there is a huge number of data flows requiring different policies.

A third point is the large number of policies in Policy Control Enforcement Function PCEF. In the PCEF are stored the active policies for the traffic controlling. In the core of networks, the number of policies could be very huge, which may cause a scalability problem. The controlling of a huge number of traffic flows with a huge number of policies is not economical, in particular for a PCEF that is placed close to the center of networks.

Currently, it is the way of policy control to perform the service control in the network. Following the direction of traditional telecommunication methodology, with the assumption of the availability of the dedicated control plane, the complexity of PCRF, PCEF and the corresponding signaling exchanging is considered to be a burden when providing QoS-guaranteed service control.

As regards the issue of policy scalability in the PCEF, it has been proposed to aggregate the traffic flows with same policy requirements in the core networks. Thus, the similar traffic flows in terms of policy requirements sharing a common path could be aggregated and only one policy could be applied to this aggregation flow. However, considering the complexity of network topology and volatile traffic flows, it is not easy to find the aggregation point and perform aggregation and de- aggregation at the right place. And for the complexity of signaling between AF, PCRF and PCEF, as discussed above, such an approach could not provide an improvement.

In view of the above, it is evident that there exist several problems and shortcomings in the field of policy control in telecommunication networks.

Thus, a solution to the above problems and shortcomings is needed for providing an effective policy control in telecommunication networks such as e.g. for an IP Multimedia Subsystem as one non-limiting example.

Summary of embodiments of the invention

The present invention and its embodiments are made to address one or more of the above-described drawbacks and shortcomings. Thus, the present invention and its embodiments are intended to at least alleviate drawbacks and shortcomings in policy (and charging) control.

According to an exemplary first aspect of the present invention, there is provided a method comprising receiving a service access request from a user, determining an appropriate policy template for the service requested by the service access request, and setting up a proper policy for the requested service based on the determined appropriate policy template, user profile information and service description information

According to further developments or modifications thereof, one or more of the following applies:

- the method further comprises forwarding the received service access request and related service data to an application function for the requested service, and receiving policy requirements for the requested service from the application function, wherein the proper policy is set up based on the determined appropriate policy template, user profile information, service description information and the received policy requirements of the application function,

- the method further comprises negotiating policy requirements for specific service flows of the requested service with an application function for the requested service, and updating the policy based on the negotiated policy requirements,

- the policy requirements are received and/or negotiated by means of in-band signaling being coupled with service data,

- the in-band signaling comprises at least one of transporting signaling information in an IP option header field and executing a NSIS signaling layer protocol application, - the method further comprises authenticating the requested service,

- when determining an appropriate policy template for the requested service fails, the method further comprises requesting an appropriate policy template from a policy and charging rules function, and receiving an appropriate policy template together with user profile information and service description information from a policy and charging rules function,

- the method further comprises receiving a request for policy template modification or removal from a policy and charging rules function, keeping the current policy template until not being in use any more, and modifying or removing the policy template being requested to be modified or removed, and/or - the method is operable at a policy control enforcement function.

According to an exemplary second aspect of the present invention, there is provided a method comprising receiving a request for an appropriate policy template for a service requested by a user from a policy control enforcement function, generating an appropriate policy template for the requested service based on user profile information and service description information, and deploying the generated policy template together with the user profile information and the service description information to the requesting policy control enforcement function .

- when relevant user profile information and/or service description information is not available, the method further comprises at least one of querying user profile information of the user requesting the service from a subscription profile repository, and querying service description information of the requested service from a service registry database,

- the user profile information comprises at least one of user identity, allowable services of the user, quality-of-service parameters for specific services, charging rules for specific services, and user group membership attributes,

- the service description information comprises at least one of service name or identification, service descriptions or media type, service application server address or port numbers, quality-of-service and charging requirements, a right of using a policy capability, and service group membership attributes, - the method further comprises sending a request for policy template modification or removal to the requesting policy control enforcement function, and/or

- the method is operable at a policy and charging rules function .

According to an exemplary third aspect of the present invention, there is provided an apparatus comprising a service access request receiver configured to receive a service access request from a user, a policy template determiner configured to determine an appropriate policy template for the service requested by the service access request, and a policy setter configured to set up a proper policy for the requested service based on the determined appropriate policy template, user profile information and service description information.

- the apparatus further comprises a service access request transmitter configured to forward the received service access request and related service data to an application function for the requested service, and a policy requirements receiver configured to receive policy requirements for the requested service from the application function, wherein the policy setter is configured to set up the proper policy based on the determined appropriate policy template, user profile information, service description information and the received policy requirements of the application function, - the apparatus further comprises a policy requirements negotiater configured to negotiate policy requirements for specific service flows of the requested service with an application function for the requested service, wherein the policy setter is configured to update the policy based on the negotiated policy requirements,

- the policy requirements receiver and/or the policy requirements negotiater are configured to receive and/or negotiate the policy requirements by means of in-band signaling being coupled with service data, - the policy requirements receiver and/or the policy requirements negotiater are configured to at least one of transport signaling information in an IP option header field and execute a NSIS signaling layer protocol application, - the apparatus further comprises an authenticator configured to authenticate the requested service,

- the apparatus further comprises a policy template requester configured to request an appropriate policy template from a policy and charging rules function, and a policy template receiver configured to receive an appropriate policy template together with user profile information and service description information from a policy and charging rules function, - the apparatus further comprises a policy template modification or removal request receiver configured to receive a request for policy template modification or removal from a policy and charging rules function, wherein the policy setter is configured to keep the current policy template until not being in use any more, and modify or remove the policy template being requested to be modified or removed, and/or

- the apparatus is operable as a policy control enforcement function, and the apparatus comprises an interface with at least one of a user, an access network, a policy and charging rules function, and an application function .

According to an exemplary fourth aspect of the present invention, there is provided an apparatus comprising a policy template request receiver configured to receive a request for an appropriate policy template for a service requested by a user from a policy control enforcement function, a policy template generator configured to generate an appropriate policy template for the requested service based on user profile information and service description information, and a policy template deployer configured to deploy the generated policy template together with the user profile information and the service description information to the requesting policy control enforcement function.

- the apparatus further comprises at least one of a user profile retriever configured to query user profile information of the user requesting the service from a subscription profile repository, and a service description retriever configured to query service description information of the requested service from a service registry database,

- the service description information comprises at least one of service name or identification, service descriptions or media type, service application server address or port numbers, quality-of-service and charging requirements, a right of using a policy capability, and service group membership attributes,

- the apparatus further comprises a policy template modification or removal request transmitter configured to send a request for policy template modification or removal to the requesting policy control enforcement function, and/or

- the apparatus is operable as a policy and charging rules function, and the apparatus comprises an interface with at least one of a policy enforcement function, a subscription profile repository, and a service registry database . According to an exemplary fifth aspect of the present invention, there is provided a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the first aspect and any development or modification thereof.

According to an exemplary sixth aspect of the present invention, there is provided a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the second aspect and any development or modification thereof.

According to an exemplary seventh aspect of the present invention, there is provided a system comprising a policy enforcement function being configured to determine an appropriate policy template for a requested service and to set up a proper policy for the requested service based on the determined appropriate policy template, user profile information and service description information, and a policy and charging rules function being configured to generate an appropriate policy template for a requested service and to deploy the generated policy template together with the user profile information and the service description information to the policy control enforcement function.

According to further developments or modifications thereof, the system further comprises an application function being configured to negotiate policy requirements of the requested service with the policy enforcement function by means of in-band signaling being coupled with service data. According to an exemplary eighth aspect of the present invention, there is provided an apparatus comprising means for receiving a service access request from a user, means for determining an appropriate policy template for the service requested by the service access request, and means for setting up a proper policy for the requested service based on the determined appropriate policy template, user profile information and service description information.

According to further developments or modifications thereof, the apparatus further comprises one or more means for performing operations of the method according to the first aspect and any development or modification thereof.

According to an exemplary ninth aspect of the present invention, there is provided an apparatus comprising means for receiving a request for an appropriate policy template for a service requested by a user from a policy control enforcement function, means for generating an appropriate policy template for the requested service based on user profile information and service description information, and means for deploying the generated policy template together with the user profile information and the service description information to the requesting policy control enforcement function.

According to further developments or modifications thereof, the apparatus further comprising one or more means for performing operations of the method according to the second aspect and any development or modification thereof . Stated in other terms, the present invention and its embodiments propose a solution to improve the PCC architecture defined in 3GPP in an effort to reduce the signaling load and the number of policies in the PCEF' s. With this solution, the network capabilities, which e.g. include QoS and charging, could be more easily utilized e.g. by the services in the Internet by the means of policy. One idea of this solution is to use more static service and user information databases to form a more coarse policy template, and/or to use in-band signaling to exchange policy requirements and response information between application functions, end users and the policy control system. In this regard, among others, new functions and corresponding structures are defined, and/or functions and corresponding structures of existing entities are modified, relocated, improved, etc.

By way of exemplary embodiments of the present invention, one or more of the following facets are presented: - reference points between policy control entities may be modified, e.g. between PCEF, PCRF and AF/AS,

- functions of policy control entities may be modified, e.g. of PCRF and PCEF,

- in-band signaling may be involved in policy control procedures.

By way of exemplary embodiments of the present invention, there one or more of the following advantageous effects may be achieved.

In generic terms, the signaling traffic load in the policy system may be reduced, and the usage of the policy scheme/system for services e.g. in/from the Internet may be simplified. In particular, signaling between a policy and charging rules function and an application function may be reduced or even obviated. Namely, an application function only needs to register its service to a service registry database. No complicated interaction between PCRF and AF are required. Thus, during the operation of the service provided by the AF, the policy requirements signaling for each session is reduced as compared with the conventional PCC architecture.

In particular, signaling between policy and charging rules function and policy control enforcement function may be reduced. Namely, it may be avoided that a number of policies transferred from PCRF to PCEF imposes a heavy load for both entities, when there is huge number of service flows in the PCEF, as it has been the case in the conventional PCC architecture, when the PCRF decides a policy for a service flow. Rather, one PCRF could support more PCEF entities because of the reduced load in this interface according to embodiments of the present invention. That is, only very few signaling traffic load of policy templates is exchanged between this PCRF and PCEF according to embodiments of the present invention.

In particular, policy (and charging) control according to embodiments of the present invention is suitable for Internet services or comparable service types stemming from outside of the policy operator's domains. This is particularly advantageous in view of the current trend that more and more services for mobile and fixed network users will come from the Internet or the like. For the services in/from the Internet, traditionally the best- effort is the actual situation and there is no further complicated signaling for the Internet servers to provide the classified QoS guarantee. With the development of the Internet, the policy concept may help to solve the QoS issue and other network control problems. However, the major part of Internet services do not need very complicated QoS or charging schemes. The simple policy is enough for them, such as service claim. For such services, the present embodiments are especially suitable and work with minimum signaling overhead.

Brief description of the drawings

In the following, the present invention will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which

Figure 1 shows a schematic block diagram of a basic architecture of policy and charging control according to current 3GPP standards,

Figure 2 shows a schematic block diagram of a basic architecture of policy and charging control according to exemplary embodiments of the present invention,

Figures 3A and 3B show an IP option header field in accordance with IPv4 and IPv6, respectively, as a way of performing in-band signaling according to exemplary embodiments of the present invention,

Figure 4 shows a message flow diagram of a first example process of policy template deployment according to exemplary embodiments of the present invention,

Figure 5 shows a message flow diagram of a second example process of policy template deployment according to exemplary embodiments of the present invention, Figure 6 shows a message flow diagram of an example process of policy control according to exemplary embodiments of the present invention,

Figure 7 shows a message flow diagram of an example process of policy template modification/removal according to exemplary embodiments of the present invention,

Figure 8 shows a flow chart of an example procedure at a policy control enforcement function according to exemplary embodiments of the present invention,

Figure 9 shows a flow chart of an example procedure at a policy and charging rules function according to exemplary embodiments of the present invention,

Figure 10 shows a schematic block diagram of a policy control enforcement function according to exemplary embodiments of the present invention, and

Figure 11 shows a schematic block diagram of a policy and charging rules function according to exemplary embodiments of the present invention.

Detailed description of embodiments of the present invention

The present invention is described herein with reference to particular non-limiting examples. A person skilled in the art will appreciate that the invention is not limited to these examples, and may be more broadly applied.

In particular, the present invention and its embodiments are mainly described in relation to a policy and charging control system according to 3GPP standards used as a non- limiting example for an underlying network configuration. As such, the description of the embodiments given herein specifically refers to terminology which is directly related to PCC according to 3GPP. In this regard, when referring to specific examples in the context of PCC according to 3GPP, it is to be noted that any other alternatives may also be utilized as long as compliant with the described features. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the invention in any way.

Figure 2 shows a schematic block diagram of a basic architecture of policy and charging control according to exemplary embodiments of the present invention.

Namely, Figure 2 shows a basic architecture of an improved policy (and charging) control (PCC) system according to an embodiment of the present invention. According thereto, a policy control enforcement function PCEF according to embodiments of the present invention, as described below, interfaces with a policy and charging rules function PCRF according to embodiments of the present invention, and with an application function AF according to embodiments of the present invention, as well as with an access network via which a user connects with the PCC system. There are signaling traffic connections between PCEF and PCRF, and between PCEF and AF. There are data traffic connections between access network and PCEF, and between PCEF and AF. Accordingly, since there are both signaling and data traffic connections between PCEF and AF, in-band signaling as described below may be accomplished on this interface. Further, the policy and charging rules function according to embodiments of the present invention, as described below, interfaces with a subscription profile repository SPR and/or a service registry database according to embodiments of the present invention.

Hence, the signaling through the Rx interface (between PCRF and AF) could be minimized or even obviated. The application function (e.g. application servers AS, proxy call session control function P-CSCF) could send the requirements about the policy of a specific service or service flow directly to the PCEF, for example, in the form of in-band signaling within respective data flows. Details concerning in-band signaling are set out below. Generally, the usage of in-band signaling can provide a simple and flexible means for application functions to issue the (policy) requirements for a respective traffic flow. Since the signaling is coupled with the respective data flows, it is easy for the policy enforcement points (PCEF' s) in the path to receive and perform the control actions to the traffic. Moreover, it is convenient for the application functions to update the policy requirements during a session, e.g. by just sending another in-band signaling message.

According to embodiments of the present invention, in- band signaling may be implemented in any one of many conceivable alternatives. In the following, two possible methods utilizing existing protocols will be discussed as non-limiting examples, which are IP option and NSIS (Next Step in Signaling) .

Regarding the exemplary implementation alternative of IP option, this is based thereon that it is defined for the IP protocol (both of version 4, i.e. IPv4, and of version 6, i.e. IPv6) that there could be optional extra IP header fields in the IP packet containing information being useful for certain network elements. In Figures 3A and 3B, the format of an IP Option header is shown for IPv4 (Fig. 3A) and IPv6 (Fig. 3B) . Details of the thus depicted IP option headers are deemed to be known to the skilled reader, thus being omitted for the sake of brevity. According to certain embodiments of the present invention, the IP Option (of IPv4 or IPv6) is capable of being utilized as the means to transport signaling information in an in-band manner, i.e. coupled with data flows between PCEF' s and AF' s.

Regarding the exemplary implementation alternative of NSIS, this is based thereon that NSIS is a comprehensive path-coupled signaling protocol suite, defined and discussed by the Internet Engineering Task Force (IETF) . There are two layers defined in NSIS. The lower layer is for the signaling transport, named as NSIS Transport Layer Protocol (NTLP) . The NTLP guarantees the transport of signaling messages along the data path, from one signaling entity to the next. The higher layer is for the flexible signaling application, named as NSIS Signaling Layer Protocol (NSLP) . For different applications, there could be different NSLP protocols. Details of NSIS are deemed to be known to the skilled reader, thus being omitted for the sake of brevity. According to certain embodiments of the present invention, NSIS is capable of being utilized as the means to transport signaling information in an in-band manner, i.e. coupled with data flows between PCEF and AF. In this case, a new NSLP application is defined, and the PCEF' s in the path and the application functions both run this signaling application. All the information exchanging between the application functions and the PCC system will thus be performed by the NSIS protocols.

In comparison, the usage of the IP option field in the IP packet header field may be regarded as the simpler alternative, while the usage of NSIS may be regarded as the more capable and flexible alternative.

As an example, if IP option is used, the AF just needs to claim its service name or ID in the IP option header in the first packet of a certain service flow. In this case, the AF does not need to implement the (NSIS) signaling protocol. Only an IP option works. On the other hand, the more powerful signaling protocol, such as NSIS, still could be used for the more flexible traffic control for QoS and charging.

Before describing in detail the various processes and, operations according to embodiments of the present invention, reference is made to the functionality of a policy control enforcement function and a policy and charging rules function according to embodiments of the present invention.

Below, the functionality of a policy control enforcement function (PCEF) according to embodiments of the present invention is described.

The PCEF according to embodiments of the present invention is responsible for one or more of classifying service flows, deciding proper policies for the service flows and enforcing the policies e.g. for QoS control and charging. Hence, the intelligence of the PCEF is represented in that the PCEF does not just detect the service flows e.g. by 5-tuples and enforce the policy. Rather, according to embodiments of the present invention, the PCEF decides the policy dynamically based on a policy template which it obtains from the PCRF. Further, according to embodiments of the present invention, the PCEF may negotiate with the AF about policy requirements of certain services and/or certain service flows.

According to embodiments of the present invention, the PCEF may also exchange signaling with the PCRF in order to query information of user profile and/or service description. The acquired information of user profile and/or service description should be maintained in a local storage for reference and lookup, acting as a fast cache. With the information about user and/or service, the policy template and the AF' s policy or service requirements from the signaling, the PCEF decides about the appropriate policy for data flows and enforce it.

The policy decision requires more computing capability for the PCEF because it talks to the end system e.g. in an in-band signaling channel and generates the policy based on the known policy template. In a simple case, the PCEF receives the service name or ID claimed in the in- band signaling channel and verifies the authorized QoS parameters for this service name. In a more complex case, the PCEF further sends messages to the AF to inform the AF about the network capability or current network conditions, and requests updated requirements about QoS and/or charging. The detailed signaling capability could be aligned with the adopted in-band signaling alternative as described above.

Accordingly, according to embodiments of the present invention, the PCEF may have more intelligence about the policy decision than a conventional PCEF, which serves to reduce signaling traffic between the PCRF and PCEF. At least a part of the policy intelligence may thus be moved to the PCEF. When a user is attached to the access network and tries to connect to an application server, the PCRF - e.g. upon request - could download all the policy information, such as an appropriate policy template, user's profile and service information to the one or more competent PCEF' s. Then the subsequent activity between the user and the application server will be controlled by the one or more competent PCEFs according to the downloaded policy template and current policy requirements e.g. obtained by means of in-band signaling .

Stated in general terms, the PCEF according to embodiments of the present invention is involved in policy decision in a different way as a conventional PCEF. While a conventional PCEF only acts as a passive receiver of a specific policy and enforces it, the PCEF according to embodiments of the present invention receives a policy template, which could be viewed as more general instructions about policy, and decides on its own about the appropriate policy to be enforced according to the real time situation.

Thus, the traffic load of signaling exchanged on the Gx interface between PCRF and PCEF may be greatly reduced. Only policy templates are transferred on this interface, instead of more load of policies.

This is more efficient especially in the simple case such as when only a service type or category is claimed or a simple DSCP (Differentiated Service Code Point) marking is required by application server for the data flow. In this first case, the application server just claims its service type for its data flow, e.g. by IP option. Then, when the PCEF receives the service claim, it could verify based on the deployed policy template about the involved user. If this user is allowed to use this service, the service flow could pass the PCEF. For the later case, the application just sets the DSCP field in the packet header, and the PCEF is responsible for checking the validity and perform the corresponding DiffServ (Differentiated Service) operations. During the time of the data flows, there is no traffic between PCRF and AF (i.e. the application server) for signaling exchanging, so that the overhead is reduced.

Below, the functionality of a policy charging and rules function (PCRF) according to embodiments of the present invention is described.

The PCRF according to embodiments of the present invention comprises functionality including one or more of user profile querying (from SPR) , service description querying (from SRD), policy template decision and deployment (to PCEF) . The decision of policy template will be made according to user profile information and/or service description information.

The user profile information from the SPR may include one or more of the following:

- user identity, - user allowable services,

- for each service, the according QoS parameters,

- for each service, the according charging rules,

- the user's other attributes, such as e.g. belonged groups . The service description information from the SRD may include one or more of the following:

- service name or ID,

- service descriptions or media type, - service application server IP addresses and/or port numbers,

- QoS and charging requirements for this service (in different conditions and for different user groups),

- she right for the service to use the policy capability of the network,

- other service's attributes, such as e.g. belonged service groups .

Accordingly, according to embodiments of the present invention, the AF does not need to provide detailed information about the application session to the PCRF, such as subscriber ID, UE IP address, etc. Instead, the information is provided to a subscription profile repository and stored there more statically. For details, reference is made to the service registration process described below.

The policy template generated by the PCRF describes the allowable actions and the corresponding parameters for the specific users and services. The specific users and services could be abstracted by some attributes, such as user groups and service groups. Other information, like time, location, threshold etc., could also be included in the policy template as the conditions and limitations for the policy template. The possible format of a policy template is not limited by the present specification.

Shortly, in the thus presented PCC architecture, the PCRF is mainly in charge of authorizing services and users, generating the policy template about the users and services, and deploying them to the correspondent PCEF. The PCEF is responsible for the actual application of a policy decision based on the deployed policy template according to certain user/service information and/or dynamic network situations.

In the following, the processes of service registration and policy control, including policy template deployment, policy enforcement, policy modification and policy removal are described in detail by way of message flow diagrams and flow charts of Figures 4 to 9.

Generally, in Figures 4 to 7, numerals in parentheses denote the numbering of subsequent steps or operations. For the remainder of the present specification, it is to be noted that there are different choices for protocols of signaling transfer, and thus the details of each operation or process are not limited to one specific implementation described herein.

The following is a description of an example process of service registering according to embodiments of the present invention.

Before a policy decision may be made, the requirements for certain services are to be obtained. In the IMS system, the details of the service description are contained in SIP (Session Initiation Protocol) messages, which will be received, parsed and understood by the network (e.g. CSCF) . So it is easy for the PCC system to decide the policy when knowing the details about the required services.

Otherwise, the situation is different for services in/from the Internet or other networks outside of the network operator's domains. The access network only acts as bit-pipe and the AF is out of the control of the network operator. When the user does not send the application information (signaling) to the network, the AF has to actively send the service information to the PCC system through the Rx interface to help the PCRF to make the policy decision. In this approach, the information of the service is transferred in the network every time when this service is accessed and the policy is negotiated for every service access session.

Instead of this approach adopted by the PCC architecture, in order to achieve above-outlined objects, it is proposed to take a relative semi-static approach. In this approach, since there would be an agreement between the service provider in the Internet or the like and the network operator about the service in order to utilize the policy capability of the network, there is the possibility of using a registry system to register the service name or some kind of service code in a database. The detailed requirement for the policy capability and related information is stored in this database, which is referred to as Service Registry Database (SRD) . The SRD can be accessed by the PCRF for lookup of the detailed service information. For the purpose of embodiments of the present invention, the way of how the service registers in the database is not limited in any way.

For identifying the service name or service code for a data session, the following ways are conceivable as non- limiting examples.

On the one hand, IP address indexing may be used. Thereby, the IP addresses of the application servers are stored in the Service Registry Database when it is applicable. Thus, the PCRF can know the service name and its information by looking up the destination IP address (maybe plus the destination port number) contained in the user's data packets. For most of stable services in the Internet or the like, whose IP addresses do not change frequently, this method is applicable.

On the other hand, service name indexing may be used. This static register method is not applicable for services for which the IP address of the other side is not fixed, such as the system requiring a distributed overlay (P2P (peer-to-peer) SIP) or central servers (Skype) to locate the node providing the actual service. In this case, it could depend e.g. on the in-band signaling itself to inform the PCEF about the service name or service code. Then, the PCRF could use this name to lookup the SRD to obtain the further information about this service.

The following is a description of example processes of policy template deployment according to embodiments of the present invention.

After the PCRF knows the name and the detailed information of the service accessed by a user, it could combine this with the information from other sources, such as user' s profile from SPR, service description from SRD and/or network conditions from PCEF, to make the decision for the specific appropriate policy template. The policy template could be viewed as the description of traffic handling for certain users and services. It is not necessary for the PCRF to define all the policies based on all the combinations of users and services, which would lead to a huge number of policies, large complexity and potential scalability problems, as discussed above.

One possible method is to use the group concept to present the attributes of the users and services, like the user group used in the email system. Then, the policy template could be generated only based on the group of users and service. After the policy template is decided, it is sent for enforcement to the PCEF through the Gx interface.

Figure 4 shows a message flow diagram of a first example process of policy template deployment according to exemplary embodiments of the present invention. This first example process is based on the situation of a user accessing a new service not known by the PCEF.

According to Figure 4, in step 0, the service Sl running in the AS is registered in the SRD. In step 1, the user starts to establish the session to access the service running on the AS by sending a service access request to the PCEF, and the PCEF in the gateway receives this service access request. In step 2, the PCEF passes the service access request together with the user' s packets to the AS. In step 3, when the PCEF has received the service access request (and passed the traffic) , it checks whether or not this service for this AS and user has been accessed through this PCEF before, i.e. whether or not there is already available an appropriate policy template. Also, if so, the existing policy template in the PCEF is examined for the matching one. This exemplary figure assumes to use the IP address (and port number) to identify the service. According to Figure 4, it is assumed that the requested service is a new service or the requesting user is a new user, and thus no suitable policy template is found in step 3 (indicated by "N") . Then, in step 4, a request message asking for a new and appropriate policy template for the service Sl is sent from the PCEF to the corresponding PCRF. Otherwise, if the PCEF knows the user and service and could find the suitable policy template existing, it will not send the request message to PCRF and will generate the policy for the current session between the user and the service based on the found policy template. This situation is assumed in the example of Figure 6 below.

According to Figure 4, in step 5, the PCRF queries the SRD for detailed information about the service Sl, i.e. service description information, e.g. by means of an IP address, if required. In step 6, the PCRF queries the SPR for the user's profile, i.e. user profile information, if required. In step 7, the SPR responds with the user's profile. In step 8, the SRD responds with the service description of service Sl. In step 9, the PCRF generates the policy template for the service Sl based on the information of user profile, service description and the configuration of the policy system. In step 10, the PCRF sends the information of user profile and service description to the PCEF (as the fast cache) . In step 11, the PCRF deploys the generated policy template for service Sl to the according PCEF. In step 12, the PCEF generates a policy according to the policy template for the current service flow between the user and the service, and enforces it (i.e. setting up of policy) . Thereafter, the PCEF may receive service data from the AS, that is directed to the user, which is under the control of the deployed policy (as indicated by an arrow from AS to PCEF) . As a result, there is established a service flow (i.e. a service data exchange) with policy control between the user and the application function.

Moreover, although not being depicted here, during the session multiple service flows could be running, and the AS could negotiate with the PCEF to dynamically change the policy for specific service flow and generate a new policy based on this policy template for new established service flows.

In the Figure 4, it is assumed that the service name is looked up by the IP address and port number. Another alternative is to use in-band signaling as described above to let the AS claim the service name. To avoid spoofing, the authentication of the AS or service's identity may be guaranteed by a digital certificate or other similar methods.

In summary of the use case of Figure 4, from the perspective of the PCEF according to embodiments of the present invention, the following operations are performed:

- receiving a service access request from a user and forwarding the request to an AS,

- identifying the requested service by either IP address and port number or server name, checking whether there is an available policy template for the request, and setting up a policy for the user if an appropriate policy template is available,

- if no feasible template available, sending a corresponding request to the PCRF,

- receiving a policy template from the PCRF and setting up a policy for the user. In summary of the use case of Figure 4, from the perspective of the PCRF according to embodiments of the present invention, the following operations are performed: - receiving a request with either service ID or IP address of AS for a new policy template from the PCEF,

- if no policy template is available, sending service ID (= IP address and port number, or service ID) to the SRD,

- receiving service info from the SRD, - requesting and receiving user profile from the SPR,

- generating an appropriate policy template based on the received information.

- sending the generated policy template together with user profile and service information to the PCEF.

Figure 5 shows a message flow diagram of a second example process of policy template deployment according to exemplary embodiments of the present invention. This second example process is based on service lookup in the context of in-band signaling, and an optional service authentication is also described.

Generally, the procedure according to Figure 5 is basically comparable to that according to Figure 4. Thus, as regards steps 0 to 2 and 5 to 12, reference is made to the above description of steps 0 to 2 and 3 to 12 of Figure 4

According to Figure 5, step 3 and step 4 are used for service claim and service authentication, which is an alternative method for step 3 according to Figure 4.

Other steps are substantially the same or at least similar with those according to Figure 4. A difference resides in that it is exemplarily assumed for Figure 5 that no service description query from the PCRF to the SRD is required.

Moreover, the query of user' s profile information also could be earlier than that shown in Figures 4 and 5. When the user attaches to the network, this user profile query could be performed e.g. before service authentication. It is allowable at any time before the decision about or the generation of the policy template at the PCRF.

In summary of the use case of Figure 5, from the perspective of the PCEF according to embodiments of the present invention, the following operations are performed: - receiving a service access request from a user and forwarding the request to an AS,

- receiving information (service claim, e.g. signaling messages) from the AS about its service name or ID; based on this service name or ID, the policy system knows detailed information or requirements about this service; the service claim may be done by sending in-band signaling messages, such as e.g. NSIS,

- after the PCEF receives the service claim, there could be some security procedure to authenticate this service claim; any conceivable service authentication is applicable to this end,

- checking whether there is available an appropriate policy template for the user sending the request; the user may be authenticated for accessing the 2G or 3G system with a GBA (Generic Bootstrapping Architecture) procedure defined by 3GPP; the user's IP address is allocated by the GGSN; so, through the IP address, the PCEF may identify the user and communicate with the SPR,

- if no feasible policy template is found, sending a request to the PCRF, - receiving the requested policy template from the PCRF, wherein the policy template is generated by the PCRF.

In summary of the use case of Figure 5, from the perspective of the PCRF according to embodiments of the present invention, the operations are basically the same as described above in connection with Figure 4.

The following example is intended to serve for the better understanding of the respective operations and the underlying rationale.

For example, one user is visiting a video-sharing community and the PCEF may in the beginning ask the PCRF for the user's profile and service description. The PCRF will then check the user' s profile stored in the SPR to obtain the permission, and will query the SRD for the service description information. Then, according to these information, the policy template is finalized to define the allowable QoS parameters with respect to some service and user attributes. During the data session, the application server may have the right to decide the specific QoS requirements for different traffic, such as general browsing, low quality video and high quality video. Thus, the PCRF only generates and deploys the template of policy, which describes the QoS parameter range, user and service's special attribute, etc., to the PCEF. When the traffic flows (and in-band signaling) arrive at the PCEF, the actually enforced policy about the QoS parameters will be negotiated by the PCEF and the application server according to the requirements and network conditions. For the general browsing traffic, the AS will notify the PCEF by in-band signaling, and the best-effort QoS class will be used. For the low quality video traffic, the stream QoS class is used. For the high quality video traffic, the bandwidth could be reserved and strict delay jitter limit may be guaranteed, all of which is guaranteed by the thus decided policy.

The following is a description of an example process of policy control according to embodiments of the present invention .

Figure 6 shows a message flow diagram of an example process of policy control according to exemplary embodiments of the present invention. This example process is based on the situation that an appropriate policy template exists.

After policy templates are deployed in the PCEF, some data sessions could be found matching some policy template, which means a lot of signaling efforts are saved between policy decision point and policy enforcement point. According to Figure 6, the process of policy control and enforcement is shown when an existing policy template for a data session is found in the PCEF.

According to Figure 6, in step 1, the user connects to the AS for the provided/requested service Sl. In step 2, the PCEF receives the service access request and passes it together with user's service data to the AS. In step 3, the PCEF checks its local cache for the user profile, service description and existing policy template. If there is available a suitable policy template (indicated by "Y"), in step 4, the PCEF can directly generate the policy for this service flow (i.e. service data exchange) . Afterwards, the PCEF may receive service data from the AS, that is directed to the user, which is under the control of the deployed policy (as indicated by an arrow from AS to PCEF) , and the AS could negotiate with the PCEF to generate or update the policies to control the service flows in this data session based on this policy template.

The following is a description of an example process of policy template modification/removal according to embodiments of the present invention.

Figure 7 shows a message flow diagram of an example process of policy template modification/removal according to exemplary embodiments of the present invention.

When the operator needs or desires to tune the network, the principles and rules for the policy template making could be changed. Thus, the PCC system should have the capability of modifying the policy templates in the PCEF.

On the other hand, it could be needed or desirable to remove some policy templates deployed in the PCEF. Thus, the PCC system should have such a capability.

Figure 7 describes a process between the PCRF and the PCEF, which is equally applicable for policy template modification and removal. The formats and protocols for the message exchange between the PCRF and the PCEF are arbitrary, and not restricted by embodiments of the present invention. For example, Diameter could be used.

According to Figure 7, in step 1, the PCRF sends a message of a policy template modification or removal request to the PCEF. In step 2, the PCEF receives the modification or removal request, and still keeps the to- be-modified or the to-be-deleted policy template. The PCEF first needs to find out all the related data sessions using this policy template, and to monitor these sessions. All to-be-modified or the to-be-deleted policy templates are kept until no current sessions are related to these templates. In step 3, the PCEF could optionally send a message of response to the PCRF to indicate the status of the requested modification or removal (e.g.

"modification/removal in progress") . In step 4, the PCEF checks the status of the involved data sessions, i.e. whether they are all terminated. If all of the involved data sessions are ended (indicated by "Y") , in step 5, the PCEF performs the requested modification or removal according to the received information in the modification or removal request. If not, step 4 is maintained as long as necessary. In step 6, when the policy template modification or removal is finished, a response message may be sent to the PCRF to indicate the successful completion (e.g. "modification/removal done") . Otherwise, a failure response message may be sent to the PCRF (e.g. "modification/removal failed") .

While in the foregoing processes and operations are described in the context of the interaction between various functional entities, the individual operations and procedures of the individual functional entities are detailed hereinafter with reference to Figures 8 and 9.

With respect to Figures 8 and 9, it is to be noted that these flow charts depict all conceivable operations and procedures, while it is not necessary that all of these are performed in a certain situation. Accordingly, in view of the underlying situation, respective operations or procedures may be omitted, or the sequence of respective operations or procedures may be altered. For the sake of brevity, Figures 8 and 9 are explained mainly by referring to the foregoing description of processes in connection with Figures 4 to 7.

Figure 8 shows a flow chart of an example procedure at a policy control enforcement function according to exemplary embodiments of the present invention.

Receiving a service access request corresponds to step 1 of Figures 4 and 5. The optional sequence of service access request forwarding, policy requirements receipt and service authentication correspond to steps 2 of Figure 4 or steps 2, 3 and 4 of Figure 5 or steps 2 and 3 of Figure 6. Checking the availability of an appropriate policy template (and determining thereof in the case of availability) corresponds to step 3 of Figure 4 or 6 or step 5 of Figure 5. Requesting a policy template corresponds to step 4 of Figure 4 or step 6 of Figure 5. Receiving a policy template and respective information corresponds to steps 10 and 11 of Figure 4 or 5. Setting up a policy corresponds to step 12 of Figures 4 or 5 (in the case of NO in the policy template availability check) or step 4 of Figure 6 (in the case of YES in the policy template availability check) . Exchanging service data (i.e. establishing a service flow) with policy control by the thus set up policy between the user and the application function corresponds to the service flow block of Figures 4 to 6. The optional sequence of modification/removal request receipt, policy keeping and policy modification/removal correspond to steps 1, 2 and 5 of Figure 7. The optional sequence of policy requirements negotiation and policy updating are not explicitly depicted in any preceding figure, but may be accomplished at any time during policy control, preferably by means of in-band signaling as described above. The thus modified or updated policy is used for service data exchange, or the service data exchange is subsequently accomplished with no specific policy (or a predetermined standard policy) , if the currently set up policy is removed.

Figure 9 shows a flow chart of an example procedure at a policy and charging rules function according to exemplary embodiments of the present invention.

Receiving a policy template request corresponds to step 4 of Figure 4 or step 6 of Figure 5. Checking the availability of an appropriate policy template is not explicitly depicted in any preceding figure. Checking of the availability of a proper user profile and a proper service description are also not explicitly depicted in any preceding figure, but naturally precede the corresponding querying/retrieving operations which correspond to steps 5 and 8 of Figure 4 and steps 6, 7 of Figure 4 or steps 7, 8 of Figure 5, respectively. The sequence of these operations is arbitrary. Generating an appropriate policy template corresponds to step 9 of Figure 4 or 5. Deploying the generated policy template and respective information corresponds to steps 10 and 11 of Figure 4 or 5. The optional sending of a modification/removal request corresponds to step 1 of Figure 7.

Although in the foregoing embodiments of the present invention have been described mainly with reference to methods, procedures and functions, corresponding embodiments of the present invention also cover respective apparatuses, network nodes, including both software and/or hardware thereof. Respective exemplary embodiments of the present invention are described below referring to Figures 10 and 11, while for the sake of brevity reference is made to the detailed description of respective corresponding methods and operations according to Figures 4 to 9, respectively.

In Figures 10 and 11, the solid line blocks are basically configured to perform the respective operations. The entirety of blocks is basically configured to perform the methods and operations as described above, respectively. With respect to Figures 10 and 11, it is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively. Such functional blocks are implementation-independent, i.e. may be implemented by means of any kind of hardware or software, respectively. The lines/arrows interconnecting individual blocks are meant to illustrate an operational coupling there-between, which on the one hand is implementation- independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional entities not shown. It is noted that not all of the thus depicted functional blocks have to be present at the same time. Further, it is noted that arbitrary functional blocks may be implemented by a common operational unit despite exemplarily being depicted as separate blocks.

Generally, the individual functional blocks depicted in Figures 10 and 11 are to be understood as being configured to implement corresponding operations or procedures being equally denoted, respectively.

Figure 10 shows a schematic block diagram of a policy control enforcement function according to exemplary embodiments of the present invention. According to embodiments of the present invention, the thus depicted apparatus may interface with one or more of a user, an application function, and a policy and charging rules function.

Stated in general terms, according to the non-limiting embodiment of Figure 10, the thus depicted apparatus comprises the following functional blocks.

A service access request receiver represents means for receiving a service access request from a user. A service access request transmitter represents means for forwarding a received service access request to an application function. A policy template checker represents means for checking the availability of an appropriate policy template. A policy template determiner represents means for determining an appropriate policy template, if found to be available. A policy template requester represents means for requesting the provision of an appropriate policy template from another apparatus such as e.g. a PCRF, and a policy template receiver represents means for receiving a requested policy template there-from. A policy setter represents means for setting up (i.e. deciding, deploying and/or enforcing) a policy based on the existing or received appropriate policy template and further relevant information. A policy requirements receiver represents means for receiving policy requirements (e.g. a service claim) from an application function. A service authenticator represents means for authenticating a service or service flow. A modification/removal request receiver represents means for receiving a modification or removal request from another apparatus. A policy requirements negotiater represents means for negotiating policy requirements with an application function, e.g. by in-band signaling. A storage represents means for storing (caching) any available and/or received information for future use. Any functional block stores relevant information therein, and retrieves necessary information there-from, when required. A service data exchanger represents means for exchanging service data (i.e. to establish a service flow) between the user and the application function with policy control by the policy being set up by the policy setter.

The thus depicted apparatus may for example be implemented in or by a policy control enforcement function .

Figure 11 shows a schematic block diagram of a policy and charging rules function according to exemplary embodiments of the present invention. According to embodiments of the present invention, the thus depicted apparatus may interface with one or more of a policy control enforcement function, a subscription profile repository, and a service registry database.

Stated in general terms, according to the non-limiting embodiment of Figure 11, the thus depicted apparatus comprises the following functional blocks.

A policy template request receiver represents means for receiving a request for an appropriate policy template from another apparatus, e.g. a PCEF. A policy template checker represents means for checking the availability of an appropriate policy template. A user profile checker represents means for checking the availability of proper user profile information, and a user profile retriever represents means for retrieving such user profile information by means of querying e.g. a SPR. A service description checker represents means for checking the availability of proper service description information, and a service description retriever represents means for retrieving such service description information by means of querying e.g. a SRD. A policy template generator represents means for generating a policy template based on the available or retrieved user profile information and service description information in accordance with the received policy template request. A policy template deployer represents means for deploying the generated or available policy template in accordance with the received policy template request. A modification/removal request transmitter represents means for sending a modification or removal request e.g. to a PCEF, which is for example initiated by a network operator. A storage represents means for storing (caching) any available and/or received information for future use. Any functional block stores relevant information therein, and retrieves necessary information there-from, when required.

The thus depicted apparatus may for example be implemented in or by a policy and charging rules function .

In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device. Furthermore, method steps and functions likely to be implemented as software code portions and being run using a processor at one of the entities are software code independent and can be specified using any known or future developed programming language such as e.g. Java, C++, C, and Assembler. Method steps and/or devices or means likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS,

BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example. Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to those skilled in the art.

Software in the sense of the present description comprises software code as such comprising code means for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable storage medium having stored thereon a respective data structure or code portions or embodied in a signal or in a chip, potentially during processing thereof.

Generally, for the purpose of the present invention as described herein above, it should be noted that - an access technology may be any technology by means of which a user equipment can access an access network (e.g. via a base station or generally an access node) . Any present or future technology, such as WLAN (Wireless Local Access Network) , WiMAX (Worldwide Interoperability for Microwave Access), BlueTooth, Infrared, and the like may be used; although the above technologies are mostly wireless access technologies, e.g. in different radio spectra, access technology in the sense of the present invention may also imply wirebound technologies, e.g. IP based access technologies like cable networks or fixed lines but also circuits switched access technologies; access technologies may be distinguishable in at least two categories or access domains such as packet switched and circuit switched, but the existence of more than two access domains does not impede the invention being applied thereto, - an access network may be any device, apparatus, unit or means by which a station, entity or other user equipment may connect to and/or utilize services offered by the access network; such services include, among others, data and/or (audio-) visual communication, data download etc.;

- a user or user equipment may be any device, apparatus, unit or means by which a system user may experience services from an access network such as a mobile phone, personal digital assistant PDA, or computer; - devices, apparatuses, units or means can be implemented as individual devices, apparatuses, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, apparatus, unit or means is preserved,

- an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor; - a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

In view of the above, stated in general terms, there may be provided a policy control (and charging) architecture and its constituents, wherein the use of in-band signaling is described for policy requirements negotiations, and wherein certain policy control functions may be relocated, modified, added, etc.

There is provided an improved policy control (and charging) architecture, which is based on the use of policy templates. At one policy control entity, a service access request may be received, an appropriate policy template for the requested service may be determined, and a proper policy for the requested service may be set up based on the determined appropriate policy template, user profile information and service description information. At another policy control entity, a request for an appropriate policy template for a requested service may be received, an appropriate policy template for the requested service may be generated based on user profile information and service description information, and the generated policy template may be deployed together with the user profile information and the service description information to a requesting policy control entity. The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.

Even though the invention is described above with reference to the examples according to the accompanying drawings, it is to be understood that the invention is not restricted thereto. Rather, it is apparent to those skilled in the art that the present invention can be modified in many ways without departing from the scope of the inventive idea as disclosed herein.

Claims

1. A method comprising receiving a service access request from a user, determining an appropriate policy template for the service requested by the service access request, and setting up a proper policy for the requested service based on the determined appropriate policy template, user profile information and service description information.

2. The method of claim 1, further comprising forwarding the received service access request and related service data to an application function for the requested service, and receiving policy requirements for the requested service from the application function, wherein the proper policy is set up based on the determined appropriate policy template, user profile information, service description information and the received policy requirements of the application function.

3. The method of claim 1 or 2, further comprising negotiating policy requirements for specific service flows of the requested service with an application function for the requested service, and updating the policy based on the negotiated policy requirements .

4. The method of claim 2 or 3, wherein the policy requirements are received and/or negotiated by means of in-band signaling being coupled with service data.

5. The method of claim 4, wherein the in-band signaling comprises at least one of transporting signaling information in an IP option header field and executing a NSIS signaling layer protocol application.

6. The method of any one of claims 1 to 5, further comprising authenticating the requested service.

7. The method of any one of claims 1 to 6, wherein, when determining an appropriate policy template for the requested service fails, the method further comprises requesting an appropriate policy template from a policy and charging rules function, and receiving an appropriate policy template together with user profile information and service description information from a policy and charging rules function.

8. The method of any one of claims 1 to 7, further comprising receiving a request for policy template modification or removal from a policy and charging rules function, keeping the current policy template until not being in use any more, and modifying or removing the policy template being requested to be modified or removed.

9. The method of any one of claims 1 to 8, wherein the method is operable at a policy control enforcement function.

10. A method comprising receiving a request for an appropriate policy template for a service requested by a user from a policy control enforcement function, generating an appropriate policy template for the requested service based on user profile information and service description information, and deploying the generated policy template together with the user profile information and the service description information to the requesting policy control enforcement function.

11. The method of claim 10, wherein, when relevant user profile information and/or service description information is not available, the method further comprises at least one of querying user profile information of the user requesting the service from a subscription profile repository, and querying service description information of the requested service from a service registry database.

12. The method of claim 10 or 11, wherein the user profile information comprises at least one of user identity, allowable services of the user, quality-of-service parameters for specific services, charging rules for specific services, and user group membership attributes, and the service description information comprises at least one of service name or identification, service descriptions or media type, service application server address or port numbers, quality-of-service and charging requirements, a right of using a policy capability, and service group membership attributes.

13. The method of any one of claims 10 to 12, further comprising sending a request for policy template modification or removal to the requesting policy control enforcement function .

14. The method of any one of claims 10 to 13, wherein the method is operable at a policy and charging rules function.

15. An apparatus comprising a service access request receiver configured to receive a service access request from a user, a policy template determiner configured to determine an appropriate policy template for the service requested by the service access request, and a policy setter configured to set up a proper policy for the requested service based on the determined appropriate policy template, user profile information and service description information.

16. The apparatus of claim 15, further comprising a service access request transmitter configured to forward the received service access request and related service data to an application function for the requested service, and a policy requirements receiver configured to receive policy requirements for the requested service from the application function, wherein the policy setter is configured to set up the proper policy based on the determined appropriate policy template, user profile information, service description information and the received policy requirements of the application function.

17 . The apparatus of claim 15 or 16, further comprising a policy requirements negotiater configured to negotiate policy requirements for specific service flows of the requested service with an application function for the requested service, wherein the policy setter is configured to update the policy based on the negotiated policy requirements.

18. The apparatus of claim 16 or 17, wherein the policy requirements receiver and/or the policy requirements negotiater are configured to receive and/or negotiate the policy requirements by means of in-band signaling being coupled with service data.

19. The apparatus of claim 18, wherein the policy requirements receiver and/or the policy requirements negotiater are configured to at least one of transport signaling information in an IP option header field and execute a NSIS signaling layer protocol application.

20. The apparatus of any one of claims 15 to 20, further comprising an authenticator configured to authenticate the requested service.

21. The apparatus of any one of claims 15 to 20, the apparatus further comprising a policy template requester configured to request an appropriate policy template from a policy and charging rules function, and a policy template receiver configured to receive an appropriate policy template together with user profile information and service description information from a policy and charging rules function.

22. The apparatus of any one of claims 15 to 21, further comprising a policy template modification or removal request receiver configured to receive a request for policy template modification or removal from a policy and charging rules function, wherein the policy setter is configured to keep the current policy template until not being in use any more, and modify or remove the policy template being requested to be modified or removed.

23. The apparatus of any one of claims 15 to 22, wherein the apparatus is operable as a policy control enforcement function, and the apparatus comprises an interface with at least one of a user, an access network, a policy and charging rules function, and an application function.

24. An apparatus comprising a policy template request receiver configured to receive a request for an appropriate policy template for a service requested by a user from a policy control enforcement function, a policy template generator configured to generate an appropriate policy template for the requested service based on user profile information and service description information, and a policy template deployer configured to deploy the generated policy template together with the user profile information and the service description information to the requesting policy control enforcement function.

25. The apparatus of claim 24, the apparatus further comprising at least one of a user profile retriever configured to query user profile information of the user requesting the service from a subscription profile repository, and a service description retriever configured to query service description information of the requested service from a service registry database.

26. The apparatus of claim 24 or 25, wherein the user profile information comprises at least one of user identity, allowable services of the user, quality-of-service parameters for specific services, charging rules for specific services, and user group membership attributes, and the service description information comprises at least one of service name or identification, service descriptions or media type, service application server address or port numbers, quality-of-service and charging requirements, a right of using a policy capability, and service group membership attributes.

27. The apparatus of any one of claims 24 to 26, further comprising a policy template modification or removal request transmitter configured to send a request for policy template modification or removal to the requesting policy control enforcement function.

28. The apparatus of any one of claims 24 to 27, wherein the apparatus is operable as a policy and charging rules function, and the apparatus comprises an interface with at least one of a policy enforcement function, a subscription profile repository, and a service registry database.

29. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 1 to 9.

30. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 10 to 14.

31. A system comprising a policy enforcement function being configured to determine an appropriate policy template for a requested service and to set up a proper policy for the requested service based on the determined appropriate policy template, user profile information and service description information, and a policy and charging rules function being configured to generate an appropriate policy template for a requested service and to deploy the generated policy template together with the user profile information and the service description information to the policy control enforcement function.

32. The system of claim 31, further comprising an application function being configured to negotiate policy requirements of the requested service with the policy enforcement function by means of in-band signaling being coupled with service data.

33. An apparatus comprising means for receiving a service access request from a user, means for determining an appropriate policy template for the service requested by the service access request, and means for setting up a proper policy for the requested service based on the determined appropriate policy template, user profile information and service description information.

34. The apparatus according to claim 33, further comprising one or more means for performing operations of the method according to any one of claims 2 to 9.

35. An apparatus comprising means for receiving a request for an appropriate policy template for a service requested by a user from a policy control enforcement function, means for generating an appropriate policy template for the requested service based on user profile information and service description information, and means for deploying the generated policy template together with the user profile information and the service description information to the requesting policy control enforcement function.

36. The apparatus according to claim 35, further comprising one or more means for performing operations of the method according to any one of claims 11 to 14.