WO2010052030A1

WO2010052030A1 - Policy control apparatus and method for handing over policy control information

Info

Publication number: WO2010052030A1
Application number: PCT/EP2009/052676
Authority: WO
Inventors: Gerald Goermer; Ralph KÜHNE; Mirko Schramm
Original assignee: Nokia Siemens Networks Oy
Priority date: 2008-11-07
Filing date: 2009-03-06
Publication date: 2010-05-14
Also published as: WO2010051853A1

Abstract

The present invention relates to the technical field of communication networks. In particular, the present invention relates to a policy management apparatus of a communication network, to a method of operating a communication network, to a computer-readable medium, to a Broadband Remote Access Server comprising a policy management apparatus and to a use of a Subscription Profile Repository. A subscriber information device, which is adapted to store permanent information of a subscriber of the communication network, like e. g. which services the subscriber may access, is also adapted to store session information generated by a policy decision device to generate policy control rules. The policy decision device is adapted to generate or gather this information, the policy control context information, and to send it to the subscriber information device.

Description

POLICY CONTROL APPARATUS AND METHOD FOR HANDING OVER POLICY CONTROL INFORMATION

Reference to related applications

This application claims the benefit and filing date of PCT/EP2008/065156 filed November 07, 2008 and entitled "Policy Control Apparatus and method for handing over Policy control information of a Second Anchor device to a first Anchor Device".

Technical field of the invention

The present invention relates to the technical field of communication networks. In particular, the present invention relates to a policy management apparatus of a communication network, to a method of operating a communication network, to a computer-readable medium, and to a use of a Subscription Profile Repository.

Background of the invention

Policy management in a communication network may be an important task, as the policies may regulate the access of the subscribers to the communication network. In particular, policy rules may regulate what services the subscribers of the communication network may use, what quality of service (QoS) they may be granted and how they are charged for using a particular service.

A component of a policy management system may be a Policy Decision Point (PDP) which creates policy rules that may regulate the access of the subscribers to the communication network. A communication network may comprise a plurality of PDPs. For example, each operator of a part of the communication network may have a PDP, or for reasons of scalability may have several PDPs. If a subscriber accesses over an access network the communication network to use a service, a PDP will create policy rules regulating the access of the subscriber to the access network and/or the communication network. If the subscriber uses a mobile device, like a mobile phone, it may be possible that the subscriber changes to a second access network during the use of the service. Then it may be possible, that a second PDP will create a second set of policies rules.

For a policy control system with a plurality of PDPs it may be beneficial if a communication between the PDPs is established.

WO2008/016324 discloses methods and arrangements for policy decision point discovery in a roaming scenario in an IP network. To be able to set up a connection between two policy decision points, it is proposed, that one policy decision point receives the address of another policy decision point, so that the one policy decision point can contact the other policy decision point by using that address.

In a 3GPP architecture, the PDP functions may be handled by the Policy and Charging Rules Function (PCRF) .

The document 3GPP (Third Generation Partnership Project) TS23.203, "Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and Charging Control Architecture", Release 8, V8.2.0, 2008-06 may specify an overall stage 2 level functionality for policy and charging control that encompasses high level functions such as flow base charging, including charging control and online credit control and policy control for IP-CAN (IP Connectivity Access Network), e.g. GPRS (General Packet Radio Service), I-WLAN (Interworking WLAN), fixed broadband, etc..

The document 3GPP TS 32.251, "3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Packet Switched (PS) domain charging", Release 8, V8.6.0, 2008-06 may specify charging functionality and charging management for policy and charging control in 3GPP networks.

In particular, if a service established in a 3GPP network is handed over to a second network, two different PDPs may be involved.

US patent application US2008/0229385 discloses a method including a context transfer between a source PCEF and a target PCRF. The source PCEF is associated to a source PCRF.

Summary of the invention

If no communication between the PDPs of a communication network is established, every PDP has to gather the information for creating policy rules which regulate the access of a subscriber to the access network and/or the communication network. This may cause high network traffic. In particular, information about the services that are currently used by the subscriber has to be gathered by every PDP involved. This may cause a high traffic in the network and increase the time until the subscriber can continue the ongoing service via the new access.

Further, in a handover scenario or inter-system mobility scenario, the policy rules created by a first PDP may diverge from the policy rules created by a second PDP due to differing policies with regard to e.g. the access, operator or time-of-day. Having the policy control context information available in the second PDP may increase the chance for a seamless inter-system mobility without any impacts on the currently running services. Furthermore, the creation of the second set of policies rules may be time consuming and will create a high load on the apparatus creating the second policy rules. There may be a need for a more efficient policy control system. Further, there may be a need to provide a more efficient handing over of services between two networks.

According to an exemplary embodiment of the present invention, a policy management apparatus for a communication network is provided, the policy management apparatus comprising: a subscriber information device for storing information of a subscriber of the communication network, and a policy decision device for generating policy control context information of the subscriber, wherein the policy decision device is adapted for generating policy control rules based on the policy control context information, wherein the policy decision device is adapted for sending the policy control context information to the subscriber information device, and wherein the subscriber information device is adapted for storing the policy control context information .

The subscriber information device may be a subscriber database. The policy decision device may be a policy decision point .

The subscriber information device, which is adapted to store permanent information of the subscriber, like e. g. which services the subscriber may access, is also adapted to store information generated by the policy decision device to generate the policy rules. The policy decision device is adapted to generate or gather this information, the policy control context information, and is further adapted to send it to the subscriber information device.

Permanent information may be information only changing slowly with respect to session information. For example, permanent information may be the contract type of the subscriber, wherein the contract type may define which services the subscriber may access or how the subscriber has to be charged for certain services. Additionally, the policy control context information may comprise information about the currently ongoing services of the subscriber and their parameters. For example, this information may comprise port numbers and IP-addresses, QoS information and information about the state of a service e.g. call on hold.

Generating information may also comprise creating information or gathering information, like gathering information which has been sent to the policy decision device from other components of the communication network, like a user equipment of the subscriber.

Policy control may also comprise charging control. For example, the policy control context information may also comprise charging control context information.

The policy control context information may comprise at least information about which services are currently activated for the respective user as well as the currently selected parameters for them like the quality of service (QoS) and packet filter information (which may be part of the respective policy rules, too) . The policy control context information may be a representation of the status information of the police decision point.

According to an exemplary embodiment of the invention, a subscriber information device is provided, wherein the subscriber information device is adapted for storing information of a subscriber of the communication network, wherein the subscriber information device is adapted for storing the policy control context information. The subscriber information device may be adapted to receive policy control context information from a policy decision device .

According to an exemplary embodiment of the invention, a policy decision device is provided, wherein the policy decision device is adapted for generating policy control context information of the subscriber, wherein the policy decision device is adapted for generating policy control rules based on the policy control context information, wherein the policy decision device is adapted for sending the policy control context information to a subscriber information device.

A direct interaction between two policy decision points or a policy decision point and a policy enforcement point may require interfaces between the two policy decision points or a policy decision point and the policy enforcement point. This may cause additional efforts especially regarding inter- operator agreements, node configuration and the need to support another inter-operator signalling connection. The storing of the policy control context information in the subscriber information device may be done via a present interface used for the communication of the policy decision device with the subscriber information device. Furthermore, the identity or IP-address of a policy decision point or device may not be made available to another policy decision point or device or an policy enforcement function. A transfer of the identity of the policy decision point or device or its IP-address information may not be necessary.

According to an exemplary embodiment of the present invention, the policy decision device is a Policy and Charging Rules Function (PCRF) of a 3GPP network. Alternatively, the policy decision device may be associated with a network selected from a group of networks, the group comprising a non-3GPP communication network, a fixed broadband network and a DSL network.

According to an exemplary embodiment of the present invention, the subscriber information device is a Subscription Profile Repository (SPR) of a 3GPP network. Alternatively, the subscriber information device may be associated with a network selected from a group of networks, the group comprising a non-3GPP communication network, a fixed broadband network and a DSL network.

Generally in this text, the word "non-3GPP" may be used to describe networks which may substantially only allow charging on the bearer level and may substantially not provide charging on flow level, for example DSL, WiFi. If a connection in such a non-3GPP network may be setup, in a network control this connection may appear as a single connection with substantially no further granularity. Thus, it may be an aspect of the present invention to split such a single bearer in service streams or service flows to allow a service based charging if a handover or inter-system change from a network having fine granularity may happen.

WLAN, WiMAX™ may be non-3GPP networks which may be integrated in a 3GPP environment.

In the context of this document, "non-3GPP" may define a network, a network environment or a network technology which may only support mobility functionalities on higher layers of the OSI (Open Systems Interconnection) Reference Model than layer 3 or L3. For example, a "non-3GPP" network may be a network, which may support mobility on an application layer or on layer 7, e.g. SIP. A non-3GPP network may be a wire bound, fixed or wireless network.

A 3GPP network may support mobility on a network layer or on layer 3, e.g. mobile IP as defined in IP v6. On higher layers than layer 3, layer 3 mobility or network layer mobility may be invisible.

A Subscription Profile Repository (SPR) which is part of the PCC architecture described in 3GPP TS 23.203 (v8.2.0) may be used as subscriber information device. The SPR may become a common storage node for the involved PCRFs. A SPR used as subscriber information device may be denoted as extended Subscription Profile Repository (SPR*) . The interaction between the PCRF and the SPR* may take place over the extended Sp reference point or interface, called Sp*. The 3GPP procedures may be extended by enabling the PCRF to use the SPR* as a storage node for policy control context information. The PCRF may save the policy control context information to the SPR*. This may enable another component of the network, for example another PCRF, to retrieve the policy control context information.

According to an exemplary embodiment of the present invention, a policy management apparatus is provided, the policy apparatus further comprising: a policy enforcement device for enforcing policy rules of the subscriber accessing the communication network, wherein the policy enforcement device is adapted for requesting the policy rules from the policy decision device, wherein the policy decision device is adapted for sending the policy control context information to the subscriber information device after the policy enforcement device has requested the policy rules or after the policy context information has changed due to other reasons .

The policy enforcement device may be a policy enforcement point .

A possible way to trigger the sending of the policy control context information may be the request of the policy enforcement point to generate the policy rules. After the policy decision device has received the request to generate the policy rules, the policy decision device gathers the policy control context information and generates the policy rules. After that the policy decision device sends the policy control context information to the subscriber information device. In addition or alternatively, the policy decision device may update the policy control context information in the subscriber information device after the policy context information has changed due to other reasons. The policy decision device may save the currently applied policy control context information to the subscriber information device whenever a change in this information occurs. This means that another component of the communication network may retrieve or request the policy control context information that is currently applied at any time, for example together with the other subscriber- /subscription-related information when the subscriber tries to establish an IP-CAN session over a second access network.

