top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

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.

+2 votes
679 views

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.

posted Jun 9, 2017 by Reginald Lutterodt

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+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

+2 votes

This regarding the sessions b/w the PGW and PCRF.

Lets say we have 2 default bearers(DEF1, ad DEF2) for UE1, and 2 dediicated bearers for each of these Default bearers. And for UE2 assume 2 def bearers, DEF3, and DEF4.

Now a CCR is sent for initial default bearer DEF1 creation for UE1. Lets say session(session1) is created for this. with CCRequest number=0.
For Ded bearer1 creation, will it use the same session Id ? and increment the CCRNumber ?
What about the UE2?

I am new to Diameter and earlier, these things were internal and didnot need diameter interface. So the questions are arising.

+1 vote

Hi all,

We have complexity linked to Gy and Gx interfaces.

Let's say that we have two rules configured as static on PGW with :

Rule1= Reports RatingGroup1
Rule2= Reports RatingGroup2

When PCRF install Rule 1 on Gx, the ratingGroup reported by PGW to OCS is RatingGroup1
When PCRF uninstal Rule1 then install Rule2, the ratingGroup reported by PGW remain RatingGroup1 till a Gy trigger is reached (revalidation time, GSU consumption...).
Then the problem on our system is that when PCRF change the rules on Gx interface the PGW keep reporting the old rating group on Gy interface ie: Gx change do not lead to a Gy change similtanously. I m wondering if there is a standard behaviour for such a use case?

Thanks a lot

+3 votes

In the CCA message sent by the PCRF to PGW during the Initial Attach, may have "Charging-Rule-Base-Name" Or "Charging-rule-Name". I think "Charging-rule-Name" is sent as part of the Charging-Rule-Install , where the Rule is sent from the PCRF to PGW. "Charging-Rule-Base-Name" is sent as part of the preinstalled rules in the PGW.

Now the question is if the PCRF is getting integrated to thirdparty PGW. In this case how PCRF knows about the names installed in the PGW ?

thanks a lot for the responses and hints

+1 vote

1) Assume that susbcriber is having lower specifications handset which can support of 300kbps in 2G radio, when susbcriber creates a session/starts browsing then GGSN will send QOS in CCR-I as 300kbps & PCRF will reply CCA-I as 400kbps (Assume that at PCRF end 400kbps plan is configured), subscriber can browse successfully & no extra messages in network

2) Assume that susbcriber is having lower specifications handset which can support of 300kbps in 2G radio, when susbcriber creates a session/starts browsing then GGSN will send QOS in CCR-I as 300kbps, PCRF will reply CCA-I as 400kbps (Assume that at PCRF end 400kbps plan is configured), subscriber can browse successfully, after sometime GGSN send CCR-U1 messages with event trigger revalidation timer expired & qos as 300kbps, PCRF will again execute policy function & allocate 400kbps in CCA-U1. Now GGSN again sends an CCR-U2 with 300kbps QOS-CHANGE as event trigger & again PCRF send 400kbps in CCA-U2, like this it go on loop.

/IPCANTYPE=3GPP-EPS mode/
Concern is why same qos send in case-1 is no loop messages, where as loop in case-2

...