10.5.4 Call control information elements

24.0083GPPCore network protocolsMobile radio interface Layer 3 specificationRelease 18Stage 3TS

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	0		1	1	0	1	13.	Call completed elsewhere	–
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"

A mobile station not initiating an eCall shall set bit 6 and bit 7 to "0" and may set one or more of bit 1, bit 2, bit 3, bit 4 or bit 5 to "1". If more than one of these bits is set to "1", routing to a combined emergency centre (e.g. ambulance and fire brigade in Japan) is required.

A mobile station initiating an eCall shall set either bit 6 or bit 7 to "1" and shall set all other bits to "0". A MSC supporting eCall shall 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.

If the MSC can not match the received service category to any of the emergency centres, or if no bit is set to "1", the MSC shall route the emergency call to an operator defined default emergency 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