According to an exemplary embodiment of the present invention, the policy enforcement device may be a Policy and Charging Rules Function of a 3GPP network. Alternatively, the policy enforcement device may be associated with a network selected from a group of networks, the group comprising a non-3GPP communication network, a fixed broadband network and a DSL network.

According to an exemplary embodiment of the present invention, a policy management apparatus is provided, the policy management apparatus further comprising: a network change detector, wherein the network detector is adapted for detecting that the subscriber having a first service connection over a first network wants to establish a second service connection over a second network, wherein the network detector is adapted for informing the policy decision device that the subscriber wants to establish a second service connection, wherein the policy decision device is adapted for sending the policy control context information to the subscriber information device after the network change detector has informed the policy decision device that the subscriber wants to establish the second service connection.

Another possible way to trigger the policy decision device to send the policy control context information to the subscriber information device may be the detection that the subscriber wants to change the access network. In this case, the policy control context information is only sent to the subscriber information device, when the situation arises that another component or device, like a policy decision device of the same or a different network, wants to request the policy control context information from the subscriber information device.

The policy control context information may only be stored in the subscriber information device if required, for example, when an inter-system change that comprises a change of policy decision devices or points is imminent. This may have the advantage that the signalling load between the policy decision device and the subscriber information device is minimized. The policy decision device associated with the first network may be informed about the ongoing inter-system change and may store the current policy control context information in the subscriber information device.

According to an exemplary embodiment of the present invention, the network change detector may be a device selected from the group of devices comprising a routing agent, a Diameter Routing Agent (as described in 3GPP TS 23.203), and an Application Function (AF) of a 3GPP network.

The policy decision device associated with the first network may be informed about an inter-system change by a routing agent. The routing agent may be a device that receives data from a first component of the communication network, wherein the data has been dedicated to a second component of the communication network by the first component. The routing agent may determine the position of the second component in the communication network and may forward the data to the second component. In particular, the routing agent may receive a request for policy rules from a policy enforcement device or PEP, wherein the request has to be forwarded to a policy decision device or PDP. The request for policy rules may be associated with a service and a subscriber. The routing agent may determine, if an other policy decision device or PDP associated with the subscriber and the service may exist. If the other policy decision device or PDP exists, the routing agent may inform the other policy decision device or PEP over the inter-system change and the other policy decision device or PDP may store the policy control context information.

In particular, a PCRF associated to the first 3GPP network may be informed about an inter-system change through a Diameter Routing Agent (DRA) .

If an Application Function (AF) of a 3GPP network is available and connected to a first PCRF associated to the first network and to a second PCRF of a second network, the first PCRF may be informed through the Application Function (AF) .

According to an exemplary embodiment of the present invention, the policy control context information may comprise at least one information selected from the group of information comprising: information sent to the policy decision device for creating the policy rules, information sent to the policy decision device by an Application Function, information sent to the policy decision device by an policy enforcement device, information concerning active services of the subscriber, and the policy control rules.

According to an exemplary embodiment of the present invention, the policy decision device is adapted for requesting policy control context information from the subscriber information device.

According to an exemplary embodiment of the present invention a policy management apparatus of a communication network is provided, the policy management apparatus comprising: a policy decision device for requesting policy control context information from a subscriber information device, wherein the subscriber information device is adapted for storing information of a subscriber of the communication network, and wherein the subscriber information device is adapted for storing the policy control context information, wherein the policy decision device is adapted for generating policy control rules based on the policy control context information.

The policy decision device or PDP can query the policy control context information stored to the subscriber information device by another policy decision device or PDP. The policy decision device or PDP may not have to gather the policy control context information. The policy decision device may generate the policy rules based on the policy control context information already gathered by the other policy decision device. The policy decision device requests the policy control context information without directly contacting the other policy decision device.

According to an exemplary embodiment of the invention, a network system is provided, the network system comprising: a first policy management apparatus and a second policy management apparatus, wherein one of the first policy management apparatus and the second policy management apparatus is associated with a 3GPP network and the other one of the first policy management apparatus and the second policy management apparatus is associated with a network selected from a group of networks, the group comprising a non-3GPP communication network, a fixed broadband network and a DSL network.

The network system may provide anchor change support capabilities .

In a design of a 3GPP SAE/LTE architecture an anchor can be established in order to support mobility management, quality of service (QoS) and accounting control. This concept may comprise that an anchor has exclusive control over a bearer and remains in place during the whole lifecycle of the bearer, i.e. in particular that the anchor does not change during inter-system change or handover. However, this may be only applicable, if a inter-system change between a first access network and a second access network of differing technology is supported, e.g. based on network-layer mechanisms, such as Proxy Mobile IP (PMIP) . Alternatively, higher-layer mechanisms like SIP-based mobility may be employed to enable a inter-system change or handover between access technologies. One example of a network technology are broadband access networks based on DSL (Digital Subscriber Line) technology, where network-layer mobility mechanisms do not exist and future extensions are not likely. DSL may be an example of a non-3GPP network. With DSL as the second access network it may be possible, that two different policy decision points are used. The two access networks may be deployed in a completely independent manner and even belong to different access network operators.

For a inter-system change of a non-3GPP access network to a 3GPP network and vice versa, the mobility anchor including the accompanying Policy and Charging Enforcement Function

(PCEF) in the 3GPP network may change and a new anchor in the non-3GPP network (for example the Broadband Remote Access Server (BRAS) in DSL) may be used after the inter-system change has been completed.

As a change of an anchor may result in a change of the PCEF, the change of the anchor may also comprise the involvement of a second PCRF. With the policy management system a maintaining and exchanging of policy and charging context information between the two involved PCRFs may be possible. A seamless service usage and seamless charging may be allowed, even if the PCRF changes.

The policy management system may enhance the 3GPP architecture with the capability for an inter-system change from and to DSL networks in a seamless manner while keeping the required changes at a minimum by using existing interfaces. Since no further interfaces are introduced, the inter-system change is aligned with the general handover concept in 3GPP TS 23.402. Furthermore, having the context information of the first PCRF available at the second PCRF is typically much faster, more efficient and bears less risk of failure than relying on getting the policy control context information for each of the sessions individually. Further, services that don't use an Rx interface can be supported as well .

In a 3GPP network, it may also be possible, that the PCRF concludes a change in anchor points. The PCEF requesting policy rules from the PCRF may be provided with information to allocate the resources and to setup the packet switched charging for all ongoing services regarding policy and charging control context information.

A 3GPP communication network may comprise more than one gateway and therefore more than one anchor. One possibility of operation the communication network is, that a subscriber is assigned to a nearest gateway. A nearest gateway may be a gateway that is spatial near to the user equipment of the subscriber or a gateway to which the travel time of data from the user equipment to the gateway is short. If the subscriber has established a service connection for a long time or the subscriber is moving, it may be possible that an other gateway becomes the nearest gateway. In this case, an anchor change which can be performed as a inter-system change may be beneficial since it would not require that the user equipment disconnects from the access network.

According to an exemplary embodiment of the invention a method for operating a communication network may be provided, the method comprising the steps of: storing information of a subscriber of the communication network in a subscriber information device, generating policy control context information of the subscriber by a policy decision device, generating policy control rules based on the policy control context information by the policy decision device, sending the policy control context information to the subscriber information device, and storing the policy control context information in the subscriber information device.

According to an exemplary embodiment of the invention a method for operating a communication network is provided, the method comprising the steps of: requesting policy control context information from a subscriber information device by a policy decision device, wherein the subscriber information device is adapted for storing information of a subscriber of the communication network, and generating policy control rules based on the policy control context information by the policy decision device.

According to an exemplary embodiment of the invention a computer readable medium is provided, comprising program code, which program code is adapted, when being executed on a processor, to carry out at least one of the methods for operating a communication network.

Computer-readable medium may be a floppy disk, a harddisk, an USB (Universal Serial Bus) storage device, a RAM (Random Access Memory) , a ROM (Read Only Memory) and an EPROM (Erasable Programmable Read Only Memory) . A computer-readable medium may also be a data communication network, e.g. the internet, which may allow downloading a program code.

According to an exemplary embodiment of the invention, a use of a Subscription Profile Repository of a 3GPP communication network for storing policy control context information may be provided.

According to an exemplary embodiment of the present invention a Policy Control Apparatus, which may be part of the policy management system, a method for handing over Policy Control information of a second Anchor Device to a first Anchor Device, a further computer-readable medium, a further Broadband Remote Access Server and a further use of a Subscription Profile Repository may be provided.

According to an exemplary embodiment of the present invention a Policy Control Apparatus may comprise an Anchor Change Detecting Device, a Handover Device and a first Anchor Device. In an example the Anchor Change Detecting Device may be adapted for detecting that a subscriber and/or a terminal may be changing from a second Anchor Device to a first Anchor Device.

In a further example the Handover Device may be adapted for handing over policy and charging control information of the subscriber from the second Anchor Device to the first Anchor Device upon detecting the subscriber may be changing from the second Anchor Device to the first Anchor Device.

According to another exemplary embodiment of the present invention, a method for handing over Policy Control information of a second Anchor Device to a first Anchor

Device may be provided. The method may comprise detecting that a subscriber is changing from the second Anchor Device to the first Anchor Device. The method, for example, may further comprise, upon detecting the subscriber may be changing from the second Anchor Device to the first Anchor Device handing over policy and charging control information of the subscriber from the second Anchor Device to the first Anchor Device.

According to yet another exemplary embodiment of the present invention, a computer-readable medium may be provided, wherein the computer-readable medium may comprise a program code, which program code may be adapted, when being executed on a processor, to carry out the method for handing over Policy Control information of a second Anchor Device to a first Anchor Device. The method may comprise detecting that a subscriber may be changing from the second Anchor Device to the first Anchor Device and upon detecting the subscriber may be changing from the second Anchor Device to the first Anchor Device, handing over policy and charging control information of the subscriber from the second Anchor Device to the first Anchor Device.

According to another exemplary embodiment of the present invention, a program element may be provided, wherein the program element may be adapted, when being executed on a processor, to carry out the method for handing over Policy Control information of a second Anchor Device to a first Anchor Device. The method may comprise detecting that a subscriber may be changing from the second Anchor Device to the first Anchor Device and upon detecting the subscriber may be changing from the second Anchor Device to the first Anchor Device, handing over policy and charging control information of the subscriber from the second Anchor Device to the first Anchor Device.

