10.5.5 GPRS mobility management information elements

04.083GPPMobile radio interface Layer 3 specificationRelease 1998TS

10.5.5.1 Attach result

The purpose of the attach result information element is to specify the result of a GPRS attach procedure.

The attach result is a type 1 information element.

The attach result information element is coded as shown in figure 10.5.117/3GPP TS 04.08 and table 10.5.134/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Attach result
IEI

0
spare

Result of attach

octet 1

Figure 10.5.117/3GPP TS 04.08: Attach result information element

Table 10.5.134/3GPP TS 04.08: Attach result information element

Result of attach (octet 1)

Bits

3 2 1

0 0 1 GPRS only attached

0 1 1 Combined GPRS/IMSI attached

All other values are reserved.

10.5.5.2 Attach type

The purpose of the attach type information element is to indicate the type of the requested attach, i.e. whether the MS wants to perform a GPRS or combined GPRS attach.

The attach type is a type 1 information element.

The attach type information element is coded as shown in figure 10.5.118/3GPP TS 04.08 and table 10.5.135/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Attach type
IEI

0
spare

Type of attach

octet 1

Figure 10.5.118/3GPP TS 04.08: Attach type information element

Table 10.5.135/3GPP TS 04.08: Attach type information element

Type of attach (octet 1)

Bits

3 2 1

0 0 1 GPRS attach

0 1 0 GPRS attach while IMSI attached

0 1 1 Combined GPRS/IMSI attach

All other values are interpreted as GPRS attach in this version of the protocol.

10.5.5.3 Ciphering algorithm

The purpose of the ciphering algorithm information element is to specify which ciphering algorithm shall be used.

The ciphering algorithm is a type 1 information element.

The ciphering algorithm information element is coded as shown in figure 10.5.119/3GPP TS 04.08 and table 10.5.136/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Ciphering algorithm
IEI

0
spare

Type of algorithm

octet 1

Figure 10.5.119/3GPP TS 04.08: Ciphering algorithm information element

Table 10.5.136/3GPP TS 04.08: Ciphering algorithm information element

Type of algorithm (octet 1)

Bits

3 2 1

0 0 0 ciphering not used

0 0 1 GPRS Encryption Algorithm GEA/1

0 1 0 GPRS Encryption Algorithm GEA/2

0 1 1 GPRS Encryption Algorithm GEA/3

1 0 0 GPRS Encryption Algorithm GEA/4

1 0 1 GPRS Encryption Algorithm GEA/5

1 1 0 GPRS Encryption Algorithm GEA/6

1 1 1 GPRS Encryption Algorithm GEA/7

In this version of the protocol the network shall not allocate values other than 000 or 001 to the MS.

10.5.5.4 [Spare]TMSI status

The purpose of the TMSI status information element is to indicate whether a valid TMSI is available in the MS or not.

The TMSI status is a type 1 information element.

The TMSI status information element is coded as shown in figure 10.5.120/3GPP TS 04.08 and table 10.5.137/3GPP TS 04.08.

8 7 6 5 4 3 2 1

TMSI status
IEI

0 0 0
spare

TMSI
flag

octet 1

Figure 10.5.120/3GPP TS 04.08: TMSI status information element

Table 10.5.137/3GPP TS 04.08: TMSI status information element

TMSI flag (octet 1)

Bit

1

0 no valid TMSI available

1 valid TMSI available

10.5.5.5 Detach type

The purpose of the detach type information element is to indicate which type of detach is requested by the MS. In the network to MS direction the detach type information element is used to indicate the reason why a detach request is sent.

The detach type is a type 1 information element.

The detach type information element is coded as shown in figure 10.5.121/3GPP TS 04.08 and table 10.5.138/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Detach type
IEI

Power
off

Type of detach

octet 1

Figure 10.5.121/3GPP TS 04.08: Detach type information element

Table 10.5.138/3GPP TS 04.08: Detach type information element

Type of detach (octet 1)

In the MS to network direction:

Bits

3 2 1

0 0 1 GPRS detach

0 1 0 IMSI detach

0 1 1 Combined GPRS/IMSI detach

All other values are interpreted as Combined GPRS/IMSI detach by this version of the protocol.

In the network to MS direction:

Bits

3 2 1

0 0 1 re-attach required

0 1 0 re-attach not required

