11 L3 Messages

04.073GPPMobile Radio Interface Signalling Layer 3 - General AspectsTS

This clause specifies the generic methods used in the layer 3 protocol specifications to describe messages. It define in particular a generic message structure, that of the "standard L3 messages". Not all messages in layer 3 protocols follow this structure, but many do, and this section specifies how to interpret the standard description.

This clause also addresses basic aspects of the handling of messages received but not compliant with the allowed structure. In most cases, only the conditions that lead to the diagnosis of an error are described. The reaction of an entity receiving a message leading to such a diagnosis is in general specified for each protocol in the relevant protocol specification.

11.1 General

11.1.1 Messages

For all concerned protocols, concrete messages are bit strings of variable length, formally a succession of a finite, possibly null, number of bits (i.e., elements of the set {"0", "1"}), with a beginning and an end.

The services provided by lower layers includes the transmission of such bit strings.

Considered as messages, these bit strings follow some structure (the syntax), enabling to organise bits in information pieces of a different meaning level.

The term message is used as well for a concrete message (i.e., a bit-string, as defined by the giving of all its bits, in practice appearing at one point of time in a concrete dialog), as for a class of concrete messages sharing a common structure. A concrete message is an instance of the corresponding class of messages. Message classes can be described as sets of potential bit strings, and of a common structure, enabling in particular to identify parts meaningful for the co-operation functions the protocol supports.

In general, in the rest of the clause as in the protocol specifications, the term message will be used to refer to the class. It may be used, when the context prevents ambiguity, to refer to a message instance (e.g., a received is usually a message instance). In the rest of this clause, the term message instance will be used when needed to refer unambiguously to specific concrete message, i.e., to a specific bit string.

A message (message class) can be described directly as a set of bit strings, using the formal notation described in Annex B.

A message can also be described as a standard L3 message, in which case the interpretation of the message description in term of a set of bit strings is specified in the next sub-clauses.

In all cases, structuring messages is based on the underlying bit string. Thus, the following terms are used :

a part of a message instance is a sub-string of the corresponding string ; a part of a message (as a class) is described by a definition applicable to all instances; a part of a message then is both a structural attribute of the message as a class, and a set of sub-strings, composed of the sub-strings obtained by applying the definition to each possible instance ; for instance, « the first octet » of a message instance is defined from the moment its length is greater than 8, and is the sub-string composed of the first 8 bits of the message instance; the « first octet » of a message as a class is the structural definition given above, and the set of all 8-bit octet strings that can be obtained as the first octet of one instance of the class.

‘part A follows part B’ means that in the message the sub-string corresponding to part B is concatenated with the sub-string of part B ;

the length of a message instance, or of part of message instance, is the number of bits of the corresponding sub string ; rigorously speaking, a message as a class (or a part seen as a class) has a length only if all the corresponding instances have the same length ; by extension, sentences such as « a message as a length in the range so and so » means that the length of an instances of the class always fall in the range ;

11.1.2 Octets

In many places, a message is described as a succession of octets. An octet is generally a succession of 8 bits. Unless otherwise indicated, the term octet is used more restrictively to refer to a part of message, defined when considering a message as a succession of octets, e.g., the first 8 bits of a message, or the 17th to the 23rd, form an octet, but not the second bit to the 9th.

Unless specified otherwise, the numbering conventions are the following :

Octets in a message or in a part are numbered from 1 onward, starting at the beginning of the bit string. This numbering can be strictly applied only for message instances, and for the first part of a message structurally identical for all instances.

Bits in octets are numbered from 8 down to 1, starting at the beginning of the octet.

When represented as tables showing the different bit positions, octets are presented in the natural occidental order, i.e., from the top of a page downward. Bits in octets are presented with the first bit on the left of the page.

11.1.3 Integer

In many places, message parts are described as encoding integers. Two generic encoding are defined in this sub-clause.

11.1.3.1 Binary

A message part is said to encode in binary an integer to indicate that concrete strings are mapped, for some usage, on the set of non signed integers with the following rule :

