“Well, as we have talked about QoS, why not try to see it at work?”

“Good idea!” – says I

So, let’s take a look at the way 3GPP guys thought of a Dedicated Bearer creation. First of all, these dedicated bearers are structures that:

- have a specific QoS level

- unlike the default bearers, they can be both GBR and non-GBR (but not in the same time, of course) – default bearers can only be non-GBR (as per TS23.401)

- they should only be initiated from the APN, when a bearer is needed in order to send/receive data to/from a specific UE – actually, there is a Bearer Resource Command sent by the MME to the SGW on the S11 – GTP-C interface, which, if the SGW (after asking PCRF), is permitted, receives a Create Bearer Request message on the same S11 GTP-C interface. The MME forwards the Bearer Setup Request/Session Management Request to the eNB (on the S1 interface) – which verifies and deals with the resource allocation, exchanging RRC Connection Configuration messages with the UE. Once the eNB confirms the UE has enough resources to deal with another bearer, it informs the MME about this also, sending it a Bearer Setup Response/Session Management Response, which MME forwards to the SGW as a Create Bearer Response message… Pretty much what the following picture says:

Looking at the S11 interface that I particularly fancy, the first message of interest is the Bearer Resource Command, which has the headers described below. I am omitting the Flags header and any other header that has values described so far in the previous posts…

- Procedure Transaction ID : the ID of the transactions – new concept that appears now (here is 1)

- EBI – EPS Bearer ID : 5 is here ( should be between 5 and 15 – as you know, at most 11 bearers per UE)

- TAD - Traffic Aggregation Description: one of its fields is Operation Code, which, here, is set to Create New TFT, as the output of this transaction will be the creation of a new bearer, with an associated TFT

*** Second to think about stuff: When the PGW intends to create a new bearer (which must have attached a new TFT), it does so based on existing QoS rules on the PCRF. Well, those rules are defined on a per port basis, which means that PGW knows what type of traffic it should transport. And so do UE and MME when sending this command. So, assuming that the traffic triggering my bearer creation is HTTP only, the TFT will need to have a single TFT Filter, on port 80 as a Single Remote Port Type. Assuming that I am intending to send FTP only, the TFT will still have a single TFT Filter, but there will be a Remote port range low limit number of 20 and a Remote port range high limit of 21. Should I want to send both FTP and HTTP, there will be 2 TFT Filters.

- Flow QoS: this one sets the values requested by the MME for the following parameters:

— QCI – QoS Class Identifier – belongs to [1..255] – here is 3

— MBR-U – Maximum Bit Rate for Uplink

— MBR-D – Maximum Bit Rate for Downlink

— GBR-U – Guaranteed Bit Rate for Uplink

— GBR-D – Guaranteed bit Rate for Downlink

The reply from the SGW on this message is the Create Bearer Request from the SGW, which asks the MME to start the negotiation with the eNB in order to allocate resources for this bearer:

- it keeps the same EBI – 5 here

- it also keeps the Transaction ID – 1 here

- and the Bearer Context looks like this:

— EBI – same : 5

— Charging ID : if needed – here 0

— F-TEID of the S1 GTP-U interface of the SGW (!!! Remember that SGW has GTP-C _and_ GTP-U on its interface – which can be a single IP or different IP addresses-recommended – GTP-C does with MME and GTP-U does with eNB – in here it negotiates the GTP-U interface that the eNB will use to send data plane traffic on )

— F-TEID of the S5/S8 GTP-U interface of the SGW – which is headed towards the PGW – may be the same as the previous one or a different one

— Bearer QoS : which holds our beloved QoS values described in the previous eGTP post:

—– the QCI, MBR-U, MBR-D, GBR-U and GBR-D described above

—– the ARP – Allocation&Retention Priority

*** Please read TS23.401 – starting with page 38… Basically, this ARP should be interpreted as “The Priority of Allocation and Retention” – meaning this is a bearer prioritizer: marks a bearer as being more important than another one (the higher the number the more important the bearer); this matter when doing handovers, for instance, because, if you need to cut off some bearers (from lack of resources), you start by cutting off the ones with the smallest ARP values.

*** Still in the TS23.401 (page 38), you will find out that ARP is not a field, but a set of 3 (sub)fields:

— PVI : Pre-emption vulnerability

— PL : Priority Level

— PCI : Pre-emption capability

*** Details of each of them on TS23.401

— EPS Bearer TFT – as the TFT described above

If the MME verifies that everything is OK and the rest of the network is ready to create this new bearer, it replies to the above SGW’s message with a Create Bearer Response message, containing:

- Cause: set to 0 (Request accepted)

- Bearer context, having:

— EBI : set to 6 (the next EBI available) – ! still to verify with the TSs

— Cause: as above

— F-TEID – with the IP address of the S1-U eNB’s interface

— F-TEID – with the IP address of the S1-U SGW’s interface

And now we should be ready for traffic.

Whiiichhh, by the way, is encapsulated as GTPv1! Note to self: log a bug to 3GPP

* first picture is the content of the Bearer Resource Command

* subsequent 2 pictures are from the Create Bearer Request

* last 2 pictures are from the Create Bearer Response

[Show as slideshow]

Tags: 3GPP, ARP, bearers, EBI, eGTP, eNB, GBR, LTE, MME, non-GBR, passion, PGW, QCI, QoS, SGW, TAD, techie, TFT, UE