The Attach Type indicates the purpose of the attach and as in most of other procedure, the attach type is also determined by a kind of mutual agreement between UE and Network. It means that UE indicates the attatch type I want to get and Network finaly determines available attach type and informs it to UE as in following procedure.

That agreement is narrower than it sounds, and it is worth knowing the shape of it before reading any of the captures below. The UE asks with one three-bit field in the ATTACH REQUEST. The network answers with a different three-bit field in the ATTACH ACCEPT, and the answer field carries fewer values than the request field does. So the network cannot always reply in the same terms the UE used. It can grant less than was asked for, and most of this page is about what happens when it does.

Followings are the topics :

• What are the attach types, and what does each one ask for ?
• How do the UE and the network agree on the attach type ?
• What happens when the network grants less than the UE asked for ?
• How is EPS emergency attach different ?
• What are EPS RLOS attach and disaster roaming attach ?
• Reference

What are the attach types, and what does each one ask for ?

Let's start with the field itself, because everything else on this page depends on it. The UE puts the attach type into the ATTACH REQUEST as a three-bit value, and 24.301 Table 9.9.3.11.1 says what each value means. The UE chooses that value before the network has said anything at all. So the attach type records what the UE wants, not what it gets.

There are three different types of attach as listed below.

• EPS attach : indicate the attach for EPS services only)
• Combined EPS/IMSI attach  : indicate the attach for both EPS and non-EPS services
• EPS emergency attach : indicate the attach for emergency bearer services

Those three are the original Release 8 set, and they still cover almost every attach you will meet in a live log. 24.301 has added two more values to the same field since then. The table below lists all five the way Table 9.9.3.11.1 codes them, so you can read a decoder line straight off it.

Two notes belong with that table. Bit 4 of the octet is spare and is coded as zero. The network reads any value other than the five above as "EPS attach". That rule is what keeps an old MME working in front of a new UE.

The difference between the first two values is the CS domain. A plain EPS attach registers the UE with the MME and stops there. A combined EPS/IMSI attach also asks the MME to register the UE with the MSC/VLR, across the SGs interface. CS fallback and SMS over SGs both depend on that registration. The UE does not choose between them freely. A UE in PS mode of operation sends EPS attach. A UE in CS/PS mode 1 or CS/PS mode 2 sends combined EPS/IMSI attach, because it wants the CS domain available. Combined EPS/IMSI attach has a page of its own.

One more case exists that the field has no value for. Clause 5.5.1.1 lists an attach for EPS services and "SMS only", used by a UE that supports NB-S1 mode only. The UE marks it in a separate IE instead. It sets the AUTV bit of the Additional update type IE to "SMS only" (Table 9.9.3.0B.1). So the attach type alone does not always tell you the whole request.

• The attach type is a request, not a result : the UE picks one value before the network has replied. The field says what the UE wants.
• Only the CS domain separates the first two values : a plain EPS attach stops at the MME. A combined EPS/IMSI attach also registers the UE with the MSC/VLR over SGs.
• The UE's mode of operation decides which one it sends : PS mode of operation sends EPS attach. CS/PS mode 1 or mode 2 sends combined EPS/IMSI attach.
• Two values arrived after Release 8 : EPS RLOS attach and disaster roaming attach share the same three bits. A network that does not know a value reads it as EPS attach.

How do the UE and the network agree on the attach type ?

Now let's follow the two messages that carry the agreement. The UE sends its request in the first NAS message of the call, and the network answers in the ATTACH ACCEPT. Each value shares an octet with something else, which is why both look cramped in a decoder. The table below shows where the two messages sit in the call.

The reply does not reuse the request IE. 24.301 Table 9.9.3.10.1 defines a separate EPS attach result, and it holds only two values.

Every other value of that field is reserved. Put the two tables side by side and the asymmetry is obvious. The UE can send five values, and the network can answer with two. The network cannot reply "emergency" or "RLOS" in this field, because no such value exists in it. It also cannot grant more than the UE asked for, so an EPS attach never comes back as a combined one. What it can do is answer a combined request with "EPS only", and that single case is the one worth studying.

