Additional GUTI and additional P-TMSI

The release 8 specifications talk about sending additional GUTI / additional P-TMSI in attach reqeusts and Tracking Area Update (TAU) or Routing Area Update (RAU) requests. So what exactly is the purpose of them?

As mentioned in the previous post, an EPS capable UE can have itself registered both in an MME and an S4-SGSN. In that case the UE's USIM will have a valid GUTI from the MME and P-TMSI and P-TMSI signature from the SGSN.

Whenever the UE does a new attach into an E-UTRAN network (or) UTRAN/GERAN network, it has two temporary identifiers. It informs one of them as an additional identifier to the MME / SGSN. Lets consider each of the cases

Attaching to MME

The UE has a valid GUTI and a valid P-TMSI. TIN = P-TMSI

In the attach request:

• Old GUTI = GUTI mapped from P-TMSI.
• Additional GUTI = GUTI. P-TMSI signature is also sent in this case

The UE has a valid GUTI and a valid P-TMSI. TIN = GUTI / RAT related TMSI

In the attach request:

• Old GUTI = GUTI at UE. No additional GUTI is sent

So what is the purpose of sending the additional GUTI in the first case above?

Since the old GUTI received by the MME is a GUTI mapped from P-TMSI, ideally it has to query the UE's identity from an S4 SGSN. But why do it if is possible for the MME to locate the subscriber's context within itself? To locate the subscriber's context it needs a GUTI that it allocated to the UE. So the additional GUTI helps (provided that additional GUTI was allocated by this MME).

Attaching to S4-SGSN

The UE has a valid GUTI and a valid P-TMSI. TIN = GUTI

In attach request:

• Old P-TMSI = P-TMSI mapped from GUTI.
• Additional P-TMSI = P-TMSI

The UE has a valid GUTI and a valid P-TMSI. TIN = P-TMSI or RAT related TMSI

In attach request:

• Old P-TMSI = P-TMSI.
• Aditional P-TMSI is also = P-TMSI if TIN = P-TMSI. The P-TMSI signature is also sent.

The usage of additional P-TMSI in the first case to look up the subscriber's context locally at SGSN instead of going to MME.

The same logic applies to TAU and RAU procedures as well.

Idle Mode Signaling Reduction

For the call flows refer Annex J in TS 23.401. Also refer this spec for an introduction to some of the terminologies used here.

What is ISR?

ISR means Idle Mode Signaling Reduction. This is a feature that allows an EPS subscriber to roam between E-UTRAN and UTRAN/GERAN coverage while in IDLE state without updating Routing Area / Tracking Area to MME / SGSN.

ISR is mandatory to be supported in an EPS capable UE but can be optionally configured in the EPC core network (S4 SGSN and MME)

Why is it needed?

The deployment of E-UTRAN network will co-exist with existing UTRAN and GERAN networks. So it is possible that within the same are a subscriber moves between E-UTRAN and UTRAN/GERAN coverage. This should not generate unnecessary signalling with the core network when the UE is in IDLE state. So what is IDLE state? It means that the UE is not having a signaling connection towards the core network (SGSN / MME). When in IDLE state,

packet transfer will not happen.

When is ISR activated?

ISR is activated ONLY on the following cases:

CASE 1

1. Subscriber is already registered in a MME (EMM-REGISTERED state at MME)
2. Subscriber is in ECM-IDLE state in the UE.
3. Subscriber does a RAU into UTRAN / GERAN. RAU request carries P-TMSI mapped from GUTI. SGSN checks if ISR is activated in the config. If yes, it returns the ISR active flag in RAU accept to UE
4. UE sees that its current TIN is GUTI and hence sets its TIN to "RAT Related TMSI"
5. SGSN sends Update Location to HSS / HLR. HLR / HSS does not send Cancel Location to MME. A release 8 HLR / HSS keeps an EPS subscriber registered at both MME and SGSN at the same time.

CASE 2

1. Subscriber is already attached in a SGSN
2. Subscriber is in PMM-IDLE state in the UE.
3. Subscriber does a TAU into E-UTRAN. TAU request carries GUTI mapped from P-TMSI. MME checks if ISR is activated in the config. If yes, it returns the ISR active flag in TAU accept to UE
4. UE sees that its current TIN is P-TMSI and hence sets its TIN to "RAT Related TMSI"
5. MME sends Update Location to HSS / HLR. HLR / HSS does not send Cancel Location to MME.

How does the UE know that ISR is activated and hence it need not do RAU / TAU while roaming within the TAI list / RAI in IDLE mode?

If TIN is set to "RAT Related TMSI" then UE knows that ISR is activated.

When does ISR get deactivated in UE?

ISR is deactivated in following scenarios

1. TIN = "RAT Related TMSI" and RAU / TAU into a new RA / TA outside of the stored TAI list / RAI. Upon successful completion of the new RAU, TIN will be set to P-TMSI. Upon successful completion of new TAU, TIN will be set to GUTI.
2. TIN = "RAT Related TMSI", periodic RAU timer expires (probably lost radio coverage in UTRAN), starts deactivate ISR timer and the deactivate ISR timer also expires. TIN will be set to GUTI
3. TIN = "RAT Related TMSI", periodic TAU timer expires (probably lost radio coverage in E-UTRAN), starts deactivate ISR timer and the deactivate ISR timer also expires. TIN will be set to P-TMSI

Will ISR be activated if current TIN is same as the temporary identifier of the RAT to which UE is doing an update procedure?

No. For example if TIN = P-TMSI, and UE does a RAU into a new RA, the SGSN returns a new P-TMSI. The context transfer is between two RAs in the same radio technology. So even if the SGSN includes the "ISR Activated" flag in RAU accept, UE should set its TIN to P-TMSI only.

How is a downlink packet delivered to the UE when it is registered with both MME and SGSN and the UE is in IDLE state?

S-GW sees that it has an active GTP-C v2 tunnel with an S4-SGSN and MME and hence it sends downlink data indication to both of them. Both SGSN and MME initiate paging. The UE responds to one of them with a service request.

Once the radio bearer establishment is completed and service request procedure is completed, the S-GW sends a stop paging request to the other RAN from which service request was not received. For example if the UE latched onto E-UTRAN,

stop paging will be sent to SGSN.

Is ISR done when roaming from MME to a Gn/Gp SGSN?

No. ISR is applicable only between MME and S4 SGSN.

Updates:

Found the book

"SAE and the Evolved Packet Core: Driving the Mobile Broadband Revolution"

covering this topic in good detail. Preview of it is available in Google books. The ISR chapter, luckily is there for preview

Back with posts on 4G to 3G/2G packet switched mobility

I have been going through the 3GPP release 8 specifications on the aspects of E-UTRAN to UTRAN/GERAN mobility. Though there are few blogs that discuss a lot about the LTE packet core (here and here), I couldnt find a blog that discusses the scenarios with respect to E-UTRAN to UTRAN/GERAN mobility.

I will start a series of blogs on the same shortly. Few interesting scenarios that are not very clear from a quick read of the specs are

1. Idle mode signaling reduction
2. S4-SGSN to S4-SGSN handoff of a EPS subscriber
3. E-UTRAN to UTRAN SRNS relocation with indirect data forwarding

The upcoming blogs will discuss about each of the above and also about GTP V2. Stay tuned.