3 General message format and information elements coding

04.803GPPMobile Radio Interface Layer 3 - Supplementary Services Specification Formats and CodingRelease 1998TS

The figures and text in this clause describe message contents. Within each octet, the bit designated "bit 1" is transmitted first, followed by bits 2, 3, 4, etc. Similarly, the octet shown at the top of each figure is sent first.

3.1 Overview

Within the layer 3 protocol defined in GSM 04.80, every message is a standard L3 message as defined in GSM 04.07. This means that the message consists of the following parts:

a) protocol discriminator;

b) transaction identifier;

c) message type;

d) other information elements, as required.

Unless specified otherwise, a particular information element may be present only once in a given message.

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field.

3.2 Protocol discriminator

The Protocol Discriminator (PD) and its use are defined in GSM 04.07. GSM 04.80 defines the protocols relating to the PD values:

1 0 1 1 supplementary services (call independent).

3.3 Transaction identifier

For general rules, format and coding of transaction identifier values, see GSM 04.08.

3.4 Message type

The message type IE and its use are defined in GSM 04.07. Table 3.1 defines the value part of the message type IE used in the supplementary service protocol.

Table 3.1: Message types

8

7

6

5

4

3

2

1

Message types

0

x

1

0

.

.

.

.

Clearing messages:

1

0

1

0

– RELEASE COMPLETE

0

x

1

1

.

.

.

.

Miscellaneous message group:

1

0

1

0

– FACILITY

1

0

1

1

– REGISTER

NOTE 1: Bit 8 is reserved for possible future use as an extension bit, see GSM 04.07.

NOTE 2: Bit 7 is reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bit 7 is coded with a "0", see GSM 04.07.

3.5 Other information elements

These information elements are coded according to the general coding rules as defined in GSM 04.08.

Table 3.2 contains the code-points allocated to the information elements used in messages defined in the present document. All IEs are defined in GSM 04.08, but the content of the Facility and SS version indicator IEs are defined within the present document.

Table 3.2: Information elements specific to call independent supplementary service control

8 7 6 5 4 3 2 1

Reference
(IE content)

0 . . . . . . .

Type 3 and 4 information elements

0 0 0 1 0 0 0

Cause

GSM 04.08

0 0 1 1 1 0 0

Facility

3.6

1 1 1 1 1 1 1

SS version indicator

3.8.2

3.6 Facility information element

The purpose of the Facility information element is to indicate the invocation and operation of supplementary services, identified by the corresponding operation code within the Facility information element.

The Facility information element is coded as shown in figure 3.1 and tables 3.3 to 3.17.

The Facility is a type 4 information element with no upper length limit except that given by the maximum number of octets in a L3 message, see GSM 04.06.

8

7

6

5

4

3

2

1

0

0

0

1

1

1

0

0

octet 1

Facility IEI

Length of Facility contents

octet 2

Component(s) (note)

octet 3 etc.

NOTE: One or more components may be included depending on specific service requirements.

Figure 3.1: Facility information element

3.6.1 Component (octet 3 etc.)

This subclause provides the formats and encoding of components in the Facility information element. Formats and encoding methods make use of and is a subset of CCITT Recommendation Q.773 (Transaction Capabilities formats and Encoding) and T/S 43/BB. The used part of CCITT Recommendation Q.773 respectively T/S 43/BB is almost the same as the Component Portion of TC messages. The only difference is that returnResultNotLast is not used.

This subclause is further based on:

– CCITT Recommendation X.208 (Specification of Abstract Syntax Notation One (ASN.1));

– CCITT Recommendation X.209 (Specification of basic encoding rules for Abstract Syntax Notation One);

and is consistent with these CCITT recommendations.

The CCITT Recommendations X.208 and X.209 formal description language is not used.

The parameters in tables 3.3 to 3.6 may be one of the following:

– a Sequence of Parameters;

– a Set of Parameters;

– a specific Parameter with its own tag (i.e. not part of a Sequence or Set);

– nothing at all (i.e. absent).

NOTE: Concerning the general rules for encoding (structure of encoding, identifier octets, length octets, etc.) see CCITT Recommendations X.208 and X.209. For these general rules the same exceptions apply as stated in GSM 09.02. This holds also for tables 3.3 to 3.6.

Table 3.3: Invoke component

Invoke component

Reference

Mandatory indication

Component type tag

3.6.2

M

Component length

X.209

Invoke ID tag

3.6.3

Invoke ID length

X.209

M

Invoke ID

3.6.3

Linked ID tag

3.6.3

