WO2010051853A1 - Appareil de contrôle de politiques et procédé permettant de transférer des informations relatives aux règles de politiques - Google Patents

Appareil de contrôle de politiques et procédé permettant de transférer des informations relatives aux règles de politiques Download PDF

Info

Publication number
WO2010051853A1
WO2010051853A1 PCT/EP2008/065156 EP2008065156W WO2010051853A1 WO 2010051853 A1 WO2010051853 A1 WO 2010051853A1 EP 2008065156 W EP2008065156 W EP 2008065156W WO 2010051853 A1 WO2010051853 A1 WO 2010051853A1
Authority
WO
WIPO (PCT)
Prior art keywords
anchor
charging
anchor device
subscriber
policy
Prior art date
Application number
PCT/EP2008/065156
Other languages
English (en)
Inventor
Uwe Föll
Gerald Görmer
Ralph KÜHNE
Original Assignee
Nokia Siemens Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Priority to PCT/EP2008/065156 priority Critical patent/WO2010051853A1/fr
Priority to PCT/EP2009/052676 priority patent/WO2010052030A1/fr
Publication of WO2010051853A1 publication Critical patent/WO2010051853A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/66—Policy and charging system

Definitions

  • the present invention relates to the technical field of communication networks.
  • the present invention relates to a Policy Control Apparatus, to a method for handing over Policy Control and Charging information of a second Anchor Device to a first Anchor Device, to a computer- readable medium, to a Broadband Remote Access Server comprising a Policy Control Apparatus and to a use of a Subscription Profile Repository Function.
  • 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.
  • IP-CAN IP Connectivity Access Network
  • GPRS General Packet Radio Service
  • I-WLAN Interworking WLAN
  • 3GPP TS 32.296 "3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Online Charging System (OCS) : Applications and interfaces", Release 8, V.2.0, 2008-06 may specify charging functionality and charging management in 3GPP networks .
  • no solution may be provided to allow handover of services established in a 3GPP network to a broadband access network without dedicated user and service identification e.g. DSL or WIMAX.
  • a Policy Control Apparatus a method for handing over Policy Control information of a second Anchor Device to a first Anchor Device, a computer-readable medium, a Broadband Remote Access Server and a use of a Subscription Profile Repository may be provided.
  • a Policy Control Apparatus may comprise an Anchor Change Detecting Device, a Handover Device and a first Anchor Device.
  • 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.
  • 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.
  • the method may comprise detecting that a subscriber is changing from the second Anchor Device to the first Anchor Device.
  • the method 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.
  • 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.
  • 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.
  • 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.
  • a Broadband Remote Access Server may be provided, wherein the BRAS may comprise an inventive Policy Control Apparatus.
  • 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.
  • 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 x old' may relate to a direction of handing over a UE, a terminal or a service.
  • 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.
  • another aspect of the invention may be buffering identifiers and charging-related context information in an extended SPR during a handover.
  • 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 .
  • 3GPP SAE System Architecture Evolution
  • QoS Quality of Service
  • PEF Accounting Control Policy Enforcement Point
  • 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.
  • 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.
  • 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.
  • a Bearer may be an information transmission path of defined capacity, delay and bit error rate, etc.
  • a 3GPP user or 3GPP subscriber may access a 3GPP network via WiMAXTM a WiMAXTM 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 .
  • a subscriber may establish a 3GPP bearer, e.g. for a UMTS/3G (Universal Mobile Telecommunication System/3 rd Generation) , for a WiMAXTM (Worldwide Interoperability for Microwave Access) or for a GPRS (General Packet Radio Service) access.
  • a 3GPP bearer e.g. for a UMTS/3G (Universal Mobile Telecommunication System/3 rd Generation)
  • WiMAXTM Worldwide Interoperability for Microwave Access
  • GPRS General Packet Radio Service
  • 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.
  • DSL Digital Subscriber Line
  • 3GPP may define several parameters or functions for a bearer.
  • a non-3GPP bearer e.g. a DSL bearer, may not support these functions.
  • 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.
  • a AAA architecture may be used for accounting on a BRAS.
  • AAA may not allow for service flow differentiation such as service flow differentiation may be possible with PCC.
  • 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.
  • 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.
  • a non- 3GPP network may be a broadband access network without dedicated user and service identification e.g. DSL or WIMAX.
  • 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 from a network having fine granularity may happen.
  • WLAN WiMAXTM may be non-3GPP networks which may be integrated in a 3GPP environment.
  • 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.
  • OSI Open Systems Interconnection
  • 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 handover of a service between a 3GPP network and a non-3GPP network may be characterized by a change of an anchor point.
  • 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.
  • services may be exchanged between a 3GPP network and a non-3GPP network and vice versa.
  • a service e.g. an IPTV service of a defined user, which service may have been started in the 3GPP network
  • a non-3GPP network e.g. a DSL network
  • a service started in the 3GPP network may not x find' a corresponding service in the non-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.
  • GTP Global Transport Stream
  • PMIP proxy mobile IP
  • 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.
  • 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 .
  • 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.
  • the service triple 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.
  • 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.
  • 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.
  • a 3GPP network e.g. UMTS, LTE/EPC (Evolved Packet Core)
  • a non 3GPP network e.g. a broadband access network such as DSL may be conducted.
  • PEF Policy Enforcement Function
  • PCC Policy and Charging Control
  • PEF Policy Enforcemnet Function
  • 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.
  • 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.
  • IP TV IP Television
  • the Policy Enforcement Function 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
  • SIP may be used for higher layer mobility.
  • SIP may allow mobility management of services in a non-3GPP network, such as DSL.
  • SIP may be enhanced with features which may be required in mobility environments.
  • 3GPP bearer may be conducted in a 3GPP network and accounting for non-3GPP bearer may be conducted in the non-3GPP network.
  • 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.
  • 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.
  • the first Anchor Device may be associated with a first anchor in the first network.
  • 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.
  • the second anchor, the second anchor point, the second PEF or the second PCEF may not have control over the first bearer.
  • the first Anchor Device may be a first Policy and Charging Execution Function (PCEF) and/or a Policy and Charging Execution Device.
  • PCEF Policy and Charging Execution Function
  • 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 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 and a PDG (Packet Data Gateway) in a WLAN (Wireless Local Area Network) case .
  • GGSN Gateway GPRS Support Node
  • PDG Packet Data Gateway
  • WLAN Wireless Local Area Network
  • 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 Execution Function and a second Policy and
  • the first Anchor Device may comprise a first Policy and Charging Execution 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 second Anchor Device may also comprise a Policy and Charging Execution Function, wherein the second Policy and Charging Execution Function may be separate from the first PCEF.
  • 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.
  • 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.
  • the policy and/or charging control information may travel in parallel to a subscriber and/or a terminal.
  • 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.
  • the first Anchor Device may be associated with a 3GPP bearer.
  • handing over policy and/or charging control information of the subscriber from the second anchor to the first anchor 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.
  • 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.
  • the service key or the service tuple may be stored in combination with the old anchor and the new anchor or with the old PCEF and the new PCEF.
  • 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) .
  • SPR Subscription Profile Repository
  • the anchor change support capabilities may comprise charging related information which may allow for a smooth change of anchor points.
  • 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.
  • the Handover Device may be a Subscription Repository Device (SPR) , wherein the SPR may be adapted for storing the anchor change support capability.
  • SPR Subscription Repository Device
  • the Anchor Change Detecting Device may be a Policy and/or Charging Rule Function Device (PCRF) .
  • PCRF Policy and/or Charging Rule Function Device
  • 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.
  • 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.
  • a 3GPP network and a non-3GPP network may be networks which may not be related to one and another.
  • a 3GPP network and a non-3GPP network may be disjunct networks.
  • 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.
  • 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
  • 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.
  • an IP TV service may continuously be charged even if a subscriber, while using the service, may change the access network .
  • an SPR* may be used to translate Policy and/or Charging rules between different access networks.
  • 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.
  • 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.
  • 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.
  • the Policy Control Apparatus further may comprise an Off-Line Charging Device.
  • the Off-Line Charging Device 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.
  • charging data records for the service may be generated in different Policy Control Apparatuses or PCEFs or PEFs.
  • An Off-Line Charging Device 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. Off-line 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.
  • the Policy Control Apparatus may comprise an On- Line Charging Device, wherein the On-line Charging Device 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.
  • 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.
  • 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.
  • 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 may allow to continuously charging the service, even if a anchor change may be conducted.
  • Fig. 1 shows a PCC architecture according to an exemplary embodiment of the present invention.
  • Fig. 2A 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.
  • Fig. 2B 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. 3 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.
  • 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 Execution
  • Anchor Device 101 which may run or which may be located on a gateway (not shown in Fig. 1)
  • the Anchor Device 101 may be an anchor 101 associated with a bearer of a network (not shown in Fig. 1) .
  • the Policy and Charging Execution Function (PCEF) 101 may be a function running on a first Anchor Device 100. In an example the PCEF may run on a gateway, i.e. an anchor.
  • 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.
  • PCRF Policy and Charging Rules Function
  • the PCRF 102 Via the Rx interface 105 the PCRF 102 is connected to the Application Function (AF) 106.
  • AF Application Function
  • the PCRF 102 furthermore is connected to the Subscription Profile Repository* (SPR*) 107 via the interface SP* 108.
  • SPR* Subscription Profile Repository*
  • the Policy Control Apparatus 100 based on the PCC architecture further comprises an Online Charging System (OCS) 109 or an Online Charging Device 109.
  • OCS Online Charging System
  • the Online Charging System 109 OR Online Charging Device 109 is connected to the PCEF 101 via the Gy interface 110.
  • 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) .
  • 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 101 change may be a change of the Policy and Charging Execution Function (PCEF) 101.
  • PCEF Policy and Charging Execution Function
  • a change of an anchor point 101 may affect three reference points or three interfaces in a PCC architecture 100.
  • 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.
  • 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) .
  • At least two Policy Control Apparatuses 100 may share a common Subscription Profile Repository 107.
  • an advertising access function and/or an accounting management concept for changes in access networks with changing anchor points may be provided.
  • 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 101 may correspond to a second anchor point or a second bearer and the new PCEF 101 or the first Anchor Device 101 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.
  • the anchor points or the Anchor Devices 101 involved in the anchor changing process may have the current off-line 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 off-line charging may be provided from the corresponding PCEF 101 to the Offline Charging Device 111 via the reference point Gz 112.
  • 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.
  • OCS Online Charging System
  • 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.
  • the first PCEF and the second PCEF each are connected to the same On-line Charging System (OCS) 109 and Off-line Charging System (OFCS) 111.
  • OCS On-line Charging System
  • OFCS Off-line Charging System
  • 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
  • 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.
  • VoIP Voice over IP
  • VoIP Voice over IP
  • IP TV IP TV service
  • a different bearer e.g. a first bearer and a second bearer, may be established, also different anchor points may be established.
  • the anchor points and the PCEFs of the different networks may be disjunct and may not be connected.
  • 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.
  • charging rules on the first PCEF may be taken over from the second PCEF.
  • the service rules for charging the service may be the same.
  • a translation of the service rules may be required, which translation may be executed by requesting a PCRF 102 via the interface Gx 103.
  • 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 .
  • 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.
  • 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.
  • an on-line 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.
  • converged charging may be allowed for on-line charging and double charging may be prevented.
  • 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.
  • 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.
  • IP-CAN IP Connectivity Access Network
  • 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.
  • a non-3GPP may be a DSL network.
  • the PCEF 101 may be adapted to be available on a Broadband Remote Access Server (BRAS) .
  • 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) .
  • 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.
  • AAA Authentication, Authorization, Accounting
  • 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.
  • 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.
  • 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) .
  • PMIP 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.
  • IP-CAN bearer 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.
  • PDP Packet Data Protocol
  • 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.
  • 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 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.
  • 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
  • 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.
  • 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.
  • the charging context information may be information which may be required for a change of anchor points.
  • a change of anchor points may be required if a subscriber changes an access network between a 3GPP network and a non-3GPP network.
  • the PCRF 102 queries the SPR* 107 for a combination of a subscriber description, a service description and a flow description.
  • a PCC authorization for the non-3GPP network may be required.
  • the PCRF 102 may be requested.
  • 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.
  • 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.
  • IMS IP Multimedia Subsystem
  • EPC Evolved Packet Core
  • 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.
  • the PCRF or the Anchor Change Detecting Device 102 may assume or conclude, that a pending change in anchor points is conducted.
  • 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.
  • 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 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.
  • 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.
  • the corresponding PCC rules may be removed.
  • 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.
  • 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.
  • 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.
  • the new PCEF 101 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.
  • 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.
  • 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.
  • 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. 2A 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.
  • 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.
  • 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
  • the 3GPP network 208 e.g. a 3G (3 rd generation) or UMTS network
  • a subscriber uses an IP connectivity service 210.
  • 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.
  • the PCEF 216 may be the second PCEF or the old PCEF 216 after an handover.
  • Fig. 2B 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. 3 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.
  • the video call 210 e.g. an IP service
  • the video call 210 has a new PCEF 207.
  • the video call 210 should be continued by using the DSL access network 200 at home.
  • the new PCEF 207 is associated with the video call 210.
  • the PCEF 216 in Fig. 2B 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.
  • 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
  • a network layer 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.
  • 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 Execution 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.
  • Fig. 3 shows a flow diagram for a method for handing over policy control information of a second Anchor Device to a first Anchor Device.
  • 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.
  • 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.
  • step S303 the method reaches again the idle state.
  • AAA Authentication, Authorization and Accounting
  • BRAS Broadband Remote Access Server
  • DSL Digital Subscriber Line
  • IMS IP Multimedia Subsystem
  • IP Internet Protocol
  • IP-CAN IP Connectivity Access Network
  • PCC Policy and Charging Control
  • PCEF Policy and Charging Execution Function
  • PCRF Policy and Charging Control Functions

