10.5.4 Call control information elements

04.083GPPMobile radio interface Layer 3 specificationRelease 1998TS

10.5.4.1 Extensions of codesets

There is a certain number of possible information element identifier values using the formatting rules described in sub-clause 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 sub-clause 10.5 shall apply for information elements belonging to any active codeset.

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 sub-clause 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 04.08 and table 10.5.98/3GPP TS 04.08.

8 7 6 5 4 3 2 1

+———————————————–+

│ │ │ 0 │ New codeset │ octet 1

│ │ Shift identifier│ │ identification │

+————————–│——————–+

"0" in this position indicates locking shift

Figure 10.5.85/3GPP TS 04.08: Locking shift element

Table 10.5.98/3GPP TS 04.08: Locking shift element

+———————————————————+
│ Codeset identification (octet 1): │
│ bits 3 2 1 │
│ 0 0 0 not applicable │
│ 0 0 1 │
│ to 1 0 0 reserved │
│ 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 04.08 and table 10.5.99/3GPP TS 04.08.

8 7 6 5 4 3 2 1

+———————————————–+

│ │ │ 1 │Temporary codeset│ octet 1

│ │ Shift identifier│ │ identification │

+————————–│——————–+

"1" in this position indicates non-locking shift

Figure 10.5.86/3GPP TS 04.08: Non-locking shift element

Table 10.5.99/3GPP TS 04.08: Non-locking shift element

+———————————————————+

│ Codeset identification (octet 1): │

│ bits 3 2 1 │

│ 0 0 0 codeset 0 (initially active): │

│ GSMß04.08 information elements │

│ 0 0 1 │

│ to 1 0 0 reserved │

│ 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 TSs 3GPP TS 04.83 and 04.84)

The auxiliary states information element is coded as shown in figure 10.5.87/3GPP TS 04.08, table 10.5.100/3GPP TS 04.08 and table 10.5.101/3GPP TS 04.08.

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 04.08: Auxiliary states information element

Table 10.5.100/3GPP TS 04.08: 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 Rec GSMß04.83. │

+———————————————————+

Table 10.5.101/3GPP TS 04.08: 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 Rec GSMß04.84. │

+———————————————————+

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 04.08 and tables 10.5.102/3GPP TS 04.08 to 10.5.115/3GPP TS 04.08.

The 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

+———————————————–+

│ │ Bearer capability IEI │ octet 1

+———————————————–│

│ │

│ Length of the bearer capability contents │ octet 2

+———————————————–│

│ 0/1 │ radio │ co- │trans│ information │

│ ext │ channel │ding │ fer │ transfer │ octet 3

│ │requirement│ std │mode │ capability │

+—–+—————–+———————–│

│ 0/1 │ 0 │ │ 0 │ │

│ ext │ co- │ CTM │spare│ speech version │octet 3a*

│ │ ding│ │ │ indication │

+—–+—–+———–+———————–│

│ 0/1 │ 0 │ 0 0 │ │

│ ext │ co- │ spare │ speech version │octet 3b etc*

│ │ ding│ │ indication │

+—–+—–+———–+———————–│

│ 1 │comp-│ │dupl.│confi│ NIRR│esta-│

│ ext │ress.│ structure │mode │ gur.│ │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 │Hdr/ │Multi│Mode │ LLI │Assig│Inb. │ 0 │

│ ext │noHdr│frame│ │ │nor/e│neg │Spare│ octet 5b*

+—–+———–+———————–+—–│

│ 0/1 │ 0 1 │ User information │sync/│

│ ext │layer 1 id.│ layer 1 protocol │async│ octet 6*

+—–+———–+—————————–│

│ 0/1 │numb.│nego-│numb.│ │

│ ext │stop │tia- │data │ user rate │ octet 6a*

│ │bits │tion │bits │ │

+—–+———–+—–+———————–│

│ 0/1 │ intermed. │ NIC │ NIC │ │

│ ext │ rate │on TX│on RX│ Parity │ octet 6b*

+—–+———–+—————————–│

│ 0/1 │connection │ │

│ ext │ element │ modem type │ octet 6c*

│ │ │ │

+—–+———–+—————————–│

