Posts Tagged ‘eNB’

At first, I thought I was too noob to understand this stuff. I still consider myself a noob, but the way these TSs are written sometimes really gets on my nerves.

Let’s just consider the case of the S1-based handover with MME relocation and SGW relocation and Indirect Tunneling – meaning there is no X2 link between the source and target eNBs. All I can do for the moment is to look at the S11 interface, because this is the one I have the opportunity to study at this point.

So, the 2 TSs involved in this case, at least at the high  level are TS 23.401 – which describes the message flows between the SAE entities and TS 29.274 – which describes each message and its IEs.

The S1 based handover with MME/SGW relocation and Indirect Tunneling looks something like this:

55123-indir

In order to make this more human-readable, I have considered the following scenario:

mme2

where my UE (UE-1) moves from eNB 30.0.0.1 to eNB 30.0.0.5 (which have an X2 link together) – doing X2 handover (with no MME relocation), then it moves from eNB 30.0.0.5 to eNB 30.0.0.8 (which don’t have an X2 link between them). As you can see from the picture, these 2 eNBs belong to 2 different MMEs and SGWs. This means that, when the UE moves from eNB5 (30.0.0.5) to eNB8(30.0.0.8), it will generate an S1 handover signaling between the source MME – MME1 (30.0.1.1), source SGW – SGW1 (30.0.2.1), target MME – MME4 (30.0.1.4) and target SGW – SGW2 (30.0.2.2). As there is no X2 link between eNB5 and eNB5, the downlink packets coming from the PGW while the UE is in the handover process with reach eNB5, then they will be “reflected” back to SG1, which will then forward them via an “indirect” tunnel to SGW2, which will forward them to the new eNB8, which is in charge of my UE.

The flow is like this (3GPP copy-pasted 🙂 )

ts1

1)  So, as this picture states, once the handover is decided, the source MME sends a Forward Relocation Request to the target MME. This message must at least contain the following mandatory IEs, as per TS 29.274:

– IMSI

– Sender’s F-TEID for Control Plane

– MME/SGSN UE EPS PDN Connections

– SGW S11/S4 IP Address and TEID for Control Plane

– MME/SGSN UE MM Context

2) Then the target MME sends a Create Session Request message to the target SGW, including (M == Mandatory):

– IMSI (M)

– RAT Type – here is E-UTRAN (M)

– Sender F-TEID for Control Plane – here it is the IP address of the source MME: 30.0.1.4 + it’s TEID/GRE Key (this “key” is actually a hexadecimal number on 2 bytes) (M)

– APN Name (M)

– Maximum APN Restriction (M)

– LBI – Linked EPS Bearer ID – indicates the default bearer of the connection – the ID of the default bearer, usually this has value 5 (C)

– PGW S5/S8 Address for Control Plane or PMIP – this is the IP address of the PGW: 20.0.0.1 (C)

3) the target SGW replies to the target MME with a Create Session Response message, containing:

– Cause (M)

– Sender F-TEID for Control Plane – this is the IP address of the target SGW: 30.0.2.2 (C)

– APN Restriction (M)

– Bearer Contexts created (M) – this means that all the bearers that have the OK to be created for the UE in question are going to be present here, in a separate group IE; the IEs within a Bearer Context have the following:

— EBI – EPS Bearer ID (M)

— Cause (M)

— S1-U SGW F-TEID – the IP address of the SGW used for user-plane and a TEID/GRE identifier on 2 bytes – this is usually the same identifier used for the initial traffic of this user, _before_ the handover, let’s just call it Key-A – which is the uplink identifier for the user (C)

— Bearer Level QoS – the new QoS parameters, if they have been changed (C)

** Let’s stop for a second a recap. What do I have at this point? I have an UE (UE-1 in the picture) with an IP address (let’s say: 40.0.0.91). It is attached to the eNB 30.0.0.5, having a default bearer in place with the MME 30.0.1.1 (source) and the SGW 30.0.2.1 (source). This default bearer has an uplink identifier TEID, called as above Key-A, which also has a downlink identifier TEID, called Key-1. Let’s say that what travels in uplink has a key made out of letters, and what travels in downlink has keys made out of numbers 🙂