Abstract

L'invention concerne un appareil de contrôle de politiques et un procédé permettant de transférer des informations relatives aux règles de politiques d'un second dispositif d'ancrage à un premier dispositif d'ancrage. L'invention concerne un appareil de contrôle de politiques (100) qui comporte un dispositif de détection de changement d'ancrage (102), un dispositif de transfert (107) et un premier dispositif d'ancrage (101). Le dispositif de détection de changement d'ancrage (102) est conçu pour détecter le passage d'un abonné d'un second dispositif d'ancrage à un premier dispositif d'ancrage (101). Le dispositif de transfert (107) est conçu pour transmettre des informations relatives aux règles de politiques et de facturation liées à l'abonné du second dispositif d'ancrage au premier dispositif d'ancrage (101), lors de la détection du passage de l'abonné du second dispositif d'ancrage au premier dispositif d'ancrage (101). (Fig. 3)
PCT/EP2008/065156 2008-11-07 2008-11-07 Appareil de contrôle de politiques et procédé permettant de transférer des informations relatives aux règles de politiques WO2010051853A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/EP2008/065156 WO2010051853A1 (fr) 2008-11-07 2008-11-07 Appareil de contrôle de politiques et procédé permettant de transférer des informations relatives aux règles de politiques
PCT/EP2009/052676 WO2010052030A1 (fr) 2008-11-07 2009-03-06 Appareil de commande de politique et procédé de transfert d'informations de commande de politique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/065156 WO2010051853A1 (fr) 2008-11-07 2008-11-07 Appareil de contrôle de politiques et procédé permettant de transférer des informations relatives aux règles de politiques