According to another exemplary embodiment of the present invention, a Broadband Remote Access Server (BRAS) may be provided, wherein the BRAS may comprise an inventive Policy Control Apparatus.

According to another exemplary embodiment of the present invention, a use of a Subscription Profile Repository function for handing over policy and charging control information of a subscriber from a second Anchor Device to a first Anchor Device may be provided. The policy and charging control information may be handed over from the second Anchor Device to the first Anchor Device upon detecting that the subscriber may be changing from the second Anchor Device to the first Anchor Device.

In other words, a Handover Device which may be adapted for handing over Policy and Charging Control Information of the subscriber from the second Anchor Device to the first Anchor Device may describe the principle that PCRF may retrieve the identifiers and charging-related context information from an extended Subscription Profile Repository SPR* and that PCRF may send the charging identifiers and charging-related context information to a new PCEF. This new PCEF may be provided, in order to differentiate between PCEF in a 3GPP network and a PCEF in a non-3GPP network.

The term ^λnew' and ^λold' may relate to a direction of handing over a UE, a terminal or a service. Thus, the receiving PCEF may be the 'new' PCEF.

The information may be initially from the second Anchor device, and at the moment of handover, a Handover device may provide the identifiers and charging-related context information that may have been stored earlier and that may be present in SPR*.

This may not mean that information may be transferred directly from the second Anchor Device to the first Anchor Device. Thus, another aspect of the invention may be buffering identifiers and charging-related context information in an extended SPR during a handover.

Generally, even if only described in one direction, a handover may be conducted in either direction, i.e. a handover may be conducted from the 3GPP network to the non- 3GPP network and/or from the non-3GPP network to the 3GPP network.

It may be one design principle of a 3GPP SAE (System Architecture Evolution) architecture to establish an anchor to support mobility management, Quality of Service (QoS) and Accounting Control Policy Enforcement Point (PEF) .

According to another exemplary embodiment of the present invention, a program element may be provided which may be adapted, when being executed on a processor, to carry out a method comprising detecting that a subscriber may be changing from the second Anchor Device to the first Anchor Device and handing over policy and charging control information of the subscriber from the second Anchor Device to the first Anchor Device upon detecting that the subscriber is changing from the second Anchor Device to the first Anchor Device.

The concept provided in SAE may specify that an anchor may have exclusive control over a bearer. In other words, a subscriber who may initiate a service within the 3GPP network may establish a 3GPP bearer which may be associated with a corresponding service. Therefore, in a 3GPP network, when a subscriber may have established a 3GPP bearer this bearer may be associated with an anchor or with an Anchor Device, specific for the subscriber. In an example, the Anchor Device may be associated with an anchor in a network, e.g. a network gateway. Therefore, when the subscriber may change the access technology within a 3GPP environment, still the same anchor or 3GPP bearer may be active.

A bearer may be defined as a context specific for a subscriber and/or service which may be stored in a network in order to identify a user connection. Thus, a Bearer may be an information transmission path of defined capacity, delay and bit error rate, etc. In an example, if a 3GPP user or 3GPP subscriber may access a 3GPP network via WiMAX™ a WiMAX™ bearer may be created, and if the subscriber may access the 3GPP network via GSM a GSM bearer may be created. The bearer may be the unique identification of a service and/or user in a network.

An anchor may have an exclusive control over the established bearer. Therefore, an Anchor Device may also have an exclusive control over an established bearer, i.e. the Anchor Device or a PCEF may see the identification of the service and/or of the user. The anchor point, in particular the PCEF, executes the PCRF' s decisions regarding the corresponding bearer . However, in a mobile access scenario it may happen that a subscriber may establish a 3GPP bearer, e.g. for a UMTS/3G (Universal Mobile Telecommunication System/3^rd Generation) , for a WiMAX™ (Worldwide Interoperability for Microwave Access) or for a GPRS (General Packet Radio Service) access. Via the corresponding access technology different services may be used. For example, an IP access service, web browsing, a voice over IP (VoIP) service, IPTV and/or a VPN (Virtual Private Network) service may be utilized.

A subscriber may expect that if a service on a 3GPP bearer may have been established, the subscriber may continuously use the service even if the subscriber may have changed to a non-3GPP bearer. A non-3GPP bearer for example may be established in a Digital Subscriber Line (DSL) network.

3GPP may define several parameters or functions for a bearer. A non-3GPP bearer, e.g. a DSL bearer, may not support these functions. Thus, it may be an aspect of the invention to introduce such parameters, as for example QoS parameter, accounting quota, in a non-3GPP network in order to increase the granularity for a connection in a 3GPP network.

The bearer of a 3GPP network may differ from the bearer of a non-3GPP network in that the granularity of a 3GPP network may be finer than the granularity of a non 3GPP network. In other words, for accounting on a BRAS a AAA architecture may be used. AAA may not allow for service flow differentiation such as service flow differentiation may be possible with PCC. This means, the granularity of PCC may be finer, e.g. identify a service data flow by means of a IP 5-tuple or other filter criteria (c.f. deep packet inspection) may be possible. The IP 5 tuple may be a filter.

Thus, when a 3GPP bearer may be established, access to an IP 5-tuple may be provided. An IP 5-tuple may comprise a source IP address, a destination IP address, a source port number, a destination port number and a protocol ID (identifier) of the protocol above IP. A non-3GPP e.g. DSL bearer may substantially only allow to provide a single monolith data flow, which may not allow to differentiate the IP 5 tuple. In other words, if a DSL connection may be established, a single data flow may be provided. The services transported via the data flow may not be differentiated. Thus, charging of individual flows, services, ports or protocols within the data flow may not be possible.

A non-3GPP network may use a non-3GPP bearer, wherein a non- 3GPP network may be a broadband access network without dedicated user and service identification e.g. DSL or WIMAX.

Therefore, different anchor points may exist for the same service in a 3GPP network and/or in a non 3GPP network. A handover of a service between a 3GPP network and a non-3GPP network may be characterized by a change of an anchor point. In other words, a service handover between different 3GPP access networks, e.g. between UMTS and LTE may not require an anchor point change since the service in both networks may use the same anchor point. A service handover between a 3GPP network and a non 3GPP network, e.g. between UMTS and DSL, may require an anchor change.

In other words, services may be exchanged between a 3GPP network and a non-3GPP network and vice versa. Since the granularity in both types of networks may be different, in an example, a service, e.g. an IPTV service of a defined user, which service may have been started in the 3GPP network, may not be handed over to a non-3GPP network. In the non-3GPP network, e.g. a DSL network, only a single connection may exist. In other words, a service started in the 3GPP network may not ^λfind' a corresponding service in the non-3GPP network .

Thus, it may also be an aspect of the present invention to break down a connection or a single bearer in a plurality of services and handle a charging and policy exchange between the services. If the service granularity of a non-3GPP network may be increased, it may be possible to hand over an IPTV service of a defined user of a 3GPP network to an IPTV service of the same user in the non-3GPP network.

In a 3GPP network a PDP context may be generated for a 3GPP bearer, for a packet-switched bearer. This may be a tunnel, e.g. GTP or PMIP (proxy mobile IP) . Traffic received in a PDN GW (Packet Data Network Gate Way) may be forwarded to an application server.

In the PDN only a single anchor point may exist for managing different access technologies and for managing a handover of services between different anchor points.

A DSL connection may not be known in a PDN GW.

During authorization of a bearer and/or of a service for a subscriber, a subscriber ID (Identifier), a service ID and a flow ID may be generated. This may be seen as a service key, a service triple, service 3 tuple, or service tuple or a subscriber description /service description /flow description combination. The service key may allow identifying uniquely a service in different networks. This identifier or key may not be limited to 3 entries as in a triple. The identifier may be a single value if an identifier for a service may be generated or be any n tuple, wherein n may be any integer value .

According to an exemplary embodiment of the present invention the service triple may be reported to the SPR* and may be stored in the SPR*. This may allow a service handover and a continuous charging/policy between a 3GPP network and a non 3GPP network. For detecting that a service may continuously be used, the service triple may be matched with an already generated service triple. The service triple may also be reported to the SPR* in a 3GPP environment. The service triple may be reported to the SPR* on service initiation or when a service handover between a 3GPP network and a non-3GPP network may be prepared.

It may also be possible to report the service triple if predefined conditions may be met. For example, the service triple may only have to be reported to the SPR* if the corresponding subscriber may be permitted to or capable of changing an anchor. Thus, the reporting may be dependent on a subscriber ID, subscriber group ID, UE device type, etc. A subscriber only having a UMTS subscription may not need to report a service triple to the SPR*.

An anchor or anchor point may be any endpoint of a connection or of a tunnel and may not be limited to a mobility anchor.

The concept of providing an anchor may comprise exclusive control over a bearer. In other words, the anchor may be a location in a network, where services can be handled on a service level. Substantially all 3GPP access networks may generate the same anchor for a service.

An example for a non-3GPP network may be a broadband access network such as a DSL network. Another example for a non-3GPP network may be a power-line network. Thus, handing over a service from a mobile network to a fixed power-line connection may be possible while continuously charging the corresponding subscriber.

The concept of an anchor having exclusive control over bearer may not be applicable if a handover between a 3GPP network (e.g. UMTS, LTE/EPC (Evolved Packet Core)) and a non 3GPP network, e.g. a broadband access network such as DSL may be conducted.

In order to enable a continuous accounting between a fixed access network (e.g., a non-3GPP network) and a mobile access network (e.g. a 3GPP network), more than one PEF (Policy Enforcement Function) may need to be controlled. PCC (Policy and Charging Control) may be an overall concept and

PEF (Policy Enforcement Function) may be a part of the PCC.

Applying a handover scenario for e.g. DSL access a situation may occur, where a subscriber and/or a terminal may have established a DSL bearer which may be under control of a first PEF, e.g. PEFl, and for another subscriber and/or terminal, which may have established a 3GPP bearer, e.g. 3G, LTE/EPC which may under control of a second PEF, for example PEF2. In an example, a terminal may have established a video call or a video connection to a second terminal via 3G network and another subscriber and/or another terminal may be running an IP TV (IP Television) connection to a IP TV server, for example via a DSL network.

In other words, for the two connections, two independent PEFs may exist.

Consequently, the Policy Enforcement Function (PEF) may change in some situations or the control of more than one PEF by one Policy Control function may be needed.

Therefore, according to an exemplary embodiment of the present invention, a concept for changing a Policy