│ 0/1 │ Other │ Fixed network user rate │ octet 6d*

│ ext │modem type │ │

+—–+—————————————–│

│ 0/1 │ Acceptable │Maximum number of│ octet 6e*

│ ext │ channel │traffic channels │

│ │ codings │ │

+—–+—————————————–│

│ 0/1 │ UIMI │ Wanted air interface │ octet 6f*

│ ext │ │ user rate │

+—–+—————————————–│

│ 1 │ 1 0 │ User information │

│ ext │layer 2 id.│ layer 2 protocol │ octet 7*

+———————————————–+

Figure 10.5.88/3GPP TS 04.08: Bearer capability information element

NOTE: The coding of the octets of the bearer capability information element is not conforming to TS ITU-T Recommendation Q.931.

Table 10.5.102/3GPP TS 04.08: Bearer capability information element

 Radio channel requirement (octet 3), network to MS direction 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. 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 04.08: Bearer capability information element

 Octet(s) 3a etc. MS to network direction CodingBit 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 In this version of the protocol, bit 6 in octet 3a shall be ignored by the network. 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 0 0 1 0 GSM full rate speech version 2 0 1 0 0GSM full rate speech version 3 0 0 0 1 GSM half rate speech version 1 0 1 0 1GSM half rate speech version 3 All other values have the meaning "speech version tbd" and shall be ignored when received. 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 04.08: 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) 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 04.08: 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 V.110/X.30 rate adaptation 1 0 ITU-T X.31 flag stuffing 1 1 Other rate adaption (see octet 5a) Signalling access protocol (octet 5) Bits 3 2 1 0 0 1 I.440/450 0 1 0 X.21 0 1 1 X.28 – dedicated PAD, individual NUI 1 0 0 X.28 – dedicated PAD, universal NUI 1 0 1 X.28 – non dedicated PAD 1 1 0 X.32 All other values are reserved.

Table 10.5.106/3GPP TS 04.08: 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. Bit 5 4 0 0 V.120 All other values are reserved.

Table 10.5.107/3GPP TS 04.08: 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 04.08: 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 04.08: 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 Rec. V.110 and X.30 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) Bits 4 3 2 1 0 0 0 1 0.3 kbit/s Recommendation X.1 and V.110 0 0 1 0 1.2 kbit/s Recommendation X.1 and V.110 0 0 1 1 2.4 kbit/s Recommendation X.1 and V.110 0 1 0 0 4.8 kbit/s Recommendation X.1 and V.110 0 1 0 1 9.6 kbit/s Recommendation X.1 and V.110 0 1 1 0 12.0 kbit/s transparent (non compliance with X.1 and V.110) 0 1 1 1 1.2 kbit/s/75 bit/s Recommendation V.23, (asymmetric) X.1,V.110. 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 04.08: Bearer capability information element

 Octet 6b for V.110/X.30 rate adaptation Intermediate rate (octet 6b) 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 Rec. V.110 and X.30) 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 Rec. V.110 and X.30) 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 04.08: 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 V.21 0 0 0 1 0 V.22 0 0 0 1 1 V.22 bis 0 0 1 0 0 V.23 0 0 1 0 1 V.26 ter 0 0 1 1 0 V.32 0 0 1 1 1 modem for undefined interface 0 1 0 0 0 autobauding type 1 All other values are reserved.

Table 10.5.112/3GPP TS 04.08: 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 Recommendation X.1 and V.110 0 0 0 1 0 14.4 kbit/s Recommendation X.1 and V.110 0 0 0 1 1 19.2 kbit/s Recommendation X.1 and V.110 0 0 1 0 0 28.8 kbit/s Recommendation X.1 and V.110 0 0 1 0 1 38.4 kbit/s Recommendation X.1 and V.110 0 0 1 1 0 48.0 kbit/s Recommendation X.1 and V.110(synch) 0 0 1 1 1 56.0 kbit/s Recommendation X.1 and V.110(synch) /bit transparent 0 1 0 0 0 64.0 kbit/s bit transparent All other values are reserved.

