4G/LTE - Call Processing

 

 

 

Combined Attach

 

In UMTS, we had a terminology called 'Combined Registration'. It means that UE simultaneously performs registration for CS network and PS network. LTE is bascially packet only (PS only). Then what is the purpose of this 'Combined Attach" ? What does it mean ?

It means that UE performs registration for LTE network and Non-LTE network (e.g, WCDMA or GSM) simultaneously.

Why do we need this kind of simultaneous registration for two different network ? It is mainly for CS-Fallback. Unless a system operator/UE use Voice Over IMS, we use legacy network (e.g, WCDMA, GSM, C2K) for voice call. In this case, UE has to go through the registration for the legacy network. The idea of Combined Attach is to perform the attach process for LTE and Legacy Network simultaneously.

What the UE asks for in Attach Request

One field carries the whole of the request, and it is three bits wide. The UE sets it before the network has said anything, so this choice is the UE's own. The decode below is a capture of that message. The field this section is about is the red line at the bottom of it.

This attach method is specified in Attach Request and Attach Accept as follows.

 

Attach Request, decoded by a protocol tester and quoted as the author captured it. It records one message rather than specification text, so none of its values have been corrected. The red marking is the author's.

Attach request ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Attach request message identity ::= V
  | +-Message type ::= MSG [41]
  +-NAS key set identifier ::= V
  | +-TSC ::= CHOICE [native security context (for KSI ASME)]
  | +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 1]
  +-EPS attach type ::= V
  | +-Spare ::= FIX [0]
  | +-EPS attach type value ::= CHOICE [Combined EPS/IMSI Attach]
  • The header says the message is not protected : Security header type reads CHOICE [Plain NAS message, not security protected]. That is normal for the first message of an attach.
  • Protocol discriminator 7 is EPS mobility management : PD [7] sends the message to the EMM sublayer rather than to session management.
  • MSG [41] is the Attach Request message type : 24.301 Table 9.8.1 codes Attach request as 0100 0001. 0x41 is that byte.
  • The NAS key set identifier says which security context applies : TSC reads native security context (for KSI ASME). The keys therefore came from an EPS authentication rather than from a mapped context.
  • The bit above the attach type is spare : Spare ::= FIX [0] takes bit 4 of the octet. Three bits are left to say what kind of attach this is.
  • EPS attach type value is the request itself : CHOICE [Combined EPS/IMSI Attach] is what the UE sends. No other field in this message asks for the second network.

 

UE send its attach type information in at EPS attach type value IE of Attach Request. This IE has the options below, and the first two are the ones this page is about.

  • EPS Attach
  • Combined EPS/IMSI Attach
  • EPS RLOS attach
  • EPS emergency attach
  • disaster roaming attach

24.301 Table 9.9.3.11.1 codes all five of those in bits 3 to 1 of a single octet. EPS attach is 001 and combined EPS/IMSI attach is 010. EPS RLOS attach is 011, EPS emergency attach is 110, and disaster roaming attach is 111. Every other value is read as a plain EPS attach by the network. An unknown code therefore never becomes a combined attach by accident.

  • The request is three bits : 010 in bits 3 to 1 is all the UE sends. The fourth bit of that octet is spare.
  • The UE decides, not the network : 24.301 clause 5.5.1.3.1 names who may do this. It is a UE in CS/PS mode 1 or CS/PS mode 2 of operation.
  • An unknown value falls back rather than failing : the network reads every unused code as EPS attach. That is the safe direction to be wrong in.
  • A request is not a grant : the Attach Accept decides whether the second registration happened, and that is the next section.

What the network grants in Attach Accept

The answer comes back in a field the same size as the question. Two further IEs matter as much as that field. They carry the identity the UE will use on the other network. 24.301 Table 8.2.1.1 marks both of them optional, and both are present in the capture below.

To Complete the Combined Attach, Network has to specify Attach Type as CombinedEPS/IMSI attach and LAI and TMSI as shown below.

 

Attach Accept, from the same tester decode and quoted as captured. The row of dots is the author's cut, not a truncation introduced here. The mandatory IEs it hides were never recorded. Nothing has been corrected against a specification.

