This is a continuation of the 4G – IMS topic I’ve started a while back.

Still, before continuing the IMS registration started in http://www.imacandi.net/windancer/2010/08/26/4g-to-ims-call-flow-register-to-ims.html

I would like to show a preview of the Specs describing this fancy IMS thinggie.

[This information is not structured by me, but it was on tech-invite, before they decided to put a price on all that information.]

The General aspects:

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, LTE, MME, P-CSCF, passion, PCRF, PGW, Register, S-CSCF, SGW, techie, UE

As I was describing in the previous episode - 4G to IMS call flow – Register to IMS – part 1 - the IP-CAN Session Establishment is scheduled for today.

The procedure of IP-CAN (Connectivity Access Network) establishment is described in TS 23.203.

Basically, the IP-CAN is the IP address that the User Equipment gets:

- either during Initial Attach

- or at a Dedicated Bearer creation

that connects that UE to the IMS APN. There are multiple ways of getting this IP address, ways varying from DHCP/DHCPv6, PPP and so on. With regards to IMS, the IP-CAN is given by the PGW, following the PCC rules from its local PCRF.

But, before displaying the actual IP-CAN Session Establishment, let’s take a look at the functional entities and the architectures involved.

The possible scenarios when talking about PCC (Policy and Charging Control) functionality, presented in TS 23.203. I have just copied the architecture pictures. The functional entities are described separately in the same TS 23.203 spec – section 6.2. Functional Entities. I will just underline, where the case requires, which entity from this “PCC Reference Architecture” matches which entity on the 4G architecture.

Before, let’s clarify a few things about these 3 funky pictures:

The acronyms:

HPLMN == Home Public Land Mobile Network

VPLMN == Visited Public Land Mobile Network (the user is in roaming)

SPR == Subscription Profile Repository

TS 23.203 – section 6.2.4 – SPR :

The SPR logical entity contains all subscriber/subscription related information needed for subscription-based policies and IP‑CAN bearer level PCC rules by the PCRF. The SPR may be combined with or distributed across other databases in the operator’s network, but those functional elements and their requirements for the SPR are out of scope of this document.

** The SPR is connected to the PCRF via the Sp interface.

AF == Application Function

TS 23.203 – section 6.2.3 – AF:

The Application Function (AF) is an element offering applications that require dynamic policy and/or charging control over the IP‑CAN user plane behaviour. The AF shall communicate with the PCRF to transfer dynamic session information, required for PCRF decisions as well as to receive IP‑CAN specific information and notifications about IP‑CAN bearer level events. One example of an AF is the P‑CSCF of the IM CN subsystem.

** The AF is connected to the PCRF via the Rx interface.

OCS == Online Charging System

- The OCS is described in TS 32.240. In the PCC architecture we are only interested in its component called Service Data Flow Based Credit Control - its main purpose being to perform online credit control functions.

** The OCS is connected to the PCEF via the Gy interface.

PCRF == Policy Control and Charging Rules Function

TS 23.203 – section 6.2.1 PCRF:

The PCRF encompasses policy control decision and flow based charging control functionalities.

The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF.

The PCRF shall apply the security procedures, as required by the operator, before accepting service information from the AF.

…………….

Here we are talking about 2 PCRF entities:

a) there is only one PCRF involved in the first case, when the UE is NOT in roaming; this is the local/home PCRF

b) in the home routed access and local breakout scenarios there is on one hand the V-PCRF (visited) – the PCRF entity from the visited network and on the other hand the H-PCRF (home) – the PCRF entity from the home network

** The PCRF is connected to the:

- AF via the Rx interface

- SPR via the Sp interface

- BBERF via the Gxx interface

- PCEF via the Gx interface

- H-PCRF and V-PCRF are connected via the S9 interface

BBERF == Bearer Binding and Even Reporting Function

TS 23.203 – section 6.2.7 BBERF:

The BBERF includes the following functionalities:

-     Bearer binding.

-     Uplink bearer binding verification.

-     Event reporting to the PCRF.

-     Sending or receiving IP‑CAN-specific parameters, to or from the PCRF.

* Note: As far as I understand, and in order to somehow “map” the names of the “PCC” entities to the names of the “EPC” entities I’ve first learned about, I believe this BBERF role is actually played by the SGW as we know it from the EPC terminology. Please correct me if I’ve got this wrong.

CORRECTION (further reading on TS 23.203): In the GTP-based 3GPP access network the BBERF entity does NOT apply.

** The BBERF is connected to the PCRF via the Gxx interface.