Ooook, what’s next. Well, as my UE moves to eNB 30.0.0.8, AND there is no X2 link between eNB5 and eNB8, target MME creates an indirect tunnel for the packets. Once the UE has moved to eNB8, the uplink flows directly from this new eNB, to the new SGW and so on. So, the indirect path is for the downlink packets, more precisely, for THOSE downlink packets that have already been routed by the source SGW to the source eNB (eNB5). eNB5 cannot contact eNB8 directly, so it re-routes these packets back to the source SGW, which will also re-route them via this indirect tunnel to the target SGW – which has direct S1-U connectivity to the target eNB to deliver the packets to my dear UE 🙂

How does EPC do that?

4) Target MME (30.0.1.4) sends a Create Indirect Data Forwarding Tunnel Request message to the Target SGW (30.0.2.2), containing all the grouped IEs Bearer Contexts that are to be forwarded this way, this grouped IE being the only Mandatory IE in this message. This Bearer Context IE contains:

— EBI – EPS Bearer ID (M)

— S1-U eNodeB F-TEID for data forwarding – this is the IP address of the target eNB (30.0.0.8) and its associated TEID/GRE key, let’s call it Key -2. This key instructs the target SGW about the destination of the packets for my UE (C)

5) then the Target SGW (30.0.2.2) responds to this message with a Create Indirect Data Forwarding Tunnel Response message. This message has 2 Mandatory IEs: the Cause and the Bearer Contexts grouped IE. This Bearer Context IE has:

— EBI (M)

— Cause (M)

— S1-U SGW F-TEID for data forwarding – this is the IP address of the target SGW and its TEID/GRE identifier – Key-B

6) After this, the target MME sends a Forward Relocation Response message to the source MME, instructing it about the bearers that have been accepted for creation on this indirect path

7) Now, the source MME (30.0.1.1) sends a Create Indirect Data Forwarding Tunnel Request to the source SGW (30.0.2.1), with elements similar to the corresponding message above, except that in this case, the Bearer Context has the TEID/GRE identifiers of the target SGW, contained in the Create Indirect Data Forwarding Tunnel Response from above – Key-B – when source SGW will forward the packets to target SGW, this will be the GRE Identifier used for encapsulating those packets

8) The source SGW responds with a Create Indirect Data Forwarding Tunnel Response message, same as above, but the TEID/GRE ID is the one of the IP address of the source SGW. This ID shall be used for uplink data on the indirect tunnel from the source eNB to the source SGW. Let’s call this ID Key-3.

*** At this point, we have an indirect tunnel created between the following entities:

source eNB (30.0.0.5) -> source SGW (30.0.2.1) : TEID Key-3

source SGW (30.0.2.1) -> target SGW (30.0.2.2) : TEID  Key-B

target SGW (30.0.2.2) -> target eNB (30.0.0.8) : TEID Key-2

At this point, the user traffic is like this:

traffic

1: packets already forwarded by the source SGW to the source eNB are “reflected” by this eNB – use the downlink GRE ID established initially, Key-1

2: the reflected packets from source eNB back to source SGW use the GRE negotiated via the messages above: Key-3

3: packets then travel on the tunnel from source to target SGW, via the TEID/GRE ID: Key-B

4: then the target SGW finally forwards the packets down to the target eNB via GRE ID: Key-2

*** During all this complicated process, the uplink is already using the target eNB as source for the encapsulating tunnel

So, what happens afterwards?

9) the target MME sends a Modify Bearer Request message to the target SGW, describing the newly created tunnels for downlink, not the indirect ones, the usual, direct ones and the target SGW replies with a Modify Bearer Response message in order to acknowledge (or state a cause for rejecting) this

10) the source MME deletes its session from its (source) SGW, using a Delete Session Request /  Delete Session Response pair of messages, carefully indicating the SGW that this is only a “local detach” of the UE, not a complete detach, meaning that the UE just moved and the local information about it is no longer valid, NOT that the UE disappeared from the network and the resources are to be deleted !