Let k denote the length of the bit string, and let b(i) denote an integer of value 0 if the ith bit in the string is "0", and 1 otherwise. The encoded integer n respects the equation :

11.1.3.2 2-complement binary

A message part is said to encode in 2-complement binary an integer to indicate that concrete strings are mapped, for some usage, on the set of signed integers with the following rule :

Let k denote the length of the bit string, and let b(i) denote an integer of value 0 if the ith bit in the string is "0", and 1 otherwise. The encoded integer n respects the equation :

11.1.4 Spare parts

In some cases the specification is that which message instances can be accepted by a receiver comprise more that the legal message instances that can be sent. One example of this is the notion of spare bit. A spare bit has to send as the value indicated in the specification (typically 0), but can be accepted as a 0 or a 1 by the receiver without error diagnosis. A spare field is a field composed entirely of spare bits.

11.2 Standard L3 messages

11.2.1 Components of a standard L3 message

A standard L3 message consists of an imperative part, itself composed of a header and the rest of imperative part, followed by a non-imperative part. Both the non-header part of the imperative part and the non-imperative part are composed of successive parts referred as standard information elements.

11.2.1.1 Format of standard information elements

A standard IE may have the following parts, in that order:

– an information element identifier (IEI);

– a length indicator (LI);

– a value part.

A standard IE has one of the formats shown in table 11.1:

Table 11.1: Formats of information elements

Format

Meaning

IEI present

LI present

Value part present

T

Type only

yes

no

no

V

Value only

no

no

yes

TV

Type and Value

yes

no

yes

LV

Length and Value

no

yes

yes

TLV

Type, Length and Value

yes

yes

yes

Some IEs may appear in the structure, but not in all instances of messages. An IE is then said to be present or not present in the message instance. If an IE is not present in a message instance, none of the three parts is present. Otherwise, parts must be present according to the IE format.

In the message structure, an IE that is allowed not to be present in all message instances is said not to be mandatory. Other IEs are said to be mandatory.

11.2.1.1.1 Information element type and value part

Every standard IE has an information element type which determines the values possible for the value part of the IE, and the basic meaning of the information. The information element type describes only the value part. Standard IEs of the same information element type may appear with different formats. The format used for a given standard IE in a given message is specified within the description of the message.

The value part of a standard IE either consists of a half octet or one or more octets; the value part of a standard IE with format LV or TLV consists of an integral number of octets, between 0 and 255 inclusive ; it then may be empty, i.e., consist of zero octets; if it consists of a half octet and has format TV, its IEI consists of a half octet, too. The value part of a standard IE may be further structured into parts, called fields.

11.2.1.1.2 Length indicator

When present, the LI of a standard IE consists of one octet. It contains the binary encoding of the number of octets of the IE value part. The length indicator of a standard IE with empty value part indicates 0 octets. Standard IE of an information element type such that the possible values may have different values must be formatted with a length field, i.e., LV or TLV.

11.2.1.1.3 Information element identifier

When present, the IEI of a standard IE consists of a half octet or one octet. A standard IE with IEI consisting of a half octet has format TV, and its value part consists of a half octet. The value of the IEI depends on the standard IE, not on its information element type. The IEI, if any, of a given standard IE in a given message is specified within the description of the message. In some protocol specifications, default IEI values can be indicated. They are to be used if not indicated in the message specification. Non mandatory standard IE in a given message, i.e., IE which may be not be present (formally, for which the null string is acceptable in the message), must be formatted with an IEI, i.e., with format T, TV or TLV.

11.2.1.1.4 Categories of IEs; order of occurrence of IEI, LI, and value part

Totally four categories of standard information elements are defined:

– information elements of format V or TV with value part consisting of 1/2 octet (type 1);

– information elements of format T with value part consisting of 0 octets (type 2);

– information elements of format V or TV with value part that has fixed length of at least one octet (type 3);

– information elements of format TLV or LV with value part consisting of zero, one or more octets (type 4);