0 1 1 IMSI detach (after VLR failure)

All other values are interpreted as re-attach not required by this version of
the protocol.

Power off (octet 1)

In the MS to network direction:

Bit

4

0 normal detach

1 power switched off

In the network to MS direction the Power
off
bit shall be spare and set to zero.

10.5.5.6 DRX parameter

The purpose of the DRX parameter information element is to indicate whether the MS uses DRX mode or not.

The DRX parameter is a type 3 information element with a length of 3 octets.

The value part of a DRX parameter information element is coded as shown in table 10.5.139/3GPP TS 04.08.

8 7 6 5 4 3 2 1

DRX parameter IEI

octet 1

SPLIT PG CYCLE CODE

octet 2

0 0 0 0
spare

SPLIT on CCCH

non-DRX
timer

octet 3

Figure 10.5.122/3GPP TS 04.08: DRX parameter information element

Table 10.5.139/3GPP TS 04.08: DRX parameter information element

SPLIT PG CYCLE CODE, octet 2

The octet contains the binary coded value of the SPLIT PG CYCLE CODE. The SPLIT PG CYCLE value is derived from the SPLIT PG CYCLE CODE as follows:

SPLIT PG CYCLE CODE SPLIT PG CYCLE value

0 704 (equivalent to no DRX)
1 to 64 1 to 64, respectively

65 71
66 72
67 74
68 75
69 77
70 79
71 80
72 83
73 86
74 88
75 90
76 92
77 96
78 101
79 103
80 107
81 112
82 116
83 118
84 128
85 141
86 144
87 150
88 160
89 171
90 176
91 192
92 214
93 224
94 235
95 256
96 288
97 320
98 352

All other values are reserved and shall be interpreted as 1 by this version of the protocol.

SPLIT on CCCH, octet 3 (bit 4)

0 Split pg cycle on CCCH is not supported by the mobile station

1 Split pg cycle on CCCH is supported by the mobile station

non-DRX timer, octet 3

bit

3 2 1

0 0 0 no non-DRX mode after transfer state
0 0 1 max. 1 sec non-DRX mode after transfer state
0 1 0 max. 2 sec non-DRX mode after transfer state
0 1 1 max. 4 sec non-DRX mode after transfer state
1 0 0 max. 8 sec non-DRX mode after transfer state
1 0 1 max. 16 sec non-DRX mode after transfer state
1 1 0 max. 32 sec non-DRX mode after transfer state
1 1 1 max. 64 sec non-DRX mode after transfer state

Bits 8 to 5 of octet 3 are spare and shall be coded all zeros.

10.5.5.7 Force to standby

The purpose of the force to standby information element is to force the MS to stop the READY timer in order to prevent the MS to perform cell updates.

The force to standby is a type 1 information element.

The force to standby information element is coded as shown in figure 10.5.123/3GPP TS 04.08 and table 10.5.140/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Force to standby
IEI

0
spare

Force to standby value

octet 1

Figure 10.5.123/3GPP TS 04.08: Force to standby information element

Table 10.5.140/3GPP TS 04.08: Force to standby information element

Force to standby value (octet 1)

Bits

3 2 1

0 0 0 Force to standby not indicated

0 0 1 Force to standby indicated

All other values are interpreted as
force to standby not indicated by this version of the protocol.

10.5.5.8 P-TMSI signature

The purpose of the P-TMSI signature information element is to identify a GMM context of an MS.

The P-TMSI signature is a type 3 information element with 4 octets length.

The P-TMSI signature information element is coded as shown in figure 10.5.124/3GPP TS 04.08 and table 10.5.141/3GPP TS 04.08.

8 7 6 5 4 3 2 1

P-TMSI signature IEI

octet 1

P-TMSI signature value

octet 2

octet 4

Figure 10.5.124/3GPP TS 04.08: P-TMSI signature information element

Table 10.5.141/3GPP TS 04.08: P-TMSI signature information element

P-TMSI signature value

Octets 2, 3 and 4 contain the binary representation of the P-TMSI signature.

Bit 1 of octet 4 is the least significant bit and bit 8 of octet 2 is the most significant bit.

10.5.5.9 Identity type 2

The purpose of the identity type 2 information element is to specify which identity is requested.

The identity type 2 is a type 1 information element.