PCEF == Policy and Charging Enforcement Function

TS 23.203 – section 6.2.2 PCEF:

The PCEF encompasses service data flow detection, policy enforcement and flow based charging functionalities.

This functional entity is located at the Gateway (e.g. GGSN in the GPRS case, and PDG in the WLAN case). It provides service data flow detection, user plane traffic handling, triggering control plane session management (where the IP‑CAN permits), QoS handling, and service data flow measurement as well as online and offline charging interactions.

………………

*Note: The EPC entity assuming the role of the PCEF in the PCC Architecture is the PGW.

** The PCEF is connected to the:

- PCRF via the Gx interface

- OCS via the Gy interface

- OFCS via the Gz interface

OFCS == Offline Charging System

TS 23.203 – section 6.2.6 OFCS:

The Offline Charging System is specified in TS 32.240 [3].

There may be several OFCSs in a PLMN. The default OFCS addresses (i.e. the primary address and secondary address) shall be locally pre-configured within the PCEF. OFCS addresses may also be passed once per IP‑CAN session from the PCRF to the PCEF. The addresses provided by the PCRF shall have a higher priority than the pre-configured ones.

** The OFCS is connected to the PCEF via the Gz interface.

[I'll keep the pictures numbering for future referencing.]

Figure 5.1.1 Overall PCC logical architecture (non-roaming)

This architecture describes the simplest case where the User Equipment is located in his home network – in the network of the operator he subscribed to.

Figure 5.1.2 Overl PCC architecture (roaming with home routed access)

As the picture shows, here only the BBERF (which can be an SGW or a SGSN) is located in the visited network. This implies that the local (visited) PCRF is also to be used when locating the UE. The visited PCRF will contact the home PCRF via the S9 interface.

Figure 5.1.3 Overall PCC architecture for roaming with PCEF in visited network (local breakout)

This is the case where basically the entire access network is a visited network as the UE is concerned about. The BBERF (SGW or SGSN) and the PCEF (GGSN or SGW) [at least as far as the 3GPP implementations go...WiMAX guys, please help me out complete this article] are in the visited network. This implies: the use of (at least) the local (visited) PCRF, possibly the use of a local AF and the existence of a local OFCS.

This being said, let’s see how the IP-CAN Session Establishment process takes place – shamelessly copy-pasted from TS 23.203 – section 7.2 IP-CAN Session Establishment – with the consideration that, at least this spec is concise enough when describing these procedures so that I won’t feel the need to add anything else (afaik):

** Careful with the local notes, as in this single picture there are represented the IP-CAN procedures for all the 3 roaming/non-roaming scenarios described above:

This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control Session Establishment information between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-Id and roaming agreements.

For the Local Breakout scenario (Figure 5.1.3) the V-PCRF shall proxy the Indication and Acknowledge of IP‑CAN Session Establishment over S9 between the PCEF in the VPLMN and the H-PCRF

In the non-roaming case (Figure 5.1.1) the V-PCRF is not involved.

1.   The BBERF initiates a Gateway Control Session Establishment procedure as defined in clause 7.7.1 (applicable for cases 2a during initial attach and 2b, as defined in clause 7.1).

2.   The GW(PCEF) receives a request for IP‑CAN Bearer establishment. A PDN Connection Identifier may be included in the request. The GW(PCEF) accepts the request and assigns an IP address for the user.

3.  The PCEF determines that the PCC authorization is required, requests the authorization of allowed service(s) and PCC Rules information. The PCEF includes the following information: UE Identity (e.g. MN NAI), a PDN identifier (e.g. APN), the IP‑CAN type and the IP address(es), if available, the PDN Connection Identifier received for IP‑CAN Bearer establishment and, if available, the default charging method and the IP‑CAN bearer establishment modes supported. The PDN identifier, IP address(es) and UE identity enables identification of the IP‑CAN session. The IP‑CAN Type identifies the type of access from which the IP‑CAN session is established. If the service data flow is tunnelled at the BBERF, the PCEF shall provide information about the mobility protocol tunnelling encapsulation header. The PCEF may also include the Default Bearer QoS and APN-AMBR (applicable for case 1, as defined in clause 7.1). In case 2a the PCEF may also include charging ID information.

4.   If the PCRF does not have the subscriber’s subscription related information, it sends a request to the SPR in order to receive the information related to the IP‑CAN session. The PCRF provides the subscriber ID and, if applicable, the PDN identifier to the SPR. The PCRF may request notifications from the SPR on changes in the subscription information.

5.   The PCRF stores the subscription related information containing the information about the allowed service(s) and PCC Rules information.

6.   The PCRF makes the authorization and policy decision.

7.  The PCRF sends the decision(s) , including the chosen IP‑CAN bearer establishment mode, to the PCEF. The GW(PCEF) enforces the decision. The PCRF may provide the default charging method and may include the following information: the PCC Rules to activate and the Event Triggers to report. The Policy and Charging Rules allow the enforcement of policy associated with the IP‑CAN session. The Event Triggers indicate to the PCEF what events must be reported to the PCRF.

8.   If online charging is applicable, and at least one PCC rule was activated, the PCEF shall activate the online charging session, and provide relevant input information for the OCS decision. Depending on operator configuration PCEF may request credit from OCS for each charging key of the activated PCC rules.

9.   If online charging is applicable the OCS provides the possible credit information to the PCEF and may provide re-authorisation triggers for each of the credits.

In cases 2a and 2b if the OCS provides any re-authorisation trigger, which can not be monitored at the PCEF, the PCEF shall request PCRF to arrange those to be reported by the BBERF via the PCRF.

10. If at least one PCC rule was successfully activated and if online charging is applicable, and credit was not denied by the OCS, the GW(PCEF) acknowledges the IP‑CAN Bearer Establishment Request.

11. If network control applies the GW may initiate the establishment of additional IP-‑CAN bearers. See Annex A and Annex D for details.

12.  If the PCRF in step 7 requested an acknowledgement based on PCC rule operations, the GW(PCEF) sends the IP‑CAN Session  Establishment Acknowledgement to the PCRF in order to inform the PCRF of the activated PCC rules result.

Many more information on this on TS 23.203. Insist on the QoS parameter interaction.

Specially: Annex 4. 3GPP Accesses (GERAN/UTRAN/E-UTRAN) GTP-based EPC

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, LTE, MME, P-CSCF, passion, PCRF, PGW, Register, S-CSCF, SGW, techie, UE

So, let’s talk about 4G and IMS. This will describe the registration to the IMS core, when the IMS equipment is located in a Visited Network, in roaming.

The normal lines (and arrows) represent the main protocol:

- while in the 4G environment (UE, eNodeB, MME, SGW, PGW): it is eGTP (GTPv2-C) protocol

- while in the IMS environment(P-CSCF, I-CSCF, S-CSCF, HSS): it is plain IP or Diameter protocol

The dotted lines (and arrows) represent the inner IP protocol messages, which are encapsulated in GTPv1-U header.

The specs impacted by this are:

TS 23.401 : for the 4G UE equipment Initial Attach to the network

TS 23.203 : description of the IP-CAN Session Establishment procedures

TS 23.228 : description of the P-CSCF Discovery procedures

TS 21.905 : vocabulary for 3GPP Specifications

TS 29.061 : interworking of 4G and IMS

TS 29.212 : PCC (Policy and Charging Control) over Gx interface

TS 29.213 : PPC signaling flows and QoS parameters

TS 24.229 : IP multimedia call control over SIP and SDP

RFC 3261 : SIP – Session Initiation Protocol

The IMS protocols are just too many and diverse to list here all the TSs and RFCs related to them.

Let’s describe – shortly, very shortly – the messages exchanged here:

[Some of the message descriptions are simply and shamelessly copy-pasted from the spec :p  ]

1. Attach Request [TS 23.401]

2. Attach Request [TS 23.401]

The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected Network. If that MME is not associated with the eNodeB or the old GUMMEI is not available, the eNodeB selects an MME as described in clause 4.3.8.3 on “MME selection function”. The eNodeB forwards the Attach Request message to the new MME contained in a S1-MME control message (Initial UE message) together with the Selected Network and TAI+ECGI of the cell from where it received the message to the new MME.

3. Create Session Request [TS 23.401]

If a subscribed PDN address is allocated for the UE for this APN, the PDN subscription context contains the UE’s IPv4 address and/or the IPv6 prefix and optionally the PDN GW identity. In case the PDN subscription context contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in the PDN address. For Attach Type indicating “Initial Attach”, if the UE does not provide an APN, the MME shall use the PDN GW corresponding to the default APN for default bearer activation. If the UE provides an APN, this APN shall be employed for default bearer activation. For Attach type indicating “Handover”, if the UE provides an APN, the MME shall use the PDN GW corresponding to the provided APN for default bearer activation, If the UE does not provide an APN, and the subscription context from HSS contains a PDN GW identity corresponding to the default APN, the MME shall use the PDN GW corresponding to the default APN for default bearer activation. The case where the Attach type indicates “Handover” and the UE does not provide an APN, and the subscription context from HSS does not contain a PDN GW identity corresponding to the default APN constitutes an error case. If the attach type indicates “Initial Attach” and the selected PDN subscription context contains no PDN GW identity the new MME selects a PDN GW as described in clause 4.3.8.1 on PDN GW selection function (3GPP accesses). If the PDN subscription context contains a dynamically allocated PDN GW identity and the Attach Type does not indicate “Handover” the MME may select a new PDN GW as described in clause PDN GW selection function, e.g. to allocate a PDN GW that allows for more efficient routing. The new MME selects a Serving GW as described in clause 4.3.8.2 on Serving GW selection function and allocates an EPS Bearer Identity for the Default Bearer associated with the UE. Then it sends a Create Session Request (IMSI, MSISDN, MME TEID for control plane, PDN GW address, PDN Address, APN, RAT type, Default EPS Bearer QoS, PDN Type, APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information (ECGI), MS Info Change Reporting support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, the Protocol Type over S5/S8) message to the selected Serving GW.

The RAT type is provided in this message for the later PCC decision. The subscribed APN AMBR for the APN is also provided in this message. The MSISDN is included if provided in the subscription data from the HSS. Handover Indication is included if the Attach type indicates handover. Selection Mode indicates whether a subscribed APN was selected, or a non-subscribed APN sent by the UE was selected.. Charging Characteristics indicates which kind of charging the bearer context is liable for. The MME may change the requested PDN type according to the subscription data for this APN as described in clause 5.3.1.1. The MME shall set the Dual Address Bearer Flag when the PDN type is set to IPv4v6 and all SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing, which is determined based on node pre-configuration by the operator. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.

The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of handling Charging Characteristics and whether to send them or not to the P GW is defined in TS 32.251 [44]. The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S GW and/or P GW trace is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC.

The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4 of TS 23.060 [7]). If the P GW receives the Maximum APN Restriction, then the P GW shall check if the Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with sending an appropriate error cause to the UE.

