WO2012065657A1

WO2012065657A1 - A method for policy and charge control over data flows in a gx-enabled network

Info

Publication number: WO2012065657A1
Application number: PCT/EP2011/004040
Authority: WO
Inventors: Maria Dolores Vallecillo Alvarez; Maria Antonia Lopez Ajenjo
Original assignee: Telefonica, S.A.
Priority date: 2010-11-19
Filing date: 2011-08-11
Publication date: 2012-05-24
Also published as: ES2382855A1; AR083664A1; ES2382855B1

Abstract

A method for policy and charge control over data flows in a Gx-enabled network Comprises dynamically provisioning PCC rules from a PCRF to a PCEF, over a Gx interface by applying AVPs, and carrying out the next steps: - requesting, the PCRF to the PCEF, to be notified by the latter about the detection of data flows for one or more specific services, indicated by the PCRF or predefined in the PCEF, and - detecting, by means of the PCEF, data flows for the one or more indicated specific services and notifying said detection to the PCRF. Said steps are carried out by generating one or more new AVPs and/or including one or more new values into a known AVP, and applying the obtained AVP through said Gx interface.

Description

A method for policy and charge control over data flows in a Gx-enabled network

Field of the art

The present invention generally relates to a method for policy and charge control over data flows in a Gx-enabled network, and particularly to a method enabling the notification from PCEF to PCRF regarding the detection of a certain service data flow, by generating a new AVP and/or including a new value into a known AVP, and applying the obtained AVP through a Gx interface. Prior State of the Art

Policy and Charging Control for IP service environment has evolved to accommodate more and more complex functions. At the beginning, policies to be evaluated and enforced were simple (e.g. access control to Internet or a corporate network), static (i.e. previously provisioned in the enforcement points) and granularity hardly covered policy per service or per subscriber.

Several standardization foras have defined different approaches to solve the same problem: provide service and user aware dynamic policy and charging control over the access network. For those access technologies with limited bandwidth resources, such as Mobile Broadband access, the suitable management of QoS is a key issue. The most commonly adopted specification regarding Mobile Broadband QoS control is 3GPP TS 23.203 "Policy and Charging and Control Architecture" (PCC).

PCC allows charging control (online and offline) and policy control over data flows. Although at the beginning it was focus on 3G access networks, in the last releases it also provides recommendations to other wireless technologies, such as WiFi and WiMax.

As shown by Figure 1 , PCC architecture is mainly compounded of a central node,

PCRF (Policy and Charging Rules Function) acting as a policy decision point able to evaluate the suitable rule to enforce in PCEF (Policy and Charging Enforcement Function) in the access/transport layers via Gx interface. Besides that, PCRF will receive QoS reservation requests from AF (Application Function) via Rx interface. In this sense, PCRF links the application layer and the access/transport layer, guaranteeing the authorized QoS.

Typically, in the Mobile Broadband access, PCEF role will be performed by a GGSN (Gateway GPRS Support Node). Other option is a DPI (Deep Packet Inspection) platform that could be inserted in line with other access/transport nodes to perform a specialized traffic analysis, using either static methods based on well known service data flow information, such as IP address and port number, or heuristic methods based on algorithms able to identify level 7 protocols, such as P2P. DPI nodes are often able to control service data flow QoS per subscriber and per service as instructed by a PCRF.

For IMS sessions, the role of AF will be usually performed by a P-CSCF (Proxy Call Session Control Function) or an SBC (Service Border Controller). The AF function is optional in PCC architecture, in the sense that service data flow control could be enforced without any application layer interaction.

PCRF may receive as input for the policy evaluation, information from PCEF, from AF (if it is part of the scenario) and from SPR (Subscriber Profile Repository), that contains information regarding the subscriber, such as allowed service, QoS parameters and subscriber category. Based on these, the PCRF will decide the PCC Rules that apply to each case and it will push it to the PCEF.

There are three flavours of PCC Rule:

^■ Dynamic PCC Rule, generated on the fly based on the evaluation process and pushed to the PCEF by the PCRF. A PCC Rule is compounded of information to detect the service data flow and information regarding the QoS and charging parameters for the PCEF to enforce.

^■ Pre-defined PCC Rule, already defined in the PCEF but under the control of the PCRF, which is able to activate/ deactivate based on the evaluation process. The corresponding service data flow and

QoS/charging parameters are defined in the PCEF (i.e. PCRF just activate/deactivate the PCC Rule by invoking the PCC Rule name).