Enforcement point or of changing Policy Enforcement points during mobility may be provided, which concept may include a solution for continuous charging across different access systems, in particular charging across a 3GPP access network and a broadband access network without dedicated subscriber service identification or charging across different PEFs.

SIP (Session Initiated Protocol) may be used for higher layer mobility. SIP may allow mobility management of services in a non-3GPP network, such as DSL. For mobility management mechanisms SIP may be enhanced with features which may be required in mobility environments. In other words, by providing different anchor points for different communication network access types, may allow handling connections belonging to different communication networks differently. Thus, for example accounting for 3GPP bearer may be conducted in a 3GPP network and accounting for non-3GPP bearer may be conducted in the non-3GPP network.

However, when a service may have to be handed over from one access technology to another access technology, an exchange of policy information and/or charging information between the different networks may be required. Therefore, a Handover Device, which may be adapted for handing over policy and charging control information of a subscriber from a second Anchor Device to a first Anchor Device upon detecting the change from the subscriber from the second access network to the first access network may allow to continue a charging for a service. In particular, a service, such as a video call which may have been started in a 3GPP network may continue when the user of the video call changes into a broadband access network, which may not be able to use a 3GPP bearer.

According to another exemplary embodiment of the present invention, the first Anchor Device may be associated with a first anchor in the first network. In an example, the first Anchor Device may be the first anchor in the first network.

The first Anchor Device may establish a bearer in the first network and thus, the first Anchor Device may exclusively control the bearer. In other words, the second anchor, the second anchor point, the second PEF or the second PCEF may not have control over the first bearer.

According to another exemplary embodiment of the present invention, the first Anchor Device may be a first Policy and Charging Enforcement Function (PCEF) and/or a Policy and

Charging Enforcement Device. The PCEF may control the bearer of an associated anchor and/or of an associated network. Allowing a change of an anchor within a network by an anchor change detecting device may allow detecting that a subscriber may intend to change the access network. Policy and Charging Enforcement Function (PCEF) may encompass service data flow detection, policy enforcement and flow-based charging functionalities. The PCEF may be located at a gateway, e.g., a GGSN (Gateway GPRS Support Node) in the GPRS case, P-GW (PDN Gateway) in EPS case and a PDG (Packet Data Gateway) in a WLAN (Wireless Local Area Network) case.

A PCEF may provide service data flow detection, user plane traffic handling, triggering control plane session management, QoS handling and service data flow measurement as well as online charging interactions and offline charging interactions .

The possibility to detect a change between a second Anchor Device and a first Anchor Device may allow maintaining the same service in different networks, wherein a first Policy and Charging Enforcement Function and a second Policy and Charging Enforcement Function may be employed for controlling corresponding bearers.

The first Anchor Device may comprise a first Policy and

Charging Enforcement Function. If a change to the first PCEF may be detected 3GPP bearer and non-3GPP bearer may be differentiated. The PCEF may be adapted to communicate with the Anchor Change Detecting Device via the Gx interface. Via the Gx interface the PCEF may request a PCC decision for the requested bearer from the PCRF. Already existing bearers may be transparent for the newly involved PCEF. The PCRF may provide the PCEF with already existing identifiers obtained via the extended SPR (=SPR*) . Via the Gx interface the PCEF may request which may already exist for the service in the second Anchor Device for a service established in the second network. The second Anchor Device may also comprise a Policy and Charging Enforcement Function, wherein the second Policy and Charging Enforcement Function may be separate from the first PCEF.

According to another exemplary embodiment of the present invention, the first Anchor Device may be associated with a bearer selected from the group of bearers consisting of a 3GPP bearer, a bearer on layer 3 and below, a network layer bearer, a fixed broadband bearer and a DSL bearer.

If the first Anchor Device may be associated with a non-3GPP bearer the first Anchor Device may differentiate an access service of a second Anchor Device, wherein the second Anchor Device may be associated with a 3GPP bearer. Therefore, a change between a second anchor and a first anchor or a second anchor point and a first anchor point may be detected by the Policy Control Apparatus and policy and/or charging control information of a subscriber may be provided from the second Anchor Device to the first Anchor Device.

The policy and/or charging control information of a subscriber may be generated when the subscriber establishes a service and upon changing the access network the policy and/or charging control information may be distributed to the new Anchor Device or to the first Anchor Device. This may allow a continuous charging operation since the actual policy and charging control information may be exchanged in parallel with an exchange of the access network.

In other words, the policy and/or charging control information may travel in parallel to a subscriber and/or a terminal. Thus, when the subscriber and/or the terminal may travel from one network to another network a control of a bearer may be handed over from one Anchor Device to another Anchor Device.

According to another exemplary embodiment of the present invention, the first Anchor Device may be associated with a 3GPP bearer. According to another exemplary embodiment of the present invention, handing over policy and/or charging control information of the subscriber from the second anchor to the first anchor, i.e. from the second Anchor Device to the first Anchor Device, may comprise providing from the second Anchor Device to the first Anchor Device at least one anchor change support capability selected from the group of anchor change support capabilities consisting of a charging related information, a charging rule, offline charging identifiers and online charging identifiers. Furthermore, handing over policy and/or charging control information may comprise information about a current anchor and/or a current PCEF or of the involved, i.e. old and/or new, anchor points.

In another example, the service key or the service tuple, e.g. the service 3 tuple, may be stored in combination with the old anchor and the new anchor or with the old PCEF and the new PCEF. Thus, it may be possible to identify a service which may have been handed over between networks. The combination of the key and/or tuple and the old PCEF and the new PCEF may be stored in the SPR*. Therefore, if only a key in combination with a single PCEF may be stored and the PCEF entry may disappear, the SPR* may conclude that the service may have been cancelled. If the combination of the key, an old PCEF and a new PCEF may exist and one PCEF may disappear, the SPR* may conclude, that a handover may have been conducted. Thus, also the direction of the handover may be detected.

A 3GPP network may have a second anchor which may be associated with a second Anchor Device. A first network, such as a non-3GPP network may comprise a first anchor which may be associated with a first Anchor Device.

An anchor change support capability may be stored in a

Subscription Profile Repository (SPR) . A SPR which may be adapted to store change support capabilities or which may be adapted to store a service 3-tuple, may be an extended SPR or a SPR*. The anchor change support capabilities may comprise charging related information which may allow for a smooth change of anchor points. In other words, an anchor change support capability may be information which may allow an Online and/or an Offline Charging System or an Online

Charging Device and/or an Offline Charging Device to continue charging, while a subscriber, the services of which subscriber may have to be charged, changes between networks, having different anchor points. Identifier for example, may allow correlating charging information of one subscriber who may travel between different type of access networks.

According to another exemplary embodiment of the present invention the Handover Device may be a Subscription Repository Device (SPR) , wherein the SPR may be adapted for storing the anchor change support capability.

If the anchor change support capability may be stored in the SPR, different Anchor Devices may access the same information even if the Anchor Devices may be associated with anchor points belonging to different access networks.

According to a further exemplary embodiment of the present invention, the Anchor Change Detecting Device may be a Policy and/or Charging Rule Function Device (PCRF) . In an example the PCRF device may be adapted for saving and/or retrieving charging context information to and/or from the Handover Device and/or the SPR.

Saving and retrieving charging context information may allow to exchange policy and/or charging information between networks which may have different charging concepts or which may employ different charging concepts. In other words, charging rules belonging to a service may be adapted such, that the same charging rules can be applied in different access networks, i.e. in access networks, which base on different access technologies. For example, a 3GPP network and a non-3GPP network may be networks which may not be related to one and another. In other words, a 3GPP network and a non-3GPP network may be disjunct networks.

Therefore, substantially no charging information may be exchanged between a 3GPP network and a non-3GPP network. Due to different service flow structures, the Policy and Charging concepts may also be different.

However, since an access network may only be a physical network which may be used for accessing to the same services, policy and charging, which relate to the same predefined service may be required.

An SPR, e.g. an SPR* or an extended SPR, may allow to exchange subscription profiles on a subscriber basis, independently on the underlying network access technology. The subscription profiles may be translated into policies and into charging rules which may depend on the specific access network. By providing such a translation it may be possible to provide the same or a similar policy and/or charging rule for a service within different access networks. Thus, for example an IP TV service may continuously be charged even if a subscriber, while using the service, may change the access network .

In other words, an SPR* may be used to translate Policy and/or Charging rules between different access networks.

According to another exemplary embodiment of the present invention, the Anchor Change Detecting Device may be adapted for detecting that a combination of a subscriber description, a service description and a flow description, associated with the second Anchor Device may exist and that the same combination may also be associated with the first Anchor Device.

The combination of a subscriber description, a service description and a flow description may be a pattern which substantially may allow uniquely and substantially unambiguously to identify a service across different access networks. Therefore, the combination of a subscriber description, a service description and a flow description may be a footprint which may allow identifying a service which a certain subscriber may use in different access networks.

If the Anchor Change Detecting Device may realize or detect that in a second network, a second Anchor Device may exist which may be associated with such a combination of a subscriber description, a service description and a flow description and the Anchor Change Detecting Device may also realize that the same combination continues in a second network and may now be associated with the first network or may be associated with the first Anchor Device, the Policy Control Apparatus may realize that a change of the same service between different access networks may have been conducted.

Thus, a service established in the second network may still be used from the same subscriber in the first network. If such a continuous service can be detected by the Policy Control Apparatus, the inventive Policy Control Apparatus may be able to continuously charge the service independently from the type of the access network. For example, the Policy

Control Apparatus may translate Policy and/or Charging rules from one network to the other.

According to another exemplary embodiment of the present invention, the Policy Control Apparatus further may comprise an Offline Charging Device. In an example the Offline Charging Device or System may be adapted for correlating charging data records generated by the first Anchor Device and the Charging Data Records (CDR) generated by the second Anchor Device.

In a case when a subscriber uses the same service in different access networks, charging data records for the service may be generated in different Policy Control Apparatuses or PCEFs or PEFs. An Offline Charging Device or System, which may be adapted for correlating the charging data records may allow to continue the charging of a predefined service which may continuously used in two different networks. Offline charging may mean that for example a bill or a ticket may be generated after the generated charging data records may have been collected, e.g. after a service may have been used.

According to another exemplary embodiment of the present invention, the Policy Control Apparatus may comprise an Online Charging Device or System, wherein the Online Charging Device or System may be adapted for correlating quota consumed by a first Anchor Device and quota consumed by a second Anchor Device. Correlating quota from a first Anchor Device and a second Anchor Device may allow providing online charging for continuously used services. Online charging may mean that charging may be based on credits.

