Sunday, March 22, 2009

Bearer Level QoS (TS 23.401, Clause 4.7.3)

The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and MBR, described in this post. This post also describes QoS parameters which are applied to an aggregated set of EPS Bearers: APN‑AMBR and UE‑AMBR.

Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS parameters:

-   QoS Class Identifier (QCI);

-   Allocation and Retention Priority (ARP).

A QCI is a scalar that is used as a reference to access node-specific parameters that control bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operator owning the access node (e.g. eNodeB).

The ARP shall contain information about the priority level (scalar), the pre-emption capability (flag) and the pre-emption vulnerability (flag). The primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or needs to be rejected in case of resource limitations (typically available radio capacity in case of GBR bearers). The priority level information of the ARP is used for this decision to ensure that the request of the bearer with the higher priority level is preferred. In addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at handover). The pre-emption capability information of the ARP defines whether a bearer with a lower ARP priority level should be dropped to free up the required resources. The pre-emption vulnerability information of the ARP defines whether a bearer is applicable for such dropping by a pre-emption capable bearer with a higher ARP priority value. Once successfully established, a bearer's ARP shall not have any impact on the bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding treatment should be solely determined by the other EPS bearer QoS parameters: QCI, GBR and MBR, and by the AMBR parameters. The ARP is not included within the EPS QoS Profile sent to the UE.

Each GBR bearer is additionally associated with the following bearer level QoS parameters:

-   Guaranteed Bit Rate (GBR);

-   Maximum Bit Rate (MBR).

The GBR denotes the bit rate that can be expected to be provided by a GBR bearer. The MBR limits the bit rate that can be expected to be provided by a GBR bearer (e.g. excess traffic may get discarded by a rate shaping function).

Each APN access, by a UE, is associated with the following QoS parameter:

-   per APN Aggregate Maximum Bit Rate (APN-AMBR).

The APNAMBR is a subscription parameter stored per APN in the HSS. It limits the aggregate bit rate that can be expected to be provided across all Non‑GBR bearers and across all PDN connections of the same APN (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non‑GBR bearers could potentially utilize the entire APN‑AMBR, e.g. when the other Non‑GBR bearers do not carry any traffic. GBR bearers are outside the scope of APN‑AMBR. The P‑GW enforces the APN‑AMBR in downlink. Enforcement of APN‑AMBR in uplink is done in the UE and additionally in the P‑GW.

Each UE in state EMM-REGISTERED is associated with the following bearer aggregate level QoS parameter:

-   per UE Aggregate Maximum Bit Rate (UE-AMBR).

The UE‑AMBR is limited by a subscription parameter stored in the HSS. The MME shall set the UE‑AMBR to the sum of the APN‑AMBR of all active APNs up to the value of the subscribed UE‑AMBR. The UE‑AMBR limits the aggregate bit rate that can be expected to be provided across all Non‑GBR bearers of a UE (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non‑GBR bearers could potentially utilize the entire UE‑AMBR, e.g. when the other Non‑GBR bearers do not carry any traffic. GBR bearers are outside the scope of UE AMBR. The E‑UTRAN enforces the UE‑AMBR in uplink and downlink.

The GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/APN-AMBR denote bit rates of traffic per group of bearers. Each of those QoS parameters has an uplink and a downlink component. On S1_MME the values of the GBR, MBR, and AMBR refer to the bit stream excluding the GTP-U/IP header overhead of the tunnel on S1_U.

The HSS defines, for each PDN subscription context, the 'EPS subscribed QoS profile' which contains the bearer level QoS parameter values for the default bearer (QCI and ARP) and the subscribed APN-AMBR value. The subscribed ARP shall be used to set the priority level of the EPS bearer parameter ARP for the default bearer while the pre-emption capability and the pre-emption vulnerability information for the default bearer are set based on MME operator policy.

The ARP of the default bearer should be set appropriately to minimize the risk of unnecessary release of the default bearer.

7 comments:

Unknown said...

About the statement from 23.401 spec: "The MME shall set the UE‑AMBR to the sum of the APN‑AMBR of all active APNs up to the value of the subscribed UE‑AMBR":

Do you have an idea of at least one case when by doing this change of UE AMBR in accordance to the APN AMBR would bring some difference to the network? By always keeping the UE AMBR constant, equal to the value the MME received from HSS, so independent from the APN AMBR value change triggered online from PCRF, I see excatly teh same netwrok behaviour.

So I'm wondering why this re-calculation of UE AMBR, dependent on APN AMBR, was introduced in the 3GPP spec, as currently I see that this is always useless.
I'd be glad if you can give me ONE example where this UE AMBR recalculation would bring a difference, as then it will be clear the 3GPP spec team did well their job.

Santosh Dornal said...

Ofcourse 3GPP has done well with AMBR calculations. The biggest example where UE-AMBR recalculation is done is additional PDN creation. Imagine this, UE-AMBR=x and APN-AMBR for PDN1=y. x>y, so enforced UE-AMBR will be y. Now UE wants to create a additional pdn, PDN2. For next PDN APN-AMBR is z. x>y+z, so enforced UE-AMBR is y+z. if y+z>x then UE-AMBR should be throttled to x.

Unknown said...

Just to understand your point, by using the same example:
Suppose MME always kept the original UE AMBR values: x and APN AMBR1 = y<x.

The DL traffic limitation will be done by PGW to y value, so everything is OK.
The UL traffic limitation is done by UE to y value, so again everything is OK.

Next, you say a PDN is created with APN AMBR=z.
Again, the DL traffic limitation will be done by PGW for each of the APN in part to its defined APN AMBR and eNB might also enter in action limiting even more the DL traffic in case the total traffic on both APNs is greater than UE AMBR DL.

For UL again UE will limit the traffic for each APN according to its APN AMBR and eNB might also enter in action to limit even more the UL traffic if the total UL traffic is greater than UE AMBR UL.

You see now why I don't understand the need to recalculate the UE AMBR???
In normal situation I'd say it is completely useless. It could be needed only in buggy cases, when either UE (for UL traffic) or PGW (for DL traffic) would not perform correctly their job, then eNB would be there to impose the limits and only for this case eNB would need to be updated by MME with UE AMBR = minimum (sum (APN AMBR1,...,APN AMBRn, UE AMBR set in HSS)).
Do you agree?

Santosh Dornal said...

I understand your point, but you just cannot trust the UE's. All the network elements may be tested to make sure they work accordingly but give the wide variety of UE's its not a good idea leave the bit rate values to UE.

Also, as you pointed out, UE AMBR recalculation is required so as to perfectly manage the eNB resources. The point that PGW can limit the DL and UE can limit the UL ultimately depend the eNB resources. So it is a good idea to keep the resources free based on these recalculations. You can afford a core network resource easily but radio resource is expensive.

Another scenario where this is very useful is local breakout. If your UE-AMBR<APN-AMBR then MME has to throttle bit rates to UE-AMBR. Hence the UE-AMBR cap.

NITESH said...

Hi everyone, i am a new person for this domain, but so far what i have gathered is UE-AMBR and APN-MBR does not question GBR, i.e. GBR is out of their scope. My question is, from where comes the Quota for GBR? of course there will be a limit at radio resources, but is the quota not defined anywhere in HSS or PCRF or anywhere else and does that mean that GBR will eat all the non-GBR EPS resources for establishing itself in case of its high demand?

Santosh Dornal said...

MBR/GBR comes from PCRF.

NITESH said...

Is this MBR an APN-AMBR?