11) 12) both pairs of source and target MME/SGW now delete the indirect tunnel by exchanging the Delete Indirect Data Forwarding Tunnel Request / Delete Indirect Data Forwarding Tunnel Response messages.

And everybody is happy.

EXCEPT Me, because there are a lot of misleading and confusing “explanations” in the specs regarding this type of scenarios, like for instance:

a) one spec (TS 23.401) states that the delete session procedure should have Cause and LBI IEs in the Create Session Request message, while TS 29.274 defines these 2 IEs as Conditional, and, as per the condition in place, none of them should appear in this message when the source MME disconnects from the source SGW. Instead, the SGW should look at the Indication Flags in this request: if the Operation Indication is set, then this is a full detach, if the Scope Indication is set, this is a local detach.

b) look at the above flags: shouldn’t it be better to have just 1 flag, and, if it is set, we have a full detach, otherwise we have a local detach?

c) what happens in the S1 handover with no SGW relocation (whether or not the MME is relocated) and Indirect Tunneling? How is that going? Do I still send the two pairs of Create Indirect Data Forwarding Tunnel Request/Response?

and more to come

TAU dilemmas – take 3

Posted: August 10, 2010 in technical
Tags: , , , , , , , ,

PGW initiated dedicated bearer creation versus Downlink Data Notification

There are 2 scenarios that involve the “awakening” of the UE from ECM-IDLE to ECM-CONNECTED:

A. The PCRF decides the creation of a new dedicated bearer, via the Create Bearer Request message. The Spec (TS 23.401) describes this procedure in 3 places:

1. TS23.401 – 5.4.1 Dedicated bearer activation

– in step 3 (corresponding to the sending of Create Bearer Request from SGW to MME), it states that, if the UE is in ECM-IDLE, then the MME with do the “network triggered service request” procedure (5.3.4.3) first, buffering the Create Bearer Request message received from the SGW, until it awakens the UE

2. TS23.401 – 5.3.4.3 Network Triggered Service Request

– this section starts with an introduction that indicates the procedure should begin from step 3 if this procedure is triggered by a control-plane signaling coming from the SGW (like in my case); and step 3 is Paging the UE

– after this, the procedure “calls” yet another procedure, namely the UE triggered service request procedure

3. TS23.401 – 5.3.4.1 UE Triggered Service Request

– this procedure includes the NAS Service Request, the Authentication process and the setup of the bearer contexts

It’s like calling recursive procedures in programming. Very hard to follow, when trying to understand a scenario. Visually it should look something like this…

ue_trigg

B. The “second” scenarios happens (or at least to my understanding happens) specifically when there is downlink data to be sent from the SGW to the UE, without (necessarily???) having to send control-plane signaling.

In this case, the hop-by-hoping through the sections of TS 23.401 starts with

1. TS 23.401 – 5.3.4.3 Network Triggered Service Request

with Step 1

and, nevertheless, we get to

2. TS 23.401 – 5.3.4.1 UE Triggered Service Request

which is executed fully, just as in the first scenario, then the execution flows goes back to 5.3.4.3

This one should be shorter, because I only have the questions, not the answers for all 😛 . Fortunately, there is one guy that strives to make me understand stuff. Hopefully, tonight his wife won’t beat his ass and let him write a post that (hopefully) would clarify some of my dilemmas:

(10:01:13 AM) Cristina: dunno..in a few days 🙂 I still have the week-end
(10:01:28 AM) Cristina: and..more importantly..I want to understand
(10:01:42 AM) SD: how about I write a nice article describing TAU tonight
(10:01:49 AM) SD: or by early tomorrow and send it to u?

So, till then:

Q1: When does the TAU relocate MME/SGW?

A1: see table

reloc

Q2: Why doesn’t the ECM-CONNECTED relocate MME/SGW?

A2: Because, if the UE is ECM-CONNECTED and it moves to an eNB that may require the relocation of both MME and SGW, there will be a Handover taking place. This Handover will relocate the MME and the SGW (as necessary). Then, the TAU’s place comes. But at this point, the UE is already behind the new eNB and the Handover took care of the “relocation” dilemmas. So, the TAU will only update the Network with the new UE’s location, without changing MME, nor SGW.