The identity type 2 information element is coded as shown in figure 10.5.125/3GPP TS 04.08 and table 10.5.142/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Identity type 2
IEI

0
spare

Type of identity

octet 1

Figure 10.5.125/3GPP TS 04.08: Identity type 2 information element

Table 10.5.142/3GPP TS 04.08: Identity type 2 information element

Type of identity (octet 1)

Bits

3 2 1

0 0 1 IMSI

0 1 0 IMEI

0 1 1 IMEISV

1 0 0 TMSI

All other values are interpreted as
IMSI by this version of the protocol.

10.5.5.10 IMEISV request

The purpose of the IMEISV request information element is to indicate that the IMEISV shall be included by the MS in the authentication and ciphering response message.

The IMEISV request is a type 1 information element.

The IMEISV request information element is coded as shown in figure 10.5.126/3GPP TS 04.08 and table 10.5.143/3GPP TS 04.08.

8 7 6 5 4 3 2 1

IMEISV request
IEI

0
spare

IMEISV request
value

octet 1

Figure 10.5.126/3GPP TS 04.08: IMEISV request information element

Table 10.5.143/3GPP TS 04.08: IMEISV request information element

IMEISV request value (octet 1)

Bits

3 2 1

0 0 0 IMEISV not requested

0 0 1 IMEISV requested

All other values are interpreted as IMEISV not requested by this version
of the protocol.

10.5.5.11 Receive N‑PDU Numbers list

The purpose of the Receive N‑PDU Numbers list information element is to specify the current SNDCP Receive N‑PDU Number values.

The Receive N‑PDU Number list is a type 4 information element with a length of 4 to 19 octets.

The value part of a Receive N‑PDU Number list information element is coded as shown in figure 10.5.127/3GPP TS 04.08 and table 10.5.144/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Receive N‑PDU Number list IEI

octet 1

Length of Receive N‑PDU Number list contents

octet 2

Receive N‑PDU Number-list

octet 3

octet 4

octet n*

Figure 10.5.127/3GPP TS 04.08: Receive N‑PDU Number list information element

Table 10.5.144/3GPP TS 04.08: Receive N‑PDU Number list information element

Receive N‑PDU Number -list value ::=

{
< Receive N‑PDU Number -list >
< Padding bits>
} ;

< Receive N‑PDU Number-list > ::= < sapi : bit-string(4) > < Receive N‑PDU Number-value : bit-string(8) > { < Receive N‑PDU Number-list> | < null > } ;

< nsapi > ::=
{ 0101 }; | — NSAPI 5
{ 0110 }; | — NSAPI 6
{ 0111 }; | — NSAPI 7
{ 1000 }; | — NSAPI 8
{ 1001 }; | — NSAPI 9
{ 1010 }; | — NSAPI 10
{ 1011 }; | — NSAPI 11
{ 1100 }; | — NSAPI 12
{ 1101 }; | — NSAPI 13
{ 1110 }; | — NSAPI 14
{ 1111 }; — NSAPI 15

< Receive N‑PDU Number-value > ::= { 0 | 1} (8) ;
— Contains the binary coded representation of the receive N-PDU Number value.
— The first bit in transmission order is the most significant bit.

<Padding bits> ::= null | 0000;

10.5.5.12 MS network capability

The purpose of the MS network capability information element is to provide the network with information concerning aspects of the mobile station related to GPRS. The contents might affect the manner in which the network handles the operation of the mobile station. The MS network capability information indicates general mobile station characteristics and it shall therefore, except for fields explicitly indicated, be independent of the frequency band of the channel it is sent on.

The MS network capability is a type 4 information element with a minimum of 3 and a maximum of 4 octets length.

Octet 4 shall be included by the MS, if it supports in addition to GEA/1 at least one of the GPRS Encryption Algorithm GEA/2 to GEA/7. In this version of the protocol the network shall ignore octet 4.

The value part of a MS network capabilityinformation element is coded as shown in figure 10.5.128/3GPP TS 04.08 and table 10.5.145/3GPP TS 04.08.

8

7

6

5

4

3

2

1

MS network capability IEI

octet 1

Length of MS network capability contents

octet 2

MS network capability value

octet 3

Octet 4

Figure 10.5.128/3GPP TS 04.08: MS network capability information element

Table 10.5.145/3GPP TS 04.08: MS network capability information element

<MS network capability value part> ::=