Type 1 standard information elements of format V provide the value in bit positions 8, 7, 6, 5 of an octet (see figure 11.1) or bits 4, 3, 2, 1 of an octet (see figure 11.2).

Figure 11.1: Type 1 IE of format V

Figure 11.2: Type 1 IE of format V

Type 1 standard information elements of format TV have an IEI of a half octet length; they provide the IEI in bit positions 8, 7, 6, 5 of an octet and the value part in bit positions 4, 3, 2, 1 of the same octet, see figure 11.3.

Figure 11.3: Type 1 IE of format TV

A type 2 standard IE has format T; its IEI consists of one octet, its value part is empty, see figure 11.4.

Figure 11.4: Type 2 IE

A type 3 standard information element has format V or TV; if it has format TV, its IEI consists of one octet and proceeds the value part in the IE. The value part consists of at least one octet. See figure 11.5 and figure 11.6.

Figure 11.5: Type 3 IE of format V (k = 0, 1, 2, …)

Figure 11.6: Type 3 IE of format TV (k = 1, 2, …)

A type 4 standard information element has format LV or TLV. Its LI precedes the value part, which consists of zero, one, or more octets; if present, its IEI has one octet length and precedes the LI. See figure 11.7 and figure 11.8.

Figure 11.7: Type 4 IE of format LV (k = 0, 1, 2, …)

Figure 11.8: Type 4 IE of format TLV (k = 1, 2, …)

11.2.2 Description methods for IE structure

Standard IEs can be further structured in parts called fields. Two description methods are recommended and described hereafter.

11.2.2.1 Tables

According to this description method, the IE is presented in its maximum format, i.e., T, TV or TLV, in a picture representing the bits in a table, each line representing an octet. Bits appear in the occidental order, i.e., from left of the page to right of the page, and from top of the page to bottom of the page.

Boxes so delimited contains typically the field name, possibly an indication of which bits in the field are in the box, and possibly a value (e.g., for spare bits).

A specific method can be used in the IE description to describe a branching structure, i.e., a structure variable according to the value of particular fields in the IE. This design is unusual outside type 4 IEs, and as, a design rule, should be used only in type 4 IEs.

a) The octet number of an octet within the IE is defined typically in the table. It consists of a positive integer, possibly of an additional letter, and possibly of an additional asterisk, see clause f). The positive integer identifies one octet or a group of octets.

b) Each octet group is a self contained entity. The internal structure of an octet group may be defined in alternative ways.

c) An octet group is formed by using some extension mechanism. The preferred extension mechanism is to extend an octet (N) through the next octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an extension bit.

The bit value "0" indicates that the octet group continues through to the next octet. The bit value "1" indicates that this octet is the last octet of the group. If one octet (Nb) is present, the preceding octets (N and Na) shall also be present.

In the format descriptions appearing in section 10.5.1 to 10.5.4, bit 8 is marked "0/1 ext" if another octet follows. Bit 8 is marked "1 ext" if this is the last octet in the extension domain.

Additional octets may be defined in later versions of the protocols ("1 ext" changed to "0/1 ext") and equipments shall be prepared to receive such additional octets; the contents of these octets shall be ignored. However the length indicated in sections 9 and 10 only takes into account this version of the protocols.

d) In addition to the extension mechanism defined above, an octet (N) may be extended through the next octet(s) (N+1, N+2 etc.) by indications in bits 7-1 (of octet N).

e) The mechanisms in c) and d) may be combined.

f) Optional octets are marked with asterisks (*). As a design rule, the presence of absence of an optional octet should be determinable from information in the IE and preceding the optional octet. Care should be taken not to introduce ambiguities with optional octets.

11.2.2.1.1 Compact notation

The compact notation described in Annex B can be used to describe the value part of a standard IE. This method is recommended for complex structures, or for a branching structure not respecting octet boundaries.

11.2.3 Imperative part of a standard L3 message

The imperative part of a standard L3 message is composed a header possibly followed by mandatory standard IEs having the format V or LV.

11.2.3.1 Header