Linked ID length

X.209

O

Linked ID

3.6.3

Operation Code tag

3.6.4

Operation Code length

X.209

M

Operation Code

3.6.4

Parameters

4

O

Table 3.4: Return Result component

Return Result component

Reference

Mandatory indication

Component type tag

3.6.2

M

Component length

X.209

Invoke ID tag

3.6.3

Invoke ID length

X.209

M

Invoke ID

3.6.3

Sequence tag

3.6.5

O (note)

Sequence length

X.209

Operation Code tag

3.6.4

Operation Code length

X.209

O (note)

Operation Code

3.6.4

Parameters

4

O (note)

NOTE: Omitted if the Return Result component does not include any parameters.

Table 3.5: Return Error component

Return Error component

Reference

Mandatory indication

Component type tag

3.6.2

M

Component length

X.209

Invoke ID tag

3.6.3

Invoke ID length

X.209

M

Invoke ID

3.6.3

Error Code tag

3.6.6

Error Code length

X.209

M

Error Code

3.6.6

Parameters

4

O

Table 3.6: Reject component

Reject component

Reference

Mandatory indication

Component type tag

3.6.2

M

Component length

X.209

Invoke ID tag (note)

3.6.3

Invoke ID length

X.209

M

Invoke ID

3.6.3

Problem Code tag

3.6.7

Problem Code length

X.209

M

Problem Code

3.6.7

NOTE: If the Invoke ID is not available, Universal Null (table 3.9) with length = 0 shall be used.

3.6.2 Component type tag

The Component type tag is coded context-specific, constructor as indicated in table 3.7.

Table 3.7: Coding of Component type tag

Component type tag

8 7 6 5 4 3 2 1

Invoke

1 0 1 0 0 0 0 1

Return Result

1 0 1 0 0 0 1 0

Return Error

1 0 1 0 0 0 1 1

Reject

1 0 1 0 0 1 0 0

3.6.3 Component ID tag

The term Component ID refers to the Invoke ID or the Linked ID. The Component ID tag is coded as shown in table 3.8.

Table 3.8: Coding of Component ID tag

Component ID tag

8 7 6 5 4 3 2 1

Invoke ID

0 0 0 0 0 0 1 0

Linked ID (note)

1 0 0 0 0 0 0 0

NOTE: This tag differs from the Invoke ID tag, which is coded as a Universal INTEGER, in order to distinguish it from the following tag (Operation Code) which is also coded as a Universal INTEGER.

The length of a Component ID is 1 octet.

An Invoke Component has one or two Component IDs: an Invoke ID, and if it is desired to associate the Invoke with a previous Invoke, then the Linked ID is provided in addition to the Invoke ID.

Return Result and Return Error Components have one Component ID, called an Invoke ID which is the reflection of the Invoke ID of the Invoke Component to which they are responding.

The Reject Component uses as its Invoke ID, the Invoke ID in the Component being rejected. If this ID is unavailable (e.g. due to mutilation of the message not detected by lower layers), then the Invoke ID tag is replaced with a universal NULL tag as shown in table 3.9. Universal NULL has always length = 0

Any kind of component, except a reject component, may be rejected.

Table 3.9: Coding of NULL tag

8 7 6 5 4 3 2 1

NULL tag

0 0 0 0 0 1 0 1

If an Invoke containing both Invoke and Linked IDs is being rejected, only the Invoke ID is used in the Reject Component.

3.6.4 Operation Code

Each Operation is assigned an Operation Code to identify it. An Operation Code follows an Operation Code tag and Operation Code length. The Operation Code tag is coded as shown in table 3.10.

Table 3.10: Coding of Operation Code tag

8 7 6 5 4 3 2 1

Operation Code tag

0 0 0 0 0 0 1 0

The Operation Codes for the different Operations are defined in subclause 4.5.

3.6.5 Sequence and Set tags

When there is more than one parameter in a Component (applicable to all Component types), they follow the Sequence or Set tag, which are coded universal, constructor as shown in table 3.11.

Table 3.11: Coding of Sequence and set tags

Sequence and set tags

8 7 6 5 4 3 2 1

Sequence tag

0 0 1 1 0 0 0 0

Set tag

0 0 1 1 0 0 0 1

3.6.6 Error Code

Each Error is assigned a value (Error Code) to identify it.

An Error Code follows an Error Code tag and Error Code length. The Error Code tag is coded as shown in table 3.12.

Table 3.12: Coding of Error Code tag

8 7 6 5 4 3 2 1

Error Code tag