According to yet another exemplary embodiment of the present invention, at least one device selected from the group of devices consisting of an Anchor Change Detecting Device, a Handover Device and a first Anchor Device may be implemented as a device and/or as a function located on separate apparatuses .

A device may be hardware or a processor executing a certain function loaded on the processor and distributing such devices or functions over different apparatuses may allow implementing a distributed architecture for a Policy Control Apparatus. Thus, at least one device or at least one function from the group of an Anchor Change Detecting Device, a Handover Device and a first Anchor Device may be additionally implemented with another functionality such as a gateway functionality. Distributing functions or devices or spreading functions or devices over a plurality of separate devices may allow increasing the performance of a Policy Control Apparatus.

According to yet another exemplary embodiment of the present invention service, handed over from the second Anchor Device to the first Anchor Device may be identified by a key, a service 3 tuple, the service triple or service tuple.

Identifying a service by a service 3 tuple or by another identifier, which may substantially unambiguously identify the service, may allow to continuously charging the service, even if a anchor change may be conducted.

It has also to be noted that exemplary embodiments of the present invention and aspects of the invention have been described with reference to different subject-matters. In particular, some embodiments have been described with reference to apparatus type claims whereas other embodiments have been described with reference to method type claims. However, a person skilled in the art will gather from the above and the following description that unless other notified in addition to any combination between features belonging to one type of subject-matter also any combination between features relating to different subject-matters in particular between features of the apparatus claims and the features of the method claims may be considered to be disclosed with this application.

These and other aspects of the present invention will become apparent from and elucidated with reference to the embodiments described hereinafter.

Exemplary embodiments of the present invention will be described in the following with reference to the following drawings . Brief description of the drawings

Fig. 1 shows a policy management apparatus according to an exemplary embodiment of the invention.

Fig. 2 shows a inter-system change Scenario Comprising two PDPs.

Fig. 3 shows message flows for the inter-system change scenario of Fig. 2.

Fig. 4A shows a inter-system change from a 3GPP network to a DSL network before a inter-system change has been conducted.

Fig. 4B shows a network scenario comprising a video call and an IP TV session after a inter-system change.

Fig. 5 shows a flow diagram for a method for handing over policy control information of a second Anchor Device to a first Anchor Device.

Detailed description

The illustration in the drawings is schematic. In different drawings, similar or identical elements are provided with the same reference numerals.

Fig. 1 shows a policy management apparatus 100 according to an exemplary embodiment of the invention. The policy management apparatus comprises a policy enforcement device or PEP 101, a policy decision device or PDP 102 and a subscriber information device 107. The subscriber information device may be a database.

If a subscriber wants to establish a service connection over the gateway 99, the policy enforcement point 101 requests policy rules form the policy decision point 102 over the connection 103. The policy decision point 102 generates policy rules, for example by requesting subscriber information over the connection 108 from the subscriber information device 107. After that, the policy decision point 102 sends the generated policy rules over the connection 103 to the policy enforcement point 101. Then, the policy enforcement point 101 enforces the policy rules. For example, the policy enforcement point 101 may authorize the subscriber to use the service or the policy enforcement point 101 installs and starts the subscriber related charging for using the service.

For example, the policy decision point 102 may generate the policy rule that a certain service has to be charged with respect to the numbers of the sent or received data packages. Alternatively, a service may be charged with respect to the time the subscriber has used the service or may be charged with respect to the bytes which have been sent or received over the communication network for the use of the service.

The policy decision point 102 is further adapted to generate or gather policy control context information that has been used to generate the policy rules. The policy decision point 102 is further adapted to send the policy control context information to the subscriber information device 107 over the connection 108.

In the case of a 3GPP network, the policy enforcement point 101 is a Policy and Charging Enforcement Function (PCEF) 101, the policy decision point 102 is a Policy an Charging Rules

Function (PCRF) 102 and the subscriber information device 107 is an extended Subscription Profile Repository (SPR*) 107. The PCEF 101 may communicate with the PCRF 102 via the Gx interface 103, the PCRF 102 may communicate with the SPR* 107 via the extended SP* interface 108.

The PCRF may also communicate with an Application Function (AF) 106 via the Rx interface 105. A Subscription Profile Repository (SPR) 107 according to 3GPP may contain as logical entity subscriber-related information and/or subscription-related information that the PCRF 102 requires for the generation of subscription-based policy rules as well as IP-CAN bearer level policy rules (PCC rules according to 3GPP) . For example, the SPR 107 may comprise all subscriber related information, i.e. the SPR 107 may comprise all available subscriber related information which may, for example, be stored in a database. The SPR 107 may provide the subscription profile information on a per IP-CAN session basis, i.e. identified by a User Equipment and the PDN identifier. A subscription profile information may comprise the subscriber's allowed services, for each allowed service, a pre-emption priority, information on the subscriber's allowed QoS, including the Subscribed Guaranteed Bandwidth, the subscriber's charging-related information (e.g. location information relevant for charging) , and the subscriber category.

The policy management apparatus 100 comprises further a routing agent (RA) 114, that may be a Diameter Routing agent (DRA) 114, for example in the case of a 3GPP network.

Whereas in Fig. 1 a distributed architecture for a policy management apparatus 100 is shown, the components or devices of the policy management apparatus 100 may be included in a single housing or in a single apparatus.

Fig. 2 shows a inter-system change scenario comprising two PDPs 102a and 102b.

A communication network 119 comprises a first access network 120 that is a 3GPP network and a second access network 122 that is a non-3GPP network. For example, the second access network may be a network without network layer mobility support like a DSL network. It is also possible that the second access network 122 is also a 3GPP network. The communication network 199 comprises further a core network 124, which in the present case is a 3GPP core network.

The user equipment (UE) 126 of a subscriber of the communication network 119 has established a first service connection 130a with the aid of a first PCEF 101a associated to the first access network 120 and a first PCRF 102a associated with the core network 124. Alternatively, the first PCRF 102a may be associated to the first access network 120.

In the shown inter-system change scenario, the user equipment (UE) 126 wants to establish a second service connection 130b. An inter-system mobility procedure or inter-system change 128 between the first access network 120 and the second access network 122 has to be made.

A second PCEF 101b is associated with the second access network 122. Further, a second PCRF 102b exists in the core network 124. Alternatively, the second PCRF 102b may be associated to the second access network 122. In case of an inter-system mobility procedure, it cannot be assumed that the first PCRF 102a of the first active PCEF 101a will always be the same as for the second new PCEF 101b. In this case, policy control context information may be provided via the SPR* 107 to the second new PCRF 102b. The first PCRF 102a is adapted to store policy control context information over a first Sp* interface connection 108a. The second PCRF 102b is adapted to request the policy control context information over a second Sp* interface connection 108b. This may ensure a seamless inter-system change regarding charging and policy control of the currently running application sessions of the subscriber .

A policy management system 118 of the communication network 119 may comprise the first PCEF 101a, the second PCEF 101b, the first PCRF 102a, the second PCRF 102b and the SPR* 107. Fig. 3 shows message flows for the inter-system change scenario of Fig. 2.

The subscriber of the communication network 119 wants to use a service with his user equipment (UE) 126. In step 150 the user equipment 126 requests the establishment of an IP-CAN bearer for the first service connection 130a. In step 152 the first PCEF 101a sends a indication of the IP-CAN bearer request over the Gx interface connection 103a to the first PCRF 102a. In step 154 the first PCRF 102a sends a subscriber profile request over the Sp interface connection 108a to the extended SPR* 107. In step 156 the SPR* 107 sends a subscriber profile response over the Sp interface connection 108a back to the first PCRF 102a. In step 158 the first PCRF 102a generates policy rules based on the subscriber profile and the service the subscriber wants to use.

The policy rules may be generated based on subscriber profile information, allowed services from the SPR* 107, and bearer information from the first PCEF 101a as well as potential information from the Application Function (AF) 106.

Further, in step 158 policy control context information is generated by the first PCRF 102a. In step 160 the first PCRF 102a sends a Profile update together with the policy control context information over the extended Sp* interface connection 108a to the SPR* 107. In step 162 the SPR* acknowledges the profile update over the Sp* interface connection 108a. In step 164 the first PCRF 102a acknowledges the IP-CAN bearer establishment over the Gx interface connection 103a to the first PCEF 101a.

In step 165 the first PCEF 101a acknowledges the establishment of the IP-CAN bearer for the first service connection 130a towards the user equipment 126.

In step 166 the subscriber uses the service over the first service connection 130a via the first, now active access network 120. Later, a inter-system mobility decision to the second access network 122 is made. For example, the second access network 122 may be a local hotspot network operated by an operator different from the operator of the first access network 120 and the core network 124. Alternatively, the second access network 122 may be a DSL network.

In step 168 the user equipment requests the establishment of an IP-CAN bearer for the second service connection 130b from the second new PCEF 101b. In step 170 the second PCEF 101b sends an indication of the IP-CAN bearer request over the Gx interface connection 103b to the second new PCRF 102b. In step 172 the second PCRF 102 sends a profile request with a query for policy context information over the Sp* interface connection 108a to the SPR* 107. In step 174 the SPR* 107 sends a profile response with the policy context information that has been stored by the first PCRF 102a over the Sp* interface connection 108a to the second PCRF 102b. In step 176 the second PCRF 102b generates policy rules based on the policy control context information. In step 178 the second PCRF 102b acknowledges the IP-CAN bearer establishment over Gx interface connection 103b to the second PCEF 101b. In step 179 the second PCEF 101b acknowledges the establishment of the IP-CAN bearer for the second service connection 130b towards the user equipment 126. In step 180 the user equipment 126 is now using the second service connection 130b. The inter-system mobility procedure between the access networks or the inter-system handover, respectively, is completed. The user equipment 126 is only required to inform the other endpoint of the communication service or the AF about the IP address of the second service connection 130b.

Alternatively to this scenario, the policy control context information may only be stored in the SPR* 107, if it is required. In the alternative scenario, the steps 160 and 162 will not be executed after step 158. Instead, the steps 160' and 162' will be executed after step 168 as indicated by dashed lines in Fig. 2. In step 160' the first PCRF 102a is informed that the second PCRF 102b may need policy control context information and the first PCRF 102a sends a Profile update together with the policy control context information over the extended Sp* interface connection 108a to the SPR* 107. In step 162' the SPR* acknowledges the profile update over the Sp* interface connection 108a.

The information of the first PCRF 102a about a second PCRF 102b in step 160' may be done by the routing agent 114, in particular by the Diameter Routing Agent 114.