Q3: [Timing dilemmas] Scenario:

– UE is in ECM-IDLE

– UE moves to a new TAL, so it has to do TAU with MME relocation and SGW relocation (or just one of them, but at least one is relocated via TAU)

– then UE needs to do some traffic, so it becomes ECM-CONNECTED

What happens with the Handover in this case? Does it take place anymore? And what type of Handover would be – if it takes place?

Q4: Generic dilemma: I know that TAU and Handover are “independent”. Handover is always network-triggered, while TAU can be triggered by eNB or MME. Still, it seems to me they are very connected together right now.

The TAU – Tracking Area Update procedures are defined in TS 23.401 – section 5.3.3.

MOTO: TAU – the place of my most annoying dilemmas.

Before going any further, please refer to the nice picture below (shamelessly copy-pasted from Academic Press — SAE and the Evolved Packet Core – Driving the Mobile Broadband Revolution – Magnus Olsson(2009))

TAs

In order to better manage the UE – User Equipment, EPS – Evolved Packet System has the concept of areas (this concept is not new, it was present from 3G, but it is a bit different in 4G – we’ll see how).

To my understanding (and here comes my request to the nice inter-web readers for help and clarifications):

– a tracking area is a group of cells managed by an SGW; multiple SGWs can serve the same TA and multiple TAs can be served by the same SGW

– a tracking area can be shared by more than one eNB; one eNB can also serve more than one TA

– a registration area is a list of one or more tracking areas (TAs)

– when a UE attaches to the network, the MME gives it a list of areas where it can be tracked : Tracking Area List (or Registration Area)

– an MME can manage multiple tracking areas; the purpose of the MME here being to sent the TA list to the UE when this UE is registered to the network and also update the UE with the new TA list when this UE moves around the TAs

This has importance and impacts the following situations:

– When the UE is located at the edge of an area (registration area), it can go back and forth between 2 areas, which generates a lot of signaling, as the UE is required to update its position to the EPS. By having a list of areas where the user can move without having to constantly update the EPC about its position, the amount of signaling is low.

– When UE moves frequently between 3G and 4G, it has to update his position, de-register from 4G and register in 3G and vice-versa. By keeping being registered, it can go back and forth 3G and 4G without having to signal each time its updated status.

– The UE may be in ECM-CONNECTED state or in ECM-IDLE state. No matter its state, the UE must perform the TAU – Tracking Area Update whenever it moves outside of its Registration Area (or TAL – Tracking Area List) or when a certain TAU timer expires.

The TAU procedure is described very nicely in the picture below (shamelessly copy-pasted from Academic Press — SAE and the Evolved Packet Core – Driving the Mobile Broadband Revolution – Magnus Olsson(2009))

TAU_Procedure

[I’ll get into the details later on.]

– 2 MMEs can serve an overlapping set of TAs, when both of them are connected to the same SGW
the UE receives a TAList from the SGW where it attaches and this TAList does not change, unless there happens a case of SGW relocation – when the UE receives a new TAL (this TAL may have or not some of the TAs from the former TAL; some TAs may overlap)
Just as with any usual handover, TAU as well may trigger MME relocation and/or SGW relocation:
– how/when is it possible to change MME in idle/connected states?
– how/when is it possible to change SGW in idle/connected states?

The TAU procedure is not very complicated per se, but, as we should have got used to the marvels of 3GPP Specs, the Spec only describes a scenario, preferably the most complicated one, leaving the other scenarios to the reader’s understanding. Some times simply describing the most complicated scenario won’t do the “understanding” part for the “less complicated” scenarios.

For instance, you will see below the 2 TAU scenarios: SGW relocation and no SGW relocation, but both of them have the MME relocated.

The problems are:

1. Is it possible to have a TAU procedure with no MME relocation? – the spec seems to say you can…

2. What is the actual difference in the message flows and technical design between a TAU in ECM-IDLE and a TAU in ECM-CONNECTED states?

