top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration

CCA being rejected by PGW

+3 votes
218 views

CCA being rejected by PGW

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?

posted Sep 11, 2015 by Pdk

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

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

answer Sep 17, 2015 by Peeyush Sharma
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".
+2 votes

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.

enter image description here

answer Sep 11, 2015 by Peeyush Sharma
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 :)
+1 vote

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

enter image description here

answer Sep 14, 2015 by Pdk
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
0 votes

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)
enter image description here

answer Sep 15, 2015 by Pdk
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.
0 votes

enter image description hereNow 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 ?

answer Sep 17, 2015 by Pdk
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 ?
0 votes

@ 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.

answer Sep 23, 2015 by Pdk
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.
Similar Questions
+1 vote

I would like to understand that under what circumstances the “ RESOURCES_LIMITATION” failure code sent by SAE-GW on Rx?

+2 votes

PGW sending a USU of 0 in CCR Updates after the first USU in first CCA Update was sent correctly. GSU from PCRF is 10Mb.

+1 vote

How the signalling messages flow between network nodes of inter PLMN ?
Assume a scenario, in which LTE UE is connected to its home network and handed over to another network due to mobility.

+3 votes

enter image description here

Hello,

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 ?

{ Imp Please Note: This is my initial basic implementation, so only basic necessary AVPs are handled. }

Thanks a lot for the comments and replies
~p

Contact Us
+91 9880187415
sales@queryhome.net
support@queryhome.net
#280, 3rd floor, 5th Main
6th Sector, HSR Layout
Bangalore-560102
Karnataka INDIA.
QUERY HOME
...