^■ Static PCC Rule, already defined in the PCEF and not under the control of the PCRF (not even known).

PCC architecture just take cares of dynamic and predefined policy rules, being the former the most flexible mean to solve mobile operators QoS control use case. Figure 2 depicts the basic flow and commands:

(1) The terminal tries to establish a IP-CAN Bearer and PCEF requests the policies to enforce to the PCRF (2). The PCRF evaluates the information (3) from the PCEF, the SPR and from the PCRF itself and takes a decision on the policies to apply, which are pushed to the PCEF (4). (9) The policies could be updated any time during the session (due to an application request (6) or any other event).

International application WO2010077684A1 discloses a method for performing packet flow optimization with policy and charging control, wherein a PCRF, or a similar mechanism, creates and sends to a PCEF second PCC rules based on a detected data flow, in order to optimize the flow of data. Detection is carried out using criteria defined in first PCC rules. WO2010077684A1 focuses on predefined policies for radio access and, although PCRF is indicated to subscribe to flow detection triggers, said document does not define said triggers, neither its use, nor the description of the flow to be detected, nor the notification to be received.

EP2146458A1 discloses to carry out a low granularity detection of an event associated with a specific PCC rule, and its application to 3GPP. To that end, the PCRF links an event trigger parameter to a PCC rule, and sends it to a PCEF, which detects the status of an IP-CAN bearer corresponding to said PCC rule associated with an event indicated by said event trigger parameter. Among the many embodiments described by EP2146458A1 , it is proposed that the PCEF also detects, besides the state of the IP-CAN bearer, the event state, and that the PCRF generates and sends new PCC rules based on such detections.

EP2146458A1 focuses on improving the level of granularity for the triggers already defined in 3GPP (session, context or flow policy level). The triggers defined in 3GPP refer to events in the network (e.g. cell change, disconnection, lack of credit), and they do not allow the detection and reporting of a given flow with a particular traffic type. Problems with existing solutions:

The market demands new connectivity services to be part of the portfolio of the mobile network operators, being critical the ability to detect, inform and react dynamically to certain service flows, so the suitable QoS could be applied. Although 3GPP provides several mechanisms to enforce a wide set of PCC Rules, it has not yet fully exploited the advantage neither of new nodes, such as standalone DPIs, nor the new generations of GGSN, such as the ability to detect certain types of service traffic, including L7 analysis.

In this sense, 3GPP does not offer:

Any notification from PCEF to PCRF regarding the detection of a certain service data flow. Complex service data flow templates (i.e. filter/s to detect a service data flow). The filters for certain type of traffic which have become very popular the last years, such as streaming or P2P, has to be predefined in the corresponding node (e.g. DPI) since 3GPP filters only considered the IP 5 tuple: origin/ destination, Port origin/ destination and protocol over IP (e.g. TCP).

Partially pre-defined PCC. Pre-defined PCC rules are mainly used due to the inability to define a specific filter to detect the service data flow of interest. In these cases, 3GPP recommends the use of pre-defined PCC Rules completely configured in the PCEF although activated/deactivated from PCRF, but there is no option to push dynamically some PCC Rule information, such as QoS or Charging features.

Description of the Invention

It is necessary to offer an alternative to the state of the art which covers the gaps found therein and indicated above.

To that end, the present invention provides a method for policy and charge control over data flows in a Gx-enabled network, comprising at least dynamically provisioning

(and modifying, updating or retrieving if necessary) Policy and Charge Control, PCC, rules from a Policy and Charging Rule Function, PCRF, to a Policy Control Enforcement

Function, PCEF, over a Gx interface by applying Attribute Value Pairs, AVPs.

Differently from the prior art disclosures, the method of the invention comprises, in a characteristic manner, carrying out the next steps:

- requesting, said PCRF to said PCEF, to be notified by the latter about the detection of data flows for one or more specific services, at least indicated by the PCRF or predefined in the PCEF, and

- detecting, by means of said PCEF, data flows for said one or more indicated specific services and notifying said detection to said PCRF.

Said steps are carried out by means of generating one or more new AVPs (understanding "new AVP" as an AVP not known in the prior art) and/or including one or more new values into a known AVP, and applying the obtained AVP through said Gx interface.

The method of the invention also comprises, for another embodiment, carrying out said indicating of said one or more specific services, and their description, by at least dynamically providing, said PCRF to said PCEF, one or more service data flow templates included in one or more AVPs, for one or more corresponding specific services.