NOTE 7: The Dual Address Bearer Flag is not used when the Protocol Type over S5/S8 is PMIP.

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, LTE, MME, P-CSCF, passion, PCRF, PGW, Register, S-CSCF, SGW, techie, UE

TS 29.061, more precisely the Interworking between PGW and PDN, sections 11 to 13.

TS 23.401, sections 5.3.1 – IP Address Allocation, 5.3.2 – Attach Procedure

It seems that:

1. an UE can simultaneously connect to multiple APNs;

2. an UE can have multiple default bearers per APN connection: for example, one for IPv4 and one for IPv6;

2.a) 2 default bearers per APN connection are possible when the MME does NOT set the Dual Address Bearer Flag; this way, the MME forces the sending of separate IPv4 and IPv6 requests for PDN connectivity;

2.b) if the MME sets the Dual Address Bearer Flag, then it can send a request with dual-stack IPv4v6 and the APN can provide both of these IP addresses at once – this means that there are 2 IP addresses (one IPv4 and one IPv6 ONLY one of each type !) for a SINGLE default bearer;

3. Allocation of these IP addresses to the UE can happen from a local PGW pool or from the PDN. In the later case, the Create Session Response message sent from the PGW to the SGW (and further on to the MME) has PAA = 0.0.0.0, following the later completion of this address;