Table 10.5.113/3GPP TS 04.08: 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 04.08: Bearer capability information element

 UIMI, User initiated modification indication (octet 6f), 7 6 5 0 0 0 User initiated modification not allowed/required 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". 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 protocol1 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 04.08: 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 recommendation X.25, link level 0 1 0 0 0 ISO 6429, 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 X.75 layer 2 modified (CAPI) All other values are reserved.
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 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 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 and 6f are optional. In the network to MS direction in case octet 6d is included, octets 6e and 6f may be included. In the MS to network direction in case octet 6d is included octet 6e shall also be included and 6f 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 04.08 and table 10.5.116/3GPP TS 04.08.

The Call Control Capabilities is a type 4 information element with a length of 3 octets.

8 7 6 5 4 3 2 1

+———————————————–+

│ │ Call Control Capabilities IEI │ octet 1

+———————————————–│

│ │

│ Length of Call Control Capabilities contents │ octet 2

+———————————————–│

│ 0 0 0 0 0 0 │ │ │

│ spare │ PCP │DTMF │ octet 3

+———————————————–+

Figure 10.5.89/3GPP TS 04.08: Call Control Capabilities information element

Table 10.5.116/3GPP TS 04.08: 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 sub-clause 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. │

│ │

│ │

│ │

│ │

+————————————————————–+

10.5.4.6 Call state

The purpose of the call state information element is to describe the current status of a call, (see sub-clause 5.1).

The call state information element is coded as shown in figure 10.5.90/3GPP TS 04.08 and table 10.5.117/3GPP TS 04.08.

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 04.08: Call state information element

Table 10.5.117/3GPP TS 04.08: 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 N0.1- MM connection │

│ pending 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 N0.3- Network answer│

│ information pending │

│ 1 0 0 1 0 0 U0.4- CC-Establishment N0.4- CC-Establish- │

│ present ment present │

│ 1 0 0 1 0 1 U0.5- CC-Establishment N0.5- CC-Establish- │

│ confirmed ment 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 N3 – mobile origina-│

│ call proceeding ting 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 N9 – mobile termina-│

│ call confirmed ting 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 N26- mobile origina-│

│ modify ting modify │

│ 0 1 1 0 1 1 U27- mobile terminating N27- mobile termina-│

│ modify ting 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 04.08 and table 10.5.118/3GPP TS 04.08.

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 │ type of │ Numbering plan │

│ ext │ number │ 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 04.08: 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 04.08: 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 and 3GPP TS 03.03.

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 04.08: 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 │

│ (Rec. E.164/E.163) │

│ 0 0 1 1 data numbering plan (Recommendation X.121) │

│ 0 1 0 0 telex numbering plan (Recommendation F.69) │

│ 1 0 0 0 national numbering plan │

│ 1 0 0 1 private numbering plan │

│ 1 0 1 1 reserved for CTS (see 3GPP TS 04.56) │

│ 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 04.08: 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 Recommendation I.330.

The Called party subaddress information element is coded as shown in figure 10.5.92/3GPP TS 04.08 and table 10.5.119/3GPP TS 04.08

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 04.08: Called party subaddress

Table 10.5.119/3GPP TS 04.08: Called party subaddress

+——————————————————-+

│ Type of subaddress (octet 3) │

│ │

│ Bits │

│ 7 6 5 │