Attach accept ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Attach accept message identity ::= V
  | +-Message type ::= MSG [42]
  +-Spare half octet ::= V
  | +-Spare half octet ::= FIX [0]
  +-EPS attach result ::= V
  | +-Spare ::= FIX [0]
  | +-EPS attach result value ::= CHOICE [combined EPS/IMSI attach]
  .............
  +-Location area identification ::= TV OPTIONAL:Exist
  | +-Octet1 ::= DIVISION
  | | +-Location Area Identification IEI ::= IEI [13]
  | +-Octet2 ::= DIVISION
  | | +-MCC digit 2 ::= INT (0..15) [0]
  | | +-MCC digit 1 ::= INT (0..15) [0]
  | +-Octet3 ::= DIVISION
  | | +-MNC digit 3 ::= INT (0..15) [15]
  | | +-MCC digit 3 ::= INT (0..15) [1]
  | +-Octet4 ::= DIVISION
  | | +-MNC digit 2 ::= INT (0..15) [1]
  | | +-MNC digit 1 ::= INT (0..15) [0]
  | +-Octet5 ::= DIVISION
  | | +-LAC ::= INT (0..255) [0]
  | +-Octet6 ::= DIVISION
  |   +-LAC (continued) ::= INT (0..255) [0]
  +-MS identity ::= TLV OPTIONAL:Exist
  | +-Octet1 ::= DIVISION
  | | +-Mobile Identity IEI ::= IEI [23]
  | +-Octet2 ::= DIVISION
  | | +-Length of mobile identity contents ::= LEN (0..255) [5]
  | +-Octet3 ::= DIVISION
  | | +-Identity digit 1 ::= INT (0..15) [0]
  | | +-Odd/even indication ::= CHOICE [even number of identity digits and also when the TMSI/P-TMSI is used]
  | | +-Type of identity ::= CHOICE [TMSI/P-TMSI/M-TMSI]
  | +-Octet4-Octet10 ::= DIVISION
  |   +-Identity digit p ::= OCTETARRAY SIZE(0..7) [00000000]
  • MSG [42] is the Attach Accept message type : Table 9.8.1 codes Attach accept as 0100 0010.
  • EPS attach result value is the grant : CHOICE [combined EPS/IMSI attach] says the registration on the second network succeeded. 24.301 Table 9.9.3.10.1 allows one other value only, EPS only.
  • The row of dots hides the mandatory part of the message : the T3412 timer, the TAI list and the ESM message container all sit there. Table 8.2.1.1 marks every one of them M.
  • IEI 13 is Location area identification : Table 8.2.1.1 lists it as optional, format TV, six octets long. The decode shows all six.
  • Those six octets spell a PLMN and a location area code : MCC digits 1, 2 and 3 read 0, 0 and 1. MNC digits 1 and 2 read 0 and 1. That is PLMN 001/01, and LAC is zero across both of its octets.
  • MNC digit 3 is a filler rather than a digit : the value 15 fills it here. 24.008 clause 10.5.1.3 codes bits 5 to 8 of octet 3 as 1111 when the MNC has two digits.
  • IEI 23 is MS identity : format TLV, and Type of identity reads TMSI/P-TMSI/M-TMSI rather than IMSI.
  • The length field says five content octets : one octet of identity flags plus four octets of TMSI. The value printed for those four is 00000000.

The last three bullets are the combined part of the message. The result field says the request was granted. The two optional IEs carry what the grant consists of, which is a location area and an identity to use in it.

  • The result field has two values and no middle : combined EPS/IMSI attach, or EPS only.
  • The LAI is what makes the second registration usable : a location area is what the UE quotes on the legacy network. Without one it has nothing to present.
  • A CS identity arrives inside an EPS message : the TMSI belongs to the other domain, and LTE signalling delivers it.
  • Optional does not mean unimportant here : Table 8.2.1.1 marks both IEs O. Their presence is itself the evidence that the combined attach worked.

Where the LAI and the TMSI come from

The MME invents neither the location area nor the TMSI. Both come from a second node, across an interface the UE never sees. 29.118 defines that interface as SGs, and the exchange on it happens between the two messages above.

The drawing below puts the two captured messages back into the exchange they belong to. The outer arrows are the NAS messages this page has already decoded. The inner arrows are SGsAP. They are the reason the Attach Accept has a location area and a TMSI to carry.

UE MME MSC / VLR Attach Request EPS attach type value = Combined EPS/IMSI Attach SGsAP-LOCATION-UPDATE-REQUEST new location area identifier, MME starts Ts6-1 SGsAP-LOCATION-UPDATE-ACCEPT Mobile identity may carry a new TMSI, Ts6-1 stops Attach Accept EPS attach result, LAI, MS identity Attach Complete SGsAP-TMSI-REALLOCATION-COMPLETE Ts6-1