The Diameter Routing Agent (DRA) 114 that processes the establishment of the Gx session or interface connection 103b for the new second PCEF 101b (i.e. during the IP-CAN session establishment procedure in step 168) may identify the existence of the active first PCRF 102a via the subscriber and the PDN identifier. Since the Gx session 103b is established from a different node (the second PCEF 101b) than the existing Gx session 103a, the DRA concludes that an inter-system change is ongoing. The 3GPP Rel8 allows more than one IP-CAN session per PDN identifier but only from the same PCEF node. The DRA 114 informs the active first PCRF 102a by duplicating the Gx session 103b establishment signalling and sending it to the active first PCRF 102a. The Gx session 103b establishment signalling to the new second

PCRF 102b is delayed until the response from the active first PCRF 102a is received to ensure that the active first PCRF 102a has stored the policy control context information in the SPR* 107.

The active first PCRF 102a receives the Gx session 103a establishment signalling and detects that it was sent to indicate the inter-system mobility event or inter-system change event based on the same criteria as the DRA (i.e. the request has the same PDN identifier as an ongoing Gx session 103a but comes from the different second PCEF 102b) . This triggers the active first PCRF 102a to store the policy control context information in the SPR* 107. Alternatively the Application Function (AF) 106 can be used in case the AF 106 gets informed about the change of the mobility anchor, i.e. the change of the IP address of the UE 126. If the AF 106 receives a new IP address of the UE 126 for the service, the AF 106 can forward this information to the active first PCRF 102a through the existing Rx session 105 before it establishes the new Rx session 105 with the new second PCRF 102b (based on the new IP address of the UE 126) . Receiving an IP address change of the UE 126 for an ongoing Rx session 105 triggers the active first PCRF 102a to store the current policy control context information in the SPR* 107.

Turning back to Fig. 1, Fig. 1 shows a PCC architecture according to an exemplary embodiment of the present invention. The PCC (Policy and Charging Control) architecture may be implemented in the form of a Policy Control Apparatus 100. The Policy Control Apparatus 100 comprises the Policy and Charging Enforcement Function 101 on an Anchor Device 99, which may run or which may be located on a gateway 99 The

Anchor Device 99 may be an anchor 99 associated with a bearer of a network (not shown in Fig. 1) .

The Policy and Charging Enforcement Function (PCEF) 101 may be a function running on a first Anchor Device 99. In an example the PCEF 101 may run on a gateway 99, i.e. an anchor

99. The PCEF 101 is connected to the Policy and Charging

Rules Function (PCRF) 102 or to the Anchor Change Detecting

Device 102 via the interface Gx 103.

Other Policy and Charging Enforcement Function are connected to the PCRF 102 via the Gxx interface 104.

The Policy Control Apparatus 100 based on the PCC architecture further comprises an Online Charging System (OCS) 109 or an Online Charging Device 109. The Online Charging System 109 OR Online Charging Device 109 is connected to the PCEF 101 via the Gy interface 110. Furthermore, the Policy Control Apparatus 100 comprises the Offline Charging System (OFCS) 111 or the Offline Charging Device 111. The Offline Charging Device 111 is connected to the PCEF 101 via the GZ interface 112.

The Policy Control Apparatus 100 may base on the PCC architecture (Policy and Charging Control) .

Whereas in Fig. 1 a distributed architecture for a Policy Control Apparatus is shown, the components or devices of the Policy Control Apparatus 100 may be included in a single housing or in a single apparatus.

An anchor point 99 change may be a change of the Policy and Charging Enforcement Function (PCEF) 101. An anchor point change may happen, if a subscriber may use a service via different access networks.

A change of an anchor point 99 may affect three reference points or three interfaces in a PCC architecture 100.

In an example a change of an anchor point may affect the Gx 103, the Gy 110 and the Gz 112 reference point. Different access networks may also comprise different policy control apparatuses 100, wherein in Fig. 1 only one Policy Control Apparatus may be depicted.

Also components of the Policy Control Apparatuses may be shared. For example, a SPR 107, an AF 106 and a PCRF 102 can be shared by a first PCEF 101 associated with a first network and a second PCEF 101 associated with a second network (in Fig. 1 only a single PCEF 101 is depicted) .

In an example at least two Policy Control Apparatuses 100 may share a common Subscription Profile Repository 107. Thus, an advertising access function and/or an accounting management concept for changes in access networks with changing anchor points may be provided. In an example the functional groups which are involved in the change process of changing an anchor point may have to be provided with information in order to correctly retrieve required charging rules to be installed on the new PCEF 101 from the PCRF (via the GX interface) 102, 103.

The functional groups involved in an anchor point change may be two different Policy and Charging Control functions 102 or the Policy and Charging Rules Function PCRF 102, the old PCEF 101 and the new PCEF 101.

The old PCEF 101 or the second Anchor Device 99 may correspond to a second anchor point or a second bearer and the new PCEF 101 or the first Anchor Device 99 may correspond to a first anchor point or a first bearer.

The second network may be a 3GPP network and the first network may be non-3GPP network, e.g. a DSL network.

Furthermore the anchor points or the Anchor Devices 99 involved in the anchor changing process may have the current offline charging identifiers available in order to correlate charging data records (CDRs) generated by the old PCEF of the second network and the new PCEF 101 of the first network for the ongoing service sessions. The CDRs for offline charging may be provided from the corresponding PCEF 101 to the Offline Charging Device or System 111 via the reference point Gz 112.

Furthermore the old PCEF and the new PCEF, which may be involved in the anchor changing process, may have to be provided with information in order to have the current Online charging identifiers available in order to release and request quota from OCS (Online Charging System) 109 and also to allow for a converged charging there, i.e. for enabling the correlation between consumed quota by the old PCEFs 101 and the new PCEFs 101 via the Gy interface by the OCS 109. In other words, the second network, for example a 3GPP network may comprise a second anchor point related to a second PCEF and a first network, for example a DSL network, may comprise a first anchor point, related with a first PCEF. The first PCEF and the second PCEF may be connected to a shared SPR* 107. Furthermore the first PCEF and the second PCEF each are connected to the same Online Charging System (OCS) 109 and Offline Charging System (OFCS) 111. The first network may have a first OCS and/or a first OFCS and the second network may have a second OCS and/or a second OFCS

Since the first network and the second network may be different networks different anchor points may be established in each of the separate networks. Since different anchor points are established in different networks, also different bearers are established to provide the basis for a service.

A service in the first network and in the second network may be a video conference service, a video call, a Voice over IP (VoIP) service or an IP TV service. In order to charge the service or to provide Policy Control for the service on a service level, i.e. across different underlying physical access networks, it may make substantially no difference, whether the service is provided via the first network and/or via the second network. However, since for the service in each of the first network and the second network a different bearer, e.g. a first bearer and a second bearer, may be established, also different anchor points may be established.

Therefore, different PCEFs 101, which are associated with the anchor points have to be established. The anchor points and the PCEFs of the different networks may be disjunct and may not be connected. In order to provide a unique service or a seamless service, from a policy and charging perspective, a seamless handover between the second anchor point and the second anchor point may have to be provided when the terminal changes from the second access network or from the second network to the first network or to the first access network while maintaining the service.

In order to achieve a substantially seamless handover on a service level, charging rules on the first PCEF may be taken over from the second PCEF. Thus, in the different networks, the service rules for charging the service may be the same. In an example, a translation of the service rules may be required, which translation may be executed by requesting a PCRF 102 via the interface Gx 103. In other words Gx may serve the provision of PCC rules. Anchor changes may be transparent to the PCEF with the exception of being provisioned with already existing identifiers/context information .

Furthermore in an Offline Charging System 111 CDRs, generated by the second PCEF as long as the service is active in the second network are correlated with CDRs, generated by the first PCEF, as long as the service is active in the first network.

In order to provide a seamless offline charging, CDRs generated by the second PCEF and by the first PCEF may be correlated in order to prevent that the service may be charged twice.

Similar, an Online charging identifier may be provided to CDRs generated of the second PCEF as long as the service is active in the second network. The identifier may allow correlating the quota from the second PCEF with quota generated by the first PCEF as long as the service is active in the first network. Thus, converged charging may be allowed for Online charging and double charging may be prevented.

In order to provide anchor change support capabilities, such as common charging rules, offline charging identifiers and/or online charging identifiers a Subscription Profile Repository, SPR* may be utilized to exchange the offline charging identifiers and/or online charging identifiers. The SPR* may comprise a subscriber related information and/or subscription related information that a PCRF 102 require for subscription based policies as well as for IP-CAN bearer level PCC rules.

The SPR provides the subscriber related information and/or the subscription related information and the IP-CAN bearer level PCC rules. A subscription profile information may comprise the subscribers allowed services, for each allowed service, a pre-emption priority , an information on the subscribers allowed QoS, including the subscribed guaranteed bandwidth QoS, the subscribers charging related information and the subscriber category. In an example a charging related information may be a location information relevant for charging. Service pre-emption priority may enable the PCRF to resolve conflicts where the activation of all requested active PCC rules for services would result in a cumulative authorized QoS which exceeds the Subscribed Guaranteed bandwidth QoS.

The SPR* in particular may further comprise subscribers charging related information, to which IP-CAN (IP Connectivity Access Network) bearer related information may be added, which allows for a smooth change of anchor points.

The subscriber's charging-related information may comprise the identifiers as already described above and/or further charging-related context information required for anchor point changes.

The PCR 102 and the SPR* 107 may interact over the extended SP reference point 108. The extended SP reference point is called SP* 108.

The PCEF 101 may also be adapted to work with a non-3GPP network. An example for a non-3GPP may be a DSL network. In order to work with a non-3GPP network, such as a DSL network, the PCEF 101 may be adapted to be available on a Broadband Remote Access Server (BRAS) . A BRAS may be a connection end point for a DSL connection and in particular for a xDSL connection such as ADSL (Asynchronous Digital Subscriber Line) , SDSL (Synchronous Digital Subscriber Line) or a HDSL (High-speed Digital Subscriber Line) .

For example, in order to be compatible with a BRAS, the PCEF function may be adapted to be located on the BRAS. The BRAS, for example acts as a gateway and thus, the BRAS may act as the anchor point for the DSL access network. A BRAS may only be adapted to use AAA (Authentication, Authorization, Accounting) functionality and thus, no accounting below the bearer level is possible in DSL network. Therefore, a SPR* may be provided for non-3GPP networks.