│ 0 0 0 NSAP (X.213/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: 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 ac- │

│ cording to the "preferred binary encoding" as defined │

│ in X.213/ISO8348AD2. For the definition of this type │

│ of subaddress, see Rec. ITU-T I.334. │

│ │

│ │

│ 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. When interworking with │

│ X.25 networks BCD coding should be applied. │

│ │

│ 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 standar- │

│ dised 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 04.08 and table 10.5.120/3GPP TS 04.08.

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 │ type of │ Numbering plan │

│ ext │ number │ 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 04.08: 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.

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 04.08: 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 Rec. ITU-T I.330.

The Calling party subaddress information element is coded as shown in figure 10.5.94/3GPP TS 04.08 and table 10.5.121/3GPP TS 04.08

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 04.08: Calling party subaddress

Table 10.5.121/3GPP TS 04.08: Calling party subaddress

+——————————————————-+

│ Type of subaddress (octet 3) │

│ │

│ Bits │

│ 7 6 5 │

│ 0 0 0 NSAP (X.213/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 ac- │

│ cording to the "preferred binary encoding" as defined │

│ in X.213/ISO8348AD2. For the definition of this type │

│ of this type of subaddress, see Rec. ITU-T I.332. │

│ │

│ │

│ 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. When interworking with │

│ X.25 networks BCD coding should be applied. │

│ │

│ 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 standar- │

│ dised 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 04.08 and tables 10.5.122 and 10.5.123/3GPP TS 04.08.

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 │ coding │ 0 │ │

│ ext │ standard │spare│ location │ octet 3

+—–+—————————————–│

│ 1 │ │ octet 3a*

│ ext │ recommendation │

+—–+—————————————–│

│ 1 │ │

│ ext │ cause value │ octet 4

+———————————————–│

│ │

│ diagnostic(s) if any │ octet 5*

: :

: : octet N*

+———————————————–+

Figure 10.5.95/3GPP TS 04.08: Cause information element

If the default value applies for the recommendation field, octet 3a shall be omitted.

Table 10.5.122/3GPP TS 04.08: 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.86/GSMß04.08 │

│ │

│ 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. │

│ │

│ │

│ 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.86/GSMß04.08 below │

│ and defined in Annex H. │

│ │

│ Diagnostic(s) (octet 5) │

│ Diagnostic information is not available for every cause, see│

│ Table 10.86/GSMß04.08 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 04.08: 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) │ Note 9│

│ │ │number │ │

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

0 0 0│0 1 1 0│ 6. │Channel unacceptable │ – │

0 0 0│1 0 0 0│ 8. │Operator determined barring │ – │

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

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

0 0 1│0 0 1 0│ 18. │No user responding │ – │

0 0 1│0 0 1 1│ 19. │User alerting, no answer │ – │

0 0 1│0 1 0 1│ 21. │Call rejected │ Note 9 – user

│ │ │ │ supplied diag-

│ │ │ │nostic (note 4)

0 0 1│0 1 1 0│ 22. │Number changed │New destination

│ │ │ │ (note 5)

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 (in- │ – │

│ │ │complete 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 conges- │ – │

│ │ │tion │ │

0 1 0│1 0 1 1│ 43. │Access information discarded│Discarded info-

│ │ │ │ mation 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, un- │ – │

│ │ │specified │ │

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

│ │ │unavailable │ │

0 1 1│0 0 1 0│ 50. │Requested facility not sub- │ Note 1│

│ │ │scribed │ │

0 1 1│0 1 1 1│ 55. │Incoming calls barred with- │ Note 1│

│ │ │in the CUG │ │

0 1 1│1 0 0 1│ 57. │Bearer capability not au- │ Note 3│

│ │ │thorized │ │

0 1 1│1 0 1 0│ 58. │Bearer capability not pre- │ Note 3│

│ │ │sently available │ │

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 │ Note 3│

│ │ │implemented │ │

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 │ Note 1│

│ │ │implemented │ │

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 iden- │ │

│ │ │ tifier 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 se-│ – │

│ │ │lection │ │

1 0 1│1 1 1 1│ 95. │Semantically incorrect │ – │

│ │ │message │ – │

1 1 0│0 0 0 0│ 96. │Invalid mandatory informa- │ Information

│ │ │tion │ element

│ │ │ │ identifier(s)

1 1 0│0 0 0 1│ 97. │Message type non-existent │ Message type

│ │ │or not implemented │ │

1 1 0│0 0 1 0│ 98. │Message type not compatible│ Message type

│ │ │with protocol state │ │

1 1 0│0 0 1 1│ 99. │Information element non-ex-│ Information

│ │ │istent or not implemented │ 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│ Message type

│ │ │protocol state │ │

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 sub-clause 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 04.08 and tables 10.5.102/3GPP TS 04.08 to 10.5.115/3GPP TS 04.08.

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 sub-clauses 10.5.4.2 and 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 04.81.

The CLIR suppression information element is coded as shown in figure 10.5.96/3GPP TS 04.08.

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 04.08: 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 04.81.

The CLIR invocation information element is coded as shown in figure 10.5.97/3GPP TS 04.08.

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 04.08: 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 04.08 and table 10.5.124/3GPP TS 04.08.

The congestion level is a type 1 information element.

8 7 6 5 4 3 2 1

+———————————————–+

│ │Congestion level │ │ octet 1

│ │ IEI │ │

+———————————————–+

Figure 10.5.98/3GPP TS 04.08: Congestion level information element

Table 10.5.124/3GPP TS 04.08: 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 04.08

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 │ Type of number │ Number plan │ octet 3

│ ext │ │ identification │ 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 04.08

The contents of octets 3,4,5, etc. … are coded as shown in table 10.5.118/3GPP TS 04.08. The coding of octet 3a is defined in table 10.5.120/3GPP TS 04.08.

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".

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 04.08

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

+————————————————│

│ 1 │ Type of odd/even 0 0 0 │ octet 3*

│ ext │ subaddress indicator Spare │

+————————————————│

│ Subaddress information │ octet 4*

: : :

: : : etc.

+————————————————+

Figure 10.5.100/3GPP TS 04.08

The coding for Type of subaddress, odd/even indicator, and subaddress information is in table 10.5.119/3GPP TS 04.08.

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 04.08 the content of the Facility information field is an array of octets. The usage of this transportation mechanism is defined in 3GPP TS 04.80.

The facility information element is coded as shown in figure 10.5.101/3GPP TS 04.08

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 04.06).

8 7 6 5 4 3 2 1

+————————————————+

│ │ Facility IEI │ octet 1

+————————————————│

│ Length of facility contents │ octet 2

+————————————————│

│ Facility information (see GSMß04.80) │ octet 3-?*

+————————————————+

Figure 10.5.101/3GPP TS 04.08

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 04.08 and table 10.5.125/3GPP TS 04.08.

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 │ coding │ │presentat. │

│ ext │ standard │ interpretation │method of │ octet 3*

│ │ │ │protocol │

│ │ │ │profile │

+—–+—————————————–│

│ 0/1 │ │ octet 4*

│ ext │High layer characteristics identification│

+—–+—————————————–│

│ 1 │ Extended high layer characteristics │octet 4a*

│ ext │ identification │ (note)

+———————————————–+

Figure 10.5.102/3GPP TS 04.08: 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.

Table 10.5.125/3GPP TS 04.08: High layer compatibility information element

+——————————————————+

│ Coding standard (octet 3) │

│ see ITU-T Recommendation Q.931. │

│ │

│ │

│ Interpretation (octet 3) │

│ see ITU-T Recommendation Q.931. │

│ │

│ │

│ Presentation method of protocol profile (octet 3) │

│ see ITU-T Recommendation Q.931. │

│ │

│ │

│ High layer characteristics identification (octet 4) │

│ see ITU-T Recommendation Q.931. │

│ │

│ Extended high layer characteristics identification │

│ (octet 4a) │

│ see ITU-T 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.

The purpose of the keypad facility information element is to convey IA5 characters, e.g. entered by means of a terminal keypad. (Note).

The keypad facility information element is coded as shown in figure 10.5.103/3GPP TS 04.08.

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 04.08: Keypad facility information element

NOTE: In the GSM 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 ETS 300 102-1.

The low layer compatibility is a type 4 information element with a minimum length of 2 octets and a maximum length of 15 octets.

8 7 6 5 4 3 2 1

+———————————————–+

│ │ Low layer compatibility IEI │ octet 1

+———————————————–│

│ Length of the low layer compatibility contents│ octet 2

+———————————————–│

│ │ octet 3*

│ The following octets are coded │

│ as described in ETS 300 102-1 │ :

│ │

│ │ :

+———————————————–+

Figure 10.5.104/3GPP TS 04.08: 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 04.08.

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 04.08: More data information element

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 04.08 and table 10.5.126/ 3GPP TS 04.08.

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 │ │ octet 2

│ ext │ Notification description │

+———————————————–+

Figure 10.5.106/3GPP TS 04.08: Notification indicator information element

Table 10.5.126/3GPP TS 04.08: 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 04.08 and table 10.5.127/3GPP TS 04.08.

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 │ coding │ 0 │ │

│ ext │ standard │spare│ location │ octet 3

+—–+—————————————–│

│ 1 │ │ octet 4

│ ext │ progress description │

+———————————————–+

Figure 10.5.107/3GPP TS 04.08: Progress indicator information element

Table 10.5.127/3GPP TS 04.08: 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 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 04.08 and Table 10.5.128/3GPP TS 04.08.

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 04.08: Recall type information element

Table 10.5.128/3GPP TS 04.08: 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 │

│ 1 1 0 } similar types of Recall) │