The two decoded messages are the ends of a longer exchange. SGs decides what the Attach Accept can carry, and that happens in the middle.

  • The attach type alone starts the SGs leg : 29.118 clause 5.2.2.2.1 begins the location update for non-EPS services. The trigger is an attach request indicating combined EPS/IMSI attach.
  • The MME picks the location area, not the VLR : it derives the LAI from the tracking area the UE is in. The VLR name then follows from that LAI.
  • Timer Ts6-1 bounds the wait : the MME starts it with the request and stops it on the accept. The Attach Accept waits for one of those two things.
  • The TMSI belongs to the VLR : the accept may carry a Mobile identity IE. The MME relays that IE to the UE unchanged.
  • Attach Complete finishes the procedure on both sides : the MME answers it with SGsAP-TMSI-REALLOCATION-COMPLETE. That message tells the VLR the UE holds the new TMSI.

The MME reaches a state worth naming here, because it explains what a later registration does. On the accept the MME moves the SGs association to SGs-ASSOCIATED. The trigger list in clause 5.2.2.2.1 then calls for a fresh location update in three cases only. That association is SGs-NULL, the LAI has changed, or the serving MME has changed. An association already in place over an unchanged location area meets none of those.

  • Two protocols, one procedure : NAS carries the request and the answer. SGsAP carries the part that decides what the answer says.
  • The MME is the translator : it turns an EPS attach type into a location update. It then turns the VLR's reply back into an EPS attach result.
  • The UE never sees SGs : everything it learns about the CS domain reaches it inside an EPS message.

When the network grants EPS only

A combined attach can half succeed, and the message that says so still reads as an accept. 24.301 clause 5.5.1.3.4.1 splits the outcome on the EPS attach result value alone. When that value is EPS only, an EMM cause IE beside it says why the second half failed.

Five cause values are named in clause 5.5.1.3.4.3, and the UE answers each of them differently. The differences are worth reading, because two of them end the attempt and three of them schedule a retry.

  • #2 IMSI unknown in HSS : the UE deletes any TMSI, LAI and ciphering key sequence number, and sets the update status to U3 ROAMING NOT ALLOWED. The USIM then counts as invalid for non-EPS services. That lasts until the UE is switched off or the UICC is removed.
  • #16 MSC temporarily not reachable : this is the one the SGs timer produces. 29.118 clause 5.2.2.5 makes the MME report it when Ts6-1 expires with no answer from the VLR.
  • #17 Network failure : handled exactly as #16 is. The tracking area updating attempt counter goes up, and timer T3411 or T3402 schedules the retry.
  • #18 CS domain not available : the UE sets the update status to U2 NOT UPDATED and stops trying. It attempts no combined attach and no combined tracking area update on that PLMN. The restriction lasts until the UE is switched off or the UICC is removed.
  • #22 Congestion : the attempt counter is set straight to 5 and timer T3402 starts. The retry is deliberately slow.

The retry path matters more than the cause values do. For #16 and #17 the UE does not attach again from the beginning. It starts timer T3411, and on expiry it runs a combined tracking area update indicating combined TA/LA updating with IMSI attach. That asks for the non-EPS half on its own, and the EPS half of the registration stays up throughout.

Any other cause value is an abnormal case. So is an accept that grants EPS only and carries no EMM cause IE at all. 24.301 sends both to clause 5.5.1.3.6, and treats the combined attach as failed for non-EPS services.

  • An accept can still be a partial failure : read the EPS attach result before assuming that the combined attach worked.
  • The EMM cause names which node refused : #2 points at the HSS. #16 and #18 point at the MSC or at the SGs interface, and #17 covers the rest.
  • The EPS side is never taken back : every case above leaves the UE attached for EPS. Only the non-EPS half is retried.
  • Two of the five are terminal : #2 and #18 stop the UE from asking again until it is switched off. A device that never retries is not necessarily faulty.

Reference

The clauses below are the ones this page draws on directly. Each was read in the version named. The capture on the page was compared against the message definitions rather than corrected to match them.

  • 24.301 : 3GPP - Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS), v20.0.0. Clause 5.5.1.3 (combined attach procedure), Table 8.2.1.1 (ATTACH ACCEPT message content), Table 9.8.1 (EMM message types), Table 9.9.3.10.1 (EPS attach result) and Table 9.9.3.11.1 (EPS attach type).
  • 29.118 : 3GPP - Mobility Management Entity (MME) - Visitor Location Register (VLR) SGs interface specification, v19.1.0. Clause 5.2.2 (location update for non-EPS services), which covers the SGsAP messages, timer Ts6-1 and the SGs association states.
  • 24.008 : 3GPP - Mobile radio interface Layer 3 specification; Core network protocols, v20.0.0. Clause 10.5.1.3 (Location Area Identification), which 24.301 clause 9.9.2.2 points to for the octet layout the capture shows.
  • CS Fallback : the procedure the combined attach exists to support, on this site.