An IP 5 tuple may comprise a source IP address, a destination IP address, a source port number, a destination port number, a protocol ID of the protocol above IP.

For example, a non-3GPP network may be a AAA based network, i.e. a network which authenticates a subscriber with using a AAA server.

The IP 5 tuple is an example for a service flow filter in a PCC rule. The standard DSL solution, which may base on AAA, may not allow the fine granularity of PCC. AAA may only handle a complete connection as one.

The PCEF 101 may run on the BRAS. Thus, it can be seen, that the PCC architecture 100 or the Policy Control Apparatus 100 may be a distributed system wherein the PCEF 101, the PCRF 102, the SPR* 107, the AF 106, the OCS 109 and/or the OFCS 111 may run on different hardware platforms, such as a BRAS, a Gateway or a charging server.

AAA server based solution may not allow a flow-based charging. A flow-based charging may allow for a differentiated charging on the level of service data flows whereas a non-3GPP network may only allow to charge on the level of a single bearer. A single bearer based network may also be an IP network in a PMIP mode (Proxy Mobile IP) . A non 3GPP network may use the concept of PMIP for implementing mobility. In an example however, PMIP may be implemented for WiMAX and for WLAN and not for DSL.

When a subscriber's UE, i.e. a subscriber terminal, may try to establish an IP-CAN bearer, the PCEF 101 request a PCC authorization for the requested bearer over the Gx reference point 103 from the PCRF 102. An IP-CAN bearer may be established for GPRS by a PDP (Packet Data Protocol) context activation procedure.

The PCRF 102 then requests subscriber information, allowed services and bearer information via the SP* interface 108 from the Subscription Profile Repository SPR* 107 and potential information from the Application Function 106 .

The Sp reference point may allow the PCRF to request subscription information related to the IP-CAN transport level policies from the SPR based on a subscriber ID, a PDN identifier and possible further IP-CAN session attributes. For example, the subscriber ID can be IMSI (International Mobile Subscriber Identity) . The reference point may allow the SPR to notify the PCRF when the subscription information has been changed if the PCRF has requested such notifications. The SPR may stop sending the updated subscription information when a cancellation notification request has been received from the PCRF.

The PCRF 102 then selects and where required, completes PCC rules which have to be provided to the requesting PCEF 101 or which may have to be activated in the requesting PCEF 101 for the respective bearer. These PCC rules may be returned as an authorization decision over the Gx reference point 103. The information provided via the Gx reference point 103 to the PCEF thus may comprise subscriber information, allowed services and bearer information.

Furthermore via the Gx interface potential charging context information may be provided to the PCRF 101, which charging context information may be required for an anchor change from the second anchor point to the first anchor point. This charging context information is provided from the extended SPR* 107. The PCRF 102 saves the charging context information to the SPR* and the PCRF also retrieves the charging context information from the SPR*. The PCRF saves and retrieves such context information to and from the SPR*, which charging context information may be relevant for a potential change of anchor points.

Additionally, the PCRF creates an entry for the new subscriber / service / flow description combination or the service 3 tuple in the SPR* that comprises the requesting PCEF' s identifier as well as the charging context information required for the anchor change, namely the IMS Charging

Identifier (ICID) if present and the access network charging identifier (e.g. the EPC Charging Identifier) both exchanged during the bearer establishment and authorization procedure. The provided charging rules may need not to be saved as they may be newly derived when the anchor changes during a handover procedure.

A potential change of anchor points for which the PCRF saves charging context information to the SPR* may be charging context information which may be required, if for example a subscriber and/or a terminal conducts a handover from a mobile access network (3GPP based) to a DSL network (non-3GPP based or single bearer based) . The charging context information may also be required, when a subscriber conducts a handover from a DSL network to a mobile access network. In other words, the charging context information may be information which may be required for a change of anchor points. And a change of anchor points may be required if a subscriber changes an access network between a 3GPP network and a non-3GPP network.

When a request for PCC authorization reaches the PCRF via the Gx 103 reference point, the PCRF 102 queries the SPR* 107 for a combination of a subscriber description, a service description and a flow description. In other words, this means, when a handover between a 3GPP network and a non-3GPP network may happen, a PCC authorization for the non-3GPP network may be required. In order to conduct an authorization of the subscriber in the non-3GPP network the PCRF 102 may be requested. In order to authorize a subscriber, the PCRF may request the SPR* 107 whether the same subscriber description, service description and flow description combination as requested by the bearer may already exist at another PCEF 101. In other words, by detecting that the same subscriber description, service description and flow description combination associated with a second anchor or with a second bearer exists for a PCEF associated with a first anchor or with a first bearer, a continued service may be detected.

If a subscriber description, service description and flow description combination (the same) not exist in the SPR* 107, a standard PCC procedure as defined in 3GPP TS 23.203 may be carried out. Additionally the PCRF 102 creates an entry for the new subscriber description, service description and flow description combination in the SPR* 107. The new subscriber description, service description and flow description may be associated with the new anchor, for example the first anchor.

The new subscriber description, service description and flow description combination (subscriber/service/flow description combination) in the SPR* comprises the identifier of the requesting PCEF 101, i.e. the PCEF associated with the new anchor, for example the PECF associated with the first anchor . The subscriber description, service description and flow description combination may also comprise charging context information required for the anchor change. Charging context information required for the anchor change may be IMS (IP Multimedia Subsystem) charging identifier (ICID) if present and the access network charging identifier, e.g. the EPC (Evolved Packet Core) charging identifier. The ICID and the EPC charging identifier are both exchanged during the bearer establishment and authorization procedure , e.g. on a GPRS bearer establishment. The provided charging rules may not need to be saved as they can be derived when the anchor changes during a handover procedure. Charging rules may not need to be saved as they can be newly requested.

If for the same subscriber description, service description and flow description combination a bearer already exits at another PCF, the PCRF or the Anchor Change Detecting Device 102 may assume or conclude, that a pending change in anchor points is conducted. In other words, if the Anchor Change Detecting Device detects that at least two different PCEF associated with two different anchors or with two different networks exist for the same subscriber description, service description and flow description combination the anchor charge detecting may assume that a service which may have been established in a second network may still be maintained while a subscriber is changing to a first network.

Thus, the Anchor Change Detecting Device may detect an anchor change, because two different anchor points exist belonging to the same subscriber description, service description and flow description combination. This may mean, that the new PCEF, the first PCEF or the PCEF which may be currently requesting PCC authorization, needs to be provided with the PCC rules and/or with the PCC information which may be relevant for continuously charging and accounting the service session which may be handed over to a new anchor point. The new anchor point may be the new PCEF. The charging and/or accounting information for the service may comprise charging rules or offline charging identifiers or online charging identifiers .

The PCC rules can be newly provided to the new PCEF, i.e. the PCEF currently requesting PCC authorization, and the PCC rules which have been activated and/or which have been installed for the corresponding old bearer may not need to be transferred from the old PCEF or second PCEF to the new PCEF or first PCEF. However, the PCC rules activated or installed for the corresponding old bearer may need to be removed after the handover and after the change of the anchor point have successfully taken place. In other words, when the service have been handed over from the second network to the first network rules, which have been activated or installed in the second network for the second bearer may have to be removed since the same rules may now have been activated for the first bearer in the first network. When a bearer may be terminated, the corresponding PCC rules may be removed.

However, the new PCEF has to be informed about the charging identifiers which have been used for the old bearer such that incorrect charging and billing can be avoided and a correct correlation of charging information is possible. For example, offline charging identifiers and online charging identifiers used for the old bearer may have to be provided for the new

PCEF to allow a correct correlation of the CDRs. The new PCEF is informed about the charging identifiers which have been used for the old bearer as part of the PCRFs authorization decision which may be communicated over the GX reference point. In other words, the new PCEF may request from the PCRF an authorization decision and if the PCRF has conducted an authorization decision, PCC rules and charging identifiers are communicated over the GX reference point to the new PCEF 101.

Based on the charging identifiers passed to the PCEF the interaction with the charging systems 109, 111 via the Gy 110 reference point and the Gz 112 reference point takes place. In case of offline charging via the Gz reference point, the new PCEF 101 generates the CDRs as required by the PCC rules. The CDRs also comprise the charging identifiers obtained from the PCRF. The charging identifiers may be needed for a correlation and the PCEF sends the charging identifiers to the specified destination. The destination may be specified in the rules and may be the OCS or OFCS and/or the Billing system. PCEF may not send isolated identifiers but may send them in the CDRs .

After handover has been completed, the old PCEF closes all CDRs belonging to the old IP-CAN bearer and sends them to the specified offline charging destination.

Double generation of offline CDRs may be avoided by the policy control architecture.)

In case of online charging via the Gy reference point, the new PCEF 101 requests quota, e.g. units specifying the number of minutes or bytes allowed or already paid for, from the specified OCS 109. The new PCEF sends with the request the charging identifiers used by the old PCEF to the OCS 109, which identifiers the new PCEF have been obtained from the PCRF 102. The new PCEF sends the charging identifiers used by the old PCEFs and obtained from the PCRF to the OCS 109, such that a correlation or a potential quota splitting can be conducted in the OCS 109.

A potential quota splitting may have to be conducted, e.g. because a large amount of quota has been generated to the old PCEF such that the request from the new PCEF would otherwise be rejected. For example if too much money has been reserved, such that not enough money is left to do it again. This could happen if no coordination between PCEFs was introduced. A request may be rejected from the PCEF if not enough money left on subscriber account. A transfer of quota between old PCEF and new PCEF may not be used since granted units may differ in valuation of which the PCEFs do not have knowledge such that the OCS needs to be included in this interaction. For example if units provided as quota may have a different monetary value.

Besides, the charging identifier may be required in case that OCS also generates CDR files as part of a converged charging solution. After handover has successfully taken place, the old PCEF returns all remaining quota to the OCS by reporting the quota consumption.

Fig. 4A shows a handover from a 3GPP network to a DSL network before a handover has been conducted according to an exemplary embodiment of the present invention. In Fig. 4A a scenario is shown where the same operator operates different networks, e.g. the 3GPP network 208 and the DSL network 200. The operator may be interested to provide a common billing for services provided on both networks.

The first network is a DSL broadband access network 200. The DSL network is a non-3GPP network 200. On the first network 200 an IP service 201 has been established between an IP TV subscriber 202 and an IP TV server 203. The IP TV service 201 may use the SAE GWl 204. The SAE GWl 204 comprises the S-GW (Serving Gateway) 205. The P-GW (PDN (Public Data Network) Gateway) 206 comprises the first PCEF 207