The header of a standard L3 message is composed of two octets, and structured in three main parts, the protocol discriminator (1/2 octet), a message type octet, and a half octet used in some cases as a Transaction Identifier, in some other cases as a sub-protocol discriminator, and called skip indicator otherwise.

11.2.3.1.1 Protocol discriminator

Bits 1 to 4 of the first octet of a standard L3 message contain the protocol discriminator (PD) information element. The PD identifies the L3 protocol to which the standard layer 3 message belongs. The correspondence between L3 protocols and PDs is one-to-one.

For future evolution an extension mechanism is foreseen which allows the use of protocol discriminators with one octet length, where bits 4 to one are coded as 1 1 1 0. Messages of such protocols may not be standard L3 messages. In particular, the rest of the header may not respect the structure described in this sub-clause.

The PD can take the following values:

Table 11.2: Protocol discriminator values

bits 4 3 2 1

0 0 0 0

group call control

0 0 0 1

broadcast call control

0 0 1 0

PDSS1

0 0 1 1

call control; call related SS messages

0 1 0 0

PDSS2

0 1 0 1

mobility management messages

0 1 1 0

radio resources management messages

1 0 0 0

GPRS mobility management messages

1 0 0 1

SMS messages

1 0 1 0

GPRS session management messages

1 0 1 1

non call related SS messages

1 1 0 0

Location services

1 1 1 0

reserved for extension of the PD to one octet length

1 1 1 1

reserved for tests procedures described in GSM 11.10

If the network receives, on a SAP where it expects standard L3 messages, a message with a protocol discriminator different from those specified in table 11.2, the network may ignore the message or initiate the channel release procedure defined in GSM 04.08.

If the Mobile Station receives, on a SAP where it expects standard L3 messages, a standard L3 message with a protocol discriminator different from those specified in table 11.2, or for a protocol that it does not support, the Mobile Station shall ignore the message.

11.2.3.1.2 Skip indicator

Bits 5 to 8 of octet 1 of a standard L3 message may be used differently, depending on the protocol and the SAP. The use of this half-octet is consistent for a given PD and SAP. One possibility is that this half-octet contains the skip indicator. Unless otherwise specified in the protocol, the skip indicator IE is a spare field.

11.2.3.1.3 Transaction identifier

A L3 protocol may define that bits 5 to 8 of octet 1 of a standard L3 message of the protocol contains the transaction identifier (TI). The TI allows to distinguish up to 16 different bi-directional messages flows for a given PD and a given SAP. Such a message flow is called a transaction.

The TI IE is coded as shown in figure 11.9 and table 11.3. It is composed of the TI value and the TI flag.

The TI value and the TI flag occupy bits 5 – 7 and bit 8 of the first octet respectively.

Transactions are dynamically created, and their TI value is assigned at creation time. TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction a free TI value (i.e., a value not yet used for the given PD, the given SAP, and with the given initiator) is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction.

Two identical TI values may be used when each value pertains to a transaction initiated by the different sides of the interface. In this case the TI flag shall avoid ambiguity. The transaction identifier flag can take the values "0" or "1". The TI flag is used to identify which side of the interface initiated the transaction. A message has a TI flag set to "0" when it belongs to transaction initiated by its sender, and to "1" otherwise.

Hence the TI flag identifies who allocated the TI value for this transaction and the only purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.

The TI may in future evolutions of the L3 protocols be extended by using a combination of bits in the TI value field that is specified as "reserved for future extension" in table 11.3. In the present version, messages received on a SAP where standard L3 messages are expected and with a TI of TI value 111 may be ignored.

Figure 11.9: Transaction identifier

Table 11.3. Transaction identifier

TI flag (octet 1)

Bit

8

0

The message is sent from the side that originates the TI

1

The message is sent to the side that originates the TI

TI value (octet 1)

Bits

7 6 5

0 0 0

TI value 0

0 0 1

‑ ‑ 1

0 1 0

‑ ‑ 2

0 1 1

‑ ‑ 3

