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 |
0 |
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 |
0 |
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 |
0 |
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 |
0 0 0 |
TMSI |
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 |
Power |
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 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 |
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 |
SPLIT on CCCH |
non-DRX |
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) 65 71 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 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 |
0 |
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 |
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 |
0 |
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 |
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 |
0 |
IMEISV request |
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 |
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 > ::= < sapi : bit-string(4) > < Receive N‑PDU Number-value : bit-string(8) > { < Receive N‑PDU Number-list> | < null > } ; < nsapi > ::= < Receive N‑PDU Number-value > ::= { 0 | 1} (8) ; <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> <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 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 1 Mobile station supports mobile terminated point to point SMS via dedicated UCS2 support GPRS Encryption Algorithm GEA/1 SoLSA Capability GPRS Encryption Algorithm GEA/2 GPRS Encryption Algorithm GEA/3 GPRS Encryption Algorithm GEA/4 GPRS Encryption Algorithm GEA/5 GPRS Encryption Algorithm GEA/6 GPRS Encryption Algorithm GEA/7 |
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 RF Power Capability A5/1 A5/2 A5/3 A5/4 A5/5 A5/6 A5/7 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) VGCS – (Voice Group Call Service) VBS – (Voice Broadcast Service) HSCSD Multi Slot Class GPRS Multi Slot Class |
GPRS Extended Dynamic Allocation Capability 1 Extended Dynamic Allocation Capability for GPRS is implemented SMS_VALUE (Switch-Measure-Switch) (4 bit field) Bits 0 0 0 0 1/4 timeslot (~144 microseconds) (SM_VALUE) Switch-Measure (4 bit field) Bits |
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 |
0 |
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 |
0 |
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 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 |