10	General message format and information elements coding
The figures and text in this clause describe the Information Elements contents.
10.1	Overview
Within the Layer 3 protocols defined in 3GPP TS 24.008, every message is a standard L3 message as defined in 3GPP TS 24.007 [20]. This means that the message consists of the following parts:
a)	protocol discriminator;
b)	transaction identifier;
c)	message type;
d)	other information elements, as required.
This organization is illustrated in the example shown in figure 10.1/3GPP TS 24.008.


Figure 10.1/3GPP TS 24.008 General message organization example
Unless specified otherwise in the message descriptions of clause 9, a particular information element shall not be present more than once in a given message.
The term "default" implies that the value defined shall be used in the absence of any assignment, or that this value allows negotiation of alternative values in between the two peer entities.
When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field.
10.2	Protocol Discriminator
The Protocol Discriminator (PD) and its use are defined in 3GPP TS 24.007 [20]. 
10.3	Skip indicator and transaction identifier
10.3.1	Skip indicator
Bits 5 to 8 of the first octet of every Mobility Management message and GPRS MobilityManagement message contains the skip indicator.
With the exception of the following cases for a shared GERAN network in A/Gb mode, 
-	when the MS is sending a LOCATION UPDATING REQUEST, CM SERVICE REQUEST, IMSI DETACH INDICATION or CM RE-ESTABLISHMENT REQUEST message; or
-	when the network is receiving a LOCATION UPDATING REQUEST, PAGING RESPONSE, CM SERVICE REQUEST, IMSI DETACH INDICATION or CM RE-ESTABLISHMENT REQUEST message,
the skip indicator field shall be handled as follows:
a)	A message received with skip indicator different from 0000 shall be ignored. A message received with skip indicator encoded as 0000 shall not be considered an error that causes the message to be ignored.
b)	A protocol entity sending a Mobility Management message or a GPRS Mobility Management message shall encode the skip indicator as 0000.
In a shared GERAN network in A/Gb mode:
a)	When the MS is sending a LOCATION UPDATING REQUEST, CM SERVICE REQUEST, IMSI DETACH INDICATION or CM RE-ESTABLISHMENT REQUEST message,
-	if the MS is a GERAN network sharing supporting MS, the MS shall encode the skip indicator IE to indicate the chosen PLMN identity from the PLMN identities in the broadcast system information (see 3GPP TS 44.018 [84]) according to table 10.3.1;
-	otherwise, the MS shall encode the skip indicator as 0000.
b)	When the network is receiving a LOCATION UPDATING REQUEST, PAGING RESPONSE, CM SERVICE REQUEST, IMSI DETACH INDICATION or CM RE-ESTABLISHMENT REQUEST message,
-	if the skip indicator is encoded as 0000, the message shall not be considered an error that causes the message to be ignored;
-	if the skip indicator is different from 0000, the message shall not be considered an error and shall be processed by the receiving MM entity. The MS shall be considered as GERAN network sharing supporting MS.
NOTE:	The skip indicator handling of PAGING RESPONSE message on the MS and the BSS is specified in 3GPP TS 44.018 [84].

8
7
6
5
4
3
2
1



Skip indicator
-
-
-
-
octet 1

Figure 10.3.1: Skip indicator
Table 10.3.1/3GPP TS 24.008: Skip indicator
Bits
8
7
6
5

0
0
0
0
Skip Indicator without indication of selected PLMN
0
0
0
1
PLMN identity of the Common PLMN in the broadcast system information
0
0
1
0
PLMN identity of the first Additional PLMN in the broadcast system information
0
0
1
1
PLMN identity of the second Additional PLMN in the broadcast system information
0
1
0
0
PLMN identity of the third Additional PLMN in the broadcast sytem information
0
1
0
1
PLMN identity of the fourth Additional PLMN in the broadcast system information
0
1
1
0
Reserved
0
1
1
1
Reserved

All other values shall be interpreted as "Skip Indicator without indication of selected PLMN".

Value 0000 indicates no indication of selected PLMN from the MS, which happens in UTRAN, or non-shared GERAN or Multi-Operator Core Network (MOCN) with common GERAN configurations or in a shared GERAN if the MS does not support GERAN network sharing.



10.3.2	Transaction identifier
Bits 5 to 8 of the first octet of every message belonging to the protocols "Call Control; call related SS messages" and "Session Management"contain the transaction identifier (TI). The transaction identifier and its use are defined in 3GPP TS 24.007 [20].
For the session management protocol, the extended TI mechanism may be used (see 3GPP TS 24.007 [20]). 
For the call control protocol, the extended TI mechanism shall be supported for the purpose of protocol error handling as specified in subclause 8.3.1
10.4	Message Type
The message type IE and its use are defined in 3GPP TS 24.007 [20]. Tables 10.3/3GPP TS 24.008, 10.4/3GPP TS 24.008, and 10.4a/3GPP TS 24.008 define the value part of the message type IE used in the Mobility Management protocol, the Call Control protocol, and Session management protocol.
Table 10.2/3GPP TS 24.008: Message types for Mobility Management










8
7
6
5
4
3
2
1












x
x
0
0
-
-
-
-

Registration messages:




0
0
0
1

- IMSI DETACH INDICATION




0
0
1
0

- LOCATION UPDATING ACCEPT




0
1
0
0

- LOCATION UPDATING REJECT




1
0
0
0

- LOCATION UPDATING REQUEST










x
x
0
1
-
-
-
-

Security messages:




0
0
0
1

- AUTHENTICATION REJECT




0
0
1
0

- AUTHENTICATION REQUEST




0
1
0
0

- AUTHENTICATION RESPONSE




1
1
0
0

- AUTHENTICATION FAILURE…………..




1
0
0
0

- IDENTITY REQUEST




1
0
0
1

- IDENTITY RESPONSE




1
0
1
0

- TMSI REALLOCATION COMMAND




1
0
1
1

- TMSI REALLOCATION COMPLETE










x
x
1
0
-
-
-
-

Connection management messages:




0
0
0
1

- CM SERVICE ACCEPT




0
0
1
0

- CM SERVICE REJECT




0
0
1
1

- CM SERVICE ABORT




0
1
0
0

- CM SERVICE REQUEST




0
1
0
1

- CM SERVICE PROMPT




0
1
1
0

- Reserved (see NOTE)




1
0
0
0

- CM RE-ESTABLISHMENT REQUEST




1
0
0
1

- ABORT










x
x
1
1
-
-
-
-

Miscellaneous messages:




0
0
0
0

- MM NULL




0
0
0
1

- MM STATUS




0
0
1
0

- MM INFORMATION











NOTE:	This value was allocated but never used in earlier phases of the protocol.
When the radio connection started with a core network node of earlier than R99, bit 8 shall be set to 0 and bit 7 is reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bits 7 and 8 are coded with a "0". See 3GPP TS 24.007 [20].
When the radio connection started with a core network node of R'99 or later, bits 7 and 8 are reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bits 7 and 8 are coded with a "0". See 3GPP TS 24.007 [20].
Table 10.3/3GPP TS 24.008: Message types for Call Control and call related SS messages










8
7
6
5
4
3
2
1


x
x
0
0
0
0
0
0

escape to nationally specific 









message types; see 1) below










x
x
0
0
-
-
-
-

Call establishment messages:




0
0
0
1

- ALERTING




1
0
0
0

- CALL CONFIRMED




0
0
1
0

- CALL PROCEEDING




0
1
1
1

- CONNECT




1
1
1
1

- CONNECT ACKNOWLEDGE




1
1
1
0

- EMERGENCY SETUP




0
0
1
1

- PROGRESS




0
1
0
0

- CC-ESTABLISHMENT




0
1
1
0

- CC-ESTABLISHMENT CONFIRMED




1
0
1
1

- RECALL




1
0
0
1

- START CC




0
1
0
1

- SETUP










x
x
0
1
-
-
-
-

Call information phase messages:




0
1
1
1

- MODIFY




1
1
1
1

- MODIFY COMPLETE




0
0
1
1

- MODIFY REJECT




0
0
0
0

- USER INFORMATION




1
0
0
0

- HOLD




1
0
0
1

- HOLD ACKNOWLEDGE




1
0
1
0

- HOLD REJECT




1
1
0
0

- RETRIEVE




1
1
0
1

- RETRIEVE ACKNOWLEDGE




1
1
1
0

- RETRIEVE REJECT










x
x
1
0
-
-
-
-

Call clearing messages:




0
1
0
1

- DISCONNECT




1
1
0
1

- RELEASE




1
0
1
0

- RELEASE COMPLETE










x
x
1
1
-
-
-
-

Miscellaneous messages:




1
0
0
1

- CONGESTION CONTROL




1
1
1
0

- NOTIFY




1
1
0
1

- STATUS




0
1
0
0

- STATUS ENQUIRY




0
1
0
1

- START DTMF




0
0
0
1

- STOP DTMF




0
0
1
0

- STOP DTMF ACKNOWLEDGE




0
1
1
0

- START DTMF ACKNOWLEDGE




0
1
1
1

- START DTMF REJECT




1
0
1
0

- FACILITY











1):	When used, the message type is defined in the following octet(s), according to the national specification.

When the radio connection started with a core network node of earlier than R99, bit 8 shall be set to 0 and bit 7 is reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bits 7 and 8 are coded with a "0". See 3GPP TS 24.007 [20]. 
When the radio connection started with a core network node of R'99 or later, bits 7 and 8 are reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bits 7 and 8 are coded with a "0". See 3GPP TS 24.007 [20].
Table 10.4/3GPP TS 24.008: Message types for GPRS mobility management
Bits


8
7
6
5
4
3
2
1












0
0
-
-
-
-
-
-

Mobility management messages










0
0
0
0
0
0
0
1

Attach request   
0
0
0
0
0
0
1
0

Attach accept 
0
0
0
0
0
0
1
1

Attach complete
0
0
0
0
0
1
0
0

Attach reject   
0
0
0
0
0
1
0
1

Detach request   
0
0
0
0
0
1
1
0

Detach accept                     










0
0
0
0
1
0
0
0

Routing area update request
0
0
0
0
1
0
0
1

Routing area update accept
0
0
0
0
1
0
1
0

Routing area update complete
0
0
0
0
1
0
1
1

Routing area update reject                                                        










0
0
0
0
1
1
0
0

Service Request
0
0
0
0
1
1
0
1

Service Accept
0
0
0
0
1
1
1
0

Service Reject 










0
0
0
1
0
0
0
0

P-TMSI reallocation command  
0
0
0
1
0
0
0
1

P-TMSI reallocation complete  
0
0
0
1
0
0
1
0

Authentication and ciphering req
0
0
0
1
0
0
1
1

Authentication and ciphering resp
0
0
0
1
0
1
0
0

Authentication and ciphering rej
0
0
0
1
1
1
0
0

Authentication and ciphering failure
0
0
0
1
0
1
0
1

Identity request                
0
0
0
1
0
1
1
0

Identity response                                                                  
0
0
1
0
0
0
0
0

GMM status                       
0
0
1
0
0
0
0
1

GMM information











Table 10.4a/3GPP TS 24.008: Message types for GPRS session management
Bits


8
7
6
5
4
3
2
1












0
1
-
-
-
-
-
-

Session management messages










0
1
0
0
0
0
0
1

Activate PDP context request
0
1
0
0
0
0
1
0

Activate PDP context accept 
0
1
0
0
0
0
1
1

Activate PDP context reject 










0
1
0
0
0
1
0
0

Request PDP context activation 
0
1
0
0
0
1
0
1

Request PDP context activation rej.   
0
1
0
0
0
1
1
0

Deactivate PDP context request  
0
1
0
0
0
1
1
1

Deactivate PDP context accept   
0
1
0
0
1
0
0
0

Modify PDP context request(Network to MS direction)
0
1
0
0
1
0
0
1

Modify PDP context accept (MS to network direction)
0
1
0
0
1
0
1
0

Modify PDP context request(MS to network direction)
0
1
0
0
1
0
1
1

Modify PDP context accept (Network to MS direction)
0
1
0
0
1
1
0
0

Modify PDP context reject










0
1
0
0
1
1
0
1

Activate secondary PDP context request
0
1
0
0
1
1
1
0

Activate secondary PDP context accept
0
1
0
0
1
1
1
1

Activate secondary PDP context reject










0
1
0
1
0
0
0
0

Reserved: was allocated in earlier phases of the protocol
0
1
0
1
0
0
0
1

Reserved: was allocated in earlier phases of the protocol
0
1
0
1
0
0
1
0

Reserved: was allocated in earlier phases of the protocol
0
1
0
1
0
0
1
1

Reserved: was allocated in earlier phases of the protocol
0
1
0
1
0
1
0
0

Reserved: was allocated in earlier phases of the protocol










0
1
0
1
0
1
0
1

SM Status










0
1
0
1
0
1
1
0

Activate MBMS Context Request
0
1
0
1
0
1
1
1

Activate MBMS Context Accept
0
1
0
1
1
0
0
0

Activate MBMS Context Reject
0
1
0
1
1
0
0
1

Request MBMS Context Activation
0
1
0
1
1
0
1
0

Request MBMS Context Activation Reject










0
1
0
1
1
0
1
1

Request Secondary PDP Context Activation
0
1
0
1
1
1
0
0

Request Secondary PDP Context Activation Reject










0
1
0
1
1
1
0
1

Notification











10.5	Other information elements
The different formats (V, LV, T, TV, TLV) and the four categories of information elements (type 1, 2, 3, and 4) are defined in 3GPP TS 24.007 [20].
The first octet of an information element in the non-imperative part contains the IEI of the information element. If this octet does not correspond to an IEI known in the message, the receiver shall determine whether this IE is of type 1 or 2 (i.e. it is an information element of one octet length) or an IE of type 4 (i.e. that the next octet is the length indicator indicating the length of the remaining of the information element) (see 3GPP TS 24.007 [20]).
This allows the receiver to jump over unknown information elements and to analyse any following information elements.
The information elements which are common for at least two of the three protocols Radio Resources management, Mobility Management and Call Control, are listed in subclause 10.5.1.
The information elements for the protocols Mobility Management and Call Control are listed in subclauses 10.5.3 and 10.5.4 respectively. Default information element identifiers are listed in annex K.
NOTE:	Different information elements may have the same default information element identifier if they belong to different protocols.
The descriptions of the information element types in subclauses 10.5.1, 10.5.3, and 10.5.4 are organized in alphabetical order of the IE types. Each IE type is described in one subclause.
The subclause may have an introduction:
-	possibly explaining the purpose of the IE;
-	possibly describing whether the IE belongs to type 1, 2, 3, 4 or 5;
-	possibly indicating the length that the information element has if it is either type 5 or if it is used in format TV (type 1 and 3) or TLV (type 4).
A figure of the subclause defines the structure of the IE indicating:
-	possibly the position and length of the IEI. (However it depends on the message in which the IE occurs whether the IE contains an IEI.);
-	the fields the IE value part is composed of;
-	possibly the position and length of the length indicator. (However it depends on the IE type whether the IE contains a length indicator or not.);
-	possibly octet numbers of the octets that compose the IE (see clause a) below).
Finally, the subclause contains tables defining the structure and value range of the fields that compose the IE value part. The order of appearance for information elements in a message is defined in clause 9.
The order of the information elements within the imperative part of messages has been chosen so that information elements with 1/2 octet of content (type 1) go together in succession. The first type 1 information element occupies bits 1 to 4 of octet N, the second bits 5 to 8 of octet N, the third bits 1 to 4 of octet N + 1 etc. If the number of type 1 information elements is odd then bits 5 to 8 of the last octet occupied by these information elements contains a spare half octet IE in format V.
Where the description of information elements in the present document contains bits defined to be "spare bits", these bits shall set to the indicated value (0 or 1) by the sending side, and their value shall be ignored by the receiving side. With few exceptions, spare bits are indicated as being set to "0" in 3GPP TS 24.008.
10.5.1	Common information elements.
10.5.1.1	Cell identity
The purpose of the Cell Identity information element is to identify a cell within a location area.
The Cell Identity information element is coded as shown in figure 10.5.1/3GPP TS 24.008 and table 10.5.1/3GPP TS 24.008.
The Cell Identity is a type 3 information element with 3 octets length.

8
7
6
5
4
3
2
1


Cell Identity IEI
octet 1

CI value

octet 2

CI value (continued)

octet 3

Figure 10.5.1/3GPP TS 24.008 Cell Identity information element
Table 10.5.1/3GPP TS 24.008: Cell Identity information element
CI value, Cell identity value (octet 2 and 3)

In the CI value field bit 8 of octet 2 is the most significant bit and bit 1 of octet 3 the least significant bit.

The coding of the cell identity is the responsibility of each administration. Coding using full hexadecimal representation may be used.
The cell identity consists of 2 octets.


10.5.1.2	Ciphering Key Sequence Number
In a GSM authentication challenge, the purpose of the Ciphering Key Sequence Number information element is to make it possible for the network to identify the ciphering key Kc which is stored in the mobile station without invoking the authentication procedure. 
The ciphering key sequence number is allocated by the network and sent with the AUTHENTICATION REQUEST or AUTHENTICATION AND CIPHERING REQUEST message to the mobile station where it is stored together with the calculated keys, e.g. Kc, CK, IK, Kc128, Kint.
The Ciphering Key Sequence Number information element is coded as shown in figure 10.5.2/3GPP TS 24.008 and table 10.5.2/3GPP TS 24.008.
In a UMTS authentication challenge, the purpose of the Ciphering Key Sequence Number information element is to make it possible for the network to identify the ciphering key CK and integrity key IK which are stored in the MS without invoking the authentication procedure. CK and IK form a Key Set Identifier (KSI) (see 3GPP TS 33.102 [5a]) which is encoded the same as the CKSN and is therefore included in the CKSN field.
The ciphering key sequence number is a type 1 information element.

8
7
6
5
4
3
2
1

              Ciphering Key	
           Sequence Number	
	                IEI	

0
spare
key sequence
octet 1

Figure 10.5.2/3GPP TS 24.008 Ciphering Key Sequence Number information element
Table 10.5.2/3GPP TS 24.008: Ciphering Key Sequence Number information element
Key sequence (octet 1)

Bits
3
2
1





0
0
0

through
Possible values for the ciphering key
1
1
0
sequence number




1
1
1
No key is available (MS to network);



Reserved (network to MS)

10.5.1.3	Location Area Identification
The purpose of the Location Area Identification information element is to provide an unambiguous identification of location areas within the area covered by the 3GPP system.
The Location Area Identification information element is coded as shown in figure 10.5.3/3GPP TS 24.008 and table 10.5.3/3GPP TS 24.008.
The Location Area Identification is a type 3 information element with 6 octets length.

8
7
6
5
4
3
2
1


Location 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 (continued)

octet 6

Figure 10.5.3/3GPP TS 24.008 Location Area Identification information element
Table 10.5.3/3GPP TS 24.008: Location 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 LAI is deleted the MCC and MNC shall take the value from the deleted LAI. 

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 LAI 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 LAI over the radio interface. In this case, bits 5 to 8 of octet 3 shall be coded as "1111". Mobile equipment shall accept LAI coded in such a way.

NOTE 1:	In earlier versions of this protocol, the possibility to use a one digit MNC in LAI 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 LAI, and therefore unable to register on a network broadcasting the LAI 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 LAI 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 LAI, as deleted. Coding using full hexadecimal representation may be used. The location area code consists of 2 octets.
If a LAI 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/USIM 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 LAI


10.5.1.4	Mobile Identity
The purpose of the Mobile Identity information element is to provide either the international mobile subscriber identity, IMSI, the temporary mobile subscriber identity, TMSI/P-TMSI/M-TMSI, the international mobile equipment identity, IMEI, the international mobile equipment identity together with the software version number, IMEISV, or the temporary mobile group identity (TMGI), associated with the optional MBMS Session Identity.
The IMSI shall not exceed 15 digits, the TMSI/P-TMSI/M-TMSI is 4 octets long, and the IMEI is composed of 15 digits, the IMEISV is 16 digits (see 3GPP TS 23.003 [10]). The TMGI is at maximum 6 octets long and is defined in subclause 10.5.6.13. The MBMS Session Identity, if included, is 1 octet long (see 3GPP TS 48.018 [86]).
For packet paging the network shall select the mobile identity type with the following priority:
1-	P-TMSI: The P-TMSI shall be used if it is available.
2-	IMSI: The IMSI shall be used in cases where no P-TMSI is available.
For MBMS (pre-)notification (see 3GPP TS 44.018 [84] and 3GPP TS 44.060 [76]) the network shall select the mobile identity type "TMGI and optional MBMS Session Identity".
NOTE 1:	The type of identity "TMGI and optional MBMS Session Identity" is only used by the MBMS (pre‑)notification procedure in of A/Gb mode.
For all other transactions with the following exceptions:
-	emergency call establishment, emergency call re-establishment, mobile terminated call establishment, the identification procedure, the GMM identification procedure, the GMM authentication, GPRS attach, routing area updating, and ciphering procedure and the ciphering mode setting procedure; and
-	location updating when the MS is configured for "AttachWithIMSI" as specified in 3GPP TS 24.368 [135] or 3GPP TS 31.102 [112] and the selected PLMN is neither the registered PLMN nor in the list of equivalent PLMNs;
the mobile station and the network shall select the mobile identity type with the following priority:
1-	TMSI: The TMSI shall be used if it is available.
2-	IMSI: The IMSI shall be used in cases where no TMSI is available.
For mobile terminated call establishment the mobile station shall select the same mobile identity type as received from the network in the PAGING REQUEST message. In case of enhanced DTM CS establishment (see 3GPP TS 44.018 [84]) the mobile station shall select the mobile identity type with the following priority in the PAGING RESPONSE message:
1-	TMSI: The TMSI shall be used if it is available.
2-	IMSI: The IMSI shall be used in cases where no TMSI is available.
For the PAGING RESPONSE message sent as a response to a paging for CS fallback, the MS shall:
-	select the TMSI as mobile identity type if the network has, in E-UTRAN, 
-	paged the MS for CS fallback using the S-TMSI; or
-	indicated TMSI in the CS SERVICE NOTIFICATION message (see 3GPP TS 24.301 [120]);
-	select the IMSI as mobile identity type if the network has, in E-UTRAN,
-	paged the MS for CS fallback using the IMSI; or
-	indicated IMSI in the CS SERVICE NOTIFICATION message (see 3GPP TS 24.301 [120]).
For emergency call establishment and re-establishment the mobile station shall select the mobile identity type with the following priority:
1-	TMSI: The TMSI shall be used if it is available and if the location update status is UPDATED, and the stored LAI is equal to the one received on the BCCH from the current serving cell.
2-	IMSI: The IMSI shall be used in cases where no TMSI is available or TMSI is available but either the update status is different from UPDATED, or the stored LAI is different from the one received on the BCCH from the current serving cell.
3-	IMEI: The IMEI shall be used in cases where no SIM/USIM is available or the SIM/USIM is considered as not valid by the mobile station or no IMSI or TMSI is available.
In the identification procedure and in the GMM identification procedure the mobile station shall select the mobile identity type which was requested by the network, if available. If the requested identity is not available, then the mobile station shall indicate the identity type "No Identity".
In the ciphering mode setting procedure and in the GMM authentication and ciphering procedure the mobile shall select the IMEISV.
The Mobile Identity information element is coded as shown in figure 10.5.4/3GPP TS 24.008 and table 10.5.4/3GPP TS 24.008.
The Mobile Identity is a type 4 information element with a minimum length of 3 octet and 11 octets length maximal. Further restriction on the length may be applied, e.g. number plans.

8
7
6
5
4
3
2
1


Mobile Identity IEI
octet 1

Length of mobile identity contents

octet 2

Identity digit 1

odd/
even
indic

Type of identity


octet 3

Identity digit p+1

Identity digit p

octet 4*

Figure 10.5.4/3GPP TS 24.008 Mobile Identity information element

8
7
6
5
4
3
2
1


Mobile Identity IEI
octet 1
Length of Mobile Identity contents
octet 2
0
0
MBMS Sess Id indic
MCC/MNC indic
odd/
even
indic

Type of identity

octet 3

spare






MBMS Service ID
octet 4
octet 5

octet 6

MCC digit 2 
MCC digit 1
octet 6a*

MNC digit 3
MCC digit 3
octet 6b*

MNC digit 2
MNC digit 1
octet 6c*

MBMS Session Identity
octet 7*

Figure 10.5.4a/3GPP TS 24.008: Mobile Identity information element for type of identity "TMGI and optional MBMS Session Identity"

Table 10.5.4/3GPP TS 24.008: Mobile Identity information element
Type of identity (octet 3)
Bits
3
2
1

0
0
1
IMSI
0
1
0
IMEI
0
1
1
IMEISV
1
0
0
TMSI/P-TMSI/M-TMSI
1
0
1
TMGI and optional MBMS Session Identity
0
0
0
No Identity (note 1)

All other values are reserved.

Odd/even indication (octet 3)
Bit
4



0


even number of identity digits and also when the TMSI/P-TMSI or TMGI and optional MBMS Session Identity is used
1


odd number of identity digits

Identity digits (octet 3 etc)

For the IMSI, IMEI and IMEISV this field is coded using BCD coding. If the number of identity digits is even then bits 5 to 8 of the last octet shall be filled with an end mark coded as "1111".

For Type of identity "No Identity", the Identity digit bits shall be encoded with all 0s and the Length of mobile identity contents parameter shall be set to one of the following values:
-	"1" if the identification procedure is used (see subclause 9.2.11);
-	"3" if the GMM identification procedure is used (see subclause 9.4.13)
-	"3" if the EMM identification procedure is used (see 3GPP TS 24.301 [120])

If the mobile identity is the TMSI/P-TMSI/M-TMSI then bits 5 to 8 of octet 3 are coded as "1111" and bit 8 of octet4 is the most significant bit and bit 1 of the last octet the least significant bit. The coding of the TMSI/P-TMSI is left open for each administration.

For type of identity "TMGI and optional MBMS Session Identity" the coding of octet 3 etc is as follows:

MCC/MNC indication (octet 3)
Bit
5



0


MCC/MNC is not present
1


MCC/MNC is present

MBMS Session Identity indication (octet 3)
Bit
6



0


MBMS Session Identity is not present
1


MBMS Session Identity is present
MBMS Service ID (octet 4, 5 and 6)

The contents of the MBMS Service ID field are coded as octets 3 to 5 of the Temporary Mobile Group Identity IE in Figure 10.5.154/3GPP TS 24.008. Therefore, bit 8 of octet 4 is the most significant bit and bit 1 of octet 6 the least significant bit. The coding of the MBMS Service ID is the responsibility of each administration. Coding using full hexadecimal representation may be used. The MBMS Service ID consists of 3 octets.

MCC, Mobile country code (octet 6a, octet 6b bits 1 to 4)

The MCC field is coded as in ITU-T Rec. E.212 [46], Annex A.

MNC, Mobile network code (octet 6b bits 5 to 8, octet 6c)

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. If a network operator decides to use only two digits in the MNC, bits 5 to 8 of octet 6b shall be coded as "1111".

The contents of the MCC and MNC digits are coded as octets 6 to 8 of the Temporary Mobile Group Identity IE in Figure 10.5.154/3GPP TS 24.008.

MBMS Session Identity (octet 7)

The MBMS Session Identity field is encoded as the value part of the MBMS Session Identity IE as specified in 3GPP TS 48.018 [86].

NOTE 1:	This can be used in the case when a fill paging message without any valid identity has to be sent on the paging subchannel and when the requested identity is not available at the mobile station during the identity request procedure.

10.5.1.5	Mobile Station Classmark 1
The purpose of the Mobile Station Classmark 1 information element is to provide the network with information concerning aspects of high priority of the mobile station equipment. This affects the manner in which the network handles the operation of the mobile station. The Mobile Station Classmark 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 Mobile Station Classmark 1 information element is coded as shown in figure 10.5.5/3GPP TS 24.008 and table 10.5.5/3GPP TS 24.008.
The Mobile Station Classmark 1 is a type 3 information element with 2 octets length.

8
7
6
5
4
3
2
1


Mobile Station Classmark 1 IEI
octet 1
0
spare
Revision
level
ES
IND
A5/1
RF power
capability

octet 2

Figure 10.5.5/3GPP TS 24.008 Mobile Station Classmark 1 information element

Table 10.5.5/3GPP TS 24.008: Mobile Station Classmark 1 information element

Revision level (octet 2)
Bits
7
6


0
0

Reserved for GSM phase 1
0
1

Used by GSM phase 2 mobile stations
1
0

Used by mobile stations supporting R99 or later versions of the protocol
1
1

Reserved for future use. If the network receives a revision level specified as 'reserved for future use', then it shall use the highest revision level supported by the network.




ES IND (octet 2, bit 5) "Controlled Early Classmark Sending" option implementation
An MS not supporting A/Gb mode shall set this bit to ‘0’.
An MS supporting A/Gb mode shall indicate the associated capability (see table):

0


"Controlled Early Classmark Sending" option is not implemented in the MS
1


"Controlled Early Classmark Sending" option is implemented in the MS

NOTE 1:	The value of the ES IND gives the implementation in the MS. It's value is not dependent on the broadcast SI 3 Rest Octet <Early Classmark Sending Control> value.

A5/1 algorithm supported (octet 2, bit4) (Note 2)
An MS not supporting A/Gb mode shall set this bit to ‘1’.
An MS supporting A/Gb mode shall indicate the associated capability (see table):

0


encryption algorithm A5/1 available
1


encryption algorithm A5/1 not available

RF power capability (octet 2)
When GSM 450, GSM 480, GSM 710, GSM 750, T-GSM 810, GSM 850, GSM 900 P, E [or R] band is used (for exceptions see 3GPP TS 44.018 [84]), the MS shall indicate the RF power capability of the band used (see table):
When UMTS is used, a single band GSM 450, GSM 480, GSM 710, GSM 750, T-GSM 810, GSM 850, GSM 900 P, E [or R] MS shall indicate the RF power capability corresponding to the (GSM) band it supports (see table). In this case information on which single band is supported is found in classmark 3.
Bits
3
2
1

0
0
0
class 1
0
0
1
class 2
0
1
0
class 3
0
1
1
class 4
1
0
0
class 5
All other values are reserved.

When the GSM 1800 or GSM 1900 band is used (for exceptions see 3GPP TS 44.018 [84], sub-clause 3.4.18), the MS shall indicate the RF power capability of the band used (see table):
When UMTS is used, a single band GSM 1800 or GSM 1900 MS shall indicate the RF power capability corresponding to the (GSM) band it supports (see table). In this case, information on which single band is supported is found in classmark 3.
Bits
3
2
1

0
0
0
class 1
0
0
1
class 2
0
1
0
class 3
All other values are reserved.
When UMTS is used, an MS not supporting any GSM band or a multiband GSM MS shall code this field as follows (see table):
Bits
3
2
1

1
1
1
RF power capability is irrelevant in this information element.
All other values are reserved.

NOTE 2: 	The requirements for the support of the A5 algorithms in the MS are specified in 3GPP TS 43.020 [13].

10.5.1.6	Mobile Station Classmark 2
The purpose of the Mobile Station Classmark 2 information element is to provide the network with information concerning aspects of both high and low priority of the mobile station equipment. This affects the manner in which the network handles the operation of the mobile station. The Mobile Station Classmark 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 Mobile Station Classmark 2 information element is coded as shown in figure 10.5.6/3GPP TS 24.008, table 10.5.6a/3GPP TS 24.008 and table 10.5.6b/3GPP TS 24.008.
The Mobile Station Classmark 2 is a type 4 information element with 5 octets length.

8
7
6
5
4
3
2
1


Mobile station classmark 2 IEI
octet 1

Length of mobile station classmark 2 contents

octet 2
0
spare
Revision
level
ES
IND
A5/1

RF power
capability

octet 3
0
spare
PS
capa.
SS Screen.
Indicator
SM ca
pabi.
VBS

VGCS

FC


octet 4
CM3

0
spare
LCSVA
CAP
UCS2

SoLSA

CMSP

A5/3

A5/2


octet 5

NOTE 1:	Owing to backward compatibility problems, bit 8 of octet 4 should not be used unless it is also checked that the bits 8, 7 and 6 of octet 3 are not "0 0 0".

Figure 10.5.6/3GPP TS 24.008 Mobile Station Classmark 2 information element

Table 10.5.6a/3GPP TS 24.008: Mobile Station Classmark 2 information element
Revision level (octet 3)
Bits
7
6


0
0

Reserved for GSM phase 1
0
1

Used by GSM phase 2 mobile stations
1
0

Used by mobile stations supporting R99 or later versions of the protocol
1
1

Reserved for future use. If the network receives a revision level specified as 'reserved for future use', then it shall use the highest revision level supported by the network.




ES IND (octet 3, bit 5) "Controlled Early Classmark Sending" option implementation
AN MS not supporting A/Gb mode shall set this bit to ‘0’.
An MS supporting A/Gb mode shall indicate the associated capability (see table):

0


"Controlled Early Classmark Sending" option is not implemented in the MS
1


"Controlled Early Classmark Sending" option is implemented in the MS

NOTE 1:	The value of the ES IND gives the implementation in the MS. It's value is not dependent on the broadcast SI 3 Rest Octet <Early Classmark Sending Control> value

A5/1 algorithm supported (octet 3, bit 4) (Note 4)
An MS not supporting A/Gb mode shall set this bit to ‘1’.
An MS supporting A/Gb mode shall indicate the associated capability (see table)

0


encryption algorithm A5/1 available
1


encryption algorithm A5/1 not available

RF Power Capability (Octet 3)
When T-GSM 380, T-GSM 410, GSM 450, GSM 480, GSM 710, GSM 750, T-GSM 810, GSM 850, GSM 900 P, E [or R] band is used (for exceptions see 3GPP TS 44.018 [84]), the MS shall indicate the RF power capability of the band used (see table).
When UMTS or E-UTRAN is used, a single band T-GSM 380, T-GSM 410, GSM 450, GSM 480, GSM 710, GSM 750, T-GSM 810, GSM 850, GSM 900 P, E [or R] MS shall indicate the RF power capability corresponding to the (GSM) band it supports (see table). In this case, information on which single band is supported is found in classmark 3.
Bits
3
2
1

0
0
0
class 1
0
0
1
class 2
0
1
0
class 3
0
1
1
class 4
1
0
0
class 5
All other values are reserved.

When the GSM 1800 or GSM 1900 band is used (for exceptions see 3GPP TS 44.018 [84]) The MS shall indicate the RF power capability of the band used (see table).
When UMTS or E-UTRAN is used, a single band GSM 1800 or GSM 1900 MS shall indicate the RF power capability corresponding to the (GSM) band it supports (see table). In this case, information on which single band is supported is found in classmark 3
Bits
3
2
1

0
0
0
class 1
0
0
1
class 2
0
1
0
class 3
All other values are reserved.

When UMTS or E-UTRAN is used, an MS not supporting any GSM band or a multiband GSM MS shall code this field as follows (see table):
Bits
3
2
1

1
1
1
RF Power capability is irrelevant in this information element
All other values are reserved.

PS capability (pseudo-synchronization capability) (octet 4)
An MS not supporting A/Gb mode shall set this bit to ‘0’.
An MS supporting A/Gb mode shall indicate the associated capability (see table):
Bit 7
0


PS capability not present
1


PS capability present




SS Screening Indicator (octet 4)
Bits
6
5


0
0

defined in 3GPP TS 24.080 [24]
0
1

defined in 3GPP TS 24.080 [24]
1
0

defined in 3GPP TS 24.080 [24]
1
1

defined in 3GPP TS 24.080 [24]

SM capability (MT SMS pt to pt capability) (octet 4)
Bit 4
0


Mobile station does not support mobile terminated point to point SMS
1


Mobile station supports mobile terminated point to point SMS





VBS notification reception (octet 4)
An MS not supporting A/Gb mode shall set this bit to ‘0’.
An MS supporting A/Gb mode shall indicate the associated capability (see table):
Bit 3
0


no VBS capability or no notifications wanted
1


VBS capability and notifications wanted




VGCS notification reception (octet 4)
An MS not supporting A/Gb mode shall set this bit to ‘0’.
An MS supporting A/Gb mode shall indicate the associated capability (see table):
Bit 2
0


no VGCS capability or no notifications wanted
1


VGCS capability and notifications wanted




FC Frequency Capability (octet 4)
When the T-GSM 400, GSM 400, or GSM 700, or T-GSM 810, or GSM 850, or GSM 1800, or GSM 1900 band or UMTS or E-UTRAN is used (for exceptions see 3GPP TS 44.018 [84]), for definitions of frequency band see 3GPP TS 45.005 [33]), this bit shall be sent with the value ‘0’.




NOTE 2:	This bit conveys no information about support or non support of the E-GSM or R-GSM bands when T-GSM 400, GSM 400, GSM 700, T-GSM 810, GSM 850, GSM 1800, GSM 1900 band or UMTS or E-UTRAN is used.




When a GSM 900 band is used (for exceptions see 3GPP TS 44.018 [84]):
Bit 1
0


The MS does not support the E-GSM or R-GSM band (For definition of frequency bands see 3GPP TS 45.005 [33])
1


The MS does support the E-GSM or R-GSM (For definition of frequency bands see 3GPP TS 45.005 [33])
NOTE 3:	For mobile station supporting the R-GSM band further information can be found in MS Classmark 3.

CM3 (octet 5, bit 8)

0


The MS does not support any options that are indicated in CM3
1


The MS supports options that are indicated in classmark 3 IE

LCS VA capability (LCS value added location request notification capability) (octet 5,bit 6)

This information field indicates the support of the LCS value added location request notification via CS domain as defined in 3GPP TS 23.271 [105].
0


location request notification via CS domain not supported
1


location request notification via CS domain supported

UCS2 treatment (octet 5, bit 5)

This information field indicates the likely treatment by the mobile station of UCS2 encoded character strings. For backward compatibility reasons, if this field is not included, the value 0 shall be assumed by the receiver.
0


the ME has a preference for the default alphabet (defined in 3GPP TS 23.038 [8b]) over UCS2.
1


the ME has no preference between the use of the default alphabet and the use of UCS2.

SoLSA (octet 5, bit 4)
An MS not supporting A/Gb mode shall set this bit to ‘0’.
An MS supporting A/Gb mode shall indicate the associated capability (see table):
0


The ME does not support SoLSA.
1


The ME supports SoLSA.

CMSP: CM Service Prompt (octet 5, bit 3) $(CCBS)$

0


"Network initiated MO CM connection request" not supported.
1


"Network initiated MO CM connection request" supported for at least one CM protocol.

A5/3 algorithm supported (octet 5, bit 2) (Note 4)
An MS not supporting A/Gb mode shall set this bit to ‘0’.
An MS supporting A/Gb mode shall indicate the associated capability (see table):
0


encryption algorithm A5/3 not available
1


encryption algorithm A5/3 available

A5/2 algorithm supported (octet 5, bit 1) (Note 4)
The MS shall set this bit to ‘0’.
The network shall accept any received value.
0


encryption algorithm A5/2 not available
1


Not used. This value was allocated in earlier versions of the protocol.

NOTE 4: 	The requirements for the support of the A5 algorithms in the MS are specified in 3GPP TS 43.020 [13].

NOTE 2:	Additional mobile station capability information might be obtained by invoking the classmark interrogation procedure when GSM is used.
10.5.1.7	Mobile Station Classmark 3
The purpose of the Mobile Station Classmark 3 information element is to provide the network with information concerning aspects of the mobile station. The contents might affect the manner in which the network handles the operation of the mobile station. The Mobile Station Classmark 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 Mobile Station Classmark 3 is a type 4 information element with a maximum of 34 octets length.
The value part of a Mobile Station Classmark 3 information element is coded as shown in figure 10.5.1.7/3GPP TS 24.008 and table 10.5.1.7/3GPP TS 24.008.
NOTE:	The 34 octet limit is so that the CLASSMARK CHANGE message will fit in up to two layer 2 frames.
SEMANTIC RULE: a multiband mobile station shall provide information about all frequency bands it can support. A single band mobile station shall not indicate the band it supports in the Multiband Supported, GSM 400 Bands Supported, GSM 710 Associated Radio Capability, GSM 750 Associated Radio Capability, T-GSM 810 Associated Radio Capability, GSM 850 Associated Radio Capability or GSM 1900 Associated Radio Capability fields in the Mobile Station Classmark 3. Due to shared radio frequency channel numbers between GSM 1800 and GSM 1900, the mobile should indicate support for either GSM 1800 band OR GSM 1900 band.
SEMANTIC RULE: a mobile station shall include the MS Measurement Capability field if the Multi Slot Class field contains a value of 19 or greater (see 3GPP TS 45.002 [32]).
Typically, the number of spare bits at the end is the minimum to reach an octet boundary. The receiver may add any number of bits set to "0" at the end of the received string if needed for correct decoding.

<Classmark 3 Value part> ::=
	< spare bit >
	{	< Multiband supported : { 000 } >
			< A5 bits > 
	|	< Multiband supported : { 101 | 110 } > 
			< A5 bits >
			< Associated Radio Capability 2 : bit(4) >
			< Associated Radio Capability 1 : bit(4) >
	|	< Multiband supported : { 001 | 010 | 100 } > 
			< A5 bits >
			< spare bit >(4)
			< Associated Radio Capability 1 : bit(4) > }
	{ 0 | 1 < R Support > }
	{ 0 | 1 < HSCSD Multi Slot Capability > }
	< UCS2 treatment: bit >
	< Extended Measurement Capability : bit >
	{ 0 | 1 < MS measurement capability > }
	{ 0 | 1 < MS Positioning Method Capability > }
	{ 0 | 1 < ECSD Multi Slot Capability > }
	{ 0 | 1 < 8-PSK Struct > }
	{ 0 | 1 < GSM 400 Bands Supported : { 01 | 10 | 11 } >
			< GSM 400 Associated Radio Capability: bit(4) > }

	{ 0 | 1 <GSM 850 Associated Radio Capability : bit(4) > }
	{ 0 | 1 <GSM 1900 Associated Radio Capability : bit(4) > }
	< UMTS FDD Radio Access Technology Capability : bit >
	< UMTS 3.84 Mcps TDD Radio Access Technology Capability : bit >
	< CDMA 2000 Radio Access Technology Capability : bit >

	{ 0 | 1	< DTM GPRS Multi Slot Class : bit(2) >
			< Single Slot DTM : bit >
			{0 | 1< DTM EGPRS Multi Slot Class : bit(2) > } } 
	{ 0 | 1 < Single Band Support > } 								-- Release 4 starts here.
	{ 0 | 1 <GSM 750 Associated Radio Capability : bit(4)>}

	< UMTS 1.28 Mcps TDD Radio Access Technology Capability : bit >
	< GERAN Feature Package 1 : bit >

	{ 0 | 1 < Extended DTM GPRS Multi Slot Class : bit(2) >
			< Extended DTM EGPRS Multi Slot Class : bit(2) > }

	{ 0 | 1 < High Multislot Capability : bit(2) > }					--Release 5 starts here.

	0 	-- The value '1' was allocated in an earlier version of the protocol and shall not be used.
	< GERAN Feature Package 2 : bit >

	< GMSK Multislot Power Profile : bit (2) >
	< 8-PSK Multislot Power Profile : bit (2) >

	{ 0 | 1 < T-GSM 400 Bands Supported : { 01 | 10 | 11 } >		-- Release 6 starts here.
			< T-GSM 400 Associated Radio Capability: bit(4) > }

	0	-- The value '1' was allocated in an earlier version of the protocol and shall not be used.

	< Downlink Advanced Receiver Performance : bit (2)>

	< DTM Enhancements Capability : bit >

	{ 0 | 1	< DTM GPRS High Multi Slot Class : bit(3) >
			< Offset required : bit>
			{ 0 | 1 < DTM EGPRS High Multi Slot Class : bit(3) > } }

	< Repeated ACCH Capability : bit >

	{ 0 | 1 <GSM 710 Associated Radio Capability : bit(4)>} 		-- Release 7 starts here.
	{ 0 | 1 <T-GSM 810 Associated Radio Capability : bit(4)>}
	< Ciphering Mode Setting Capability : bit >

	< Additional Positioning Capabilities : bit >

	< E-UTRA FDD support : bit >									-- Release 8 starts here
	< E-UTRA TDD support : bit >
	< E-UTRA Measurement and Reporting support : bit >
	< Priority-based reselection support : bit >

	< UTRA CSG Cells Reporting : bit >							-- Release 9 starts here
	< VAMOS Level : bit(2) >

	< TIGHTER Capability : bit(2) >									-- Release 10 starts here
	< Selective Ciphering of Downlink SACCH : bit >

	< CS to PS SRVCC from GERAN to UTRA : bit(2) >			 -- Release 11 starts here
	< CS to PS SRVCC from GERAN to E-UTRA : bit(2)>

	< GERAN Network Sharing support : bit >
	< E-UTRA Wideband RSRQ measurements support : bit >

	< ER Band Support : bit >										 -- Release 12 starts here
	< UTRA Multiple Frequency Band Indicators support : bit >
	< E-UTRA Multiple Frequency Band Indicators support: bit >
	< Extended TSC Set Capability support: bit >
	< Extended EARFCN value range : bit >						-- Late addition of a release 11 feature
	< spare bits > ;

< A5 bits > ::= 
	< A5/7 : bit > < A5/6 : bit > < A5/5 : bit > < A5/4 : bit >  ;

<R Support>::=
	< R-GSM band Associated Radio Capability : bit(3) > ;

< HSCSD Multi Slot Capability > ::=
	< HSCSD Multi Slot Class : bit(5) >  ;

< MS Measurement capability > ::=
	< SMS_VALUE : bit (4) >
	< SM_VALUE : bit (4) > ;

< MS Positioning Method Capability > ::=
	< MS Positioning Method : bit(5) > ;

< ECSD Multi Slot Capability > ::=
	< ECSD Multi Slot Class : bit(5) > ;

-- < 8-PSK Struct> : :=
< 8PSK Struct> ::=
	< Modulation Capability : bit >
	{ 0 | 1 < 8-PSK RF Power Capability 1: bit(2) > }
	{ 0 | 1 < 8-PSK RF Power Capability 2: bit(2) > } ;

< Single Band Support > ::=
	< GSM Band : bit (4) > ;



Figure 10.5.1.7/3GPP TS 24.008 Mobile Station Classmark 3 information element
Table 10.5.1.7/3GPP TS 24.008: Mobile Station Classmark 3 information element
Multiband Supported (3 bit field)

Band 1 supported
Bit	1
	0	P-GSM not supported
	1	P-GSM supported

Band 2 supported
Bit	2
	0	E-GSM or R-GSM not supported
	1	E-GSM or R-GSM supported

Band 3 supported
Bit	3
	0	GSM 1800 not supported
	1	GSM 1800 supported

The indication of support of P-GSM band or E-GSM or R-GSM band is mutually exclusive.

When the 'Band 2 supported' bit indicates support of E-GSM or R-GSM, the presence of the <R Support> field, see below, indicates if the E-GSM or R-GSM band is supported.

In this version of the protocol, the sender indicates in this field either none, one or two of these 3 bands supported.

For single band mobile station or a mobile station supporting none of the GSM 900 bands(P-GSM, E-GSM and R-GSM) and GSM 1800 bands, all bits are set to 0.

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

Associated Radio capability 1 and 2 (4 bit fields)

If either of P-GSM or E-GSM or R-GSM is supported, the radio capability 1 field indicates the radio capability for P-GSM, E-GSM or R-GSM, and the radio capability 2 field indicates the radio capability for GSM 1800 if supported, and is spare otherwise.

If none of P-GSM or E-GSM or R-GSM are supported, the radio capability 1 field indicates the radio capability for GSM 1800, and the radio capability 2 field is spare.

The radio capability contains the binary coding of the power class associated with the band indicated in multiband support bits (see 3GPP TS 45.005 [33]).


 (continued...)
Table 10.5.1.7/3GPP TS 24.008 (continued): Mobile Station Classmark 3 information element
R-GSM band Associated Radio Capability (3 bit field)

In case where the R-GSM band is supported the R-GSM band associated radio capability field contains the binary coding of the power class associated (see 3GPP TS 45.005 [33]) (regardless of the number of GSM bands supported). A mobile station supporting the R-GSM band shall also when appropriate, (see 10.5.1.6) indicate its support in the 'FC' bit in the Mobile Station Classmark 2 information element.

NOTE: The coding of the power class for P-GSM, E-GSM, R-GSM and GSM 1800 in radio capability 1 and/or 2 is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.

HSCSD Multi Slot Class (5 bit field)

In case the MS supports the use of multiple timeslots for HSCSD then the HSCSD Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32].

UCS2 treatment (1 bit field)

This information field indicates the likely treatment by the mobile station of UCS2 encoded character strings. If not included, the value 0 shall be assumed by the receiver.
	0	the ME has a preference for the default alphabet (defined in 3GPP TS 23.038 [8b]) over UCS2.
	1	the ME has no preference between the use of the default alphabet and the use of UCS2.

Extended Measurement Capability (1 bit field)

This bit indicates whether the mobile station supports 'Extended Measurements' or not
	0	the MS does not support Extended Measurements
	1	the MS supports Extended Measurements

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 neighbour 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 neighbour 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)

MS Positioning Method (5 bit field)	
This field indicates the Positioning Method(s) supported by the mobile station for the provision of location services (LCS) via the CS domain in A-mode.
MS assisted E-OTD 
Bit	5
	0	MS assisted E-OTD not supported
	1	MS assisted E-OTD supported

Table 10.5.1.7/3GPP TS 24.008 (continued): Mobile Station Classmark 3 information element

MS based E-OTD
Bit 4
	0	MS based E-OTD not supported
	1	MS based E-OTD supported

MS assisted GPS
Bit 3
	0	MS assisted GPS not supported
	1	MS assisted GPS supported

MS based GPS
Bit 2
	0	MS based GPS not supported
	1	MS based GPS supported

MS Conventional GPS
Bit 1
	0	conventional GPS not supported
	1	conventional GPS supported

ECSD Multi Slot class (5 bit field) 

An MS that supports ECSD shall include this field to indicate its ECSD capability. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the value of the Modulation Capability field in the 8-PSK struct. The ECSD Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32].

8-PSK struct

The MS shall include the 8-PSK struct if it supports ECSD or DTM EGPRS or both. 

Modulation Capability

The Modulation Capability field indicates the modulation scheme the MS supports in addition to GMSK.
	0	8-PSK supported for downlink reception only
	1	8-PSK supported for uplink transmission and downlink reception

8-PSK RF Power Capability 1 (2 bit field) 
If 8-PSK modulation is supported for both uplink and downlink, the 8-PSK RF Power Capability 1 field indicates the radio capability for 8‑PSK modulation in GSM 400, GSM 700, GSM 850 or GSM 900.

8-PSK RF Power Capability 2 (2 bit field) 
If 8-PSK modulation is supported for both uplink and downlink, the 8-PSK RF Power Capability 2 field indicates the radio capability for 8‑PSK modulation in GSM 1800 or GSM 1900 if supported, and is not included otherwise.

The respective 8-PSK RF Power Capability 1 and 8-PSK RF Power Capability 2 fields contain the following coding of the 8‑PSK modulation power class (see 3GPP TS 45.005 [33]):
Bits	2 1
		0 0		Reserved
		0 1		Power class E1
		1 0		Power class E2
		1 1		Power class E3

Table 10.5.1.7/3GPP TS 24.008 (continued): Mobile Station Classmark 3 information element

GSM 400 Bands Supported (2 bit field)
See the semantic rule for the sending of this field.
Bits
	2 1
	0 1		GSM 480 supported, GSM 450 not supported
	1 0		GSM 450 supported, GSM 480 not supported
	1 1		GSM 450 supported, GSM 480 supported 

GSM 400 Associated Radio Capability (4 bit field)
If either GSM 450 or GSM 480 or both is supported, the GSM 400 Associated Radio Capability field indicates the radio capability for GSM 450 and/or GSM 480.

The radio capability contains the binary coding of the power class associated with the band indicated in GSM 400 Bands Supported bits (see 3GPP TS 45.005 [33]).

NOTE: The coding of the power class for GSM 450 and GSM 480 in GSM 400 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.

GSM 850 Associated Radio Capability (4 bit field)
See the semantic rule for the sending of this field.
This field indicates whether GSM 850 band is supported and its associated radio capability. 

The radio capability contains the binary coding of the power class associated with the GSM 850 band (see 3GPP TS 45.005 [33]).

Note: the coding of the power class for GSM 850 in GSM 850 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.

GSM 1900 Associated Radio Capability (4 bit field)
See the semantic rule for the sending of this field.
This field indicates whether GSM 1900 band is supported and its associated radio capability.

The radio capability contains the binary coding of the power class associated with the GSM 1900 band (see 3GPP TS 45.005 [33]).

Note: the coding of the power class for GSM 1900 in GSM 1900 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.


Table 10.5.1.7/3GPP TS 24.008 (continued): Mobile Station Classmark 3 information element
UMTS FDD Radio Access Technology Capability (1 bit field)
	0	UMTS FDD not supported 
	1	UMTS FDD supported

UMTS 3.84 Mcps TDD Radio Access Technology Capability (1 bit field)
	0	UMTS 3.84 Mcps TDD not supported 
	1	UMTS 3.84 Mcps TDD supported

CDMA 2000 Radio Access Technology Capability (1 bit field)
	0	CDMA2000 not supported
	1	CDMA2000 supported

DTM GPRS Multi Slot Class (2 bit field)
This field indicates the DTM GPRS multislot capabilities of the MS. It is coded as follows:
Bit
	2 1
	0 0		Unused. If received, the network shall interpret this as ‘01’
	0 1		Multislot class 5 supported
	1 0		Multislot class 9 supported
	1 1		Multislot class 11 supported

If a multislot class type 1 MS indicates the support of a DTM GPRS multislot class for which three uplink timeslots can be assigned, the mobile station shall support Extended Dynamic Allocation.

This field shall contain one of the following values if the DTM GPRS High Multi Slot Class field is present:

    • Multislot class 9	if DTM GPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41;
    • Multislot class 11	if DTM GPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44.

The same multislot capability is applicable also for EGPRS2 if supported.

Single Slot DTM (1 bit field)
This field indicates whether the MS supports single slot DTM operation (see 3GPP TS 43.055 [87]). It is coded as follows:
	0	Single Slot DTM not supported
	1	Single Slot DTM supported
An MS indicating support for Extended DTM GPRS multislot class or Extended DTM EGPRS multislot class shall set this bit to ‘1’. The network may ignore the bit in this case.
DTM EGPRS Multi Slot Class (2 bit field)
This field indicates the DTM EGPRS multislot capabilities of the MS. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the value of the Modulation Capability field in the 8-PSK struct. This field shall be included only if the mobile station supports EGPRS DTM. This field is coded as the DTM GPRS Multi Slot Class field.

If a multislot class type 1 MS indicates the support of a DTM EGPRS multislot class for which three uplink timeslots can be assigned, the mobile station shall support Extended Dynamic Allocation.

This field shall contain one of the following values if the DTM EGPRS High Multi Slot Class field is present:

    • Multislot class 9	if DTM EGPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41;
    • Multislot class 11	if DTM EGPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44.

Single Band Support
This field shall be sent if the mobile station supports UMTS and one and only one GSM band with the exception of R-GSM; this field shall not be sent otherwise

GSM Band (4 bit field)
Bits
	4 3 2 1
	0 0 0 0		E-GSM is supported
	0 0 0 1		P-GSM is supported
	0 0 1 0		GSM 1800 is supported
	0 0 1 1		GSM 450 is supported
	0 1 0 0		GSM 480 is supported
	0 1 0 1		GSM 850 is supported
	0 1 1 0		GSM 1900 is supported
	0 1 1 1		GSM 750 is supported
	1 0 0 0		GSM 710 is supported
	1 0 0 1		T-GSM 810 is supported
All other values are reserved for future use.

NOTE: When this field is received, the associated RF power capability is found in Classmark 1 or 2.

GSM 750 Associated Radio Capability (4 bit field)

See the semantic rule for the sending of this field.
This field indicates whether GSM 750 band is supported and its associated radio capability. 

The radio capability contains the binary coding of the power class associated with the GSM 750 band (see 3GPP TS 45.005 [33]).

NOTE: The coding of the power class for GSM 750 in GSM 750 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.

UMTS 1.28 Mcps TDD Radio Access Technology Capability (1 bit field)
	0	UMTS 1.28 Mcps TDD not supported 
	1	UMTS 1.28 Mcps TDD supported

GERAN Feature Package 1 (1 bit field)
This field indicates whether the MS supports the GERAN Feature Package 1 (see 3GPP TS 44.060 [76]). It is coded as follows:

	0	GERAN feature package 1 not supported.
	1	GERAN feature package 1 supported.

Extended DTM GPRS Multi Slot Class (2 bit field)
This field indicates the extended DTM GPRS multislot capabilities of the MS and shall be interpreted in conjunction with the DTM GPRS Multi Slot Class field. It is coded as follows, where ‘DGMSC’ denotes the DTM GPRS Multi Slot Class field:
DGMSC Bit	2 1		Bit	2 1
				0 0			0 0		Unused. If received, it shall be interpreted as ‘01 00’
				0 0			0 1		Unused. If received, it shall be interpreted as ‘01 00’
				0 0			1 0		Unused. If received, it shall be interpreted as ‘01 00’
				0 0			1 1		Unused. If received, it shall be interpreted as ‘01 00’
				0 1			0 0		Multislot class 5 supported
				0 1			0 1		Multislot class 6 supported
				0 1			1 0		Unused. If received, it shall be interpreted as ‘01 00’
				0 1			1 1		Unused. If received, it shall be interpreted as ‘01 00’
				1 0			0 0		Multislot class 9 supported
				1 0			0 1		Multislot class 10 supported
				1 0			1 0		Unused. If received, it shall be interpreted as ‘10 00’
				1 0			1 1		Unused. If received, it shall be interpreted as ‘10 00’
				1 1			0 0		Multislot class 11 supported
				1 1			0 1		Unused. If received, it shall be interpreted as ’11 00’
				1 1			1 0		Unused. If received, it shall be interpreted as ’11 00’
				1 1			1 1		Unused. If received, it shall be interpreted as ’11 00’

The presence of this field indicates that the MS supports combined fullrate and halfrate GPRS channels in the downlink.When this field is not present, the MS supports the multislot class indicated by the DTM GPRS Multi Slot Class field.

If this field is included, it shall contain one of the following values if the DTM GPRS High Multi Slot Class field is present:

    • Multislot class 10	if DTM GPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41;
    • Multislot class 11	if DTM GPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44.

Extended DTM EGPRS Multi Slot Class (2 bit field)
This field is not considered when the DTM EGPRS Multi Slot Class field is not included. This field indicates the extended DTM EGPRS multislot capabilities of the MS and shall be interpreted in conjunction with the DTM EGPRS Multi Slot Class field. This field is coded as the Extended DTM GPRS Multi Slot Class field. The presence of this field indicates that the MS supports combined fullrate and halfrate GPRS channels in the downlink. When this field is not present, the MS supports the multislot class indicated by the DTM EGPRS Multi Slot Class field.

If this field is included, it shall contain one of the following values if the DTM EGPRS High Multi Slot Class field is present:

    • Multislot class 10	if DTM EGPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41;
    • Multislot class 11	if DTM EGPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44.

High Multislot Capability (2 bit field)
This field indicates the support of multislot classes 30 to 45, see 3GPP TS 45.002 [32].
The High Multislot Capability is individually combined with each multislot class field sent by the MS (the possible multislot class fields are: GPRS multislot class, EGPRS multislot class) to extend the related multislot class with the rule described in the MS Radio Access Capability IE. The same capability is applicable also to EGPRS2 if supported.

GERAN Feature Package 2 (1 bit field)
This field indicates the MS support of the GERAN Feature Package 2. The GERAN Feature Package 2 includes Enhanced Power Control (EPC) (see 3GPP TS 45.008 [34]).

	0	GERAN feature package 2 not supported.
	1	GERAN feature package 2 supported.

GMSK Multislot Power Profile (2 bit field)
This field indicates the GMSK multislot power capability parameter GMSK_MULTISLOT_POWER_PROFILE as described in 3GPP TS 45.005 [33].

Bits
2 1
0 0		GMSK_MULTISLOT_POWER_PROFILE 0
0 1		GMSK_MULTISLOT_POWER_PROFILE 1
1 0		GMSK_MULTISLOT_POWER_PROFILE 2
1 1		GMSK_MULTISLOT_POWER_PROFILE 3

8-PSK Multislot Power Profile (2 bit field)
This field indicates the 8-PSK multislot power capability parameter 8‑PSK_MULTISLOT_POWER_PROFILE as described in 3GPP TS 45.005 [33]. If the MS does not support 8-PSK in the uplink, then it shall set this field to ‘0 0’.

Bits
2 1
0 0		8-PSK_MULTISLOT_POWER_PROFILE 0
0 1		8-PSK_MULTISLOT_POWER_PROFILE 1
1 0		8-PSK_MULTISLOT_POWER_PROFILE 2
1 1		8-PSK_MULTISLOT_POWER_PROFILE 3

T-GSM 400 Bands Supported (2 bit field)
See the semantic rule for the sending of this field.
Bits
	2 1
	0 1		T-GSM 380 supported, T-GSM 410 not supported
	1 0		T-GSM 410 supported, T-GSM 380 not supported
	1 1		T-GSM 410 supported, T-GSM 380 supported 

T-GSM 400 Associated Radio Capability (4 bit field)
If either T-GSM 410 or T-GSM 380 or both is supported, the T-GSM 400 Associated Radio Capability field indicates the radio capability for T-GSM 410 and/or T-GSM 380.

The radio capability contains the binary coding of the power class associated with the band indicated in T-GSM 400 Bands Supported bits (see 3GPP TS 45.005 [33]).

NOTE: The coding of the power class for T-GSM 410 and T-GSM 380 in T-GSM 400 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.

Downlink Advanced Receiver Performance (2 bit field)
This field indicates Downlink Advanced Receiver Performance capabilities of the MS (see 3GPP TS 45.005 [33]).
Bits
2 1
0 0		Downlink Advanced Receiver Performance not supported
0 1		Downlink Advanced Receiver Performance – phase I supported
1 0		Downlink Advanced Receiver Performance – phase II supported

The value ‘11’ shall not be used by the MS.
If the value ‘11’ is received by the network, it shall be interpreted as ‘10’.

DTM Enhancements Capability (1 bit field) 
This field indicates whether the mobile station supports enhanced DTM CS establishment and enhanced DTM CS release or not. It is coded as follows:

	0	The mobile station does not support enhanced DTM CS establishment and enhanced DTM CS release procedures. 
	1	The mobile station supports enhanced DTM CS establishment and enhanced DTM CS release procedures.

DTM GPRS High Multi Slot Class (3 bit field)
This field indicates the DTM GPRS multislot capabilities of the MS. It is coded as follows:

	Bit
	3 2 1
	0 0 0		Unused. If received, the network shall interpret this as ‘0 0 1’
	0 0 1		Multislot class 31 or 36 supported
	0 1 0		Multislot class 32 or 37 supported
	0 1 1		Multislot class 33 or 38 supported
	1 0 0		Multislot class 41 supported
	1 0 1		Multislot class 42 supported
	1 1 0		Multislot class 43 supported
	1 1 1		Multislot class 44 supported

The presence of this field indicates that the MS supports the DTM extension to high multislot classes. When this field is not present, the MS supports the DTM multislot class indicated by the DTM GPRS Multi Slot Class field.

The values '0 0 1', '0 1 0' and '0 1 1' shall be interpreted as indicating DTM GPRS multislot class 36, 37 or 38 respectively if the Offset required field indicates that the offset t0 is required; in all other cases those codepoints shall be interpreted as indicating DTM GPRS multislot class 31, 32 or 33 respectively.

Offset required (1 bit field)
This field indicates whether the GPRS multislot class of the mobile station is such that the Timing Advance offset t0 is required (see 3GPP TS 45.002 [32]). It is coded as follows:

	0	The mobile station does not require the offset 
	1	The mobile station requires the offset

DTM EGPRS High Multi Slot Class (3 bit field)
This field indicates the DTM EGPRS multislot capabilities of the MS. This field may be included only if the mobile station supports EGPRS DTM. This field is coded as the DTM GPRS High Multi Slot Class field. When this field is not present, the MS supports the DTM multislot class indicated by the DTM EGPRS Multi Slot Class field.

The values '0 0 1', '0 1 0' and '0 1 1' shall be interpreted as indicating DTM EGPRS multislot class 36, 37 or 38 respectively if the Offset required field indicates that the Timing Advance offset t0 is required; in all other cases those codepoints shall be interpreted as indicating DTM EGPRS multislot class 31, 32 or 33 respectively.

The same multislot capability is applicable also for EGPRS2 if supported

Repeated ACCH Capability (1 bit field)
This field indicates whether the MS supports Repeated SACCH and Repeated Downlink FACCH (see 3GPP TS 44.006 [19]). It is coded as follows:

	0	The mobile station does not support Repeated SACCH
	1	The mobile station supports Repeated SACCH and Repeated Downlink FACCH

An MS that only supports Repeated Downlink FACCH shall set this bit field to ‘0’.

GSM 710 Associated Radio Capability (4 bit field)
See the semantic rule for the sending of this field.
This field indicates whether GSM 710 band is supported and its associated radio capability. 

The radio capability contains the binary coding of the power class associated with the GSM 710 band (see 3GPP TS 45.005 [33]).

NOTE: The coding of the power class for GSM 710 in GSM 710 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.

T-GSM 810 Associated Radio Capability (4 bit field)
See the semantic rule for the sending of this field.
This field indicates whether T- GSM 810 band is supported and its associated radio capability. 

The radio capability contains the binary coding of the power class associated with the T-GSM 810 band (see 3GPP TS 45.005 [33]).

NOTE: The coding of the power class for T-GSM 810 in T-GSM 810 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.

Ciphering Mode Setting Capability (1 bit field)
This field indicates whether the MS supports the Ciphering Mode Setting IE in the DTM ASSIGNMENT COMMAND message (see 3GPP TS 44.018 [84]). It is coded as follows:

	0	The mobile station does not support the Ciphering Mode Setting IE in the 
		DTM ASSIGNMENT COMMAND message
	1	The mobile station supports the Ciphering Mode Setting IE in the DTM ASSIGNMENT COMMAND 
		message

Additional Positioning Capabilities (1 bit field)
This field indicates whether the mobile station supports additional positioning capabilities which can be retrieved using RRLP. It is coded as follows:

	0	The mobile station does not support additional positioning capabilities which can be retrieved using 				RRLP
	1	The mobile station supports additional positioning capabilities which can be retrieved using RRLP.

E-UTRA FDD support (1 bit field)
Bit
0		E-UTRA FDD not supported
1		E-UTRA FDD supported

E-UTRA TDD support (1 bit field)
Bit
0		E-UTRA TDD not supported
1		E-UTRA TDD supported

E-UTRA Measurement and Reporting support (1 bit field)
This field indicates whether the mobile station supports E-UTRAN neighbouring cell measurements and measurement reporting in dedicated mode and, if the mobile station is DTM capable, also in dual transfer mode. If both "E-UTRA FDD support" and "E-UTRA TDD support" bits are set to '0', this field shall be set to '0'. If one of or both "E-UTRA FDD support"and "E-UTRA TDD support" bits are set to '1', this field may be set to '0' or '1'. It is coded as follows:

Bit
	0	E-UTRAN Neighbour Cell measurements and measurement reporting while having an RR connection
		not supported
	1	E-UTRAN Neighbour Cell measurements and measurement reporting while having an RR connection
		supported

Priority-based reselection support (1 bit field)
This field indicates whether the mobile station supports priority-based cell reselection. It is coded as follows:

Bit
	0	Priority-based cell reselection not supported
	1	Priority-based cell reselection supported

UTRA CSG Cells Reporting (1 bit field)
This field indicates whether the mobile station supports reporting of measurements and routing parameters (see 3GPP TS 44.018 [84]) for UTRAN CSG cells in dedicated mode and, if the mobile station is DTM capable, also in dual transfer mode. This capability shall apply to each UTRA radio access mode supported by the mobile. It is coded as follows: 
Bit
	0	Reporting of UTRAN CSG cells not supported
	1	Reporting of UTRAN CSG cells supported

VAMOS Level (2 bit field)
This field indicates the VAMOS support of the MS and the VAMOS level supported. It is coded as follows: 

	Bits
	2 1
	0 0		VAMOS not supported
	0 1		VAMOS I supported
	1 0		VAMOS II supported
	1 1		VAMOS III supported.

TIGHTER Capability (2 bit field)
This field indicates Tightened Link Level Performance support in the MS (see 3GPP TS 45.005 [33]). The tightened performance applies to the traffic channels and signalling channels specified in 3GPP TS 45.005 [33].
The field is coded as follows:

Bits
2 1
0 0		TIGHTER not supported
0 1		TIGHTER supported for speech and signalling channels only
1 0		TIGHTER supported for speech and signalling channels and for GPRS and EGPRS, but not for EGPRS2
1 1		TIGHTER supported for speech and signalling channels and for GPRS, EGPRS and EGPRS2

Selective Ciphering of Downlink SACCH (1 bit field)
This field indicates whether the mobile station supports Selective Ciphering of Downlink SACCH (see 3GPP TS 44.018 [84]). It is coded as follows: 

Bit
	0	Selective Ciphering of Downlink SACCH not supported
	1	Selective Ciphering of Downlink SACCH supported

CS to PS SRVCC from GERAN to UTRA (2 bit field)
This field indicates whether the mobile station supports CS to PS SRVCC to UTRAN. If" UMTS FDD Radio Access Technology Capability" and" UMTS 1.28 Mcps TDD Radio Access Technology Capability" bitsare set to ‘0’ this field shall be set to ‘00’. If one or both bits are set to ‘1’ this field may be set to ‘01’ or ‘10’ or ‘11’. It is coded as follows:

Bits
	2 1
	0 0		CS to PS SRVCC from GERAN to U MTS FDD and 1.28 Mcps TDD not supported
	0 1		CS to PS SRVCC from GERAN to UMTS FDD supported
	1 0		CS to PS SRVCC from GERAN to UMTS 1.28 Mcps TDD supported
	1 1		CS to PS SRVCC from GERAN to UMTS FDD and 1.28 Mcps TDD supported


CS to PS SRVCC from GERAN to E-UTRA (2 bit field)
This field indicates whether the mobile station supports CS to PS SRVCC to E-UTRAN. If both "E-UTRA FDD support" and "E-UTRA TDD support" bits are set to '0', this field shall be set to '00'. If one or both "E-UTRA FDD support" and "E-UTRA TDD support" bits are set to '1', this field may be set to '01' or '10' or ‘11’. A mobile station not compliant to the UE E-UTRA capability requirements as defined in 3GPP TS 36.306 [153] shall set this field to '00'. It is coded as follows:

Bits
	2 1
	0 0		CS to PS SRVCC from GERAN to E-UTRA FDD and TDD not supported
	0 1		CS to PS SRVCC from GERAN to E-UTRA FDD supported
	1 0		CS to PS SRVCC from GERAN to E-UTRA TDD supported
	1 1		CS to PS SRVCC from GERAN to E-UTRA FDD and TDD supported

GERAN Network Sharing support (1 bit field)
This field indicates whether the mobile station supports GERAN network sharing. A mobile station supporting GERAN network sharing shall also support the extended EARFCN value range in GERAN and indicate this in the respective bit. The field is coded as follows:

Bit
	0	GERAN network sharing not supported
	1	GERAN network sharing supported

E-UTRA Wideband RSRQ measurements support (1 bit field)
This field indicates whether the mobile station supports E-UTRA wideband RSRQ measurements (see 3GPP TS 45.008 [151]). It is coded as follows:

Bit
	0	E-UTRA wideband RSRQ measurements not supported
	1	E-UTRA wideband RSRQ measurements supported


ER Band Support (1 bit field)
This field indicates whether the mobile station supports ER-GSM band (see 3GPP TS 45.005 [33]). It is coded as follows: 

Bit
	0	ER-GSM not supported
	1	ER-GSM supported

NOTE: When ER-GSM is supported, the associated RF power capability is found in Mobile Station Classmark 1, Mobile Station Classmark 2 and/or Mobile Station Classmark 3. The ER-GSM band associated radio capability is the same as for the R-GSM band (see R-GSM band Associated Radio Capability).

UTRA Multiple Frequency Band Indicators support (1 bit field)
This field indicates whether the mobile station supports multiple radio frequency bands in UTRAN (see 3GPP TS 25.331 [23c]) and whether it understands signalling of overlapping UTRA frequency bands (see 3GPP TS 44.018 [84]). It is coded as follows:

Bit
	0	Multiple Frequency Band Indicators in UTRAN not supported
	1	Multiple Frequency Band Indicators in UTRAN supported

E-UTRA Multiple Frequency Band Indicators support (1 bit field)
This field indicates whether the mobile station supports multiple radio frequency bands in E-UTRAN (see 3GPP TS 36.331 [129]) and whether it understands signalling of overlapping E-UTRA frequency bands (see 3GPP TS 44.018 [84]). It is coded as follows:

Bit
	0	Multiple Frequency Band Indicators in E-UTRAN not supported
	1	Multiple Frequency Band Indicators in E-UTRAN supported

Extended TSC Set Capability support (1 bit field)
This field indicates whether the mobile station supports the extended TSC sets when operating in the PS or CS domain (see 3GPP TS 45.002 [32]). It is coded as follows:

Bit
	0	Extended TSC sets not supported
	1	Extended TSC sets supported

Extended EARFCN value range (1 bit field)
This field indicates whether the mobile station supports the extended EARFCN value range in GERAN (see 3GPP TS 44.018 [84]). It is coded as follows:

Bit
	0	Extended EARFCN value range not supported
	1	Extended EARFCN value range supported


10.5.1.8	Spare Half Octet
This element is used in the description of messages in clause 9 when an odd number of half octet type 1 information elements are used. This element is filled with spare bits set to zero and is placed in bits 5 to 8 of the octet unless otherwise specified.
10.5.1.9	Descriptive group or broadcast call reference
The purpose of the Descriptive Group or Broadcast Call Reference is to provide information describing a voice group or broadcast call. The IE of the Descriptive Group or Broadcast Call Reference is composed of the group or broadcast call reference together with a service flag, an acknowledgement flag, the call priority and the group cipher key number.
The Descriptive Group or Broadcast Call Reference information element is coded as shown in figure 10.5.8/3GPP TS 24.008 and Table10.5.8/3GPP TS 24.008
The Descriptive Group or Broadcast Call Reference is a type 3 information element with 6 octets length.

8
7
6
5
4
3
2
1


Group or broadcast call reference IEI
octet 1

Binary coding of the group or broadcast call reference

octet 2



octet 3



octet 4



SF

AF

call priority

octet 5

Spare

Ciphering information
0
0
0
0
octet 6

Figure 10.5.8/3GPP TS 24.008 Descriptive Group or Broadcast Call Reference
Table 10.5.8/3GPP TS 24.008 Descriptive Group or Broadcast Call Reference
Binary code of the group or broadcast call reference
The length of the binary code has 27 bits which is encoded in the octet 2, 3, 4 and Bits 8,7,6 (octet 5).
The highest bit of the BC is the bit 8 in the octet 2 and the lowest bit is allocated in the bit 6 in the octet 5. (see also 3GPP TS 23.003 [10])
SF Service flag (octet 5)
Bit
5



0


VBS (broadcast call reference)
1


VGCS (group call reference)




AF Acknowledgement flag (octet 5), network to MS direction:
Bit
4



0


acknowledgement is not required
1


acknowledgement is required




Call priority (octet 5)
Bit
3
2
1

0
0
0
no priority applied
0
0
1
call priority level 4
0
1
0
call priority level 3
0
1
1
call priority level 2
1
0
0
call priority level 1
1
0
1
call priority level 0
1
1
0
call priority level B
1
1
1
call priority level A




Ciphering information (octet 6)
Bit
8
7
6
5

0
0
0
0
no ciphering
0
0
0
1
ciphering with cipher key number 1
0
0
1
0
ciphering with cipher key number 2
0
0
1
1
ciphering with cipher key number 3
0
1
0
0
ciphering with cipher key number 4
0
1
0
1
ciphering with cipher key number 5
0
1
1
0
ciphering with cipher key number 6
0
1
1
1
ciphering with cipher key number 7
1
0
0
0
ciphering with cipher key number 8
1
0
0
1
ciphering with cipher key number 9
1
0
1
0
ciphering with cipher key number A
1
0
1
1
ciphering with cipher key number B
1
1
0
0
ciphering with cipher key number C
1
1
0
1
ciphering with cipher key number D
1
1
1
0
ciphering with cipher key number E
1
1
1
1
ciphering with cipher key number F

AF Acknowledgement flag (octet 5), MS to network direction:
Bit 4 is spare and shall be set to "0".




Call priority (octet 5)
Bits 1 to 3 are spare and shall be set to "0".




Ciphering information (octet 6)
Bits 5 to 8 are spare and shall be set to "0".


10.5.1.10	Group Cipher Key Number
The purpose of the Group Cipher Key Number is to provide information on the group cipher key to be used for ciphering and deciphering by the mobile station.
The Group Cipher Key Number information element is coded as shown in figure 10.5.9/3GPP TS 24.008 and Table10.5.9/3GPP TS 24.008
The Group Cipher Key Number is a type 1 information element with 1 octet length.

8
7
6
5
4
3
2
1

Group cipher key number
IEI

Group cipher key number


Figure 10.5.9/3GPP TS 24.008 Group Cipher Key Number
Table 10.5.9/3GPP TS 24.008 Group Cipher Key Number
Group cipher key number
Bit
4
3
2
1

0
0
0
0
spare
0
0
0
1
cipher key number 1
0
0
1
0
cipher key number 2
0
0
1
1
cipher key number 3
0
1
0
0
cipher key number 4
0
1
0
1
cipher key number 5
0
1
1
0
cipher key number 6
0
1
1
1
cipher key number 7
1
0
0
0
cipher key number 8
1
0
0
1
cipher key number 9
1
0
1
0
cipher key number A
1
0
1
1
cipher key number B
1
1
0
0
cipher key number C
1
1
0
1
cipher key number D
1
1
1
0
cipher key number E
1
1
1
1
cipher key number F


10.5.1.10a	PD and SAPI $(CCBS)$
The purpose of the PD and SAPI information element is to provide information concerning Protocol Discriminators and Service Access Point Identifiers.
The PD and SAPI information element is coded as shown in figure 10.5.10/3GPP TS 24.008 and table 10.5.10/3GPP TS 24.008.
The PD and SAPI is a type 3 information element with 2 octets length.

8
7
6
5
4
3
2
1


PD and SAPI IEI
octet 1
0
spare
0
spare
SAPI
PD

octet 2

Figure10.5.10/3GPP TS 24.008
PD and SAPI information element
Table 10.5.1.10/3GPP TS 24.008: PD and SAPI information element

SAPI: Service Access Point Identifier (octet 2)

Bits
6
5


0
0

SAPI 0
0
1

reserved
1
0

reserved
1
1

SAPI 3

PD: Protocol Discriminator (octet 2)
bits 4-1
Encoded as specified in subclause 11.2.1 of 3GPP TS 24.007 [20].


10.5.1.11	Priority Level
The purpose of the Priority Level is to provide information defining the priority level requested or applied. The Priority Level IE may be included in CM_SERVICE_REQUEST, CALL_PROCEEDING and SETUP messages.
The Priority Level information element is coded as shown in figure 10.5.11/3GPP TS 24.008 and table 10.5.11/3GPP TS 24.008.
The Priority Level is a type 1 information element with 1 octet length.

8
7
6
5
4
3
2
1


Priority Level
IEI
0
spare
call priority

octet 1

Figure 10.5.11/3GPP TS 24.008 Priority Level
Table 10.5.11/3GPP TS 24.008 Priority Level
Call priority (octet 1)
Bit
3
2
1

0
0
0
no priority applied
0
0
1
call priority level 4
0
1
0
call priority level 3
0
1
1
call priority level 2
1
0
0
call priority level 1
1
0
1
call priority level 0
1
1
0
call priority level B
1
1
1
call priority level A


10.5.1.12	Core Network System Information (Iu mode only)
The purpose of the Core Network System Information is to provide the MS with actual parameter settings of system information parameters controlling MM and GMM functionality. The Core Network system information is included in specific information elements within some RRC messages sent to MS, see 3GPP TS 25.331 [23c].
NOTE:	These IEs do not have an IEI or a length indicator, because these IEs are never present in any layer 3 messages, Hence these IEs do not conform to the general IE rules defined in 3GPP TS 24.007 [20].
10.5.1.12.1	CN Common GSM-MAP NAS system information
The purpose of the CN Common GSM-MAP NAS system information element is to provide the MS with actual parameter settings of parameters relevant for both MM and GMM functionality. The coding of the information element identifier and length information is defined in the 3GPP TS 25.331 [23c]. Only the coding of the content is in the scope of the present document.
The content of the CN common GSM-MAP NAS system information element is coded as shown in figure 10.5.1.12.1/3GPP TS 24.008 and table 10.5.1.12.1/3GPP TS 24.008.
The length of this element content is two octets. The MS shall ignore any additional octets received.

8
7
6
5
4
3
2
1

LAC
octet 1

octet 2

Figure 10.5.1.12.1/3GPP TS 24.008 Common system information element
Table 10.5.1.12.1/3GPP TS 24.008: Common system information element
LAC, Location Area Code (2 octet field)
This field is the binary representation of the Location Area Code, see 3GPP TS 23.003 [10]. The LAC field consists of 16 bits. Bit 8 in octet 1 is the most significant bit and bit 1 in octet 2 is the least significant bit.

10.5.1.12.2	CS domain specific system information
The purpose of the CN domain specific GSM-MAP NAS system information element, when used for the CS domain, is to provide the MS with actual parameter settings of parameters relevant only for MM functionality. The coding of the information element identifier and length information is defined in the 3GPP TS 25.331 [23c]. Only the coding of the content is in the scope of the present document.
For CS domain, the content of the CN domain specific GSM-MAP NAS system information element is coded as shown in figure 10.5.1.12.2/3GPP TS 24.008 and table 10.5.1.12.2/3GPP TS 24.008. The length of this element content is two octets. The MS shall ignore any additional octets received.

8
7
6
5
4
3
2
1

T3212
octet 1
Spare
ATT
octet 2

Figure 10.5.1.12.2/3GPP TS 24.008 CS domain specific system information element
Table 10.5.1.12.2/3GPP TS 24.008: CS domain specific system information element
T3212 timeout value (1 octet field)
The T3212 timeout field is coded as the binary representation of the timeout value for periodic updating in decihours. Bit 8 in octet 1 is the most significant bit and bit 1 in octet 1 is the least significant bit.
Range: 1 to 255
The value 0 is used for infinite timeout value i.e. periodic updating shall not be used

ATT, Attach-detach allowed (1 bit field):
Bit 	1
 	0	MSs shall not apply IMSI attach and detach procedure.
 	1	MSs shall apply IMSI attach and detach procedure 

The bits 2 – 8 of octet 2 are spare and shall be coded all zeros.

10.5.1.12.3	PS domain specific system information
The purpose of the CN domain specific GSM-MAP NAS system information element, when used for the PS domain, is to provide the MS with actual parameter settings of parameters relevant only for GMM functionality. The coding of the information element identifier and length information is defined in the 3GPP TS 25.331 [23c]. Only the coding of the content is in the scope of the present document.
For PS domain, the content of the CN domain specific GSM-MAP NAS system information element is coded as shown in figure 10.5.1.12.3/3GPP TS 24.008 and table 10.5.1.12.3/3GPP TS 24.008. The length of this element content is two octets. The MS shall ignore any additional octets received.

8
7
6
5
4
3
2
1

RAC
octet 1
Spare
NMO I 
NMO
octet 2


Figure 10.5.1.12.3/3GPP TS 24.008 PS domain specific system information element 
Table 10.5.1.12.3/3GPP TS 24.008: PS domain specific system information element
RAC, Routing Area Code (8 bit field)
This field is the binary representation of the Routing Area Code, see 3GPP TS 23.003 [10]. Bit 8 in octet 1 is the most significant bit and bit 1 in octet 1 is the least significant bit.

NMO, Network Mode of Operation (1 bit field) 
This field is the binary representation of the Network Mode of Operation, see 3GPP TS 23.060 [74]
Bit	1
 	0	Network Mode of Operation I
 	1	Network Mode of Operation II

NMO I, Network Mode of Operation I (1 bit field) 
This field is the binary representation of whether the Network Mode of Operation I is applicable for the MS configured for NMO_I_Behaviour, see 3GPP TS 24.368 [135] or 3GPP TS 31.102 [112]
Bit	2
 	0	Network Mode of Operation indicated in Bit 1 (NMO, Network Mode of Operation) is used for MS configured for NMO_I_Behaviour
 	1	Network Mode of Operation I is used for MS configured for NMO_I_Behaviour

The bits 3 – 8 of octet 2 are spare and shall be coded all zeros.

10.5.1.13	PLMN list
The purpose of the PLMN List information element is to provide a list of PLMN codes to the mobile station.
The PLMN List information element is coded as shown in figure 10.5.13/3GPP TS 24.008 and table 10.5.13/3GPP TS 24.008.
The PLMN List is a type 4 information element with a minimum length of 5 octets and a maximum length of 47 octets.

8
7
6
5
4
3
2
1



PLMN List IEI

octet 1

Length of PLMN List contents

octet 2

MCC digit 2, PLMN 1

MCC digit 1, PLMN 1

octet 3

MNC digit 3, PLMN 1

MCC digit 3, PLMN 1

octet 4

MNC digit 2, PLMN 1

MNC digit 1, PLMN 1

octet 5



















MCC digit 2, PLMN 15

MCC digit 1, PLMN 15

octet 45

MNC digit 3, PLMN 15

MCC digit 3, PLMN 15

octet 46

MNC digit 2, PLMN 15

MNC digit 1, PLMN 15

octet 47

Figure 10.5.13/3GPP TS 24.008 PLMN List information element
Table 10.5.13/3GPP TS 24.008: PLMN List information element

MCC, Mobile country code (octet 3, octet 4 bits 1 to 4)
The MCC field is coded as in ITU-T Rec. E212, Annex A. 

MNC, Mobile network code (octet 5, octet 4 bits 5 to 8).
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 over the radio interface. In this case, bits 5 to 8 of octet 4 shall be coded as "1111". Mobile equipment shall accept MNC coded in such a way.



10.5.1.14	NAS container for PS HO
The purpose of the NAS container for PS HO information element is to indicate the NAS specific information for the PS handover to A/Gb mode. The NAS container for PS HO information element is included in the PS HO command message, see 3GPP TS 44.060 [76]. The coding of the information element identifier and length information is defined in 3GPP TS 44.060 [76]. 
The content of the NAS container for PS HO information element is coded as shown in figure 10.5.1.14/3GPP TS 24.008 and table 10.5.1.14/3GPP TS 24.008. The length of this information element is 5 octets. The MS shall ignore any additional octets received.

8
7
6
5
4
3
2
1

0
spare
0
spare
0
spare
old
XID
0
spare
Type of ciphering algorithm
octet 1
IOV-UI value (High-order octet)
octet 2
IOV-UI value (continued)
octet 3 
IOV-UI value (continued)
octet 4 
IOV-UI value (Low-order octet)
octet 5 

Figure 10.5.1.14/3GPP TS 24.008 NAS container for PS HO information element
Table 10.5.1.14/3GPP TS 24.008: NAS container for PS HO information element
Type of ciphering algorithm (octet 1, bits 1 to 3)
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

Bit 4 of octet 1 is spare and shall be coded as zero.

old XID (octet 1, bit 5):
With this bit the network indicates, which LLC layer parameters and layer‑3 parameters the MS shall use in the target cell after it has performed the Reset of LLC and SNDCP.

Bit 	5
	0	The MS shall perform a Reset of LLC and SNDCP without old XID indicator as specified in
		3GPP TS 44.064 [78a] and 3GPP TS 44.065 [78].
	1	The MS shall perform a Reset of LLC and SNDCP with old XID indicator as specified in
		3GPP TS 44.064 [78a] and 3GPP TS 44.065 [78].

The bits 6 – 8 of octet 1 are spare and shall be coded all zeroes.

IOV-UI value (octet 2 to 5)
The IOV-UI value consists of 32 bits, the format is defined in 3GPP TS 44.064 [78a].


10.5.1.15	MS network feature support
The purpose of the MS network feature support information element is to indicate support of mobility management parameters during the tracking area updating, location updating, routing area updating, IMSI attach, GPRS attach, and EPS attach procedures.
The MS network feature support information element is coded as shown in figure 10.5.1.15/3GPP TS 24.008 and table 10.5.1.15/3GPP TS 24.008.
The MS network feature support information element is a type 1 information element.

8
7
6
5
4
3
2
1

MS network feature support
IEI
0
Spare
0
Spare
0
Spare
extended periodic timers 
octet 1

Figure 10.5.1.15/3GPP TS 24.008: MS network feature support information element
Table 10.5.1.15/3GPP TS 24.008: MS network feature support information element
Extended periodic timers (octet 1) 

Bit 
1

0
MS does not support the extended periodic timer in this domain 
1
MS supports the extended periodic timer in this domain

The relevant extended periodic timer is T3212 for MM messages, T3312 for GMM messages, and T3412 for EMM messages.

Bits 4, 3 and 2 of octet 1 are spare and shall be coded as zero.


10.5.2	Radio Resource management information elements.
See 3GPP TS 44.018 [84].
10.5.3	Mobility management information elements.
10.5.3.1	Authentication parameter RAND
The purpose of the Authentication Parameter RAND information element is to provide the mobile station with a non-predictable number to be used to calculate the authentication response signature SRES and the ciphering key Kc (for a GSM authentication challenge), or the response RES and both the ciphering key CK and integrity key IK (for a UMTS authentication challenge).
The Authentication Parameter RAND information element is coded as shown in figure 10.5.75/3GPP TS 24.008 and table 10.5.89/3GPP TS 24.008.
The Authentication Parameter RAND is a type 3 information element with 17 octets length.

8
7
6
5
4
3
2
1

Authentication parameter RAND IEI
octet 1

RAND value

octet 2




octet 17


Figure 10.5.75/3GPP TS 24.008 Authentication Parameter RAND information element
Table 10.5.89/3GPP TS 24.008: Authentication Parameter RAND information element
RAND value (octet 2, 3,... and 17)
The RAND value consists of 128 bits. Bit 8 of octet 2 is the most significant bit while bit 1 of octet 17 is the least significant bit.

10.5.3.1.1	Authentication Parameter AUTN (UMTS and EPS authentication challenge)
The purpose of the Authentication Parameter AUTN information element is to provide the MS with a means of authenticating the network.
The Authentication Parameter AUTN information element is coded as shown in figure 10.5.75.1/3GPP TS 24.008 and table 10.5.89.1/3GPP TS 24.008.
The Authentication Parameter AUTN is a type 4 information element with a length of 18 octets.

8
7
6
5
4
3
2
1

Authentication Parameter AUTN IEI
octet 1
Length of AUTN contents
octet 2

octet 3
AUTN




octet 18

Figure 10.5.75.1/3GPP TS 24.008 Authentication Parameter AUTN information element (UMTS and EPS authentication challenge)
Table 10.5.89.1/3GPP TS 24.008 Authentication Parameter AUTN information element (UMTS and EPS authentication challenge) 
AUTN value (octets 3 to 18)
The AUTN consists of	(SQN xor AK)||AMF||MAC
							=48+16+64 bits
							(see 3GPP TS 33.102 [5a])

Bit 8 of octet 9 is the "separation bit" of the AMF field (see 3GPP TS 33.401 [123]).


10.5.3.2	Authentication Response parameter
The purpose of the authentication response parameter information element is to provide the network with the authentication response calculated in the SIM/USIM.
The Authentication Parameter SRES information element is coded as shown in figure 10.5.76/3GPP TS 24.008 and tables 10.5.90 a & b /3GPP TS 24.008.
The Authentication Response Parameter is a type 3 information element with 5 octets length. In a GSM authentication challenge, the response calculated in the SIM/USIM (SRES) is 4 bytes in length, and is placed in the Authentication Response Parameter information element.
In a UMTS authentication challenge, the response calculated in the USIM (RES) may be up to 16 octets in length. The 4 most significant octets shall be included in the Authentication Response Parameter information element. The remaining part of the RES shall be included in the Authentication Response Parameter (extension) IE (see subclause 10.5.3.2.1)

8
7
6
5
4
3
2
1

Authentication Response parameter IEI
octet 1


SRES value or most significant
4 octets of RES
:
octet 2


:

octet 5


Figure 10.5.76/3GPP TS 24.008 Authentication Response Parameter information element
Table 10.5.90a/3GPP TS 24.008: Authentication Response Parameter information element
(SRES) (GSM authentication challenge only)
SRES value (octet 2, 3, 4 and 5)
The SRES value consists of 32 bits. Bit 8 of octet 2 is the most significant bit while bit 1 of octet 5 is the least significant bit.

Table 10.5.90b/3GPP TS 24.008: Authentication Response Parameter information element (RES) (UMTS authentication challenge only)
RES value (octet 2, 3, 4 and 5)
This contains the most significant 4 octets of RES
If RES>4 octets, the remaining octets of RES shall appear in the Authentication Response Parameter (extension) IE (see subclause 10.5.3.2.1)

10.5.3.2.1	Authentication Response Parameter (extension) (UMTS authentication challenge only)
This IE is included if the authentication response parameter RES is longer than 4 octets (UMTS only) and therefore does not fit in the Authentication Response Parameter field (see 10.5.3.2).
The Authentication Response parameter (extension) IE is coded as shown in figure 10.5.76.1/3GPP TS 24.008 and table 10.5.90.1/3GPP TS 24.008.
The Authentication Response parameter (extension) IE is a type 4 information element with a minimum length of 3 octets and a maximum length of 14 octets.

8
7
6
5
4
3
2
1

Authentication Response (extension) IEI
octet 1
Length of Authentication Response contents
octet 2
RES (all but 4 most significant octets)
:
octet 3

:


octet 14

Figure 10.5.76.1/3GPP TS 24.008 Authentication Response Parameter (extension) information element (UMTS authentication challenge only)
Table 10.5.90.1/3GPP TS 24.008: Authentication Response Parameter (extension) information element (RES)
RES (extension) value (octet 3 to 14)

This contains all but the 4 most significant octets of RES


10.5.3.2.2	Authentication Failure parameter (UMTS and EPS authentication challenge)
The purpose of the Authentication Failure parameter information element is to provide the network with the necessary information to begin a re-authentication procedure (see 3GPP TS 33.102 [5a]) in the case of a 'Synch failure', following a UMTS or EPS authentication challenge.
The Authentication Failure parameter IE is coded as shown in figure 10.5.76.2/3GPP TS 24.008 and table 10.5.90.2/3GPP TS 24.008.
The Authentication Failure parameter IE is a type 4 information element with a length of 16 octets.

8
7
6
5
4
3
2
1

Authentication Failure parameter IEI
octet 1
Length ofAuthentication Failure parameter contents
octet 2
Authentication Failure parameter
:
octet 3

:


octet 16

Figure 10.5.76.2/3GPP TS 24.008 Authentication Failure parameter information element (UMTS and EPS authentication challenge)
Table 10.5.90.2/3GPP TS 24.008: Authentication Failure parameter information element
Authentication Failure parameter value (octet 3 to 16)

This contains AUTS (see 3GPP TS 33.102 [5a])


10.5.3.3	CM service type
The purpose of the CM Service Type information element is to specify which service is requested from the network.
The CM Service Type information element is coded as shown in figure 10.5.77/3GPP TS 24.008 and table 10.5.91/3GPP TS 24.008.
The CM Service Type is a type 1 information element.

8
7
6
5
4
3
2
1

CM service type IEI
service type
octet 1

Figure 10.5.77/3GPP TS 24.008 CM Service Type information element
Table 10.5.91/3GPP TS 24.008: CM Service Type information element
Service type (octet 1)
Bits
4
3
2
1

0
0
0
1
Mobile originating call establishment or packet mode connection establishment
0
0
1
0
Emergency call establishment
0
1
0
0
Short message service
1
0
0
0
Supplementary service activation
1
0
0
1
Voice group call establishment
1
0
1
0
Voice broadcast call establishment
1
0
1
1
Location Services	(NOTE)





All other values are reserved.
NOTE:		this service type shall only be used by a type A LMU if the MM connection was requested for the transmission of LCS signalling messages specified in 3GPP TS 44.071 [23a].

10.5.3.4	Identity type
The purpose of the Identity Type information element is to specify which identity is requested.
The Identity Type information element is coded as shown in figure 10.5.78/3GPP TS 24.008 and table 10.5.92/3GPP TS 24.008.
The Identity Type is a type 1 information element.

8
7
6
5
4
3
2
1

Identity type IEI
0
spare
type of identity
octet 1

Figure 10.5.78/3GPP TS 24.008 Identity Type information element
Table 10.5.92/3GPP TS 24.008: Identity Type 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
1
0
1

P-TMSI, RAI, P-TMSI signature





All other values are reserved.

10.5.3.5	Location updating type
The purpose of the Location Updating Type information element is to indicate whether a normal updating, a periodic updating or an IMSI attach is wanted. It may also indicate that a follow-on request has been received from the mobile station CM layer.
The Location Updating Type information element is coded as shown in figure 10.5.79/3GPP TS 24.008 and table 10.5.93/3GPP TS 24.008.
The Location Updating Type is a type 1 information element.

8
7
6
5
4
3
2
1

Location updating
type IEI
FOR
0
spare
LUT
octet 1

Figure 10.5.79/3GPP TS 24.008 Location Updating Type information element
Table 10.5.93/3GPP TS 24.008: Location Updating Type information element
LUT (octet 1)
Bits
2
1



0
0


Normal location updating
0
1


Periodic updating
1
0


IMSI attach
1
1


Reserved





FOR (octet 1)
The Follow-On Request bit (FOR) is coded as follows:
Bits
4




0



No follow-on request pending
1



Follow-on request pending






10.5.3.5a	Network Name
The purpose of this information element is to pass a text string to the mobile station.
The Network Name information element is coded as shown in figure 10.5.80/3GPP TS 24.008 and table 10.5.94/3GPP TS 24.008.
If the coding scheme UCS2 is used and Chinese-Japanese-Korean-Vietnamese (CJKV) ideographs as defined in ISO/IEC 10646 [72] are received in the text string, the MS shall use the MCC of the PLMN from which it received the network name information element to determine the language for those CJKV ideographs as specified in table 10.5.93a/3GPP TS 24.008:
Table 10.5.93a/3GPP TS 24.008: MCC to CJKV ideograph language mapping table
MCC(s)
Country/Region
Language
(C, J, K, or V)
460, 461
Mainland China
Chinese-G
466
Taiwan
Chinese-T
454
HongKong
Chinese-T
455
Macao
Chinese-T
440, 441
Japan
J (Kanji)
450, 467
Korea
K (Hanja)
452
Vietnam
V (Chunom)

NOTE:	This is due to CJKV ideograph language ambiguity in UCS2, in the sense that the same hexadecimal code can be mapped to different character displays dependent on the used language. The coding of CJKV ideographs itself does not allow to discriminate the CJKV ideograph language.
The Network Name is a type 4 information element with a minimum length of 3 octets. No upper length limit is specified except for that given by the maximum number of octets in a L3 message (see 3GPP TS 44.006 [19]).

8
7
6
5
4
3
2
1


Network Name IEI
octet 1

Length of Network Name contents

octet 2
ext
1
coding scheme
Add
CI
Number of spare
bits in last octet

octet 3


octet 4
Text String




octet n

Figure 10.5.80/3GPP TS 24.008 Network Name information element
Table 10.5.94/3GPP TS 24.008 Network Name information element
Number of spare bits in last octet (octet 3, bits 1 to 3)

2
1



0
0
1

bit 8 is spare and set to "0" in octet n
0
1
0

bits 7 and 8 are spare and set to "0" in octet n
0
1
1

bits 6 to 8(inclusive) are spare and set to "0" in octet n
1
0
0

bits 5 to 8(inclusive) are spare and set to "0" in octet n
1
0
1

bits 4 to 8(inclusive) are spare and set to "0" in octet n
1
1
0

bits 3 to 8(inclusive) are spare and set to "0" in octet n
1
1
1

bits 2 to 8(inclusive) are spare and set to "0" in octet n
0
0
0

this field carries no information about the number of spare bits in octet n





Add CI (octet 3, bit 4)

0



The MS should not add the letters for the Country's Initials to the text string
1



The MS should add the letters for the Country's Initials and a separator




(e.g. a space) to the text string

Coding Scheme (octet 3, bits 5-7)

0
0
0

Cell Broadcast data coding scheme, GSM default alphabet, language unspecified, defined in 3GPP TS 23.038 [8b]
0
0
1

UCS2 (16 bit) [72]
0
1
0


to
reserved
1
1
1







Text String (octet 4 to octet n, inclusive)
Encoded according to the Coding Scheme defined by octet 3, bits 5-7

10.5.3.6	Reject cause
The purpose of the Reject Cause information element is to indicate the reason why a request from the mobile station is rejected by the network.
The Reject Cause information element is coded as shown in figure 10.5.81/3GPP TS 24.008 and table 10.5.95/3GPP TS 24.008.
The Reject Cause is a type 3 information element with 2 octets length.

8
7
6
5
4
3
2
1

Reject cause IEI
octet 1

reject cause value

octet 2

Figure 10.5.81/3GPP TS 24.008 Reject Cause information element
Table 10.5.95/3GPP TS 24.008: Reject Cause information element
Reject 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
0
0

IMSI unknown in VLR
0
0
0
0
0
1
0
1

IMEI not accepted
0
0
0
0
0
1
1
0

Illegal ME
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
1

No Suitable Cells In Location Area
0
0
0
1
0
0
0
1

Network failure
0
0
0
1
0
1
0
0

MAC failure
0
0
0
1
0
1
0
1

Synch failure
0
0
0
1
0
1
1
0

Congestion
0
0
0
1
0
1
1
1

GSM authentication unacceptable
0
0
0
1
1
0
0
1

Not authorized for this CSG
0
0
1
0
0
0
0
0

Service option not supported
0
0
1
0
0
0
0
1

Requested service option not subscribed
0
0
1
0
0
0
1
0

Service option temporarily out of order
0
0
1
0
0
1
1
0

Call cannot be identified
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 0010 0010, 'Service option temporarily out of order'. 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.3.7	Follow-on Proceed
The purpose of the Follow-on Proceed information element is to indicate that an MM connection may be established on an existing RR connection.
The Follow-on Proceed information element is coded as shown in figure 10.5.82/3GPP TS 24.008.
The Follow-on Proceed is a type 2 information element.

8
7
6
5
4
3
2
1

Follow-on Proceed IEI
octet 1

Figure 10.5.82/3GPP TS 24.008 Follow-on Proceed information element
10.5.3.8	Time Zone
The purpose of this information element is to encode the offset between universal time and local timein steps of 15 minutes.
The Time Zone information element is coded as shown in figure 10.5.83/3GPP TS 24.008 and table 10.5.96/3GPP TS 24.008.
The Time Zone is a type 3 information element with a length of 2 octets.

8
7
6
5
4
3
2
1


Time Zone IEI
octet 1
Time Zone

octet 2

Figure 10.5.83/3GPP TS 24.008 Time Zone information element
Table 10.5.96/3GPP TS 24.008 Time Zone information element

Time Zone (octet 2, bits 1-8)
This field uses the same format as the Timezone field used in the TP-Service-Centre-Time-Stamp, which is defined in 3GPP TS 23.040 [90], and its value shall be set as defined in 3GPP TS 22.042 [89]


10.5.3.9	Time Zone and Time
The purpose of the timezone part of this information element is to encode the offset between universal time and local time in steps of 15 minutes.
The purpose of the time part of this information element is to encode the universal time at which this information element may have been sent by the network.
The Time Zone and Time information element is coded as shown in figure 10.5.84/3GPP TS 24.008 and table 10.5.97/3GPP TS 24.008.
The Time Zone and Time is a type 3 information element with a length of 8 octets.

8
7
6
5
4
3
2
1


Time Zone and Time IEI
octet 1
Year

octet 2
Month

octet 3
Day

octet 4
Hour

octet 5
Minute

octet 6
Second

octet 7
Time zone

octet 8

Figure 10.5.84/3GPP TS 24.008 Time Zone and Time information element
Table 10.5.97/3GPP TS 24.008 Timezone and Time information element
Year (octet 2, bits 1-8)

This field uses the same format as the Year field used in the TP-Service-Centre-Time-Stamp, which is defined in 3GPP TS 23.040 [90], and its value shall be set as defined in 3GPP TS 22.042 [89]

Month (octet 3, bits 1-8) 
This field uses the same format as the Month field used in the TP-Service-Centre-Time-Stamp, which is defined in 3GPP TS 23.040 [90], and its value shall be set as defined in 3GPP TS 22.042 [89].
Day (octet 4, bits 1-8)
This field uses the same format as the Day field used in the TP-Service-Centre-Time-Stamp, which is defined in 3GPP TS 23.040 [90], and its value shall be set as defined in 3GPP TS 22.042 [89].

Hour (octet 5, bits 1-8)
This field uses the same format as the Hour field used in the TP-Service-Centre-Time-Stamp, which is defined in 3GPP TS 23.040 [90], and its value shall be set as defined in 3GPP TS 22.042 [89].

Minute (octet 6, bits 1-8)
This field uses the same format as the Minute field used in the TP-Service-Centre-Time-Stamp, which is defined in 3GPP TS 23.040 [90], and its value shall be set as defined in 3GPP TS 22.042 [89].

Second (octet 7, bits 1-8)
This field uses the same format as the Second field used in the TP-Service-Centre-Time-Stamp, which is defined in 3GPP TS 23.040 [90], and its value shall be set as defined in 3GPP TS 22.042 [89].

Time Zone (octet 8, bits 1-8)
This field uses the same format as the Time Zone field used in the TP-Service-Centre-Time-Stamp, which is defined in 3GPP TS 23.040 [90], and its value shall be set as defined in 3GPP TS 22.042 [89].


NOTE:	Due to ambiguities in earlier versions of the protocol specifications, some mobile stations may interpret the received NITZ time as local time. This may result in incorrect time settings in the mobile.
10.5.3.10	CTS permission
The purpose of the CTS permission information element is to indicate that the mobile station is allowed to use GSM-Cordless Telephony System in the Location Area. The CTS permission information element is coded as shown in figure 10.5.84a/3GPP TS 24.008.
The CTS permission is a type 2 information element.

8
7
6
5
4
3
2
1

CTS Permission IEI
octet 1

Figure 10.5.84a/3GPP TS 24.008 CTS permission information element
10.5.3.11	LSA Identifier
This element uniquely identifies a LSA.
The LSA Identifier information element is coded as shown in figure 10.68c/3GPP TS 24.008.
The LSA Identifier is a type 4 information element with a length of 2 or 5 octets.

8
7
6
5
4
3
2
1


LSA Identifier IEI
octet 1
Length of LSA Identifier contents

octet 2
LSA ID

octet 3
LSA ID cont.

octet 4
LSA ID cont.

octet 5

Figure 10.68c/3GPP TS 24.008 LSA Identifier information element
If the Length = 0, then no LSA ID is included. This is used to indicate that the MS has moved to an area where there is no LSA available for that MS.
Octets 3-5 are coded as specified in 3GPP TS 23.003 [10], 'Identification of Localised Service Area'. Bit 8 of octet 3 is the most significant bit.
10.5.3.12	Daylight Saving Time
The purpose of this information element is to encode the Daylight Saving Time in steps of 1 hour.
The Daylight Saving Time information element is coded as shown in figure 10.5.84b/3GPP TS 24.008 and table 10.5.97a/3GPP TS 24.008.
The Daylight Saving Time is a type 4 information element with a length of 3 octets.

8
7
6
5
4
3
2
1

Daylight Saving Time IEI
octet 1

Length of Daylight Saving Time contents

octet 2
spare
value

0
0
0
0
0
0

octet 3

Figure 10.5.84b/3GPP TS 24.008 Daylight Saving Time information element
Table 10.5.97a/3GPP TS 24.008: Daylight Saving Time information element
Daylight Saving Time value (octet 3)
Bits
2
1



0
0


No adjustment for Daylight Saving Time
0
1


+1 hour adjustment for Daylight Saving Time
1
0


+2 hours adjustment for Daylight Saving Time
1
1


Reserved






10.5.3.13	Emergency Number List
The purpose of this information element is to encode emergency number(s) for use within the country where the IE is received.
The Emergency Number List information element is coded as shown in figure 10.5.84c/3GPP TS 24.008.
The Emergency Number List IE is a type 4 information element with a minimum length of 5 octets and a maximum length of 50 octets.

8
7
6
5
4
3
2
1

Emergency Number List IEI
octet 1
Length of Emergency Number List IE contents
octet 2
Length of 1st Emergency Number information (Note 1)
octet 3
Spare
Emergency Service Category Value
octet 4
0
0
0


Number digit 2
Number digit 1
octet 5


(Note 2)
Number digit 4
Number digit 3
octet 6*



:
:
:



(Note 3)

octet j-1*



Length of 2nd Emergency Number information (Note 1)
octet j*
Spare
Emergency Service Category Value
octet j+1*
0
0
0


Number digit 2
Number digit 1
octet j+2*


(Note 2)
Number digit 4
Number digit 3
octet j+3*



:
:
:



(Note 3)
:
octet j+k*



.
.
.
.
.
.
Length of xth Emergency Number information (Note 1)
octet n*
Spare
Emergency Service Category Value
octet n+1*
0
0
0


Number digit 2
Number digit 1
octet n+2*


(Note 2)
Number digit 4
Number digit 3
octet n+3*



:
:
:



(Note 3)
:
octet n+m*




NOTE 1:	The length contains the number of octets used to encode the Emergency Service Category Value and the Number digits.
NOTE 2:	The number digit(s) in octet 5 precedes the digit(s) in octet 6 etc. The number digit, which would be entered first, is located in octet 5, bits 1 to 4. The contents of the number digits are coded as shown in table 10.5.118/3GPP TS 24.008.
NOTE 3:	If the emergeny number contains an odd number of digits, bits 5 to 8 of the last octet of the respective emergency number shall be filled with an end mark coded as "1111".

Figure 10.5.84c/3GPP TS 24.008 Emergency Number List information element
Table 10.5.97aa/3GPP TS 24.008: Emergency Number List information element
Emergency Service Category Value (octet 4, j+1, n+1, etc.; bit 1 to 5)

Bits 1 to 5 are coded as bits 1 to 5 of octet 3 of the Service Category information element as specified in subclause 10.5.4.33.


10.5.3.14	Additional update parameters
The purpose of the Additional update parameters information element is to provide additional information during the location updating procedure and during MM connection establishment.
The Additional update parameters information element is coded as shown in figure 10.5.84d/3GPP TS 24.008 and table 10.5.97b/3GPP TS 24.008.
The Additional update parameters information element is a type 1 information element.

8
7
6
5
4
3
2
1

Additional update parameters
IEI
0
Spare
0
Spare
CSMO
CSMT
octet 1

Figure 10.5.84d/3GPP TS 24.008: Additional update parameters information element
Table 10.5.97b/3GPP TS 24.008: Additional update parameters information element
Additional update parameters value (octet 1, bit 1 to 4)

CSMT (1 bit field)

Bit
1

0
No additional information.
1
CS fallback mobile terminating call

CSMO (1 bit field)

Bit
2
0	No additional information.
1	CS fallback mobile originating call

Bits 4 and 3 of octet 1 are spare and shall be all coded as zero.


10.5.3.15	Void
10.5.3.16	MM Timer
The purpose of the MM timer information element is to specify MM specific timer values, e.g. for the timer T3246.
The MM timer is a type 4 information element with 3 octets length.
The MM timer information element is coded as shown in figure 10.5.3.16-1/3GPP TS 24.008 and table 10.5.3.16-1/3GPP TS 24.008.


8
7
6
5
4
3
2
1


MM Timer IEI
octet 1

Length of MM Timer contents
octet 2

MM Timer value
octet 3

Figure 10.5.3.16-1/3GPP TS 24.008: MM Timer information element
Table 10.5.3.16-1/3GPP TS 24.008: MM Timer information element


Timer value (octet 3)

Bits 5 to 1 represent the binary coded timer value.

Bits 6 to 8 defines the timer value unit for the MM timer as follows:
Bits 
8 7 6
0 0 0  value is incremented in multiples of 2 seconds
0 0 1  value is incremented in multiples of 1 minute 
0 1 0  value is incremented in multiples of decihours
1 1 1  value indicates that the timer is deactivated.

Other values shall be interpreted as multiples of 1 minute in this version of the protocol.

The value indicated is contructed by multiplying the value in bits 5 to 1 with the timer value unit in bits 8 to 6, unless the timer value unit indicates the timer being deactivated.


10.5.4	Call control information elements
10.5.4.1	Extensions of codesets
There is a certain number of possible information element identifier values using the formatting rules described in subclause 10.5: 128 from the type 3 & 4 information element format and at least 8 from the type 1 & 2 information element format.
One value in the type 1 format is specified for shift operations described below. One other value in both the type 3 & 4 and type 1 format is reserved. This leaves 133 information element identifier values available for assignment.
It is possible to expand this structure to eight codesets of 133 information element identifier values each. One common value in the type 1 format is employed in each codeset to facilitate shifting from one codeset to another. The contents of this shift information element identifies the codeset to be used for the next information element or elements. The codeset in use at any given time is referred to as the "active codeset". By convention, codeset 0 is the initially active codeset.
Two codeset shifting procedures are supported: locking shift and non-locking shift.
Codeset 5 is reserved for information elements reserved for national use.
Codeset 6 is reserved for information elements specific to the local network (either public or private).
Codeset 7 is reserved for user-specific information elements.
The coding rules specified in subclause 10.5 shall apply for information elements belonging to any active codeset.
The mobile station and the network shall not apply the "comprehension required" scheme (see 3GPP TS 24.007 [20]) to information elements belonging to codesets different from codeset 0.
IEIs with bits 5, 6, 7 and 8 all set to zero should not be allocated for new optional information elements in codesets different from codeset 0, because there are legacy mobile stations that apply the "comprehension required" scheme also to these information elements, e.g. if such a mobile station receives a SETUP message containing an unknown information element from codeset 5 with an IEI with bits 5, 6, 7 and 8 all set to zero, then the mobile station will release the call.
Transitions from one active codeset to another (i.e. by means of the locking shift procedure) may only be made to a codeset with a higher numerical value than the codeset being left.
An information element belonging to codeset 5, 6 or 7 may appear together with information elements belonging to codeset 0, by using the non-locking shift procedure (see subclause 10.5.4.3).
A user or network equipment shall have the capability to recognize a shift information element and to determine the length of the following information element, although the equipment need not be able to interpret and act on the content of the information element. This enables the equipment to determine the start of the subsequent information element.
10.5.4.2	Locking shift procedure
The locking shift procedure employs an information element to indicate the new active codeset. The specified codeset remains active until another locking shift information element is encountered which specifies the use of another codeset. For example, codeset 0 is active at the start of message content analysis. If a locking shift to codeset 5 is encountered, the next information elements will be interpreted according to the information element identifiers assigned in codeset 5, until another shift information element is encountered. This procedure is used only to shift to a higher order codeset than the one being left.
The locking shift is valid only within that message which contains the locking shift information element. At the start of every message content analysis, the active codeset is codeset 0.
The locking shift information element uses the type 1 information element format and coding shown in figure 10.5.85/3GPP TS 24.008 and table 10.5.98/3GPP TS 24.008.

8
7
6
5
4
3
2
1

1
0
0
1
0
New codeset
identification
octet 1

(Shift identifier)






"0" in this position indicates locking shift


Figure 10.5.85/3GPP TS 24.008 Locking shift element
Table 10.5.98/3GPP TS 24.008: Locking shift element
Codeset identification (octet 1):
Bits
3
2
1


0
0
0

not applicable
0
0
1

}
to
 } reserved
1
0
0

}
1
0
1

codeset 5:		information elements for national use
1
1
0

codeset 6:		information elements specific to the local network
				(either public or private)
1
1
1

codeset 7:		user-specific information elements






10.5.4.3	Non-locking shift procedure
The non-locking shift procedure provides a temporary shift to the specified lower or higher codeset. The non-locking shift procedure uses a type 1 information element to indicate the codeset to be used to interpret the next information element. After the interpretation of the next information element, the active codeset is again used for interpreting any following information elements. For example, codeset 0 is active at the beginning of message content analysis. If a non-locking shift to codeset 6 is encountered, only the next information element is interpreted according to the information element identifiers assigned in codeset 6. After this information element is interpreted, codeset 0 will again be used to interpret the following information elements. A non-locking shift information element indicating the current codeset shall not be regarded as an error.
A locking shift information element shall not follow directly a non-locking shift information element. If this combination is received, it shall be interpreted as though a locking shift information element had been received.
The non-locking shift information element uses the type 1 information format and coding shown in figure 10.5.86/3GPP TS 24.008 and table 10.5.99/3GPP TS 24.008.

8
7
6
5
4
3
2
1

1
0
0
1
1
Temporary codeset
identification
octet 1

(Shift identifier)






"1" in this position indicates non-locking shift


Figure 10.5.86/3GPP TS 24.008 Non-locking shift element
Table 10.5.99/3GPP TS 24.008: Non-locking shift element
Codeset identification (octet 1):
Bits
3
2
1


0
0
0

codeset 0 (initially active):
3GPP TS 24.008 information elements
0
0
1

}
to
 } reserved
1
0
0

}
1
0
1

codeset 5:		information elements for national use
1
1
0

codeset 6:		information elements specific to the local network
				(either public or private)
1
1
1

codeset 7:		user-specific information elements






10.5.4.4	Auxiliary states
The purpose of the auxiliary states information element is to describe the current status of the auxiliary states of a call in the call control states "active" and "mobile originating modify" (see 3GPP TS 24.083 [27] and 3GPP TS 24.084 [28]).
The auxiliary states information element is coded as shown in figure 10.5.87/3GPP TS 24.008, table 10.5.100/3GPP TS 24.008 and table 10.5.101/3GPP TS 24.008.
The auxiliary states is a type 4 information element with 3 octets length.

8
7
6
5
4
3
2
1


Auxiliary states IEI
octet 1

Length of auxiliary states contents

octet 2
1
0
0
0
hold aux.
MPTY aux.

ext
spare
state
state
octet 3

Figure 10.5.87/3GPP TS 24.008 Auxiliary states information element
Table 10.5.100/3GPP TS 24.008: Auxiliary states information element
Hold auxiliary state (octet 3)

Bits
4
3



0
0


idle							Note 1
0
1


hold request				Note 1
1
0


call held					Note 1
1
1


retrieve request			Note 1

Note 1:	These states are defined in 3GPP TS 24.083 [27].

Table 10.5.101/3GPP TS 24.008: Auxiliary states information element
Multi party auxiliary state (octet 3)
Bits
2
1



0
0


idle							Note 2
0
1


MPTY request			Note 2
1
0


call in MPTY				Note 2
1
1


split request				Note 2

Note 2:	These states are defined in 3GPP TS 24.084 [28].

10.5.4.4a	Backup bearer capability
The purpose of the backup bearer capability IE is to indicate a requested service to a MS in case a complete description of the bearer service by a bearer capability IE is not available. The backup bearer capability information element is not subject to compatibility checking as described in annex B.
The backup bearer capability IE is coded as shown in figure 10.5.87a/3GPP TS 24.008 and tables 10.5.101a/3GPP TS 24.008 to 10.5.101m/3GPP TS 24.008.
The backup bearer capability is a type 4 information element with a minimum length of 3 octets and a maximum length of 15 octets. 

8
7
6
5
4
3
2
1


Backup bearer capability IEI
octet 1

Length of the backup bearer capability contents

octet 2
1
ext
radio
channel
requirement
co-
ding
std
trans
fer
mode
information
transfer
capability

octet 3
1
ext
comp
-ress.

Structure
dupl.
mode
confi
gur.
NIRR
esta-
bli.

octet 4*
0/1
0
0
rate
signalling

ext
access id.
adaption
access protocol
octet 5*
1


Other rate
0
0
0

ext
Other IT
C
adaption
Spare
octet 5a*
0/1
0
1
User information
sync/

ext
layer 1 id.
layer 1 protocol
async
octet 6*
0/1
ext
numb.
stop
bits
nego-
tia-
tion
numb.
data
bits

user rate

octet 6a*
0/1
ext
intermed.
rate
NIC
on TX
NIC
on RX

Parity

octet 6b*
0/1
ext
connection
element

modem type

octet 6c*
0/1
ext
Other
modem type

Fixed network user rate

octet 6d*
0/1
ext
Acceptable
channel
codings
Maximum number of
traffic channels

octet 6e*
0/1
ext
UIMI
Wanted air interface
user rate

octet 6f*
1
ext
Acceptable
channel codings

Asymmetry
0
0


Extended
Indication
Spare
octet 6g*
1
1
0
User information

ext
layer 2 id.
layer 2 protocol
octet 7*

Figure 10.5.87a/3GPP TS 24.008 Backup bearer capability information element
NOTE:	The coding of the octets of the backup bearer capability IE is not conforming to the coding of the bearer capability IE in ITU-T Recommendation Q.931 [53].
Table 10.5.101a/3GPP TS 24.008: Backup bearer capability information element
Radio channel requirement (octet 3)
In A/Gb mode and GERAN Iu mode, i.e. not applicable for UTRAN Iu mode data services.

Bits 6 and 7 are spare bits. The sending side (i.e. the network) shall set bit 7 to value 0 and bit 6 to value 1.

Coding standard (octet 3)
Bit
5
0	GSM standardized coding as described below 
1	reserved

Transfer mode (octet 3)
Bit
4
0	circuit mode
1	packet mode

Information transfer capability (octet 3)
Bits
3 2 1
0 0 0	speech
0 0 1	unrestricted digital information
0 1 0	3.1 kHz audio, ex PLMN
0 1 1	facsimile group 3
1 0 1	Other ITC (See Octet 5a)
1 1 1	reserved, to be used in the network. 
	The meaning is: alternate speech/facsimile group 3 - starting with speech.

All other values are reserved

Table 10.5.101b/3GPP TS 24.008: Backup bearer capability information element
Compression (octet 4)
Bit 7 is spare and shall be set to “0”.

Structure (octet 4)

Bits
6 5
0 0		service data unit integrity
1 1		unstructured 
 
All other values are reserved. 

Duplex mode (octet 4) 
Bit
4 
0	half duplex 
1	full duplex 

Configuration (octet 4) 
Bit 
3 
0	point-to-point 

All other values are reserved. 

NIRR (octet 4) 
(Negotiation of Intermediate Rate Requested) 
In A/Gb mode and GERAN Iu mode, i.e. not applicable for UTRAN Iu modedata services.
Bit 2 is spare and shall be set to “0”.

Establishment (octet 4) 
Bit 
1
0	demand 

All other values are reserved


Table 10.5.101c/3GPP TS 24.008: Backup bearer capability information element
Access identity (octet 5)
Bits 
7 6 
0 0		octet identifier 

All other values are reserved 


Rate adaption (octet 5) 
Bits 
5 4 
0 0		no rate adaption 
0 1		rate adaptation according to ITU-T Rec. V.110 [60] and ITU-T Rec. X.30 [65]
1 0		flag stuffing according to ITU-T Rec. X.31 [66]
1 1		Other rate adaption (see octet 5a)

Signalling access protocol (octet 5)

Bits 
3 2 1
0 0 1	according to ITU-T Rec. Q.920 [49] and ITU-T Rec. Q.930 [50]

All other values are reserved.


Table 10.5.101d/3GPP TS 24.008: Backup bearer capability information element
Other ITC (octet 5a)
If the value "Other ITC" is not signalled in the field "ITC" then the contents of this field shall be ignored.

Bit
7 6
0 0		restricted digital information

All other values are reserved


Other rate adaption (octet 5a)
If the value " Other rate adaption" is not signalled in the field "Rate adaption" then the contents of this field shall be ignored.
In UTRAN Iu mode, PIAFS (see 3GPP TS 27.001 [36]) shall be considered. In A/Gb mode and GERAN Iu mode, the call shall be rejected if PIAFS is requested.


Bit
5 4
0 0		according to ITU-T Rec. V.120 [61]
0 1		according to ITU-T Rec. H.223 [146] and ITU-T Rec. H.245 [119]
1 0		PIAFS

All other values are reserved.


Table 10.5.101e/3GPP TS 24.008: Backup bearer capability information element
Layer 1 identity (octet 6)
Bits
7 6
0 1		octet identifier 

All other values are reserved 

User information layer 1 protocol (octet 6)
Bits 
5 4 3 2 
0 0 0 0		default layer 1 protocol 

All other values reserved. 

Synchronous/asynchronous (octet 6) 
Bit 
1 
0	synchronous 
1	asynchronous 


Table 10.5.101f/3GPP TS 24.008: Backup bearer capability information element
Number of Stop Bits (octet 6a)
Bit 
7 
0	1 bit (This value is also used in the case of synchronous mode) 
1	2 bits 

Negotiation (octet 6a) 
Bit 
6
0	in-band negotiation not possible 

NOTE:	See ITU-T Rec. V.110 [60] and ITU-T Rec. X.30 [65]

All other values are reserved 

Number of data bits excluding parity bit if present (octet 6a) 
Bit 
5
0	7 bits 
1	8 bits (this value is also used in the case of bit oriented protocols) 

User rate (octet 6a) 
In A/Gb mode and GERAN Iu mode only.

Bits 
4 3 2 1 
0 0 0 0		User rate unknown
0 0 0 1		0.3 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 0 1 0		1.2 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 0 1 1		2.4 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 1 0 0		4.8 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 1 0 1		9.6 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 1 1 0		12.0 kbit/s transparent (non compliance with ITU-T Rec. X.1 [142] and 								ITU-T Rec. V.110 [60])
0 1 1 1		reserved: was allocated in earlier phases of the protocol.

All other values are reserved. 

For facsimile group 3 calls the user rate indicates the first and maximum speed the mobile station is using.


Table 10.5.101g/3GPP TS 24.008: Backup bearer capability information element
Octet 6b for rate adaptation Intermediate rate (octet 6b) according to ITU-T Rec. V.110 [60] and ITU-T Rec. X.30 [65]
In A/Gb mode and GERAN Iu mode only.
If the value "User rate unknown" is signalled in the field "User rate" then the contents of this field shall be ignored.


Bits 
7 6 
0 0		reserved 
0 1		reserved 
1 0		8 kbit/s 
1 1		16 kbit/s 

Network independent clock (NIC) on transmission (Tx) (octet 6b) (See ITU-T Rec. V.110 [60] and ITU-T Rec. X.30 [65]). 
In A/Gb mode and GERAN Iu mode only.


Bit 
5 
0	does not require to send data with network independent clock 
1	requires to send data with network independent clock 

Network independent clock (NIC) on reception (Rx) (octet 6b) (See ITU-T Rec. V.110 [60] and ITU-T Rec. X.30 [65]) 
In A/Gb mode and GERAN Iu mode only.


Bit 
4
0	cannot accept data with network independent clock (i.e. sender does not 	support this optional procedure) 
1	can accept data with network independent clock (i.e. sender does support this 	optional procedure) 

Parity information (octet 6b) 
Bits 
3 2 1 
0 0 0	odd 
0 1 0	even 
0 1 1	none 
1 0 0	forced to 0 
1 0 1	forced to 1 
 
All other values are reserved.


Table 10.5.101h/3GPP TS 24.008: Backup bearer capability information element
Connection element (octet 6c)
Bit 
7 6 
0 0		transparent 
0 1		non transparent (RLP) 
1 0		both, transparent preferred 
1 1		both, non transparent preferred 

The network should use the 4 values depending on its capabilities to support the different modes. 
Modem type (octet 6c)
Bits 
5 4 3 2 1 
0 0 0 0 0	none
0 0 0 0 1	according to ITU-T Rec. V.21 [54] (note 1)
0 0 0 1 0	according to ITU-T Rec. V.22 [55] (note 1)
0 0 0 1 1	according to ITU-T Rec. V.22 bis [56] (note 1)
0 0 1 0 0	reserved: was allocated in earlier phases of the protocol
0 0 1 0 1	according to ITU-T Rec. V.26 ter [58] (note 1)
0 0 1 1 0	according to ITU-T Rec. V.32 [59]
0 0 1 1 1	modem for undefined interface
0 1 0 0 0	autobauding type 1

All other values are reserved.
 Note 1: In A/Gb mode and GERAN Iu mode only.



Table 10.5.101i/3GPP TS 24.008: Backup bearer capability information element
Other modem type (octet 6d)
Bits 
7 6
0 0	no other modem type specified in this field
1 0		according to ITU-T Rec. V.34 [148]

All other values are reserved.

Fixed network user rate (octet 6d)
Bit 
5 4 3 2 1
0 0 0 0 0	Fixed network user rate not applicable/No meaning is associated
			with this value.
0 0 0 0 1	9.6 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 0 0 1 0	14.4 kbit/s (according to ITU-T Rec. X.1 [142] and V.110 [60])
0 0 0 1 1	19.2 kbit/s (according to ITU-T Rec. X.1 [142] and V.110 [60])
0 0 1 0 0	28.8 kbit/s (according to ITU-T Rec. X.1 [142] and V.110 [60])
0 0 1 0 1	38.4 kbit/s (according to ITU-T Rec. X.1 [142] and V.110 [60])
0 0 1 1 0	48.0 kbit/s (according to ITU-T Rec. X.1 [142] and V.110 [60] (synch) (note 1))
0 0 1 1 1	56.0 kbit/s (according to ITU-T Rec. X.1 [142] and V.110 [60] (synch) /bit transparent)
0 1 0 0 0	64.0 kbit/s bit transparent
0 1 0 0 1	33.6 kbit/s bit transparent (note 2)
0 1 0 1 0	32.0 kbit/s (according to ITU-T Rec. I.460 [79])
0 1 0 1 1	31.2 kbit/s (according to ITU-T Rec. V.34 [148] (note 2))

The value "0 1 0 1 1" shall be used only by the network to inform the MS about FNUR modification due to negotiation between the modems in a 3.1 kHz multimedia call.

All other values are reserved. 
Note 1: In A/Gb mode and GERAN Iu mode only.
Note 2: In UTRAN Iu mode only


Table 10.5.101j/3GPP TS 24.008: Backup bearer capability information element
Acceptable channel codings (octet 6e):
Bits 4 to 7 are spare and shall be set to "0".


Maximum number of traffic channels (octet 6e):
Bits 1 to 3 are spare and shall be set to "0".



Table 10.5.101k/3GPP TS 24.008: Backup bearer capability information element
UIMI, User initiated modification indication (octet 6f), 


7 6 5
0 0 0	User initiated modification not allowed/applicable
0 0 1	User initiated modification up to 1 TCH/F allowed/may be requested
0 1 0	User initiated modification up to 2 TCH/F allowed/may be requested
0 1 1	User initiated modification up to 3 TCH/F allowed/may be requested
1 0 0	User initiated modification up to 4 TCH/F allowed/may be requested

All other values shall be interpreted as "User initiated modification up to 4 TCH/F may be requested".

User initiated modification indication is not applicable for transparent connection.

Wanted air interface user rate (octet 6f):
Bits 1 to 4 are spare and shall be set to "0".


Table 10.5.101l/3GPP TS 24.008: Backup bearer capability information element

Layer 2 identity (octet 7)
Bits 
7 6 
1 0		octet identifier 

All other values are reserved 

User information layer 2 protocol (octet 7)

Bits 
5 4 3 2 1 
0 0 1 1 0	reserved: was allocated in earlier phases of the protocol
0 1 0 0 0	according to ISO/IEC 6429 [42], codeset 0 (DC1/DC3)
0 1 0 0 1	reserved: was allocated but never used in earlier phases of the protocol
0 1 0 1 0	videotex profile 1
0 1 1 0 0	COPnoFlCt (Character oriented Protocol with no Flow Control
		mechanism)
0 1 1 0 1	reserved: was allocated in earlier phases of the protocol

All other values are reserved.


Table 10.5.101m/3GPP TS 24.008: Backup bearer capability information element
Acceptable Channel Codings extended (octet 6g):


Bits 3 to 7 are spare and shall be set to "0".

Bits 2 and 1 are spare.


10.5.4.4a.1	Static conditions for the backup bearer capability IE contents
If the information transfer capability field (octet 3) indicates "speech", octets 4, 5, 5a, 5b, 6, 6a, 6b, 6c, 6d, 6e, 6f, 6g and 7 shall not be included. 
If the information transfer capability field (octet 3) indicates a value different from "speech", octets 4 and 5shall be included, octets 6, 6a, 6b, 6c, 6d, 6e, 6f and 6g are optional. In case octet 6 is included, octets 6a, 6b, and 6c shall also be included. In case octet 6d is included, octets 6e, 6f and 6g may be included. If the information transfer capability field (octet 3) indicates "facsimile group 3" and octet 6c is included, the modem type field (octet 6c) shall indicate "none". 
If the information transfer capability field (octet 3) indicates "other ITC" or the rate adaption field (octet 5) indicates "other rate adaption", octet 5a shall be included. 
The modem type field (octet 6c) shall not indicate "autobauding type 1" unless the connection element field (octet 6c) indicates "non transparent".
10.5.4.5	Bearer capability
The purpose of the bearer capability information element is to describe a bearer service. The use of the bearer capability information element in relation to compatibility checking is described in annex B.
The bearer capability information element is coded as shown in figure 10.5.88/3GPP TS 24.008 and tables 10.5.102/3GPP TS 24.008 to 10.5.115/3GPP TS 24.008.
The bearer capability is a type 4 information element with a minimum length of 3 octets and a maximum length of 16 octets.

8
7
6
5
4
3
2
1


Bearer capability IEI
octet 1

Length of the bearer capability contents

octet 2
0/1
ext
radio
channel
requirement
co-
ding
std
trans
fer
mode
information
transfer
capability

octet 3
0/1
0

0


ext
co-
ding
CTM
	spare

speech version
indication
octet 3a *
0/1
0
0
0


ext
co-
ding
spare
spare
Speech version
Indication
octet 3b etc*
1
ext
comp
-ress.

structure
dupl.
mode
confi
gur.
NIRR
esta-
bli.

octet 4*
0/1
0
0
rate
signalling

ext
access id.
adaption
access protocol
octet 5*
0/1


Other rate
0
0
0

ext
Other ITC
adaption
Spare
octet 5a*
1
ext
Hdr/
noHdr
Multi
frame
Mode
LLI
Assig
nor/e
Inb.
neg
0
Spare

octet 5b*
0/1
0
1
User information
sync/

ext
layer 1 id.
layer 1 protocol
async
octet 6*
0/1
ext
numb.
stop
bits
nego-
tia-
tion
numb.
data
bits

user rate

octet 6a*
0/1
ext
intermed.
rate
NIC
on TX
NIC
on RX

Parity

octet 6b*
0/1
ext
connection
element

modem type

octet 6c*
0/1
ext
Other
modem type

Fixed network user rate

octet 6d*
0/1
ext
Acceptable
channel
codings
Maximum number of
traffic channels

octet 6e*
0/1
ext
UIMI
Wanted air interface
user rate

octet 6f*
1
ext
Acceptable
channel codings

Asymmetry
0
0


extended
Indication
Spare
octet 6g*
1
1
0
User information

ext
layer 2 id.
layer 2 protocol
octet 7*

Figure 10.5.88/3GPP TS 24.008 Bearer capability information element
NOTE 1:	The coding of the octets of the bearer capability information element is not conforming to ITU Recommendation Q.931 [53].
An MS shall encode the Bearer Capability infomation element according to A/Gb mode call control requirements also if it is requesting for a service in Iu mode, with the following exceptions:
    1. A mobile station not supporting A/Gb mode and GERAN Iu mode for the requested bearer service shall set the following parameters to the value "0":
-	Maximum number of traffic channels (octet 6e, bits 1-3)
-	Acceptable Channel coding(s) (octet 6e, bits 4, 5 and 7)
    2. Furthermore, a mobile station not supporting A/Gb mode and GERAN Iu mode for the requested bearer service shall also set the following parameters to the value "0", if the respective octets have to be included in the bearer capability information element according to subclause 10.5.4.5.1 and 3GPP TS 27.001 [36]:
-	UIMI, User initiated modification indication (octet 6f, bits 5-7)
-	Acceptable Channel Codings extended (octet 6g, bits 5-7)
For UTRAN Iu mode the following parameters are irrelevant for specifying the radio access bearer, because multiple traffic channels (multislot) are not deployed, see 3GPP TS 23.034 [104]. However, the parameters if received, shall be stored in the MSC, and used for handover to A/Gb or GERAN Iu mode:
-	Maximum number of traffic channels (octet 6e, bits 1-3)
-	Acceptable Channel coding(s) (octet 6e, bits 4, 5 and 7)
-	UIMI, User initiated modification indication (octet 6f, bits 5-7)
-	Acceptable Channel Codings extended (octet 6g, bits 5-7)
NOTE 2:	The following parameters are relevant in UTRAN Iu mode for non transparent data calls for deciding which RLP version to negotiate in order to avoid renegotiation of RLP version in case of inter-system handover from UTRAN Iu mode to A/Gb or GERAN Iu mode, see 3GPP TS 24.022 [141]:
-	Maximum number of traffic channels (octet 6e, bits 1-3)
-	Wanted air interface user rate (octet 6f, bits 1- 4)
-	UIMI, User initiated modification indication (octet 6f, bits 5-7).
Table 10.5.102/3GPP TS 24.008: Bearer capability information element
Radio channel requirement (octet 3), network to MS direction 
In A/Gb mode and GERAN Iu mode, i.e. not applicable for UTRAN Iu mode data services.


Bits 6 and 7 are spare bits. The sending side (i.e. the network) shall set bit 7 to value 0 and bit 6 to value 1.

Radio channel requirement (octet 3) MS to network direction

When information transfer capability (octet 3) indicates other values than speech:
Bits
7 6
0 0		reserved
0 1		full rate support only MS
1 0		dual rate support MS/half rate preferred
1 1		dual rate support MS/full rate preferred

When information transfer capability (octet 3) indicates the value speech and no speech version indication is present in octet 3a etc.:
Bits
7 6
0 0		reserved
0 1		full rate support only MS/fullrate speech version 1 supported
1 0	dual rate support MS/half rate speech version 1 preferred, full rate speech version 1 also supported
1 1	dual rate support MS/full rate speech version 1 preferred, half rate speech version 1 also supported

When information transfer capability (octet 3) indicates the value speech and speech version indication(s) is(are) present in octet 3a etc.:
Bits
7 6
0 0		reserved
0 1		the mobile station supports at least full rate speech version 1 but does not support half rate 		speech version 1. The complete voice codec preference is specified in octet(s) 3a etc.
1 0		The mobile station supports at least full rate speech version 1 and half rate speech version 		1. The mobile station has a greater preference for half rate speech version 1 than for full 			rate speech version 1. The complete voice codec preference is specified in octet(s) 3a etc.
1 1		The mobile station supports at least full rate speech version 1 and half rate speech version 		1. The mobile station has a greater preference for full rate speech version 1 than for half 			rate speech version 1. The complete voice codec preference is specified in octet(s) 3a etc.


(continued...)
Table 10.5.102/3GPP TS 24.008: Bearer capability information element (continued)
Coding standard (octet 3)
Bit
5
0	GSM standardized coding as described below 
1	reserved

Transfer mode (octet 3)
Bit
4
0	circuit mode
1	packet mode

Information transfer capability (octet 3)
Bits
3 2 1
0 0 0	speech
0 0 1	unrestricted digital information
0 1 0	3.1 kHz audio, ex PLMN
0 1 1	facsimile group 3
1 0 1	Other ITC (See Octet 5a)
1 1 1	reserved, to be used in the network. 
	The meaning is: alternate speech/facsimile group 3 - starting with speech.

All other values are reserved

Table 10.5.103/3GPP TS 24.008 Bearer capability information element
Octet(s) 3a etc. MS to network direction
Octet(s) 3a etc., bits 1 to 4 shall only be used to convey speech coding information belonging to a A/Gb mode or GERAN Iu mode. When included for a UTRAN Iu mode call establishment they shall be used for handover to A/Gb mode or GERAN Iu mode.
A mobile station supporting CTM text telephony, but not supporting A/Gb mode or GERAN Iu mode shall encode octet 3a, bits 1 to 4 as “no speech version supported for GERAN”.

Coding

Bit
7
0	octet used for extension of information transfer capability
1	octet used for other extension of octet 3

When information transfer capability (octet 3) indicates speech and coding (bit 7 in octet 3a etc.) is coded as 0, bits 1 through 6 are coded:

CTM text telephony indication (octet 3a)
Bit
6
0  CTM text telephony is not supported
1  CTM text telephony is supported

Bit 6 in octet(s) 3b etc. is spare.

Bit 5 in octet(s) 3a etc. is spare.

Speech version indication (octet(s) 3a etc.)
Bits
4 3 2 1
0 0 0 0		GSM full rate speech version 1   (note 2)
0 0 1 0		GSM full rate speech version 2   (note 2)
0 1 0 0		GSM full rate speech version 3   (note 2)
0 1 1 0		GSM full rate speech version 4   (note 2)
1 0 0 0		GSM full rate speech version 5   (note 2)
0 0 0 1		GSM half rate speech version 1   (note 2)
0 1 0 1		GSM half rate speech version 3   (note 2)
0 1 1 1		GSM half rate speech version 4   (note 2)
1 0 1 1		GSM half rate speech version 6   (note 2)
1 1 1 1		no speech version supported for GERAN (note 1)
All other values have the meaning "speech version tbd" and shall be ignored
when received.

NOTE 1: This value shall only be used by an MS supporting CTM text telephony, but not supporting A/Gb or GERAN Iu mode.

NOTE 2: As defined in 3GPP TS 26.103 [83] and 3GPP TS 48.008 [85].

If octet 3 is extended with speech version indication(s) (octets 3a etc.), all speech versions supported shall be indicated and be included in order of preference (the first octet (3a) has the highest preference and so on). 

If information transfer capability (octet 3) indicates speech and coding (bit 7 in octet 3a etc.) is coded as 1, or the information transfer capability does not indicate speech, then the extension octet shall be ignored.

Octet(s) 3a etc. network to MS direction

The octet(s) 3a etc. shall be ignored by the MS.


Table 10.5.104/3GPP TS 24.008: Bearer capability information element
Compression (octet 4), network to MS direction:
Bit
7
0	data compression not possible
1	data compression possible

Compression (octet 4), MS to network direction:
Bit
7
0	data compression not allowed
1	data compression allowed

Structure (octet 4)

Bits
6 5
0 0	service data unit integrity
1 1	unstructured 
 
All other values are reserved. 

Duplex mode (octet 4) 
Bit
4 
0	half duplex 
1	full duplex 

Configuration (octet 4) 
Bit 
3 
0	point-to-point 

All other values are reserved. 

NIRR (octet 4) 
(Negotiation of Intermediate Rate Requested) 
In A/Gb mode and GERAN Iu mode, i.e. not applicable for UTRAN Iu mode data services.

Bit 
2 
0	No meaning is associated with this value. 
1	Data up to and including 4.8 kb/s, full rate, non-transparent, 6 kb/s radio 	interface rate is requested.

Establishment (octet 4) 
Bit 
1
0	demand 

All other values are reserved


Table 10.5.105/3GPP TS 24.008: Bearer capability information element
Access identity (octet 5)
Bits 
7 6 
0 0	octet identifier 

All other values are reserved 


Rate adaption (octet 5) 
Bits 
5 4 
0 0	no rate adaption 
0 1	rate adaptation according to ITU-T Rec. V.110 [66] and ITU-T Rec. X.30 [65]
1 0	flag stuffing according to ITU-T Rec. X.31 [66]
1 1	Other rate adaption (see octet 5a)

Signalling access protocol (octet 5)

Bits 
3 2 1
0 0 1	according to ITU-T Rec. Q.920 [49] and ITU-T Rec. Q.930 [50]
0 1 0	reserved: was allocated in earlier phases of the protocol
0 1 1	reserved: was allocated in earlier phases of the protocol
1 0 0	reserved: was allocated in earlier phases of the protocol
1 0 1	reserved: was allocated in earlier phases of the protocol
1 1 0	reserved: was allocated in earlier phases of the protocol

All other values are reserved.


Table 10.5.106/3GPP TS 24.008: Bearer capability information element
Other ITC (octet 5a)
If the value "Other ITC" is not signalled in the field "ITC" then the contents of this field shall be ignored.

Bit
7 6
0 0	restricted digital information

All other values are reserved


Other rate adaption (octet 5a)
If the value " Other rate adaption" is not signalled in the field "Rate adaption" then the contents of this field shall be ignored.
In UTRAN Iu mode, PIAFS (see 3GPP TS 27.001 [36]) shall be considered. In A/Gb mode and GERAN Iu mode, the call shall be rejected if PIAFS is requested.


Bit
5 4
0 0		according to ITU-T Rec. V.120 [61]
0 1		according to ITU-T Rec. H.223 [146] and ITU-T Rec. H.245 [119]
1 0		PIAFS

All other values are reserved.


Table 10.5.107/3GPP TS 24.008: Bearer capability information element
Rate adaption header/no header (octet 5b)

Bit
7
0	Rate adaption header not included
1	Rate adaption header included

Multiple frame establishment support in data link (octet 5b)

Bit
6
0	Multiple frame establishment not supported, only UI frames allowed
1	Multiple frame establishment supported

Mode of operation (octet 5b)

Bit
5
0	Bit transparent mode of operation
1	Protocol sensitive mode of operation

Logical link identifier negotiation (octet 5b)

Bit
4
0	Default, LLI=256 only
1	Full protocol negotiation, (note: A connection over which protocol negotiation will
	be executed is indicated in bit 2 of octet 5b)

Assignor/Assignee (octet 5b)

Bit
3
0	Message originator is "default assignee"
1	Message originator is "assignor only"

In band/Out of band negotiation (octet 5b)

Bit
2
0	Negotiation is done in-band using logical link zero
1	Negotiation is done with USER INFORMATION messages on a temporary
	signalling connection

Bit 1 is spare and set to the value "0"


Table 10.5.108/3GPP TS 24.008: Bearer capability information element
Layer 1 identity (octet 6)
Bits
7 6
0 1	octet identifier 

All other values are reserved 

User information layer 1 protocol (octet 6)
Bits 
5 4 3 2 
0 0 0 0	default layer 1 protocol 

All other values reserved. 

Synchronous/asynchronous (octet 6) 
Bit 
1 
0	synchronous 
1	asynchronous 


Table 10.5.109/3GPP TS 24.008: Bearer capability information element
Number of Stop Bits (octet 6a)
Bit 
7 
0	1 bit (This value is also used in the case of synchronous mode) 
1	2 bits 

Negotiation (octet 6a) 
Bit 
6
0	in-band negotiation not possible 

NOTE:	See ITU-T Rec. V.110 [60] and ITU-T Rec. X.30 [65]

All other values are reserved 

Number of data bits excluding parity bit if present (octet 6a) 
Bit 
5
0	7 bits 
1	8 bits (this value is also used in the case of bit oriented protocols) 

User rate (octet 6a) 
In A/Gb mode and GERAN Iu mode only.

Bits 
4 3 2 1 
0 0 0 1		0.3 kbit/s according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60]
0 0 1 0		1.2 kbit/s according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60]
0 0 1 1		2.4 kbit/s according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60]
0 1 0 0		4.8 kbit/s according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60]
0 1 0 1		9.6 kbit/s according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60]
0 1 1 0		12.0 kbit/s transparent (non compliance with ITU-T Rec. X.1 [142] and ITU-						T Rec. V.110 [60]) 
0 1 1 1		reserved: was allocated in earlier phases of the protocol.

All other values are reserved. 

For facsimile group 3 calls the user rate indicates the first and maximum speed the mobile station is using.


Table 10.5.110/3GPP TS 24.008: Bearer capability information element
Octet 6b for V.110/X.30 rate adaptation Intermediate rate (octet 6b) 
In A/Gb mode and GERAN Iu mode only.


Bits 
7 6 
0 0	reserved 
0 1	reserved 
1 0	8 kbit/s 
1 1	16 kbit/s 
 
Network independent clock (NIC) on transmission (Tx) (octet 6b) (See ITU-T Rec. V.110 [60] and ITU-T Rec. X.30 [65])
In A/Gb mode and GERAN Iu mode only.


Bit 
5 
0	does not require to send data with network independent clock 
1	requires to send data with network independent clock 

Network independent clock (NIC) on reception (Rx) (octet 6b) (See ITU-T Rec. V.110 [60] and ITU-T Rec. X.30 [65])
In A/Gb mode and GERAN Iu mode only.


Bit 
4
0	cannot accept data with network independent clock (i.e. sender does not 	support this optional procedure) 
1	can accept data with network independent clock (i.e. sender does support this 	optional procedure) 

Parity information (octet 6b) 
Bits 
3 2 1 
0 0 0	odd 
0 1 0	even 
0 1 1	none 
1 0 0	forced to 0 
1 0 1	forced to 1 
 
All other values are reserved.


Table 10.5.111/3GPP TS 24.008: Bearer capability information element
Connection element (octet 6c)
Bit 
7 6 
0 0	transparent 
0 1	non transparent (RLP) 
1 0	both, transparent preferred 
1 1	both, non transparent preferred 

The requesting end (e.g. the one sending the SETUP message) should use the 4 values depending on its capabilities to support the different modes. The answering party shall only use the codings 00 or 01, based on its own capabilities and the proposed choice if any. If both MS and network support both transparent and non transparent, priority should be given to the MS preference.

Modem type (octet 6c)
Bits 
5 4 3 2 1 
0 0 0 0 0	none
0 0 0 0 1	according to ITU-T Rec. V.21 [54] (note 1)
0 0 0 1 0	according to ITU-T Rec. V.22 [55] (note 1)
0 0 0 1 1	according to ITU-T Rec. V.22 bis [56] (note 1)
0 0 1 0 0	reserved: was allocated in earlier phases of the protocol
0 0 1 0 1	according to ITU-T Rec.V.26 ter [58] (note 1)
0 0 1 1 0	according to ITU-T Rec. V.32 [59]
0 0 1 1 1	modem for undefined interface
0 1 0 0 0	autobauding type 1

All other values are reserved.
 Note 1: In A/Gb mode and GERAN Iu mode only.



Table 10.5.112/3GPP TS 24.008: Bearer capability information element
Other modem type (octet 6d)
Bits 
7 6
0 0	no other modem type specified in this field
1 0		V.34

All other values are reserved.

Fixed network user rate (octet 6d)
Bit 
5 4 3 2 1
0 0 0 0 0	Fixed network user rate not applicable/No meaning is associated
		with this value.
0 0 0 0 1	9.6 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 0 0 1 0	14.4 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 0 0 1 1	19.2 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 0 1 0 0	28.8 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 0 1 0 1	38.4 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60])
0 0 1 1 0	48.0 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60]) (synch)					(note 1)
0 0 1 1 1	56.0 kbit/s (according to ITU-T Rec. X.1 [142] and ITU-T Rec. V.110 [60]) (synch) /bit 				transparent)
0 1 0 0 0	64.0 kbit/s bit transparent
0 1 0 0 1	33.6 kbit/s bit transparent (note 2)
0 1 0 1 0	32.0 kbit/s Recommendation I.460 [79]
0 1 0 1 1	31.2 kbit/s Recommendation V.34 [148] (note 2)

The value "0 1 0 1 1" shall be used only by the network to inform the MS about FNUR modification due to negotiation between the modems in a 3.1 kHz multimedia call.

All other values are reserved. 
Note 1: In A/Gb mode and GERAN Iu mode only.
Note 2: In UTRAN Iu mode only


Table 10.5.113/3GPP TS 24.008: Bearer capability information element
Acceptable channel codings (octet 6e), mobile station to network direction:


Bit 
7
0	TCH/F14.4 not acceptable
1	TCH/F14.4 acceptable

Bit
6
0	Spare

Bit 
5
0	TCH/F9.6 not acceptable
1	TCH/F9.6 acceptable

Bit 
4
0	TCH/F4.8 not acceptable
1	TCH/F4.8 acceptable

Acceptable channel codings (octet 6e), network to MS direction:
Bits 4 to 7 are spare and shall be set to "0".


Maximum number of traffic channels (octet 6e), MS to network direction:


Bits 
3 2 1
0 0 0     1 TCH
0 0 1     2 TCH
0 1 0     3 TCH
0 1 1     4 TCH
1 0 0     5 TCH
1 0 1     6 TCH
1 1 0     7 TCH
1 1 1     8 TCH

Maximum number of traffic channels (octet 6e), network to MS direction:
Bits 1 to 3 are spare and shall be set to "0".



Table 10.5.114/3GPP TS 24.008: Bearer capability information element
UIMI, User initiated modification indication (octet 6f), 


7 6 5
0 0 0	User initiated modification not allowed/required/applicable
0 0 1	User initiated modification up to 1 TCH/F allowed/may be requested
0 1 0	User initiated modification up to 2 TCH/F allowed/may be requested
0 1 1	User initiated modification up to 3 TCH/F allowed/may be requested
1 0 0	User initiated modification up to 4 TCH/F allowed/may be requested

All other values shall be interpreted as "User initiated modification up to 4 TCH/F may be requested".

User initiated modification indication is not applicable for transparent connection.

Wanted air interface user rate (octet 6f), MS to network direction:
Bits
4 3 2 1
0 0 0 0	Air interface user rate not applicable/No meaning associated with this value
0 0 0 1		9.6 kbit/s
0 0 1 0		14.4 kbit/s
0 0 1 1		19.2 kbit/s
0 1 0 1		28.8 kbit/s
0 1 1 0 	38.4 kbit/s
0 1 1 1		43.2 kbit/s
1 0 0 0		57.6 kbit/s
1 0 0 1		interpreted by the network as 38.4 kbit/s in this version of the protocol
1 0 1 0		interpreted by the network as 38.4 kbit/s in this version of the protocol
1 0 1 1		interpreted by the network as 38.4 kbit/s in this version of the protocol
1 1 0 0		interpreted by the network as 38.4 kbit/s in this version of the protocol

All other values are reserved.

Wanted air interface user rate (octet 6f), network to MS direction:
Bits 1 to 4 are spare and shall be set to "0".


Table 10.5.115/3GPP TS 24.008: Bearer capability information element

Layer 2 identity (octet 7)  
Bits 
7 6 
1 0	octet identifier 

All other values are reserved 

User information layer 2 protocol (octet 7)

Bits 
5 4 3 2 1 
0 0 1 1 0	reserved: was allocated in earlier phases of the protocol
0 1 0 0 0	according to ISO/IEC 6429 [42], codeset 0 (DC1/DC3)
0 1 0 0 1	reserved: was allocated but never used in earlier phases of the protocol
0 1 0 1 0	videotex profile 1
0 1 1 0 0	COPnoFlCt (Character oriented Protocol with no Flow Control
		mechanism)
0 1 1 0 1	reserved: was allocated in earlier phases of the protocol

All other values are reserved.

Table 10.5.115a/3GPP TS 24.008: Bearer capability information element
Acceptable Channel Codings extended (octet 6g) mobile station to network direction:


Bit
7
0 TCH/F28.8 not acceptable
1 TCH/F28.8 acceptable

Bit
6
0 TCH/F32.0 not acceptable
1 TCH/F32.0 acceptable

Bit
5
0 TCH/F43.2 not acceptable
1 TCH/F43.2 acceptable
Channel Coding Asymmetry Indication

Bits 
4 3
0 0		Channel coding symmetry preferred 
1 0		Downlink biased channel coding asymmetry is preferred
0 1		Uplink biased channel coding asymmetry is preferred
1 1      Unused, if received it shall be interpreted as "Channel coding symmetry preferred"


EDGE Channel Codings (octet 6g), network to MS direction:


Bits 3 to 7 are spare and shall be set to "0".

Bits 2 and 1 are spare.


10.5.4.5.1	Static conditions for the bearer capability IE contents
If the information transfer capability field (octet 3) indicates "speech", octets 4, 5, 5a, 5b, 6, 6a, 6b, 6c, 6d, 6e, 6f, 6g and 7 shall not be included.
If the information transfer capability field (octet 3) indicates "speech", octet 3a etc. shall be included only if the mobile station supports CTM text telephony or if it supports at least one speech version for GERAN other than:
‑	GSM full rate speech version 1; or
‑	GSM half rate speech version 1.
If the information transfer capability field (octet 3) indicates a value different from "speech", octets 4, 5, 6, 6a, 6b, and 6c shall be included, octets 6d, 6e, 6f and 6g are optional. In the network to MS direction in case octet 6d is included, octets 6e, 6f and 6g may be included. In the MS to network direction in case octet 6d is included octet 6e shall also be included and 6f and 6g may be included.
If the information transfer capability field (octet 3) indicates "facsimile group 3", the modem type field (octet 6c) shall indicate "none".
If the information transfer capability field (octet 3) indicates "other ITC" or the rate adaption field (octet 5) indicates "other rate adaption", octet 5a shall be included.
If the rate adaption field (octet 5) indicates "other rate adaption" and the other rate adaption field (octet 5a) indicates "V.120", octet 5b shall be included.
The modem type field (octet 6c) shall not indicate "autobauding type 1" unless the connection element field (octet 6c) indicates "non transparent".
10.5.4.5a	Call Control Capabilities
The purpose of the Call Control Capabilities information element is to identify the call control capabilities of the mobile station.
The Call Control Capabilities information element is coded as shown in figure 10.5.89/3GPP TS 24.008 and table 10.5.116/3GPP TS 24.008.
The Call Control Capabilities is a type 4 information element with a length of 4 octets.

8
7
6
5
4
3
2
1


Call Control Capabilities IEI
octet 1
Length of Call Control Capabilities contents
octet 2
Maximum number of supported bearers
MCAT
ENICM
PCP
DTMF
octet3
0
0
0
0
Maximum number of

spare
speech bearers
octet 4

Figure 10.5.89/3GPP TS 24.008 Call Control Capabilities information element
Table 10.5.116/3GPP TS 24.008: Call Control Capabilities 
DTMF (octet 3, bit 1)
0



This value is reserved for earlier versions of the protocol.
1



This value indicates that the mobile station supports DTMF as specified in subclause 5.5.7 of the present document.





PCP (octet 3, bit 2)
0



This value indicates that the mobile station does not support the Prolonged Clearing Procedure
1



This value indicates that the mobile station supports the Prolonged Clearing Procedure.





ENICM (octet 3, bit 3)
0



This value indicates that the mobile station does not support the Enhanced Network-initiated In-Call Modification procedure.
1



This value indicates that the mobile station supports the Enhanced Network-initiated In-Call Modification procedure as specified in subclause 5.3.4.3 of the present document.





MCAT (octet 3, bit 4)
0



This value indicates that the mobile station does not support Multimedia CAT.
1



This value indicates that the mobile station supports Multimedia CAT 
during the alerting phase of a mobile originated multimedia call establishment as specified in subclause 5.3.6.4 of the present document.





Maximum number of supported bearers (octet 3, bit 5 to bit 8)
0
0
0
0
1 bearer supported





All values are interpreted as the binary representation of the number of bearers supported.

Bit 5 of octet 3 is the least significant bit and bit 8 of octet 3 is the most significant bit.

Maximum number of speech bearers (octet 4, bit 1 to bit 4)

All values are interpreted as the binary representation of the number of bearers supported.

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

Note:	In this version of the protocol, the MS should not indicate more than one speech bearer.


10.5.4.6	Call state
The purpose of the call state information element is to describe the current status of a call, (see subclause 5.1).
The call state information element is coded as shown in figure 10.5.90/3GPP TS 24.008 and table 10.5.117/3GPP TS 24.008.
The call state is a type 3 information element with 2 octets length.

8
7
6
5
4
3
2
1


call state IEI
octet 1
coding
standard

call state value (coded in binary)

octet 2

Figure 10.5.90/3GPP TS 24.008 Call state information element
Table 10.5.117/3GPP TS 24.008: Call state information element
Coding standard (octet 2)
Bits
8
7



0
0


standardized coding as described in ITU-T Rec. Q.931
0
1


reserved for other international standards
1
0


national standard
1
1


standard defined for the GSM PLMNS as described below

Coding standards other than "1 1 - Standard defined for the GSM PLMNS" shall not be used if the call state can be represented with the GSM standardized coding.





The mobile station or network need not support any other coding standard than
"1 1 - Standard defined for the GSM PLMNS".
If a call state IE indicating a coding standard not supported by the receiver is received, call state "active" shall be assumed.

Call state value (octet 2)
Bits
6
5
4
3
2
1


0
0
0
0
0
0
UO - null
NO - null
0
0
0
0
1
0
U0.1- MM connection pending
N0.1- MM connection pending
1
0
0
0
1
0
U0.2- CC prompt present
N0.2- CC connection pending
1
0
0
0
1
1
U0.3- Wait for network information
N0.3- Network answer pending
1
0
0
1
0
0
U0.4- CC-Establishment present
N0.4- CC-Establishment present
1
0
0
1
0
1
U0.5- CC-Establishment confirmed
N0.5- CC-Establishment confirmed
1
0
0
1
1
0
U0.6- Recall present
N0.6- Recall present
0
0
0
0
0
1
U1 - call initiated
N1 - call initiated
0
0
0
0
1
1
U3 - mobile originating call proceeding
N3 - mobile originating call proceeding
0
0
0
1
0
0
U4 - call delivered
N4 - call delivered
0
0
0
1
1
0
U6 - call present
N6 - call present
0
0
0
1
1
1
U7 - call received
N7 - call received
0
0
1
0
0
0
U8 - connect request
N8 - connect request
0
0
1
0
0
1
U9 - mobile terminating call confirmed
N9 - mobile terminating call confirmed
0
0
1
0
1
0
U10- active
N10- active
0
0
1
0
1
1
U11- disconnect request

0
0
1
1
0
0
U12- disconnect indication
N12-disconnect indication
0
1
0
0
1
1
U19- release request
N19- release request
0
1
1
0
1
0
U26- mobile originating modify
N26- mobile originating modify
0
1
1
0
1
1
U27- mobile terminating modify
N27- mobile terminating modify
0
1
1
1
0
0

N28- connect indication


10.5.4.7	Called party BCD number
The purpose of the called party BCD number information element is to identify the called party.
The called party BCD number information element is coded as shown in figure 10.5.91/3GPP TS 24.008 and table 10.5.118/3GPP TS 24.008.
The called party BCD number is a type 4 information element with a minimum length of 3 octets and a maximum length of 43 octets. For PCS 1900 the maximum length is 19 octets.

8
7
6
5
4
3
2
1


Called party BCD number IEI
octet 1

Length of called party BCD number contents

octet 2
1
ext
type of
number
Numbering plan
identification

octet 3

Number digit 2

Number digit 1

octet 4*

Number digit 4

Number digit 3

octet 5*


	:

2)






	:

Figure 10.5.91/3GPP TS 24.008 Called party BCD number information element
NOTE 1:	The number digit(s) in octet 4 precedes the digit(s) in octet 5 etc. The number digit which would be entered first is located in octet 4, bits 1 to 4.
NOTE 2:	If the called party BCD number contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end mark coded as "1111".
Since the information element must contain the complete called party BCD number there is no need for an additional complete indication.
Table 10.5.118/3GPP TS 24.008: Called party BCD number
Type of number (octet 3) (Note 1)

Bits
7
6
5


0
0
0

unknown (Note 2)
0
0
1

international number (Note 3, Note 5)
0
1
0

national number (Note 3)
0
1
1

network specific number (Note 4)
1
0
0

dedicated access, short code
1
0
1

reserved
1
1
0

reserved
1
1
1

reserved for extension


NOTE 1:	For the definition of "number" see ITU-T Recommendation I.330 [48] and 3GPP TS 23.003 [10].
NOTE 2:	The type of number "unknown" is used when the user or the network has no knowledge of the type of number, e.g. international number, national number, etc. In this case the number digits field is organized according to the network dialling plan, e.g. prefix or escape digits might be present.
NOTE 3:	Prefix or escape digits shall not be included.
NOTE 4:	The type of number "network specific number" is used to indicate administration/service number specific to the serving network, e.g. used to access an operator.
NOTE 5:	The international format shall be accepted by the MSC when the call is destined to a destination in the same country as the MSC.
Table 10.5.118/3GPP TS 24.008: Called party BCD number (continued)
Numbering plan identification (octet 3)

Number plan (applies for type of number = 000, 001, 010 and 100)
Bits
4
3
2
1

0
0
0
0
unknown
0
0
0
1
ISDN/telephony numbering plan (ITU-T Rec. E.164 [45] / ITU-T Rec. E.163 [44])
0
0
1
1
data numbering plan (ITU-T Rec. X.121 [69])
0
1
0
0
telex numbering plan (ITU-T Rec. F.69 [47])
1
0
0
0
national numbering plan
1
0
0
1
private numbering plan
1
0
1
1
reserved for CTS (see 3GPP TS 44.056 [91])
1
1
1
1
reserved for extension

All other values are reserved.

-	When an MS is the recipient of number information from the network, any incompatibility between the number digits and the number plan identification shall be ignored and a STATUS message shall not be sent to the network.
-	In the case of numbering plan "unknown", the number digits field is organized according to the network dialling plan; e.g. prefix or escape digits might be present.
Table 10.5.118/3GPP TS 24.008: Called party BCD number (continued)
Number digits (octets 4, etc.)
Bits

Number digit value
4
3
2
1
or

8
7
6
5


0
0
0
0

0
0
0
0
1

1
0
0
1
0

2
0
0
1
1

3
0
1
0
0

4
0
1
0
1

5
0
1
1
0

6
0
1
1
1

7
1
0
0
0

8
1
0
0
1

9






1
0
1
0

*
1
0
1
1

#
1
1
0
0

a
1
1
0
1

b
1
1
1
0

c
1
1
1
1

used as an endmark in the case of an odd number of number digits


10.5.4.8	Called party subaddress
The purpose of the Called party subaddress is to identify the subaddress of the called party of a call. For the definition of a subaddress see ITU-T Rec. I.330 [48].
The Called party subaddress information element is coded as shown in figure 10.5.92/3GPP TS 24.008 and Table 10.5.119/3GPP TS 24.008.
The called party subaddress is a type 4 information element with a minimum length of 2 octets and a maximum length of 23 octets.

8
7
6
5
4
3
2
1


Called party Subaddress IEI
octet 1

Length of called party subaddress contents

octet 2
1
type of
odd/ev
0
0
0

ext
subaddress
Indica
spare
octet 3*


Subaddress information
octet 4*
:

:
etc.

Figure 10.5.92/3GPP TS 24.008 Called party subaddress
Table 10.5.119/3GPP TS 24.008: Called party subaddress
Type of subaddress (octet 3)

Bits
7
6
5


0
0
0

NSAP (see ITU-T Rec. X.213 [144]/ISO 8348 AD2)
0
1
0

User specified
All other values are reserved

Odd/even indicator (octet 3)
Bit
4




0



even number of address signals
1



odd number of address signals

NOTE 1:	The odd/even indicator is used when the type of subaddress is "user specified" and the coding is BCD.

Subaddress information (octet 4, etc...)
The NSAP X.213/ISO8348AD2 address shall be formatted as specified by octet 4 which contains the Authority and Format Identifier (AFI). The encoding is made according to the "preferred binary encoding" as defined in X.213 [144]/ISO8348AD2. For the definition of this type of subaddress, see ITU-T Rec. I.334 [145].

A coding example is given in ANNEX A.

For User-specific subaddress, this field is encoded according to the user specification, subject to a maximum length of 20 octets.

NOTE 2:	It is recommended that users apply NSAP subaddress type since this subaddress type allows the use of decimal, binary and IA5 characters in a standardised manner.

10.5.4.9	Calling party BCD number
The purpose of the calling party BCD number information element is to identify the origin of a call.
The calling party BCD number information element is coded as shown in figure 10.5.93/3GPP TS 24.008 and table 10.5.120/3GPP TS 24.008.
The calling party BCD number is a type 4 information element. In the network to mobile station direction it has a minimum length of 3 octets and a maximum length of 14 octets. (This information element is not used in the mobile station to network direction.).

8
7
6
5
4
3
2
1


Calling party BCD number IEI
octet 1

Length of calling party BCD number contents

octet 2
0/1
ext
type of
number
Numbering plan
identification

octet 3
1
presentat.
0
0
0
screening

ext
indicator
spare
indicator
octet 3a*

Number digit 2

Number digit 1

octet 4*

Number digit 4

Number digit 3

octet 5*


	:


	:

Figure 10.5.93/3GPP TS 24.008 Calling party BCD number information element
The contents of octets 3, 4, etc. are coded as shown in table 10.5.118. The coding of octet 3a is defined in table 10.5.120 below.
If the calling party BCD number contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end mark coded as "1111".
Table 10.5.120/3GPP TS 24.008: Calling party BCD number
Presentation indicator (octet 3a)
Bits
7
6



0
0


Presentation allowed
0
1


Presentation restricted
1
0


Number not available due to interworking
1
1


Reserved

If octet 3a is omitted the value "00 - Presentation allowed" is assumed.

Screening indicator (octet 3a)

Bits
2
1



0
0


User-provided, not screened
0
1


User-provided, verified and passed
1
0


User-provided, verified and failed
1
1


Network provided

If octet 3a is omitted the value "0 0 - User provided, not screened" is assumed.


10.5.4.10	Calling party subaddress
The purpose of the Calling party subaddress is to identify a subaddress associated with the origin of a call. For the definition of a subaddress see ITU-T Rec. I.330 [48].
The Calling party subaddress information element is coded as shown in figure 10.5.94/3GPP TS 24.008 and table 10.5.121/3GPP TS 24.008.
The calling party subaddress is a type 4 information element with a minimum length of 2 octets and a maximum length of 23 octets.

8
7
6
5
4
3
2
1


Calling party Subaddress IEI
octet 1

Length of calling party subaddress contents

octet 2
1
type of
odd/ev
0
0
0

ext
subaddress
Indica

octet 3*


Subaddress information
octet 4*
:
:

etc.

Figure 10.5.94/3GPP TS 24.008 Calling party subaddress
Table 10.5.121/3GPP TS 24.008: Calling party subaddress
Type of subaddress (octet 3)

Bits
7
6
5


0
0
0

NSAP (see ITU-T Rec. X.213 [144]/ISO 8348 AD2)
0
1
0

User specified
All other values are reserved

Odd/even indicator (octet 3)
Bit
4




0



even number of address signals
1



odd number of address signals

The odd/even indicator is used when the type of subaddress is "user specified" and the coding is BCD

Subaddress information (octet 4, etc...)
The NSAP X.213/ISO8348AD2 address shall be formatted as specified by octet 4 which contains the Authority and Format Identifier (AFI). The encoding is made according to the "preferred binary encoding" as defined in ITU-T Rec.  X.213 [144]/ISO8348AD2. For the definition of this type of this type of subaddress, see ITU-T Rec. I.334 [145].

A coding example is given in annex A.

For User-specific subaddress, this field is encoded according to the user specification, subject to a maximum length of 20 octets.

NOTE:	It is recommended that users apply NSAP subad dress type since this subaddress type allows the use of decimal, binary and IA5 characters in a standardised manner.

10.5.4.11	Cause
The purpose of the cause information element is to describe the reason for generating certain messages, to provide diagnostic information in the event of procedural errors and to indicate the location of the cause originator.
The cause information element is coded as shown in figure 10.5.95/3GPP TS 24.008 and tables 10.5.122 and 10.5.123/3GPP TS 24.008.
The cause is a type 4 information element with a minimum length of 4 octets and a maximum length of 32 octets.
The cause information element may be repeated in a message.

8
7
6
5
4
3
2
1


Cause IEI
octet 1

Length of cause contents

octet 2
0/1
ext
coding
standard
0
spare

location

octet 3
1
ext

recommendation

octet 3a*
1
ext

cause value

octet 4


diagnostic(s) if any
octet 5*



octet N*

Figure 10.5.95/3GPP TS 24.008 Cause information element
If the default value applies for the recommendation field, octet 3a shall be omitted.
Table 10.5.122/3GPP TS 24.008: Cause information element
Coding standard (octet 3)
Bits
7
6



0
0


Coding as specified in ITU-T Rec. Q.931
0
1


Reserved for other international standards
1
0


National standard
1
1


Standard defined for the GSM PLMNs as described below and in table 10.5.123/3GPP TS 24.008

Coding standards other than "1 1 - Standard defined for the GSM PLMNS" shall not be used if the cause can be represented with the GSM standardized coding.

The mobile station or network need not support any other coding standard than "1 1 - Standard defined for the GSM PLMNS".
If a cause IE indicating a coding standard not supported by the receiver is received, cause "interworking, unspecified" shall be assumed.

Location (octet 3)
Bits
4
3
2
1

0
0
0
0
user
0
0
0
1
private network serving the local user
0
0
1
0
public network serving the local user
0
0
1
1
transit network
0
1
0
0
public network serving the remote user
0
1
0
1
private network serving the remote user
0
1
1
1
international network
1
0
1
0
network beyond interworking point

All other values are reserved.

Recommendation (octet 3a)
Octet 3a shall not be included if the coding standard is coded as "1 1 - Standard defined for GSM PLMNS".

If the coding standard is different from "1 1 - Standard defined for GSM PLMNS", the coding of octet 3a, if included, and octets 4 to N is according to that coding standard.

Table 10.5.122/3GPP TS 24.008: Cause information element (continued)
Cause value (octet 4)

The cause value is divided in two fields: a class (bits 5 through 7) and a value within the class (bits 1 through 4).

The class indicates the general nature of the event.

Class (000):
normal event
Class (001):
normal event
Class (010):
resource unavailable
Class (011):
service or option not available
Class (100):
service or option not implemented
Class (101):
invalid message (e.g. parameter out of range)
Class (110):
protocol error (e.g. unknown message)
Class (111):
interworking

The cause values are listed in Table 10.5.123/3GPP TS 24.008 below and defined in Annex H.

Diagnostic(s) (octet 5)
Diagnostic information is not available for every cause, see Table 10.5.123/3GPP TS 24.008 below.

When available, the diagnostic(s) is coded in the same way as the corresponding information element in clause 10.

The inclusion of diagnostic(s) is optional.

Table 10.5.123/3GPP TS 24.008: Cause information element values
Cause value
Cause
Cause
Diag-
Remarks
Class
Value
num.

nostic

7
6
5
4
3
2
1















0
0
0
0
0
0
1
1.
Unassigned (unallocated) number
Note 9

0
0
0
0
0
1
1
3.
No route to destination
Note 9

0
0
0
0
1
1
0
6.
Channel unacceptable
-

0
0
0
1
0
0
0
8.
Operator determined barring
-

0
0
1
0
0
0
0
16.
Normal call clearing
Note 9

0
0
1
0
0
0
1
17.
User busy
Note 1

0
0
1
0
0
1
0
18.
No user responding
-

0
0
1
0
0
1
1
19.
User alerting, no answer
-

0
0
1
0
1
0
1
21.
Call rejected
Note 9 - user supplied diagnostic (note 4)
0
0
1
0
1
1
0
22.
Number changed
New destination(note 5)
0
0
1
1
0
0
0
24.
Call rejected due to feature at the destination
-

0
0
1
1
0
0
1
25.
Pre-emption


0
0
1
1
0
1
0
26.
Non selected user clearing
-

0
0
1
1
0
1
1
27.
Destination out of order
-

0
0
1
1
1
0
0
28.
Invalid number format (incomplete number)
-

0
0
1
1
1
0
1
29.
Facility rejected
Note 1

0
0
1
1
1
1
0
30.
Response to STATUS ENQUIRY
-

0
0
1
1
1
1
1
31.
Normal, unspecified
-

0
1
0
0
0
1
0
34.
No circuit/channel available
Note 1

0
1
0
0
1
1
0
38.
Network out of order
-

0
1
0
1
0
0
1
41.
Temporary failure
-

0
1
0
1
0
1
0
42.
Switching equipment congestion
-

0
1
0
1
0
1
1
43.
Access information discarded
Discarded information element identifiers (note 6)
0
1
0
1
1
0
0
44.
requested circuit/channel not available
-

0
1
0
1
1
1
1
47.
Resources unavailable, unspecified
-

0
1
1
0
0
0
1
49.
Quality of service unavailable
Note 9

0
1
1
0
0
1
0
50.
Requested facility not subscribed
Note 1

0
1
1
0
1
1
1
55.
Incoming calls barred within the CUG
Note 1

0
1
1
1
0
0
1
57.
Bearer capability not authorized
Note 3

0
1
1
1
0
1
0
58.
Bearer capability not presently available
Note 3

0
1
1
1
1
1
1
63.
Service or option not available, unspecified
-

1
0
0
0
0
0
1
65.
Bearer service not implemented
Note 3


(continued)

Table 10.5.123/3GPP TS 24.008 (concluded): Cause information element values
Cause value
Cause
Cause
Diag-
Remarks
Class
Value
num.

nostic

7
6
5
4
3
2
1















1
0
0
0
1
0
0
68.
ACM equal to or greater than ACMmax


1
0
0
0
1
0
1
69.
Requested facility not implemented
Note 1

1
0
0
0
1
1
0
70.
Only restricted digital information bearer capability is available


1
0
0
1
1
1
1
79.
Service or option not implemented, unspecified
-

1
0
1
0
0
0
1
81.
Invalid transaction identifier value
-

1
0
1
0
1
1
1
87.
User not member of CUG
Note 1

1
0
1
1
0
0
0
88.
Incompatible destination
Incompatible parameter (Note 2)
1
0
1
1
0
1
1
91.
Invalid transit network selection
-

1
0
1
1
1
1
1
95.
Semantically incorrect message
-

1
1
0
0
0
0
0
96.
Invalid mandatory information
Information element identifier(s)
1
1
0
0
0
0
1
97.
Message type non-existent or not implemented
Message type
1
1
0
0
0
1
0
98.
Message type not compatible with protocol state
Message type
1
1
0
0
0
1
1
99.
Information element non-existent or not implemented
Information element identifier(s) (notes 6,7)
1
1
0
0
1
0
0
100.
Conditional IE error
Information element identifier(s) (note 6)
1
1
0
0
1
0
1
101.
Message not compatible with protocol state
Message type
1
1
0
0
1
1
0
102.
Recovery on timer expiry
Timer number (note 8)
1
1
0
1
1
1
1
111.
Protocol error, unspecified
-

1
1
1
1
1
1
1
127.
Interworking, unspecified
-


All other values in the range 0 to 31 shall be treated as cause 31.
All other values in the range 32 to 47 shall be treated as cause 47.
All other values in the range 48 to 63 shall be treated as cause 63.
All other values in the range 64 to 79 shall be treated as cause 79.
All other values in the range 80 to 95 shall be treated as cause 95.
All other values in the range 96 to 111 shall be treated as cause 111.
All other values in the range 112 to 127 shall be treated as cause 127.
NOTE 1:	Diagnostics for supplementary services are handled as follows:
octet 5, bit 8:
	This is an extension bit as defined in the preliminary part of subclause 10.5. In this version of this protocol, this bit shall be set to 1. If it is set to zero, the contents of the following octets shall be ignored.
octet 5, bit 7-1:
	0000001 - Outgoing calls barred within CUG
	0000010 - No CUG selected
	0000011 - Unknown CUG index
	0000100 - CUG index incompatible with requested basic service
	0000101 - CUG call failure, unspecified
	0000110 - CLIR not subscribed
	0000111 - CCBS possible
	0001000 - CCBS not possible
	All other values shall be ignored.
NOTE 2:	The incompatible parameter is composed of the incompatible information element identifier.
NOTE 3:	The format of the diagnostic field for cause numbers 57, 58 and 65 is as shown in figure 10.5.88/3GPP TS 24.008 and tables 10.5.102/3GPP TS 24.008 to 10.5.115/3GPP TS 24.008.
NOTE 4:	The user supplied diagnostics field is encoded according to the user specification, subject to the maximum length of the cause information element. The coding of user supplied diagnostics should be made in such a way that it does not conflict with the coding described in note 9 below.
NOTE 5:	The new destination is formatted as the called party BCD number information element, including information element identifier.
NOTE 6:	Locking and non-locking shift procedures described in subclause 10.5.4.2 and clause 3 are applied. In principle, information element identifiers are ordered in the same order as the information elements in the received message.
NOTE 7:	When only the locking shift information element is included and no information element identifier follows, it means that the codeset in the locking shift itself is not implemented.
NOTE 8:	The timer number is coded in IA5 characters, e.g., T308 is coded as "3" "0" "8". The following coding is used in each octet:
	bit 8: spare "0"
	bits 7-1: IA5 character
	Octet 5 carries "3", octet 5a carries "0", etc.
NOTE 9:	The following coding is used for octet 5:
	bit 8     : 1
	bits 7-3: 00000
	bits 2-1: condition as follows:
	00 - unknown
	01 - permanent
	10 - transient
10.5.4.11a	CLIR suppression
The CLIR suppression information element may be sent by the mobile station to the network in the SETUP message. The use is defined in 3GPP TS 24.081 [25].
The CLIR suppression information element is coded as shown in figure 10.5.96/3GPP TS 24.008.
The CLIR suppression is a type 2 information element.

8
7
6
5
4
3
2
1


CLIR suppression IEI
octet 1

Figure 10.5.96/3GPP TS 24.008 CLIR suppression information element
10.5.4.11b	CLIR invocation
The CLIR invocation information element may be sent by the mobile station to the network in the SETUP message. The use is defined in 3GPP TS 24.081 [25].
The CLIR invocation information element is coded as shown in figure 10.5.97/3GPP TS 24.008.
The CLIR invocation is a type 2 information element.

8
7
6
5
4
3
2
1


CLIR invocation IEI
octet 1

Figure 10.5.97/3GPP TS 24.008 CLIR invocation information element
10.5.4.12	Congestion level
The purpose of the congestion level information element is to describe the congestion status of the call.
The congestion level information element is coded as shown in figure 10.5.98/3GPP TS 24.008 and table 10.5.124/3GPP TS 24.008.
The congestion level is a type 1 information element.

8
7
6
5
4
3
2
1


Congestion level
IEI
Congestion level
octet 1

Figure 10.5.98/3GPP TS 24.008 Congestion level information element
Table 10.5.124/3GPP TS 24.008: Congestion level information element
Congestion level (octet 1)
Bits
4
3
2
1

0
0
0
0
receiver ready
1
1
1
1
receiver not ready

All other values are reserved.

10.5.4.13	Connected number
The purpose of the connected number information element is to identify the connected party of a call.
The connected number information element is coded as shown in figure 10.5.99/3GPP TS 24.008.
The connected number is a type 4 information element with a minimum length of 3 octets and a maximum length of 14 octets.

8
7
6
5
4
3
2
1


Connected number IEI
octet 1
Length of connected number contents
octet 2
0/1
ext
Type of number

Number plan
identification
octet 3
	note 1)
1
Presentation
0
0
0
Screening
octet 3a*
ext
indicator
Spare
indicator
	note 1)
Number digit 2
Number digit 1
octet 4*
	note 1)
Number digit 4
Number digit 3
octet 5*
	note 1)
note 2)

	:
	:

Figure 10.5.99/3GPP TS 24.008
NOTE 1:	The contents of octets 3,4,5, etc. ... are coded as shown in table 10.5.118/3GPP TS 24.008. The coding of octet 3a is defined in table 10.5.120/3GPP TS 24.008.
NOTE 2:	If the connected number contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with the end mark coded as "1111".
10.5.4.14	Connected subaddress
The purpose of the connected subaddress information element is to identify a subaddress associated with the connected party of a call.
The connected subaddress information element is coded as shown in figure 10.5.100/3GPP TS 24.008.
The connected subaddress is a type 4 information element with a minimum length of 2 octets and a maximum length of 23 octets.

8
7
6
5
4
3
2
1


Connected subaddress IEI
octet 1
Length of connected subaddress contents
octet 2

	Type of	odd/even
0
0
0
octet 3*

	subaddress	indicator
Spare

Subaddress information
octet 4*
:

:
etc.

Figure 10.5.100/3GPP TS 24.008
The coding for Type of subaddress, odd/even indicator, and subaddress information is in table 10.5.119/3GPP TS 24.008.
10.5.4.15	Facility
The purpose of the facility information element is to transport supplementary service related information. Within the scope of 3GPP TS 24.008 the content of the Facility information field is an array of octets. The usage of this transportation mechanism is defined in 3GPP TS 24.080 [24].
The facility information element is coded as shown in figure 10.5.101/3GPP TS 24.008.
The facility is a type 4 information element with a minimum length of 2 octets. No upper length limit is specified except for that given by the maximum number of octets in a L3 message (see 3GPP TS 44.006 [19]).

8
7
6
5
4
3
2
1


Facility IEI
octet 1
Length of facility contents
octet 2
Facility information (see 3GPP TS 24.080 [24])
octet 3-?*

Figure 10.5.101/3GPP TS 24.008
10.5.4.16	High layer compatibility
The purpose of the high layer compatibility information element is to provide a means which should be used by the remote user for compatibility checking. See annex B.
The high layer compatibility information element is coded as shown in figure 10.5.102/3GPP TS 24.008 and table 10.5.125/3GPP TS 24.008.
The high layer compatibility is a type 4 information element with a minimum length of 2 octets and a maximum length of 5 octets.
NOTE:	The high layer compatibility information element is transported transparently by a PLMN between a call originating entity (e.g. a calling user) and the addressed entity (e.g. a remote user or a high layer function network node addressed by the call originating entity). However, if explicitly requested by the user (at subscription time), a network which provides some capabilities to realize teleservices may interpret this information to provide a particular service.

8
7
6
5
4
3
2
1


High layer compatibility IEI
octet 1

Length of high layer compatibility contents

octet 2
1
ext
coding
standard

interpretation
presentat.
method of
protocol
profile

octet 3*
0/1
ext

High layer characteristics identification
octet 4*

1
ext
Extended high layer characteristics
identification
octet 4a*
	(note)

Figure 10.5.102/3GPP TS 24.008 High layer compatibility information element
If the value part of the IE is empty, the IE indicates "not applicable".
NOTE:	Octet 4a may be present e.g. when octet 4 indicates Maintenance or Management, or audio visual.
Table 10.5.125/3GPP TS 24.008: High layer compatibility information element
Coding standard (octet 3)
see ITU Recommendation Q.931.

Interpretation (octet 3)
see ITU Recommendation Q.931.

Presentation method of protocol profile (octet 3)
see ITU Recommendation Q.931.

High layer characteristics identification (octet 4)
see ITU Recommendation Q.931.
Extended high layer characteristics identification (octet 4a)
see ITU Recommendation Q.931.

10.5.4.16.1	Static conditions for the high layer compatibility IE contents
Either the value part of the IE is empty, or it contains at least octet 3 and 4.
10.5.4.17	Keypad facility
The purpose of the keypad facility information element is to convey IA5 characters, e.g. entered by means of a terminal keypad (see note).
The keypad facility information element is coded as shown in figure 10.5.103/3GPP TS 24.008.
The keypad facility is a type 3 information element with 2 octets length.

8
7
6
5
4
3
2
1


Keypad facility IEI
octet 1
Spare
0

Keypad information (IA5 character)

octet 2

Figure 10.5.103/3GPP TS 24.008 Keypad facility information element
NOTE:	In the 3GPP system this information element is only used to transfer one DTMF digit (0, 1, ... , 9, A, B, C, D, *, #) as one IA5 character.
10.5.4.18	Low layer compatibility
The purpose of the low layer compatibility information element is to provide a means which should be used for compatibility checking by an addressed entity (e.g., a remote user or an interworking unit or a high layer function network node addressed by the calling user). The low layer compatibility information element is transferred transparently by a PLMN between the call originating entity (e.g. the calling user) and the addressed entity.
Except for the information element identifier, the low layer compatibility information element is coded as in ITU recommendation Q.931.
For backward compatibility reasons coding of the modem type field according to ETS 300 102-1 (12-90) shall also be supported.
The low layer compatibility is a type 4 information element with a minimum length of 2 octets and a maximum length of 18 octets.

8
7
6
5
4
3
2
1


Low layer compatibility IEI
octet 1
Length of the low layer compatibility contents
octet 2

The following octets are coded
as described in
ITU Recommendation Q.931
(Coding of the modem type according to both Q.931 and 
ETS 300 102-1 (12-90) shall be accepted)

octet 3*

	:
	:
	:

Figure 10.5.104/3GPP TS 24.008 Low layer compatibility information element
If the value part of the IE is empty, the IE indicates "not applicable".
10.5.4.19	More data
The more data information element is sent by the mobile station to the network or to the network to the mobile station in a USER INFORMATION message. The presence of the more data information element indicates to the destination remote user/mobile station that another USER INFORMATION message will follow containing information belonging to the same block.
The use of the more data information element is not supervised by the network.
The more data information element is coded as shown in figure 10.5.105/3GPP TS 24.008.
The more data is a type 2 information element.

8
7
6
5
4
3
2
1


More data IEI
octet 1

Figure 10.5.105/3GPP TS 24.008 More data information element
10.5.4.20	Notification indicator
The purpose of the notification indicator information element is to indicate information pertaining to a call.
The notification indicator element is coded as shown in figure 10.5.106/3GPP TS 24.008 and table 10.5.126/ 3GPP TS 24.008.
The notification indicator is a type 3 information element with 2 octets length.

8
7
6
5
4
3
2
1


Notification indicator IEI
octet 1
1
ext

Notification description
octet 2

Figure 10.5.106/3GPP TS 24.008 Notification indicator information element
Table 10.5.126/3GPP TS 24.008: Notification indicator information element
Notification description (octet 2)
Bits


7
6
5
4
3
2
1



0
0
0
0
0
0
0


User suspended
0
0
0
0
0
0
1


User resumed
0
0
0
0
0
1
0


Bearer change










All other values are reserved.

10.5.4.21	Progress indicator
The purpose of the progress indicator information element is to describe an event which has occurred during the life of a call.
The progress indicator information element is coded as shown in figure 10.5.107/3GPP TS 24.008 and table 10.5.127/3GPP TS 24.008.
The progress indicator is a type 4 information element with a length of 4 octets.

8
7
6
5
4
3
2
1


Progress indicator IEI
octet 1

Length of progress indicator contents

octet 2
1
ext
coding
standard
0
spare

location

octet 3
1
ext

progress description
octet 4

Figure 10.5.107/3GPP TS 24.008 Progress indicator information element
Table 10.5.127/3GPP TS 24.008: Progress indicator information element
Coding standard (octet 3)
Bits
7
6



0
0


Standardized coding, as described in ITU-T Rec. Q.931
0
1


Reserved for other international standards
1
0


National standard
1
1


Standard defined for the GSMßPLMNS as described below

Coding standards other than "1 1 - Standard defined for the GSM PLMNS" shall not be used if the progress description can be represented with the GSMßstandardized coding.

The mobile station or network need not support any other coding standard than "1 1 - Standard defined for the GSM PLMNS".
If a progress indicator IE indicating a coding standard not supported by the receiver is received, progress description "Unspecific" shall be assumed.

Location (octet 3)
Bits
4
3
2
1

0
0
0
0
User
0
0
0
1
Private network serving the local user
0
0
1
0
Public network serving the local user
0
1
0
0
Public network serving the remote user
0
1
0
1
Private network serving the remote user
1
0
1
0
Network beyond interworking point

All other values are reserved.

Note:	Depending on the location of the users, the local public network and remote public network may be the same network.

Progress description (octet 4)
Bits
7
6
5
4
3
2
1

No.

0
0
0
0
0
0
1

1.
Call is not end-to-end PLMN/ISDN, further call progress information may be available in-band
0
0
0
0
0
1
0

2.
Destination address in non-PLMN/ISDN
0
0
0
0
0
1
1

3.
Origination address in non-PLMN/ISDN
0
0
0
0
1
0
0

4.
Call has returned to the PLMN/ISDN
0
0
0
1
0
0
0

8.
In-band information or appropriate pattern now available
0
0
0
1
0
0
1

9.
In-band multimedia CAT available
0
1
0
0
0
0
0

32.
Call is end-to-end PLMN/ISDN
1
0
0
0
0
0
0

64.
Queueing
All other values

Unspecific

10.5.4.21a	Recall type $(CCBS)$
The purpose of the recall type information element is to describe the reason for the recall.
The recall type information element is coded as shown in Figure 10.5.108/3GPP TS 24.008 and Table 10.5.128/3GPP TS 24.008.
The recall type is a type 3 information element with 2 octets length.

8
7
6
5
4
3
2
1


recall type IEI
octet 1
spare
recall type

0
0
0
0
0

octet 2

Figure 10.5.108/3GPP TS 24.008 Recall type information element
Table 10.5.128/3GPP TS 24.008: Recall type information element
recall type (octet 2, bits 1 to 4)
Bits
3
2
1


0
0
0

- CCBS
0
0
1

}
to
 } - shall be treated as CCBS (intended for other similar types of Recall)
1
1
0

}
1
1
1

- reserved

10.5.4.21b	Redirecting party BCD number
The purpose of the redirecting party BCD number information element is to identify the redirecting party.
The redirecting party BCD number information element is coded as shown in figure 10.5.108a/3GPP TS 24.008.
The redirecting party BCD number is a type 4 information element. In the network to mobile station direction it has a minimum length of 3 octets and a maximum length of 19 octets.

8
7
6
5
4
3
2
1


Redirecting party BCD number IEI
octet 1

Length of redirecting party BCD number contents

octet 2
0/1
ext
type of
number
Numbering plan
identification
octet 3
(note 1)
1
presentat.
0
0
0
Screening
octet 3a*
ext
indicator
spare
indicator
(note 1)

Number digit 2

Number digit 1
octet 4*
(note 1)

Number digit 4

Number digit 3
octet 5*
(note 1)


	:



Note 2)

	:

Figure 10.5.108a/3GPP TS 24.008
Redirecting party BCD number information element
NOTE 1:	The contents of octets 3, 4, etc. are coded as shown in table 10.5.118/3GPP TS 24.008. The coding of octet 3a is defined in table 10.5.120/3GPP TS 24.008.
NOTE 2:	If the redirecting party BCD number contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end mark coded as "1111".
10.5.4.21c	Redirecting party subaddress
The purpose of the Redirecting party subaddress is to identify a subaddress associated with the redirecting party. For the definition of a subaddress see Rec. ITU-T I.330.
The Redirecting party subaddress information element is coded as shown in figure 10.5.108b/3GPP TS 24.008 and table 10.5.121/3GPP TS 24.008.
The Redirecting party subaddress is a type 4 information element with a minimum length of 2 octets and a maximum length of 23 octets.

8
7
6
5
4
3
2
1


Redirecting party Subaddress IEI
octet 1

Length of redirecting party subaddress contents

octet 2
1
ext
type of
subaddress
odd/ev
Indica
0
0
0

octet 3*

Subaddress information
:

octet 4*
:



etc.

Figure 10.5.108b/3GPP TS 24.008
Redirecting party subaddress information element
10.5.4.22	Repeat indicator
The purpose of the repeat indicator information element is to indicate how the associated repeated information elements shall be interpreted, when included in a message. The repeat indicator information element is included immediately before the first occurrence of the associated information element which will be repeated in a message. "Mode 1" refers to the first occurrence of that information element, "mode 2" refers to the second occurrence of that information element in the same message.
The repeat indicator information element is coded as shown in figure 10.5.109/3GPP TS 24.008 and table 10.5.129/3GPP TS 24.008.
The repeat indicator is a type 1 information element.

8
7
6
5
4
3
2
1


repeat indicator
IEI
repeat indication
octet 1

Figure 10.5.109/3GPP TS 24.008 Repeat indicator information element
Table 10.5.129/3GPP TS 24.008: Repeat indicator information element
Repeat indication (octet 1)
Bits
4
3
2
1

0
0
0
1
Circular for successive selection
"mode 1 alternate mode 2"
0
0
1
0
Support of fallback – mode 1 preferred, mode 2 selected if setup of mode 1 fails
0
0
1
1
reserved: was allocated in earlier phases of the protocol
0
1
0
0
Service change and fallback – mode 1 alternate mode 2, mode 1 preferred
All other values are reserved.


10.5.4.22a	Reverse call setup direction
This information element may be included in a MODIFY and MODIFY COMPLETE message to indicate that the direction of the data call to which the MODIFY message relates is opposite to the call setup direction.
The reverse call setup direction information element is coded as shown in figure 10.5.110/3GPP TS 24.008.
The reverse call setup direction is a type 2 information element

8
7
6
5
4
3
2
1

reverse call setup direction IEI
octet 1

Figure 10.5.110/3GPP TS 24.008 Reverse call setup direction information element
10.5.4.22b	SETUP Container $(CCBS)$
This information element contains the contents of a SETUP message (Mobile Station to Network). This means that the Call Control protocol discriminator IE, the Transaction Identifier IE and the Setup message type IE are not included.
The SETUP Container information element is coded as shown in figure 10.5.111/3GPP TS 24.008.
The SETUP Container is a type 4 information. No upper length limit is specified except for that given by the maximum number of octets in a L3 message (see 3GPP TS 44.006 [19]).

8
7
6
5
4
3
2
1


SETUP Container IEI
octet 1
Length of SETUP container contents
octet 2

SETUP message


octet 3-n

Figure 10.5.111/3GPP TS 24.008 Octet j (j = 3, 4 ... n) is the unchanged octet j of the SETUP message.
10.5.4.23	Signal
The purpose of the signal information element is to allow the network to convey information to a user regarding tones and alerting signals (see subclauses 5.2.2.3.2 and 7.3.3.).
The signal information element is coded as shown in figure 10.5.112/3GPP TS 24.008 and table 10.5.130/3GPP TS 24.008.
The signal is a type 3 information element with 2 octets length.

8
7
6
5
4
3
2
1


Signal IEI
octet 1

Signal value

octet 2

Figure 10.5.112/3GPP TS 24.008 Signal information element
Table 10.5.130/3GPP TS 24.008: Signal information element
Signal value (octet 2)
Bits
8
7
6
5
4
3
2
1


0
0
0
0
0
0
0
0

dial tone on
0
0
0
0
0
0
0
1

ring back tone on
0
0
0
0
0
0
1
0

intercept tone on
0
0
0
0
0
0
1
1

network congestion tone on
0
0
0
0
0
1
0
0

busy tone on
0
0
0
0
0
1
0
1

confirm tone on
0
0
0
0
0
1
1
0

answer tone on
0
0
0
0
0
1
1
1

call waiting tone on
0
0
0
0
1
0
0
0

off-hook warning tone on
0
0
1
1
1
1
1
1

tones off
0
1
0
0
1
1
1
1

alerting off










All other values are reserved.

10.5.4.24	SS Version Indicator
The purpose of the SS version indicator information element is to aid the decoding of the Facility information element as described in 3GPP TS 24.010 [21]. Within the scope of 3GPP TS 24.008 the contents of the SS Version information field is an array of one or more octets. The usage of the SS version information field is defined in 3GPP TS 24.080 [24].
The SS version indicator information element is coded as shown in figure 10.5.113/3GPP TS 24.008.
The SS version indicator is a type 4 information element with a minimum length of 2 octets. No upper length limit is specified except for that given by the maximum number of octets in a L3 message (see 3GPP TS 44.006 [19]).

8
7
6
5
4
3
2
1


SS version indicator IEI
octet 1
Length of SS version indicator contents
octet 2
SS version information (see 3GPP TS 24.080 [24])




octet 3*

	:	*

	:	*

Figure 10.5.113/3GPP TS 24.008
NOTE:	Usually, this information element has only one octet of content.
10.5.4.25	User-user
The purpose of the user-user information element is to convey information between the mobile station and the remote ISDN user.
The user-user information element is coded as shown in figure 10.5.114/3GPP TS 24.008 and table 10.5.131/ 3GPP TS 24.008. There are no restrictions on the content of the user-user information field.
The user-user is a type 4 information element with a minimum length of 3 octets and a maximum length of either 35 or 131 octets. In the SETUP message the user-user information element has a maximum size of 35 octets in a GSM PLMN. In the USER INFORMATION, ALERTING, CONNECT, DISCONNECT, PROGRESS, RELEASE and RELEASE COMPLETE messages the user-user information element has a maximum size of 131 octets in a GSM PLMN.
In other networks than GSM PLMNs the maximum size of the user-user information element is 35 or 131 octets in the messages mentioned above. The evolution to a single maximum value is the long term objective; the exact maximum value is the subject of further study.
NOTE:	The user-user information element is transported transparently through a GSM PLMN.

8
7
6
5
4
3
2
1


User-user IEI
octet 1

Length of user-user contents

octet 2
User-user protocol discriminator

octet 3

User-user information
octet 4*





octet N*

Figure 10.5.114/3GPP TS 24.008 User-user information element

Table 10.5.131/3GPP TS 24.008: User-user information element
User-user protocol discriminator (octet 3)
Bits
8
7
6
5
4
3
2
1


0
0
0
0
0
0
0
0

User specific protocol (Note 1)
0
0
0
0
0
0
0
1

OSI high layer protocols
0
0
0
0
0
0
1
0

X.244 (Note 2)
0
0
0
0
0
0
1
1

Reserved for system management convergence function
0
0
0
0
0
1
0
0

IA5 characters (Note 3)
0
0
0
0
0
1
1
1

rate adaption according to ITU-T Rec. V.120 [61]
0
0
0
0
1
0
0
0

user-network call control messages according to ITU-T Rec. Q.931 [53]










0
0
0
1
0
0
0
0

Reserved for other network layer or
through

layer 3 protocols
0
0
1
1
1
1
1
1












0
1
0
0
0
0
0
0


through

National use
0
1
0
0
1
1
1
0


0
1
0
0
1
1
1
1

3GPP capability exchange protocol (NOTE 4)










0
1
0
1
0
0
0
0

Reserved for other network
through

layer or layer 3 protocols
1
1
1
1
1
1
1
0












All other values are reserved.

NOTE 1:	The user information is structured according to user needs.
NOTE 2:	The user information is structured according to ITU-T Rec. X.244 which specifies the structure of ITU-T Rec. X.25 [143] call user data.
NOTE 3:	The user information consists of IA5 characters.
NOTE 4:	When the user-user protocol discriminator is set to "3GPP capability exchange protocol", the user-user information is coded according to 3GPP TS 24.279 [116].

10.5.4.26	Alerting Pattern $(NIA)$
The purpose of the Alerting Pattern information element is to allow the network to convey information related to the alert to be used by the MS (see 3GPP TS 22.101 [8]).
The Alerting Pattern information element is coded as shown in figure 10.5.115/3GPP TS 24.008 and table 10.5.132/3GPP TS 24.008.
The Alerting Pattern IE is a type 4 information element with 3 octet length.

8
7
6
5
4
3
2
1


Alerting Pattern IEI
octet 1
length of alerting pattern content
octet 2
0
0
0
0
Alerting Pattern

spare
value
octet 3

Figure 10.5.115/3GPP TS 24.008 Alerting Pattern information element
Table 10.5.132/3GPP TS 24.008: Alerting Pattern information element
Alerting Pattern value (octet 3)
Bits
4
3
2
1


0
0
0
0
alerting pattern 1
0
0
0
1
alerting pattern 2
0
0
1
0
alerting pattern 3





0
1
0
0
alerting pattern 5
0
1
0
1
alerting pattern 6
0
1
1
0
alerting pattern 7
0
1
1
1
alerting pattern 8
1
0
0
0
alerting pattern 9





all other values are reserved

Alerting pattern 1, 2 and 3 indicate alerting levels 0, 1 and 2.
Alerting pattern 5 to 9 indicate alerting categories 1 to 5
10.5.4.27	Allowed actions $(CCBS)$
The purpose of the Allowed actions information element is to provide the mobile station with information about further allowed procedures.
The Allowed actions information element is coded as shown in figure 10.5.116/3GPP TS 24.008 and table 10.5.133/3GPP TS 24.008.
The Allowed actions is a type 4 information element with 3 octets length.

8
7
6
5
4
3
2
1


Allowed Actions IEI
octet 1

Length of allowed actions contents

octet 2
CCBS
0
0
0
0
0
0
0

act.
spare
octet 3

Figure 10.5.116/3GPP TS 24.008 Allowed actions information element
Table 10.5.133/3GPP TS 24.008: Allowed actions information element
CCBS activation (octet 3)

Bits
8




0



Activation of CCBS not possible
1



Activation of CCBS possible

10.5.4.28	Stream Identifier
The purpose of the stream identifier (SI) information element is to associate a particular call with a Radio Access Bearer (RAB), and to identify whether a new traffic channel shall be assigned within the interface controlled by these signalling procedures. The SI value indicated in the CC protocol shall be sent in the RAB setup message. And mobile station is informed the relationship between the call and the RAB.
The Stream identifier information element is coded as shown in figure 10.5.117/3GPP TS 24.008 and table 10.5.134/3GPP TS 24.008.
The Stream Identifier is a type 4 information element with 3 octets length.

8
7
6
5
4
3
2
1

Stream Identifier IEI
octet 1

Length of Stream Identifier contents

octet 2

Stream Identifier Value

octet 3

Figure 10.5.117/3GPP TS 24.008: Stream Identifier information element
Table 10.5.134/3GPP TS 24.008: Stream Identifier information element
Stream Identifier value(octet 3)

Bit
8
7
6
5
4
3
2
1


0
0
0
0
0
0
0
0

No bearer
0
0
0
0
0
0
0
1

1



:








:





1
1
1
1
1
1
1
1

255

10.5.4.29	Network Call Control Capabilities
The purpose of the Network Call Control Capabilities information element is to identify the call control capabilities of the network. The contents might affect the manner in which the mobile station handles the call. 
The Network Call Control Capabilities information element is coded as shown in figure 10.5.118/3GPP TS 24.008 and table 10.5.135/3GPP TS 24.008.
The Network Call Control Capabilities is a type 4 information element with a length of 3 octets.

8
7
6
5
4
3
2
1

Network Call Control Capabilities IEI
octet 1

Length of NW Call Control Cap. contents

octet 2
0
0
0
0
0
0
0


spare
MCS
octet 3

Figure 10.5.118/3GPP TS 24.008 Network Call Control Capabilities information element
Table 10.5.135/3GPP TS 24.008: Network Call Control Capabilities 
MCS (octet 3, bit 1)
0



This value indicates that the network does not support the multicall.
1



This value indicates that the network supports the multicall.

10.5.4.30	Cause of No CLI
Cause of No CLI information element provides the mobile station the detailed reason why Calling party BCD number is not notified (see 3GPP TS 24.081 [25]).
The Cause of No CLI information element is coded as shown in figure 10.5.118a/3GPP TS 24.008 and table 10.5.135a/3GPP TS 24.008.
The Cause of No CLI is a type 4 information element with the length of 3 octets.

8
7
6
5
4
3
2
1

Cause of No CLI IEI
octet 1
Length of Cause of No CLI contents
octet 2
Cause of No CLI
octet 3

Figure 10.5.118a/3GPP TS 24.008 Cause of No CLI information element
Table 10.5.135a/3GPP TS 24.008: Cause of No CLI information element
Cause of No CLI (octet 3)
Bits


8
7
6
5
4
3
2
1


0
0
0
0
0
0
0
0

Unavailable
0
0
0
0
0
0
0
1

Reject by user
0
0
0
0
0
0
1
0

Interaction with other service
0
0
0
0
0
0
1
1

Coin line/payphone
Other values shall be interpreted as "Unavailable".

10.5.4.31	Void
10.5.4.32	Supported codec list
The purpose of the Supported Codec List information element is to provide the network with information about the speech codecs supported by the mobile.
The Supported Codec List information element is coded as shown in figure 10.5.118c/3GPP TS 24.008.
The Supported Codec List information element is a type 4 information element with a minimum length of 5 octets and a maximum length of m+3 octets.
Speech codec information belonging to GERAN and UTRAN shall be conveyed by this information element.

8
7
6
5
4
3
2
1

Supported Codec List IEI
octet 1
Length Of Supported Codec list

octet 2
 System Identification 1 (SysID 1)

octet 3

Length Of Bitmap for SysID 1

octet 4
Codec Bitmap for SysID 1, bits 1 to 8
octet 5
Codec Bitmap for SysID 1, bits 9 to 16
octet 6
System Identification 2 (SysID 2)

octet j

Length Of Bitmap for (SysID 2)

octet j+1
Codec Bitmap for (SysID 2), bits 1 to 8
octet j+2
Codec Bitmap for (SysID 2), bits 9 to 16
octet j+3
System Identification x (SysID x)

octet m

Length Of Bitmap for (SysID x)

octet m+1
Codec Bitmap for (SysID x), bits 1 to 8
octet m+2
Codec Bitmap for (SysID x), bits 9 to 16
octet m+3

Figure 10.5.118c/3GPP TS 24.008 Supported codec list information element
Table 10.5.4.135c/3GPP TS 24.008: Supported Codec List information element
Octet 3, (j), m etc
SysID indicates the radio access technology for which the subsequent Codec Bitmap indicates the supported codec types. 
Coding of this Octet is defined in 3GPP TS 26.103 [83].

Octet 4, (j+1), m+1 etc
Length Of Codec Bitmap for SysID indicates the number of octets included in the list for the given SysID.

Octets (5 & 6), (j+2 & j+3), (m+2 & m+3) etc
The coding of the Codec Bitmap is defined in 3GPP TS 26.103 [83].

NOTE:	If the Codec Bitmap for a SysID is 1 octet, it is an indication that all codecs of the 2nd octet are not supported. If the Codec Bitmap for a SysID is more than 2 octets, the network shall ignore the additional octet(s) of the bitmap and process the rest of the information element.


10.5.4.33	Service category
The purpose of the Service category information element is to provide the network with information about services invoked by the user equipment.
The Service category information element is coded as shown in figure 10.5.118d/3GPP TS 24.008 and table 10.5.135d/3GPP TS 24.008
The Service category is a type 4 information element with a minimum length of 3 octets.

8
7
6
5
4
3
2
1


Service Category IEI
octet 1
Length of Service Category
octet 2
0
Emergency Service Category Value
octet 3
spare



Figure 10.5.118d/3GPP TS 24.008 Service Category information element
Table 10.5.135d/3GPP TS 24.008: Service Category information element
Emergency Service Category Value (octet 3)
The meaning of the Emergency Category Value is derived from the following settings (see 3GPP TS 22.101 [8] clause 10):
Bit 1	Police
Bit 2	Ambulance
Bit 3	Fire Brigade
Bit 4	Marine Guard
Bit 5	Mountain Rescue
Bit 6	manually initiated eCall
Bit 7	automatically initiated eCall
Bit 8	is spare and set to "0"


Mobile station may set one or more bits to "1"
If more than one bit is set to "1", routing to a combined Emergency centre (e.g. ambulance and fire brigade in Japan) is required. If the MSC can not match the received service category to any of the emergency centres, it shall route the call to an operator defined default emergency centre.

If no bit is set to "1", the MSC shall route the Emergency call to an operator defined default emergency centre. 
A mobile station initiating an eCall shall set either bit 6 or bit 7 to “1”. The network may use the information indicated in bit 6 and bit 7 to route the manually or automatically initiated eCall to an operator defined emergency call centre.



10.5.4.34	Redial
The purpose of the Redial information element is to indicate to the network that a call is the result of a redial attempt to switch from speech to multimedia or vice-versa.
The Redial information element is coded as shown in figure 10.5.118e/3GPP TS 24.008 
The Redial is a type 2 information element with a length of 1 octet.

8
7
6
5
4
3
2
1


Redial IEI
octet 1

Figure 10.5.118e/3GPP TS 24.008 Redial information element

10.5.4.35	Network-initiated Service Upgrade indicator
The purpose of the Network-initiated Service Upgrade indicator information element is to indicate to the mobile station that the in-call modification procedure is due to a network-initiated upgrade from speech to UDI/RDI multimedia  (see 3GPP TS 23.172 [97]).
The Network- initiated Service Upgrade indicator information element is coded as shown in figure 10.5.118f/3GPP TS 24.008. 
The Network-initiated Service Upgrade indicator is a type 2 information element with a length of 1 octet.

8
7
6
5
4
3
2
1


Network-initiated Service Upgrade indicator IEI
octet 1

Figure 10.5.118f/3GPP TS 24.008 Network-initiated Service Upgrade indicator information element

10.5.5	GPRS mobility management information elements 
10.5.5.0	Additional update type
See subclause 9.9.3.0B in 3GPP TS 24.301 [120].
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.117a/3GPP TS 24.008 and table 10.5.134a/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Attach result
IEI
FOP
Result of
attach
octet 1

Figure 10.5.117a/3GPP TS 24.008: Attach result information element
Table 10.5.134a/3GPP TS 24.008: 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.

Follow-on proceed (octet 1)
Bit
4




0



Follow-on proceed
1



No follow-on proceed

Follow-on proceed is applicable only in Iu mode. This indication shall be ignored if received in A/Gb mode.

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.117b/3GPP TS 24.008 and table 10.5.135b/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Attach type
IEI
FOR
Type of attach
octet 1

Figure 10.5.117b/3GPP TS 24.008: Attach type information element
Table 10.5.135b/3GPP TS 24.008: Attach type information element
Type of attach (octet 1, bit 1 to 3)
Bits
3
2
1


0
0
1

GPRS attach
0
1
0

Not used. This value was allocated in earlier versions of the protocol (Note1)
0
1
1

Combined GPRS/IMSI attach
1
0
0

Emergency attach

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

Follow-on request (octet 1, bit 4)
Bits
4




0



No follow-on request pending
1



Follow-on request pending
Follow-on request pending is applicable only in Iu mode.

NOTE 1: 	The code point “010” if received by the network, it shall be interpreted as "Combined GPRS/IMSI attach".

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 24.008 and table 10.5.136/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Ciphering algorithm
IEI
0
spare
Type of
algorithm
octet 1

Figure 10.5.119/3GPP TS 24.008: Ciphering algorithm information element
Table 10.5.136/3GPP TS 24.008: Ciphering algorithm information element
Type of ciphering 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




10.5.5.3a	Integrity algorithm
The purpose of the integrity algorithm information element is to specify which integrity algorithm shall be used.
The integrity algorithm is a type 1 information element.
The integrity algorithm information element is coded as shown in figure 10.5.5.3a-1/3GPP TS 24.008 and table 10.5.5.3a-1/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Integrity algorithm
IEI
0
spare
Type of
algorithm
octet 1

Figure 10.5.5.3a-1/3GPP TS 24.008: Integrity algorithm information element
Table 10.5.5.3a-1/3GPP TS 24.008: Integrity algorithm information element
Type of integrity algorithm (octet 1)
Bits
3
2
1


0
0
0

GPRS Integrity Algorithm GIA/4
0
0
1

GPRS Integrity Algorithm GIA/5
0
1
0

GPRS Integrity Algorithm GIA/6
0
1
1

GPRS Integrity Algorithm GIA/7
All other values are reserved.


10.5.5.4	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 24.008 and table 10.5.137/3GPP TS 24.008.

8
7
6
5
4
3
2
1

TMSI status
0
0
0
TMSI
octet 1
IEI
spare
flag


Figure 10.5.120/3GPP TS 24.008: TMSI status information element
Table 10.5.137/3GPP TS 24.008: 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 24.008 and table 10.5.138/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Detach type
IEI
Power
off
Type of detach

octet 1

Figure 10.5.121/3GPP TS 24.008: Detach type information element
Table 10.5.138/3GPP TS 24.008: 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 24.008.

8
7
6
5
4
3
2
1

DRX parameter IEI
octet 1
SPLIT PG CYCLE CODE
octet 2
CN Specific DRX cycle length coefficient 
and
DRX value for S1 mode
SPLIT on CCCH
non-DRX
timer

octet 3

Figure 10.5.122/3GPP TS 24.008: DRX parameter information element
Table 10.5.139/3GPP TS 24.008: 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:


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

CN Specific DRX cycle length coefficient and DRX value for S1 mode, octet 3

This field represents two separate values. For Iu mode, it represents the 'CN domain specific DRX cycle length' as defined in 3GPP TS 25.331 [23c]. For S1 mode, it represents the DRX cycle parameter 'T' as defined in 3GPP TS 36.304 [121].

bit
8
7
6
5
Iu and S1 mode specific
0
0
0
0
For Iu mode, CN Specific DRX cycle length coefficient not specified by the MS, ie. the system information value 'CN domain specific DRX cycle length' is used . For S1 mode, DRX value not specified by the MS.
0
1
1
0
CN Specific DRX cycle length coefficient 6 and T = 32
0
1
1
1
CN Specific DRX cycle length coefficient 7 and T = 64
1
0
0
0
CN Specific DRX cycle length coefficient 8 and T = 128
1
0
0
1
CN Specific DRX cycle length coefficient 9 and T = 256

All other values shall be interpreted as "CN Specific DRX cycle length coefficient not specified by the MS " and "DRX value not specified by the MS" by this version of the protocol.

NOTE:	For Iu mode and S1 mode, this field (octet 3 bits 8 to 5) is used, but was spare in earlier versions of this protocol.


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.
In Iu mode, the network shall always indicate force to standby not indicated in the force to standby information element.
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 24.008 and table 10.5.140/3GPP TS 24.008.

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 24.008: Force to standby information element 
Table 10.5.140/3GPP TS 24.008: 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 24.008 and table 10.5.141/3GPP TS 24.008.

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 24.008: P-TMSI signature information element
Table 10.5.141/3GPP TS 24.008: 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.8a	P-TMSI signature 2
The purpose of the P-TMSI signature 2 information element is to identify a GMM context of an MS.
The P-TMSI signature 2 is a type 4 information element with 5 octets length.
The P-TMSI signature 2 information element is coded as shown in figure 10.5.124a/3GPP TS 24.008 and table 10.5.141a/3GPP TS 24.008.

8
7
6
5
4
3
2
1

P-TMSI signature 2 IEI
octet 1
Length of P-TMSI signature 2 contents
octet 2

P-TMSI signature 2 value

octet 3

octet 5

Figure 10.5.124a/3GPP TS 24.008: P-TMSI signature 2 information element
Table 10.5.141a/3GPP TS 24.008: P-TMSI signature 2 information element

P-TMSI signature 2 value is coded as octets 2 to 4 of the P-TMSI signature IE.


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 24.008 and table 10.5.142/3GPP TS 24.008.

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 24.008: Identity type 2 information element
Table 10.5.142/3GPP TS 24.008: 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 24.008 and table 10.5.143/3GPP TS 24.008.

8
7
6
5
4
3
2
1

IMEISV request
IEI
0
spare
IMEISV request
value
octet 1

Figure 10.5.126/3GPP TS 24.008: IMEISV request information element
Table 10.5.143/3GPP TS 24.008: 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 24.008 and table 10.5.144/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Receive N‑PDU Number list IEI
octet 1
Length of Receive N‑PDU Number list contents


Receive N‑PDU Number-list


octet 3
octet 4

octet n*

Figure 10.5.127/3GPP TS 24.008: Receive N‑PDU Number list information element
Table 10.5.144/3GPP TS 24.008: Receive N‑PDU Number list information element
-- Receive N‑PDU Number -list value ::=
< Receive NPDU Number list value > ::=
{
   --< Receive N‑PDU Number -list >
   < Receive NPDU 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 > } ;
< Receive NPDU Number list > ::= < sapi : bit (4) > < Receive NPDU Number value : bit (8) > { < Receive NPDU 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
{ 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) ;
< Receive NPDU 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 maximum of 10 octets length.
The value part of a MS network capabilityinformation element is coded as shown in figure 10.5.128/3GPP TS 24.008 and table 10.5.145/3GPP TS 24.008.
NOTE: 	The requirements for the support of the GEA algorithms in the MS are specified in 3GPP TS 43.020 [13].

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-10

Figure 10.5.128/3GPP TS 24.008 MS network capability information element
Table 10.5.145/3GPP TS 24.008 MS network capability information element
<MS network capability value part> ::=

<GEA1 bits>
<SM capabilities via dedicated channels: bit>
<SM capabilities via GPRS channels: bit>
	<UCS2 support: bit>
--<SS Screening Indicator: bit string(2)>
<SS Screening Indicator: bit (2)>
<SoLSA Capability : bit>
<Revision level indicator: bit>
<PFC feature mode: bit>
<Extended GEA bits>
<LCS VA capability: bit>
<PS inter-RAT HO from GERAN to UTRAN Iu mode capability: bit>
<PS inter-RAT HO from GERAN to E-UTRAN S1 mode capability: bit>
<EMM Combined procedures Capability: bit>
<ISR support: bit>
<SRVCC to GERAN/UTRAN capability: bit>
<EPC capability: bit>

<NF capability: bit>
<GERAN network sharing capability: bit>
<User plane integrity protection support: bit>
<GIA/4: bit>
<GIA/5: bit>
<GIA/6: bit>
<GIA/7: bit>
<Spare bits>;

<GEA1 bits> ::= < 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 24.080 [24] 
	0 1	defined in 3GPP TS 24.080 [24] 
	1 0	defined in 3GPP TS 24.080 [24]
	1 1	defined in 3GPP TS 24.080 [24] 

SM capabilities via dedicated channels
	0	Mobile station does not support mobile terminated point to point SMS via CS domain
	1	Mobile station supports mobile terminated point to point SMS via CS domain

SM capabilities via GPRS channels
	0	Mobile station does not support mobile terminated point to point SMS via PS domain
	1	Mobile station supports mobile terminated point to point SMS via PS domain
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 23.038 [8b])
		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 (NOTE)
The MS shall set this bit to '0'.
The network shall accept any received value in order to support MSs that are compliant to earlier versions of this specification.
0	encryption algorithm GEA/1not available
1	Not used. This value was allocated in earlier versions of the protocol.
SoLSA Capability
	0	The ME does not support SoLSA.
	1	The ME supports SoLSA.

Revision level indicator 
	0	used by a mobile station not supporting R99 or later versions of the protocol
	1	used by a mobile station supporting R99 or later versions of the protocol 
PFC feature mode
    0 Mobile station does not support BSS packet flow procedures
    1 Mobile station does support BSS packet flow procedures
GEA/2 (NOTE)
0	encryption algorithm GEA/2 not available
1	encryption algorithm GEA/2 available
GEA/3 (NOTE)
0	encryption algorithm GEA/3 not available
1	encryption algorithm GEA/3 available
GEA/4 (NOTE)
0	encryption algorithm GEA/4 not available
1	encryption algorithm GEA/4 available
GEA/5 (NOTE)
0	encryption algorithm GEA/5 not available
1	encryption algorithm GEA/5 available
GEA/6 (NOTE)
0	encryption algorithm GEA/6 not available
1	encryption algorithm GEA/6 available
GEA/7 (NOTE)
0	encryption algorithm GEA/7 not available
1	encryption algorithm GEA/7 available

LCS VA capability (LCS value added location request notification capability)
This information field indicates the support of the LCS value added location request notification via PS domain as defined in 3GPP TS 23.271 [105].
0	location request notification via PS domain not supported
1	location request notification via PS domain supported
PS inter-RAT HO from GERAN to UTRAN Iu mode capability
This information field indicates the support of the PS inter-RAT HO from GERAN to UTRAN Iu mode.
0	PS inter-RAT HO from GERAN to UTRAN Iu mode not supported
1	PS inter-RAT HO from GERAN to UTRAN Iu mode supported
PS inter-RAT HO from GERAN to E-UTRAN S1 mode capability
This information field indicates the support of the PS inter-RAT HO from GERAN to E-UTRAN S1 mode. A mobile station not compliant to the UE E-UTRA capability requirements as defined in 3GPP TS 36.306 [153] shall set this field to '0'.
0	PS inter-RAT HO from GERAN to E-UTRAN S1 mode not supported
1	PS inter-RAT HO from GERAN to E-UTRAN S1 mode supported
EMM Combined procedures capability
This information field indicates the support of EMM combined procedures. The MS shall not change this information field from the one that was included in the GMM or EMM ATTACH REQUEST message.
0	Mobile station does not support EMM combined procedures
1	Mobile station supports EMM combined procedures
ISR support
0	The mobile station does not support ISR.
1	The mobile station supports ISR.
SRVCC to GERAN/UTRAN capability
0	SRVCC from UTRAN HSPA or E-UTRAN to GERAN/UTRAN not supported
1	SRVCC from UTRAN HSPA or E-UTRAN to GERAN/UTRAN supported
EPC capability
This information field indicates if the MS supports access to the EPC via access networks other than GERAN or UTRAN.The network can use this information to decide whether to select a PDN Gateway or a GGSN. The MS shall set the indication to "0" if a SIM is inserted in the MS.
0	EPC not supported
1	EPC supported
NF capability
This information field indicates if the MS supports the notification procedure.
0	Mobile station does not support the notification procedure.
1	Mobile station supports the notification procedure.
GERAN network sharing capability
This information field indicates if the MS supports GERAN network sharing.
0	Mobile station does not support GERAN network sharing.
1	Mobile station supports GERAN network sharing.
User plane integrity protection support
0	The mobile station does not support user plane integrity protection.
1	The mobile station supports user plane integrity protection.
GIA/4 (NOTE)
0	integrity algorithm GIA/4 not available
1	integrity algorithm GIA/4 available
GIA/5 (NOTE)
0	integrity algorithm GIA/5 not available
1	integrity algorithm GIA/5 available 
GIA/6 (NOTE)
0	integrity algorithm GIA/5 not available
1	integrity algorithm GIA/5 available 
GIA/7 (NOTE)
0	integrity algorithm GIA/5 not available
1	integrity algorithm GIA/5 available

NOTE:	The requirements for the support of the GEA and the GIA algorithms in the MS are specified in 3GPP TS 43.020 [13].

10.5.5.12a	MS Radio Access capability
The purpose of the MS Radio Access 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 Radio Access capability is a type 4 information element, with a maximum length of 52 octets.
The MS Radio Access capability information element is coded as shown in figure 10.5.128a/3GPP TS 24.008 and table 10.5.146/3GPP TS 24.008.
For the indication of the radio access capabilities the following conditions shall apply:
-	Among the three Access Type Technologies GSM 900-P, GSM 900-E and GSM 900-R only one shall be present.
-	Due to shared radio frequency channel numbers between GSM 1800 and GSM 1900, the mobile station should provide the relevant radio access capability for either GSM 1800 band OR GSM 1900 band, not both.
-	The MS shall indicate its supported Access Technology Types during a single MM procedure.
-	If the alternative coding by using the Additional access technologies struct is chosen by the mobile station, the mobile station shall indicate its radio access capability for the serving BCCH frequency band in the first included Access capabilities struct, if this information element is not sent in response to an Access Technologies Request from the network or if none of the requested Access Technology Types is supported by the MS. Otherwise, the mobile station shall include the radio access capabilities for the frequency bands it supports in the order of priority requested by the network (see 3GPP TS 44.060 [76]).
-	The first Access Technology Type shall not be set to "1111".
For error handling the following shall apply:
	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.
	For more details about error handling of MS radio access capability see 3GPP TS 48.018 [86].
NOTE: 	The requirements for the support of the A5 algorithms in the MS are specified in 3GPP TS 43.020 [13].

8
7
6
5
4
3
2
1

MS Radio Access Capability IEI
octet 1
Length of MS Radio Access Capability contents
octet 2
MS RA capability value part
octet 3-52

Figure 10.5.128a/3GPP TS 24.008 MS Radio Access Capability information element
Table 10.5.146/3GPP TS 24.008: MS Radio Access Capability Information Element
< 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) > exclude 1111
			< Access capabilities : <Access capabilities struct> > }

	 | 	{	< Access Technology Type: bit (4) == 1111 >	-- structure adding Access technologies with same capabilities
			< Length : bit (7) > 		-- length in bits of list of Additional access technologies and spare bits
			< bit (val (Length))
			& {
				{ 1 < Additional access technologies: < Additional access technologies struct > > } ** 0
				<spare bits>**
			} >
		 }
	 }

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

< Additional access technologies struct > ::=
	< Access Technology Type : bit (4) >
	< GMSK Power Class : bit (3) >
	< 8PSK Power Class : bit (2) > ;

< Access capabilities struct > ::=
	< Length : bit (7) > -- length in bits of Content and spare bits
		< bit (val (Length))
	& { 
			<Access capabilities : <Content>> 
		<spare bits>**
		} > ; -- expands to the indicated length

< 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 preceding Access capabilities field 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 for multislot parameters as given in an earlier Access capabilities field within this IE apply also here
-- Additions in release 99
	{ 0 | 1 < 8PSK Power Capability : bit(2) >}
	< COMPACT Interference Measurement Capability : bit >
	< Revision Level Indicator : bit >
	< UMTS FDD Radio Access Technology Capability : bit > 				-- 3G RAT
	< UMTS 3.84 Mcps TDD Radio Access Technology Capability : bit > 	-- 3G RAT
	< CDMA 2000 Radio Access Technology Capability : bit > 				-- 3G RAT
-- Additions in release 4
	< UMTS 1.28 Mcps TDD Radio Access Technology Capability: bit >	-- 3G RAT
	< GERAN Feature Package 1 : bit >
	{ 0 | 1 < Extended DTM GPRS Multi Slot Class : bit(2) >
			< Extended DTM EGPRS Multi Slot Class : bit(2) > }
	< Modulation based multislot class support : bit >
-- Additions in release 5
	{ 0 | 1 < High Multislot Capability : bit(2) > }
	0	-- The value '1' was allocated in an earlier version of the protocol and shall not be used.
< GMSK Multislot Power Profile : bit (2) >
	< 8-PSK Multislot Power Profile : bit (2) > 
-- Additions in release 6
	< Multiple TBF Capability : bit >
	< Downlink Advanced Receiver Performance : bit(2) >
	< Extended RLC/MAC Control Message Segmentation Capability : bit >
	< DTM Enhancements Capability : bit >
	{ 0 | 1	< DTM GPRS High Multi Slot Class : bit(3) >
			{ 0 | 1 < DTM EGPRS High Multi Slot Class : bit(3) > } }
	< PS Handover Capability : bit >
-- Additions in release 7
	< DTM Handover Capability : bit >
	{ 0 | 1 < Multislot Capability Reduction for Downlink Dual Carrier: bit (3) >
			< Downlink Dual Carrier for DTM Capability : bit> }
	< Flexible Timeslot Assignment : bit >
	< GAN PS Handover Capability : bit >
	< RLC Non-persistent Mode : bit >
	< Reduced Latency Capability : bit >
	< Uplink EGPRS2 : bit(2) >	
	< Downlink EGPRS2 : bit(2) >
-- Additions in release 8
	< E-UTRA FDD support : bit > 
	< E-UTRA TDD support : bit >
	< GERAN to E-UTRA support in GERAN packet transfer mode: bit(2) >
	< Priority-based reselection support : bit >
-- Additions in release 9
	< Enhanced Flexible Timeslot Assignment : Enhanced Flexible Timeslot Assignment struct>
	< Indication of Upper Layer PDU Start Capability for RLC UM : bit >
	< EMST Capability : bit >
	< MTTI Capability : bit >
	< UTRA CSG Cells Reporting : bit >
	< E-UTRA CSG Cells Reporting : bit >
-- Additions in release 10
	< DTR Capability : bit >
	< EMSR Capability : bit >
	< Fast Downlink Frequency Switching Capability : bit >
	< TIGHTER Capability : bit(2) >
-- Additions in release 11
	< FANR Capability : bit >
	< IPA Capability : bit>
	< GERAN Network Sharing support : bit>
	< E-UTRA Wideband RSRQ measurements support : bit>
-- Additions in release 12
	< UTRA Multiple Frequency Band Indicators support : bit >
	< E-UTRA Multiple Frequency Band Indicators support : bit >
	{ 0			-- DLMC not supported
		| 1 < DLMC Capability : DLMC Capability struct > }
	< Extended TSC Set Capability support : bit >
-- Late addition of a release 11 feature
	< Extended EARFCN value range: bit>
-- Additions in release 13
	--< (EC-)PCH monitoring support: bit(2)>;
	< PCH monitoring support: bit(2)>;
	-- error: struct too short, assume features do not exist	
	-- error: struct too long, ignore data and jump to next Access technology

Table 10.5.146/3GPP TS 24.008 (continued): MS Radio Access Capability 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)  > }
-- Additions in release 99
	{ 0 | 1 < ECSD multislot class : bit (5) > }
	{ 0 | 1 < EGPRS multislot class : bit (5) > < EGPRS Extended Dynamic Allocation Capability : bit > }
	{ 0 | 1	< DTM GPRS Multi Slot Class: bit(2)>
			<Single Slot DTM : bit>
			{0 | 1 <DTM EGPRS Multi Slot Class : bit(2)> } } ;
	-- error: struct too short, assume features do not exist

<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. These fields are not used by the network and may be excluded by the MS.

< Enhanced Flexible Timeslot Assignment struct > ::=
	{ 0 | 1 	< Alternative EFTA Multislot Class : bit(4) > 
			< EFTA Multislot Capability Reduction for Downlink Dual Carrier: bit (3) > };

< DLMC Capability struct > ::=
	{ 0 | 1	< DLMC - Non-contiguous intra-band reception : bit(2) >
 			< DLMC - Inter-band reception : bit(1) > }
	< DLMC - Maximum Bandwidth : bit(2) >
	< DLMC - Maximum Number of Downlink Timeslots : bit(6) >
	< DLMC - Maximum Number of Downlink Carriers : bit(3) > ;

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
0 1 0 1 	GSM 450
0 1 1 0 	GSM 480
0 1 1 1 	GSM 850
1 0 0 0 	GSM 750
1 0 0 1 	GSM T 380
1 0 1 0 	GSM T 410
1 0 1 1 	-- This value was allocated in an earlier version of the protocol and shall not be used.
1 1 0 0 	GSM 710
1 1 0 1 	GSM T  810
1 1 1 1 	Indicates the presence of a list of Additional access technologies
All other values are treated as unknown by the receiver.

A MS which does not support any GSM access technology type shall set this field to '0000'.

RF Power Capability, GMSK Power Class (3 bit field)
This field contains the binary coding of the power class used for GMSK associated with the indicated Access Technology Type (see 3GPP TS 45.005 [33]).

A MS which does not support any GSM access technology type shall set this field to '000'.

8PSK Power Capability (2 bit field)
If 8-PSK modulation is supported for uplink, this field indicates the radio capability for 8‑PSK modulation. The following coding is used (see 3GPP TS 45.005 [33]):
Bits	2 1
		0 0		Reserved
		0 1		Power class E1
		1 0		Power class E2
		1 1		Power class E3

The presence of this field also indicates 8PSK modulation capability in the uplink.

8PSK Power Class (2 bit field)
This field indicates the radio capability for 8‑PSK modulation. The following coding is used (see 3GPP TS 45.005 [33]):
Bits	2 1
		0 0		8PSK modulation not supported for uplink
		0 1		Power class E1
		1 0		Power class E2
		1 1		Power class E3

Additional access technologies struct
This structure contains the GMSK Power Class and 8PSK Power Class for an additional Access Technology. All other capabilities for this indicated Access Technology are the same as the capabilities indicated by the preceding Access capabilities struct.

A5/1 
0	encryption algorithm A5/1 not available
1	encryption algorithm A5/1 available
A5/2 
The MS shall set this bit to ‘0’.
The network shall accept any received value.
0	encryption algorithm A5/2 not available
1	Not used. This value was allocated in earlier versions of the protocol.
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

Table 10.5.146/3GPP TS 24.008 (concluded): MS Radio Access Capability IE
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 3GPP TS 45.002 [32]. This field is not used by the network and may be excluded by the MS.
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 3GPP TS 45.002 [32].
ECSD Multi Slot Class 
The presence of this field indicates ECSD capability. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the presence of 8-PSK Power Capability field. The Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32]. This field is not used by the network and may be excluded by the MS.
Range 1 to 18, all other values are reserved.
EGPRS Multi Slot Class
The presence of this field indicates EGPRS capability. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the presence of 8-PSK Power Capability field. The EGPRS Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32]. 

The same multislot capability is applicable also for EGPRS2 if supported.
The same multislot capability is applicable also for Downlink Multi Carrier configuration if supported.

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

If a multislot class type 1 MS indicates in the GPRS Multi Slot Class field the support of a multislot class for which three or more uplink timeslots can be assigned, Extended Dynamic Allocation for GPRS shall be implemented in the mobile station.

EGPRS Extended Dynamic Allocation Capability
0     Extended Dynamic Allocation Capability for EGPRS and EGPRS2 (if supported) is not implemented
1     Extended Dynamic Allocation Capability for EGPRS and EGPRS2 (if supported) is implemented

If a multislot class type 1 MS indicates in the EGPRS Multi Slot Class field the support of a multislot class for which three or more uplink timeslots can be assigned, Extended Dynamic Allocation for EGPRS and EGPRS2 (if supported) shall be implemented in the mobile station.

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. This field is not used by the network and may be excluded by the MS.
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 neighbour cell power measurement. This field is not used by the network and may be excluded by the MS.
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)


DTM GPRS Multi Slot Class (2 bit field)
This field indicates the DTM GPRS multislot capabilities of the MS. It is coded as follows:
Bits
2 1
0 0		Unused. If received, the network shall interpret this as ‘01’
0 1		Multislot class 5 supported
1 0		Multislot class 9 supported
1 1		Multislot class 11 supported

This field shall contain one of the following values if the DTM GPRS High Multi Slot Class field is present:

Multislot class 9	if DTM GPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41;
Multislot class 11	if DTM GPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44.

Single Slot DTM (1 bit field)
This field indicates whether the MS supports single slot DTM operation (see 3GPP TS 43.055 [87]).
Bit
0		Single Slot DTM not supported
1		Single Slot DTM supported

An MS indicating support for Extended DTM GPRS multislot class or Extended DTM EGPRS multislot class shall set this bit to ‘1’. The network may ignore the bit in this case.

DTM EGPRS Multi Slot Class (2 bit field)
This field indicates the DTM EGPRS multislot capabilities of the MS. This field shall be included only if the mobile station supports EGPRS DTM. This field is coded as the DTM GPRS multislot Class field.

This field shall contain one of the following values if the DTM EGPRS High Multi Slot Class field is present:

Multislot class 9	if DTM EGPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41;
Multislot class 11	if DTM EGPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44.

The same multislot capability is applicable also for EGPRS2 if supported.

COMPACT Interference Measurement Capability (1 bit field)
0		COMPACT Interference Measurement Capability is not implemented
1		COMPACT Interference Measurement Capability is implemented

Revision Level Indicator (1 bit field)
Bit
0		The ME is Release ’98 or older
1		The ME is Release ’99 onwards

UMTS FDD Radio Access Technology Capability (1 bit field)
Bit
0		UMTS FDD not supported
1		UMTS FDD supported

UMTS 3.84 Mcps TDD Radio Access Technology Capability (1 bit field)
Bit
0		UMTS 3.84 Mcps TDD not supported
1		UMTS 3.84 Mcps TDD supported

CDMA 2000 Radio Access Technology Capability (1 bit field)
Bit
0		CDMA 2000 not supported
1		CDMA 2000 supported

UMTS 1.28 Mcps TDD Radio Access Technology Capability (1 bit field)
Bit
0		UMTS 1.28 Mcps TDD not supported
1		UMTS 1.28 Mcps TDD supported

GERAN Feature Package 1 (1 bit field)
The support of interworking towards E-UTRA is indicated separately in the "GERAN to E-UTRA support in GERAN packet transfer mode" field. This field indicates whether the MS supports the GERAN Feature Package 1 (see 3GPP TS 44.060 [76]). It is coded as follows:

0		GERAN feature package 1 not supported.
1		GERAN feature package 1 supported.

Extended DTM GPRS Multi Slot Class (2 bit field)
This field indicates the extended DTM GPRS capabilities of the MS and shall be interpreted in conjunction with the DTM GPRS Multi Slot Class field. It is coded as follows, where ‘DGMSC’ denotes the DTM GPRS multislot class field:
DGMSC Bit	2 1		Bit	2 1
				0 0			0 0		Unused. If received, it shall be interpreted as ‘01 00’
				0 0			0 1		Unused. If received, it shall be interpreted as ‘01 00’
				0 0			1 0		Unused. If received, it shall be interpreted as ‘01 00’
				0 0			1 1		Unused. If received, it shall be interpreted as ‘01 00’
				0 1			0 0		Multislot class 5 supported
				0 1			0 1		Multislot class 6 supported
				0 1			1 0		Unused. If received, it shall be interpreted as ‘01 00’
				0 1			1 1		Unused. If received, it shall be interpreted as ‘01 00’
				1 0			0 0		Multislot class 9 supported
				1 0			0 1		Multislot class 10 supported
				1 0			1 0		Unused. If received, it shall be interpreted as ’10 00’
				1 0			1 1		Unused. If received, it shall be interpreted as ’10 00’
				1 1			0 0		Multislot class 11 supported
				1 1			0 1		Unused. If received, it shall be interpreted as ’11 00’
				1 1			1 0		Unused. If received, it shall be interpreted as ’11 00’
				1 1			1 1		Unused. If received, it shall be interpreted as ’11 00’

The presence of this field indicates that the MS supports combined fullrate and halfrate GPRS channels in the downlink. When this field is not present, the MS supports the multislot class indicated by the DTM GPRS Multi Slot Class field.

If this field is included, it shall contain one of the following values if the DTM GPRS High Multi Slot Class field is present:

Multislot class 10	if DTM GPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41;
Multislot class 11	if DTM GPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44.

Extended DTM EGPRS Multislot Class (2 bit field)
This field is not considered when the DTM EGPRS Multislot Class field is not included. This field indicates the extended DTM EGPRS multislot capabilities of the MS and shall be interpreted in conjunction with the DTM EGPRS Multislot Class field. This field is coded as the Extended DTM GPRS Multislot Class field. The presence of this field indicates that the MS supports combined fullrate and halfrate GPRS channels in the downlink. When this field is not present, the MS supports the multislot class indicated by the DTM EGPRS Multi Slot Class field.

If this field is included, it shall contain one of the following values if the DTM EGPRS High Multi Slot Class field is present:

Multislot class 10	if DTM EGPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41;
Multislot class 11	if DTM EGPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44.

Modulation based multislot class support (1 bit field)
Bit
0		"Modulation based multislot class" not supported
1		"Modulation based multislot class" supported

High Multislot Capability (2 bit field)
The High Multislot Capability is individually combined with each multislot class field sent by the MS (the possible multislot class fields are: GPRS multislot class, EGPRS multislot class) to extend the related multislot class to multislot classes 30 to 45, see 3GPP TS 45.002 [32]. The same capability is applicable also to EGPRS2 if supported. The same capability is applicable also to Downlink Multi Carrier configuration if supported.
For each multislot class, the following mapping is done:
Bits
2 1		coded multislot class field			actual multislot class
0 0				8										30
0 0				10, 23, 28, 29							39
0 0				11, 20, 25								32
0 0				12, 21, 22, 26, 27						33
0 0				Any other								Multislot Class field value
0 1				8										35
0 1				10, 19, 24								36
0 1				11, 23, 28, 29							45
0 1				12, 21, 22, 26, 27						38
0 1				Any other								Multislot Class field value
1 0				 8										40
1 0				10, 19, 24								41
1 0				11, 20, 25								42
1 0				12, 23, 28, 29                                   44
1 0				Any other								Multislot Class field value
1 1				12, 21, 22, 26, 27						43
1 1				11, 20, 25								37
1 1				10, 19, 24								31
1 1				 9, 23, 28, 29							34
1 1				Any other								Multislot Class field value

GMSK Multislot Power Profile (2 bit field)
For detailed definitions, see the Mobile Station Classmark 3 information element.

8-PSK Multislot Power Profile (2 bit field)
For detailed definitions, see the Mobile Station Classmark 3 information element.

Multiple TBF Capability (1 bit field)
Bit
0		Multiple TBF procedures in A/Gb mode not supported
1		Multiple TBF procedures in A/Gb mode supported


Downlink Advanced Receiver Performance (2 bit field)
This field indicates Downlink Advanced Receiver Performance capabilities of the MS (see 3GPP TS 45.005 [33]).
Bits
2 1
0 0		Downlink Advanced Receiver Performance not supported
0 1		Downlink Advanced Receiver Performance – phase I supported
1 0		Downlink Advanced Receiver Performance – phase II supported

The value ‘11’  shall not be used by the MS.
If the value ‘11’ is received by the network, it shall be interpreted as ‘10’ .

Extended RLC/MAC Control Message Segmentation capability (1 bit field)
Bit
0		Extended RLC/MAC control message segmentation not supported
1		Extended RLC/MAC control message segmentation supported

DTM Enhancements Capability (1 bit field) 
This field indicates whether the mobile station supports enhanced DTM CS establishment and enhanced DTM CS release or not. It is coded as follows:
Bit
0		The mobile station does not support enhanced DTM CS establishment and enhanced DTM CS release procedures. 
1		The mobile station supports enhanced DTM CS establishment and enhanced DTM CS release procedures.

DTM GPRS High Multi Slot Class (3 bit field)
This field indicates the DTM GPRS multislot capabilities of the MS. It is coded as follows:

	Bit
	3 2 1
	0 0 0		Unused. If received, the network shall interpret this as ‘0 0 1’
	0 0 1		Multislot class 31 or 36 supported
	0 1 0		Multislot class 32 or 37 supported
	0 1 1		Multislot class 33 or 38 supported
	1 0 0		Multislot class 41 supported
	1 0 1		Multislot class 42 supported
	1 1 0		Multislot class 43 supported
	1 1 1		Multislot class 44 supported

The presence of this field indicates that the MS supports the DTM extension to high multislot classes. When this field is not present, the MS supports the DTM multislot class indicated by the DTM GPRS Multi Slot Class field.

The values '0 0 1', '0 1 0' and '0 1 1' shall be interpreted as indicating DTM GPRS multislot class 36, 37 or 38 respectively in case the MS indicates support for one of the GPRS multislot classes 35 to 39; in all other cases those codepoints shall be interpreted as indicating DTM GPRS multislot class 31, 32 or 33 respectively.

This field shall be ignored if the High Multislot Capability field is not present.

DTM EGPRS High Multi Slot Class (3 bit field)
This field indicates the DTM EGPRS multislot capabilities of the MS. This field may be included only if the mobile station supports EGPRS DTM. This field is coded as the DTM GPRS High Multi Slot Class field. When this field is not present, the MS supports the DTM multislot class indicated by the DTM EGPRS Multi Slot Class field.

The values '0 0 1', '0 1 0' and '0 1 1' shall be interpreted as indicating DTM EGPRS multislot class 36, 37 or 38 respectively in case the MS indicates support for one of the EGPRS multislot classes 35 to 39; in all other cases those codepoints shall be interpreted as indicating DTM EGPRS multislot class 31, 32 or 33 respectively.

This field shall be ignored if the High Multislot Capability field is not present.

The same multislot capability is applicable also for EGPRS2 if supported.

PS Handover Capability (1 bit field)
This field indicates whether the mobile station supports PS Handover. The PS Handover Capability applies to all RATs and modes indicated as supported in this information element, except for E-UTRA, where the support is indicated separately in the "GERAN to E-UTRA support in GERAN packet transfer mode" field.
Bit
0		The mobile station does not support PS Handover.
1		The mobile station supports PS Handover

DTM Handover Capability (1 bit field)
This field indicates whether the mobile station supports DTM Handover. The DTM Handover Capability applies to all RATs and modes indicated as supported in this information element. It is coded as follows:
Bit
0		The mobile station does not support DTM Handover.
1		The mobile station supports DTM Handover

Multislot Capability Reduction for Downlink Dual Carrier (3 bit field)
This field indicates the receive multislot capability reduction of a dual carrier capable mobile station applicable to EGPRS and EGPRS2 support when EFTA is not used (see 3GPP TS 45.002 [32]). This reduction applies to the maximum number of downlink timeslots for dual carrier operation derived from the (DTM) EGPRS (high) multislot class. The field is coded as follows:

	 Bit
	3 2 1
	0 0 0		No reduction
	0 0 1		The MS supports 1 timeslot fewer than the maximum number of receive timeslots
	0 1 0		The MS supports 2 timeslots fewer than the maximum number of receive timeslots 
	0 1 1		The MS supports 3 timeslots fewer than the maximum number of receive timeslots 
	1 0 0		The MS supports 4 timeslots fewer than the maximum number of receive timeslots 
	1 0 1		The MS supports 5 timeslots fewer than the maximum number of receive timeslots 
	1 1 0		The MS supports 6 timeslots fewer than the maximum number of receive timeslots 
	1 1 1		Reserved for future use

The presence of this field also indicates that the mobile station supports dual carrier in the downlink for EGPRS.

Downlink Dual Carrier for DTM Capability (1 bit field)
This field indicates whether the mobile station supports DTM during downlink dual carrier operation. 

Bit
0		The mobile station does not support DTM during downlink dual carrier operation
1		The mobile station supports DTM during downlink dual carrier operation

If the mobile station supports DTM during downlink dual carrier operation as indicated by this field, the Multislot Capability Reduction for Downlink Dual Carrier field provided in the MS Radio Access Capability IE is applicable to EGPRS DTM support as well. 

Flexible Timeslot Assignment (1 bit field)
This field indicates whether the mobile station supports Flexible Timeslot Assignment (see 3GPP TS 45.002 [32]).

	0	The mobile station does not support Flexible Timeslot Assignment
	1	The mobile station supports Flexible Timeslot Assignment

GAN PS Handover Capability (1 bit field)
This field indicates whether or not the mobile station supports PS Handover from GERAN/UTRAN cell to a GAN cell. The field is coded as follows:
Bit
0		The mobile station does not support PS Handover from GERAN/UTRAN cell to a GAN cell
1		The mobile station supports PS Handover from GERAN/UTRAN cell to a GAN cell

RLC Non-persistent Mode Capability (1 bit field)
This field indicates whether the mobile station supports RLC Non-persistent Mode (see 3GPP TS 44.060 [76]). 

	0	The mobile station does not support RLC Non-persistent Mode
	1	The mobile station supports RLC Non-persistent Mode 

Reduced Latency Capability (1 bit field)
This field indicates whether the mobile station supports Reduced TTI configurations and Fast Ack/Nack Reporting (see 3GPP TS 44.060 [76]) in packet transfer mode for both EGPRS and, if supported, EGPRS2. 

	0	The mobile station does not support Reduced TTI configurations and Fast Ack/Nack Reporting 
	1	The mobile station supports Reduced TTI configurations and Fast Ack/Nack Reporting

A mobile station whose multislot class does not allow the support of Reduced TTI configurations in packet transfer mode due to a limited number of uplink or downlink timeslots (see 3GPP TS 45.002 [32]) shall set the Reduced Latency Capability field to '0'.

Uplink EGPRS2 (2 bit field)
This field indicates whether the mobile station supports EGPRS2-A or EGPRS2-A and EGPRS2-B in the uplink.

Bit
2 1
0 0		The mobile station does not support either EGPRS2-A or EGPRS2-B  in the uplink
0 1		The mobile station supports EGPRS2-A in the uplink
1 0		The mobile station supports both EGPRS2-A and EGPRS2-B in the uplink
1 1 	This value is not used in this release/version of the specifications. If received it shall be interpreted 					as ‘10’

Downlink EGPRS2 (2 bit field)
This field indicates whether the mobile station supports EGPRS2-A or EGPRS2-A and EGPRS2-B in the downlink.

Bit
2 1
0 0		The mobile station does not support either EGPRS2-A or EGPRS2-B  in the downlink
0 1		The mobile station supports EGPRS2-A in the downlink
1 0		The mobile station supports both EGPRS2-A and EGPRS2-B in the downlink
1 1 	This value is not used in this release/version of the specifications. If received it shall be interpreted 					as ‘10’

E-UTRA FDD support (1 bit field)
Bit
0		E-UTRA FDD not supported
1		E-UTRA FDD supported

E-UTRA TDD support (1 bit field)
Bit
0		E-UTRA TDD not supported
1		E-UTRA TDD supported

GERAN to E-UTRA support in GERAN packet transfer mode (2 bit field)
This field indicates the capabilities supported by the mobile station in packet transfer mode for GERAN to E-UTRA interworking. If both "E-UTRA FDD support" and "E-UTRA TDD support" bits are set to '0', the bit field shall be set to '0 0'. If one or both of "E-UTRA FDD support" and "E-UTRA TDD support" bits are set to '1', the bit field may be any of the listed values. The bit field is coded as follows:
Bit
2 1
0 0		None
0 1		E-UTRAN Neighbour Cell measurements and MS autonomous cell reselection to E-UTRAN supported
1 0		CCN towards E-UTRAN, E-UTRAN Neighbour Cell measurement reporting and Network controlled cell
		reselection to E-UTRAN supported in addition to capabilities indicated by '01'
1 1		PS Handover to E-UTRAN supported in addition to capabilities indicated by '01' and '10'

Priority-based reselection support (1 bit field)
This field indicates whether the mobile station supports priority-based cell reselection.

0		Priority-based cell reselection not supported
1		Priority-based cell reselection supported

Alternative EFTA multislot class (4 bit field)
The presence of the Alternative EFTA multislot class field indicates that the mobile station supports Enhanced Flexible Timeslot Assignment, EFTA, (see 3GPP TS 45.002 [32]). This field shall be ignored if the High Multislot Capability field is not present. The Alternative EFTA multislot class field is used together with the (DTM) EGPRS (high) multislot class to determine the mobile stations capabilities when using Enhanced Flexible Timeslot Assignment, EFTA, and is coded as follows:

	Bit
	4 3 2 1
	0 0 0 0		No Alternative EFTA multislot class is indicated. Use (DTM) EGPRS (high) multislot class only.
	0 0 0 1		Alternative EFTA multislot class 1
	0 0 1 0		Alternative EFTA multislot class 2
	0 0 1 1		Alternative EFTA multislot class 3
	0 1 0 0
	to
	1 1 1 1		Unused. If received, these values shall be interpreted as ’0000’

EFTA Multislot Capability Reduction for Downlink Dual Carrier (3 bit field)
This field indicates the receive multislot capability reduction of a dual carrier capable mobile station applicable to EGPRS and EGPRS2 support when Enhanced Flexible Timeslot Assignment is used (see 3GPP TS 45.002 [32]). This reduction applies to the maximum number of downlink timeslots for dual carrier operation derived from the Alternative EFTA Multislot Class field. The coding of this field is the same as the coding of the Multislot Capability Reduction for Downlink Dual Carrier field.

This field shall be ignored if a mobile station does not support Downlink Dual Carrier.

Indication of Upper Layer PDU Start Capability for RLC UM (1 bit field)
This field indicates whether the mobile station supports "Indication of Upper Layer PDU Start for RLC UM” (see 3GPP TS 44.060 [76]) for RLC unacknowledged mode of operation. The field is coded as follows:

0	The mobile station does not support "Indication of Upper Layer PDU Start for RLC UM” 
1	The mobile station supports "Indication of Upper Layer PDU Start for RLC UM” 

EMST Capability (1 bit field)
This field indicates whether the mobile station supports Enhanced Multiplexing for Single TBF (EMST) (see 3GPP TS 44.060 [76]).

0	The mobile station does not support EMST
1	The mobile station supports EMST

MTTI Capability (1 bit field)
This field indicates whether the mobile station supports multiple TTI (MTTI) configurations (see 3GPP TS 44.060 [76])
Bit
0		MTTI configurations not supported
1		MTTI configurations supported

UTRA CSG Cells Reporting (1 bit field)
This field indicates whether the mobile station supports reporting of measurements and routing parameters (see 3GPP TS 44.060 [76]) for UTRAN CSG cells in packet transfer mode. This capability shall apply to each UTRA radio access mode supported by the mobile.
Bit
0		Reporting of UTRAN CSG cells in packet transfer mode not supported
1		Reporting of UTRAN CSG cells in packet transfer mode supported

E-UTRA CSG Cells Reporting (1 bit field)
This field indicates whether the mobile station supports reporting of measurements and routing parameters (see 3GPP TS 44.060 [76]) for E-UTRAN CSG cells in packet transfer mode. This capability shall apply to each E-UTRA radio access mode supported by the mobile.
Bit
0		Reporting of E-UTRAN CSG cells in packet transfer mode not supported
1		Reporting of E-UTRAN CSG cells in packet transfer mode supported

DTR Capability (1 bit field)
This field indicates whether the mobile station supports Dynamic Timeslot Reduction (DTR), see 3GPP TS 44.060 [76].

0	The mobile station does not support DTR
1	The mobile station supports DTR

EMSR Capability (1 bit field)
This field indicates whether the mobile station supports Enhanced Multiplexing for Single RLC Entity (EMSR), see 3GPP TS 44.060 [76].

0	The mobile station does not support EMSR
1	The mobile station supports EMSR

Fast Downlink Frequency Switching Capability (1 bit field)
This field indicates whether the mobile station supports fast downlink frequency switching between two consecutive TDMA frames (see 3GPP TS 45.002 [32]).

0		Fast downlink frequency switching not supported
1		Fast downlink frequency switching supported

TIGHTER Capability (2 bit field)
This field indicates Tightened Link Level Performance support in the MS (see 3GPP TS 45.005 [33]). The tightened performance applies to the traffic channels and signalling channels specified in 3GPP TS 45.005 [33].

Bits
2 1
0 0		TIGHTER not supported
0 1		TIGHTER supported for speech and signalling channels only
1 0		TIGHTER supported for speech and signalling channels and for GPRS and EGPRS, but not for EGPRS2
1 1		TIGHTER supported for speech and signalling channels and for GPRS, EGPRS and EGPRS2

FANR Capability (1 bit field)
This field indicates whether the mobile station supports Fast Ack/Nack Reporting (see 3GPP TS 44.060 [76]) in packet transfer mode for EGPRS and, if supported, EGPRS2. If the mobile station indicates support for Reduced TTI configurations and Fast Ack/Nack Reporting using the Reduced Latency Capability Indicator then the network shall ignore FANR Capability information.

	0	The mobile station does not support Fast Ack/Nack Reporting 
	1	The mobile station supports Fast Ack/Nack Reporting

IPA Capability (1 bit field)
This field indicates whether the mobile station supports Immediate Packet Assignment (IPA), see 3GPP TS 44.018 [84].

Bit
0		The mobile station does not support IPA
1		The mobile station supports IPA

GERAN Network Sharing support (1 bit field)
This field indicates whether the mobile station supports GERAN network sharing. A mobile station supporting GERAN network sharing shall also support the extended EARFCN value range in GERAN and indicate this in the respective bit.
Bit
0		The mobile station does not support GERAN network sharing
1		The mobile station supports GERAN network sharing

E-UTRA Wideband RSRQ measurements support (1 bit field)
This field indicates whether the mobile station supports E-UTRA wideband RSRQ measurements (see 3GPP TS 45.008 [151]).

Bit
0		The mobile station does not support E-UTRA wideband RSRQ measurements
1		The mobile station supports E-UTRA wideband RSRQ measurements

UTRA Multiple Frequency Band Indicators support (1 bit field)
This field indicates whether the mobile station supports multiple radio frequency bands in UTRAN (see 3GPP TS 25.331 [23c]) and whether it understands signalling of overlapping UTRA frequency bands (see 3GPP TS 44.060 [76]).

Bit
0		The mobile station does not support Multiple Frequency Band Indicators in UTRAN
1		The mobile station supports Multiple Frequency Band Indicators in UTRAN

E-UTRA Multiple Frequency Band Indicators support (1 bit field)
This field indicates whether the mobile station supports multiple radio frequency bands in E-UTRAN (see 3GPP TS 36.331 [129]) and whether it understands signalling of overlapping E-UTRA frequency bands (see 3GPP TS 44.060 [76]).

Bit
0		The mobile station does not support Multiple Frequency Band Indicators in E-UTRAN
1		The mobile station supports Multiple Frequency Band Indicators in E-UTRAN

DLMC - Non-contiguous intra-band reception (2 bit field)
This field indicates the intra-band non-contiguous reception mode (see 3GPP TS 45.005 [33]) supported by the mobile station in Downlink Multicarrier configurations. The absence of this field indicates that a mobile station does not support intra-band non-contiguous reception. 

Bit
2 1
0 0		Not supported
0 1		Supported in band E-GSM or GSM850
1 0		Supported in band DCS1800 or PCS1900
1 1		Supported in band E-GSM, or GSM850, or DCS1800 or PCS1900

DLMC - Inter-band reception (1 bit field)
This field indicates the inter-band reception mode (see 3GPP TS 45.005 [33]) supported by the mobile station in Downlink Multicarrier configuration. The absence of this field indicates that a mobile station does not support inter-band reception.

Bit
0		Not supported
1		Supported in band combination (E-GSM, DCS1800), or band combination (GSM850, PCS1900). 

DLMC - Maximum Bandwidth (2 bit field)
This field indicates the maximum bandwidth supported by a mobile station. 

Bit
2 1	
0 0		Bandwidth = 5 MHz
0 1		Bandwidth = 10 MHz
1 0		Bandwidth = 15 MHz
1 1		Bandwidth = 20 MHz

DLMC - Maximum Number of Downlink Timeslots (6 bit field)
This field indicates the maximum number of downlink timeslots supported by a mobile station in Downlink Multi Carrier configuration.

Bit
6 5 4 3 2 1
0 0 0 0 0 0 	6 TS supported
0 0 0 0 0 1 	8 TS supported
0 0 0 0 1 0 	10 TS supported
0 0 0 0 1 1 	12 TS supported
…
…
1 1 1 1 0 1  	128 TS supported
1 1 1 1 1 0 	reserved
1 1 1 1 1 1 	reserved

DLMC - Maximum Number of Downlink Carriers (3 bit field)
This field indicates the maximum number of downlink carriers supported by a mobile station in Downlink Multi Carrier configuration.

Bit
3 2 1
0 0 0 	2 carriers supported
0 0 1 	4 carriers supported
0 1 0 	6 carriers supported
0 1 1 	8 carriers supported
1 0 0  	10 carriers supported
1 0 1 	12 carriers supported
1 1 0 	14 carriers supported
1 1 1 	16 carriers supported

Extended TSC Set Capability support (1 bit field)
This field indicates whether the mobile station supports the extended TSC sets when operating in the PS or CS domain (see 3GPP TS 45.002 [32]).

Bit
0		The mobile station does not support Extended TSC sets
1		The mobile station supports Extended TSC sets

Extended EARFCN value range (1 bit field)
This field indicates whether the mobile station supports the extended EARFCN value range in GERAN (see 3GPP TS 44.060 [76]).

Bit
0		The mobile station does not support extended EARFCN value range
1		The mobile station supports extended EARFCN value range

(EC-)PCH monitoring support (2 bit field)
This field indicates if the mobile station is capable of monitoring the PCH channel, the EC-PCH channel or both for paging based reachability.

Bit
2 1
0 0 	PCH supported
0 1 	EC-PCH supported
1 0 	PCH and EC-PCH supported
1 1 	reserved
EC-PCH support also indicates EC-GSM-IoT capability, see 3GPP TS 43.064 [159].


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 24.008 and table 10.5.147/3GPP TS 24.008.
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 24.008: GMM cause information element
Table 10.5.147/3GPP TS 24.008: 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
0
1

IMEI not accepted
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
0
1
1
1
1

No Suitable Cells In Location Area
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
0
0

MAC failure
0
0
0
1
0
1
0
1

Synch failure
0
0
0
1
0
1
1
0

Congestion
0
0
0
1
0
1
1
1

GSM authentication unacceptable
0
0
0
1
1
0
0
1

Not authorized for this CSG
0
0
0
1
1
1
0
0

SMS provided via GPRS in this routing area
0
0
1
0
1
0
0
0

No PDP context activated
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 GPRS coverage area.
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 24.008 and table 10.5.148/3GPP TS 24.008.

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 24.008: Routing area identification information element
Table 10.5.148/3GPP TS 24.008: 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 register on 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/USIM 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.15a	Routing area identification 2
The purpose of the Routing area identification 2 information element is to provide an unambiguous identification of routing areas within the GPRS coverage area.
The Routing area identification 2 is a type 4 information element with a length of 8 octets.
The Routing area identification 2 information element is coded as shown in figure 10.5.130a/3GPP TS 24.008 and table 10.5.148a/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Routing area identification 2 IEI
octet 1
Length of routing area identification 2 contents
octet 2

octet 3
Routing area identification 2 value


octet 8

Figure 10.5.130a/3GPP TS 24.008: Routing area identification 2 information element
Table 10.5.148a/3GPP TS 24.008: Routing area identification 2 information element
Routing area identification 2 value (octet 3 to 8)

The routing area identification 2 value is coded as octet 2 to 7 of the Routing area identification information element.


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 24.008 and table 10.5.149/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Update result
IEI
FOP
Update result
value
octet 1

Figure 10.5.131/3GPP TS 24.008: Update result information element
Table 10.5.149/3GPP TS 24.008: 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
1
0
0

RA updated and ISR activated
1
0
1

combined RA/LA updated and ISR activated

All other values are reserved.

Follow-on proceed (octet 1, bit 4)
Bit
4




0



Follow-on proceed
1



No follow-on proceed

Follow-on proceed is applicable only in Iu mode. This indication shall be ignored if received in A/Gb mode.

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 24.008 and table 10.5.150/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Update type
IEI
FOR
Update type
value
octet 1

Figure 10.5.132/3GPP TS 24.008: Update type information element
Table 10.5.150/3GPP TS 24.008: Update type information element
Update type value (octet 1, bit 1 to 3)

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.

Follow-on request (octet 1, bit 4)
Bit

4




0



No follow-on request pending
1



Follow-on request pending

Follow-on request pending is applicable only in Iu mode.


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.134/3GPP TS 24.008 and table 10.5.152/3GPP TS 24.008.

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 24.008: A&C reference number information element 
Table 10.5.152/3GPP TS 24.008: A&C reference number information element

A&C reference number value (octet 1)

Unformatted 4 bit field


10.5.5.20	Service type
The purpose of the service type information element is to specify the purpose of the Service request procedure.
The service type is a type 1 information element.
The service type information element is coded as shown in figure 10.5.135/3GPP TS 24.008 and table 10.5.153a/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Service type
IEI
0
spare
Service type
octet 1

Figure 10.5.135/3GPP TS 24.008: Service type information element
Table 10.5.153a/3GPP TS 24.008: Service type information element

Service type value    (octet 1)

Bits
3
2
1


0
0
0

Signalling
0
0
1

Data
0
1
0

Paging Response
0
1
1

MBMS Multicast Service Reception 
1
0
0

MBMS Broadcast Service Reception

All other values are reserved.


10.5.5.21	Cell Notification
The purpose of the Cell Notification information element is to indicate that the Cell Notification is supported by the network and shall be then used by MS. 
The Cell Notification information element is coded as shown in figure 10.5.135a/3GPP TS 24.008.
The Cell Notification is a type 2 information element.

8
7
6
5
4
3
2
1

Cell Notification IEI
octet 1

Figure 10.5.135a/3GPP TS 24.008: Cell Notification information element

10.5.5.22	PS LCS Capability
The purpose of the PS LCS Capability element is to indicate the positioning methods and additional positioning capabilities supported by the MS for the provision of location services (LCS) via the PS domain in Gb-mode.
The PS LCS Capability is a type 4 information element with a length of 3 octets.
The PS LCS Capability element is coded as shown in figure 10.5.135b/3GPP TS 24.008 and table 10.5.153b/3GPP TS 24.008.

8
7
6
5
4
3
2
1

PS LCS Capability IEI
octet 1
Length of PS LCS Capability contents
octet 2
Spare
APC
OTD-A
OTD-B
GPS-A
GPS-B
GPS-C
octet 3
0
0








Figure 10.5.135b/3GPP TS 24.008: PS LCS Capability information element
Table 10.5.153b/3GPP TS 24.008 PS LCS Capability information element

PS LCS Capability value (octet 3, bit 1 to 5)

APC (Additional Positioning Capabilities)
Bit 6
	0	Additional Positioning Capabilities which can be retrieved by RRLP are not supported 
	1	Additional Positioning Capabilities which can be retrieved by RRLP are supported 

OTD-A (MS assisted E-OTD)
Bit 5
	0	MS assisted E-OTD not supported
	1	MS assisted E-OTD supported

OTD-B (MS based E-OTD)
Bit 4
	0	MS based E-OTD not supported
	1	MS based E-OTD supported

GPS-A (MS assisted GPS)
Bit 3
	0	MS assisted GPS not supported
	1	MS assisted GPS supported

GPS-B (MS based GPS)
Bit 2
	0	MS based GPS not supported
	1	MS based GPS supported

GPS-C (Conventional GPS)
Bit 1
	0	Conventional GPS not supported 
	1	Conventional GPS supported 

Octet 3, bits 8, 7, 6 are spare and shall be coded all 0.


10.5.5.23	Network feature support
The purpose of the network feature support information element is to indicate whether certain features are supported by the network. If this IE is not included then the respective features are not supported.
The network feature support is a type 1 information element.
The network feature support information element is coded as shown in figure 10.5.135c/3GPP TS 24.008 and table 10.5.153c/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Network feature support
IEI
LCS-MOLR
MBMS
IMS VoPS
EMC BS
octet 1

Figure 10.5.135c/3GPP TS 24.008: Network feature support information element
Table 10.5.153c/3GPP TS 24.008: Network feature support information element
Network feature support value (octet 1, bit 1 to 4)

LCS-MOLR (1 bit field)

Bit
4




0



LCS-MOLR via PS domain not supported
1



LCS-MOLR via PS domain supported

MBMS (1 bit field)

Bit
3




0



MBMS not supported
1



MBMS supported

IMS voice over PS session indicator (IMS VoPS) (1 bit field)

Bit
2




0



IMS voice over PS session in Iu mode and A/Gb mode not supported
1



IMS voice over PS session supported in Iu mode, but not supported in A/Gb mode

Emergency bearer services indicator (EMC BS) (1 bit field)

Bit
1




0



Emergency bearer services in Iu mode and A/Gb mode not supported
1



Emergency bearer services supported in Iu mode, but not supported in A/Gb mode


10.5.5.23A	Additional network feature support
The purpose of the Additional network feature support information element is to indicate whether certain features are supported by the network.
The Additional network feature support is a type 4 information element with a length of 3 octets.
The Additional network feature support information element is coded as shown in figure 10.5.5.23A/3GPP TS 24.008 and table 10.5.5.23A/3GPP TS 24.008.
8
7
6
5
4
3
2
1

Additional network feature support IEI
octet 1
Length of additional network feature support contents
octet 2
0
0
0
0
0
0
0
GPRS-SMS

octet 3
Spare



Figure 10.5.5.23A: Additional network feature support information element
Table 10.5.5.23A: Additional network feature support information element
GPRS-SMS supported (GPRS-SMS) (octet 3, bit 1)

Bit
1




0



SMS via GPRS supported
1



SMS via GPRS not supported

Bits 2 to 8 of octet 3 are spare and shall be coded all zero.


10.5.5.24	Inter RAT information container
The purpose of the Inter RAT information container information element is to supply the network with Iu mode related information that needs to be transferred at PS inter-system handover to Iu mode (see 3GPP TS 43.129 [113]).
The Inter RAT information container information element is coded as shown in figure 10.5.150/3GPP TS 24.008.
The Inter RAT information container information element is a type 4 information element with a minimum length of 3 octets and a maximum length of 250 octets.
The Inter RAT information container contains:
-	predefined configuration status information; 
-	mobile station security information to be used after handover to Iu mode, which includes the START-PS value that is stored by the MS at handover from Iu mode to A/Gb mode (see 3GPP TS 33.102 [5a]); and/or
-	the specific Iu mode radio capabilities of the mobile station, i.e. UE RAC (see 3GPP TS 25.331 [23c]).

8
7
6
5
4
3
2
1

Inter RAT information container IEI
octet 1
Length of inter RAT information container
octet 2
Inter RAT information container value part
octet 3-250

Figure 10.5.150/3GPP TS 24.008: Inter RAT information container information element
The value part of the Inter RAT information container information element is the INTER RAT HANDOVER INFO as defined in 3GPP TS 25.331 [23c]. If this field includes padding bits, they are defined in 3GPP TS 25.331 [23c].
10.5.5.25	Requested MS information
The purpose of the Requested MS information information element is to indicate whether certain feature-related information is requested from the MS by the network. If this IE is not included then no information is requested.
The Requested MS information information element is coded as shown in figure 10.5.151/3GPP TS 24.008 and table 10.5.166/3GPP TS 24.008.
The Requested MS information is a type 1 information element.

8
7
6
5
4
3
2
1

Requested MS information
IEI 
I-RAT
I-RAT2
0           0             Spare
octet 1

Figure 10.5.151/3GPP TS 24.008: Requested MS information information element
Table 10.5.166/3GPP TS 24.008: Requested MS information information element
Requested MS information value (octet 1, bit 1 to 4)

I-RAT (1 bit field)

Bit
4




0



Inter RAT information container IE not requested
1



Inter RAT information container IE requested

I-RAT2 (1 bit field)
Bit
 3                   
 0                    See NOTE.

NOTE:	The value '1' was allocated in a previous version of the protocol and shall not be used. The behaviour of a mobile station receiving the Requested MS information IE with the I-RAT2 field set to the value '1' is not specified. Network implementations following previous versions of the specification can set the I-RAT2 bit to request E-UTRAN Inter RAT information container IE, but an MS implementation following this version of the specification does not provide this information in the response and the procedure where the request is included can fail.

10.5.5.26	UE network capability
See subclause 9.9.3.34 in 3GPP TS 24.301 [120].
10.5.5.27	E-UTRAN inter RAT information container
The purpose of the E-UTRAN inter RAT information container information element is to supply the network with E-UTRAN related information that needs to be transferred at Inter-RAT PS handover to E-UTRAN (see 3GPP TS 23.401 [122]).
The E-UTRAN inter RAT information container information element is coded as shown in figure 10.5.151/3GPP TS 24.008.
The E-UTRAN inter RAT information container information element is a type 4 information element with a minimum length of 3 octets and an upper length limit of 257 octets.

8
7
6
5
4
3
2
1

E-UTRAN Inter RAT information container IEI
octet 1
Length of E-UTRAN Inter RAT information container
octet 2
E-UTRAN Inter RAT information container value part
octet 3-257

Figure 10.5.151/3GPP TS 24.008: E-UTRAN inter RAT information container information element
The value part of the E-UTRAN inter RAT information container information element is formatted and coded according to the UE-EUTRA-Capability IE defined in 3GPP TS 36.331 [129].
10.5.5.28	Voice domain preference and UE's usage setting
The purpose of the Voice domain preference and UE's usage setting information element is to provide the network with the UE's usage setting and the voice domain preference for WB-S1 mode. The network uses the UE's usage setting and the voice domain preference for E-UTRAN (see 3GPP TS 24.167 [13B]) only to select the RFSP index.
The UE's usage setting bit indicates the value configured on the ME as defined in 3GPP TS 23.221 [131].
The voice domain preference for E-UTRAN bit indicates the value configured on the ME of the Voice domain preference for E-UTRAN as defined in 3GPP TS 24.167 [134].
The Voice domain preference and UE's usage setting information element is coded as shown in figure 10.5.151A/3GPP TS 24.008 and table 10.5.166A/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Voice domain preference and UE's usage setting IEI
octet 1
Length of Voice domain preference and UE's usage setting contents
octet 2
0
Spare
0
Spare
0
Spare
0
Spare
0
Spare
UE's
usage setting
Voice domain preference for E-UTRAN
octet 3

Figure 10.5.151A/3GPP TS 24.008: Voice domain preference and UE's usage setting information element
Table 10.5.166A/3GPP TS 24.008: Voice domain preference and UE's usage setting information element
Voice domain preference and UE's usage setting value (octet 3, bit 1 to 3)

UE's usage setting (1 bit field)

Bit
3




0



Voice centric
1



Data centric

Voice domain preference for E-UTRAN (2 bit field)

Bit
2
1



0
0


CS Voice only
0
1


IMS PS Voice only
1
0


CS voice preferred, IMS PS Voice as secondary
1
1


IMS PS voice preferred, CS Voice as secondary

MS not supporting IMS voice shall indicate "CS Voice only".
MS only supporting IMS voice shall indicate "IMS PS Voice only".

10.5.5.29	P-TMSI type
The purpose of the P-TMSI type information element is to indicate whether the P-TMSI included in the same message in an information element of type mobile identity, or the P-TMSI used by the MS to derive a foreign TLLI (see subclause 4.7.1.4.1) represents a native P-TMSI or a mapped P-TMSI.
The P-TMSI type information element information element is coded as shown in figure 10.5.5.29.1 and table 10.5.5.29.1.
The P-TMSI type is a type 1 information element.

8
7
6
5
4
3
2
1

P-TMSI type IEI
0
0
0
P-TMSI type
octet 1

spare



Figure 10.5.5.29.1: P-TMSI type information element
Table 10.5.5.29.1: P-TMSI type information element
P-TMSI type (octet 1)
Bit
1




0



Native P-TMSI
1



Mapped P-TMSI

Bits 2 to 4 of octet 1 are spare and shall be coded as zero.


10.5.5.30	Location Area Identification 2
The purpose of the Location Area Identification 2 information element is to provide an unambiguous identification of location areas within the area covered by the 3GPP system.
The Location Area Identification 2 information element is coded as shown in figure 10.5.5.30/3GPP TS 24.008 and table 10.5.5.30/3GPP TS 24.008.
The Location Area Identification 2 is a type 4 information element with 7 octets length.
8
7
6
5
4
3
2
1

Location Area Identification 2 IEI
octet 1
Length of Location Area Identification 2 IEI
octet 2

octet 3
Location Area Identification 2 value


octet 7

Figure 10.5.5.30/3GPP TS 24.008: Location Area Identification 2 information element
Table 10.5.5.30/3GPP TS 24.008: Location Area Identification 2 information element
Location Area Identification 2 value (octet 3 to 7)

The Location Area Identification 2 value is coded as octet 2 to 6 of the Location Area Identification information element.


10.5.5.31	Network resource identifier container
The purpose of the Network resource identifier container information element is to provide a part of the allocated TMSI that the network will use to determine the actual NRI.
The Network resource identifier container is a type 4 information element with a length of 4 octets.
The Network resource identifier container information element is coded as shown in figure 10.5.5.31/3GPP TS 24.008 and table 10.5.5.31/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Network resource identifier container IEI
octet 1
Length of Network resource identifier container contents 
octet 2
NRI container value
octet 3
NRI container value
spare
0
0
0
0
0
0

octet 4

Figure 10.5.5.31/3GPP TS 24.008 Network resource identifier container information element
Table 10.5.5.31/3GPP TS 24.008: Network resource identifier container information element

NRI container value (octet 3 and bit 7-8 of octet 4)
The NRI container value consists of 10 bits which correspond to bits 23 to 14 of the valid TMSI.

NRI container value shall start with bit 8 of octet 3, which corresponds to bit 23 of TMSI. Bit 7 of octet 4 corresponds to TMSI bit 14.

Bits 6, 5, 4, 3, 2, and 1 in octet 4 are spare and shall be set to zero.

10.5.5.32	Extended DRX parameters
The purpose of the Extended DRX parameters information element is to indicate that the MS wants to use eDRX and for the network to indicate the Paging Time Window length value and the extended DRX cycle value to be used for eDRX.
The Extended DRX parameters is a type 4 information element with a length of 3 octets.
The Extended DRX parameters information element is coded as shown in figure 10.5.5.32/3GPP TS 24.008 and table 10.5.5.32/3GPP TS 24.008.
8
7
6
5
4
3
2
1

Extended DRX parameters IEI
octet 1
Length of Extended DRX parameters
octet 2
Paging Time Window
eDRX value
octet 3

Figure 10.5.5.32/3GPP TS 24.008: Extended DRX parameters information element

Table 10.5.5.32/3GPP TS 24.008: Extended DRX parameters information element
Paging Time Window (PTW), octet 3 (bit 8 to 5)
The field contains a PTW value. The PTW value can be applied for Iu mode, WB-S1 mode and NB-S1 modeas specified below.

Iu mode
The field contains the PTW value in seconds for Iu mode.The PTW value is used as specified in 3GPP TS 23.682 [133a].The PTW value is derived as follows:


bit
8
7
6
5
Paging Time Window length
0
0
0
0
0 seconds (PTW not used)
0
0
0
1
1 second
0
0
1
0
2 seconds
0
0
1
1
3 seconds
0
1
0
0
4 seconds
0
1
0
1
5 seconds
0
1
1
0
6 seconds
0
1
1
1
7 seconds
1
0
0
0
8 seconds
1
0
0
1
9 seconds
1
0
1
0
10 seconds
1
0
1
1
12 seconds
1
1
0
0
14 seconds
1
1
0
1
16 seconds
1
1
1
0
18 seconds
1
1
1
1
20 seconds

WB-S1 mode
The field contains the PTW value in seconds for WB-S1 mode.The PTW value is used as specified in 3GPP TS 23.682 [133a].The PTW value is derived as follows:

bit
8
7
6
5
Paging Time Window length
0
0
0
0
1,28 seconds
0
0
0
1
2,56 seconds
0
0
1
0
3,84 seconds
0
0
1
1
5,12 seconds
0
1
0
0
6,4 seconds
0
1
0
1
7,68 seconds
0
1
1
0
8,96 seconds
0
1
1
1
10,24 seconds
1
0
0
0
11,52 seconds
1
0
0
1
12,8 seconds
1
0
1
0
14,08 seconds
1
0
1
1
15,36 seconds
1
1
0
0
16,64 seconds
1
1
0
1
17,92 seconds
1
1
1
0
19,20 seconds
1
1
1
1
20,48 seconds

NB-S1 mode
The field contains the PTW value in seconds for NB-S1 mode.The PTW value is used as specified in 3GPP TS 23.682 [133a].The PTW value is derived as follows:

bit
8
7
6
5
Paging Time Window length
0
0
0
0
2,56 seconds
0
0
0
1
5,12 seconds
0
0
1
0
7,68 seconds
0
0
1
1
10,24 seconds
0
1
0
0
12,8 seconds
0
1
0
1
15,36 seconds
0
1
1
0
17,92 seconds
0
1
1
1
20,48 seconds
1
0
0
0
23,04 seconds
1
0
0
1
25,6 seconds
1
0
1
0
28,16 seconds
1
0
1
1
30,72 seconds
1
1
0
0
33,28 seconds
1
1
0
1
35,84 seconds
1
1
1
0
38,4 seconds
1
1
1
1
40,96 seconds

eDRX value, octet 3 (bit 4 to 1)
The octet contains the eDRX value field. The parameter values are applied for A/Gb mode, Iu mode or S1 mode according to the tables below.

A/Gb mode
The field contains the eDRX value for A/Gb mode. The GERAN eDRX cycle length duration and Number of 51-MF per GERAN eDRX cycle values are derived from the eDRX value as follows:

bit
4
3
2
1
GERAN eDRX cycle length duration
Number of 51-MF per GERAN eDRX cycle
0
0
0
0
~1,88 seconds (NOTE 1, NOTE 2)
8
0
0
0
1
~3,76 seconds (NOTE 1, NOTE 2)
16
0
0
1
0
~7,53 seconds (NOTE 1, NOTE 2)
32
0
0
1
1
12,24 seconds (NOTE 2)
52
0
1
0
0
24,48 seconds (NOTE 2)
104
0
1
0
1
48,96 seconds (NOTE 2)
208
0
1
1
0
97,92 seconds (NOTE 2)
416
0
1
1
1
195,84 seconds (NOTE 2)
832
1
0
0
0
391,68 seconds (NOTE 2)
1664
1
0
0
1
783,36 seconds (NOTE 2)
3328
1
0
1
0
1566,72 seconds (NOTE 2)
6656
1
0
1
1
3133,44 seconds (NOTE 2)
13312

All other values shall be interpreted as 0000 by this version of the protocol.

NOTE 1:	The listed values are rounded.

NOTE 2:	The value in seconds can be calculated with the formula ((3,06 / 13) * (Number of 51-MF)). See 3GPP TS 45.001 [157], subclause 5.1.

Iu mode
The field contains the eDRX value for Iu mode. The UTRAN eDRX cycle length duration value is derived from the eDRX value as follows:

bit
4
3
2
1
UTRAN eDRX cycle length duration
0
0
0
0
10,24 seconds
0
0
0
1
20,48 seconds
0
0
1
0
40,96 seconds
0
0
1
1
81,92 seconds
0
1
0
0
163,84 seconds
0
1
0
1
327,68 seconds
0
1
1
0
655,36 seconds
0
1
1
1
1310,72 seconds
1
0
0
0
1966,08 seconds
1
0
0
1
2621,44 seconds

All other values shall be interpreted as 0000 by this version of the protocol.

S1 mode
The field contains the eDRX value for S1 mode. The E-UTRAN eDRX cycle length duration value and the eDRX cycle parameter 'TeDRX' as defined in 3GPP TS 36.304 [121] are derived from the eDRX value as follows:

bit
4
3
2
1
E-UTRAN eDRX cycle length duration
eDRX cycle parameter 'TeDRX'
0
0
0
0
5,12 seconds (NOTE 4)
NOTE 3
0
0
0
1
10,24 seconds (NOTE 4)
20
0
0
1
0
20,48 seconds
21
0
0
1
1
40,96 seconds
22
0
1
0
0
61,44 seconds (NOTE 5)
6
0
1
0
1
81,92 seconds
23
0
1
1
0
102,4 seconds (NOTE 5)
10
0
1
1
1
122,88 seconds (NOTE 5)
12
1
0
0
0
143,36 seconds (NOTE 5)
14
1
0
0
1
163,84 seconds
24
1
0
1
0
327,68 seconds
25
1
0
1
1
655,36 seconds
26
1
1
0
0
1310,72 seconds
27
1
1
0
1
2621,44 seconds
28
1
1
1
0
5242,88 seconds (NOTE 6)
29
1
1
1
1
10485,76 seconds (NOTE 6)
210

All other values shall be interpreted as 0000 by this version of the protocol.

NOTE 3:	For E-UTRAN eDRX cycle length duration of 5,12 seconds the eDRX cycle parameter 'TeDRX' is not used as a different algorithm compared to the other values is applied. See 3GPP TS 36.304 [121] for details.

NOTE 4:	The value is applicable only in WB-S1 mode. If received in NB-S1 mode it is interpreted as if the Extended DRX parameters IE were not included in the message by this version of the protocol.

NOTE 5:	The value is applicable only in WB-S1 mode. If received in NB-S1 mode it is interpreted as 0010 by this version of the protocol.

NOTE 6:	The value is applicable only in NB-S1 mode. If received in WB-S1 mode it is interpreted as 1101 by this version of the protocol.

10.5.5.33	Message authentication code
The purpose of the Message authentication code information element is to protect the integrity of a NAS message.
The Message authentication code is a type 3 information element with 6 octets length.
The Message authentication code information element is coded as shown in figure 10.5.5.33-1/3GPP TS 24.008 and table 10.5.5.33-1/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Message authentication code IEI
octet 1
Length of message authentication code contents
octet 2

Message authentication code value

octet 3

octet 6

Figure 10.5.5.33-1/3GPP TS 24.008: Message authentication code information element
Table 10.5.5.33-1/3GPP TS 24.008: Message authentication code information element
Message authentication code value (octet 3 to 6)

This field contains the 32 bit message authentication code calculated for GMM integrity protection. Bit 1 of octet 3 contains the most significant bit, and bit 8 of octet 6 the least significant bit of these 4 octets.


10.5.5.34	User Plane integrity indicator
The purpose of the User Plane integrity indicator information element is to indicate to the MS that it shall integrity protect user plane data in LLC layer.
The User Plane integrity indicator is allocated by the network and sent with the ATTACH ACCEPT message or ROUTING AREA UPDATE ACCEPT message to the mobile station.
The User Plane integrity indicator information element is coded as shown in figure 10.5.5.34-1/3GPP TS 24.008 and table 10.5.5.34-1/3GPP TS 24.008.
In A/Gb mode, in the case when a UMTS security context is established and if the MS supports integrity protection, , the purpose of the User Plane integrity indicator information element is to request the MS to start integrity protection of user plane data in LLC layer. 
The User Plane integrity indicator is a type 1 information element.

8
7
6
5
4
3
2
1

User Plane
Integrity Indicator
IEI
0
spare
0
spare
0
spare
Integrity indicator
octet 1

Figure 10.5.5.34-1/3GPP TS 24.008 User Plane integrity indicator information element
Table 10.5.5.34-1/3GPP TS 24.008: User Plane integrity indicator information element
User Plane integrity indicator (octet 1)

Bits
1







0


MS shall disable integrity protection of user plane data in LLC layer
1


MS shall enable integrity protection of user plane data in LLC layer




Bits 2 to 4 are spare and shall be set to "0".

10.5.6	Session management information elements
10.5.6.1	Access point name
The purpose of the Access point name information element is to identify the packet data network to which the GPRS user wishes to connect and to notify the access point of the packet data network that wishes to connect to the MS.
The Access point name is a label or a fully qualified domain name according to DNS naming conventions (see 3GPP TS 23.003 [10]).
The Access point name is a type 4 information element with a minimum length of 3 octets and a maximum length of 102 octets.
The Access point name information element is coded as shown in figure 10.5.152/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Access point name IEI
octet 1
Length of access point name contents
octet 2
Access point name value
octet 3



octet n*

Figure 10.5.152/3GPP TS 24.008: Access point name information element
The value part is defined in 3GPP TS 23.003 [10].
10.5.6.2	Network service access point identifier
The purpose of the Network service access point identifier information element is to identify the service access point that is used for the GPRS data transfer at layer 3.
The Network service access point identifier is a type 3 information element with a length of 2 octets.
The value part of a Network service access point identifier information element is coded as shown in figure 10.5.153/3GPP TS 24.008 and table 10.5.167/3GPP TS 24.008.

8
7
6
5
4
3
2
1

NSAPI IEI
octet 1
0
0
0
0
NSAPI
octet 2
Spare
value


Figure 10.5.153/3GPP TS 24.008: Network service access point identifier information element
Table 10.5.167/3GPP TS 24.008: Network service access point identifier information element

NSAPI value (octet 2)

Bits
4
3
2
1

0
0
0
0
reserved
0
0
0
1
reserved
0
0
1
0
reserved
0
0
1
1
reserved
0
1
0
0
reserved
0
1
0
1
NSAPI 5
0
1
1
0
NSAPI 6
0
1
1
1
NSAPI 7
1
0
0
0
NSAPI 8
1
0
0
1
NSAPI 9
1
0
1
0
NSAPI 10
1
0
1
1
NSAPI 11
1
1
0
0
NSAPI 12
1
1
0
1
NSAPI 13
1
1
1
0
NSAPI 14
1
1
1
1
NSAPI 15


10.5.6.3	Protocol configuration options
10.5.6.3.1	General
The purpose of the protocol configuration options information element is to:
-	transfer external network protocol options associated with a PDP context activation, and
-	transfer additional (protocol) data (e.g. configuration parameters, error codes or messages/events) associated with an external protocol or an application.
The protocol configuration options is a type 4 information element with a minimum length of 3 octets and a maximum length of 253 octets. 
The protocol configuration options information element is coded as shown in figure 10.5.136/3GPP TS 24.008 and table 10.5.154/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Protocol configuration options IEI
octet 1
Length of protocol config. options contents
octet 2
1
ext
0	0	0	0
Spare
Configuration
protocol
octet 3
Protocol ID 1

octet 4
octet 5
Length of protocol ID 1 contents
octet 6

Protocol ID 1 contents
octet 7

octet m
Protocol ID 2

octet m+1
octet m+2
Length of protocol ID 2 contents
octet m+3

Protocol ID 2 contents
octet m+4

octet n

. . .
octet n+1

octet u
Protocol ID n-1

octet u+1
octet u+2
Length of protocol ID n-1 contents
octet u+3

Protocol ID n-1 contents
octet u+4

octet v
Protocol ID n

octet v+1
octet v+2
Length of protocol ID n contents
octet v+3

Protocol ID n contents
octet v+4

octet w
Container ID 1
octet w+1
octet w+2
Length of container ID 1 contents
octet w+3
Container ID 1 contents
octet w+4

octet x

. . .
octet x+1

octet y
Container ID n
octet y+1
octet y+2
Length of container ID n contents
octet y+3
Container ID n contents
octet y+4

octet z

Figure 10.5.136/3GPP TS 24.008: Protocol configuration options information element 
Table 10.5.154/3GPP TS 24.008: Protocol configuration options information element
Configuration protocol (octet 3)
Bits
3 2 1
0 0 0	PPP for use with IP PDP type or IP PDN type (see 3GPP TS 24.301 [120])

All other values are interpreted as PPP in this version of the protocol.
After octet 3, i.e. from octet 4 to octet z, two logical lists are defined:
-	the Configuration protocol options list (octets 4 to w), and
-	the Additional parameters list (octets w+1 to z).
Configuration protocol options list (octets 4 to w)
The configuration protocol options list contains a variable number of logical units, they may occur in an arbitrary order within the configuration protocol options list.
Each unit is of variable length and consists of a:
-	protocol identifier (2 octets);
-	the length of the protocol identifier contents of the unit (1 octet); and
-	the protocol identifier contents itself (n octets).
The protocol identifier field contains the hexadecimal coding of the configuration protocol identifier. Bit 8 of the first octet of the protocol identifier field contains the most significant bit and bit 1 of the second octet of the protocol identifier field contains the least significant bit.
If the configuration protocol options list contains a protocol identifier that is not supported by the receiving entity the corresponding unit shall be ignored.
The length of the protocol identifier contents field contains the binary coded representation of the length of the protocol identifier contents field of a unit. The first bit in transmission order is the most significant bit.
The protocol identifier contents field of each unit contains information specific to the configuration protocol specified by the protocol identifier.
At least the following protocol identifiers (as defined in RFC 3232 [103]) shall be supported in this version of the protocol:
-	C021H (LCP);
-	C023H (PAP);
-	C223H (CHAP); and
-	8021H (IPCP).
The support of other protocol identifiers is implementation dependent and outside the scope of the present document.
The protocol identifier contents field of each unit corresponds to a “Packet” as defined in RFC 1661 [102] that is stripped off the “Protocol” and the “Padding” octets.
The detailed coding of the protocol identifier contents field is specified in the RFC that is associated with the protocol identifier of that unit.
Additional parameters list (octets w+1 to z)
The additional parameters list is included when special parameters and/or requests (associated with a PDP context) need to be transferred between the MS and the network. These parameters and/or requests are not related to a specific configuration protocol (e.g. PPP), and therefore are not encoded as the "Packets" contained in the configuration protocol options list.
The additional parameters list contains a list of special parameters, each one in a separate container. The type of the parameter carried in a container is identified by a specific container identifier. In this version of the protocol, the following container identifiers are specified:
MS to network direction:
-	0001H (P-CSCF IPv6 Address Request);
-	0002H (IM CN Subsystem Signaling Flag);
-	0003H (DNS Server IPv6 Address Request); 
-	0004H (Not Supported);
-	0005H (MS Support of Network Requested Bearer Control indicator);
-	0006H (Reserved); 
-	0007H (DSMIPv6 Home Agent Address Request);
-	0008H (DSMIPv6 Home Network Prefix Request);
-	0009H (DSMIPv6 IPv4 Home Agent Address Request);
-	000AH (IP address allocation via NAS signalling);
-	000BH (IPv4 address allocation via DHCPv4);
-	000CH (P-CSCF IPv4 Address Request);
-	000DH (DNS Server IPv4 Address Request);
-	000EH (MSISDN Request);
-	000FH (IFOM-Support-Request);
-	0010H (IPv4 Link MTU Request);
-	0011H (MS support of Local address in TFT indicator);
-	0012H (P-CSCF Re-selection support);
-	0013H (NBIFOM request indicator);
-	0014H (NBIFOM mode);
-	0015H (Non-IP Link MTU Request);
-	0016H (APN rate control support indicator); and
-	FF00H to FFFFH reserved for operator specific use.

Network to MS direction:
-	0001H (P-CSCF IPv6 Address);
-	0002H (IM CN Subsystem Signaling Flag);
-	0003H (DNS Server IPv6 Address);
-	0004H (Policy Control rejection code);
-	0005H (Selected Bearer Control Mode;
-	0006H (Reserved);
-	0007H (DSMIPv6 Home Agent Address) ;
-	0008H (DSMIPv6 Home Network Prefix);
-	0009H (DSMIPv6 IPv4 Home Agent Address);
-	000AH (Reserved);
-	000BH (Reserved); 
-	000CH (P-CSCF IPv4 Address);
-	000DH (DNS Server IPv4 Address);
-	000EH (MSISDN);
-	000FH (IFOM-Support);
-	0010H (IPv4 Link MTU);
-	0011H (Network support of Local address in TFT indicator);
-	0012H (Reserved);
-	0013H (NBIFOM accepted indicator);
-	0014H (NBIFOM mode);
-	0015H (Non-IP Link MTU);
-	0016H (APN rate control parameters); and
-	FF00H to FFFFH reserved for operator specific use.

If the additional parameters list contains a container identifier that is not supported by the receiving entity the corresponding unit shall be ignored.
The container identifier field is encoded as the protocol identifier field and the length of container identifier contents field is encoded as the length of the protocol identifier contents field.
When the container identifier indicates P-CSCF IPv6 Address Request, DNS Server IPv6 Address Request, or MSISDN Request, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates IM CN Subsystem Signaling Flag (see 3GPP TS 24.229 [95]), the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. In Network to MS direction this information may be used by the MS to indicate to the user whether the requested dedicated signalling PDP context was successfully established.
When the container identifier indicates P-CSCF IPv6 Address, the container identifier contents field contains one IPv6 address corresponding to a P-CSCF address (see 3GPP TS 24.229 [95]). This IPv6 address is encoded as a 128-bit address according to IETF RFC 4291 [99]. When there is a need to include more than one P-CSCF IPv6 address, then more logical units with the container identifier indicating P-CSCF IPv6 Address are used. If more than 3 instances of the P‑CSCF IPv6 Address logical unit are received by the MS then the MS may ignore all but the first 3 instances of the P‑CSCF IPv6 Address logical unit received.
When the container identifier indicates DNS Server IPv6 Address, the container identifier contents field contains one IPv6 DNS server address (see 3GPP TS 27.060 [36a]). This IPv6 address is encoded as a 128-bit address according to IETF RFC 4291 [99]. When there is a need to include more than one DNS Server IPv6 address, then more logical units with the container identifier indicating DNS Server IPv6 Address are used.
When the container identifier indicates Policy Control rejection code, the container identifier contents field contains a Go interface related cause code from the GGSN to the MS (see 3GPP TS 29.207 [100]). The length of container identifier contents indicates a length equal to one. If the container identifier contents field is empty or its actual length is greater than one octect, then it shall be ignored by the receiver.
When the container identifier indicates MS Support of Network Requested Bearer Control indicator, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates Selected Bearer Control Mode, the container identifier contents field contains the selected bearer control mode, where ‘01H’ indicates that ‘MS only’ mode has been selected and ‘02H’ indicates that ‘MS/NW’ mode has been selected. The length of container identifier contents indicates a length equal to one. If the container identifier contents field is empty or its actual length is greater than one octect, then it shall be ignored by the receiver.
When the container identifier indicates DSMIPv6 Home Agent Address Request, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates DSMIPv6 Home Network Prefix Request, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates DSMIPv6 IPv4 Home Agent Address Request, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates DSMIPv6 Home Agent Address, the container identifier contents field contains one IPv6 address corresponding to a DSMIPv6 HA address (see 3GPP TS 24.303 [124] and 3GPP TS 24.327 [125]). This IPv6 address is encoded as a 128-bit address according to IETF RFC 4291 [99]. 
When the container identifier indicates DSMIPv6 Home Network Prefix, the container identifier contents field contains one IPv6 Home Network Prefix (see 3GPP TS 24.303 [124] and 3GPP TS 24.327 [125]). This IPv6 prefix is encoded as an IPv6 address according to IETF RFC 4291 [99] followed by 8 bits which specifies the prefix length.
When the container identifier indicates DSMIPv6 IPv4 Home Agent Address, the container identifier contents field contains one IPv4 address corresponding to a DSMIPv6 IPv4 Home Agent address (see 3GPP TS 24.303 [124] and 3GPP TS 24.327 [125]).
When the container identifier indicates P-CSCF IPv4 Address Request, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates DNS Server IPv4 Address Request, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates P-CSCF IPv4 Address, the container identifier contents field contains one IPv4 address corresponding to the P-CSCF address to be used. When there is a need to include more than one P‑CSCF IPv4 address, then more logical units with the container identifier indicating P‑CSCF IPv4 Address are used. If more than 3 instances of the P‑CSCF IPv4 Address logical unit are received by the MS then the MS may ignore all but the first 3 instances of the P‑CSCF IPv4 Address logical unit received.
When the container identifier indicates DNS Server IPv4 Address, the container identifier contents field contains one IPv4 address corresponding to the DNS server address to be used. When there is a need to include more than one DNS Server IPv4 address, then more logical units with the container identifier indicating DNS Server IPv4 Address are used.
P-CSCF IPv4 Address Request, P-CSCF IPv4 Address, DNS Server IPv4 Address Request and DNS Server IPv4 Address are applicable only in S1-mode.
When the container identifier indicates IP address allocation via NAS signalling, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates IP address allocation via DHCPv4, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates MSISDN, the container identifier contents field contains the MSISDN (see 3GPP TS 23.003 [10]) assigned to the MS. Use of the MSISDN provided is defined in subclause 6.4.
When the container identifier indicates IFOM Support Request (see 3GPP TS 24.303 [124] and 3GPP TS 24.327 [125]), the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates IFOM Support, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This information indicates that the Home Agent supports IFOM.
When the container identifier indicates IPv4 Link MTU Request, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates IPv4 Link MTU, the length of container identifier contents indicates a length equal to two. The container identifier contents field contains the binary coded representation of the IPv4 link MTU size in octets. Bit 8 of the first octet of the container identifier contents field contains the most significant bit and bit 1 of the second octet of the container identifier contents field contains the least significant bit. If the length of container identifier contents is different from two octets, then it shall be ignored by the receiver.
When the container identifier indicates MS support of Local address in TFT, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This information indicates that the MS supports Local address in TFTs.
When the container identifier indicates Network support of Local address in TFT, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This information indicates that the network supports Local address in TFTs.
When the container identifier indicates P-CSCF Re-selection support, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This PCO parameter may be present only if a container with P-CSCF IPv4 Address Request or P-CSCF IPv6 Address Request is present. This information indicates that the UE supports P-CSCF re-selection based on procedures specified in 3GPP TS 24.229 [95] subclauses B.2.2.1C, L.2.2.1C and R.2.2.1C.
When the container identifier indicates NBIFOM request indicator, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This information indicates that the MS requests the NBIFOM usage.
When the container identifier indicates NBIFOM accepted indicator, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This information indicates that the network accepts UE's request of the NBIFOM usage.
When the container identifier indicates NBIFOM mode, the length of container identifier contents indicates a length equal to one. If the length of container identifier contents indicates length different to one, it shall be ignored. The container identifier contents field containing value 00H indicates the UE-initiated NBIFOM mode. The container identifier contents field containing value 01H indicates the network-initiated NBIFOM mode. The container identifier contents field containing a value other than 00H and other than 01H shall be ignored.
When the container identifier indicates Non-IP Link MTU Request, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This information indicates that the MS requests link MTU for "non-IP" PDN connection.
When the container identifier indicates Non-IP Link MTU, the length of container identifier contents indicates a length equal to two. The container identifier contents field contains the binary coded representation of the link MTU size for non-IP PDN connection in octets which is at least 128 octets. Bit 8 of the first octet of the container identifier contents field contains the most significant bit and bit 1 of the second octet of the container identifier contents field contains the least significant bit. If the length of container identifier contents is different from two octets, then it shall be ignored by the receiver.
When the container identifier indicates APN rate control support indicator, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This information indicates that the MS supports APN rate control functionality.
When the container identifier indicates APN rate control parameters, the container identifier contents field contains parameters for APN rate control functionality. The the container contents are coded as described in subclause 10.5.6.3.2.
When the container identifier indicates operator specific use, the Container contents starts with MCC and MNC of the operator providing the relevant application and can be followed by further application specific information. The coding of MCC and MNC is as in octet 2 to 4 of the Location Area Identification information element in subclause 10.5.1.3.
NOTE 1: The additional parameters list and the configuration protocol options list are logically separated since they carry different type of information. The beginning of the additional parameters list is marked by a logical unit, which has an identifier (i.e. the first two octets) equal to a container identifier (i.e. it is not a protocol identifier).

10.5.6.3.2	APN rate control parameters
The purpose of the APN rate control parameters container contents is to indicate the APN rate control parameters.
The APN rate control parameters container contents are coded as shown in figure 10.5.136A/3GPP TS 24.008 and table 10.5.154A/3GPP TS 24.008.
The APN rate control parameters container contents can be 1 octet long, or 4 octets long. If the APN rate control parameters container contents is longer than 4 octets, the 5th octet and later octets are ignored.

8
7
6
5
4
3
2
1

Spare
AER
Uplink time unit
octet 1

Maximum uplink rate
octet 2

octet 4
Figure 10.5.136A/3GPP TS 24.008: APN rate control parameters 
Table 10.5.154A/3GPP TS 24.008: APN rate control parameters 
Additional exception reports (AER) (octet 1)
Bit
4

0
Additional exception reports at maximum rate reached are not allowed
1
Additional exception reports at maximum rate reached are allowed

Uplink time unit (octet 1)
Bit
3
2
1

0
0
0
unrestricted
minute
hour
day
week
0
0
1

0
1
0

0
1
1

1
0
0


All other values shall be interpreted as 000 by this version of the protocol.

Maximum uplink rate (octet 2 to octet 4) is a binary coded representation of the maximum number of messages the UE is restricted to send per time unit. The time unit is indicated in the uplink time unit. If the uplink time unit is set to "unrestricted", the maximum uplink data volume the UE can send is not restricted.



10.5.6.4	Packet data protocol address
The purpose of the packet data protocol address information element is to identify an address associated with a PDP.
The packet data protocol address is a type 4 information element with minimum length of 4 octets and a maximum length of 24 octets.
The packet data protocol address information element is coded as shown in figure 10.5.137/3GPP TS 24.008 and table 10.5.155/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Packet data protocol address IEI
octet 1
Length of PDP address contents
octet 2
0	0	0	0
spare
PDP type organisation
octet 3
PDP type number
octet 4

Address information

octet 5

octet n

Figure 10.5.137/3GPP TS 24.008: Packet data protocol address information element
Table 10.5.155/3GPP TS 24.008: Packet data protocol address information element

Length of PDP address contents (octet 2)

If the value of octet 2 equals 0000 0010, then:
-	No PDP address is included in this information 	element; and
-	If the PDP type is IP, dynamic addressing is 	applicable.
NOTE: For PPP no address is required in this information element.
PDP type organisation (octet 3)
Bits
4 3 2 1
In MS to network direction :
0 0 0 0		ETSI allocated address 
0 0 0 1		IETF allocated address
1 1 1 1		Empty PDP type

All other values are reserved.
In network to MS direction :
0 0 0 0		ETSI allocated address 
0 0 0 1		IETF allocated address
All other values are reserved.
If bits 4,3,2,1 of octet 3 are coded 0 0 0 0
PDP type number value (octet 4)
Bits
8 7 6 5 4 3 2 1 
0 0 0 0 0 0 0 0 Reserved, used in earlier version of this protocol
0 0 0 0 0 0 0 1  PDP-type PPP
All other values are reserved 
in this version of the protocol.
If bits 4,3,2,1 of octet 3 are coded 0 0 0 1
PDP type number value (octet 4)
Bits
8 7 6 5 4 3 2 1 
0 0 1 0 0 0 0 1  IPv4 address
0 1 0 1 0 1 1 1  IPv6 address
1 0 0 0 1 1 0 1  IPv4v6 address
All other values shall be interpreted as IPv4 address
in this version of the protocol.
In MS to network direction:
If bits 4,3,2,1 of octet 3 are coded 1 1 1 1
PDP type number value (octet 4)
bits 8 to 1 are spare and shall be coded all 0.
Octet 3, bits 8, 7, 6, and 5 are spare and shall be coded all 0.

If PDP type number indicates IPv4, the Address information in octet 5 to octet 8 contains the IPv4 address. Bit 8 of octet 5 represents the most significant bit of the IP address and bit 1 of octet 8 the least significant bit.
If PDP type number indicates IPv6, the Address information in octet 5 to octet 20 contains the IPv6 address. Bit 8 of octet 5 represents the most significant bit of the IP address and bit 1 of octet 20 the least significant bit.
If PDP type number indicates IPv4v6:
The Address information in octet 5 to octet 8 contains the IPv4 address. Bit 8 of octet 5 represents the most significant bit of the IP address and bit 1 of octet 8 the least significant bit.
The Address information in octet 9 to octet 24 contains the IPv6 address. Bit 8 of octet 9 represents the most significant bit of the IP address and bit 1 of octet 24 the least significant bit.
If PDP type number indicates IPv4 or IPv4v6 and DHCPv4 is to be used to allocate the IPv4 address, the IPv4 address shall be coded as 0.0.0.0.
10.5.6.5	Quality of service
The purpose of the quality of service information element is to specify the QoS parameters for a PDP context.
The QoS IE is defined to allow backward compatibility to earlier version of Session Management Protocol.
The quality of service is a type 4 information element with a minimum length of 14 octets and a maximum length of 18 octets. The QoS requested by the MS shall be encoded both in the QoS attributes specified in octets 3-5 and in the QoS attributes specified in octets 6-14.
In the MS to network direction and in the network to MS direction the following applies:
-	Octets 15-22 are optional. If octet 15 is included, then octet 16 shall also be included, and octets 17-22may be included.
-	If octet 17 is included, then octet 18 shall also be included and octets 19-22 may be included.
-	If octet 19 is included, then octet 20 shall also be included, and octets 21 and 22 may be included.
-	If octet 21 is included, then octet 22 shall also be included.
-	A QoS IE received without octets 6-22, without octets 14-22, without octets 15-22, without octets 17-22, without octets 19-22 or without octets 21-22 shall be accepted by the receiving entity.
NOTE:	This behavior is required for interworking with entities supporting an earlier version of the protocol, or when the Maximum bit rate for downlink or for downlink and uplink is negotiated to a value lower than 8700 kbps.
The quality of service information element is coded as shown in figure 10.5.138/3GPP TS 24.008 and table 10.5.156/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Quality of service IEI
octet 1
Length of quality of service IE
octet 2
0	0
spare
Delay
class
Reliability
class
octet 3
Peak 
throughput
0
spare
Precedence
class
octet 4
0	0	0
spare
Mean
throughput
octet 5
Traffic Class
Delivery order
Delivery of erroneous SDU
octet 6
Maximum SDU size
octet 7
Maximum bit rate for uplink
octet 8
Maximum bit rate for downlink
octet 9
Residual BER
SDU error ratio
octet 10
Transfer delay
Traffic Handling priority
octet 11

Guaranteed bit rate for uplink
octet 12
Guaranteed bit rate for downlink
octet 13
0	0	0
spare
Signal-ling Indicat-ion
Source Statistics Descriptor
octet 14
Maximum bit rate for downlink (extended)
octet 15
Guaranteed bit rate for downlink (extended)
octet 16
Maximum bit rate for uplink (extended)
octet 17
Guaranteed bit rate for uplink (extended)
octet 18
Maximum bit rate for downlink (extended-2)
octet 19
Guaranteed bit rate for downlink (extended-2)
octet 20
Maximum bit rate for uplink (extended-2)
octet 21
Guaranteed bit rate for uplink (extended-2)
octet 22

Figure 10.5.138/3GPP TS 24.008: Quality of service information element
Table 10.5.156/3GPP TS 24.008: Quality of service information element
Reliability class, octet 3 (see 3GPP TS 23.107 [81])
Bits
3 2 1
In MS to network direction:
0 0 0	Subscribed reliability class
In network to MS direction:
0 0 0	Reserved
In MS to network direction and in network to MS direction:
0 0 1	Unused. If received, it shall be interpreted as '010' (Note)
0 1 0	Unacknowledged GTP; Acknowledged LLC and RLC, Protected data
0 1 1	Unacknowledged GTP and LLC; Acknowledged RLC, Protected data
1 0 0	Unacknowledged GTP, LLC, and RLC, Protected data
1 0 1	Unacknowledged GTP, LLC, and RLC, Unprotected data
1 1 1	Reserved

All other values are interpreted as Unacknowledged GTP and LLC; Acknowledged RLC, Protected data in this version of the protocol.

If network supports EPS, then it should not assign Reliability class value ‘010’.

NOTE: this value was allocated in earlier versions of the protocol.

Delay class, octet 3 (see 3GPP TS 22.060 [73] and 3GPP TS 23.107 [81])
Bits
6 5 4
In MS to network direction:
0 0 0	Subscribed delay class 
In network to MS direction:
0 0 0	Reserved
In MS to network direction and in network to MS direction:
0 0 1	Delay class 1
0 1 0	Delay class 2
0 1 1	Delay class 3
1 0 0	Delay class 4 (best effort)
1 1 1	Reserved


All other values are interpreted as Delay class 4 (best effort) in this version 
of the protocol.
Bit 7 and 8 of octet 3 are spare and shall be coded all 0.
Precedence class, octet 4 (see 3GPP TS 23.107 [81])
Bits
3 2 1
In MS to network direction:
0 0 0	Subscribed precedence
In network to MS direction:
0 0 0	Reserved
In MS to network direction and in network to MS direction:
0 0 1	High priority
0 1 0	Normal priority
0 1 1	Low priority
1 1 1	Reserved


All other values are interpreted as Normal priority in this version of the protocol.

Bit 4 of octet 4 is spare and shall be coded as 0.

Peak throughput, octet 4 (see 3GPP TS 23.107 [81]) 
This field is the binary representation of the Peak Throughput Class (1 to 9). The corresponding peak throughput to each peak throughput class is indicated.
Bits
8 7 6 5
In MS to network direction:
0 0 0 0		Subscribed peak throughput
In network to MS direction:
0 0 0 0		Reserved
In MS to network direction and in network to MS direction:
0 0 0 1		Up to 1 000 octet/s
0 0 1 0		Up to 2 000 octet/s
0 0 1 1		Up to 4 000 octet/s
0 1 0 0		Up to 8 000 octet/s
0 1 0 1		Up to 16 000 octet/s
0 1 1 0		Up to 32 000 octet/s
0 1 1 1		Up to 64 000 octet/s
1 0 0 0		Up to 128 000 octet/s
1 0 0 1		Up to 256 000 octet/s
1 1 1 1		Reserved

All other values are interpreted as Up to 1 000 octet/s in this 
version of the protocol.
Mean throughput, octet 5 (see 3GPP TS 23.107 [81])
This field is the binary representation of the Mean Throughput Class (1 to 18; mean throughput class 30 is reserved and 31 is best effort). The corresponding mean throughput to each mean throughput class is indicated.
Bits
5 4 3 2 1


In MS to network direction:
0 0 0 0 0		Subscribed mean throughput
In network to MS direction:
0 0 0 0 0		Reserved
In MS to network direction and in network to MS direction:
0 0 0 0 1		100 octet/h
0 0 0 1 0		200 octet/h
0 0 0 1 1		500 octet/h
0 0 1 0 0		1 000 octet/h
0 0 1 0 1		2 000 octet/h
0 0 1 1 0		5 000 octet/h
0 0 1 1 1		10 000 octet/h
0 1 0 0 0		20 000 octet/h
0 1 0 0 1		50 000 octet/h
0 1 0 1 0		100 000 octet/h
0 1 0 1 1		200 000 octet/h
0 1 1 0 0		500 000 octet/h
0 1 1 0 1		1 000 000 octet/h
0 1 1 1 0		2 000 000 octet/h
0 1 1 1 1		5 000 000 octet/h
1 0 0 0 0		10 000 000 octet/h
1 0 0 0 1		20 000 000 octet/h
1 0 0 1 0		50 000 000 octet/h
1 1 1 1 0		Reserved
1 1 1 1 1		Best effort
The value Best effort indicates that throughput shall be made available to the MS on a per need and availability basis.
All other values are interpreted as Best effort in this 
version of the protocol.

Bits 8 to 6 of octet 5 are spare and shall be coded all 0.


Delivery of erroneous SDUs, octet 6 (see 3GPP TS 23.107 [81])
Bits
3 2 1
In MS to network direction:
0 0 0		Subscribed delivery of erroneous SDUs
In network to MS direction:
0 0 0		Reserved
In MS to network direction and in network to MS direction:
0 0 1		No detect ('-')
0 1 0		Erroneous SDUs are delivered ('yes')
0 1 1		Erroneous SDUs are not delivered ('no')
1 1 1		Reserved

 
The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol.

The MS shall consider all other values as reserved.

Delivery order, octet 6 (see 3GPP TS 23.107 [81])
Bits
5 4 3
In MS to network direction:
0 0		Subscribed delivery order
In network to MS direction:
0 0		Reserved
In MS to network direction and in network to MS direction:
0 1		With delivery order ('yes')
1 0		Without delivery order ('no')
1 1		Reserved




Traffic class, octet 6 (see 3GPP TS 23.107 [81])
Bits
8 7 6
In MS to network direction:
0 0 0		Subscribed traffic class
In network to MS direction:
0 0 0		Reserved
In MS to network direction and in network to MS direction:
0 0 1		Conversational class
0 1 0		Streaming class
0 1 1		Interactive class
1 0 0		Background class
1 1 1		Reserved

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol.


The MS shall consider all other values as reserved.

Maximum SDU size, octet 7 (see 3GPP TS 23.107 [81])
In MS to network direction:
0 0 0 0 0 0 0 0		Subscribed maximum SDU size
1 1 1 1 1 1 1 1		Reserved
In network to MS direction:
0 0 0 0 0 0 0 0		Reserved
1 1 1 1 1 1 1 1		Reserved
In MS to network direction and in network to MS direction:

For values in the range 00000001 to 10010110 the Maximum SDU size value is binary coded in 8 bits, using a granularity of 10 octets, giving a range of values from 10 octets to 1500 octets.
Values above 10010110 are as below:
1 0 0 1 0 1 1 1		1502 octets 
1 0 0 1 1 0 0 0		1510 octets 
1 0 0 1 1 0 0 1		1520 octets


The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol.

The MS shall consider all other values as reserved.


Maximum bit rate for uplink, octet 8
Bits
8 7 6 5 4 3 2 1
In MS to network direction:
0 0 0 0 0 0 0 0	Subscribed maximum bit rate for uplink
In network to MS direction:
0 0 0 0 0 0 0 0	Reserved
In MS to network direction and in network to MS direction:
0 0 0 0 0 0 0 1 	The maximum bit rate is binary coded in 8 bits, using a granularity of 1 kbps
0 0 1 1 1 1 1 1	giving a range of values from 1 kbps to 63 kbps in 1 kbps increments.

0 1 0 0 0 0 0 0 	The maximum bit rate is 64 kbps + ((the binary coded value in 8 bits –01000000) * 8 kbps)
0 1 1 1 1 1 1 1	giving a range of values from 64 kbps to 568 kbps in 8 kbps increments.

1 0 0 0 0 0 0 0 	The maximum bit rate is 576 kbps + ((the binary coded value in 8 bits –10000000) * 64 kbps)
1 1 1 1 1 1 1 0	giving a range of values from 576 kbps to 8640 kbps in 64 kbps increments.

1 1 1 1 1 1 1 1	0kbps

If the sending entity wants to indicate a Maximum bit rate for uplink higher than 8640 kbps, it shall set octet 8 to "11111110", i.e. 8640 kbps, and shall encode the value for the Maximum bit rate in octet 17.


The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

Maximum bit rate for downlink, octet 9 (see 3GPP TS 23.107 [81])

Coding is identical to that of Maximum bit rate for uplink.

If the sending entity wants to indicate a Maximum bit rate for downlink higher than 8640 kbps, it shall set octet 9 to "11111110", i.e. 8640 kbps, and shall encode the value for the Maximum bit rate in octet 15.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

In this version of the protocol, for messages specified in the present document, the sending entity shall not request 0 kbps for both the Maximum bitrate for downlink and the Maximum bitrate for uplink at the same time. Any entity receiving a request for 0 kbps in both the Maximum bitrate for downlink and the Maximum bitrate for uplink shall consider that as a syntactical error (see clause 8).



Residual Bit Error Rate (BER), octet 10 (see 3GPP TS 23.107 [81])
Bits
8 7 6 5 
In MS to network direction:
0 0 0 0		Subscribed residual BER
In network to MS direction:
0 0 0 0		Reserved
In MS to network direction and in network to MS direction:
The Residual BER value consists of 4 bits. The range is from 5*10-2 to 6*10-8. 
0 0 0 1		5*10-2 
0 0 1 0		1*10-2 
0 0 1 1		5*10-3
0 1 0 0		4*10-3 
0 1 0 1		1*10-3 
0 1 1 0		1*10-4 
0 1 1 1		1*10-5 
1 0 0 0		1*10-6 
1 0 0 1		6*10-8 
1 1 1 1		Reserved

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

The MS shall consider all other values as reserved.

SDU error ratio, octet 10 (see 3GPP TS 23.107 [81])
Bits
4 3 2 1
In MS to network direction:
0 0 0 0		Subscribed SDU error ratio
In network to MS direction:
0 0 0 0		Reserved
In MS to network direction and in network to MS direction:
The SDU error ratio value consists of 4 bits. The range is is from 1*10-1 to 1*10-6. 
0 0 0 1		1*10-2 
0 0 1 0		7*10-3
0 0 1 1		1*10-3 
0 1 0 0		1*10-4 
0 1 0 1		1*10-5 
0 1 1 0		1*10-6 
0 1 1 1		1*10-1
1 1 1 1		Reserved

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

The MS shall consider all other values as reserved.

Traffic handling priority, octet 11 (see 3GPP TS 23.107 [81])
Bits
2 1
In MS to network direction:
0 0		Subscribed traffic handling priority
In network to MS direction:
0 0		Reserved
In MS to network direction and in network to MS direction:
0 1		Priority level 1
1 0		Priority level 2
1 1		Priority level 3

The Traffic handling priority value is ignored if the Traffic Class is Conversational class, Streaming class or Background class.

Transfer delay, octet 11 (See 3GPP TS 23.107 [81])
Bits
8 7 6 5 4 3



In MS to network direction:
0 0 0 0 0 0		Subscribed transfer delay
In network to MS direction:
0 0 0 0 0 0		Reserved
In MS to network direction and in network to MS direction:


0 0 0 0 0 1 	The Transfer delay is binary coded in 6 bits, using a granularity of 10 ms
0 0 1 1 1 1	 	giving a range of values from 10 ms to 150 ms in 10 ms increments

0 1 0 0 0 0 	The transfer delay is 200 ms + ((the binary coded value in 6 bits – 010000) * 50 ms)
0 1 1 1 1 1	 	giving a range of values from 200 ms to 950 ms in 50ms increments

1 0 0 0 0 0 	The transfer delay is 1000 ms + ((the binary coded value in 6 bits – 100000) * 100 ms)
1 1 1 1 1 0	 	giving a range of values from 1000 ms to 4000 ms in 100ms increments

1 1 1 1 1 1	 	Reserved

The Transfer delay value is ignored if the Traffic Class is Interactive class or Background class.

Guaranteed bit rate for uplink, octet 12 (See 3GPP TS 23.107 [81])

Coding is identical to that of Maximum bit rate for uplink.

If the sending entity wants to indicate a Guaranteed bit rate for uplink higher than 8640 kbps, it shall set octet 12 to "11111110", i.e. 8640 kbps, and shall encode the value for the Guaranteed bit rate in octet 18.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

The Guaranteed bit rate for uplink value is ignored if the Traffic Class is Interactive class or Background class, or Maximum bit rate for uplink is set to 0 kbps.

Guaranteed bit rate for downlink, octet 13(See 3GPP TS 23.107 [81])

Coding is identical to that of Maximum bit rate for uplink.

If the sending entity wants to indicate a Guaranteed bit rate for downlink higher than 8640 kbps, it shall set octet 13 to "11111110", i.e. 8640 kbps, and shall encode the value for the Guaranteed bit rate in octet 16.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

The Guaranteed bit rate for downlink value is ignored if the Traffic Class is Interactive class or Background class, or Maximum bit rate for downlink is set to 0 kbps.

Source Statistics Descriptor, octet 14 (see 3GPP TS 23.107 [81])
Bits
4 3 2 1
In MS to network direction
0 0 0 0 	unknown
0 0 0 1		speech

The network shall consider all other values as unknown.

In network to MS direction
Bits 4 to 1 of octet 14 are spare and shall be coded all 0.

The Source Statistics Descriptor value is ignored if the Traffic Class is Interactive class or Background class.

Signalling Indication, octet 14 (see 3GPP TS 23.107 [81])
Bit
5
In MS to network direction and in network to MS direction:
0		Not optimised for signalling traffic
1		Optimised for signalling traffic

If set to '1' the QoS of the PDP context is optimised for signalling

The Signalling Indication value is ignored if the Traffic Class is Conversational class, Streaming class or Background class.

Bits 8 to 6 of octet 14 are spare and shall be coded all 0.

Maximum bit rate for downlink (extended), octet 15
Bits
8 7 6 5 4 3 2 1
In MS to network direction and in network to MS direction:
0 0 0 0 0 0 0 0	Use the value indicated by the Maximum bit rate for downlink in octet 9.

					For all other values: Ignore the value indicated by the Maximum bit rate for downlink in octet 9
					and use the following value:
0 0 0 0 0 0 0 1	The maximum bit rate is 8600 kbps + ((the binary coded value in 8 bits) * 100 kbps),
0 1 0 0 1 0 1 0	giving a range of values from 8700 kbps 
to 16000 kbps in 100 kbps increments.

0 1 0 0 1 0 1 1	The maximum bit rate is 16 Mbps + ((the binary coded value in 8 bits - 01001010) * 1 Mbps),
1 0 1 1 1 0 1 0	giving a range of values from 17 Mbps to 128 Mbps in 1 Mbps increments.

1 0 1 1 1 0 1 1	The maximum bit rate is 128 Mbps + ((the binary coded value in 8 bits - 10111010) * 2 Mbps),
1 1 1 1 1 0 1 0	giving a range of values from 130 Mbps to 256 Mbps in 2 Mbps increments.

If the sending entity wants to indicate a Maximum bit rate for downlink higher than 256 Mbps, it shall set octet 15 to "11111010", i.e. 256 Mbps, and shall encode the value for the maximum bit rate in octet 19.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

Guaranteed bit rate for downlink (extended), octet 16 
Bits
8 7 6 5 4 3 2 1
In MS to network direction and in network to MS direction:
0 0 0 0 0 0 0 0	Use the value indicated by the Guaranteed bit rate for downlink in octet 13.

					For all other values: Ignore the value indicated by the Guaranteed bit rate for downlink in octet 9
					and use the following value:
0 0 0 0 0 0 0 1	The guaranteed bit rate is 8600 kbps + ((the binary coded value in 8 bits) * 100 kbps),
0 1 0 0 1 0 1 0	giving a range of values from 8700 kbps to 16000 kbps in 100 kbps increments.

0 1 0 0 1 0 1 1	The guaranteed bit rate is 16 Mbps + ((the binary coded value in 8 bits - 01001010) * 1 Mbps),
1 0 1 1 1 0 1 0	giving a range of values from 17 Mbps to 128 Mbps in 1 Mbps increments.

1 0 1 1 1 0 1 1	The guaranteed bit rate is 128 Mbps + ((the binary coded value in 8 bits - 10111010) * 2 Mbps),
1 1 1 1 1 0 1 0	giving a range of values from 130 Mbps to 256 Mbps in 2 Mbps increments.

If the sending entity wants to indicate a Guaranteed bit rate for downlink higher than 256 Mbps, it shall set octet 16 to "11111010", i.e. 256 Mbps, and shall encode the value for the guaranteed bit rate in octet 20.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

Maximum bit rate for uplink (extended), octet 17

This field is an extension of the Maximum bit rate for uplink in octet 8. The coding is identical to that of the Maximum bit rate for downlink (extended).

If the sending entity wants to indicate a Maximum bit rate for uplink higher than 256 Mbps, it shall set octet 17 to "11111010", i.e. 256 Mbps, and shall encode the value for the maximum bit rate in octet 21.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

Guaranteed bit rate for uplink (extended), octet 18 

This field is an extension of the Guaranteed bit rate for uplink in octet 12. The coding is identical to that of the Guaranteed bit rate for downlink (extended).

If the sending entity wants to indicate a Guaranteed bit rate for uplink higher than 256 Mbps, it shall set octet 18 to "11111010", i.e. 256 Mbps, and shall encode the value for the guaranteed bit rate in octet 22.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

Maximum bit rate for downlink (extended-2), octet 19
Bits
8 7 6 5 4 3 2 1
In MS to network direction and in network to MS direction:
0 0 0 0 0 0 0 0	Use the value indicated by the Maximum bit rate for downlink in octet 9 and octet 15.

					For all other values: Ignore the value indicated by the Maximum bit rate for downlink in octet 9 and
					octet 15 and use the following value:
0 0 0 0 0 0 0 1	The maximum bit rate is 256 Mbps + ((the binary coded value in 8 bits) * 4 Mbps),
0 0 1 1 1 1 0 1	giving a range of values from 260 Mbps to 500 Mbps in 4 Mbps increments.

0 0 1 1 1 1 1 0	The maximum bit rate is 500 Mbps + ((the binary coded value in 8 bits - 00111101) * 10 Mbps),
1 0 1 0 0 0 0 1	giving a range of values from 510 Mbps to 1500 Mbps in 10 Mbps increments.

1 0 1 0 0 0 1 0	The maximum bit rate is 1500 Mbps + ((the binary coded value in 8 bits - 10100001) * 100 Mbps),
1 1 1 1 0 1 1 0	giving a range of values from 1600 Mbps to 10 Gbps in 100 Mbps increments.

If the sending entity wants to indicate a Maximum bit rate for downlink higher than 256 Mbps, it shall set octet 9 to "11111110", octet 15 to "11111010", i.e. 256 Mbps, and shall encode the value for the maximum bit rate in octet 19.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

The MS shall map all other values not explicitly defined onto the maximum value defined in this version of the protocol.

Guaranteed bit rate for downlink (extended-2), octet 20 
Bits
8 7 6 5 4 3 2 1
In MS to network direction and in network to MS direction:
0 0 0 0 0 0 0 0	Use the value indicated by the Maximum bit rate for downlink in octet 13 and octet 16.

					For all other values: Ignore the value indicated by the Maximum bit rate for downlink in octet 13 and
					octet 16 and use the following value:
0 0 0 0 0 0 0 1	The guaranteed bit rate is 256 Mbps + ((the binary coded value in 8 bits) * 4 Mbps),
0 0 1 1 1 1 0 1	giving a range of values from 260 Mbps 
to 500 Mbps in 4 Mbps increments.

0 0 1 1 1 1 1 0	The guaranteed bit rate is 500 Mbps + ((the binary coded value in 8 bits - 00111101) * 10 Mbps),
1 0 1 0 0 0 0 1	giving a range of values from 510 Mbps to 1500 Mbps in 10 Mbps increments.

1 0 1 0 0 0 1 0	The guaranteed bit rate is 1500 Mbps + ((the binary coded value in 8 bits - 10100001) * 100 Mbps),
1 1 1 1 0 1 1 0	giving a range of values from 1600 Mbps to 10 Gbps in 100 Mbps increments.

If the sending entity wants to indicate a Guaranteed bit rate for downlink higher than 256 Mbps, it shall set octet 16 to "11111010", i.e. 256 Mbps, and shall encode the value for the guaranteed bit rate in octet 20.

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

The MS shall map all other values not explicitly defined onto the maximum value defined in this version of the protocol.

Maximum bit rate for uplink (extended-2), octet 21

This field is an extension of the Maximum bit rate for uplink in octet 17. The coding is identical to that of the Maximum bit rate for downlink (extended 2).

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

The MS shall map all other values not explicitly defined onto the maximum value defined in this version of the protocol.

Guaranteed bit rate for uplink (extended-2), octet 22 

This field is an extension of the Guaranteed bit rate for uplink in octet 18. The coding is identical to that of the Guaranteed bit rate for downlink (extended-2).

The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol.

The MS shall map all other values not explicitly defined onto the maximum value defined in this version of the protocol.


10.5.6.5A	Re-attempt indicator
The purpose of the Re-attempt indicator information element is to indicate a condition under which the MS is allowed, in the current PLMN for the same APN, to re-attempt an EPS session management procedure (see 3GPP TS 24.301 [120]) corresponding to the session management procedure which was rejected by the network.
The Re-attempt indicator information element is coded as shown in figure 10.5.6.5A and table 10.5.6.5A.
8
7
6
5
4
3
2
1

Reattempt indicator IEI
octet 1
Length of Reattempt indicator contents
octet 2
0
Spare
0
Spare
0
Spare
0
Spare
0
Spare
0
Spare
EPLMNC value
RATC value
octet 3

Figure 10.5.6.5A: Re-attempt indicator information element
Table 10.5.6.5A: Re-attempt indicator information element

Re-attempt indicator
RATC (octet 3, bit 1)
0		MS is allowed to re-attempt the procedure in S1 mode
1		MS is not allowed to re-attempt the procedure in S1 mode

EPLMNC (octet 3, bit 2)
0		MS is allowed to re-attempt the procedure in an equivalent PLMN
1		MS is not allowed to re-attempt the procedure in an equivalent PLMN

Bits 3 to 8 of octet 3 are spare and shall be encoded as zero.

10.5.6.6	SM cause
The purpose of the SM cause information element is to indicate the reason why a session management request is rejected.
The SM cause is a type 3 information element with 2 octets length.
The SM cause information element is coded as shown in figure 10.5.139/3GPP TS 24.008 and table 10.5.157/3GPP TS 24.008.

8
7
6
5
4
3
2
1

SM cause IEI
octet 1
Cause value
octet 2

Figure 10.5.139/3GPP TS 24.008: SM cause information element
Table 10.5.157/3GPP TS 24.008: SM cause information element

Cause value (octet 2)
Bits
8 7 6 5 4 3 2 1
0 0 0 0 1 0 0 0	Operator Determined Barring
0 0 0 1 1 0 0 0	MBMS bearer capabilities insufficient for the service
0 0 0 1 1 0 0 1	LLC or SNDCP failure(A/Gb mode only)
0 0 0 1 1 0 1 0	Insufficient resources
0 0 0 1 1 0 1 1	Missing or unknown APN
0 0 0 1 1 1 0 0 	Unknown PDP address or PDP type
0 0 0 1 1 1 0 1	User authentication failed
0 0 0 1 1 1 1 0 	Activation rejected by GGSN, Serving GW or PDN GW
0 0 0 1 1 1 1 1	Activation rejected, unspecified
0 0 1 0 0 0 0 0	Service option not supported
0 0 1 0 0 0 0 1	Requested service option not subscribed
0 0 1 0 0 0 1 0	Service option temporarily out of order
0 0 1 0 0 0 1 1	NSAPI already used (not sent)
0 0 1 0 0 1 0 0	Regular deactivation
0 0 1 0 0 1 0 1	QoS not accepted
0 0 1 0 0 1 1 0	Network failure
0 0 1 0 0 1 1 1	Reactivation requested
0 0 1 0 1 0 0 0	Feature not supported
0 0 1 0 1 0 0 1	Semantic error in the TFT operation
0 0 1 0 1 0 1 0	Syntactical error in the TFT operation
0 0 1 0 1 0 1 1	Unknown PDP context
0 0 1 0 1 1 0 0 	Semantic errors in packet filter(s)
0 0 1 0 1 1 0 1 	Syntactical errors in packet filter(s)
0 0 1 0 1 1 1 0	PDP context without TFT already activated 
0 0 1 0 1 1 1 1	Multicast group membership time-out 
0 0 1 1 0 0 0 0	Request rejected, BCM violation
0 0 1 1 0 0 1 0	PDP type IPv4 only allowed
0 0 1 1 0 0 1 1	PDP type IPv6 only allowed
0 0 1 1 0 1 0 0	Single address bearers only allowed
0 0 1 1 1 0 0 0 	Collision with network initiated request
0 0 1 1 1 1 0 0	Bearer handling not supported
0 1 0 0 0 0 0 1 	Maximum number of PDP contexts reached
0 1 0 0 0 0 1 0 	Requested APN not supported in current RAT and PLMN combination
0 1 0 1 0 0 0 1	Invalid transaction identifier value
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
0 1 1 1 0 0 0 0	APN restriction value incompatible with active PDP context
0 1 1 1 0 0 0 1	Multiple accesses to a PDN connection not allowed

Any other value received by the mobile station shall be treated as 0010 0010, "Service option temporarily out of order”. Any other value received by the network shall be treated as 0110 1111, "Protocol error, unspecified".

NOTE:	The listed cause values are defined in Annex I



10.5.6.6A	SM cause 2
The purpose of the SM cause 2 information element is to provide further information when PDP context activation initiated by the mobile station is successful.
The SM cause 2 is a type 4 information element with 3 octets length.
The SM cause 2 information element is coded as shown in figure 10.5.139a/3GPP TS 24.008 and table 10.5.157a/3GPP TS 24.008.
8
7
6
5
4
3
2
1

SM cause 2 IEI
octet 1
Length of SM cause 2 contents
octet 2
SM cause 2 value
octet 3

Figure 10.5.139a/3GPP TS 24.008: SM cause 2 information element
Table 10.5.157a/3GPP TS 24.008: SM cause 2 information element

SM cause 2 value is coded as octet 2 of the SM cause information element.


10.5.6.7	Linked TI
The purpose of the Linked TI information element is to specify the active PDP context from which the PDP address for the new PDP context could be derived by the network.
The Linked TI is a type 4 information element with a minimum length of 3 octets and a maximum length of 4 octets.
The Linked TI information element is coded as shown in figure 10.5.140/3GPP TS 24.008.


8
7
6
5
4
3
2
1


Linked TI IEI
octet 1

Length of Linked TI IE
octet 2


TI flag
TI value
0 0 0 0
Spare
octet 3

1
EXT
TI value
octet 4

Figure 10.5.140/3GPP TS 24.008: Linked TI information element
The coding of the TI flag, the TI value and the EXT bit is defined in 3GPP TS 24.007[20].
10.5.6.8	Spare
10.5.6.9	LLC service access point identifier
The purpose of the LLC service access point identifier information element is to identify the service access point that is used for the GPRS data transfer at LLC layer.
The LLC service access point identifier is a type 3 information element with a length of 2 octets.
The value part of a LLC service access point identifier information element is coded as shown in figure 10.5.141/3GPP TS 24.008 and table 10.5.159/3GPP TS 24.008.

8
7
6
5
4
3
2
1

 LLC SAPI IEI
octet 1
0	0	0	0
Spare
LLC SAPI
 value
octet 2

Figure 10.5.141/3GPP TS 24.008: LLC service access point identifier information element
Table 10.5.159/3GPP TS 24.008: LLC service access point identifier information element

LLC SAPI value (octet 2)

Bit
4 3 2 1
0 0 0 0		 LLC SAPI not assigned
0 0 1 1		SAPI 3
0 1 0 1		SAPI 5
1 0 0 1		SAPI 9
1 0 1 1		SAPI 11

All other values are reserved.


10.5.6.10	Tear down indicator
The purpose of the tear down indicator information element is to indicate whether only the PDP context associated with this specific TI or all active PDP contexts sharing the same PDP address and APN as the PDP context associated with this specific TI shall be deactivated.
The tear down indicator is a type 1 information element.
The tear down indicator information element is coded as shown in figure 10.5.142/3GPP TS 24.008 and table 10.5.160/3GPP TS 24.008.


8
7
6
5
4
3
2
1


Tear down indicator
IEI
0	0	0
spare
TDI
flag
octet 1


Figure 10.5.142/3GPP TS 24.008: Tear down indicator information element
Table 10.5.160/3GPP TS 24.008: Tear down indicator information element

Tear down indicator(TDI) flag (octet 1)

Bit                                 
1 
0		tear down not requested
1		tear down requested


10.5.6.11	Packet Flow Identifier
The Packet Flow Identifier (PFI) information element indicates the Packet Flow Identifier for a Packet Flow Context.
The Packet Flow Identifier is a a type 4 information element with 3 octets length.
The Packet Flow Identifier information element is coded as shown in figure 10.5.143/3GPP TS 24.008 and table 10.5.161/3GPP TS 24.008.


8
7
6
5
4
3
2
1


Packet Flow Identifier IEI
octet 1

Length of Packet Flow Identifier IE
octet 2

Spare
0
Packet Flow Identifier value

octet 3

Figure 10.5.143/3GPP TS 24.008: Packet Flow Identifier information element
Table 10.5.161/3GPP TS 24.008: Packet Flow Identifier information element

Packet Flow Identifier value (octet 3)
Bits
7 6 5 4 3 2 1
0 0 0 0 0 0 0	Best Effort
0 0 0 0 0 0 1	Signaling
0 0 0 0 0 1 0	SMS
0 0 0 0 0 1 1	TOM8

0 0 0 0 1 0 0	}
	to				} reserved
0 0 0 0 1 1 1	}

0 0 0 1 0 0 0	}
	to				} dynamically assigned
1 1 1 1 1 1 1	}



10.5.6.12	Traffic Flow Template
The purpose of the traffic flow template information element is to specify the TFT parameters and operations for a PDP context. In addition, this information element may be used to transfer extra parameters to the network (e.g. the Authorization Token; see 3GPP TS 24.229 [95]). The TFT may contain packet filters for the downlink direction, the uplink direction or packet filters that are applicable to both directions. The packet filters determine the traffic mapping to PDP contexts. The downlink packet filters shall be used by the network and the uplink packet filters shall be used by the MS. A packet filter that is applicable to both directions shall be used by the network as a downlink packet filter and by the MS as an uplink packet filter.
The traffic flow template is a type 4 information element with a minimum length of 3 octets. The maximum length for the IE is 257 octets.
NOTE 1:	The IE length restriction is due to the maximum length that can be encoded in a single length octet.
NOTE 2:	A maximum size IPv4 packet filter can be 32 bytes. Therefore, 7 maximum size IPv4 type packet filters, plus the last packet filter which can contain max 30 octets can fit into one TFT IE, i.e. if needed not all packet filter components can be defined into one message. A maximum size IPv6 packet filter can be 60 bytes. Therefore, only 4 maximum size IPv6 packet filters can fit into one TFT IE. However, using "Add packet filters to existing TFT", it's possible to create a TFT data structure including 16 maximum size IPv4 or IPv6 filters.
The traffic flow template information element is coded as shown in figure 10.5.144/3GPP TS 24.008 and table 10.5.162/3GPP TS 24.008.
NOTE 3:	The 3GPP TS 24.301 [120] reuses the traffic flow template information element for the purpose of the traffic flow aggregate description, where the use of individual TFT parameters, e.g. the packet filter identifier in the parameter list, can differ from this specification.


8
7
6
5
4
3
2
1


Traffic flow template IEI
Octet 1

Length of traffic flow template IE
Octet 2

TFT operation code
E bit
Number of packet filters
Octet 3


Packet filter list 

Octet 4

Octet z


Parameters list

Octet z+1

Octet v

Figure 10.5.144/3GPP TS 24.008: Traffic flow template information element


8
7
6
5
4
3
2
1


0
0
0
0
Packet filter identifier 1
Octet 4

Spare



0
0
0
0
Packet filter identifier 2
Octet 5

Spare



…


0
0
0
0
Packet filter identifier N
Octet N+3

Spare



Figure 10.5.144a/3GPP TS 24.008: Packet filter list when the TFT operation is "delete packet filters from existing TFT" (z=N+3)


8
7
6
5
4
3
2
1


0
0
Packet filter direction 1
Packet filter identifier 1
Octet 4

Spare




Packet filter evaluation precedence 1
Octet 5

Length of Packet filter contents 1
Octet 6

Packet filter contents 1
Octet 7
Octet m

0
0
Packet filter direction 2
Packet filter identifier 2
Octet m+1

Spare




Packet filter evaluation precedence 2
Octet m+2

Length of Packet filter contents 2
Octet m+3

Packet filter contents 2
Octet m+4
Octet n

…
Octet n+1
Octet y

0
0
Packet filter direction N
Packet filter identifier N
Octet y+1

Spare




Packet filter evaluation precedence N
Octet y+2

Length of Packet filter contents N
Octet y+3

Packet filter contents N
Octet y+4
Octet z

Figure 10.5.144b/3GPP TS 24.008: Packet filter list when the TFT operation is "create new TFT", or "add packet filters to existing TFT" or "replace packet filters in existing TFT"


8
7
6
5
4
3
2
1


Parameter identifier 1
Octet z+1

Length of Parameter contents 1
Octet z+2

Parameter contents 1
Octet z+3
Octet k

Parameter identifier 2
Octet k+1

Length of Parameter contents 2
Octet k+2

Parameter contents 2
Octet k+3
Octet p

…
Octet p+1
Octet q

Parameter identifier N
Octet q+1

Length of Parameter contents N
Octet q+2

Parameter contents N
Octet q+3
Octet v

Figure 10.5.144c/3GPP TS 24.008: Parameters list
Table 10.5.162/3GPP TS 24.008: Traffic flow template information element

TFT operation code (octet 3)
Bits
8 7 6
0 0 0 Ignore this IE
0 0 1 Create new TFT
0 1 0 Delete existing TFT
0 1 1 Add packet filters to existing TFT
1 0 0 Replace packet filters in existing TFT
1 0 1 Delete packet filters from existing TFT
1 1 0 No TFT operation
1 1 1 Reserved 

The TFT operation code "No TFT operation" shall be used if a parameters list is included but no packet filter list is included in the traffic flow template information element.

The TFT operation code "Ignore this IE" shall be used by the MS if the Traffic flow aggregate information element has presence requirement "M" in a message, but the information element does not serve any useful purpose in the specific procedure for which the message is sent (see 3GPP TS 24.301 [120], subclauses 6.5.3.2 and 6.5.4.2). If the TFT operation code indicates "Ignore this IE", the MS shall also set the E bit and the number of packet filters to zero.

If the TFT operation code is set to "Ignore this IE" and the the E bit and the number of packet filters to zero, then the network shall ignore the contents of the traffic flow template information element.

E bit (bit 5 of octet 3)
The E bit indicates if a parameters list is included in the TFT IE and it is encoded as follows:
0	parameters list is not included
1	parameters list is included

Number of packet filters (octet 3)
The number of packet filters contains the binary coding for the number of packet filters in the packet filter list. The number of packet filters field is encoded in bits 4 through 1 of octet 3 where bit 4 is the most significant and bit 1 is the least significant bit. For the "delete existing TFT" operation and for the "no TFT operation", the number of packet filters shall be coded as 0. For all other operations, the number of packet filters shall be greater than 0 and less than or equal to 15. 

Packet filter list (octets 4 to z)
The packet filter list contains a variable number of packet filters. For the "delete existing TFT" operation and the "no TFT operation", the packet filter list shall be empty.
For the "delete packet filters from existing TFT" operation, the packet filter list shall contain a variable number of packet filter identifiers. This number shall be derived from the coding of the number of packet filters field in octet 3.

For the "create new TFT", "add packet filters to existing TFT" and "replace packet filters in existing TFT" operations, the packet filter list shall contain a variable number of packet filters. This number shall be derived from the coding of the number of packet filters field in octet 3.

Each packet filter is of variable length and consists of 
-	a packet filter identifier and direction (1 octet); 
-	a packet filter evaluation precedence (1 octet);
- 	the length of the packet filter contents (1 octet); and
-	the packet filter contents itself (v octets).

The packet filter identifier field is used to identify each packet filter in a TFT. The least significant 4 bits are used. 

The packet filter direction is used to indicate, in bits 5 and 6, for what traffic direction the filter applies:

00 - pre Rel-7 TFT filter
01 - downlink only
10 - uplink only
11 - bidirectional
Bits 8 through 7 are spare bits.

The packet filter evaluation precedence field is used to specify the precedence for the packet filter among all packet filters in all TFTs associated with this PDP address. Higher the value of the packet filter evaluation precedence field, lower the precedence of that packet filter is. The first bit in transmission order is the most significant bit.

The length of the packet filter contents field contains the binary coded representation of the length of the packet filter contents field of a packet filter. The first bit in transmission order is the most significant bit.

The packet filter contents field is of variable size and contains a variable number (at least one) of packet filter components. Each packet filter component shall be encoded as a sequence of a one octet packet filter component type identifier and a fixed length packet filter component value field. The packet filter component type identifier shall be transmitted first.

In each packet filter, there shall not be more than one occurrence of each packet filter component type. Among the "IPv4 remote address type" and "IPv6 remote address type" packet filter components, only one shall be present in one packet filter. Among the "single local port type" and "local port range type" packet filter components, only one shall be present in one packet filter. Among the "single remote port type" and "remote port range type" packet filter components, only one shall be present in one packet filter.

The term local refers to the MS and the term remote refers to an external network entity.

Packet filter component type identifier
Bits
8 7 6 5 4 3 2 1 
0 0 0 1 0 0 0 0	IPv4 remote address type
0 0 0 1 0 0 0 1	IPv4 local address type 
0 0 1 0 0 0 0 0	IPv6 remote address type
0 0 1 0 0 0 0 1	IPv6 remote address/prefix length type
0 0 1 0 0 0 1 1	IPv6 local address/prefix length type
0 0 1 1 0 0 0 0	Protocol identifier/Next header type
0 1 0 0 0 0 0 0	Single local port type
0 1 0 0 0 0 0 1	Local port range type
0 1 0 1 0 0 0 0	Single remote port type 
0 1 0 1 0 0 0 1	Remote port range type
0 1 1 0 0 0 0 0	Security parameter index type
0 1 1 1 0 0 0 0	Type of service/Traffic class type
1 0 0 0 0 0 0 0	Flow label type
All other values are reserved.

The description and valid combinations of packet filter component type identifiers in a packet filter are defined in 3GPP TS 23.060 [74] subclause 15.3.2.

For "IPv4 remote address type", the packet filter component value field shall be encoded as a sequence of a four octet IPv4 address field and a four octet IPv4 address mask field. The IPv4 address field shall be transmitted first.

For "IPv4 local address type", the packet filter component value field shall be encoded as defined for "IPv4 remote address type".
Both the MS and network indication for support of the Local address in TFTs are required to use this packet filter component.

For "IPv6 remote address type", the packet filter component value field shall be encoded as a sequence of a sixteen octet IPv6 address field and a sixteen octet IPv6 address mask field. The IPv6 address field shall be transmitted first.

For "IPv6 remote address/prefix length type", the packet filter component value field shall be encoded as a sequence of a sixteen octet IPv6 address field and one octet prefix length field. The IPv6 address field shall be transmitted first.
This parameter shall be used, instead of IPv6 remote address type, when both the MS and network indication for support of the Local address in TFT are present.

For "IPv6 local address/prefix length type", the packet filter component value field shall be encoded as defined for "IPv6 remote address /prefix length".
Both the MS and network indication for support of the Local address in TFTs are required to use this packet filter component.

NOTE:	Local IP address and mask can be used when IPv6 prefix delegation is used (see 3GPP TS 23.060 [74] subclause  9.2.1.2).

For "Protocol identifier/Next header type", the packet filter component value field shall be encoded as one octet which specifies the IPv4 protocol identifier or IPv6 next header.

For "Single local port type" and "Single remote port type", the packet filter component value field shall be encoded as two octet which specifies a port number.

For "Local port range type" and "Remote port range type", the packet filter component value field shall be encoded as a sequence of a two octet port range low limit field and a two octet port range high limit field. The port range low limit field shall be transmitted first.

For "Security parameter index", the packet filter component value field shall be encoded as four octet which specifies the IPSec security parameter index.

For "Type of service/Traffic class type", the packet filter component value field shall be encoded as a sequence of a one octet Type-of-Service/Traffic Class field and a one octet Type-of-Service/Traffic Class mask field. The Type-of-Service/Traffic Class field shall be transmitted first.

For "Flow label type", the packet filter component value field shall be encoded as three octet which specifies the IPv6 flow label. The bits 8 through 5 of the first octet shall be spare whereas the remaining 20 bits shall contain the IPv6 flow label.
Parameters list (octets z+1 to v)

The parameters list contains a variable number of parameters that may be transferred. If the parameters list is included, the E bit is set to 1; otherwise, the E bit is set to 0.

Each parameter included in the parameters list is of variable length and consists of:
-	a parameter identifier (1 octet); 
-	the length of the parameter contents (1 octet); and
-	the parameter contents itself (v octets). 

The parameter identifier field is used to identify each parameter included in the parameters list and it contains the hexadecimal coding of the parameter identifier. Bit 8 of the parameter identifier field contains the most significant bit and bit 1 contains the least significant bit. In this version of the protocol, the following parameter identifiers are specified:
-	01H (Authorization Token);
-	02H (Flow Identifier); and
-	03H (Packet Filter Identifier).

If the parameters list contains a parameter identifier that is not supported by the receiving entity the corresponding parameter shall be discarded.
The length of parameter contents field contains the binary coded representation of the length of the parameter contents field. The first bit in transmission order is the most significant bit.

When the parameter identifier indicates Authorization Token, the parameter contents field contains an authorization token, as specified in 3GPP TS 29.207 [100]. The first octet is the most significant octet of the authorization token and the last octet is the least significant octet of the authorization token.
The parameters list shall be coded in a way that an Authorization Token (i.e. a parameter with identifier 01H) is always followed by one or more Flow Identifiers (i.e. one or more parameters with identifier 02H).

If the parameters list contains two or more consecutive Authorization Tokens without any Flow Identifiers in between, the receiver shall treat this as a semantical TFT error.

When the parameter identifier indicates Flow Identifier, the parameter contents field contains the binary representation of a flow identifier. The Flow Identifier consists of four octets. Octets 1 and 2 contains the Media Component number as specified in 3GPP TS 29.207 [100]. Bit 1 of octet 2 is the least significant bit, and bit 8 of octet 1 is the most significant bit. Octets 3 and 4 contains the IP flow number as specified in 3GPP TS 29.207 [100]. Bit 1 of octet 4 is the least significant bit, and bit 8 of octet 3 is the most significant bit.

When the parameter identifier indicates Packet Filter Identifier, the parameter contents field contains the binary representation of one or more packet filter identifiers. Each packet filter identifier is encoded in one octet, in the 4 least significant bits. This parameter is used by the MS and the network to identify one or more packet filters in a TFT when modifying the QoS of a PDP context without modifying the packet filter itself.

10.5.6.13	Temporary Mobile Group Identity (TMGI)
The purpose of the TMGI element is for group paging in MBMS.
The TMGI information element is a type 4 information element with a minimum length of 5 octets and a maximum length of 8 octets. If octet 6 is included, then octets 7 and 8 shall also be included.
The content of the TMGI element is shown in Figure 10.5.154/3GPP TS 24.008 and table 10.5.168/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Temporary Mobile Group Identity IEI
Octet 1
Length of Temporary Mobile Group Identity contents
Octet 2

MBMS Service ID
Octet 3
Octet 4

Octet 5
MCC digit 2 
MCC digit 1
Octet 6*
MNC digit 3
MCC digit 3
Octet 7*
MNC digit 2
MNC digit 1
Octet 8*

Figure 10.5.154/3GPP TS 24.008: TMGI information element
Table 10.5.168/3GPP TS 24.008: TMGI information element

MBMS Service ID (octet 3, 4 and 5)

In the MBMS Service ID field bit 8 of octet 3 is the most significant bit and bit 1 of octet 5 the least significant bit.
The coding of the MBMS Service ID is the responsibility of each administration. Coding using full hexadecimal representation may be used. The MBMS Service ID consists of 3 octets.

MCC, Mobile country code (octet 6, octet 7 bits 1 to 4)

The MCC field is coded as in ITU-T Rec. E.212 [46], Annex A.

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

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. If a network operator decides to use only two digits in the MNC, bits 5 to 8 of octet 7 shall be coded as "1111".

10.5.6.14	MBMS bearer capabilities 
The purpose of the MBMS bearer capabilities information element is to indicate the maximum bit rate for downlink supported by the MS for an MBMS context.
NOTE: 	The information element indicates the static physical capabilities of the MS, independent of the radio access (UTRAN or GERAN), the radio conditions, or other CS or PS services possibly activated by the MS.
The MBMS bearer capabilities is a type 4 information element with a maximum length of 4 octets.
The MBMS bearer capabilities information element is coded as shown in figure 10.5.155/3GPP TS 24.008 and table 10.5.169/3GPP TS 24.008.

8
7
6
5
4
3
2
1

MBMS bearer capabilities IEI
Octet 1
Length of MBMS bearer capabilities IE
Octet 2
Maximum bit rate for downlink
Octet 3
Maximum bit rate for downlink (extended)
Octet 4

Figure 10.5.155/3GPP TS 24.008: MBMS bearer capabilities information element
Table 10.5.169/3GPP TR 24.008: MBMS bearer capabilities information element

Maximum bit rate for downlink, octet 3 (see 3GPP TS 23.107 [81])

The coding is identical to that of the maximum bit rate for downlink, octet 9, in the Quality of service information element (see subclause 10.5.6.5).

If the sending entity wants to indicate a maximum bit rate for downlink higher than 8640 kbps, it shall set octet 3 to ”11111110”, i.e. 8640 kbps, and shall encode the value for the maximum bit rate in octet 4.

Maximum bit rate for downlink (extended), octet 4

The coding is identical to that of the maximum bit rate for downlink (extended), octet 15, in the Quality of service information element (see subclause 10.5.6.5).

10.5.6.15	MBMS protocol configuration options
The purpose of the MBMS protocol configuration options information element is to:
-	transfer protocol options associated with the bearer level of an MBMS context activation, and
-	transfer additional MBMS bearer related (protocol) data (e.g. configuration parameters, error codes or messages/events).
The MBMS protocol configuration options is a type 4 information element with a minimum length of 3 octets and a maximum length of 253 octets. 
The MBMS protocol configuration options information element is coded as shown in figure 10.5.156/3GPP TS 24.008 and table 10.5.170/3GPP TS 24.008.

8
7
6
5
4
3
2
1

MBMS protocol configuration options IEI
octet 1
Length of MBMS protocol configuration options contents
octet 2
0
0
0
0
0
0
0
0
octet 3
Spare


Figure 10.5.156/3GPP TS 24.008: MBMS protocol configuration options information element 
Table 10.5.170/3GPP TR 24.008: MBMS protocol configuration options information element
Bits 1 to 8 of octet 3 are spare and shall be coded as "0".
NOTE: 	The reason for defining the information element is to have a transparent mechanism in the SGSN available from the introduction of MBMS. This will ensure that MS – GGSN communication is possible if new MBMS bearer service related parameters are defined.

10.5.6.16	Enhanced network service access point identifier
The purpose of the Enhanced network service access point identifier information element is to identify the service access point that is used at layer 3.
The Enhanced network service access point identifier is a type 3 information element with a length of 2 octets.
The value part of an Enhanced network service access point identifier information element is coded as shown in figure 10.5.157/3GPP TS 24.008 and table 10.5.171/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Enhanced NSAPI IEI
octet 1
Enhanced NSAPI
value
octet 2



Figure 10.5.157/3GPP TS 24.008: Enhanced network service access point identifier information element
Table 10.5.171/3GPP TS 24.008: Enhanced network service access point identifier information element

Enhanced NSAPI value (octet 2, bits 1 to 7)

Bits
8
7
6
5
4
3
2
1










0
0
0
0
0
0
0
0
Reserved
through

0
1
1
1
1
1
1
1
Reserved









1
0
0
0
0
0
0
0
NSAPI 128 for Multimedia Broadcast/Multicast Service (MBMS) Multicast mode
through

1
1
1
1
1
1
1
0
NSAPI 254 for Multimedia Broadcast/Multicast Service (MBMS) Multicast mode









1
1
1
1
1
1
1
1
Reserved (NOTE)

NOTE: NSAPI 255 is reserved for use by lower layers in the point-to-point radio bearer allocation message for Multimedia Broadcast/Multicast Service (MBMS) Broadcast mode (see 3GPP TS 25.331 [23c]).


10.5.6.17	Request type
The purpose of the Request type information element is to indicate whether the MS requests to establish a new connectivity to a PDN or keep the connection(s) to which it has connected via non-3GPP access.
The Request type information element is also used to indicate that the MS is requesting connectivity to a PDN that provides emergency bearer services.
The Request type information element is coded as shown in figure 10.5.158/3GPP TS 24.008 and table 10.5.173/3GPP TS 24.008.
The Request type is a type 1 information element.

8
7
6
5
4
3
2
1

Request type IEI
0
Spare
Request type value
octet 1

Figure 10.5.158/3GPP TS 24.008: Request type information element
Table 10.5.173/3GPP TS 24.008: Request type information element
Request type value (octet 1)
Bits
3
2
1


0
0
1

initial request
0
1
0

Handover
0
1
1

Unused. If received, the network shall interpret this as "initial request".
1
0
0

emergency

All other values are reserved.

Bit 4 of octet 1 is spare and shall be coded as zero.


10.5.6.18	Notification indicator
The purpose of the Notification indicator information element is to inform the MS about an event which is relevant for the upper layer using a PDP context or having requested a session management procedure.
The Notification indicator information element is coded as shown in figure 10.5.159/3GPP TS 24.008 and table 10.5.174/3GPP TS 24.008.
The Notification indicator is a type 4 information element with 3 octets length.

8
7
6
5
4
3
2
1

Notification indicator IEI
octet 1
Length of notification indicator contents
octet 2
Notification indicator value
octet 3

Figure 10.5.159/3GPP TS 24.008: Notification indicator information element
Table 10.5.174/3GPP TS 24.008: Notification indicator information element
Notification indicator value (octet 3)

Bits
8
7
6
5
4
3
2
1


0
0
0
0
0
0
0
1

SRVCC handover cancelled, IMS session re-establishment required (see 3GPP TS 23.216 [126])










0
0
0
0
0
0
1
0


to

Unused, shall be ignored if received by the MS
0
1
1
1
1
1
1
1



All other values are reserved.


10.5.6.19	Connectivity type
The purpose of the Connectivity type information element is to specify the type of connectivity selected by the network for the PDN connection.
The Connectivity type information element is coded as shown in figure 10.5.6.19-1/3GPP TS 24.008 and table 10.5.6.19-1/3GPP TS 24.008.
The Connectivity type is a type 1 information element.

8
7
6
5
4
3
2
1

Connectivity type
IEI
Connectivity type
value
octet 1

Figure 10.5.6.19-1/3GPP TS 24.008: Connectivity type information element
Table 10.5.6.19-1/3GPP TS 24.008: Connectivity type information element
Connectivity type value (octet 1)
Bits
	4 3 2 1
	0 0 0 0		The PDN connection type is not indicated
	0 0 0 1		The PDN connection is considered a LIPA PDN connection

All other values shall be interpreted as "the PDN connection type is not indicated".


10.5.6.20	WLAN offload acceptability
The purpose of the WLAN offload acceptability information element is to indicate whether traffic can be offloaded using a PDN connection via a WLAN, or not.
The values "offloading the traffic of the PDN connection via a WLAN when in S1 mode is acceptable" and "offloading the traffic of the PDN connection via a WLAN when in Iu mode is acceptable" map to "indication that the PDP context is offloadable" as defined in 3GPP TS 23.060 [74] and 3GPP TS 23.401 [122]. The value "offloading the traffic of the PDN connection via a WLAN when in S1 mode is not acceptable" and "offloading the traffic of the PDN connection via a WLAN when in Iu mode is not acceptable" map to "indication that the PDP context is not offloadable" as defined in 3GPP TS 23.060 [74] and 3GPP TS 23.401 [122]. The procedures in 3GPP TS 23.060 [74] when the MS receives the UTRAN offload acceptability value in A/Gb mode or Iu mode apply. The procedures in 3GPP TS 23.401 [122] when the MS receives the E-UTRAN offload acceptability value in S1 mode apply.
The WLAN offload acceptability information element is coded as shown in figure 10.5.6.20-1/3GPP TS 24.008 and table 10.5.6.20-1/3GPP TS 24.008.
The WLAN offload acceptability is a type 1 information element.

8
7
6
5
4
3
2
1

WLAN offload acceptability
IEI
0
spare
0
spare
UTRAN offload acceptability value
E-UTRAN offload acceptability value
octet 1

Figure 10.5.6.20-1/3GPP TS 24.008: WLAN offload acceptability information element
Table 10.5.6.20-1/3GPP TS 24.008: WLAN offload acceptability information element
E-UTRAN offload acceptability value (octet 1)
Bit
1




0



Offloading the traffic of the PDN connection via a WLAN when in S1 mode is not acceptable
1



Offloading the traffic of the PDN connection via a WLAN when in S1 mode is acceptable

UTRAN offload acceptability value (octet 1)
Bit
2




0



Offloading the traffic of the PDN connection via a WLAN when in Iu mode is not acceptable
1



Offloading the traffic of the PDN connection via a WLAN when in Iu mode is acceptable

Bits 3 and 4 of octet 1 are spare and shall be coded as zero


10.5.6.21	NBIFOM container
The purpose of the NBIFOM container information element is to transfer parameters associated with the network-based IP flow mobility (NBIFOM).
The NBIFOM container is a type 4 information element with a minimum length of 3 octets and a maximum length of 257 octets.
The NBIFOM container information element is coded as shown in figure 10.5.6.21-1/3GPP TS 24.008 and table 10.5.6.21-1/3GPP TS 24.008.

8
7
6
5
4
3
2
1


NBIFOM container IEI
octet 1

Length of NBIFOM container contents
octet 2


NBIFOM container contents
octet 3

octet x

Figure 10.5.6.21-1/3GPP TS 24.008: NBIFOM container information element 
Table 10.5.6.21-1/3GPP TS 24.008: NBIFOM container information element
NBIFOM container contents field contains the NBIFOM parameter list as defined in 3GPP TS 24.161 [158], subclause 6.1.

10.5.7	GPRS Common information elements
10.5.7.1	PDP context status
The purpose of the PDP context status information element is to indicate the state of each PDP context which can be identified by NSAPI. 
The PDP context status information element is a type 4 information element with 4 octets length.
The PDP context status information element is coded as shown in figure 10.5.148/3GPP TS 24.008 and table 10.5.164/3GPP TS 24.008.

8
7
6
5
4
3
2
1

PDP context status IEI
octet 1
Length of PDP context status contents
Octet 2
NSAPI
(7)
NSAPI
(6)
NSAPI
(5)
NSAPI
(4)
NSAPI
(3)
NSAPI
(2)
NSAPI
(1)
NSAPI
(0)
octet 3
NSAPI
(15)
NSAPI
(14)
NSAPI
(13)
NSAPI
(12)
NSAPI
(11)
NSAPI
(10)
NSAPI
(9)
NSAPI
(8)
octet 4

Figure 10.5.148/3GPP TS 24.008 PDP context status information element
Table 10.5.164/3GPP TS 24.008: PDP context status information element

NSAPI(x) shall be coded as follows:

NSAPI(0) - NSAPI(4):
	are coded as '0' and shall be treated as spare in this version of the protocol.
NSAPI(5) – NSAPI(15): 
	0	indicates that the SM state of the corresponding PDP context is PDP-INACTIVE.
	1	indicates that the SM state of the corresponding PDP context is not PDP-INACTIVE.


10.5.7.2	Radio priority
The purpose of the radio priority information element is to specify the priority level that the MS shall use at the lower layers for transmission of data related to a PDP context or for mobile originated SMS transmission.
The radio priority information element is coded as shown in figure 10.5.145/3GPP TS 24.008 and table 10.5.161/3GPP TS 24.008.
The radio priority is a type 1 information element.

8
7
6
5
4
3
2
1

Radio priority IEI

0
spare
Radio priority
level value
octet 1

Figure 10.5.145/3GPP TS 24.008: Radio priority information element
Table 10.5.161/3GPP TS 24.008: Radio priority information element

Radio priority level value (octet 1)
Bits
3 2 1 

0 0 1	priority level 1 (highest)
0 1 0	priority level 2
0 1 1	priority level 3
1 0 0	priority level 4 (lowest)

All other values are interpreted as priority level 4 by this version of the protocol.


10.5.7.3	GPRS Timer
The purpose of the GPRS timer information element is to specify GPRS specific timer values, e.g. for the READY timer.
The GPRS timer is a type 3 information element with 2 octets length.
The GPRS timer information element is coded as shown in figure 10.5.146/3GPP TS 24.008 and table 10.5.172/3GPP TS 24.008.


8
7
6
5
4
3
2
1


GPRS Timer IEI
octet 1

Unit
Timer value
octet 2

Figure 10.5.146/3GPP TS 24.008: GPRS Timer information element
Table 10.5.172/3GPP TS 24.008: GPRS Timer information element

Timer value (octet 2)

Bits 5 to 1 represent the binary coded timer value.

Bits 6 to 8 defines the timer value unit for the GPRS timer as follows:
Bits 
8 7 6
0 0 0  value is incremented in multiples of 2 seconds
0 0 1  value is incremented in multiples of 1 minute 
0 1 0  value is incremented in multiples of decihours
1 1 1  value indicates that the timer is deactivated.

Other values shall be interpreted as multiples of 1 minute in this version of the protocol.


10.5.7.4	GPRS Timer 2
The purpose of the GPRS timer 2 information element is to specify GPRS specific timer values, e.g. for the timer T3302 or timer T3319.
The GPRS timer 2 is a type 4 information element with 3 octets length.
The GPRS timer 2 information element is coded as shown in figure 10.5.147/3GPP TS 24.008 and table 10.5.163/3GPP TS 24.008.


8
7
6
5
4
3
2
1


GPRS Timer 2 IEI
octet 1

Length of GPRS Timer 2 contents
octet 2

GPRS Timer 2 value
octet 3

Figure 10.5.147/3GPP TS 24.008: GPRS Timer 2 information element
Table 10.5.163/3GPP TS 24.008: GPRS Timer 2 information element

GPRS Timer 2 value is coded as octet 2 of the GPRS timer information element.


10.5.7.4a	GPRS Timer 3
The purpose of the GPRS timer 3 information element is to specify GPRS specific timer values, e.g. for the timer T3396.
The GPRS timer 3 is a type 4 information element with 3 octets length.
The GPRS timer 3 information element is coded as shown in figure 10.5.147a/3GPP TS 24.008 and table 10.5.163a/3GPP TS 24.008.


8
7
6
5
4
3
2
1


GPRS Timer 3 IEI
octet 1

Length of GPRS Timer 3 contents
octet 2

Unit
Timer value
octet 3

Figure 10.5.147a/3GPP TS 24.008: GPRS Timer 3 information element
Table 10.5.163a/3GPP TS 24.008: GPRS Timer 3 information element
GPRS Timer 3 value (octet 3)

Bits 5 to 1 represent the binary coded timer value.

Bits 6 to 8 defines the timer value unit for the GPRS timer as follows:
Bits 
8 7 6
0 0 0 value is incremented in multiples of 10 minutes 
0 0 1 value is incremented in multiples of 1 hour 
0 1 0 value is incremented in multiples of 10 hours
0 1 1 value is incremented in multiples of 2 seconds
1 0 0 value is incremented in multiples of 30 seconds
1 0 1 value is incremented in multiples of 1 minute
1 1 0 value is incremented in multiples of 320 hours (NOTE)
1 1 1 value indicates that the timer is deactivated.

NOTE:	This timer value unit is only applicable to the T3312 extended value IE and T3412 extended value IE (see 3GPP TS 24.301 [120]). If it is received in an integrity protected message, value shall be interpreted as multiples of 320 hours. Otherwise value shall be interpreted as multiples of 1 hour.

10.5.7.5	Radio priority 2
The purpose of the radio priority 2 information element is to specify the priority level that the MS shall use at the lower layers for transmission of mobile originated TOM8 transmission.

The radio priority 2 information element is coded as shown in figure 10.5.148/3GPP TS 24.008 and table 10.5.164/3GPP TS 24.008.
The radio priority is a type 1 information element.

8
7
6
5
4
3
2
1

Radio priority 2 IEI

0 spare
Radio priority
level value
octet 1

Figure 10.5.148/3GPP TS 24.008: Radio priority 2 information element
Table 10.5.164/3GPP TS 24.008: Radio priority 2 information element

Radio priority level value (octet 1, bits 1-3)

Bits
3
2
1


0
0
1

priority level 1 (highest)
0
1
0

priority level 2
0
1
1

priority level 3
1
0
0

priority level 4 (lowest)

All other values are interpreted as priority level 4 by this version of the protocol. 


10.5.7.6	MBMS context status
The purpose of the MBMS context status information element is to indicate the state of each MBMS context which can be identified by an NSAPI. 
The MBMS context status information element is a type 4 information element with a minimum length of 2 octets and a maximum length of 18 octets.
The MBMS context status information element is coded as shown in figure 10.5.149/3GPP TS 24.008 and table 10.5.165/3GPP TS 24.008.

8
7
6
5
4
3
2
1

MBMS context status IEI
octet 1
Length of MBMS context status contents
octet 2
NSAPI
(135)
NSAPI
(134)
NSAPI
(133)
NSAPI
(132)
NSAPI
(131)
NSAPI
(130)
NSAPI
(129)
NSAPI
(128)
octet 3
NSAPI
(143)
NSAPI
(142)
NSAPI
(141)
NSAPI
(140)
NSAPI
(139)
NSAPI
(138)
NSAPI
(137)
NSAPI
(136)
octet 4



NSAPI
(255)
NSAPI
(254
NSAPI
(253)
NSAPI
(252)
NSAPI
(251)
NSAPI
(250)
NSAPI
(249)
NSAPI
(248)
octet 18

Figure 10.5.149/3GPP TS 24.008 MBMS context status information element
Table 10.5.165/3GPP TS 24.008: MBMS context status information element

For x = 128 to 255, NSAPI(x) shall be coded as follows:

	0	indicates that the SM state of the corresponding MBMS context is PDP-INACTIVE.
	1	indicates that the SM state of the corresponding MBMS context is not PDP-INACTIVE.

If octets are not included in the information element, the receiver shall interprete the NSAPI(x) values of these octets as set to 0.

10.5.7.7	Uplink data status
The purpose of the Uplink data status information element is to indicate to the network which preserved PDP contexts have uplink data pending. 
The Uplink data status information element is a type 4 information element with 4 octets length.
The Uplink data status information element is coded as shown in figure 10.5.149/3GPP TS 24.008 and table 10.5.166/3GPP TS 24.008.

8
7
6
5
4
3
2
1

Uplink data status IEI
octet 1
Length of Uplink data status contents
octet 2
NSAPI
(7)
NSAPI
(6)
NSAPI
(5)
Spare
(0)
Spare
(0)
Spare
(0)
Spare
(0)
Spare
(0)
octet 3
NSAPI
(15)
NSAPI
(14)
NSAPI
(13)
NSAPI
(12)
NSAPI
(11)
NSAPI
(10)
NSAPI
(9)
NSAPI
(8)
octet 4

Figure 10.5.149A/3GPP TS 24.008 Uplink data status information element
Table 10.5.166/3GPP TS 24.008: Uplink data status information element
NSAPI uplink status (octet 3 and 4)

Octet 3, bits 1 to 5 are all spare and shall be encoded as 0

NSAPI(5) – NSAPI(15) (octets 3 – 4):
	0	no uplink data are pending for the preserved PDP context or the PDP context is PDP-INACTIVE or is PDP-ACTIVE with a RAB already established.
	1	uplink data are pending for the preserved PDP context.


10.5.7.8	Device properties
The purpose of the Device properties information element is to indicate if the MS is configured for NAS signalling low priority. The network uses the Device properties information element for core-network congestion handling and for charging purposes.
The Device properties information element is coded as shown in figure 10.5.7.8.1/3GPP TS 24.008 and table 10.5.7.8.1/3GPP TS 24.008.
The Device properties is a type 1 information element.

8
7
6
5
4
3
2
1

Device properties
IEI
0
Spare
0
Spare
0
Spare
Low priority
octet 1

Figure 10.5.7.8.1/3GPP TS 24.008: Device properties information element
Table 10.5.7.8.1/3GPP TS 24.008: Device properties information element
Low priority (octet 1)

Bit
1




0



MS is not configured for NAS signalling low priority
1



MS is configured for NAS signalling low priority





The value "0" can also be used by an MS configured for NAS signalling low priority for the exception cases specified in subclause 1.8.

Bits 2, 3 and 4 of octet 1 are spare and shall be coded as zero.