│ 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.88a.

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/1ext type ofnumber Numbering planidentification octet 3(note 1) 1ext presentat.indicator 0 0 0spare Screeningindicator octet 3a*(note 1) Number digit 2 Number digit 1 octet 4*(note 1) Number digit 4 Number digit 3 octet 5*(note 1) : Note 2) :

NOTE 1: The contents of octets 3, 4, etc. are coded as shown in Table 10.81. The coding of octet 3a is defined in table 10.83.

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".

Figure 10.88a/3GPP TS 04.08: Redirecting party BCD number information element

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.88b and Table 10.84.

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 1ext type ofsubaddress odd/evIndica 0 0 0 octet 3* Subaddress information: octet 4* : etc.

Figure 10.88b/3GPP TS 04.08: 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 04.08 and table 10.5.129/3GPP TS 04.08.

The repeat indicator is a type 1 information element.

8 7 6 5 4 3 2 1

+———————————————–+

│ │repeat indicator │ repeat indication │ octet 1

│ │ IEI │ │

+———————————————–+

Figure 10.5.109/3GPP TS 04.08: Repeat indicator information element

Table 10.5.129/3GPP TS 04.08: 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 1 Sequential for successive selection │

│ "mode 1 and then mode 2" │

│ │

│ 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 04.08.

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 04.08: 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 04.08

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 04.06).

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 04.08: 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 sub-clauses 5.2.2.3.2 and 7.3.3.).