Publications (1)

Publication Number Publication Date
WO2010051853A1 true WO2010051853A1 (fr) 2010-05-14

Family

ID=40834465

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/EP2008/065156 WO2010051853A1 (fr) 2008-11-07 2008-11-07 Appareil de contrôle de politiques et procédé permettant de transférer des informations relatives aux règles de politiques
PCT/EP2009/052676 WO2010052030A1 (fr) 2008-11-07 2009-03-06 Appareil de commande de politique et procédé de transfert d'informations de commande de politique

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/052676 WO2010052030A1 (fr) 2008-11-07 2009-03-06 Appareil de commande de politique et procédé de transfert d'informations de commande de politique

Country Status (1)

Country Link
WO (2) WO2010051853A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8028324B2 (en) * 2004-06-03 2011-09-27 Huawei Technologies Co., Ltd. Method for transmitting policy information between network equipment
EP2670195A1 (fr) * 2012-05-31 2013-12-04 Telefonaktiebolaget L M Ericsson AB (Publ) Procédés et appareil pour atténuer une interruption de service
TWI504291B (zh) * 2012-11-01 2015-10-11 Ind Tech Res Inst 爲網路存取計量的系統、伺服器與方法
CN105493533A (zh) * 2014-07-08 2016-04-13 华为技术有限公司 在线计费方法、网关设备及在线计费设备
EP3116284A4 (fr) * 2014-03-04 2017-02-22 Huawei Technologies Co., Ltd. Procédé et dispositif pour gérer une session de facturation
JP2017121079A (ja) * 2011-01-28 2017-07-06 サムスン エレクトロニクス カンパニー リミテッド 移動通信システムの課金制御装置及び方法
USRE48656E1 (en) 2010-12-09 2021-07-20 Allot Ltd. System, device, and method of traffic detection

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9225849B2 (en) 2011-05-06 2015-12-29 Tekelec, Inc. Methods, systems, and computer readable media for steering a subscriber between access networks
US9497082B2 (en) * 2011-10-03 2016-11-15 Alcatel Lucent Rules engine evaluation for policy decisions
CN103327453A (zh) * 2012-03-22 2013-09-25 北京三星通信技术研究有限公司 一种选择pcef和pcrf的方法
US10477385B2 (en) 2012-07-20 2019-11-12 Tekelec, Inc. Methods, systems and computer readable media for distributing policy rules to the mobile edge
EP2947924A4 (fr) * 2013-01-31 2016-03-02 Huawei Tech Co Ltd Procédé, dispositif, et système de traitement d'accès
CN104170420B (zh) * 2013-04-02 2018-10-30 华为技术有限公司 开放无线管道能力的方法及其装置
CN106470412B (zh) * 2015-08-20 2021-08-24 中兴通讯股份有限公司 终端下线方法、备用pcrf装置、用户签约数据装置及系统
CN110650475B (zh) * 2018-06-26 2022-06-03 中国移动通信有限公司研究院 一种会话绑定处理方法及网络设备
CN113228748B (zh) 2018-12-19 2022-11-15 台湾积体电路制造股份有限公司 用于网络接入服务的系统和方法
CN112511326B (zh) * 2020-03-16 2024-02-02 中兴通讯股份有限公司 一种切换方法、装置、设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060291419A1 (en) * 2005-06-22 2006-12-28 Sprint Spectrum L.P. Method and system for managing communication sessions during multi-mode mobile station handoff
WO2007038947A1 (fr) * 2005-09-27 2007-04-12 Telefonaktiebolaget L M Ericsson (Publ) Architecture de reseau et procede pour l'acces aux stations d'utilisateur
WO2008094401A2 (fr) * 2007-01-31 2008-08-07 Lucent Technologies Inc. Contrôle de facturation et de politique tenant compte de la mobilité dans un réseau de communication sans fil

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6862446B2 (en) * 2003-01-31 2005-03-01 Flarion Technologies, Inc. Methods and apparatus for the utilization of core based nodes for state transfer

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060291419A1 (en) * 2005-06-22 2006-12-28 Sprint Spectrum L.P. Method and system for managing communication sessions during multi-mode mobile station handoff
WO2007038947A1 (fr) * 2005-09-27 2007-04-12 Telefonaktiebolaget L M Ericsson (Publ) Architecture de reseau et procede pour l'acces aux stations d'utilisateur
WO2008094401A2 (fr) * 2007-01-31 2008-08-07 Lucent Technologies Inc. Contrôle de facturation et de politique tenant compte de la mobilité dans un réseau de communication sans fil

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
VICTOR Y.H. KUEH, MICK WILSON: "Evolution of Policy Control and Charging (PCC) Architecture for 3GPP Evolved System Architecture", IEEE VTC 2006, 63RD CONFERENCE, 18 September 2006 (2006-09-18), pages 259 - 263, XP002537246, ISSN: 1550-2252, ISBN: 1-7803-9392-9, Retrieved from the Internet <URL:http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1682816> [retrieved on 20090715] *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8028324B2 (en) * 2004-06-03 2011-09-27 Huawei Technologies Co., Ltd. Method for transmitting policy information between network equipment
US8908687B2 (en) 2004-06-03 2014-12-09 Huawei Technologies Co., Ltd. Method for transmitting policy information between network equipment
USRE48656E1 (en) 2010-12-09 2021-07-20 Allot Ltd. System, device, and method of traffic detection
JP2017121079A (ja) * 2011-01-28 2017-07-06 サムスン エレクトロニクス カンパニー リミテッド 移動通信システムの課金制御装置及び方法
US10560818B2 (en) 2011-01-28 2020-02-11 Samsung Electronics Co., Ltd. Device and method for controlling charging in a mobile communication system
EP2670195A1 (fr) * 2012-05-31 2013-12-04 Telefonaktiebolaget L M Ericsson AB (Publ) Procédés et appareil pour atténuer une interruption de service
US9191960B2 (en) 2012-05-31 2015-11-17 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatus for mitigating service interruption
TWI504291B (zh) * 2012-11-01 2015-10-11 Ind Tech Res Inst 爲網路存取計量的系統、伺服器與方法
EP3116284A4 (fr) * 2014-03-04 2017-02-22 Huawei Technologies Co., Ltd. Procédé et dispositif pour gérer une session de facturation
US10033881B2 (en) 2014-03-04 2018-07-24 Huawei Technologies Co., Ltd. Charging session management method and apparatus
US10623584B2 (en) 2014-03-04 2020-04-14 Huawei Technologies Co., Ltd. Charging session management method and apparatus
CN105493533A (zh) * 2014-07-08 2016-04-13 华为技术有限公司 在线计费方法、网关设备及在线计费设备