1 0 0

‑ ‑ 4

1 0 1

‑ ‑ 5

1 1 0

‑ ‑ 6

1 1 1

Reserved for future extension.

11.2.3.1.4 Sub-protocol discriminator

A L3 protocol may define that bits 5 to 8 of octet 1 of a standard L3 message of the protocol contains the sub-protocol discriminator (SPD). The SPD allows to distinguish between different protocols inside one sublayer.

Table 11.4: Sub-Protocol discriminator values

bits 8 7 6 5

0 0 0 0

Value used by the Skip Indicator (see 11.2.3.1.2)

0 0 0 1

CTS sub-protocol

0 0 1 0

\

To

} all other values are reserved

1 1 1 1

/

11.2.3.2 Message type octet

The message type octet is the second in a standard L3 message.

When a standard L3 message is expected, and a message is received that is less than 16 bit long, that message shall be ignored.

The message type IE is coded as shown in figure 11.10.

Bit 8 is encoded as "0"; value "1" is reserved for possible future use as an extension bit. A protocol entity expecting a standard L3 message, and receiving a message containing bit 8 of octet 2 encoded as "1" shall diagnose a " message not defined for the PD" error and treat the message accordingly.

In messages sent using the transmission functionality provided by the RR layer to upper layers, and sent from the mobile station to the network , bit 7 of octet 2 is used by the RR protocol.

In all other standard layer 3 messages bit 7 is set to 0 A protocol entity expecting a standard L3 message, and not using the transmission functionality provided by the RR layer, and receiving a message containing bit 7 of octet 2 encoded as 1 shall diagnose a "message not defined for the PD" error and treat the message accordingly.

Figure 11.10: Message type IE

Bit 1 to 6 of octet 2 of standard L3 messages contain the message type.

The message type determines the function of a message within a protocol in a given direction and for a given lower layer SAP. The meaning of the message type is therefore dependent on the protocol (the same value may have different meanings in different protocols), the direction (the same value may have different meanings in the same protocol, when sent from the Mobile Station to the network and when sent from the network to the Mobile Station) and the lower layer SAP (the same value may have different meanings, e.g., whether the message was sent on the SACCH or on the main DCCH).

Each protocol defines a list of allowed message types for each relevant SAP. A message received analysed as a standard L3 message, and with a message type not in the corresponding list leads to the diagnosis "message not defined for the PD". Some message types may correspond to a function not implemented by the receiver. They are then said to be non implemented by the receiver.

The reaction of a protocol entity expecting a standard L3 message and receiving a message with message type not defined for the PD or not implemented by the receiver and the reception conditions is defined in the relevant protocol specification. As a general rule, a protocol specification should not force the receiver to analyse the message further.

11.2.3.3 Standard information elements of the imperative part

The message type octet of a standard L3 message may be followed by mandatory standard IEs having the format V or LV as specified in the message description in the relevant protocol specification.

As a design rule, octet boundaries must be respected. This implies that half-octet standard IEs (i.e., V formatted type 1 standard IEs) must appear by pair.

If message is received as a standard L3 message, and that is too short to contain the complete imperative part as specified in the relevant protocol specification, an imperative message part error is diagnosed. (The same error may be diagnosed at detection of certain contents of the imperative part of a message; this is defined in the relevant protocol specification.) The treatment of an imperative message part error is defined in the relevant protocol specification.

11.2.4 Non-imperative part of a standard L3 message

The imperative part of a standard L3 message is followed by the (possibly empty) non-imperative part. The relevant protocol specification defines where the imperative part of a standard L3 message ends. The non-imperative part of a standard L3 message is composed of (zero, one, or several) standard IEs having the format T, TV, or TLV. The receiver of a standard L3 message shall analyse the non imperative part as a succession of standard IEs each containing an IEI, and shall be prepared for the non-imperative part of the message to contain standard IEs that are not specified in the relevant protocol specification.

An IEI may be known in a message or unknown in a message. Each protocol specification lists, for each message (i.e., according to the message type, the direction and the lower layer SAP), the known standard IEs in the non-imperative part.

