CCA being rejected by PGW

Question

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?

Answer 1

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

Comments

Added the structure in the answer.

I got an info from them from one of their simulator logs that they need base name also.

Also in the first try there was some spelling mistake in the rule name and they were sending CCR U with "Unknown Rule Name". But now they accept rule name, but now they need "flow info".

Answer 2

What is the release version that PGW supports.

Feature-List Value is 1. So I assume that PCRF supports release 8.

Please check what Rel-Version PGW checks.

Comments

Thanks a lot Peeyush !.  As always Really appreciate your knowledge on LTE.

Looks like in my current version of 29.212 (this was not proper). Now downloaded V12.9.0 and I can see that this section is updated properly.

Yes PCRF supports Rel8..(not sure why this is being rejected by PGW)...Waiting for debug info..

---

sorry this should have been a comment for Peeyush's reply :)
I think thirdparty PGW supports Rel8 PCRF.. ( will crosscheck again)

---

@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

Regards,
Peeyush Sharma

---

Thanks a lot, Ofcourse helped a lot.  :)
Yes, as you suggested, Im trying to understand the events on the spec, will be disturbing you again, if I cannot understand them

---

It would be a pleasure :)

Answer 3

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

Comments

Check the flags inside Vendor-Id AVP what you are setting. They should comply with the base rfc

---

Thanks alot Peeyush..Yes spotted correctly ..Now I find some issues in my Dictionary and base AVP constructor code.. Sorry for naive questions..

---

To be honest there are no such thing as naive questions. I have gone through the same and still goes through it...don't bother...i have been in your shoes :)


Regards,
Peeyush Sharma

---

Thanks a lot Peeyush for the kind words and help. (it is difficult, even if somebody gone through the same phase, donot accept naive questions.). I appreciate your patience ..Thankyou

Answer 4

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)

Comments

Yes as per spec both kind of rules should be allowed. However it depends on the implementation. Usually static rules are used for default bearer.

---

thanks Peeyush. Do you spot anything wrong in the above Dynamic Rule config (for the default bearer)?

I think case of static, we just send the Rule Name under "Charging Rule Install" somewhat like below, and rest of the fields remain the same as "Dynamic".

        [M] CC-Request-Type: INITIAL_REQUEST (1)
        [M] CC-Request-Number: 0
        [V] [M] Charging-Rule-Install:
          [V] [M] Charging-Rule-Name: all-http
        [V] [M] Charging-Rule-Install:
          [V] [M] Charging-Rule-Base-Name: test
        [V] Supported-Features:
          [M] Vendor-Id: 10415
          [V] Feature-List-ID: 1
          [V] Feature-List: 2
        [M] Result-Code: DIAMETER_SUCCESS (2001)
        [M] Auth-Application-Id: 16777238

Any inputs on these ?

---

yes you can send either Charging-Rule-Name or Charging-Rule-Base-Name

---

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.

---

Sending QoS-Information in initial request is ok. PGW will send requested AMBR values in QoS-Information AVP

---

Thanks a lot Peeyush...Oh ok, so this AMBR can refer to default bearer..I just was wondering that this refers to creation of dedicated bearer..

---

AMBR is basically shared by all the non-gbr bearers including the default bearer.
So in a way you can say it is a session level parameter and hence negotiated in the very beginning.

Answer 5

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.

@ Peeyush- any expert advice on this ?

Comments

Not sure why the PGW is rejecting the above CCA with the Failure code as "Missing Flow Info". I am bit stuck with this. Any inputs ?

Answer 6

@ Peeyush : Sorry being late update. But the PGW was able to setup the Default Bearer with the static rule.
Thanks a lot for all the help and support.

Comments

How were you able to resolve the issue. What was the problem actually.

---

The contents in the "static rule config " which we sent was correct. But some config issues on third party..

---

Cheers!!! mate...good going

---

I know it would have been impossible without your inputs (I really mean it)..Really appreciated..Thanks a lot :)

---

Glad to help :)

---

Just another update , now got the dedicated bearer working properly with the thirdparty. Thanks a lot Peeyush for all the help..credit goes to you for the inputs.

Next step may be voice call

---

Good to hear that. I am happy with the progress you are making.