WO2009118038A1 - Policy and charging control architecture - Google Patents
Policy and charging control architecture Download PDFInfo
- Publication number
- WO2009118038A1 WO2009118038A1 PCT/EP2008/053509 EP2008053509W WO2009118038A1 WO 2009118038 A1 WO2009118038 A1 WO 2009118038A1 EP 2008053509 W EP2008053509 W EP 2008053509W WO 2009118038 A1 WO2009118038 A1 WO 2009118038A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- policy
- charging
- interface
- function
- rules
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
Definitions
- the present invention relates to a policy and charging control architecture and more particularly to such an architecture for use with the IP Multimedia Subsystem.
- IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
- the number of services offered to the end subscribers will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.
- IMS IP Multimedia Subsystem
- 3GPP Third Generation Partnership Project
- ETSI TISPAN IP Multimedia Subsystem
- IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP -based networks.
- the IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and application servers).
- SIP Session Initiation Protocol
- SDP Session Description Protocol
- SIP was created as a subscriber- to-subscriber protocol
- IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.
- FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other IP access networks, known generically as IP Connectivity Access Networks or IP-CANs).
- IMS GPRS/PS access network
- IP-CANs IP Connectivity Access Networks
- CSCFs Call/Session Control Functions
- the 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber and which the subscriber is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
- P-CSCF Proxy CSCF
- S-CSCF Serving CSCF
- I-CSCF Interrogating CSCF
- the IMS architecture offers the opportunity to deploy peer-to-peer applications where two or more users exchange user data directly, following SIP session establishment via IMS.
- peer-to-peer applications are Multimedia Telephony (MMTeI), Push to Talk over Cellular (PoC), streaming, real-time video sharing, file sharing, gaming etc.
- MMTeI Multimedia Telephony
- PoC Push to Talk over Cellular
- streaming real-time video sharing
- file sharing gaming etc.
- the transport connection(s) is(are) negotiated dynamically by means of the SIP/SDP protocol exchange between the two end points.
- an Application Function (AF) 1 is an element implementing applications that require dynamic policy and/or charging control of traffic plane resources.
- the P-CSCF plays the role of AF in the SIP signaling plane.
- the Policy and Charging Enforcement Function (PCEF) 2 provides service data flow detection, charging, and policy enforcement of the user plane traffic.
- GPRS General Packet Radio Service
- the PCEF is located within a GPRS Gateway Support Node (GGSN).
- GGSN GPRS Gateway Support Node
- the PCRF is a separate logical node and sits in between of the Application layer (e.g. IMS), where services are initiated and service characteristics are negotiated, and the user plane where the actual service is being provided.
- the Policy and Charging Rules Function (PCRF) 3 provides policy and flow-based charging control functions, using subscriber data stored in a Subscription Profile Repository (SPR) 4.
- the PCRF receives Service Information (e.g. application identifier, type of media, bandwidth, IP address and port number) from the AF over the Rx interface, and uses this to install PCC rules into the PCEF which in turn ensures that only authorized media flows associated with the requested services are allowed, and that the correct bandwidth, charging and priority are applied.
- the PCEF provides real-time charging information to an Online Charging System (OCS) 5.
- OCS Online Charging System
- the AF may modify Session Information at any time, for example due to an AF session modification or internal AF trigger. Modification is achieved by the AF sending an AA-Request command to the PCRF over the Rx reference point ("reference point" is a term used in 3GPP to identify an information flow between logical functions) containing the Media-Component-Description Attribute- Value Pairs (AVPs), with the updated Service Information as defined in 3GPP TS 29.214.
- the PCRF processes the received Service Information according to the operator policy and may decide whether the request is accepted or not. If the request is accepted, the PCRF updates the preexisting Service Information with the new information.
- the updated Service Information may require the PCRF to create, modify or delete the related PCC rules and provide the updated information towards the PCEF over the Gx reference point as specified in 3GPP TS 29.212.
- the procedures used to update the Authorized QoS for the affected IP-CAN bearer are also specified in 3GPP TS 29.212.
- Currently specified procedures for modification of the Service Information for PCC provide for the immediate activation, replacement and removal of filter description information at the PCEF.
- apparatus for generating policy and charging rules to control IP flows across a packet switched network comprises a first interface for coupling to an application function and a second interface for coupling to a policy and charging enforcement function implemented at a node through which said IP flows pass.
- a processor or processors are configured to receive service information at said first interface, and, via said second interface to trigger the removal of one or more pre-existing policy and charging rules at the policy and charging enforcement function following a predefined delay.
- This apparatus may be embodied as a standalone logical entity, or may be colocated with some other network entity.
- said processor or processors is/are configured to initiate a timer upon receipt of said service information and, upon expiry of the timer, to send an instruction to said policy and charging enforcement function via said second interface to delete said pre-existing policy and charging rule(s).
- Said processor or processors may be configured to send to said policy and charging enforcement function, via said second interface, an instruction to delete said preexisting policy and charging rule(s) after a delay specified in the instruction.
- Said processor or processors may be configured to receive, via said first interface, an explicit request to implement said delay. Said processor or processors may be configured to receive, via said first interface, a delay value.
- Said processor or processors may be configured to implement said delay based upon service description characteristics received over said first interface.
- Said processor or processors may be configured to (a) install a new set of policy and charging rules into said policy and charging enforcement function in addition to a preexisting set and (b), following said predefined delay, to remove said pre-existing set from said policy and charging enforcement function.
- Said processor or processors may be further configured to perform steps (a) and (b) in response to respective requests received from said application function.
- the apparatus comprises an interface for coupling to a policy and charging rules function, and a processor or processors configured to determine service information relating to an IP flow or flows and to send said service information via said interface together with a request for delayed deletion of a policy and charging control rule or rules relating to said flow(s).
- said processor or processors may be configured to send a delay value together with said service information and said explicit request.
- Said processor or processors may be configured to include said service information and said explicit request, and optionally said delay value, within a Session Description Protocol offer. Said processor or processors may be configured to include said explicit request within said offer as an AVP.
- the apparatus of the above second aspect of the invention may be configured to operate as a Proxy Call Session Control Function within an IP Multimedia Subsystem.
- apparatus for implementing an application function to establish and control IP flows across a packet switched network.
- the apparatus comprises an interface for coupling to a policy and charging rules function, and a processor or processors configured to determine service information relating to an IP flow or flows and to send said service information via said interface together with a request to maintain an existing policy and charging control rule or rules relating to said flow(s), and, after a predefined delay, to send a further request to delete said existing policy and charging control rule or rules.
- apparatus for implementing a policy and charging enforcement function in respect of IP flows through a packet switched network.
- the apparatus comprises an interface for coupling to a policy and charging rules function, and a processor or processors configured to receive via said interface an instruction to remove a policy and charging rule or rules relating to an IP flow or flows, to initiate a timer upon receipt of said instruction, and upon expiry of said timer to remove said rule(s).
- the apparatus of the fourth aspect of the present invention may be configured to operate as a GPRS Gateway Support Node within a GPRS packet switched network.
- a method of controlling IP flows through a packet switched access network comprises sending updated service information from an application function to a policy and charging rules function.
- the policy and charging rule or rules are removed after a predefined delay.
- a timer is initiated at the policy and charging rules function and, upon expiry of said timer, an instruction sent to said policy and charging enforcement function to remove said policy and charging rule or rules.
- an instruction is sent to said policy and charging enforcement function to remove said policy and charging rule or rules after a predefined delay, a delay value being included with the instruction.
- a timer is initiated at said application function and, following expiry of said timer, further service information sent to said policy and charging rules function, receipt of the further service information resulting in the removal of said policy and charging rule or rules.
- policy and charging rules function is arranged to make separate determinations for rule(s) removal for uplink and downlink IP flows.
- service information means information including filter information, e.g. IP source and destination IP addresses and port numbers.
- the service information may additionally comprise an identification of required codecs, bandwidth, etc.
- a method of controlling IP flows through a packet switched access network comprises sending updated filter information from an application function to a policy and charging rules function together with a request to maintain existing filter information relating to said IP flows.
- a new policy and charging rule(s) are determined using said updated filter information and the addition of said rules at a policy and charging enforcement function is triggered whilst maintaining said existing filter information.
- a request is sent from said application function to said policy and charging rules function with previously provided updated filter information and an indication that only this filter information shall remain active.
- Said existing filter information is deleted at the policy and charging enforcement function, and corresponding bearers also deleted.
- IP flow being controlled is an IP media flow between two or more user entities, UEs.
- Figure 1 illustrates schematically components of an IP Multimedia Subsystem overlayed on a packet switched access network
- Figure 2 illustrates schematically a Policy and Charging Control Architecture
- Figure 3 illustrates signalling associated with a procedure for installing and removing
- Figure 4 illustrates schematically a PCRF according to an embodiment of the present invention
- Figure 5 illustrates schematically an AF according to an embodiment of the present invention
- Figure 6 illustrates schematically a PCEF according to an embodiment of the present invention
- Figure 7 is a flow diagram illustrating two alternative procedures for applying Policy and Charging Control.
- Figures 8A and 8B illustrate signalling associated with an alternative procedure for installing and removing PCC rules from a PCEF
- Figure 9 illustrates schematically an AF for use with the procedure illustrated in Figure
- FIG. 8 Figure 10 illustrates schematically a PCRF for use with the procedure illustrated in
- Figure 11 is a flow diagram further illustrating the procedure of Figure 8.
- Scenarios are envisaged however in which, upon modification of the Service Information by the AF to replace or to remove "existing" filter information, it is undesirable to delete the existing filter information immediately.
- the endpoints may negotiate the reestablishment of an "existing" TCP connection. This may occur during a single SIP session over IMS. It is likely that the new TCP connection is established using different port numbers, so the filter information provided previously to the PCRF must be updated.
- the existing filters remain in place to let the associated TCP packets through until either the UE itself requests the removal of the existing filters (which is possible when UE initiated bearer control mode is used), or until a network-controlled safeguard time period has elapsed (which is used regardless of the bearer control mode between the UE and the PCEF as well as when bearer control procedures are not used at all).
- the safeguard time is determined by the network and is set to a value that will allow the endpoints to gracefully terminate the "existing" TCP connection. In the case of UE initiated bearer control procedures, the safeguard time sets a limit for the UE to remove the filters itself, thus protecting the network from a potentially fraudulent UE which does not remove the filters.
- Figure 3 presents an overall description of a method for the deferred removal of existing filter information in the PCEF. This relates by way of example to the reestablishment of an existing TCP connection.
- an existing TCP connection has been established between two endpoints (UEs) and for which corresponding filters and PCC rules are active within the IP-CAN (step 0 in Figure 3).
- the endpoints then negotiate the re-establishment of this TCP connection by exchanging SDP offer and SDP answer messages via P-CSCF of the IMS (step 1-3 and
- the AF of the PCC architecture resides in the P-CSCF. If available (i.e. "new, active/passive" within SDP answer), the P-CSCF provides updated filter information to the PCRF for the establishment of the new TCP connection. It does this using the Diameter AAR message (step 4). Otherwise (i.e. "new, holdconn" within the SDP answer) the P-CSCF requests the removal of existing filter information in order to block the existing TCP connection.
- the P-CSCF additionally includes a request for deferred removal of existing filter information.
- An explicit indication that deferred removal of existing filter information is required may be in the form of a new "Deferred-Removal- Timer-UL/DL" AVP contained within the AAR message.
- the Deferred-Removal-Timer-UL/DL AVP may be of type Unsigned32, and may indicate the value for the timer, e.g. in seconds or milliseconds.
- This AVP is only used when the AF (P-CSCF) requests replacement of existing filter information with new information (i.e. updated filter information is provided within the Flow-Description AVP) or when the AF requests removal of existing filter information without providing new information (i.e. Flow- Status AVP is set to the value 'REMOVED').
- the existing filter information (if available) is removed immediately (i.e. the default value for this timer is zero if this AVP is not provided by the AF). If the AF includes this AVP but existing filter information is not available for the corresponding flows, the PCRF ignores the AVP.
- timers for deferred removal of uplink (UL) and downlink (DL) filter information may be different, two separate AVPs may be defined and included within the AAR sent from the P-CSCF to the PCRF.
- the Deferred-Removal-Timer-UL/DL may be included at Media Component level as illustrated in Table 1 below, or at the Media Subcomponent level as illustrated in Table 1 below.
- the PCRF Upon receipt of the AAR message from the P-CSCF, the PCRF starts the deferred- removal timer (step 5) and responds to the P-CSCF with a Diameter AAA message
- the PCRF creates PCC rules for the new filter information and installs these into the PCEF (step 8). To generate the new rules, the PCRF may contact the SPR (see Figure 2).
- the PCRF may request that the PCEF initiate the timer and remove the PCC rules for the existing filter information upon expiry of the timer. This approach may indeed be optimal where a single message from the PCRF is used to install both new rules and trigger the delayed removal of the existing rules.
- IP flows matching the existing filter information will be accepted at the PCEF prior to expiry of the timer as the corresponding PCC rules will not yet have been removed from the PCEF. This provides a transition period during which the end points can gracefully terminate the existing TCP connection (step 9).
- the IP-CAN will remove the corresponding PCC rules for the existing filter.
- the corresponding bearer resources will be also be released (step 11) and IP flows matching the existing filters will no longer be accepted.
- the UE may itself request the removal of existing filter information after graceful termination of the existing TCP connection (step 10' replacing steps 10 and 11), in which case the IP-CAN will remove the existing filter information and corresponding PCC rule(s) (step 10') and will stop the deferred removal timer (running in either the PCRF or PCEF) (step 11 ').
- An alternative to including an explicit deferral request in the AAR is to configure the IP-CAN to trigger the deferred removal of existing filter information based on certain service description characteristics as currently provided by the AF.
- the PCRF will start the Deferred-Removal-Timer-UL/DL.
- the PCC rule(s) for the IP flows matching the existing filter information are kept active whilst the timer is running (i.e. corresponding IP flows, e.g. over an existing TCP connection, will be accepted). If the AF provided new filter information to replace the existing information, new filters will be installed and activated at the PCEF over the Gx reference point, either within the same PCC rule(s) defining the existing filters or within a new PCC rule(s).
- the PCRF proceeds to remove the existing filter information.
- the PCRF removes the existing filter information from the PCC rules where they were defined (most probably the PCC rule itself will be removed).
- the corresponding bearer resources will be released and the IP flows matching the existing filter information will no longer be accepted.
- apparatus 6 for implementing a PCRF in the case where the PCRF implements the delay timer.
- the apparatus comprises a first interface 7 connected to the Rx reference point, and a second interface 8 connected to the Gx interface.
- a processor or processors 9 is responsible for receiving and handling
- the processor(s) determines based upon explicit indications in the Service Information, or based upon service session characteristics, that a delay is to be implemented. If so, a timer 10 is initiated as described above.
- FIG. 5 illustrates schematically apparatus 11 for implementing an AF.
- This apparatus could comprise a P-CSCF of an IMS network.
- the apparatus 11 comprises an interface 12 coupled to the Rx reference point, and a processor or processors 13 for generating Service Information based upon requirements of IMS subscribers.
- the processor(s) may include an explicit request for rule removal delay within the Service Information.
- FIG. 6 illustrates schematically apparatus 14 for implementing a PCEF in the case where the timer is implemented at the PCEF.
- the apparatus comprises an interface 15 coupled to the Gx reference point.
- a processor or processors 16 handles incoming PCC rule related instructions.
- PCC rules are maintained in a PCC rules database 18.
- a timer is implemented at entity 17.
- FIG. 7 is a flow diagram illustrating two alternative PCC mechanisms as described above. Common to both mechanisms are the steps of detecting session modification at the AF (step 100), sending modified Service Information from the AF to the PCRF (step 101), receiving the modified Service Information at the PCRF and generating any new Policy and Charging Control Information (step 102), and immediately installing the new PCC information at the PCEF (step 103).
- Option A is followed when the timer is implemented at the PCRF (step 104).
- the timer is checked (step 105), and upon expiry the PCRF sends an IP filter removal instruction to the PCEF (step 106).
- the PCEF responds by removing the appropriate IP filter(s) from its rules database (step 107).
- Option B is followed when the delay timer is implemented at the PCEF.
- the PCRF immediately sends the IP filter removal instruction to the PCEF (step 104'), together with the new rule, i.e. steps 103 and 104' may be implemented using the same message of the Gx reference point.
- the PCEF initiates a delay timer with appropriate delay value (step 105'), The timer is checked (step 106'), and upon expiry the existing IP filters are removed (step 107').
- the deferred filter removal timer is implemented at the AF, i.e. P- CSCF.
- the P-CSCF determines the need to implement the timer at step 4, with the timer actually being initiated at step 10 (or earlier).
- the P-CSCF must still include within the AAR (step 5) an indication that the existing filters shall not be removed for the time being. This allows the PCRF to install the new filter description information without removing the existing filters at step 6.
- the P-CSCF Upon expiry of the timer at the P-CSCF (step 14), the P-CSCF sends a further AAR to the PCRF, with the filter information that shall be active and with an indication that only this filter information shall now be active. This causes the PCRF to instruct (step 18) the PCEF to remove the corresponding filter information from existing PCC rules. The PCEF makes finally sure that only the filter description information contained in the AAR in step 14 is active and rest of the previously active filter information is removed from the corresponding bearer (Step 19) (if not previously removed by the UE itself).
- Figure 9 illustrates schematically an AF suitable for use with the alternative procedure of Figure 8.
- the AF is essentially as described above with reference to Figure 5, but with the addition of a timer 20.
- Figure 10 illustrates schematically a PCRF for use with the procedure of Figure 9.
- the PCRF is essentially as described above with reference to Figure 4, but with the timer 10 removed.
- the AF detects session modification and at step 201 identifies a requirement for deferred removal of filters already existing for the session.
- the AF sends an AAR, step 202, to the PCRF and includes an indication of deferred removal.
- the PCRF generates, step 203, the new rules and installs these into the PCEF, step 204.
- the AF initiates a deferred removal timer, and monitors the timer at step 206.
- the AF Upon expiry of the timer, the AF sends a further AAR with updated session information and which does not include the deferred removal request, step 207.
- the PCRF deletes the existing rules from the PCEF.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Apparatus for generating policy and charging rules to control IP flows across a packet switched network. The apparatus comprises a first interface for coupling to an application function and a second interface for coupling to a policy and charging enforcement function implemented at a node through which said IP flows pass. A processor or processors is/are configured to receive service information at said first interface, and, via said second interface to trigger the removal of one or more pre-existing policy and charging rules at the policy and charging enforcement function following a predefined delay.
Description
POLICY AND CHARGING CONTROL ARCHITECTURE
Technical Field
The present invention relates to a policy and charging control architecture and more particularly to such an architecture for use with the IP Multimedia Subsystem.
Background
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end subscribers will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) and ETSI TISPAN group to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7, and TS 24.173 Release 7). IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP -based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a subscriber- to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.
By way of example, Figure 1 illustrates schematically how the IMS fits into the mobile
network architecture in the case of a GPRS/PS access network (IMS can of course operate over other IP access networks, known generically as IP Connectivity Access Networks or IP-CANs). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber and which the subscriber is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
The IMS architecture offers the opportunity to deploy peer-to-peer applications where two or more users exchange user data directly, following SIP session establishment via IMS. Examples of peer-to-peer applications are Multimedia Telephony (MMTeI), Push to Talk over Cellular (PoC), streaming, real-time video sharing, file sharing, gaming etc. The transport connection(s) is(are) negotiated dynamically by means of the SIP/SDP protocol exchange between the two end points.
In order to support peer-to-peer IMS applications, a mechanism is needed to selectively control the IP flows (QoS, Firewalling, multiplexing etc.) associated with an IMS session of a subscriber whilst at the same time allowing the application of appropriate charging schemes. 3GPP has identified such needs and it is currently defining a Policy and Charging Control (PCC) Architecture, TS 23.203. Figure 2 presents a basic outline of the PCC architecture.
Within the PCC architecture, an Application Function (AF) 1 is an element implementing applications that require dynamic policy and/or charging control of traffic plane resources. In the case of the IMS, the P-CSCF plays the role of AF in the SIP signaling plane. The Policy and Charging Enforcement Function (PCEF) 2 provides service data flow detection, charging, and policy enforcement of the user plane traffic. Within a General Packet Radio Service (GPRS) access network, the PCEF is located within a GPRS Gateway Support Node (GGSN). The PCRF is a separate logical node and sits in between of the Application layer (e.g. IMS), where services are initiated and
service characteristics are negotiated, and the user plane where the actual service is being provided. The Policy and Charging Rules Function (PCRF) 3 provides policy and flow-based charging control functions, using subscriber data stored in a Subscription Profile Repository (SPR) 4. The PCRF receives Service Information (e.g. application identifier, type of media, bandwidth, IP address and port number) from the AF over the Rx interface, and uses this to install PCC rules into the PCEF which in turn ensures that only authorized media flows associated with the requested services are allowed, and that the correct bandwidth, charging and priority are applied. The PCEF provides real-time charging information to an Online Charging System (OCS) 5.
The AF may modify Session Information at any time, for example due to an AF session modification or internal AF trigger. Modification is achieved by the AF sending an AA-Request command to the PCRF over the Rx reference point ("reference point" is a term used in 3GPP to identify an information flow between logical functions) containing the Media-Component-Description Attribute- Value Pairs (AVPs), with the updated Service Information as defined in 3GPP TS 29.214. The PCRF processes the received Service Information according to the operator policy and may decide whether the request is accepted or not. If the request is accepted, the PCRF updates the preexisting Service Information with the new information. The updated Service Information may require the PCRF to create, modify or delete the related PCC rules and provide the updated information towards the PCEF over the Gx reference point as specified in 3GPP TS 29.212. The procedures used to update the Authorized QoS for the affected IP-CAN bearer are also specified in 3GPP TS 29.212. Currently specified procedures for modification of the Service Information for PCC provide for the immediate activation, replacement and removal of filter description information at the PCEF.
Summary
It is an object of the present invention to provide a method an apparatus for allowing the deferred removal of IP flow filters at a policy charging and enforcement function.
According to a first aspect of the present invention there is provided apparatus for generating policy and charging rules to control IP flows across a packet switched network. The apparatus comprises a first interface for coupling to an application function and a second interface for coupling to a policy and charging enforcement function implemented at a node through which said IP flows pass. A processor or processors are configured to receive service information at said first interface, and, via said second interface to trigger the removal of one or more pre-existing policy and charging rules at the policy and charging enforcement function following a predefined delay.
This apparatus may be embodied as a standalone logical entity, or may be colocated with some other network entity.
In one embodiment of the invention, said processor or processors is/are configured to initiate a timer upon receipt of said service information and, upon expiry of the timer, to send an instruction to said policy and charging enforcement function via said second interface to delete said pre-existing policy and charging rule(s).
Said processor or processors may be configured to send to said policy and charging enforcement function, via said second interface, an instruction to delete said preexisting policy and charging rule(s) after a delay specified in the instruction.
Said processor or processors may be configured to receive, via said first interface, an explicit request to implement said delay. Said processor or processors may be configured to receive, via said first interface, a delay value.
Said processor or processors may be configured to implement said delay based upon service description characteristics received over said first interface.
Said processor or processors may be configured to (a) install a new set of policy and charging rules into said policy and charging enforcement function in addition to a preexisting set and (b), following said predefined delay, to remove said pre-existing set
from said policy and charging enforcement function. Said processor or processors may be further configured to perform steps (a) and (b) in response to respective requests received from said application function.
According to a second aspect of the present invention there is provided apparatus for implementing an application function to establish and control IP flows across a packet switched network. The apparatus comprises an interface for coupling to a policy and charging rules function, and a processor or processors configured to determine service information relating to an IP flow or flows and to send said service information via said interface together with a request for delayed deletion of a policy and charging control rule or rules relating to said flow(s).
According to an embodiment of the second aspect of the invention, said processor or processors may be configured to send a delay value together with said service information and said explicit request.
Said processor or processors may be configured to include said service information and said explicit request, and optionally said delay value, within a Session Description Protocol offer. Said processor or processors may be configured to include said explicit request within said offer as an AVP.
The apparatus of the above second aspect of the invention may be configured to operate as a Proxy Call Session Control Function within an IP Multimedia Subsystem.
According to a third aspect of the present invention there is provided apparatus for implementing an application function to establish and control IP flows across a packet switched network. The apparatus comprises an interface for coupling to a policy and charging rules function, and a processor or processors configured to determine service information relating to an IP flow or flows and to send said service information via said interface together with a request to maintain an existing policy and charging control rule or rules relating to said flow(s), and, after a predefined delay, to send a further request to delete said existing policy and charging control rule or rules.
According to a fourth aspect of the present invention there is provided apparatus for implementing a policy and charging enforcement function in respect of IP flows through a packet switched network. The apparatus comprises an interface for coupling to a policy and charging rules function, and a processor or processors configured to receive via said interface an instruction to remove a policy and charging rule or rules relating to an IP flow or flows, to initiate a timer upon receipt of said instruction, and upon expiry of said timer to remove said rule(s).
The apparatus of the fourth aspect of the present invention may be configured to operate as a GPRS Gateway Support Node within a GPRS packet switched network.
According to a fifth aspect of the present invention there is provided a method of controlling IP flows through a packet switched access network. The method comprises sending updated service information from an application function to a policy and charging rules function. At the policy and charging rules function, a determination is made that a policy and charging rule or rules must be removed from a policy and charging enforcement function responsible for an IP flow or flows associated with the session. The policy and charging rule or rules are removed after a predefined delay.
According to one embodiment, following a determination that a policy and charging rule or rule must be removed from a policy and charging enforcement function, a timer is initiated at the policy and charging rules function and, upon expiry of said timer, an instruction sent to said policy and charging enforcement function to remove said policy and charging rule or rules.
Alternatively, following a determination that a policy and charging rule or rule must be removed from a policy and charging enforcement function, an instruction is sent to said policy and charging enforcement function to remove said policy and charging rule or rules after a predefined delay, a delay value being included with the instruction.
According to a still further alternative, a timer is initiated at said application function
and, following expiry of said timer, further service information sent to said policy and charging rules function, receipt of the further service information resulting in the removal of said policy and charging rule or rules.
It will be understood that said policy and charging rules function is arranged to make separate determinations for rule(s) removal for uplink and downlink IP flows.
Reference above to service information means information including filter information, e.g. IP source and destination IP addresses and port numbers. The service information may additionally comprise an identification of required codecs, bandwidth, etc.
According to a sixth aspect of the present invention there is provided a method of controlling IP flows through a packet switched access network. The method comprises sending updated filter information from an application function to a policy and charging rules function together with a request to maintain existing filter information relating to said IP flows. At said policy and charging rules function, a new policy and charging rule(s) are determined using said updated filter information and the addition of said rules at a policy and charging enforcement function is triggered whilst maintaining said existing filter information. After a predefined delay, a request is sent from said application function to said policy and charging rules function with previously provided updated filter information and an indication that only this filter information shall remain active. Said existing filter information is deleted at the policy and charging enforcement function, and corresponding bearers also deleted.
A particular use case of the above method is where the IP flow being controlled is an IP media flow between two or more user entities, UEs.
Brief Description of the Drawings
Figure 1 illustrates schematically components of an IP Multimedia Subsystem overlayed on a packet switched access network; Figure 2 illustrates schematically a Policy and Charging Control Architecture;
Figure 3 illustrates signalling associated with a procedure for installing and removing
PCC rules from a PCEF;
Figure 4 illustrates schematically a PCRF according to an embodiment of the present invention; Figure 5 illustrates schematically an AF according to an embodiment of the present invention;
Figure 6 illustrates schematically a PCEF according to an embodiment of the present invention;
Figure 7 is a flow diagram illustrating two alternative procedures for applying Policy and Charging Control.
Figures 8A and 8B illustrate signalling associated with an alternative procedure for installing and removing PCC rules from a PCEF;
Figure 9 illustrates schematically an AF for use with the procedure illustrated in Figure
8; Figure 10 illustrates schematically a PCRF for use with the procedure illustrated in
Figure 8; and
Figure 11 is a flow diagram further illustrating the procedure of Figure 8.
Detailed Description
Considering once again the PCC architecture of Figure 2, it has already been noted that current specifications require the immediate activation, replacement and removal of filter description information at the PCEF once the AF delivers modified Service Information to the PCRF. That is, if the AF modifies Service Information to provide "new" filter information, the "existing" filter information installed in the PCEF is replaced immediately with the new filter information. IP packets received by the PCEF that match the "existing" filter information will be discarded. Similarly, if the AF modifies Service Information to delete "existing" filter information, this information will be removed from the corresponding PCC rules (the PCC rule itself may be removed) immediately. IP packets matching "existing" filter information will be discarded with immediate effect.
Scenarios are envisaged however in which, upon modification of the Service Information by the AF to replace or to remove "existing" filter information, it is undesirable to delete the existing filter information immediately. For example, in the case of TCP-negotiated media over SDP as defined in IETF RFC 4145, the endpoints may negotiate the reestablishment of an "existing" TCP connection. This may occur during a single SIP session over IMS. It is likely that the new TCP connection is established using different port numbers, so the filter information provided previously to the PCRF must be updated.
It is proposed here to activate the filter information corresponding to the new TCP connection immediately, but at the same time to maintain the existing filter information at least for some time to allow the endpoints to gracefully terminate the existing TCP connection, providing for an enhanced user service. The existing filters remain in place to let the associated TCP packets through until either the UE itself requests the removal of the existing filters (which is possible when UE initiated bearer control mode is used), or until a network-controlled safeguard time period has elapsed (which is used regardless of the bearer control mode between the UE and the PCEF as well as when bearer control procedures are not used at all). The safeguard time is determined by the network and is set to a value that will allow the endpoints to gracefully terminate the "existing" TCP connection. In the case of UE initiated bearer control procedures, the safeguard time sets a limit for the UE to remove the filters itself, thus protecting the network from a potentially fraudulent UE which does not remove the filters.
Figure 3 presents an overall description of a method for the deferred removal of existing filter information in the PCEF. This relates by way of example to the reestablishment of an existing TCP connection. In this context, it is assumed that an existing TCP connection has been established between two endpoints (UEs) and for which corresponding filters and PCC rules are active within the IP-CAN (step 0 in Figure 3).
The endpoints then negotiate the re-establishment of this TCP connection by exchanging SDP offer and SDP answer messages via P-CSCF of the IMS (step 1-3 and
7). In this case, the AF of the PCC architecture resides in the P-CSCF.
If available (i.e. "new, active/passive" within SDP answer), the P-CSCF provides updated filter information to the PCRF for the establishment of the new TCP connection. It does this using the Diameter AAR message (step 4). Otherwise (i.e. "new, holdconn" within the SDP answer) the P-CSCF requests the removal of existing filter information in order to block the existing TCP connection. The P-CSCF additionally includes a request for deferred removal of existing filter information.
An explicit indication that deferred removal of existing filter information is required may be in the form of a new "Deferred-Removal- Timer-UL/DL" AVP contained within the AAR message. The Deferred-Removal-Timer-UL/DL AVP may be of type Unsigned32, and may indicate the value for the timer, e.g. in seconds or milliseconds. This AVP is only used when the AF (P-CSCF) requests replacement of existing filter information with new information (i.e. updated filter information is provided within the Flow-Description AVP) or when the AF requests removal of existing filter information without providing new information (i.e. Flow- Status AVP is set to the value 'REMOVED'). If the AF does not include this AVP, the existing filter information (if available) is removed immediately (i.e. the default value for this timer is zero if this AVP is not provided by the AF). If the AF includes this AVP but existing filter information is not available for the corresponding flows, the PCRF ignores the AVP.
It is noted that, as the timers for deferred removal of uplink (UL) and downlink (DL) filter information may be different, two separate AVPs may be defined and included within the AAR sent from the P-CSCF to the PCRF.
The Deferred-Removal-Timer-UL/DL may be included at Media Component level as illustrated in Table 1 below, or at the Media Subcomponent level as illustrated in Table
2.
Upon receipt of the AAR message from the P-CSCF, the PCRF starts the deferred- removal timer (step 5) and responds to the P-CSCF with a Diameter AAA message
(step 6). If new filter information was provided in the request, the PCRF creates PCC rules for the new filter information and installs these into the PCEF (step 8). To
generate the new rules, the PCRF may contact the SPR (see Figure 2).
Rather than implement the delay timer at the PCRF, the PCRF may request that the PCEF initiate the timer and remove the PCC rules for the existing filter information upon expiry of the timer. This approach may indeed be optimal where a single message from the PCRF is used to install both new rules and trigger the delayed removal of the existing rules.
IP flows matching the existing filter information will be accepted at the PCEF prior to expiry of the timer as the corresponding PCC rules will not yet have been removed from the PCEF. This provides a transition period during which the end points can gracefully terminate the existing TCP connection (step 9). When the deferred removal timer expires (step 10), the IP-CAN will remove the corresponding PCC rules for the existing filter. The corresponding bearer resources will be also be released (step 11) and IP flows matching the existing filters will no longer be accepted.
It is possible that the UE may itself request the removal of existing filter information after graceful termination of the existing TCP connection (step 10' replacing steps 10 and 11), in which case the IP-CAN will remove the existing filter information and corresponding PCC rule(s) (step 10') and will stop the deferred removal timer (running in either the PCRF or PCEF) (step 11 ').
An alternative to including an explicit deferral request in the AAR is to configure the IP-CAN to trigger the deferred removal of existing filter information based on certain service description characteristics as currently provided by the AF. For example, the PCRF may decide to trigger the deferred removal of existing filter information based on a protocol defined within the filter information itself (e.g. proto = TCP). This option does not impact on the current definition of the Rx reference point although the Deferred-Removal-Timer is configured locally at the PCRF.
Considering this alternative approach in more detail, when the AF requests the removal of existing filter information, the PCRF will start the Deferred-Removal-Timer-UL/DL.
The PCC rule(s) for the IP flows matching the existing filter information are kept active whilst the timer is running (i.e. corresponding IP flows, e.g. over an existing TCP connection, will be accepted). If the AF provided new filter information to replace the existing information, new filters will be installed and activated at the PCEF over the Gx reference point, either within the same PCC rule(s) defining the existing filters or within a new PCC rule(s).
When the Deferred-Removal-Timer-UL/DL expires, the PCRF proceeds to remove the existing filter information. The PCRF removes the existing filter information from the PCC rules where they were defined (most probably the PCC rule itself will be removed). The corresponding bearer resources will be released and the IP flows matching the existing filter information will no longer be accepted.
With reference to Figure 4, there is illustrated apparatus 6 for implementing a PCRF in the case where the PCRF implements the delay timer. The apparatus comprises a first interface 7 connected to the Rx reference point, and a second interface 8 connected to the Gx interface. A processor or processors 9 is responsible for receiving and handling
Service Information received over the Rx interface, and for sending Policy and
Charging Control Information out over the Gx interface. The processor(s) determines based upon explicit indications in the Service Information, or based upon service session characteristics, that a delay is to be implemented. If so, a timer 10 is initiated as described above.
Figure 5 illustrates schematically apparatus 11 for implementing an AF. This apparatus could comprise a P-CSCF of an IMS network. The apparatus 11 comprises an interface 12 coupled to the Rx reference point, and a processor or processors 13 for generating Service Information based upon requirements of IMS subscribers. In particular, the processor(s) may include an explicit request for rule removal delay within the Service Information.
Figure 6 illustrates schematically apparatus 14 for implementing a PCEF in the case where the timer is implemented at the PCEF. The apparatus comprises an interface 15
coupled to the Gx reference point. A processor or processors 16 handles incoming PCC rule related instructions. PCC rules are maintained in a PCC rules database 18. A timer is implemented at entity 17.
Figure 7 is a flow diagram illustrating two alternative PCC mechanisms as described above. Common to both mechanisms are the steps of detecting session modification at the AF (step 100), sending modified Service Information from the AF to the PCRF (step 101), receiving the modified Service Information at the PCRF and generating any new Policy and Charging Control Information (step 102), and immediately installing the new PCC information at the PCEF (step 103). Option A is followed when the timer is implemented at the PCRF (step 104). The timer is checked (step 105), and upon expiry the PCRF sends an IP filter removal instruction to the PCEF (step 106). The PCEF responds by removing the appropriate IP filter(s) from its rules database (step 107). Option B is followed when the delay timer is implemented at the PCEF. The PCRF immediately sends the IP filter removal instruction to the PCEF (step 104'), together with the new rule, i.e. steps 103 and 104' may be implemented using the same message of the Gx reference point. The PCEF initiates a delay timer with appropriate delay value (step 105'), The timer is checked (step 106'), and upon expiry the existing IP filters are removed (step 107').
Turning now to the signalling flow illustrated in Figures 8A and 8B, there is illustrated yet another alternative PCC mechanism. Steps common to the flow of Figure 3 will not be described in detail. The main difference lies in the fact that, according to the further alternative procedure, the deferred filter removal timer is implemented at the AF, i.e. P- CSCF. The P-CSCF determines the need to implement the timer at step 4, with the timer actually being initiated at step 10 (or earlier). The P-CSCF must still include within the AAR (step 5) an indication that the existing filters shall not be removed for the time being. This allows the PCRF to install the new filter description information without removing the existing filters at step 6. Upon expiry of the timer at the P-CSCF (step 14), the P-CSCF sends a further AAR to the PCRF, with the filter information that shall be active and with an indication that only this filter information shall now be active. This causes the PCRF to instruct (step 18) the PCEF to remove the
corresponding filter information from existing PCC rules. The PCEF makes finally sure that only the filter description information contained in the AAR in step 14 is active and rest of the previously active filter information is removed from the corresponding bearer (Step 19) (if not previously removed by the UE itself).
Turning now to Figure 9, this illustrates schematically an AF suitable for use with the alternative procedure of Figure 8. The AF is essentially as described above with reference to Figure 5, but with the addition of a timer 20. Figure 10 illustrates schematically a PCRF for use with the procedure of Figure 9. The PCRF is essentially as described above with reference to Figure 4, but with the timer 10 removed.
Considering now the flow diagram of Figure 11, this further illustrates the procedure of Figure 8. At step 200, the AF detects session modification and at step 201 identifies a requirement for deferred removal of filters already existing for the session. The AF sends an AAR, step 202, to the PCRF and includes an indication of deferred removal. The PCRF generates, step 203, the new rules and installs these into the PCEF, step 204. At step 205, the AF initiates a deferred removal timer, and monitors the timer at step 206. Upon expiry of the timer, the AF sends a further AAR with updated session information and which does not include the deferred removal request, step 207. At step 208, the PCRF deletes the existing rules from the PCEF.
Media-Component-Description ::= < AVP Header: 517 >
{ Media-Component-Number } ; Ordinal number of the media comp . * [ Media-Sub-Component ] ; Set of flows for one flow id [ AF-Application-Identifier ]
[ Media-Type ]
[ Max-Requested-Bandwidth-UL ] [ Max-Requested-Bandwidth-DL ] [ Flow-Status ] [Deferred-Removal-Timer-UL] [Deferred-Removal-Timer-DL] [ Reservation-priority ] [ RS-Bandwidth ] [ RR-Bandwidth ] * [ Codec-Data ]
Table 1
Media-Sub-Component ::= < AVP Header: 519 >
{ Flow-Number } ; Ordinal number of the IP flow
0*2 [ Flow-Description ] ; UL and/or DL
[Deferred-Removal-Timer-UL] [Deferred-Removal-Timer-DL]
[ Flow-Status ]
[ Flow-Usage ]
[ Max-Requested-Bandwidth-UL ]
[ Max-Requested-Bandwidth-DL ] [ AVP ]
Table 2
Claims
1. Apparatus for generating policy and charging rules to control IP flows across a packet switched network and comprising: a first interface for coupling to an application function; a second interface for coupling to a policy and charging enforcement function implemented at a node through which said IP flows pass; and a processor or processors configured to receive service information at said first interface, and, via said second interface to trigger the removal of one or more pre-existing policy and charging rules at the policy and charging enforcement function following a predefined delay.
2. Apparatus according to claim 1, wherein said processor or processors is/are configured to initiate a timer upon receipt of said service information and, upon expiry of the timer, to send an instruction to said policy and charging enforcement function via said second interface to delete said pre-existing policy and charging rule(s).
3. Apparatus according to claim 1, wherein said processor or processor is/are configured to send to said policy and charging enforcement function, via said second interface, an instruction to delete said pre-existing policy and charging rule(s) after a delay specified in the instruction.
4. Apparatus according to any one of the preceding claims, wherein said processor or processors is/are configured to receive, via said first interface, an explicit request to implement said delay.
5. Apparatus according to claim 4, wherein said processor or processors is/are configured to receive, via said first interface, a delay value.
6. Apparatus according to any one of claims 1 to 3, wherein said processor or processors is/are configured to implement said delay based upon service description characteristics received over said first interface.
7. Apparatus according to any one of the preceding claims, wherein said first interface is an interface to an Rx reference point, and said second interface is an interface to a Gx reference point.
8. Apparatus according to claim 7, said processor or processors being configured to receive said service information within a Session Description Protocol offer.
9. Apparatus according to claim 1 , said processor or processors being configured to (a) install a new set of policy and charging rules into said policy and charging enforcement function in addition to a pre-existing set and (b), following said predefined delay, to remove said pre-existing set from said policy and charging enforcement function.
10. Apparatus according to claim 9, said processor or processors being configured to perform steps (a) and (b) in response to respective requests received from said application function.
11. Apparatus for implementing an application function to establish and control IP flows across a packet switched network, the apparatus comprising: an interface for coupling to a policy and charging rules function; and a processor or processors configured to determine service information relating to an IP flow or flows and to send said service information via said interface together with a request for delayed deletion of a policy and charging control rule or rules relating to said flow(s).
12. Apparatus according to claim 11, said processor or processors being configured to send a delay value together with said service information and said explicit request.
13. Apparatus according to 11 or 12, wherein said interface is an interface to an Rx reference point.
14. Apparatus according to claim 13, said processor or processors being configured to include said service information and said explicit request, and optionally said delay value, within a Session Description Protocol offer.
15. Apparatus according to claim 14, wherein said processor or processors are configured to include said explicit request within said offer as an AVP.
16. Apparatus according to any one of claims 11 to 15, the apparatus being configured to operate as a Proxy Call Session Control Function within an IP Multimedia
Subsystem.
17. Apparatus for implementing an application function to establish and control IP flows across a packet switched network, the apparatus comprising: an interface for coupling to a policy and charging rules function; and a processor or processors configured to determine service information relating to an IP flow or flows and to send said service information via said interface together with a request to maintain an existing policy and charging control rule or rules relating to said flow(s), and, after a predefined delay, to send a further request to delete said existing policy and charging control rule or rules.
18. Apparatus for implementing a policy and charging enforcement function in respect of IP flows through a packet switched network, the apparatus comprising an interface for coupling to a policy and charging rules function; and a processor or processors configured to receive via said interface an instruction to remove a policy and charging rule or rules relating to an IP flow or flows, to initiate a timer upon receipt of said instruction, and upon expiry of said timer to remove said rule(s).
19. Apparatus according to claim 18, said interface being an interface to a Gx reference point.
20. Apparatus according to claim 18 or 19 and configured to operate as a GPRS Gateway Support Node within a GPRS packet switched network.
21. A method of controlling IP flows through a packet switched access network, the method comprising: sending updated service information from an application function to a policy and charging rules function; at the policy and charging rules function, determining that a policy and charging rule or rules must be removed from a policy and charging enforcement function responsible for an IP flow or flows associated with the session; and triggering the removal of said policy and charging rule or rules after a predefined delay.
22. A method according to claim 21, wherein said service information is sent via an Rx reference point.
23. A method according to claim 21 or 22 and comprising, following a determination that a policy and charging rule or rule must be removed from a policy and charging enforcement function, initiating a timer at the policy and charging rules function and, upon expiry of said timer, sending an instruction to said policy and charging enforcement function to remove said policy and charging rule or rules.
24. A method according to claim 21 or 22 and comprising, following a determination that a policy and charging rule or rule must be removed from a policy and charging enforcement function, sending an instruction to said policy and charging enforcement function to remove said policy and charging rule or rules after a predefined delay, a delay value being included with the instruction.
25. A method according to claim 23 or 24, said instruction being sent via a Gx reference point.
26. A method according to claim 21 or 22, and comprising initiating a timer at said application function and, following expiry of said timer, sending further service information to said policy and charging rules function, receipt of the further service information resulting in the removal of said policy and charging rule or rules.
27. A method according to any one of claims 21 to 26, wherein said application function is implemented at a Proxy Call Session Control Function of an IP Multimedia Subsystem, and said policy and charging enforcement function is implemented at a GPRS Gateway Support Node.
28. A method according to any one of claims 21 to 27, said policy and charging rules function being arranged to make separate determinations for rule(s) removal for uplink and downlink IP flows.
29. A method of controlling IP flows through a packet switched access network, the method comprising: sending updated filter information from an application function to a policy and charging rules function together with a request to maintain existing filter information relating to said IP flows; at said policy and charging rules function, determining a new policy and charging rule(s) using said updated filter information and triggering the addition of said rules at a policy and charging enforcement function whilst maintaining said existing filter information; after a predefined delay, sending a request from said application function to said policy and charging rules function with previously provided updated filter information and an indication that only this filter information shall remain active; and deleting said existing filter information at the policy and charging enforcement function, and deleting corresponding bearers.
30. A method according to claim 29, wherein the IP flow being controlled is an IP media flow between two or more user entities.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AT08735471T ATE541385T1 (en) | 2008-03-25 | 2008-03-25 | POLICY AND WITHDRAWAL TAX ARCHITECTURE |
PCT/EP2008/053509 WO2009118038A1 (en) | 2008-03-25 | 2008-03-25 | Policy and charging control architecture |
EP08735471A EP2258076B1 (en) | 2008-03-25 | 2008-03-25 | Policy and charging control architecture |
US12/934,217 US20110022722A1 (en) | 2008-03-25 | 2008-03-25 | Policy and charging control architecture |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2008/053509 WO2009118038A1 (en) | 2008-03-25 | 2008-03-25 | Policy and charging control architecture |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2009118038A1 true WO2009118038A1 (en) | 2009-10-01 |
Family
ID=40568789
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2008/053509 WO2009118038A1 (en) | 2008-03-25 | 2008-03-25 | Policy and charging control architecture |
Country Status (4)
Country | Link |
---|---|
US (1) | US20110022722A1 (en) |
EP (1) | EP2258076B1 (en) |
AT (1) | ATE541385T1 (en) |
WO (1) | WO2009118038A1 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110201303A1 (en) * | 2010-02-18 | 2011-08-18 | Alcatel-Lucent Canada Inc. | Method of handling a change to bearer control mode |
US20110320584A1 (en) * | 2010-06-25 | 2011-12-29 | Alcatel-Lucent Canada, Inc. | Method for determining a pcc rule waiting for pcef action |
CN102598633A (en) * | 2009-11-20 | 2012-07-18 | 瑞典爱立信有限公司 | Controlling packet filter installation in a user equipment |
CN106304413A (en) * | 2015-05-26 | 2017-01-04 | 成都鼎桥通信技术有限公司 | A kind of delet method of RX interface session |
EP2534788A4 (en) * | 2010-02-12 | 2017-01-25 | Tekelec, Inc. | Methods, systems, and computer readable media for service detection over an rx interface |
WO2018064826A1 (en) * | 2016-10-09 | 2018-04-12 | Nokia Solutions And Networks Oy | Sdci pull and push mode optimization |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102160452B (en) * | 2008-06-05 | 2015-02-04 | 凯敏公司 | Method and system for providing mobility management in network |
US8813168B2 (en) * | 2008-06-05 | 2014-08-19 | Tekelec, Inc. | Methods, systems, and computer readable media for providing nested policy configuration in a communications network |
US8640188B2 (en) * | 2010-01-04 | 2014-01-28 | Tekelec, Inc. | Methods, systems, and computer readable media for providing group policy configuration in a communications network using a fake user |
JP2012507223A (en) * | 2008-10-31 | 2012-03-22 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | Policy and accounting control method, server, and computer program |
CN101771678B (en) * | 2008-12-31 | 2014-04-16 | 华为技术有限公司 | Method and device for managing or triggering view |
DK2782388T3 (en) * | 2009-03-23 | 2016-08-22 | ERICSSON TELEFON AB L M (publ) | A method and device for linking leg exposed in the PCRF by handover |
CN101959164A (en) * | 2009-07-17 | 2011-01-26 | 中兴通讯股份有限公司 | Method and system for deleting redundant information of home policy and charging rule function |
EP2296309B1 (en) | 2009-09-11 | 2012-10-31 | Alcatel Lucent | A method for delivering policy rules to an end user, according on his/her account balance and service subscription level, in a telecommunication network |
US8457114B2 (en) * | 2009-09-28 | 2013-06-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Method to optimize call establishment in mobile satellite communication systems |
US8787174B2 (en) * | 2009-12-31 | 2014-07-22 | Tekelec, Inc. | Methods, systems, and computer readable media for condition-triggered policies |
EP2343853A1 (en) * | 2010-01-07 | 2011-07-13 | Alcatel Lucent | Method and system for dynamically controlling the quality of service |
CN102893640B (en) * | 2010-03-15 | 2016-03-23 | 泰克莱克股份有限公司 | For the method for transmission policy information between "Policy and Charging Rules Function and service node, system and computer-readable medium |
US9319318B2 (en) * | 2010-03-15 | 2016-04-19 | Tekelec, Inc. | Methods, systems, and computer readable media for performing PCRF-based user information pass through |
US8549116B2 (en) * | 2010-05-05 | 2013-10-01 | Alcatel Lucent | PCRF triggered rules cleanup |
US8473546B2 (en) * | 2010-05-28 | 2013-06-25 | Alcatel Lucent | Minimizing PCC rule instantiation latency |
EP2578009A1 (en) * | 2010-05-28 | 2013-04-10 | Telefonaktiebolaget LM Ericsson (publ) | Flow mobility filter rule verification |
US8869307B2 (en) * | 2010-11-19 | 2014-10-21 | Mobile Iron, Inc. | Mobile posture-based policy, remediation and access control for enterprise resources |
US9450766B2 (en) * | 2011-04-26 | 2016-09-20 | Openet Telecom Ltd. | Systems, devices and methods of distributing telecommunications functionality across multiple heterogeneous domains |
EP2523389A3 (en) * | 2011-05-09 | 2014-07-30 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus for authorizing a transactional service by a Policy and Charging Control architecture |
CN103548369B (en) * | 2011-06-09 | 2017-07-21 | 松下电器(美国)知识产权公司 | Network node, terminal, bandwidth change determination methods and bandwidth variation |
US8949413B2 (en) * | 2011-06-30 | 2015-02-03 | Juniper Networks, Inc. | Filter selection and resuse |
US9055557B1 (en) | 2012-03-26 | 2015-06-09 | Juniper Networks, Inc. | Policy and charging control rule programming and lookup in wireless connectivity access networks |
US9300695B2 (en) * | 2012-05-29 | 2016-03-29 | Alcatel Lucent | Method and apparatus for manipulating AVPs in a diameter routing agent |
KR101458302B1 (en) | 2013-04-04 | 2014-11-04 | 주식회사 엘지유플러스 | Apparatus, Method, and Recording Medium for generating PCC rule in Mobile Communication System |
CN104104520A (en) * | 2013-04-10 | 2014-10-15 | 华为技术有限公司 | Charging method and system based on OPenFlow protocol |
US10171548B2 (en) * | 2014-08-26 | 2019-01-01 | Mavenir Systems, Inc. | Method and system for efficient enrichment of upper layer protocol content in transmission control program (TCP) based sessions |
EP3232637A4 (en) * | 2015-01-09 | 2018-01-03 | Huawei Technologies Co., Ltd. | Network entity and service policy management method |
CN107078946B (en) * | 2015-09-30 | 2020-09-08 | 华为技术有限公司 | Method, device and system for processing service flow processing strategy |
CN106789117A (en) * | 2015-11-19 | 2017-05-31 | 中兴通讯股份有限公司 | The processing method and processing device of PCC rules |
EP3520444B1 (en) * | 2016-09-29 | 2021-03-31 | Nokia Solutions and Networks Oy | Enhancement of traffic detection and routing in virtualized environment |
CN108234406A (en) * | 2016-12-15 | 2018-06-29 | 中兴通讯股份有限公司 | A kind of methods, devices and systems of resource management |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20070107619A (en) * | 2006-05-03 | 2007-11-07 | 한국전자통신연구원 | A method for random access in cellular system |
ATE484937T1 (en) * | 2006-05-17 | 2010-10-15 | Research In Motion Ltd | METHOD AND SYSTEM FOR DISPLAYING A CAUSE FOR A DISCONNECT OF A SIGNALING CONNECTION IN A UMTS NETWORK |
US8856860B2 (en) * | 2006-08-18 | 2014-10-07 | Cisco Technology, Inc. | System and method for implementing policy server based application interaction manager |
US8121049B2 (en) * | 2006-11-29 | 2012-02-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for controlling service level agreements in a mobile network |
EP1933520A1 (en) * | 2006-12-15 | 2008-06-18 | Matsushita Electric Industrial Co., Ltd. | Local mobility anchor relocation and route optimization during handover of a mobile node to another network area |
-
2008
- 2008-03-25 WO PCT/EP2008/053509 patent/WO2009118038A1/en active Application Filing
- 2008-03-25 EP EP08735471A patent/EP2258076B1/en not_active Not-in-force
- 2008-03-25 AT AT08735471T patent/ATE541385T1/en active
- 2008-03-25 US US12/934,217 patent/US20110022722A1/en not_active Abandoned
Non-Patent Citations (2)
Title |
---|
3RD GENERATION PARTNERSHIP PROJECT: "Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 7)", 3RD GENERATION PARTNERSHIP PROJECT, 1 March 2008 (2008-03-01) - 1 March 2008 (2008-03-01), pages 1 - 46, XP002526081, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Specs/archive/29_series/29.212/> [retrieved on 20090429] * |
3RD GENERATION PARTNERSHIP PROJECT: "Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 7)", 3RD GENERATION PARTNERSHIP PROJECT, 1 December 2007 (2007-12-01) - 1 December 2007 (2007-12-01), pages 1 - 72, XP002526082, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Specs/html-info/23203.htm> [retrieved on 20090429] * |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8787399B2 (en) | 2009-11-20 | 2014-07-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Controlling packet filter installation in a user equipment |
CN102598633B (en) * | 2009-11-20 | 2015-09-09 | 瑞典爱立信有限公司 | The packet filter controlled in subscriber equipment is installed |
CN102598633A (en) * | 2009-11-20 | 2012-07-18 | 瑞典爱立信有限公司 | Controlling packet filter installation in a user equipment |
JP2013511871A (en) * | 2009-11-20 | 2013-04-04 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | Packet filter installation control on user equipment |
EP2502401B1 (en) * | 2009-11-20 | 2013-11-06 | Telefonaktiebolaget LM Ericsson (publ) | Controlling packet filter installation in a user equipment |
EP2709338A1 (en) * | 2009-11-20 | 2014-03-19 | Telefonaktiebolaget L M Ericsson AB (Publ) | Controlling packet filter installation in a user equipment |
US8750322B2 (en) | 2009-11-20 | 2014-06-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Controlling packet filter installation in a user equipment |
EP2534788A4 (en) * | 2010-02-12 | 2017-01-25 | Tekelec, Inc. | Methods, systems, and computer readable media for service detection over an rx interface |
US20110201303A1 (en) * | 2010-02-18 | 2011-08-18 | Alcatel-Lucent Canada Inc. | Method of handling a change to bearer control mode |
US8768295B2 (en) * | 2010-02-18 | 2014-07-01 | Alcatel Lucent | Method of handling a change to bearer control mode |
US20110320584A1 (en) * | 2010-06-25 | 2011-12-29 | Alcatel-Lucent Canada, Inc. | Method for determining a pcc rule waiting for pcef action |
US8954565B2 (en) * | 2010-06-25 | 2015-02-10 | Alcatel Lucent | Method and system for determining a PCC rule waiting for further action |
CN106304413A (en) * | 2015-05-26 | 2017-01-04 | 成都鼎桥通信技术有限公司 | A kind of delet method of RX interface session |
CN106304413B (en) * | 2015-05-26 | 2019-10-22 | 成都鼎桥通信技术有限公司 | A kind of delet method of RX interface session |
WO2018064826A1 (en) * | 2016-10-09 | 2018-04-12 | Nokia Solutions And Networks Oy | Sdci pull and push mode optimization |
US10708730B2 (en) | 2016-10-09 | 2020-07-07 | Nokia Solutions And Networks Oy | SDCI pull and push mode optimization |
Also Published As
Publication number | Publication date |
---|---|
US20110022722A1 (en) | 2011-01-27 |
EP2258076A1 (en) | 2010-12-08 |
EP2258076B1 (en) | 2012-01-11 |
ATE541385T1 (en) | 2012-01-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2258076B1 (en) | Policy and charging control architecture | |
CA2685499C (en) | Policy control in a network | |
EP2624503B1 (en) | Policy and charging control user terminal | |
US10154151B2 (en) | Methods and apparatus for implementing policy and charging control | |
US8572258B2 (en) | Control of quality-of-service preconditions in an IP multimedia subsystem | |
US8640186B2 (en) | Pre-authorization of bearer set-up | |
US20140153391A1 (en) | Method for Policy Control and Method for Bearer Control as Well as Corresponding Servers, Systems and Computer Programs | |
US10326605B2 (en) | Policy control in session initiation protocol forking | |
EP1665629B1 (en) | Charging for multimedia services | |
EP2406928B1 (en) | Traffic control by ip multimedia subsystem | |
EP3125591B1 (en) | Policy control and processing method and device | |
WO2011036649A1 (en) | Method to optimize call establishment in mobile satellite communication systems | |
US8185637B2 (en) | Control of session parameter negotiation for communication connection | |
EP2596660B1 (en) | Gating control in a telecommunications network | |
WO2009121403A1 (en) | Method and apparatus for distinguishing ip flows | |
Zoric et al. | QoS architecture in IP multimedia subsystem of UMTS |
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: 08735471 Country of ref document: EP Kind code of ref document: A1 |
|
DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 6197/DELNP/2010 Country of ref document: IN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2008735471 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 12934217 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |