Posts Tagged ‘QoS’

16
Jul

4G – IMS

   Posted by: cristina_crow    in technical

The 3GPP project consists of major telecommunications organizations worldwide and one of the latest architectures described by this organization is 4G – SAE – System Architecture Evolution. SAE consists of a radio network, named LTE – Long Term Evolution and a core network, named EPC – Evolved Packet Core, a network architecture based only on IP addressing. The radio network is

out of the scope of this paper, the focus being on the components located in EPC. Another architectural design created by 3GPP is IMS – IP Multimedia Subsystem, dealing initially with VoIP signaling, and later on with multiple types of services and applications, like push-to-talk, presence and MBMS.

The figure below describes the components most commonly found in EPC, along with their IMS interaction.

EPC – IMS Architecture

As described in Figure 1, one of the main components of the EPC is the eNodeB, which has the functionality of the antenna and the controller. This component has the role of UE – User Equipment radio management, it is the first point of contact for the UE when connecting to a 4G network, it deals with the signaling for the UE management and also with the forwarding of the user-plane traffic to and from the UE. The signaling protocol specific to 4G is called GTPv2 or eGTP – evolved GTP. This protocol is present on the following EPC interfaces: S1-MME, S11 and S5/S8 and S4 (not presented in the picture, it appears between the SGSN and SGW). The user-plane protocol present in EPC is GTPv1 – user plane, and it appears on the following interfaces: S1-U and S5/S8. One or more eNodeBs (a pool of eNBs) is managed by an entity called MME – Mobility Management Entity. This device has the role of authenticating the UE to the HSS, it manages the UE sessions and controls its mobility over the network, and, unlike its homologous SGSN (Serving GPRS Support Node) device from 3G, only has role in the signaling path of the EPC, no user-plane traffic flowing through it. The MME is the entity responsible with the selection of the following entity, SGW – Serving Gateway (it’s homologous in 3G being the GGSN – Gateway GPRS Support Node). The SGW is the local mobility anchor for the UE: it manages the UE sessions and mobility, whether the UE is in active or in idle state, does QoS enforcement and forwards the control-plane and user-plane messages to the next entity, the PGW – PDN (Packet Data Network) Gateway. This entity has the role of allocating IP addresses to the UE, to route the traffic between the EPC and the PDN, to filter the traffic and assign it to different QoS classes, as well as to enforce this QoS for certain traffic. It is as well the mobility anchor for inter-working with non-3GPP technologies.

Another important aspect of the EPC is the QoS and the way it is enforced by the EPC elements. The traffic is assigned to different QoS classes based on the rules present in the PCRF. The HSS – Home Subscriber Server is a database system used to keep the SAE – related information about a certain UE, like the authentication information or the APN – Access Point Name it can connect to. Unlike HSS, the PCRF – Policy Control and Rules Function contains the charging information about a certain user subscription, information based on which the PCEF – Policy Control Enforcement Function component of the PGW provides QoS authorization (class identifiers and bitrates) and enforces this on the traffic routed through this device. In order to signal the creation of a QoS pattern for the traffic, the EPC uses the concept of bearers. A bearer is a data structure reserved on all the EPC components, it refers to the connection between a certain UE and an APN, for a certain traffic (identified by a TFT – Traffic Flow Template – a set of TCP/IP port numbers and a QoS: QCI – QoS Class Identifier and a set of uplink and downlink bit rates). The role of the bearer is to have independent classes of traffic granularly identified on the EPC components, situation useful when doing traffic shaping and for charging. One other important situation where these bearers are very useful is the handover process; the handover process is the process when an UE moves from the coverage area of an eNB to another eNB’s area. The target antenna and the connected EPC components may or may not support the bitrates and bandwidth supported before the mobility took place. In the case where the target components no longer support the services the UE had before mobility, the EPC drops some of the bearers; the decision of what bearers to drop, meaning what services will no longer be available for that user is taken based on the bearers classification, created from a field called ARP – Allocation and Retention Priority: the bearers with the poorest ARP will be the ones dropped in a situation like the one described.