An IEI that is known in a message designates the IE type of the IE the first part of which the IEI is, as well as the use of the information. Which IE type it designates is specified in the relevant protocol specification. Within a message, different IEIs may designate the same IE type if that is defined in the relevant protocol specification.

Whether the second part of an IE with IEI known in a message is the length or not (in other words, whether the IEI is the first part of an IE formatted as TLV or not) is specified in the relevant protocol specification.

Unless otherwise specified in the protocol specification, the receiver shall assume that IE with unknown IEI are TV formatted type 1, T formatted type 2 or TLV formatted type 4 standard IEs. The IEI of unknown IEs together with, when applicable, the length indicator, enable the receiver to determine the total length of the IE, and then to skip unknown IEs. The receiver shall assume the following rule for IEs with unknown IEI :

Bit 8 of the IEI octet is set to "1" indicates a TV formatted type 1 standard IE or a T formatted type 2 IEs, and to "0" indicates a TLV formatted type 4 IE. Hence, a 1 valued bit 8 indicates that the whole IE is one octet long, and a 0 valued bit 8 indicates that the following octet is a length octet.

As a design rule, it is recommended that IEIs of any TV formatted type 1, T formatted type 2 or TLV formatted type 4 IE follow the rule, even if assumed to be known by all potential receivers.

A message may contain two or more IEs with equal IEI. Two IEs with the same IEI in a same message must have the same format, and, when of type 3, the same length. More generally, care should be taken not to introduce ambiguities by using an IEI for two purposes. Ambiguities appear in particular when two IEs potentially immediately successive have the same IEI but different meanings and when both are non-mandatory. As a recommended design rule, messages should contain a single IE of a given IEI.

Each protocol specification may put specific rules for the order of IEs in the non-imperative part. An IE known in the message, but at a position non compliant with these rules is said to be out of sequence. An out of sequence IE is decoded according to the format, and, when of type 3 the length, as defined in the message for its IEI.

11.2.5 Presence requirements of information elements

The relevant protocol specification may define three different presence requirements (M, C, or O) for a standard IE within a given standard L3 message:

– M ("Mandatory") means that the IE shall be included by the sending side, and that the receiver diagnoses a "missing mandatory IE" error when detecting that the IE is not present. An IE belonging to the imperative part of a message has presence requirement M. An IE belonging to the non-imperative part of a message may have presence requirement M;

– C ("Conditional") means:

* that inclusion of the IE by the sender depends on conditions specified in the relevant protocol specification;

* that there are conditions for the receiver to expect that the IE is present and/or conditions for the receiver to expect that the IE is not present in a received message of a given PD, SAP and message type; these conditions depend only on the content of the message itself, and not for instance on the state in which the message was received, or on the receiver characteristics; they are known as static conditions;

* that the receiver detecting that the IE is not present when sufficient static conditions are fulfilled for its presence, shall diagnose a "missing conditional IE" error;

* that the receiver detecting that the IE is present when sufficient static conditions are fulfilled for its non-presence, shall diagnose an "unexpected conditional IE" error.

Only IEs belonging to the non-imperative part of a message may have presence requirement C;

– O ("Optional") means that the receiver shall never diagnose a "missing mandatory IE" error, a "missing conditional IE" error, or an "unexpected conditional IE" error because it detects that the IE is present or that the IE is not present. (There may however be conditions depending on the states, resources, etc. of the receiver to diagnose other errors.) Only IEs belonging to the non-imperative part of a message may have presence requirement O.

Unless otherwise specified the presence of a IE of unknown IEI or of an out of sequence IE shall not lead by itself to an error. An alternative specification is the ‘comprehension required’ scheme . An IE is encoded as ‘comprehension required’ if bits 5, 6, 7 and 8 of its IEI are set to zero.. The comprehension required scheme is to be applied if explicitly indicated in the protocol specification. The reaction on the reception of an unknown or out of sequence IE coded as ‘comprehension required’ is specified in the relevant protocol specification.