Attach Request

The listing below is one real ATTACH REQUEST rather than a specification extract. Read the highlighted line first. That is the attach type, sharing an octet with the NAS key set identifier and a spare bit. Everything after it is identity and capability, and those IEs appear in every attach whatever type it carries.

< Attach Request > NAS capture. Field values come from a live capture, not from the specification.

NAS EPS Mobility Management Message Type: Attach request (0x41)
 0... .... = Type of security context flag (TSC): Native security context (for KSIasme)
 .100 .... = NAS key set identifier:  (4)
 .... 0... = Spare bit(s): 0x00
 .... .010 = EPS attach type: Combined EPS/IMSI attach (2)
 EPS mobile identity
     Length: 11
     .... 0... = odd/even indic: 0
     .... .110 = Type of identity: GUTI (6)
     Mobile Country Code (MCC): Unknown (1)
     Mobile Network Code (MNC): Unknown (01)
     MME Group ID: 32769
     MME Code: 0
     M-TMSI: 0x00000001
 UE network capability
     Length: 4
     1... .... = EEA0: Supported
     .1.. .... = 128-EEA1: Supported
     ..1. .... = 128-EEA2: Supported
     ...0 .... = 128-EEA3: Not Supported
     .... 0... = EEA4: Not Supported
     .... .0.. = EEA5: Not Supported
     .... ..0. = EEA6: Not Supported
     .... ...0 = EEA7: Not Supported
     0... .... = EIA0: Not Supported
     .1.. .... = 128-EIA1: Supported
     ..1. .... = 128-EIA2: Supported
     ...0 .... = 128-EIA3: Not Supported
     .... 0... = EIA4: Not Supported
     .... .0.. = EIA5: Not Supported
     .... ..0. = EIA6: Not Supported
     .... ...0 = EIA7: Not Supported
     1... .... = UEA0: Supported
     .1.. .... = UEA1: Supported
     ..0. .... = UEA2: Not Supported
     ...0 .... = UEA3: Not Supported
     .... 0... = UEA4: Not Supported
     .... .0.. = UEA5: Not Supported
     .... ..0. = UEA6: Not Supported
     .... ...0 = UEA7: Not Supported
     0... .... = UCS2 support (UCS2): The UE has a preference for the default alphabet
     .1.. .... = UMTS integrity algorithm UIA1: Supported
     ..0. .... = UMTS integrity algorithm UIA2: Not Supported
     ...0 .... = UMTS integrity algorithm UIA3: Not Supported
     .... 0... = UMTS integrity algorithm UIA4: Not Supported
     .... .0.. = UMTS integrity algorithm UIA5: Not Supported
     .... ..0. = UMTS integrity algorithm UIA6: Not Supported
     .... ...0 = UMTS integrity algorithm UIA7: Not Supported

Attach Accept

The answer is much shorter, and again the field to read is near the top. The attach result shares its octet with a spare half octet, so a decoder shows it as the low three bits. In this capture the network grants exactly what the UE asked for. That is the straightforward outcome, and a useful baseline for the section that follows.

< Attach Accept > NAS capture. Field values come from a live capture, not from the specification.

NAS EPS Mobility Management Message Type: Attach accept (0x42)
0000 .... = Spare half octet: 0
.... 0... = Spare bit(s): 0x00
.... .010 = Attach result: Combined EPS/IMSI attach (2)
GPRS Timer - T3412 value
    GPRS Timer: timer is deactivated
        111. .... = Unit: value indicates that the timer is deactivated (7)
        ...0 0000 = Timer value: 0
Tracking area identity list - TAI list
    Length: 6
    0... .... = Spare bit(s): 0x00
    .00. .... = Type of list: list of TACs belonging to one PLMN,
                              with non-consecutive TAC values (0)
    ...0 0000 = Number of elements: 0 [+1 = 1 element(s)]
    Mobile Country Code (MCC): Unknown (1)
    Mobile Network Code (MNC): Unknown (01)
    Tracking area code(TAC): 0x0001

