Posts Tagged ‘bearer’

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
25
Jan

my first eGTP test – take 2 – CreateSessionResponse

   Posted by: cristina_crow    in technical

As I was telling you about in a previous post – my first eGTP test, the reply (first reply) to a CreateSessionRequest message is a CreateSessionResponse message, described below. This message contains:

- GTPversion 2, Message Type information, in this case, this is a Response, the length of the message, the sequence number (1) and the TEID (tunnel Endpoint Identifier) – which is copied from the CreateSessionRequest message

- the Cause field indicates this is a Response for an Accepted Request – in case there would be any error, the Cause Source field would indicate the cause of the error

- PDN Address Allocation (PAA) – field which is completed at this moment  (in the CreateSessionResponse) by the SGW with the IP address of the PDN – should you remember, in the CreateSessionRequest message, this field indicated the type of address (IPv4) and value 0.0.0.0; as per 3GPP TS 29.274 – this value is a fixed IPv4/IPv6 address as indicated by the HSS registers, or it leaves the value to 0.0.0.0 indicating that the PDN GW address is assigned dynamically

- F-TEID (Fully Qualified Tunnel Endpoint Identifier) – as mentioned also in the previous post, there are 2 F-TEIDs: one for the S11 interface, and another one for the S5/S8 interface, both source IP addresses of GTP-C:

— one for the S11 interface (the one between MME and SGW) – the SGW end – the IP of the SGW from the S11 interface

— one for the S5/S8 interface (the one between SGW and PGW) – the IP address of the APN server

- APN Restriction header – as per 3GPP TS 29.274, it “denotes the restriction on the combination of types of APN for the APN associated with this EPS bearer Context.” – haven’t  used it yet, so I cannot say too much about it

- Bearer Context – information I have neglected to describe in sufficient detail in the CreateSessionRequest description. Here, in the CreateSessionResponse message, the Bearer Context header has 6 sub-headers:

— EPS Bearer ID

— Charging ID

— F-TEIDs : here both of the identifiers contain the IP address of the SGW’s S11 interface – the source GTP-U interface

— Cause : here is Request Accepted, no Cause Source

— Bearer QoS, which contains the QCI label and some other QoS identifiers that shall be described – hopefully I’ll be able to see them at work till then

Tags: , , , , , , , ,

4 Comments
4
Jan

my first eGTP test

   Posted by: cristina_crow    in technical

Today I have created my first eGTP scenario, trying to analyze the Wireshark capture and better understand this protocol…

eGTP, or GTPv2 is one of the ongoing and work in progress 3GPP standards, following the GTPv1 of UMTS, eGTP is used on the SAE architecture, GTP-c (GTP Control-Plane) between the two components of the EPS (Evolved Packet System): MME (Mobility Management Entity) and SGW (Serving Gateway) and between SGW and PGW (PDN Gateway) and GTP-u(GTP User-Plane) between eNodeB and SGW for the user traffic.

Basically, when the phone/UE (User Equipment) is turned on, it looks for a radio network. When it finds one, it signals its location and identity and tries to contact it’s home network – procedure called initial attach. During this procedure, the UE is given a permanent IP address by the PGW (PDN – Packet Data Network Gateway) – this being one of the purposes of this attach procedure. As a consequence, a (default) bearer (UMTS context) is created, a basic connection between the UE and the PGW, mainly to identify the UE in the PGW and keep track of its existence while it is connected to the network. This procedure is basically the initial registration to the network and the messages exchanged here are part of the so-called control-plane traffic.

The complete signaling scheme is triggered by the UE sending an AttachRequest to its closest eNodeB device, this forwards the request to its MME (to one of its MMEs, if there are more), then MME talks to SGW (after allocating an EPS bearer ID for the default bearer associated with the UE) and the SGW talks to PGW, in order to create a session for our user. The complete flow is presented below.

Still, what is of interest to eGTP, the flow between MME and SGW consists of only 2 messages: CreateSessionRequest and CreateSessionResponse (in case the bearer is modified, also ModifyBearerRequest and ModifyBearerResponse).

The CreateSessionRequest contains:

- identification information of the UE (IMSI, MSISDN, MEI – Mobile Equipment Identity, ULI – User Location Information)

- information regarding the radio access: the access can be E-UTRAN (where we have an eNodeB device) or other 3GPP and non-3GPP RANs

- information about the destination network /serving network (MCC – Mobile Country Code and MNC – Mobile Network Code)

- information about the path of the tunnel – where the user is to be registered; as the user is registered on the PGW, and this message (CreateSessionRequest) is sent by the MME, the next logical hop is the SGW; therefore there are 2 Fully Qualified Tunnel Endpoint Identifiers:

– one for the S11 interface (the one between MME and SGW)

– one for the S5/S8 interface (the one between SGW and PGW)

these two headers contain a field called F-TEID IPv4 (or IPv6) having as values the IP address of the next logical interface (SGW’s S11, respectively PGW’s S5/S8 interface)

- type of the final gateway (registration point): either IPv4 or IPv6

- information about the type of transaction in place, like: type of network selection, PDN address allocation (0.0.0.0 in this message on S11) and an Indication header used for future signaling in case a Handover takes place, for instance

- the APN (Access Point Name) – DNS name, APN restrictions, AMBR (Aggregate Maximum Bit Rate) – used in QoS (I’ll study this one later on), Bearer information (ID, QoS…) and a Restart Counter

Following up this message, the SGW also creates an entry for the default bearer of that UE and sends a CreateBearerRequest message to the PGW.

The CreateSessionResponse in the next chapter :P

***I have noticed that, in order to completely understand the entire flow of messages is better to follow-up a type of message from its starting point (let’s say, the UE or eNodeB triggering the flow) up until the PGW device. The message above has been caught on the S11 interface, between the MME and the SGW, but

Tags: , , , , , , , ,

5 Comments
Back to top