top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

FlowDescription AVP in CCA for CCR(Initial)

+3 votes
2,334 views

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

posted Aug 24, 2015 by Pdk

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

1 Answer

+2 votes
 
Best answer

Flow-Description or Flow-Information are part of Charging-Rule only. In case of CCA-I when you are trying to create a default bearer a Charging-Rule is not needed. Hence there is no need to send Flow-Info or Flow-Description in CCA-I

However, if a Rule is getting enforced for the first time then as per 29.212 Flow-Information is mandatory. If the same rule is re-installed, in that case there is no need to send the Flow-Information again and PGW will retain the previously sent values.

Dedicated bearer creation are always associated with Charging-Rule

Regards,
Peeyush Sharma

answer Aug 24, 2015 by Peeyush Sharma
Thanks a lot Peeyush .

I thought PCRF can manipulate the QOS for the default bearer (i.e during the initial setup, based on the APN (called-station-id) received in the CCR).
 I thought it is through the "QOS Information" within the "Charging Rule Install" AVP.

As you say, "ChargingRuleInstall" is not needed for the Default Bearer creation. Then how the QOS is passed across into PGW ? (for the initial request)

I also read somewhere (during my initial study) that default TFT is sent in the CCA..Not sure what it means
Sorry for asking same question again and again..i appreciate your patience. Thanks a lot for that.
As default bearer is a non-gbr bearer so when qos is sent towards SGW it is only APN-AMBR.

Let me explain it step by step.
For GBR bearers GBR and MBR values are used where GBR is a value which will tell that the bearer will get atleast that much bandwidth and MBR is the Max value which the bearer can attain.
For Non-GBR bearers MBR and GBR are not communicated towards SGW as mentioned in 29.274.
For Non-GBR SDF(group of filters). PCRF will send MBR values which are used by PGW to enforce on the particular SDF.

Let's say you have Bearer 1 which is of QCI 1. It has 2 Rules R1 and R2. Each rule has MBR 100 and GBR 50.
So, now when Create Bearer Request will go towards SGW, under the Bearer-Level-QoS the GBR UL=100, GBR DL=100, MBR-UL=200, MBR-DL =200.

Let's say you have Bearer 2 with QCI 6
It has 2 Rules R3 and R4. MBR associated with each rule is 100.
Now, when PGW when it will send Create Bearer Request or later Update Bearer Request towards SGW for this particular bearer it will send MBR and GBR parameters under Bearer-Level-QoS with value 0.
On the core side APN-AMBR allocated to that particular session will be used which was communicated while creating the default bearer
Thanks a lot.

Sorry for not making the question, very clear.

As of now , may be for me to make it simple (bear with me for my limited LTE knowledge), lets initially just look at "Default Bearer" creation.

Lets say firstever CCR comes with ARP=6 , APN-AMBR(Ul/Dl)=100kbps for apn=ims.
Now PCRF responds with CCA . My question is "whether this needs to have the defalt tft" (inside Charging Rule Defn) ?
There is no compulsion. PCRF may or may not send it. Usually operator use a static rule for default bearer
Thanks a lot.
Peeyush,
Just to update, Hopefully got all hints from your answers (sorry it took sometime to get all clues)..implemented it..but unfortunately IOT is delayed due to some restructuring at third party..so held up in testing.. This is difficult to test internally (as we donot know which AVPs are expected at thirdparty)..Internally I have two linux oracle Virtual Machines (one acts as PCRF and other IMS & PGW all other softcore components)
But thanks a lot for inputs to solve this in advance
~p
Happy to help :)
Similar Questions
+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.

+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

+3 votes

If PCRF sends Charging-Rule-Base AVP for activation/deactivation of all rules inside the given rulebase in CCA , then is it possible that PCEF was able to activate/deactivate some rules in the rulebase and other rules activation/deactivation failed ?

...