• The request field and the result field are different IEs : the UE sends EPS attach type, which has five values. The network replies with EPS attach result, which has two.
• The network can grant less, never more : it may answer a combined request with "EPS only". It cannot turn an EPS attach into a combined one.
• Both fields share an octet with something else : the attach type sits beside the NAS key set identifier, and the attach result beside a spare half octet. Each appears as the low three bits.
• Match the two captures field by field : reading the request and the accept together shows whether the network agreed to what was asked.

What happens when the network grants less than the UE asked for ?

This is the case that produces support tickets. The UE asked for a combined EPS/IMSI attach, the attach succeeded, and data works perfectly. What does not work is SMS, or a voice call over CS fallback. Nothing in the log looks like a failure, because nothing failed. The whole explanation is one field and one cause value inside the ATTACH ACCEPT.

24.301 clause 5.5.1.3.4.3 covers it, under the heading "Combined attach successful for EPS services only". The network sets the EPS attach result to "EPS only" and adds an EMM cause that says why the non-EPS half did not succeed. Four cause values appear here, and the UE reacts differently to each one.

Cause #2 "IMSI unknown in HSS" is the harshest of the four. The UE sets its update status to U3 ROAMING NOT ALLOWED and deletes any stored TMSI, LAI and ciphering key sequence number. The USIM then counts as invalid for non-EPS services until the UE is switched off, the UICC is removed, or timer T3245 expires. There is a further effect for a UE in CS/PS mode 1 of operation with "IMS voice not available". It also disables its E-UTRA capability. That is why one cause value can leave a handset with no LTE service at all.

Cause #16 "MSC temporarily not reachable" and cause #17 "Network failure" share one paragraph in the specification, and both are temporary. The UE increments the tracking area updating attempt counter and starts timer T3411. When T3411 expires it runs a combined tracking area updating procedure instead of a fresh attach. Once the counter reaches 5 the UE waits on the longer timer T3402 before trying again. So a UE that sees #16 or #17 keeps asking, just more slowly.

Cause #18 "CS domain not available" is the flat refusal. The UE resets the attempt counter and sets its MM update status to U2 NOT UPDATED. It then stops attempting combined procedures on that PLMN until it is switched off or the UICC changes. That last part is the useful one when reading a log. Once a UE has seen #18, it will not ask again. So a single ATTACH ACCEPT near the start of a session can explain hours of missing SMS.

There is also a softer version of the same answer, and it is easy to miss because the attach result looks clean. The network can grant the combined attach and still qualify it, through the Additional update result IE of Table 9.9.3.0A.1. That field takes "no additional information", "CS Fallback not preferred" or "SMS only". With "SMS only" the UE is registered with the MSC/VLR for short messages but must not use CS fallback for voice. So an attach can report "combined EPS/IMSI attach", succeed on every count, and still leave CS fallback unavailable.

All of this assumes the attach was accepted. When the network refuses outright, the message is an ATTACH REJECT with its own cause value. Attach Reject covers what the UE does with each one.

• A successful attach can still be a partial one : the EPS attach result reads "EPS only" while the attach itself is accepted. Nothing in the log resembles an error.
• The EMM cause tells you whether the UE will retry : causes #16 and #17 are temporary and drive a retry through T3411. Cause #18 stops the UE asking again on that PLMN.
• Cause #2 can push the UE off LTE entirely : it invalidates the USIM for non-EPS services until switch-off. A CS/PS mode 1 UE without IMS voice disables E-UTRA as well.
• Check the Additional update result before blaming the attach result : a combined attach reported as successful can still carry "SMS only". That leaves CS fallback unavailable.

How is EPS emergency attach different ?

Emergency attach removes the assumption behind the other two. Everywhere else the network has a subscription to check and the UE has credentials to prove. Here the UE may have neither, and the procedure still has to complete. That one change affects which identity the UE sends and what the network is allowed to refuse.

The UE sets the attach type to "EPS emergency attach", and the identity rule relaxes along with it. If the UE holds no valid GUTI, no P-TMSI and no IMSI, it puts its IMEI into the EPS mobile identity IE instead. A device with no USIM at all can therefore attach, which is the entire point of the mechanism.