Part or all of said service data flow templates comprise, for different embodiments, one or more filters describing a respective specific service in order to detect data flows related there to by the PCEF.

For an embodiment, some or all of said service data flow templates comprise several data fields including data defining several corresponding filters describing respective several possible specific services.

According to an embodiment of the method of the invention, part of said data fields are intended for including information about the filter types and part of said data fields are intended for including complementary information to each filter type.

Preferably part or all of said filters defined by said data of said data fields are more complex than the IP 5 tuple, and particularly are L4-L7 service data flow filters.

The method of the invention comprises, for some embodiments, associating to said one or more service data flow templates, or to other service data flow templates, requests of actions (such as blocking or allowing pass of a certain type of data traffic) to be carried out by the PCEF, in addition or instead of said notification, and dynamically providing said associated information together with the corresponding service data flow templates from the PCRF to the PCEF.

Although the feature referring to said service data flow templates has been claimed as a dependent feature (as it has the same common purpose than the one of the features of claim 1 , i.e. that of enhancing the policy and charge control over data flows in a Gx- enabled network), it is clear that it can be an independent feature from the one of requesting and notifying a detected specific service data flow, particularly when the service data flow templates are associated to said actions requests indicated in the above paragraph.

For another embodiment of the invention the method comprises dynamically pushing, from the PCRF to the PCEF, PCC rule information to be associated to at least partially pre-defined PCC rules configured in the PCEF, to modify and/or complement with additional data (such as data referring to QoS information) said at least partially predefined PCC rules.

The features related to said embodiment regarding said PCC rule information dynamic pushing have been claimed as dependent features (as they have the same common purpose than the one of the features of claim 1 , i.e. that of enhancing the policy and charge control over data flows in a Gx-enabled network), but it is clear that they can also be independent features from the one of requesting and notifying a detected specific service data flow, as the instructing of the PCRF to the PCEF to modify and/or complement with additional data a PCC rule pre-defined in said PCEF does not necessarily need to be triggered by the above described notification.

According to the above described different embodiments, the present invention improves 3GPP mechanisms to take advantage of service data flow information by defining extensions over 3GPP Gx interface (TS 29.212). It enables:

^■ The definition of complex service data flow templates to be provided dynamically from PCRF to PCEF.

^■ The notification from PCEF to PCRF regarding the detection of a certain service data flow, based on the complex service data flow templates already mentioned or based on specific service data flows indicated by other means or predefined in the PCEF.

^■ The improvement of the predefined PCC rules, adding a new feature for the PCRF to provide dynamically to PCEF the QoS parameters that applies to the service data flow template, in those cases where dynamic PCC Rules can not be enforced (e.g. the filter to detect the traffic can not be easily described and has to be predefined in the PCEF).

Brief Description of the Drawings

The previous and other advantages and features will be more fully understood from the following detailed description of embodiments, some of which with reference to the attached drawings (some of which have already been described in the Prior State of the Art section), which must be considered in an illustrative and non-limiting manner, in which:

Figure 1 schematically shows a simplified PCC Architecture;

Figure 2 shows a PCC Architecture basic flow;

Figure 3 shows an interlocutory carried out between a PCRF and a PCEF for an embodiment of the subscription and notification procedures of the method of the invention;

Figure 4 shows a commands interchanging between a PCRF and a PCEF, for an embodiment of the method of the present invention related to a partially predefined PCC Rule; and

Figure 5 shows another embodiment of the method of the invention, where the PCRF is sending a CCA command to the PCEF containing the definition of a complex service data flow filter. Detailed Description of Several Embodiments

The present invention proposes improvements to Gx interface of a 3GPP PCC architecture (see Figure 1), adding these new features:

■ New service data flow filters able to describe traffic flow more complex than a 5 tuple IP.

^■ Notification from PCEF to PCRF regarding the detection of specific service data flows.

^■ Partially pre-defined PCC Rules.

The following description deals with these three aspects for different embodiments, describing in detail the ones illustrated by Figures 3 to 5.

Service Data Flow detection notification: For PCRF to be able to receive notifications from PCEF regarding the detection of specific service data flow, two operations need to be considered:

^■ Subscription: PCRF shall indicate to PCEF that a specific notification is needed by subscribing to a service detection.

^■ Notification: PCEF shall notify the PCRF about the information demanded.

Subscription:

Gx reference point provides Charging-Rule-lnstall AVP (AVP code 1001) is of type Grouped, and it is used to activate, install or modify PCC rules as instructed from the PCRF to the PCEF. The present invention proposes a new AVP to be part of Charging- Rule-Install AVP.

Service-Detection AVP (AVP code xxxx) is the new AVP proposed by this invention for PCRF to subscribe to service detection. Service-Detection AVP is of type Enumerated and the following value is defined: ENABLE_NOTIFICATION (0)

This value shall be used to indicate that a notification is needed when detecting the service data flow template specified in the Charging-Rule-lnstall AVP, in the Charging- Rule-Definition AVP (AVP code 1003) to be concrete. If predefined PCC Rules are used, this value will enable the notification of the service data flow template predefined in PCEF and identified by a Charging-Rule-Name AVP (AVP code 1005) or a Charging-Rule-Base- Name AVP (AVP code 1004).

This AVP shall be used in CCA and RAR commands by the PCRF to indicate that upon detection in the PCRF of a certain service/group of service data flows, PCC rules shall be requested.

The combination of the Charging-Rule-lnstall AVP elements will enable notifications but not enforcement by using in a CCR command, a Charging-Rule-Definition AVP and the proposed Service-Detection AVP and omitting QoS-lnformation and charging information (i.e. QoS and charging policies shall not be enforced in PCEF).

Notification:

Gx reference point provides Charging-Rule-Report AVP (AVP code 1018) is of type Grouped, and it is used to report the status of PCC rules. It includes the PCC-Rule- Status AVP (AVP code 1019) of type Enumerated which describes the status of one or a group of PCC Rules. The present invention proposes the addition of a new value:

DETECTED (3)

This value is used to indicate that the service data flow/s described in Charging- Rule-Definition Name/ Base Name AVP has been detected.

This AVP shall be used in CCR command by the PCEF to indicate the detection of a certain service/ group of service data flows and to request new PCC rules, if applies.

Figure 3 shows an embodiment of said subscription and notification procedures, where the PCRF sends, at (2), a CCA command to the PCEF including the new Service- Detection AVP proposed by this invention and the new value ENABLE_NOTIFICATION (0), indicating that it requests the PCEF to notify if it detects the specific service indicated by the AVS "Charging-Rule-Name", i.e. "ServiceO", and the PCEF detects, at (3), data flow for "ServiceO" and sends to the PCRF a CCR command including the above described new value "DETECTED (3)" as a new use of the known rule "PCC-Rule-Status", thus notifying said detection to the PCRF.

Partially pre-defined PCC Rules: 3GPP provides the predefined PCC rules which are preconfigured in the PCEF and can be activated or deactivated by the PCRF at any time, identified by the Charging- Rule-Name AVP or, in case of a group of PCC Rules, the Charging-Rule-Base-Name AVP. The corresponding service data flow and QoS/charging parameters are pre-defined in the PCEF. The present invention proposes to change the predefined PCC Rule definition to a sort of partially pre-defined PCC Rule, in the sense that some PCC features could be configured in the PCEF but some others could be pushed dynamically, such as QoS and Charging information.

Gx reference point provides the Charging-Rule-Definition AVP (AVP code 1003) which defines the PCC rule for a service flow sent by the PCRF to the PCEF. The present invention proposes to add a new AVP to be part of Charging-Rule-Definition AVP.

Charging-Rule-Type AVP (AVP code xxxx) is the new AVP proposed by this invention for PCRF to indicate in CCA/RAR commands to PCEF the type of the PCC Rule. Charging-Rule-Type AVP is of type. Enumerated and the following values are defined:

DYNAMIC (0)

This value shall be used to indicate that the PCC Rule defined by Charging-Rule- Definition AVP is a dynamic PCC Rule.

PARTIAl_LY_PREDEFINED (1 )

This value shall be used to indicate that the PCC Rule defined by Charging-Rule- Definition AVP is a partially pre-defined PCC Rule. When this value is set, the PCEF shall take into account the combination of the set of features pushed dynamically in the Charging-Rule-Definition AVP and already predefined in the PCEF itself, taken precedence the former.

Figure 4 shows an embodiment of said Partially pre-defined PCC Rules procedure, where the PCRF sends, at (1 ), a RAR command to the PCEF including the new Charging- Rule-Type AVP proposed by this invention and the new value PARTIALLY_PREDEFINED (1 ), indicating that "Rulel" is a partially pre-defined PCC Rule which must be activated by the PCEF with the QoS parameters indicated in the RAR command. At (2) the PCEF activates Rulel with said QoS parameters, and after that it sends a corresponding RAA command to the PCRF. Complex Service Data Flow filters:

PCC architecture states that if the extension of the packet inspection beyond the IP 5 tuple is needed, predefined PCC rule should be used in PCEF. Gx reference point provides Flow-Information AVP (AVP Code 1058), included in the Charging-Rule- Definition AVP, is of type Grouped and it is sent from the PCRF to the PCEF and contains the information from a single IP flow packet filter including the flow description. Flow- Description AVP (AVP code 507) is of type IPFilterRule and does not provide the means to define complex service data flow filters.

The present invention proposes to add a new AVP to be part of Flow-Information

AVP.

Extended-Flow-Description AVP (AVP code xxxx) is the new AVP proposed by this invention for PCRF to defined L4-L7 service data flow filter to be provided to PCEF in CCA/RAR commands. Extended-Flow-Description AVP is of type Grouped and this is its format.

Extended-Flow-Description := < AVP Header: xxxx >

[Filter-Type]

[Filter-Info]

Filter-Type AVP (AVP code xxxx) is of type Enumerated and the values defined are:

URI (0)

This value shall be used to indicate that the filter will be defined by an URI. The URI value shall be set in Filter-Info AVP.

P2P (1 )

This value shall be used to indicate that the filter will detect P2P traffic. In case it is needed, a specific P2P protocol shall be set in Filter-Info AVP (e.g. BitTorrent).

VoIP (2)

This value shall be used to indicate that the filter will detect VoIP traffic. In case it is needed, a specific VoIP protocol shall be set in Filter-Info AVP (e.g. Skype).

Streaming (3)

This value shall be used to indicate that the filter will detect streaming traffic.

In case it is needed, a specific streaming media protocol shall be set in Filter- Info AVP (e.g. RSTP). Other (4)

This value shall be used to indicate that none of the values above apply but some complementary information is provided in Filter-Info AVP.

Filter-Info AVP (AVP code xxxx) is of type OctetString and it defines complementary information, depending on Filter-Type AVP:

• For URI (0), Filter-Info AVP will define a URI value.

■ For P2P (1), Filter- Info AVP will define a P2P specific protocol (e.g.

BitTorrent).

■ For VoIP (2), Filter- Info AVP will define a VoIP specific protocol (e.g.

Skype).

■ For Streaming (3), Filter-Info AVP will define a streaming media protocol (e.g. HTTP, RTSP, MMS, RTMP).

For Other (4), Filter-Info AVP will define any kind of extra information which PCEF shall be able to process to set a traffic filter. Figure 5 shows an embodiment of said Complex Service Data Flow Filters PCC Rules procedure, where the PCRF sends, at (2), a CCA command to the PCEF including the new Extended-Flow-Description AVP proposed by this invention in order to block BitTorrent traffic (3).

Advantages of the Invention: The invention improves the existing 3GPP PCC architecture including new features to explode the abilities of new PCEF nodes, such as DPIs and next generation GGSN by defining complex service data template, notification mechanisms on service data flow detection and partially predefined PCC Rule which will include dynamic QoS and Charging parameters. The main advantages of the invention over existing solutions are the following:

■ The invention provides some easy and low cost mechanisms to enhance the flexibility of dynamic control of connectivity services, since it is an extension of a commonly adopted reference point among PCEF nodes.

^■ The invention will increase the efficiency of radio resources allocation since the ability to notify dynamically on the service data flow detection will enable the

PCRF to adjust the radio resources needed when enforcing in the radio gateways (e.g. GGSN). This is an advantage over solution based on predefined rules enforce in DPI nodes, since DPI are not able to renegotiated PDP Context with SGSN.

The invention will reduce the time-to-market and will extend easily the portfolio of new connectivity service, since the access/ transport network will be aware of service data flows even sharing the same PDP Context and will notify to the PCRF which will instruct accordingly the corresponding PCEF node to block, shape or redirect the traffic for this flow.

The invention will simplify the access/ transport nodes provisioning tasks, since extend the ability of the PCRF to provide dynamically as much information as possible, including new filters and partially predefined PCC Rules, which reduced the number of PCC Rules that need to be defined in the PCEF themselves.

A person skilled in the art could introduce changes and modifications in the embodiments described without departing from the scope of the invention as it is defined in the attached claims.

