11 Message functional definitions and contents

3GPP44.060General Packet Radio Service (GPRS)Mobile Station (MS) - Base Station System (BSS) interfaceRadio Link Control / Medium Access Control (RLC/MAC) protocolRelease 17TS

This sub-clause defines the structure of the RLC/MAC control messages. These are non-standard L3 messages as defined in 3GPP TS 24.007. The formats for the messages are valid only for the PDCH. The format for RLC/MAC control messages for use on the CCCH are defined in 3GPP TS 44.018.

The RLC/MAC control messages defined in this sub-clause may be used also on DBPSCH and SBPSCH in Iu mode. A subset of these messages is used exclusively in Iu mode. Messages belonging to that subset are labelled as "Iu mode only" in this technical specification.

A subset of the Iu mode only messages is used exclusively on DBPSCH. These messages do not follow the general syntactical rules for the RLC/MAC control messages used on shared channels. The error handling defined for shared channels does not apply. Messages that may be sent from the network to the mobile station, and that belong to this subset, are classified as DBPSCH messages, see sub-clause 11.1.1.

Specific RLC/MAC control messages, sent on the EC-PACCH, are used for EC TBFs.

Each definition given in the present sub-clause includes:

– a brief description of the message direction and use;

– a CSN.1 description of the message information elements and fields (see CSN.1 Specification, Version 2.0). Definition of information elements may immediately follow the definition of the message. If the definition of an information element immediately follows the message definition, the information element name ends with ‘struct’. Otherwise the information element name ends with ‘IE’ and the definition of the information element is defined in clause 12 or in 3GPP TS 44.018. The definition of a ‘struct’ is valid only within the table in which it is defined. No references shall be made to a ‘struct’ definition from outside of the table in which it is defined or from outside the present document. The definition of an information element is valid throughout clause 11 and clause 12 as well as in 3GPP TS 44.018;

– a note specifying, where appropriate, conditions for information elements or fields with presence requirement C or O in the relevant message which together with other conditions specified in 3GPP TS 44.060 define when the information elements shall be included or not, what non-presence of such information elements or fields means, and – for IEs with presence requirement C – the static conditions for presence and/or non-presence of the information elements or fields (see 3GPP TS 24.007);

– a table follows which contains a definition for each field referenced in the message definition or in an information element struct immediately following the message definition.

Bit fields within RLC/MAC messages shall have the highest numbered bit of the bit field in the highest numbered bit of the lowest number octet (see sub-clause 10.0b.3.1). The mapping of an 11 bit field is illustrated in figure 11.1.

bit

8

7

6

5

4

3

2

1

Octet N

bit 11

bit 10

bit 9

bit 8

Octet N+1

bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

Octet N+2

Octet N+3

Figure 11.1: Field mapping within RLC/MAC messages

The length of an RLC/MAC control messages is an integer number of RLC/MAC control blocks. Padding bits are necessary to fill the message up to the desired length. The padding bits may be the ‘null’ string. Otherwise, the padding bits starts with bit ‘0’, followed by ‘spare padding’.

< padding bits > ::= { null | 0 < spare padding > ! < Ignore : 1 bit** = < no string > > } ;

The padding sequence used for ‘spare padding’ in the present document, see 3GPP TS 24.007, is a repetition of octet ‘00101011’, starting on an octet boundary.