Archive for July, 2010

Christine:
In sleep he sang to me
In dreams he came
That voice which calls to me
And speaks my name
And do I dream again?
For now I find
The phantom of the opera is there,
Inside my mindPhantom:
Sing once again with me
Our strange duet
My power over you
Grows stronger yet
And though you turn from me
to glance behind
The phantom of the opera is there
Inside your mind

1. If the UE is in ECM-CONNECTED and it has a dedicated bearer matching the traffic, then a request from the network will result in simply routing the downlink packets from the SGW to the eNB via the existing dedicated bearer.

2. If the UE is in ECM-CONNECTED and it does NOT have a dedicated bearer matching the traffic, then the SGW/PGW(PCRF) will initiate a dedicated bearer creation, create the bearer and route the downlink packets to the appropriate eNB.

3. If the UE is in ECM-IDLE, ONLY THEN I see this Downlink Data Notification / Downlink Data Notification Ack (…Failure Indication) exchange meaningful.

Q: Does it make any sense/When does it happen for the SGW to initiate this message exchange if the UE is NOT in ECM-IDLE?

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

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.

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

[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?

I am starting to have headaches again. First of all, I have read some of the posts from http://wired-n-wireless.blogspot.com, which is actually a great site and the owner actually works in the industry.

Second, I have taken the specs and some books and I try to understand this concept.

First of all, TAU comes from Tracking Area Update. The concept is closely related to some other concepts, which I should describe here – bear in mind that this is not an expert’s opinion, I am just the n00best person here trying to clarify stuff and hoping some nice people around the inter-web will give me a hand.

So, first things first, what is ECM and EMM? Take a look at TS 23.401.

A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state, a UE performs cell selection/reselection according to TS 36.304 [34] and PLMN selection according to TS 23.122 [10].

There exists no UE context in E-UTRAN for the UE in the ECM-IDLE state. There is no S1_MME and no S1_U connection for the UE in the ECM-IDLE state.

ECM – CONNECTED

The UE location is known in the MME with an accuracy of a serving eNodeB ID. The mobility of UE is handled by the handover procedure.

The UE performs the tracking area update procedure when the TAI in the EMM system information is not in the list of TA’s that the UE registered with the network, or when the UE handovers to an E‑UTRAN cell and the UE’s TIN indicates “P-TMSI”.

For a UE in the ECM-CONNECTED state, there exists a signalling connection between the UE and the MME. The signalling connection is made up of two parts: an RRC connection and an S1_MME connection.

The UE shall enter the ECM-IDLE state when its signalling connection to the MME has been released or broken. This release or failure is explicitly indicated by the eNodeB to the UE or detected by the UE.

Q: Now, the obvious question is: what are the conditions for the UE to switch between these states?

A: TS 23.401 says: ” The S1 release procedure changes the state at both UE and MME from ECM-CONNECTED to ECM-IDLE.” – but about the S1 release procedure later on

In the EMM‑DEREGISTERED state, the EMM context in MME holds no valid location or routeing information for the UE. The UE is not reachable by a MME, as the UE location is not known.

In the EMM-DEREGISTERED state, some UE context can still be stored in the UE and MME, e.g. to avoid running an AKA procedure during every Attach procedure.

EMM – REGISTERED

The UE enters the EMM-REGISTERED state by a successful registration with an Attach procedure to either E-UTRAN or GERAN/UTRAN. The MME enters the EMM-REGISTERED state by a successful Tracking Area Update procedure for a UE selecting an E-UTRAN cell from GERAN/UTRAN or by an Attach procedure via E-UTRAN. In the EMM-REGISTERED state, the UE can receive services that require registration in the EPS.

TRANSITIONS between States

First let’s see the transitions between these states, then look at the S1 release procedure. The pictures are shamelessly copy-pasted from the Spec [TS 23.401].

Now, further on, let’s talk about the

S1 release procedure – TS 23.401 – section 5.3.5

The message flow appears below and the result is:

– The S1-U bearers for the UE are all torn down; the S5 bearers stay active

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.

The bootstrapping procedure is described in the picture below. The UE includes the “3gpp-gba-tmpi” token in the Request message it sends to the BSF over the Ub interface, then the BSF includes this token as well in the Response.

GBA procedure

UE sends the HTTP request to the BSF, inserting an user identity, either its IMPI or its TMPI, if it has a temporary ID available;

The BSF identifies whether it received a TMPI or an IMPI; if it was a TMPI, it looks for the corresponding IMPI in its cache, and if it’s not found, it gives an error to the UE, requesting the IMPI, otherwise it continues authenticating the UE to the HSS.

Then the BSF tries to locate the HSS and retrieve the GUSS and the AV from it, where AV=(RAND||AUTN||XRES||CK||IK), over Zh;

BSF forwards the RAND and AUTN to the UE, in order to authenticate it;

The UE uses AUTN to authenticate the network, then computes the XRES, CK and IK and

sends the XRES to the BSF, in order to be authenticated by this entity and

the BSF verifies the XRES against its already computed RES; if they match, the UE is authenticated;

The BSF obtains the Ks by concatenating CK and IK, same as the UE and

replies to the UE with a B-TID in the 200 OK message;

The UE also obtains the Ks by concatenating its CK and IK

At this point, both the UE and the BSF derive the Ks_NAF key, the actual key that will be used to secure the communication between the UE and the NAF.

Ks_NAF = KDF(Ks, “gba-me”, RAND, IMPI, NAF_Id), where KDF is the key derivation function and the NAF_Id looks like this: NAF_Id = FQDN of the NAF || Ua security protocol identifier. All the values possible and structure of these components are defined in annexes to [13].