The network keeps two ways to say no. An MME may not support attach for emergency bearer services at all. It then rejects any ATTACH REQUEST carrying this attach type. Another MME may support them and still refuse an IMEI. It answers with ATTACH REJECT and EMM cause #5 "IMEI not accepted". So an emergency attach from a UE with no USIM depends on an operator policy decision, not only on radio coverage.

One detail matters when you read a capture. The accept never echoes the word emergency, because the EPS attach result field has no such value. The attach type in the request is the only place the emergency intent is visible. There is also a second route to emergency bearers, and it does not touch this attach type at all. An ordinary attach carries a PDN CONNECTIVITY REQUEST with request type set to "emergency". The two look quite different in a log, and 24.301 handles them in separate clauses.

• Emergency attach can run without a USIM : with no valid GUTI, P-TMSI or IMSI, the UE sends its IMEI instead.
• The network may still refuse : an MME without emergency bearer support rejects the attach type outright. One that refuses an IMEI answers with EMM cause #5.
• The accept message never says "emergency" : the EPS attach result holds only two values. So the request is where you confirm the intent.
• An emergency PDN is not the same as an emergency attach : a normal attach can instead carry a PDN CONNECTIVITY REQUEST with request type "emergency".

What are EPS RLOS attach and disaster roaming attach ?

Two values in Table 9.9.3.11.1 arrived long after the rest, and most deployed networks will never send or accept either one. They are still worth knowing, because a modern decoder prints them by name and because both reuse the same three bits as the familiar values. Both also exist for one reason: to give a UE limited service where a normal attach would be refused.

EPS RLOS attach is value 011. RLOS stands for Restricted Local Operator Services. 24.301 treats a UE as attached for RLOS once it asked for that access during attach and ended up with a PDN connection for RLOS. The service is deliberately narrow. It lets an operator offer something small to a UE it will not otherwise serve, such as a page for topping up an account. The backward compatibility rule is the part to remember: a network without RLOS support reads value 011 as plain "EPS attach". An unsupported RLOS request therefore does not fail visibly. It quietly becomes an ordinary attach.

Disaster roaming attach is value 111, which earlier releases listed as reserved. It belongs to the disaster roaming feature. A UE attaches to another PLMN that agreed to carry those subscribers, once its own PLMN has become unavailable. The UE sends it only when disaster roaming is enabled and it holds a list of PLMNs to use in a disaster condition. An older network has no definition for 111, so the catch-all rule applies and it reads the value as "EPS attach" as well.

That catch-all is the practical lesson from both values. 24.301 has the network read any value outside the five defined ones as "EPS attach", and the RLOS note says the same thing explicitly for 011. Together they mean a UE asking for something new never receives an explicit refusal of its attach type. It receives a plain EPS attach, and it must notice for itself that the request was not understood.

• Both values reuse the same three-bit field : RLOS attach is 011. Disaster roaming attach is 111, which earlier releases listed as reserved.
• RLOS buys restricted service, not normal service : the UE ends up with a PDN connection for RLOS only. That is how an operator can offer something to a UE it will not fully serve.
• An unsupported request degrades silently : a network without RLOS support reads 011 as "EPS attach". The catch-all rule does the same for any value it does not recognise.
• Disaster roaming depends on UE configuration : the UE sends 111 only when the feature is enabled. It also needs a list of PLMNs to use in a disaster condition.

Reference

One specification carries every rule quoted on this page. The clause and table numbers sit beside each claim above, so the wording can be checked rather than taken on trust.

• 24.301 - Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3, v20.0.0. Clause 5.5.1.1 lists the purposes the attach procedure serves. Table 9.9.3.11.1 is the EPS attach type values and Table 9.9.3.10.1 the EPS attach result values. Clause 5.5.1.3.4.3 is the combined attach that succeeds for EPS services only, with EMM causes #2, #16, #17 and #18. Table 9.9.3.0A.1 is the Additional update result IE and Table 9.9.3.0B.1 the Additional update type IE.