top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Default EPS Bearer QOS and QOS info in the CCR message

+2 votes
812 views

Hello,

Pardon me, this is just a theoretical question. Not started my real testing yet. But so meantime trying to see I handle the basic possible scenarios.

In the CCR message of type (Initial Request), lets say PCRF receives both the "QOS" (containing APN AMBR UL and APN AMBR DL) and "Default Bearer QOS" AVP (containing QCI and ARP).
As of now, in my basic code, I return the QOS based on apn info received on "Called-station-ID" AVP. Will it be ok..Or is there any better suggestions on this ?

~p

posted Aug 28, 2015 by Pdk

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

1 Answer

0 votes

Theoritically it can be like that.
But, it should be based on the RAT (Radio Access Type) info and the Subscriber Package. Let say if the user does not subscribe anything, you can give the small speed rather than the subscribed user.

answer May 7, 2017 by Hana Pamora
Similar Questions
+1 vote

I am trying to understand the charging rules in case of default bearer without the TFT info. i.e with this bearer the UE is still able to browse the internet.
Lets say the Table in PGW is like this:

Servicetype=>Internet
Method=>VolumeBased
Tariff for GroupA £0.5/KB

In this case, what will the value of "service identifier" AVP ?

Because in case we have two services, WAP and Videostreaming, we can have two charging rules ( One service type for WAP and another for Video )..In this case, the CCA will have two charging rules (each with service Identifier, as WAP and streaming) and each will have different TFT. So the PGW can apply these two rules on the default bearer.
My another silly doubt is: how the PCRF, determines, it needs to send two charging rules on CCRequest message.
{ just to clarify based on which AVP in the CCRequest }

Just to clarify the above Query, I tried to read through the book regarding the GPRS charging in the "charging for mobile All IP Communication" by Yi-Bing and section 9.2 "Content based Service for Online TPF/GPRS". where there are two charging rules configures for WAP and Video streaming..There I am trying to figure out AVP in CCR, which triggers two Rules in CCA

Just adding some more queries: on Gy.
- In the "Multiple-Services-Credit-Control AVP" , how the "Requested-Service-Unit" is filled as part of CCR (Initial) Gy request. (is this needed)Because it looks like from the Message sequence in the book CCRequest Terminate is sent with the Used Bytes at PGW. Then OCS calculates the "total bytes" and calculates the charge based on this..{Refer fig 9.3 in the book}
thanks
Priya

+1 vote

Hello all,

Can anybody suggests how we can set maximum bitrates for parameters like MBR, GBR (UL,DL), APN-AMBR(UL/DL), UE-AMBR(UL/DL) for GBR and Non GBR bearer.?

Are those values standard from PCRFor does it define dynamically based on user subscription.?
Please suggest some sources to choose the exact the bitrates for QoS parameters mentioned above.

Thanks in advance,
Naveen.

+1 vote

There is one use case here. PCEF has sent CCR (due to IP-CAN session modify) to PCRF and it again sends CCR to (due to another update) without receiving previous CCA. What should be the behavior ?

+1 vote

Looking at interoperability issues.
The CCRequest message sent from PGW to PCRF during attach. Does the CCA sent back from PCRF to PGW needs to have TFT info?

+3 votes

I was trying to understand and implement basic version of 29.213 Section 6.3 QoS parameter mapping Functions at PCRF especially for non GBR bearers.

Non GBR bearers have QCI, ARP, APN-AMBR and UE-AMBR. And also MBR associated with each bearer in the PGW..So when a new bearer is added, the UE and Ennode-b dynamically take care that total rate of all bearers doesnot exceed APN-AMBR (for each APN) and UE-AMBR for all Non GBR bearers in UE..

So not sure PCRF can alter any params related to BW in case of non GBR.. This is my understanding..If you have any comments will be very helpful.

...