3.a) If the PGW has nothing to do with the further negotiation of the IP addresses, we are talking about a direct transparent access IP allocation; the PGW is just a proxy;

3.b) If the PGW is actively (protocol dependent) implicated in the IP address allocation, then we are talking about a non transparent access; the PGW is an active part in the IP negotiation: for instance, it may act as a DHCP server for the UE (via SGW, of course) and in the same time as DHCP client – when talking to the APN’s actual DHCP server;

*Note: the role of the PGW in the DHCP allocation case is different from the role of its 3G homologous, the GGSN – this entity playing the role of a DHCP relay agent in this scenario;

*Note: We are talking about the so-called IP-CAN (Connectivity to Access Network) session establishment – which, as far as I understand from TS 29.061, refers to the process of allocating an IP address (IPv4, IPv6 or IPv4v6) by a process other than gathering it from the PGW pool, for instance: via DHCP/DHCP-PD, PPP, IMS CN IM process…etc…

4. IP-CAN can be established at:

a) Initial Attach (default bearer activation) to the APN (in EPC) – Primary PDP Context Activation to the APN (in 3G)

b) after the initial attach, via a dedicated bearer/secondary PDP context

5. The IP assignment can take place:

a) either at the subscription phase – in which case we are talking about a static address

b) or at the IP-CAN session establishment – in which case we are talking about a dynamic address