ACRONYMS AND ABBREVIATIONS

PCC Policy and Charging Control

PCEF Policy Control Enforcement Function

PCRF Policy and Charging Rule Function

UMTS Universal Mobile Telecommunication System

REFERENCES

[1] TS 23.203 "3rd Generation Partnership Project: Policy and Charging Control Architecture"

[2] TS 29.212 "3rd Generation Partnership Project: Gx reference point"

[3] TS 29.214 "3rd Generation Partnership Project: Rx reference point"

Claims

1. - A method for policy and charge control over data flows in a Gx-enabled network, comprising at least dynamically provisioning Policy and Charge Control, PCC, rules from a Policy and Charging Rule Function, PCRF, to a Policy Control Enforcement Function, PCEF, over a Gx interface by applying Attribute Value Pairs, AVPs, characterised in that the method comprises carrying out the next steps:

- requesting, said PCRF to said PCEF, to be notified by the latter about the detection of data flows for at least one specific service, at least indicated by the PCRF or predefined in the PCEF, and

- detecting, by means of said PCEF, data flows for said at least one indicated specific service and notifying said detection to said PCRF;

where said steps are carried out by generating at least one new AVP and/or including at least one new value into a known AVP, and applying the obtained AVP through said Gx interface.

2. - The method of claim 1 , comprising providing said request of said PCRF by means of a subscription to a service detection.

3. - The method of claim 2, comprising carrying out said subscription by generating a Service-detection AVP, including it into a Charging-Rule-lnstall AVP and sending the latter, as a CCA or RAR command, to the PCEF.

4. - The method of claim 3, comprising providing said notification of said PCEF by including a new value into the PCC_Rule_status AVP, said new value indicating if the requested detection has been done, and including said PCC_Rule_status AVP into a Charging-Rule-Report AVP and sending the latter, as a CCR command, to the PCRF.

5.- The method of any of the previous claims, comprising carrying out said indicating of said at least one specific service, and its description, by at least dynamically providing, said PCRF to said PCEF, at least one service data flow template included in at least one AVP.

6. - The method as per claim 5, comprising providing a plurality of said service data flows templates, for different specific services.

7. - The method as per claim 5 or 6, wherein at least part of said service data flow templates comprise at least one filter describing a respective specific service in order to detect data flows related there to by the PCEF.

8. - The method as per claim 7, wherein some or all of said service data flow templates comprise several data fields including data defining several corresponding filters describing respective several possible specific services.

9. - The method as per claim 8, wherein at least part of said filters defined by said data of said data fields are L4-L7 service data flow filters.

10. - The method of claim 8 or 9, wherein part of said data fields are intended for including information about the filter types and part of said data fields are intended for including complementary information to each filter type.

11. - The method of claim 10, wherein each of said filter types describes services associated to certain types of traffic selected from the group including: streaming, P2P and VoIP.

12. - The method of any of claims 5 to 11 , comprising associating to said one or more service data flow templates, or to other service data flow templates, requests of actions to be carried out by the PCEF, in addition or instead of said notification, and dynamically providing said associated information together with the corresponding service data flow templates from the PCRF to the PCEF.

13. - The method of any of claim 5 to 12, comprising providing each of said at least one service data flow templates to said PCEF by generating an Extended_Flow-

Description AVP, including it into a Charging-Rule-lnstall AVP, in the Charging-Rule- Definition AVP to be concrete, and sending the latter, as a CCA or RAR command, to the PCEF.

14. - The method of claim 13 when depending on claim 3, wherein said CCA or RAR command sent to the PCEF includes both said Extended-Flow-Description AVP and said Service-detection AVP.

15. - The method as per claim 12, wherein said actions requested are at least referred to blocking or allowing pass of a certain type of data traffic.

16. - The method as per any of the previous claims, comprising dynamically pushing, from the PCRF to the PCEF, PCC rule information to be associated to at least partially pre-defined PCC rules configured in the PCEF, to modify and/or complement with additional data said at least partially pre-defined PCC rules.

17. - The method as per claim 16, where said additional data refers to QoS information.

18.- The method of claim 16 or 17, comprising providing said PCC rule information to said PCEF by generating a Charging-Rule-Type AVP, including it into a Charging-Rule- lnstall AVP, in the Charging-Rule-Definition AVP to be concrete, and sending the latter, as a CCA or RAR command, to the PCEF.