The signal information element is coded as shown in figure 10.5.112/3GPP TS 04.08 and table 10.5.130/3GPP TS 04.08.

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 04.08: Signal information element

Table 10.5.130/3GPP TS 04.08: 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 04.10. Within the scope of 3GPP TS 04.08 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 04.80.

The SS version indicator information element is coded as shown in figure 10.5.113/3GPP TS 04.08

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 04.06).

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 GSMß04.80) │ octet 3*

│ │

│ │ : *

│ │

│ │ : *

+————————————————+

Figure 10.5.113/3GPP TS 04.08

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 04.08 and table 10.5.131/ 3GPP TS 04.08. 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 04.08: User-user information element

Table 10.5.131/3GPP TS 04.08: 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 Rec.V.120 rate adaption │

│ 0 0 0 0 1 0 0 0 Q.931 (I.451) user-network call control │

│ messages │

│ │

│ 0 0 0 1 0 0 0 0 Reserved for other network layer or │

│ through layer 3 protocols including Rec.X.25 │

│ 0 0 1 1 1 1 1 1 (Note 4) │

│ │

│ 0 1 0 0 0 0 0 0 │

│ through National use │

│ 0 1 0 0 1 1 1 1 │

│ │

│ 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 including Rec.X.25 (Note 4) │

│ │

│ 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│

│ Rec.X.244 which specifies the structure of X.25 call│

│ user data. │

│ │

│Note 3: The user information consists of IA5 characters. │

│ │

│Note 4: These values are reserved to discriminate these│

│ protocol discriminators from the first octet of a│

│ X.25 packet including general format identifier. │

+————————————————————+

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 02.07).

The Alerting Pattern information element is coded as shown in figure 10.5.115/3GPP TS 04.08 and table 10.5.132/3GPP TS 04.08.

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 04.08: Alerting Pattern information element

Table 10.5.132/3GPP TS 04.08: 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 04.08 and table 10.5.133/3GPP TS 04.08

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 04.08: Allowed actions information element

Table 10.5.133/3GPP TS 04.08: Allowed actions information element

+———————————————————+

│ CCBS activation (octet 3) │

│ │

│ Bit │

│ 8 │

│ 0 Activation of CCBS not possible │

│ 1 Activation of CCBS possible │

+———————————————————+