<GEA1 bit>
<SM capabilities via dedicated channels: bit>
<SM capabilities via GPRS channels: bit>
<UCS2 support: bit>
<SS Screening Indicator: bit string(2)>
<SoLSA Capability : bit>
<Spare bit>

<Spare bit>

<Extended GEA bits>

<Spare bit>;

<GEA1 bit> ::= < GEA/1 :bit>;

<Extended GEA bits> ::= <GEA/2:bit><GEA/3:bit>< GEA/4:bit >< GEA/5:bit >< GEA/6:bit ><GEA/7:bit>;

<Spare bits> ::= null | {<spare bit> < Spare bits >};

SS Screening Indicator
0 0 defined in 3GPP TS 04.80

0 1 defined in 3GPP TS 04.80

1 0 defined in 3GPP TS 04.80

1 1 defined in 3GPP TS 04.80

SM capabilities via dedicated channels
0 Mobile station does not support mobile terminated point to point SMS via
dedicated signalling channels

1 Mobile station supports mobile terminated point to point SMS via dedicated
signalling channels

SM capabilities via GPRS
channels
0 Mobile station does not support mobile terminated point to point SMS via
GPRS packet data channels
1 Mobile station supports mobile terminated point to point SMS via GPRS
packet data channels

UCS2 support
This information field indicates the likely treatment by the mobile station of UCS2 encoded character strings.
0 the ME has a preference for the default alphabet (defined in 3GPP TS 03.38)
over UCS2.
1 the ME has no preference between the use of the default alphabet and the
use of UCS2.

GPRS Encryption Algorithm GEA/1
0 encryption algorithm GEA/1not available
1 encryption algorithm GEA/1 available

SoLSA Capability
0 The ME does not support SoLSA.
1 The ME supports SoLSA.

GPRS Encryption Algorithm GEA/2
0 encryption algorithm GEA/2 not available
1 encryption algorithm GEA/2 available

GPRS Encryption Algorithm GEA/3
0 encryption algorithm GEA/3 not available
1 encryption algorithm GEA/3 available

GPRS Encryption Algorithm GEA/4
0 encryption algorithm GEA/4 not available
1 encryption algorithm GEA/4 available

GPRS Encryption Algorithm GEA/5
0 encryption algorithm GEA/5 not available
1 encryption algorithm GEA/5 available

GPRS Encryption Algorithm GEA/6
0 encryption algorithm GEA/6 not available
1 encryption algorithm GEA/6 available

GPRS Encryption Algorithm GEA/7
0 encryption algorithm GEA/7 not available
1 encryption algorithm GEA/7 available

10.5.5.12a MS Radio Access capability

The purpose of the MS RA capability information element is to provide the radio part of the network with information concerning radio aspects of the mobile station. The contents might affect the manner in which the network handles the operation of the mobile station.

The MS RA capability is a type 4 information element, with a minimum length of 6 octets and a maximum length of 14 octets.

The value part of a MS RA capability information element is coded a shown table 10.5.146/3GPP TS 04.08.

 SEMANTIC RULE : Among the three Access Type Technologies GSM 900-P, GSM 900-E and GSM 900-R only one shall be present.

 Error handling : If a received Access Technology Type is unknown to the receiver, it shall ignore all the corresponding fields;

 If within a known Access Technology Type a receiver recognizes an unknown field it shall ignore it.

 See more details about error handling of MS radio access capability in TS 3GPP TS 08.18.

– Due to shared radio frequency channel numbers between 1800 and 1900, the mobile should provide MS Radio Access capability for either 900/1800 band(s) OR 1900 band.

Table 10.5.146/3GPP TS 04.08: Mobile Station Radio Access Capability Information Element

< MS Radio Access capability IE > ::=

<MS Radio Access capability IEI : 00100100 >

<Length of MS RA capability: <octet>> — length in octets of MS RA capability value part and spare bits

<MS RA capability value part : < MS RA capability value part struct >>

<spare bits>**; — may be used for future enhancements

<MS RA capability value part struct >::= —recursive structure allows any number of Access technologies

< Access Technology Type: bit (4) >

< Access capabilities : <Access capabilities struct> >

{ 0 | 1 <MS RA capability value part struct> } ;

< Access capabilities struct > ::=

< Length : bit (7) > — length in bits of Content and spare bits