11.2.6 Description of standard L3 messages

This sub-clause describes a generic description method for standard L3 messages, the tabular description. Protocol specification may follow other methods.

A standard L3 message is described by a table listing the header elements and the standard IEs in the message. For each element is given

‑ if applicable the IEI, in hexadecimal representation (one digit followed by and hyphen for TV formatted type 1, and two digits for the other cases);

‑ The name of the IE (this is used in particular for the description of conditional presence rules);

‑ The type of the information element, with a reference of where the internal structure of the value part is specified;

‑ The format of the standard IE (T, V, TV, LV or TLV); and

‑ The length, or the range of lengths, of the whole standard IE, including when applicable the T and L parts.

The list of elements is given in the table in the order they appear in the resulting bit string, with the exception of half-octet elements in the imperative part : half octets in a pair are inverted. This applies in particular for the two first header elements : the protocol discriminator appears first in a table describing a standard L3 message.

11.3 Non standard L3 messages

In some protocols, the structure of part or all of the messages might not always follow the standard L3 message structure. As a design rule, this should be consistent for a given protocol, direction and lower layer SAP.

A possibility is to describe the message with the compact notation described in Annex B.

A few consistent structures are found in the present protocol specifications, and are described hereafter.

Other structures can be described directly in the protocol specifications.

11.3.1 Case A : BCCH and AGCH/PCH messages

In these cases, the SAP capability is for fixed length messages. The messages are structured as standard L3 messages plus one octet in front, the L2 pseudo length octet, and a rest octet part at the end.

11.3.1.1 L2 Pseudo Length octet

This octet, the L2 pseudo length indicator octet, indicates the length in octets of the subsequent octet string that can be analysed as a standard L3 message .

The octet is structured as follows :

Bits 3 to 8 encodes in binary the L2 pseudo length, i.e., the length of the part to be analysed as a standard L3 message ;

Bit 2 is set to "0" ;

Bit 1 is set to "1".

A receiver expecting a message so structured and receiving a message with bit 1 of octet 1 (i.e., the 8th bit of the message) set to "1" and bit 2 of octet 1 (i.e., the 7th bit of the message) different from "0", shall abandon the analysis of the message.

A receiver expecting a message so structured and receiving a message with an L2 pseudo length indicator encoding 0 or 1 shall skip the indicated number of octets and not try to analyse the standard L3 message part.

A receiver expecting a message so structured and receiving a L2 pseudo length indicator bigger than what is compatible with the SAP capability shall abandon the analysis of the message.

11.3.1.2 Rest Octets

The part after the part structured as a standard L3 message, and up to the end of the message as constrained by lower layers, is presented as a non standard IE of variable length (sometime indicated as of type 5), the ‘rest octets’ IE.

The rest octets element may be described by table description, or, preferably, using the compact notation described in Annex B of the present document.

11.3.1.3 Description of a modified standard L3 message

The description can be provided in the same way as a standard L3 message, with in the case of a tabular description one non standard IE at the beginning (of type L2 pseudo length), and one non standard IE at the end.

11.3.2 Case B : SACCH messages sent in unacknowledged mode

The messages are structured either as standard L3 messages, or in the so-called short header format. The value of the 8th bit (bit 1 of octet 1) of the link layer PDU distinguishes the two cases. In the case of the short header, the L3 message is the same bit string as the link layer PDU, and has a fixed length. The following description includes the 2-bit link layer header.

11.3.2.1 The first octet

Bits 1 and 2 are the link layer header. Bit 2 of octet 1 is set to "0", and bit 1 is reserved for the link layer.

A protocol discriminator is the first part of the message (starting bit 8 of octet 1). The protocol discriminator field may have different lengths. The following protocol discriminator is defined :

0 RR

All additional PD defined for this structure shall start by 1. The reception of a message with bit 8 of octet 1 set to 1 when expecting a message structured as defined by this clause shall be diagnosed as an unknown PD, and the message ignored.