3. [Related to item 2 above] Santosh also has a dilemma:

Spec Ambiguity
Could somebody kindly tell me if a SGW could be relocated by a TAU request in connected mode? I think not? Interested in a debate? 3GPP TS 23.401 Chapter:- 5.3.3 Cheers, Santosh
So, nice people around the inter-web, please help us here 🙂

4G – IMS

Posted: July 16, 2010 in technical
Tags: , , , , , , , , , , , , , , , ,

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.

SAE

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.

So, in the previous post I have bluntly copy-pasted from the TS 23.401. Now, I have tried to also get a shiny capture of at least part of that conversation, more exactly, on the S11/S4 interface, the one between the MME and the SGW.

In the X2-based handover the MME never changes, it is the anchor point of the X2 handover. SGW may change or not, as per TS 23.401.

A. The scenario below depicts the case where the SGW does not change, in an X2 handover. The session creation and deletion are the same as before; what is different is the Modify Bearer Request and Modify Bearer Response messages.

55112

As you can see, the SGW does not change, it is the same, MME also does not change, only eNodeBs change. The UE travels from source eNB to target eNB. The X2-based handover assumes that there is an X2 link/interface between these 2 eNBs.

The message exchange is the following

1

— At first, the downlink and uplink data of this UE flows from the (only) SGW through the source eNB, then the UE.

At this point, the UE already has a number of bearers created, at least the default one, created using the initial Modify Bearer Request – Modify Bearer Response sequence:

Screen-shot-2010-03-22-at-6.57.42-PM

 

Screen-shot-2010-03-22-at-6.58.57-PM

 

* I have assumed here the 10.10.0.51 is the S11-MME IP of the MME entity, and the 10.10.0.101 is the S11-MME IP of the SGW.

* 10.10.0.1 is the GTP-c IP of the source eNB, and 10.10.0.2 is the GTP-c IP of the target eNB.

— While the UE moves towards the margin of the source eNB range, source eNB, target eNB and UE prepare the handover. At this point, the source eNB knows it can no longer contact the UE, therefore it forwards the dowlink data it receives from the SGW, to the target eNB, which, in turn, forwards the data to the UE. At this point, the UE already forwards the uplink data to the new eNB.

— What remains to be done is to tell the SGW that the user-plane path changed. This is triggered by the target eNB, via a Path Switch Request message sent to the (only) MME. The MME then sends a Modify Bearer Request message to the SGW. This message contains the F-TEID of the user-plane having as IP address the IP of the target eNB, instructing the SGW to forward all the data for this user/bearer to this eNB. The SGW forwards this message on S5/S8 to the PGW. If the confirmation is received with Request Accepted Cause, then the SGW forwards the reply to the MME. Immediately after this, any new downlink data is forwarded by the SGW to the target eNB.

Screen-shot-2010-03-22-at-6.59.29-PM

 

Screen-shot-2010-03-22-at-7.00.14-PM

* As you can see the TEIDs of the user-plane don’t change, only the F-TEID IP of the path.

* The outer TEIDs are also the same, all that changes is the F-TEID inside the Bearer Context. This handover should be seamless for the user-plane traffic, it’s TEID should not change and packets should not be lost on the way.

— The MME sends a Path Switch Request Ack to the target eNB to acknowledge the handover.

— The latest message comes from the target eNB to the source eNB, letting it know that it can release resources for that UE.

B. When doing X2-based handover with SGW relocation, the things are a bit more complicated, because a new session needs to be created between the (only) MME and the target SGW. This means the scenario would look like this:

55113

Here as well, the user-plane traffic would be forwarded from the source eNB to the target eNB temporarily, then, once the EPS signaling updates all the states on the target SGW, the downlink will also take place through the target SGW.

2

— Before starting the EPS signaling, the UE already forwards the uplink data to the target eNB, which then forwards it to the source SGW via the S1-U interface (as the target SGW is not yet in place).

— After the Patch Switch Request from the target eNB to the MME, the MME looks for an appropriate SGW to deal with the new target eNB user-plane path. The MME finds this to be the target SGW and initiates a Create Session Request to this new entity. If the target SGW replies, the session is created, allowing the downlink data from the PGW to be forwarded to the target eNB, via the target SGW.