<Access capabilities : <Content>>

<spare bits>** ; — expands to the indicated length

— may be used for future enhancements

< Content > ::=

< RF Power Capability : bit (3) >
{ 0 | 1 <A5 bits : <A5 bits> > } — zero means that the same values apply for parameters as in the immediately preceeding Access capabilities field within this IE

— The presence of the A5 bits is mandatory in the 1st Access capabilities struct within this IE.
< ES IND : bit >

< PS : bit >

< VGCS : bit >

< VBS : bit >

{ 0 | 1 < Multislot capability : Multislot capability struct > } ; — zero means that the same values apply for multislot parameters as in the immediately preceeding Access capabilities field within this IE.

— The presence of the Multislot capability struct is mandatory in the 1st Access capabilities struct within this IE.

< Multislot capability struct > ::=
{ 0 | 1 < HSCSD multislot class : bit (5) > }

{ 0 | 1 < GPRS multislot class : bit (5) > < GPRS Extended Dynamic Allocation Capability : bit > }

{ 0 | 1 < SMS_VALUE : bit (4) > < SM_VALUE : bit (4) > } ;

<A5 bits> ::= < A5/1 : bit> <A5/2 : bit> <A5/3 : bit> <A5/4 : bit> <A5/5 : bit> <A5/6 : bit> <A5/7 : bit>; — bits for circuit mode ciphering algorithms

Continued…

Table 10.5.146/3GPP TS 04.08 (continued): Mobile Station Radio Access Capability Information Element

Access Technology Type
This field indicates the access technology type to be associated with the following access capabilities.

Bits
4 3 2 1
0 0 0 0 GSM P
0 0 0 1 GSM E —note that GSM E covers GSM P
0 0 1 0 GSM R —note that GSM R covers GSM E and GSM P
0 0 1 1 GSM 1800
0 1 0 0 GSM 1900
All other values are treated as unknown by the receiver.

RF Power Capability
This field is coded as radio capability in Classmark 3 for the indicated band: it contains the binary coding of he power class associated (see 3GPP TS 05.05 paragraph 4.1 output power and paragraph 4.1.1 Mobile Station).

A5/1
0 encryption algorithm A5/1 not available
1 encryption algorithm A5/1 available

A5/2
0 encryption algorithm A5/2 not available
1 encryption algorithm A5/2 available

A5/3
0 encryption algorithm A5/3 not available
1 encryption algorithm A5/3 available

A5/4
0 encryption algorithm A5/4 not available
1 encryption algorithm A5/4 available

A5/5
0 encryption algorithm A5/5 not available
1 encryption algorithm A5/5 available

A5/6
0 encryption algorithm A5/6 not available
1 encryption algorithm A5/6 available

A5/7
0 encryption algorithm A5/7 not available
1 encryption algorithm A5/7 available

ES IND – (Controlled early Classmark Sending)

0 "controlled early Classmark Sending" option is not implemented

1 "controlled early Classmark Sending" option is implemented

PS – (Pseudo Synchronisation)
0 PS capability not present
1 PS capability present

VGCS – (Voice Group Call Service)
0 no VGCS capability or no notifications wanted
1 VGCS capability and notifications wanted

VBS – (Voice Broadcast Service)
0 no VBS capability or no notifications wanted
1 VBS capability and notifications wanted

HSCSD Multi Slot Class 
The Multi Slot Class field is coded as the binary representation of the multislot class defined in TS 3GPP TS 05.02.
Range 1 to 18, all other values are reserved.

GPRS Multi Slot Class
The GPRS Multi Slot Class field is coded as the binary representation of the multislot class defined in TS 3GPP TS 05.02.

GPRS Extended Dynamic Allocation Capability
0 Extended Dynamic Allocation Capability for GPRS is not implemented

1 Extended Dynamic Allocation Capability for GPRS is implemented

SMS_VALUE (Switch-Measure-Switch) (4 bit field)
The SMS field indicates the time needed for the mobile station to switch from one radio channel to another, perform a neighbor cell power measurement, and the switch from that radio channel to another radio channel.

Bits
4 3 2 1

0 0 0 0 1/4 timeslot (~144 microseconds)
0 0 0 1 2/4 timeslot (~288 microseconds)
0 0 1 0 3/4 timeslot (~433 microseconds)
. . .
1 1 1 1 16/4 timeslot (~2307 microseconds)