As a design rule, a message type field should follow the PD, and of a length such that the PD and the message type fit in the 6 first bits of the message.

11.3.2.2 The rest of the message

The rest of the structure is not more constrained.

The preferred description method is the one described in Annex B.

11.3.3 Design guidelines for non standard parts

The guidelines in this sub-clause apply to non standard parts, such as rest octets, short header broadcast message or fully non standard L3 messages.

11.3.3.1 General

The structure should be as far as possible be such that the analysis can be conducted from beginning to end. In other terms, the conditions determining the syntactic analysis of a part (e.g., tags, lengths) should appear before that part.

The part should be structured as a succession of information elements, each carrying an elementary semantic information. An information element should be composed of (possibly) a tag, than (possibly) a length indicator, then a value part.

Tags can be of fixed or variable length, their extent being analysable from beginning to end. A typical tagging is the one bit tagging, which should preferably used as follows : value "0" indicates that the IE is no more than the tag bit, and "1" indicates that the IE continues at least with the next bit.

Variable length tagging should be used to distinguish between several possible formats of the element. Tag lengths are then chosen according to packing efficiency criteria.

The T field of standard IEs can be presented as a variable tagging with only two lengths : 4 and 8 bits.

The length indicator can be of fixed or variable length, their extent being analysable from beginning to end. It should preferably be presented as encoding the length in bits of the value part.

The L field of standard IEs can be presented as a fixed length (one octet) length indicator which can encode only lengths multiple of 8 bits.

The value part can be described as further structured, in a similar way. This can be used to help the reading, and to cover some presence dependence.

11.4 Handling of superfluous information

All equipment should be able to ignore any extra information present in an L3 message, which is not required for the proper operation of that equipment. For example, a mobile station may ignore the calling party BCD number if that number is of no interest to the Mobile Station when a SETUP message is received.

11.4.1 Information elements that are unnecessary in a message

The relevant protocol specification may define certain IEs to be under some conditions unnecessary in a L3 message. A protocol entity detecting an unnecessary IE in a received L3 message shall ignore the contents of that IE for treating the message; it is not obliged to check whether the contents of the IE are syntactically correct.

11.4.2 Other syntactic errors

This section applies to the analysis of the value part of an information element. It defines the following terminology:

– An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved", or if its value part violates syntactic rules given in the specification of the value part. However it is not a syntactical error that a type 4 standard IE specifies in its length indicator a greater length than possible according to the value part specification : extra bits are ignored.

– A message is defined to have semantically incorrect contents if it contains information which, possibly dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part.

Annex A (informative):
MN‑Services arrow diagram

Figure A.1: Mobile originated Call Setup. Successful case

Figure A.2: Mobile terminated Call Setup. Successful case

Figure A.3: Mobile originated, Call Release and Channel Release. Successful case

Figure A.4: Location updating. Successful case

Figure A.5: Handover. Successful case

Figure A.6: Establishment of parallel transactions (General view)

Figure A.7: Release of parallel transactions (General view)

Annex B (informative):
Description of CSN.1

The goal of the notation described hereafter is to describe the structure of the syntactically correct messages for a given signalling protocol, or of part of such messages. The notation addresses the cases where the concrete messages are binary strings. The notation allows to describe sets of strings : the structure of a message defined a protocol defines a set of allowable bit strings. It also allows to put labels on parts of strings that follow a given structure.

One aspect of the specification of message set is to define the set of strings that are acceptable as when received. All the strings that cannot be recognised as syntactically correct messages are to be rejected for syntactical reasons. In many cases, only a subset of this set are allowed to be sent. The notation allows also to distinguish the set of the strings that can be sent and the set of strings that are recognised as syntactically correct.

Another aspect of the specification of messages is the splitting of an acceptable string in a number of sub-strings that will be use to derive the exact significance of the message. The notation provides this function by labelling sub-strings. These labels can then in turn be used in textual or formal semantic descriptions which are not covered in the present document.

The notation described here could be enhanced in the future, with the addition of new rules.