— At this point, the MME send a Path Switch Request Ack to the target eNB, so that the uplink data from the UE can now be forwarded from the target eNB to the target SGW.

— In the end, the target eNB signals to the source eNB to release resources for this UE and the MME deletes the session with the source SGW.

As I was saying in a previous post, one of the handover types that can take place over LTE/SAE is the X2-based handover. This type of handover takes place when the UE moves from a cell controlled by one eNodeB (let’s call it source eNB) to a cell controlled by another eNB – target eNB. When this happens, the MME cannot be changed (basic condition of an X2-based handover). Still, the MME can decide whether or not to change the SGW. This means that there are 2 types of X2-based handover: with no SGW relocation and with SGW relocation. In both of them, the existence of the X2 interface between the source and target eNB is assumed.

As per TS 23.401, the behavior in case of X2 handover is the one below:[quoted from TS 23.401 – 5.5.1 Intra-E-UTRAN handover]

5.5.1.1 X2-based handover
5.5.1.1.1 General
These procedures are used to hand over a UE from a source eNodeB to a target eNodeB using the X2 reference point. In these procedures the MME is unchanged. Two procedures are defined depending on whether the Serving GW is unchanged or is relocated. In addition to the X2 reference point between the source and target eNodeB, the procedures rely on the presence of S1-MME reference point between the MME and the source eNodeB as well as between the MME and the target eNodeB.
The handover preparation and execution phases are performed as specified in TS 36.300 [5].
When the UE receives the handover command it will remove any EPS bearers for which it did not receive the corresponding EPS radio bearers in the target cell. As part of handover execution, downlink packets are forwarded from the source eNodeB to the target eNodeB. When the UE has arrived to the target eNodeB, downlink data forwarded from the source eNodeB can be sent to it. Uplink data from the UE can be delivered via the (source) Serving GW to the PDN GW. Only the handover completion phase is affected by a potential change of the Serving GW, the handover preparation and execution phases are identical.
If the MME receives a rejection to a NAS procedure (e.g. dedicated bearer establishment/modification/release; location reporting control; NAS message transfer; etc.) from the eNodeB with an indication that an X2 handover is in progress (see TS 36.300 [5]), the MME shall reattempt the same NAS procedure either when the handover is complete or the handover is deemed to have failed. The failure is known by expiry of the timer guarding the NAS procedure.
5.5.1.1.2 X2-based handover without Serving GW relocation
This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is unchanged and decides that the Serving GW is also unchanged. The presence of IP connectivity between the Serving GW and the source eNodeB, as well as between the Serving GW and the target eNodeB is assumed.
1
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2].
1. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell, including the TAI+ECGI of the target cell and the list of rejected EPS bearers. The MME determines that the Serving GW can continue to serve the UE
2. The MME sends a Modify Bearer Request (eNodeB address(es) and TEIDs for downlink user plane for the accepted EPS bearers) message to the Serving GW. If the PDN GW requested UE’s location info, the MME also includes the User Location Information IE in this message.
The MME releases the non-accepted bearers by triggering the bearer release procedure as specified in clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL packet and does not send a Downlink Data Notification to the MME.
3. If the Serving GW has received the User Location Information IE from the MME in step 2 the Serving GW informs the PDN GW(s) about this information that e.g. can be used for charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, User Location Information IE) to the PDN GW(s) concerned. A Modify Bearer Response message is sent back to the Serving GW.
4. The Serving GW starts sending downlink packets to the target eNodeB using the newly received address and TEIDs. A Modify Bearer Response message is sent back to the MME.
5. In order to assist the reordering function in the target eNB, the Serving GW shall send one or more “end marker” packets on the old path immediately after switching the path as defined in TS 36.300 [5], clause 10.1.2.2.
6. The MME confirms the Path Switch Request message with the Path Switch Request Ack message. If the UE AMBR is changed, e.g. all the EPS bearers which are associated to the same APN are rejected in the target eNodeB, the MME shall provide the updated value of UE AMBR to the target eNodeB in the Path Switch Request Ack message.
If some EPS bearers have not been switched successfully in the core network, the MME shall indicate in the Path Switch Request Ack message which bearers failed to be established (see more detail in TS 36.413 [36]) and inititate the bearer release procedure as specified in clause 5.4.4.2 to release the core network resources of the failed EPS bearers. The target eNodeB shall delete the corresponding bearer contexts when it is informed that bearers have not been established in the core network.
7. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers the release of resources. This step is specified in TS 36.300 [5].
8. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause “Triggers for tracking area update” applies.
NOTE 2: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in ECM CONNECTED state and the MME is not changed.
5.5.1.1.3 X2-based handover with Serving GW relocation
This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is unchanged and the MME decides that the Serving GW is to be relocated. The presence of IP connectivity between the source Serving GW and the source eNodeB, between the source Serving GW and the target eNodeB, and between the target Serving GW and target eNodeB is assumed. (If there is no IP connectivity between target eNodeB and source Serving GW, it is assumed that the S1-based handover procedure in clause 5.5.1.2 shall be used instead.)
2
Figure 5.5.1.1.3-1: X2-based handover with Serving GW relocation
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2].
1. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell, including the ECGI of the target cell and the list of rejected EPS bearers. The MME determines that the Serving GW is relocated and selects a new Serving GW according to clause 4.3.8.2 on “Serving GW Selection Function”.
NOTE 2: The MME knows the S GW Service Area with a TA granularity.
2. The MME sends a Create Session Request (bearer context(s) with PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, eNodeB address(es) and TEIDs for downlink user plane for the accepted EPS bearers, the Protocol Type over S5/S8) message to the target Serving GW. The target Serving GW allocates the S GW addresses and TEIDs for the uplink traffic on S1_U reference point (one TEID per bearer). The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. If the PDN GW requested UE’s location info, the MME also includes the User Location Information IE in this message.
The MME releases the non-accepted bearers by triggering the bearer release procedure as specified in clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL packet and does not send a Downlink Data Notification to the MME.
3. The target Serving GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the PDN GW. The Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. It sends a Modify Bearer Request (Serving GW addresses for user plane and TEID(s)) message to the PDN GW(s). The S GW also includes User Location Information IE if it is present in step 2. The PDN GW updates its context field and returns a Modify Bearer Response (PDN GW address and TEID, Charging Id, MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. The PDN GW starts sending downlink packets to the target GW using the newly received address and TEIDs. These downlink packets will use the new downlink path via the target Serving GW to the target eNodeB.
4. The target Serving GW sends a Create Session Response (Serving GW addresses and uplink TEID(s) for user plane) message back to the target MME. The MME starts a timer, to be used in step 7.
5. The MME confirms the Path Switch Request message with the Path Switch Request Ack (Serving GW addresses and uplink TEID(s) for user plane) message. If the UE AMBR is changed, e.g. all the EPS bearers which are associated to the same APN are rejected in the target eNodeB, the MME shall provide the updated value of UE AMBR to the target eNodeB in the Path Switch Request Ack message. The target eNodeB starts using the new Serving GW address(es) and TEID(s) for forwarding subsequent uplink packets.
If some EPS bearers have not been switched successfully in the core network, the MME shall indicate in the Path Switch Request Ack message which bearers failed to be established (see more detail in TS 36.413 [36]) and inititate the bearer release procedure as specified in clause 5.4.4.2 to release the core network resources of the failed EPS bearers. The target eNodeB shall delete the corresponding bearer contexts when it is informed that bearers have not been established in the core network.
6. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers the release of resources. This step is specified in TS 36.300 [5].
7. When the timer has expired after step 4, the source MME releases the bearer(s) in the source Serving GW by sending a Delete Session Request message, which is acknowledged by the Serving GW.
8. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause “Triggers for tracking area update” applies.
NOTE 3: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in ECM CONNECTED state. During the TA update procedure the MME deactivates ISR because of the S GW change.

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

1

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 numberof 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

2 3 4 5 6

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 😛

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]