(SM_VALUE) Switch-Measure (4 bit field)
The SM field indicates the time needed for the mobile station to switch from one radio channel to another and perform a neighbor cell power measurement.

Bits
4 3 2 1
0 0 0 0 1/4 timeslot (~144 microseconds)
0 0 0 1 2/4 timeslot (~288 microseconds)
0 0 1 0 3/4 timeslot (~433 microseconds)
. . .
1 1 1 1 16/4 timeslot (~2307 microseconds)

10.5.5.13 Spare

This is intentionally left spare.

10.5.5.14 GMM cause

The purpose of the GMM cause information element is to indicate the reason why a GMM request from the mobile station is rejected by the network.

The GMM cause information element is coded as shown in figure 10.5.129/3GPP TS 04.08 and table 10.5.147/3GPP TS 04.08.

The GMM cause is a type 3 information element with 2 octets length.

8 7 6 5 4 3 2 1

GMM cause IEI

octet 1

Cause value

octet 2

Figure 10.5.129/3GPP TS 04.08: GMM cause information element

Table 10.5.147/3GPP TS 04.08: GMM cause information element

Cause value (octet 2) ¬

Bits

8 7 6 5 4 3 2 1

0 0 0 0 0 0 1 0 IMSI unknown in HLR

0 0 0 0 0 0 1 1 Illegal MS

0 0 0 0 0 1 1 0 Illegal ME

0 0 0 0 0 1 1 1 GPRS services not allowed

0 0 0 0 1 0 0 0 GPRS services and non-GPRS services not allowed

0 0 0 0 1 0 0 1 MS identity cannot be derived by the network

0 0 0 0 1 0 1 0 Implicitly detached

0 0 0 0 1 0 1 1 PLMN not allowed

0 0 0 0 1 1 0 0 Location Area not allowed

0 0 0 0 1 1 0 1 Roaming not allowed in this location area

0 0 0 0 1 1 1 0 GPRS services not allowed in this PLMN

0 0 0 1 0 0 0 0 MSC temporarily not reachable

0 0 0 1 0 0 0 1 Network failure

0 0 0 1 0 1 1 0 Congestion

0 0 1 1 0 0 0 0 } to } retry upon entry into a new cell

0 0 1 1 1 1 1 1 }

0 1 0 1 1 1 1 1 Semantically incorrect message

0 1 1 0 0 0 0 0 Invalid mandatory information

0 1 1 0 0 0 0 1 Message type non-existent or not implemented

0 1 1 0 0 0 1 0 Message type not compatible with the protocol state

0 1 1 0 0 0 1 1 Information element non-existent or not implemented

0 1 1 0 0 1 0 0 Conditional IE error

0 1 1 0 0 1 0 1 Message not compatible with the protocol state

0 1 1 0 1 1 1 1 Protocol error, unspecified

Any other value received by the mobile station shall be treated as 0110 1111, ‘Protocol error,’ unspecified’. Any other value received by the network shall be treated as 0110 1111, ‘Protocol error, unspecified’.

NOTE: The listed reject cause values are defined in annex G.

10.5.5.15 Routing area identification

The purpose of the routing area identification information element is to provide an unambiguous identification of routing areas within the area covered by the GSM system.

The routing area identification is a type 3 information element with 7 octets length.

The routing area identification information element is coded as shown in figure 10.5.130/3GPP TS 04.08 and table 10.5.148/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Routing Area Identification IEI

octet 1

MCC digit 2

MCC digit 1

octet 2

MNC digit 3

MCC digit 3

octet 3

MNC digit 2

MNC digit 1

octet 4

LAC

octet 5

LAC cont’d

octet 6

RAC

octet 7

Figure 10.5.130/3GPP TS 04.08: Routing area identification information element

Table 10.5.148/3GPP TS 04.08: Routing area identification information element

MCC, Mobile country code (octet 2 and 3)

The MCC field is coded as in ITU-T Rec. E212, Annex A.

If the RAI is deleted, the MCC and MNC shall take the value from the deleted RAI.

In abnormal cases, the MCC stored in the mobile station can contain elements not in the set {0, 1 … 9}. In such cases the mobile station should transmit the stored values using full hexadecimal encoding. When receiving such an MCC, the network shall treat the RAI as deleted.