In a second access network, the 3GPP network 208, e.g. a 3G (3^rd generation) or UMTS network, a subscriber uses an IP connectivity service 210. Via the second SAE GW2 209 the service connection 210, for example a video call is established between terminal A 211 and terminal B 212.

The IP TV service 201 and the video call 210 are transported via the IP network IP-NW 213. The second SAE-GW2 209 comprises the S-GW 214 and the P-GW 215 which are connected via a S5 interface. The P-GW 215 comprises the second PCEF 216 and the Gx reference point. Thus, in Fig. 4A a use case is shown, where a video call 210 between terminal A 211 and terminal B 212 via the 3G network

208 is established. Furthermore, in a separate network, for example in a network at home, an IP TV session 201 via the DSL network 200 runs in parallel.

The PCEF 216 may be the second PCEF or the old PCEF 216 after a handover.

Fig. 4B shows a network scenario comprising a video call and an IP TV session after a handover according to an exemplary embodiment of the present invention.

Fig. 5 shows a flow diagram for a method for handing over policy control information of a second Anchor Device to a first Anchor Device according to an exemplary embodiment of the present invention.

After the video call 210, e.g. an IP service, between terminal A 211 and terminal B 212 has been handed over from the 3GPP network 208 to the DSL network 200 the video call 210 has a new PCEF 207. Once the user 211 or terminal A 211 comes home, the video call 210 should be continued by using the DSL access network 200 at home. After the handover of the video call 210 from the SAE-GW2 209 or from the old SAE-GW2

209 to the new SAE-GWl 204, the new PCEF 207 is associated with the video call 210. The PCEF 216 in Fig. 4B is the old

PCEF of the video call 210.

The Policy and/or Charging rules for the video call 210 have been transferred from the old PCEF 216 to the new PCEF 207 and can be used for continuously billing the video call service 210. It may not be assumed that the same SAE-GW is used for the video call 210 and the IP TV connection 201. If only a single SAE-GW is available in the whole network, it may be assumed, that both services use the same SAE-GW.

Due to missing mobility functions in the access, the traffic of the DSL connection comprising the IP TV connection 201 may not be separated at the DSL access. In a 3GPP network may no need exist to separate traffic of a bearer, because substantially all traffic of a bearer may be related to one single subscriber. Therefore, traffic for the video session 210 would be routed via SAE-GWl

In other words, since network connections may be handled independently in the networks, the handover on a network layer (layer 3) may not be possible, e.g. between 3GPP networks and non 3GPP networks. I.e. an anchor change may be involved when changing the network. Therefore, information about the services used in the networks may be lost and the same service may not be associated one with another. The key or the service n tuple may be an association, which may allow associating at least two services.

Thus, since a new anchor may be established on network layer when a service handover may be conducted, a SPR* may be used, which remembers the anchors and/or the PCEF and may know, which anchor may be the current or new anchor.

A charging session needs to be transferred to SAE-GWl 204. It may be seen as an aspect of the invention providing the SPR* with the charging related parameters, e.g. the service tuple. The PCRF 102 may know the SPR* 107, however the PCEF may not know the SRP*. Thus, communication between SPR* and PCEF 101 may be via the PCRF 102.

Policy and Charging Enforcement Function can be located in a SAE GW, and SPR can be a network element or a database in a SAE core network providing subscriber profile information over enhanced Sp reference point. A scenario may be provided, where gateways are located in different network domains and where a PCEF may be located in the non-3GPP access network gateway, so that a handover between the anchors or gateways can be executed.

The method starts in an idle state S 300 and comprises in a first step S301 detecting that a subscriber is changing from the second Anchor Device to the first Anchor Device.

Upon detecting that the subscriber is changing from the second Anchor Device to the first Anchor Device in a second step S301 the method comprises handing over Policy and Charging Control Information of the subscriber from the second Anchor Device to the first Anchor Device upon detecting.

In step S303 the method reaches again the idle state.

It should be noted that the term "comprising" does not exclude other elements or steps and the "a" or "an" does not exclude a plurality. Also elements described in association with different embodiments may be combined.

It should also be noted that reference signs in the claims shall not be construed as limiting the scope of the claims. Acronyms and Terminology

AAA Authentication, Authorization and Accounting

AR Access Router

ASN WiMAX™ Access Serving Network

ASNGW Access Serving Network Gateway

BAck MIP6 Binding Acknowledge message

BRAS Broadband Remote Access Server

BS WiMAX TM Base Station

BU MIP6 Binding Update message

CMIP Client Mobile IP (as opposed to PMIP)

CoA MIP6 Care-of Address

CSN WiMAX™ Connectivity Serving Network

DHCP Dynamic Host Configuration Protocol

DSL Digital Subscriber Line

EAP Extensible Authentication Method

FA Foreign Agent

FQDN Fully Qualified Domain Name

G-host end user device connected to the network via

G-MS

G-MS Gateway MS

HA Home agent

H-AAA Home AAA server (located in the home network of the WiMAXTM subscriber)

IANA Internet Assigned Numbers Authority

IMS IP Multimedia Subsystem

IP Internet Protocol

IP-CAN IP Connectivity Access Network

LMA Local Mobility Anchor

MAG Mobility Access Gateway

MIP Mobile IP

MN Mobile Node

MS Wi MAX Mobile Station

NAI Network Access Identifier

NAP WiMAX™ Access Network Provider (operator of an ASN) netlmm Network localized mobility management NSP WiMAX™ Network Service Provider (operator of a CSN)

PCC Policy and Charging Control

PCEF Policy and Charging Enforcement Function

PCRF Policy and Charging Rules Functions

PDP policy decision point

PEP policy enforcement point

PBAck PMIP6 Proxy Binding Acknowledge message

PBU PMIP6 Proxy Binding Update message

PMIP Proxy Mobile IP

PMIP4 Proxy Mobile IP version 4

PMI P6 Proxy Mobile IPv6

QoS Quality of Service

RAN Radio Access Network

SA Security Association

SAE System Architecture Evolution

SPR Subscription Profile Repository

V-AM visited AM server (located in the visited network)

VSA Vendor Specific Attribute

Claims

Patent claims

1. A policy management apparatus (100) for a communication network, comprising: a subscriber information device (107) for storing information of a subscriber of the communication network, and a policy decision device (102) for generating policy control context information of the subscriber, wherein the policy decision device (102) is adapted for generating policy control rules based on the policy control context information, wherein the policy decision device (102) is adapted for sending the policy control context information to the subscriber information device (107), and wherein the subscriber information device (107) is adapted for storing the policy control context information.

2. The policy management apparatus (100) of claim 1, wherein the policy decision device (102) is a Policy and Charging Rules Function of a 3GPP network, or wherein the policy decision device (102) is associated with a network selected from a group of networks, the group comprising a non-3GPP communication network, a fixed broadband network and a DSL network.

3. The policy management apparatus (100) of claim 1 or 2, wherein the subscriber information device (107) is a

Subscription Profile Repository of a 3GPP network, or wherein the subscriber information device (107) is associated with a network selected from a group of networks, the group comprising a non-3GPP communication network, a fixed broadband network and a DSL network

4. The policy management apparatus (100) of one of claims 1 to 3 further comprising: a policy enforcement device (101) for enforcing policy rules of the subscriber accessing the communication network, wherein the policy enforcement device (101) is adapted for requesting the policy rules from the policy decision device (102), wherein the policy decision device (102) is adapted for sending the policy control context information to the subscriber information device (107) after the policy enforcement device (101) has requested the policy rules.

6. The policy management apparatus (100) of claim 4, wherein the policy enforcement device (101) is a Policy and Charging Enforcement Function of a 3GPP network, or wherein the policy enforcement device (101) is a Broadband Access Server or associated with a network selected from a group of networks, the group comprising a non-3GPP communication network, a fixed broadband network and a DSL network .

7. The policy management apparatus (100) of one of claims 1 to 6 further comprising: a network change detector, wherein the network detector is adapted for detecting that the subscriber having a first service connection (130a) over a first network (120) wants to establish a second service connection (130b) over a second network (122), wherein the network detector is adapted for informing the policy decision device (102) that the subscriber wants to establish a second service connection (130b), wherein the policy decision device (102) is adapted for sending the policy control context information to the subscriber information device (107) after the network change detector has informed the policy decision device (102) that the subscriber wants to establish the second service connection (130b) .

8. The policy management apparatus (100) of claim 7, wherein the network change detector is a device selected from the group of devices comprising a routing agent (114), a Diameter Routing Agent, and an Application Function of a 3GPP network .

9. The Policy management apparatus (100) of one of claims 1 to 8, wherein the policy control context information comprises at least one information selected from the group of information comprising: information sent to the policy decision device (102) for creating the policy rules, information sent to the policy decision device (102) by an Application Function, information sent to the policy decision device (102) by an policy enforcement device (101), information concerning active services of the subscriber, and the policy control rules.

10. The policy management apparatus (100) of one of claim 1 to 9, wherein the policy decision device (102) is adapted for requesting policy control context information from the subscriber information device (107) .

11. A policy management apparatus (100) of a communication network, comprising: a policy decision device (102) for requesting policy control context information from a subscriber information device (107), wherein the subscriber information device (107) is adapted for storing information of a subscriber of the communication network, and wherein the subscriber information device (107) is adapted for storing the policy control context information, wherein the policy decision device (102) is adapted for generating policy control rules based on the policy control context information.

12. A network system (100) comprising: a first policy management apparatus of one of claims 1 to 10, a second policy management apparatus of one of claims 1 to 11, wherein one of the first policy management apparatus and the second policy management apparatus is associated with a 3GPP network and the other one of the first policy management apparatus and the second policy management apparatus is associated with a network selected from a group of networks, the group comprising a non-3GPP communication network, a fixed broadband network and a DSL network.

13. A method for operating a communication network, comprising the steps of: storing information of a subscriber of the communication network in a subscriber information device (107), generating policy control context information of the subscriber by a policy decision device (102), generating policy control rules based on the policy control context information by the policy decision device, sending the policy control context information to the subscriber information device (107), and storing the policy control context information in the subscriber information device (107) .

14. A method for operating a communication network, comprising the steps of: requesting policy control context information from a subscriber information device (107) by a policy decision device (102), wherein the subscriber information device (107) is adapted for storing information of a subscriber of the communication network, generating policy control rules based on the policy control context information by the policy decision device (102) .

15. A computer readable medium comprising program code, which program code is adapted, when being executed on a processor, to carry out at least one of the methods for operating a communication network of claim 13 and the method of operating a communication network of claim 14.