*Note: Usually, as part of the IP-CAN negotiation ( no matter if this takes place at initial attach of afterwards), the PGW may request the UE to authenticate to the external APN’s AAA server

Tags: dedicated bearer, default bearer, DHCP, IMS, LTE, MME, passion, PDN, PGW, SAE, SGW, techie, UE

Uplink data while in ECM-IDLE

I know this sounds (at least a bit) weird. Why? Because the nice fellows from 3GPP state bravely that ECM-IDLE means NO USER-PLANE Bearers. Mwell, that’s not precisely (nor entirely) true.

Should you look at TS 23.401 – 5.3.5 S1 Release Procedure, the introduction states:

This procedure is used to release the logical S1-AP signalling connection (over S1-MME) and all S1 bearers (in S1-U) for a UE. The procedure will move the UE from ECM-CONNECTED to ECM-IDLE in both the UE and MME, and all UE related context information is deleted in the eNodeB.

Unfortunately, this is not exhaustive. The things described here DO happen, but something ELSE DOES NOT happen.

Step 3 in the procedure clarifies the situation:

3.   The S‑GW releases all eNodeB related information (address and TEIDs) for the UE and responds with a Release Access Bearers Response message to the MME. Other elements of the UE’s S‑GW context are not affected. The S‑GW retains the S1-U configuration that the S‑GW allocated for the UE’s bearers. The S‑GW starts buffering downlink packets received for the UE and initiating the “Network Triggered Service Request” procedure, described in clause 5.3.4.3, if downlink packets arrive for the UE. If the MME sends UE’s Location Information in step 8, the S‑GW sends a Modify Bearer Request to the PDN GW including the User Location Information IE.

Ok, so the 3GPP guys let us believe the ECM-IDLE ==EQUALS== NO user-plane bearers. OK, point taken, there are some bearers still up.

Buuut, this affects us when talking about the following scenario:

Take a look at the TS 23.401 – 5.3.4.1 UE Triggered Service Request. What is this section actually describing? Well, it says that the UE, while in ECM-IDLE simply decides to make traffic. What does it do first? Well, it has to become CONNECTED, that’s for sure, so it re-authenticates to the HSS via the MME, then the MME sends its eNB a S1-AP: Initial Context Setup Request. After the Radio Bearers are up, the UE CAN IMMEDIATELY SEND TRAFFIC in UPLINK.

!!! You will notice that, at this point, the UE is not in ECM-CONNECTED, as we define this state, meaning that there are no eNB S1-U bearers up. STILL, should you keep in mind the observations in the beginning of this post (that the SGW S1-U TEIDs are NOT deleted in the S1 Release Procedure), the eNB actually has the Uplink TEID, so it CAN encapsulate the Uplink data of this UE. The TEID of the SGW S1-U interface is passed on to the eNB by the MME, via the S1-AP: Initial Context Setup Request message.

[Show as slideshow]

You’ll notice that barely after the UE actually uplinks data is the MME and SGW updating this UE’s information so that we can truly say it is in ECM-CONNECTED state.

Tags: ECM-CONNECTED, ECM-IDLE, HSS, LTE, MME, passion, SAE, SGW, techie, UE, UE triggered service request

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…

[Show as slideshow]

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

Tags: eNB, LTE, MME, Paging, passion, SAE, SGW, techie, UE

Consider:

1. the UE is in ECM-IDLE mode

2. the network decides to delete some of the UE’s bearers, by sending a Delete Bearer Request message to the MME managing this UE

Question:

- Will the UE first be woken-up from ECM-IDLE and become CONNTECTED, and then the Delete Bearer Request is processed and responded? Or simply the MME will process the Delete Bearer Request message and NOT put the UE in ECM-CONNECTED?

Tags: Delete Bearer Request, ECM-CONNECTED, ECM-IDLE, LTE, MME, passion, SAE, SGW, TAU, techie

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

Relocation_States

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.

Tags: ECM-CONNECTED, ECM-IDLE, eNB, handover, MME, mobility, SGW, TAU, techie, UE

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

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.]

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:

So, nice people around the inter-web, please help us here

Tags: dilemma, ECM, EMM, eNB, LTE, MME, SAE, SGW, TAU, techie, Tracking Area Update, UE