MNC, Mobile network code (octet 3 bits 5 to 8, octet 4)

The coding of this field is the responsibility of each

administration but BCD coding shall be used. The MNC shall consist of 2 or 3 digits. For PCS 1900 for NA, Federal regulation mandates that a 3-digit MNC shall be used. However a network operator may decide to use only two digits in the MNC in the RAI over the radio interface. In this case, bits 5 to 8 of octet 3 shall be coded as "1111". Mobile equipment shall accept RAI coded in such a way.

Note 1: In earlier versions of this protocol, the possibility to use a one digit MNC in RAI was provided on the radio interface. However as this was not used this possibility has been deleted.

Note 2: In earlier versions of this protocol, bits 5 to 8 of octet 3 were coded as "1111". Mobile equipment compliant with these earlier versions of the protocol may be unable to understand the 3-digit MNC format of the RAI, and therefore unable to attach to a network broadcasting the RAI in this format.

In abnormal cases, the MNC stored in the mobile station can have

– digit 1 or 2 not in the set {0, 1 … 9} or

– digit 3 not in the set {0, 1 …9, F} hex.

In such cases the mobile station shall transmit the stored values using full hexadecimal encoding. When receiving such an MNC, the network shall treat the RAI as deleted.

The same handling shall apply for the network, if a 3-digit MNC is sent by the mobile station to a network using only a 2-digit MNC.

LAC, Location area code (octet 5 and 6)

In the LAC field bit 8 of octet 5 is the most significant bit and bit 1 of octet 6 the least significant bit.

The coding of the location area code is the responsibility of each administration except that two values are used to mark the LAC, and hence the RAI, as deleted. Coding using full hexadecimal representation may be used. The location area code consists of 2 octets.

If a RAI has to be deleted then all bits of the location area code shall be set to one with the exception of the least significant bit which shall be set to zero. If a SIM is inserted in a Mobile Equipment with the location area code containing all zeros, then the Mobile Equipment shall recognise this LAC as part of a deleted RAI.

RAC, Routing area code (octet 7)

In the RAC field bit 8 of octet 7 is the most significant. The coding of the routing area code is the responsibility of each administration. Coding using full hexadecimal representation may be used. The routing area code consists of 1 octet.

10.5.5.16 Spare

This is intentionally left spare.

10.5.5.17 Update result

The purpose of the update result information element is to specify the result of the associated updating procedure.

The update result is a type 1 information element.

The update result information element is coded as shown in figure 10.5.131/3GPP TS 04.08 and table 10.5.149/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Update result
IEI

0
spare

Update result value

octet 1

Figure 10.5.131/3GPP TS 04.08: Update result information element

Table 10.5.149/3GPP TS 04.08: Update result information element

Update result value (octet 1)

Bits

3 2 1

0 0 0 RA updated

0 0 1 combined RA/LA updated

All other values are reserved.

10.5.5.18 Update type

The purpose of the update type information element is to specify the area the updating procedure is associated with.

The update type is a type 1 information element.

The update type information element is coded as shown in figure 10.5.132/3GPP TS 04.08 and table 10.5.150/3GPP TS 04.08.

8 7 6 5 4 3 2 1

Update type
IEI

0
spare

Update type value

octet 1

Figure 10.5.132/3GPP TS 04.08: Update type information element

Table 10.5.150/3GPP TS 04.08: Update type information element

Update type value (octet 1)

Bits

3 2 1

0 0 0 RA updating

0 0 1 combined RA/LA updating

0 1 0 combined RA/LA updating with
IMSI attach

0 1 1 Periodic updating

All other values are reserved.

10.5.5.19 A&C reference number

The purpose of the A&C reference number information element is to indicate to the network in the AUTHENTICATION AND CIPHERING RESPONSE message which AUTHENTICATION AND CIPHERING REQUEST message the MS is replying to.

The A&C reference number is a type 1 information element.

The A&C reference number information element is coded as shown in figure 10.5.123/3GPP TS 04.08 and table 10.5.140/3GPP TS 04.08.

8 7 6 5 4 3 2 1

A&C reference number IEI

A&C reference number value

octet 1

Figure 10.5.134/3GPP TS 04.08: A&C reference number information element

Table 10.5.152/3GPP TS 04.08: A&C reference number information element

A&C reference number value (octet 1)

Unformatted 4 bit field