Also Published As

Publication number Publication date
WO2010052030A1 (fr) 2010-05-14

Similar Documents

Publication Publication Date Title
WO2010051853A1 (fr) Appareil de contrôle de politiques et procédé permettant de transférer des informations relatives aux règles de politiques
US8750825B2 (en) Methods, systems, and computer readable media for inter-carrier roaming cost containment
CA2682979C (fr) Procede, systeme et entite de realisation de detection d&#39;evenement
KR101368709B1 (ko) 서비스 품질을 동적으로 제어하기 위한 방법 및 시스템
US9503483B2 (en) Method and apparatuses for identifying and reporting quality of service rules applicable to a communication session
US8640188B2 (en) Methods, systems, and computer readable media for providing group policy configuration in a communications network using a fake user
EP2186353B1 (fr) Procédé pour une extraction simple d&#39;informations de sélection d&#39;accès à un réseau
US9860752B2 (en) Handling of authorization requests for a packet-based service in a mobile network
US9894560B2 (en) Method and device for controlling QOS and/or policy and charging control of a guest user
US9191960B2 (en) Methods and apparatus for mitigating service interruption
US20100186064A1 (en) Method and device for obtaining capabilities of policy and charging enforcement function
WO2011060698A1 (fr) Procédé et système de réalisation de contrôle de surveillance d&#39;utilisation
EP2467970A1 (fr) Procédé, appareil et programme d&#39;ordinateur permettant la mise en application d&#39;une politique sur des sessions associées compte tenu d&#39;un quota d&#39;utilisation totale pour un utilisateur associé
WO2014023327A1 (fr) Filtrage de contenu dynamique d&#39;un trafic de données dans un réseau de communication
WO2011063688A1 (fr) Procédé et système de sélection d&#39;entité à fonction de règles de politique et de facturation
EP2052513B1 (fr) Gestion de politique dans des scénarios multi-accès
US20160073328A1 (en) Method and apparatus for determining pcrf
WO2009026812A1 (fr) Procédé, dispositif et système d&#39;application d&#39;une politique de contrôle
JP2015511432A (ja) 移動パケットコアネットワークにおけるセッション終了
JP2016154389A (ja) 移動パケットコアネットワークにおけるセッション終了

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08875295

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08875295

Country of ref document: EP

Kind code of ref document: A1