top button
Flag Notify
Site Registration

PCRF Gx related: CCRequest message during the attach, TFT info

+1 vote
672 views

Looking at interoperability issues.
The CCRequest message sent from PGW to PCRF during attach. Does the CCA sent back from PCRF to PGW needs to have TFT info?

posted Jun 30, 2015 by Pdk

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+2 votes

During initial attach UE will not request any kind of filter.

However operator has to track down the data being consumed on the default bearer too.

So what operator basically does it that they configure a static rule on PGW with some service-id and rating-group. Now what happens is that when initial CCR-I will go operator will create a policy in PCRF based on the CCR type and APN which in-turn will send the static rule name in CCA.

PGW will then enforce that rule so that charging can be done based on the service id and rating group on OCS.

Sometime operator can use this static rule to allow disallow some service on default bearer

Eg: Operator may want to allow only IMS Signalling on default bearer for IMS APN and drop other packets.

Regards,
Peeyush Sharma

answer Jul 15, 2015 by Peeyush Sharma
Similar Questions
+2 votes

Could you help me figure out CCRequest basic message contents sent from the PGW to PCRF. I am in a process of replacing our Gx interface from the static calls to the Diameter interface.

I am interested in any discussion about this interface.

I am also trying to understand , how the APN info is passed from the PGW(PCEF) to PGW. I think the Called-Party-AVP is used. It is bit contradicting info in the net than the one given in spec, (which says it is used to indicate Emergency APN)

+4 votes

Hello,

I have been able to write a standalone basic PCRF code in our software.

I had also written them using the Gx and RX interfaces (i.e using the diameter protocol). There was no time to test this feature.

Now I find flaws in my design regarding the Diameter while testing.

Initially the SIP (i.e ike IMS) was sending the request to PGW to create the voice bearer. Now my initial implemetation of Rx i thought the TFT was calculated in the SIP and sent across in the RX, but now when revisiting the code, i feel, that there was no such parameter to pass this info to the PCRF from SIP.

Now my doubt is, how this info related to TFT is being passed across to PCRF. Is it through the "Flows".
If so how to get the TFT in the PCRF to send back to PGW...I have missed this part of the design as i was looking more into the QOS..

Any help is greatly appreciated.

thanks
pdk

+3 votes

I am trying to handle all the error scenarios seen while testing the Gx with the third party. As of now I had coded for just the successful scenarios.

I am looking for some of inputs on these error scenarios and how to proceed and exit gracefully (rather than crashing the code)

  • Dynamic rule config with wrong parameters., PGW sends CCR with the CCR type=TERMINATION_REQUEST. How can PCRF respond (just log error and comeout ?)

  • Static rule config with the "wrong rule name". When the PCRF sends CCA-I with the wrong rule name, PGW sends CCR-U with the Charging Rule Report with the "Rule-Failure-Code" as "Unknown Rule Name". In this case remove those rules and continue OR just comeout with just logging error)

+3 votes

Looking for the information related to PCRF.

Another specific question. When the PCRF decides on a QOS and sends across to P-GW. P-GW might not have got any info related to Dedicated bearer to be established earlier. So how does it map this newly sent QOS for the new dedicated bearer to the one it requested by P-CSCF.

I am trying to understand, how to map the QOS info sent by PCRF to the "dedicated bearer request by the P-CSCF. Can PCRF on sending the QOS, also create the new dedicated bearer id, which is sent back to P-CSCF ?

Any info regarding with is very helpful.

...