CCA being rejected by PGW

+3 votes

218 views

Above wireshark shows the CCA being sent by PCRF for the "Initial Request". Somehow the thirdparty PGW is not liking the supported feature AVP .
As of now I put the supported feature and subAVPs in 3gpp Dictionary. So you can see the vnd=TGPP. If they are put in base dictionary this phrase { vnd=TGPP} is not seen in front of AVP.

Can somebody help why this is issue ? Or do you have any reference pcaps?

6 Answers

+1 vote

Best answer

If you are sending static rule name then there is no need to send flow information. If pgw is asking for flow information in static rule then it is an issue at pgw end.
Please check if you are sending charging rule name under charging rule definition.
Under charging rule install only charging rule name should be present.
Paste the structure of charging rule install you are sending.
I might not be able to reply fast but I'll reply as soon as I'll get some bandwidth

@Peeyush: Sorry for continuing in the same thread. Just wanted to understand the spec for another AVP in the CCA message i.e Event-Trigger AVP (All access types). Not sure whether this AVP is mandatory while sending CCA from PCRF to PCEF. Currently not sending it. From spec it looks like , this AVP needs to be sent cause a re-request of PCC rules from PCRF to PCEF.

No it is not mandatory. PCRF sends it when it wants PGW to report for a particular type of event that has occured.
Like for eg RAT_CHANGE, so when a handover will happen and RAT Change will happen. PGW will have to send a CCR-U where it has to send Event-Trigger AVP with value RAT_CHANGE and RAT-Type AVP

There are few Event-Trigger for which subscription from PCRF is not needed and PGW has to send those event triggers like QOS_CHANGE for AMBR change and Def-EPS-Bearer-QoS_CHANGE.

Hope it helped. Go through all the Event-Trigger and let me know if you don't understand any of them

Just a quick Question: Observed another thing, (from your earlier comments)that I was not including vendorId within the supported features. But now my wireshark is not able to decode it.
Not sure whether it is issue with my encoding Or wireshark error

Not sure why the PGW still is not accepting the Dynamic Rule creation for the Default Bearer. :( . Thirdparty are saying they accept static rules for the PGW..(But from spec , it looks like they should accept both, static and dynamic)

I think I spotted something bit weired (which may be correct) in the CCRequest Message sent by thirdparty PGW. They are sending QOS Info along with the "Default EPS Bearer QOS".
So may be they are expecting the creation of the dedicated bearer along with the default bearer.
As of now my basic design, just accepts, the Default Bearer creation when CCRequest type is initial, with CCReqNumber is 1.

Now it looks like we made some progress, stil little. Now PGW accepts the static rule name. But PGW again is sending CCR with the following fields (immediately after the CCA containing the static rule name)
[V] [M] Charging-Rule-Report:
[V] [M] Charging-Rule-Name: all-http
[V] [M] PCC-Rule-Status: INACTIVE (1)
[V] [M] Rule-Failure-Code: MISSING_FLOW_INFORMATION (9)

Not sure whether there is any AVP in CCA to tell that , they need to use the Flow info from their configs.

Was going through the spec , but no luck.. I think it is upto PGW to define the rules to include the "Flow info" in the static rule.

For the CCR (Initial Request), the CCA is of the above format in my internal testsetup. This seems like Dynamic Rule configuration. I am not sure whether we need to send info like "Flow information" or TFT in CCA. This was answered earlier by Peeyush ( that it is not needed). But wanted to crosscheck the same ?