0 0 0 0 0 0 1 0

The Error Codes for the different Errors are defined in subclause 4.5.

3.6.7 Problem Code

The Problem Code consists of one of the four elements: General Problem, Invoke Problem, Return Result Problem or Return Error Problem. The tags for these elements are coded as shown in table 3.13.

Table 3.13: Coding of Problem tags

Problem tags

8 7 6 5 4 3 2 1

General Problem tag

1 0 0 0 0 0 0 0

Invoke Problem tag

1 0 0 0 0 0 0 1

Return Result Problem tag

1 0 0 0 0 0 1 0

Return Error Problem tag

1 0 0 0 0 0 1 1

The Problem Codes for the different Problems are shown in tables 3.14 to 3.17.

Table 3.14: Coding of General Problem Codes

General Problem Codes

8 7 6 5 4 3 2 1

Unrecognized Component

0 0 0 0 0 0 0 0

Mistyped Component

0 0 0 0 0 0 0 1

Badly Structured Component

0 0 0 0 0 0 1 0

Table 3.15: Coding of Invoke Problem Codes

Invoke Problem Codes

8 7 6 5 4 3 2 1

Duplicate Invoke ID

0 0 0 0 0 0 0 0

Unrecognized Operation

0 0 0 0 0 0 0 1

Mistyped Parameter

0 0 0 0 0 0 1 0

Resource Limitation

0 0 0 0 0 0 1 1

Initiating Release

0 0 0 0 0 1 0 0

Unrecognized Linked ID

0 0 0 0 0 1 0 1

Linked Response Unexpected

0 0 0 0 0 1 1 0

Unexpected Linked Operation

0 0 0 0 0 1 1 1

Table 3.16: Coding of Return Result Problem Codes

Return Result Problem Codes

8 7 6 5 4 3 2 1

Unrecognized Invoke ID

0 0 0 0 0 0 0 0

Return Result Unexpected

0 0 0 0 0 0 0 1

Mistyped Parameter

0 0 0 0 0 0 1 0

Table 3.17: Coding of Return Error Problem Codes

Return Error Problem Codes

8 7 6 5 4 3 2 1

Unrecognized Invoke ID

0 0 0 0 0 0 0 0

Return Error Unexpected

0 0 0 0 0 0 0 1

Unrecognized Error

0 0 0 0 0 0 1 0

Unexpected Error

0 0 0 0 0 0 1 1

Mistyped Parameter

0 0 0 0 0 1 0 0

3.7 Version handling for supplementary services

3.7.1 Supplementary service screening indicator

The purpose of the supplementary service screening indicator is to allow the network to asses the capabilities of the MS in advance of a network initiated SS activity. The SS screening indicator is sent in the mobile station classmark 2 as defined in GSM 04.08. The handling of the SS screening indicator is described in GSM 04.10.

8

7

6

5

4

3

2

1

(note)

(note)

SS screening indicator

(note)

NOTE: Values not relevant to supplementary services.

Figure 3.2: Coding of SS screening indicator in mobile station classmark 2

Table 3.18: Coding of SS screening indicator in mobile station classmark 2

SS screening indicator in mobile station classmark 2

6

5

default value of phase 1

0

0

capability of handling of ellipsis notation and phase 2 error handling (note 1)

0

1

for future use (note 2)

1

0

for future use (note 2)

1

1

NOTE 1: Ellipsis notation is described in GSM 04.10 and GSM 09.02. SS Error handling is described in GSM 04.10.

NOTE 2: The network shall interpret these values the same as "01".

3.7.2 Supplementary service version indicator

The purpose of the supplementary service version indicator is to allow the network to select the correct version of a protocol for a specific supplementary service. The SS version indicator is included in messages as defined in GSM 04.08 and GSM 04.80. The coding described in table 3.19 refers to the first octet received in the SS version indicator. Any other octets received shall be ignored. The handling of the SS version indicator is described in GSM 04.10.

Table 3.19: Coding of SS version indicator

SS version indicator

8 7 6 5 4 3 2 1

phase 2 service, ellipsis notation, and

phase 2 error handling is supported (note 1)

0 0 0 0 0 0 0 0

SS-Protocol version 3 is supported, and

phase 2 error handling is supported (note 1)

all other values are for future use (note 2)

0 0 0 0 0 0 0 1

NOTE 1: Ellipsis notation is described in GSM 04.10 and GSM 09.02. SS Error handling is described in GSM 04.10.

NOTE 2: The network shall interpret all higher values of the SS version indicator the same as "00000001".