The PGW connects the UE to an APN via the Gi interface. This interface is a simple IP addressing network, but the APN can be an intranet, the Internet or an IMS – IP Multimedia Subsystem network. In case this is an IMS network, the PGW will most probably be connected to the P-CSCF entity of IMS. The center of the IMS is the CSCF – Call Session Control Function, functionality divided into three components: a Proxy – P-CSCF, an Interrogating unit – I-CSCF and a Serving unit – S-CSCF. The P is the first point of contact in the IMS network, whether the user is in the home network or in roaming; it is also the entity sitting in the signaling path, being able to do message inspection, can do compression of the SIP header (SigComp) and it is the one establishing IPSec sessions to the UE. If it includes a PDF – Policy Decision Function component, it can also do media-plane QoS enforcement and bandwidth management. The S is the central SIP server of the architecture, doing registrations, inspection of the messages (as it sits in the message path) and it decides the SIP AS – Application Server which serves a certain service request. In its turn, the S is assigned to the UE by the HSS. Being in the path of the messages, the S is also responsible for charging records generation. The I is another component located at the edge of the administration domain, where the other servers locate it by doing DNS interrogations (as it uses NAPTR, DNS and SRV records). It has the role of interrogating the HSS and finding out which S that HSS is allocating for that specific user. Just as the EPC, the IMS also relies on the existence of an HSS database, as well as a PCRF system. In case there are multiple IMS networks working together, and therefore multiple HSS databases present, a new element appears – SLF – Subscriber Location Function, which has the purpose of delivering a view from all the databases in order to find information about a user. The protocol dominant in IMS is SIP – Session Initiation Protocol, standardized by IETF, having multiple extensions and improvements added to it. The protocol used to access the HSS is called Diameter, the more secure and more flexible follower of RADIUS protocol. The interfaces to HSS are all running Diameter, as well as the P interface to PCRF, Rx.

Tags: , , , , , , , , , , , , , , , ,

No Comments
17
Feb

Dedicated Bearers and QoS settings

   Posted by: cristina_crow    in technical

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

“Good idea!” – says I :P

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 :P

— 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 :P

* 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

Tags: , , , , , , , , , , , , , , , , , ,

6 Comments
16
Feb

Let’s have a talk about QoS

   Posted by: cristina_crow    in technical

Everybody knows about this Quality of Service thinggie that helps admins to classify traffic and better allocate network and system resources to accommodate traffic needs and also to enforce the policies that exist for each user/groups of users – basically according to the amount of money they pay for this service :P

In order to enforce a QoS on SAE entities, there are a few things to keep in mind:

A. PCRF – Policy Charging Rules Function device, which basically is a database that holds specific service QoS associations for each UE – this device is interrogated by the PGW in order to find out which QoS is applied on which traffic for each UE that requests a dedicated bearer

B. HSS – Home Subscriber Server, which has _nothing_ to do with QoS; this is a static database that holds information about the UE as is, and no information about any SLA of that UE with the provider

C. Only dedicated bearers hold a QoS level as part of their TFT association

D. The QoS on SAE has multiple variants, dividing the bearers into 2 groups:

– GBR bearers (Guaranteed Bit Rate)

– non-GBR bearers

E. The TFT (Traffic Flow Template – containing the filtering components for the traffic) that is associated with a bearer is not per flow, but per direction:

- TFT-UL (TFT uplink)

- TFT -DL (TFT downlink)

Also, the TFT can be:

- bearer-level

- SDF-level (service data flow level)

Now, we are interested in the GBR bearers. The GBR profile includes the following parameters:

1. QCI – QoS Class Identifier

Rules:

a. 1 QCI corresponds to 1 bearer only

b. 2 services having different QCI values can NOT be on the same bearer (TFT)

c. 2 services having the different QCI values can NOT have the same ARP (see below) value

d. QCI values must belong to [1..255]

2. ARP - Allocation & Retention Priority

Rules:

a. this value has NO influence on QoS

b. this value is set per eNB, following the PGW’s decision

c. it is established by PCRF according to a tuple of —activity type — subscription information — admission policies—

3. GBR – Guaranteed Bit Rate

4. MBR – Maximum Bit Rate

** There are also aggregated GBR bearers: AMBR (this is per APN) and UE-AMBR (the per-non-GBR, per UE rate) — [note to myself] to study more on this!

***Things to consider:

Thinking about the Mobility/Handover scenarios, keep in mind that, when a UE moves from one eNB to another, or from one MME to another, or from one SGW to another, the QoS is enforced on ALL the EPS components. This means that the QCI, ARP, GBR, MBR rates will all be verified on the resources of the destination (destination eNB, destination MME and so on). This means further on that, should at least one of the components not have enough resources to sustain all the QoS of a specific UE, some bearers will be dropped – this, again, is a decision of the SGW, taking into consideration, of course, the signaling came from the rest of the components.

[courtesy of my LTE guru colleagues]

Tags: , , , , , , , , , , , , , , , , , , , , , ,

2 Comments
Back to top