top button
Flag Notify
Site Registration

How sessions between PGW and PCRF is maintained in LTE network?

+2 votes
1,545 views

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.

posted Feb 22, 2015 by Pdk

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

1 Answer

+1 vote
 
Best answer

The session for a session let say UE 1 with PDN connection 1 will remain same through out, However CC-Request no will increment with each message.

CC-Request-Type will also be different. In case of initial attach CC-Request type will be 1(Initial), in case of updation CCR-Request no will increment by 1 and CC-Request will be 2(update).

Lets say you are now doing some modification to the existing session UE1 PDN1 then the CC-Request no will increment however CC-Request type will be Update(2). And finally when session will be terminated then in that case CC-Request Type will be 3(Terminate).

Also, its good that you are getting doubts..it means you are progressing :)

answer Feb 22, 2015 by Peeyush Sharma
Great answer, deserves a wall recommendation :)
Thank you for the appreciation salil
Thanks a lot for the Very Quick response :) . I also hope .(that i am progressing :) )

Btw, i have some data from Create Session needs to be buffered in PGW, till i get response for the CCR.
.So CCRnumber can be stored for each default bearer. So i am thinking of storing the Sessionid, CCR number and default bearer id in the PGW along with the info to be buffered. So when i get the CCA back from PCRF, i can uniquely identify the buffered info in the PGW.

Btw, lets say we have Dedicated bearer1, is created for Default bearer, it will have same session id as the Default bearer1, but CCR number will be incremented to 2.

Hope i am not trying to push you too deep into my implementation details. Sorry about that.

Btw, in our implementation of PGW, we have a generic PGW handler, which spans a new PGW instance for each default bearer created
"Btw, lets say we have Dedicated bearer1, is created for Default bearer, it will have same session id as the Default bearer1, but CCR number will be incremented to 2"

Yes your understanding is correct...and i guess this dedicated bearer is created from UE side
Thankyou for clarifying :)
Similar Questions
+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

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

...