10 RLC/MAC block structure

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

10.0a RLC/MAC block structure

Different RLC/MAC block structures are defined for data transfers and for control message transfers. The RLC/MAC block structures for data transfers are different for GPRS and EGPRS/EC-GSM-IoT, whereas the RLC/MAC block structure used for control message transfers for EC-GSM-IoT is different than the one used for GPRS and EGPRS.

10.0a.1 GPRS RLC/MAC block for data transfer

The RLC/MAC block for GPRS data transfer consists of a MAC header and an RLC data block. The RLC data block consists of an RLC header, an RLC data unit and spare bits.

RLC/MAC block
MAC header	RLC data block
	RLC header	RLC data unit	Spare bits

Figure 10.0a.1.1: RLC/MAC block structure for data transfer for GPRS

The RLC data unit contains octets from one or more upper layer PDUs.

10.0a.2 EGPRS and EC-GSM-IoT RLC/MAC block for data transfer

The RLC/MAC block for EGPRS, EC-GSM-IoT and EGPRS2 data transfer is shown in figure 10.0a.2.1 and consists of:

– a combined RLC/MAC header,

– one or two RLC data blocks for EGPRS and EC-GSM-IoT, or up to four RLC data blocks for EGPRS2,

– an optional PAN field which is included in case FANR is activated,

– and an optional eTFI field which is included for the case where a mobile station in a DLMC configuration is assigned an eTFI for a downlink TBF. If an eTFI is assigned for a downlink TBF then an eTFI is included in an uplink RLC/MAC block for data transfer only if a PAN field corresponding to that downlink TBF is also included.

RLC/MAC block
RLC/MAC header	RLC data block 1	RLC data block 2 (conditional)	RLC data block 3 (conditional)	RLC data block 4 (conditional)	PAN (optional)	eTFI (optional)

Figure 10.0a.2.1: RLC/MAC block structure for EGPRS, EC-GSM-IoT and EGPRS2 data transfer

Each RLC data block contain octets from one or more upper layer PDUs.

The PAN field may only be included within an EGPRS RLC/MAC block for data transfer within a TBF with FANR activated.

In EGPRS and EC-GSM-IoT, depending on the modulation and coding scheme (see 3GPP TS 44.004 and 3GPP TS 45.003) one or two RLC data blocks are contained in one RLC/MAC block. For MCS-1, MCS-2, MCS-3, MCS-4, MCS-5 and MCS-6 there is one RLC data block, whereas for MCS-7, MCS-8 and MCS-9 there are two RLC data blocks in the RLC/MAC block.

In EGPRS and EC-GSM-IoT, in each transfer direction, uplink and downlink, three different header types are defined. The header fields for a specific header type may differ between EGPRS and EC-GSM-IoT. Which header type that is used depends on the modulation and coding scheme (MCS):

Header type 1 is used with modulation and coding scheme MCS-7, MCS-8 and MCS-9.

Header type 2 is used with modulation and coding scheme MCS-5 and MCS-6.

Header type 3 is used with modulation and coding scheme MCS-1, MCS-2, MCS-3 and MCS-4.

In EC-GSM-IoT Header type 4 is used in uplink direction as described in sub-clause 10.4.8a.3:

Header type 4 is used with modulation and coding scheme MCS-1’.

In EGPRS2, depending on the modulation and coding scheme (see 3GPP TS 44.004 and 3GPP TS 45.003) one to four RLC data blocks are contained in one RLC/MAC block as follows:

– One RLC data block per RLC/MAC block: MCS-1, MCS-2, MCS-3, MCS-4, MCS-5, MCS-6, DAS-5, DAS-6, DAS-7, DBS-5, DBS-6, UBS-5 and UBS-6;

– Two RLC data blocks per RLC/MAC block: MCS-7, MCS-8, MCS-9, DAS-8, DAS-9, DAS-10, DBS-7, DBS-8, UAS-7, UAS-8, UAS-9, UBS-7 and UBS-8;

– Three RLC data blocks per RLC/MAC block: DAS-11, DAS-12, DBS-9, DBS-10, UAS-10, UAS-11, UBS-9 and UBS-10;

– Four RLC data blocks per RLC/MAC block: DBS-11, DBS-12, UBS-11 and UBS-12.

In EGPRS2, ten header types are used in the downlink direction. Which header type is used depends on the modulation and coding scheme:

Header type 1 is used with modulation and coding scheme MCS-7, MCS-8 and MCS-9

Header type 2 is used with modulation and coding scheme DAS-5, DAS-6 and DAS-7.

Header type 3 is used with modulation and coding scheme MCS-1, MCS-2, MCS-3 and MCS-4.

Header type 4 is used with modulation and coding scheme DAS-8 and DAS-9.

Header type 5 is used with modulation and coding scheme DAS-11 and DAS-12.

Header type 6 is used with modulation and coding scheme DBS-5 and DBS-6.

Header type 7 is used with modulation and coding scheme DBS-7 and DBS-8.

Header type 8 is used with modulation and coding scheme DBS-9 and DBS-10.

Header type 9 is used with modulation and coding scheme DBS-11 and DBS-12.

Header type 10 is used with modulation and coding scheme DAS-10.

In EGPRS2, eight header types are used in the uplink direction. Which header type is used depends on the modulation and coding scheme:

Header type 2 is used with modulation and coding scheme MCS-5 and MCS-6.

Header type 3 is used with modulation and coding scheme MCS-1, MCS-2, MCS-3 and MCS-4.

Header type 4 is used with modulation and coding scheme UAS-7, UAS-8 and UAS-9.

Header type 5 is used with modulation and coding scheme UAS-10 and UAS-11.

Header type 6 is used with modulation and coding scheme UBS-5 and UBS-6.

Header type 7 is used with modulation and coding scheme UBS-7 and UBS-8.

Header type 8 is used with modulation and coding scheme UBS-9 and UBS-10.

Header type 9 is used with modulation and coding scheme UBS-11 and UBS-12.

10.0a.3 RLC/MAC block for control message transfer

The downlink RLC/MAC block for control message transfer not associated with a TBF assigned an eTFI and an uplink RLC/MAC block for control message transfer consists of a MAC header and an RLC/MAC control block as shown in Figure 10.0a.3.1.

RLC/MAC block
MAC header	RLC/MAC control block

Figure 10.0a.3.1: RLC/MAC block structure for control block

The downlink RLC/MAC block for control message transfer associated with a TBF assigned an eTFI consists of a MAC header, an RLC/MAC control block and an eTFI field as shown in Figure 10.0a.3.2.

RLC/MAC block
MAC header	RLC/MAC control block	eTFI

Figure 10.0a.3.2: RLC/MAC block structure for control block (DLMC configuration used)

10.0b RLC/MAC block format conventions

10.0b.1 Numbering convention

The physical layer transfers RLC/MAC blocks, 11‑bit and 8‑bit control messages in physical blocks of the packet data channel. The physical block formats are specified in 3GPP TS 44.004. The physical block is organised as a sequence of N1 octets that are numbered from 1 to N1. An octet is a sequence of eight bits that are numbered from 1 to 8. If the total number of bits in a physical block is not an integer number of octets, the last bits of the physical block (in octet number N1) does not form a complete octet. The bits that are transferred in the last, and possibly incomplete octet, are numbered from 1 to n, where 1  n  8. The total number of bits in the physical block is 8(N1 ‑ 1) + n.

10.0b.2 Assembling conventions

Different assembling conventions apply for GPRS RLC data blocks, RLC/MAC control blocks, 11‑bit and 8‑bit control messages and EGPRS/EC-GSM-IoT RLC data blocks.

10.0b.2.1 Assembling convention for GPRS RLC data blocks and RLC/MAC control blocks, 11‑bit and 8‑bit control messages

The different components of an RLC/MAC block carrying a GPRS RLC data block or an RLC/MAC control block shall be assembled sequentially. Each component consists of an integer number of octets with an exception for the EC-PACCH/D RLC/MAC control block where the block is of integer number of octets but not the individual components (MAC header and Control message content). The assembling of components shall be performed progressively, starting in octet number 1 of the physical block.

The 11‑bit and 8‑bit control messages map directly into the corresponding physical block.

In this respect, an RLC/MAC control message, defined in sub-clause 11, or a segment of an RLC/MAC control message, see sub-clause 9.1.12a, shall be treated as a single field of either:

– 176 bits(22 octets, using the PBCCH/PCCCH downlink/CS-1 encoded PACCH block format),

– 304 bits (38 octets, using the CS-3 encoded PACCH block format),

– 11 bits or 8 bits (using the PRACH uplink/PACCH uplink short acknowledgement block formats, see 3GPP TS 44.004),

– 75 bits or 67 bits (using the EC-PACCH/D without or with the optional RLC/MAC header bits respectively),

– 64 bits (using the EC-PACCH/U).

The message contents defines a sequence of bits in decreasing order of value, i.e. the first bit of the message contents represents the highest order value and the last bit the lowest order value.

The RLC/MAC header and a GPRS RLC data block are components that consist of an integer number of octets. Each octet shall be treated as a separate field when mapped into the physical block. The lowest numbered bit represents the lowest order value.

The PDTCH block type 2 (CS‑2), type 3 (CS‑3) and type 4 (CS‑4) formats (see 3GPP TS 44.004) do not have an integer number of octets. In these block types, bits number n to 1 of octet number N1 are spare bits.

10.0b.2.2 Assembling convention for EGPRS and EC-GSM-IoT RLC data blocks

The different components of the RLC/MAC block carrying an EGPRS or EC-GSM-IoT RLC data block shall be assembled sequentially. A component may consist of a non-integer number of octets. Each octet shall be treated as a separate field when mapped into the physical block. The lowest numbered bit represents the lowest order value.

The assembling of components shall be performed progressively, starting with octet number 1 of the physical block. If the boundary between two components falls within an octet of the physical block, the components, or parts thereof, that are contained in that octet shall be assembled progressively, starting with bit number 1 of the octet. (i.e. going from bit number 1 to bit number 8, except in octet number N1, where components are assembled going from bit number 1 to bit number n).

10.0b.3 Field mapping conventions

Different field mapping conventions apply for GPRS RLC data blocks, RLC/MAC control blocks, 11‑bit and 8‑bit control messages and EGPRS/EC-GSM-IoT RLC data blocks.

10.0b.3.1 Field mapping convention for GPRS RLC data blocks, CS-1 or CS-3 encoded RLC/MAC control blocks, EC-PACCH/D and EC-PACCH/U, 11‑bit and 8‑bit control messages

When a field within a GPRS RLC data block or a CS-1 encoded RLC/MAC control block, or a CS-3 encoded RLC/MAC control block, or EC-PACCH/D or EC-PACCH/U encoded RLC/MAC control block or an 11‑bit or an 8‑bit control message is contained within a single octet of the physical block, the lowest numbered bit of the field represents the lowest order value.

When a field spans more than one octet of the physical block, the order of bit values within each octet progressively decreases as the octet number increases. In that part of a field contained in a given octet, the lowest numbered bit represents the lowest order value.

10.0b.3.2 Field mapping convention for EGPRS and EC-GSM-IoT RLC data blocks and MCS-0 encoded RLC/MAC control blocks

When a field within an EGPRS or EC-GSM-IoT RLC data block is contained within a single octet of the physical block, the lowest numbered bit of the field represents the lowest order value.

When a field spans more than one octet of the physical block, the order of bit values within each octet progressively increases as the octet number increases. In that part of a field contained in a given octet, the lowest numbered bit represents the lowest order value.

10.1 Spare bits

Where the description of RLC/MAC blocks in this Technical Specification contains bits defined to be ‘spare bits’, these bits shall set to the value ‘0’ by the sending side, and their value shall be ignored by the receiving side.

10.2 GPRS RLC data blocks

The RLC data block consists of an RLC header, an RLC data unit, and spare bits. An RLC/MAC block containing an RLC data block may be encoded using any of the available channel coding schemes CS-1, CS-2, CS-3, or CS-4 (see 3GPP TS 45.003). RLC/MAC blocks encoded using CS-1 do not contain spare bits. The size of the RLC data block for each of the channel coding schemes is shown in table 10.2.1.

Table 10.2.1: RLC data block size

Channel Coding Scheme	RLC data block size without spare bits (N2) (octets)	Number of spare bits	RLC data block size (octets)
CS-1	22	0	22
CS-2	32	7	32 7/8
CS-3	38	3	38 3/8
CS-4	52	7	52 7/8

10.2.1 Downlink RLC data block

The Downlink RLC data block together with its MAC header is formatted as shown in figure 10.2.1.1.

Bit
8	7	6	5	4	3	2	1
Payload Type		RRBP		S/P		USF		MAC header
PR		TFI					FBI	Octet 1
			BSN				E	Octet 2
Length indicator						M	E	Octet 3 (optional)
. . .								. . .
Length indicator						M	E	Octet M (optional)
								Octet M+1
RLC data								. . .
								Octet N2-1
								Octet N2
		spare				spare		(if present)

Figure 10.2.1.1: Downlink RLC data block with MAC header

10.2.2 Uplink RLC data block

The Uplink RLC data block together with its MAC header is formatted as shown in figure 10.2.2.1.

Bit
8	7	6	5	4	3		2	1
Payload Type		Countdown Value					SI	R	MAC header
spare	PI	TFI						TI	Octet 1
			BSN					E	Octet 2
Length indicator							M	E	Octet 3 (optional)
spare					Selected PLMN Index				Octet 4 (note 2) (optional)
. . .									. . .
Length indicator							M	E	Octet M (optional)
									Octet M+1 \
			TLLI						Octet M+2 } (optional)
									Octet M+3 /
									Octet M+4 /
Length indicator						M		E	Octet M + 5 (Note 3) (Optional)
DCN-ID (octet 1)									Octet M+6
DCN-ID (octet 2)									Octet M+7
PFI								E	Octet M + 8 /
									Octet M+9
RLC data									. . .
									Octet N-1
									Octet N
		spare					spare		(if present)

NOTE 1: The field mapping convention for GPRS (sub-clause 10.0b.3.1) applies. According to that, in particular regarding the TLLI field, the most significant byte of the TLLI value shall be mapped on octet M+1 and the least significant byte of the TLLI value shall be mapped on octet M+4 of the uplink RLC data block.

NOTE 2: This octet is only included if the value of the first instance of the Length indicator in the RLC data block is 62.

NOTE 3: This octet and the following two octets are only included if both the network and MS support MS assisted Dedicated Core Network selection (see 3GPP TS 44.018 [11]).

Figure 10.2.2.1: Uplink RLC data block with MAC header

10.3 RLC/MAC control blocks

The RLC/MAC control block consists of a control message contents field and in the downlink direction an optional control header. RLC/MAC control messages shall be transported within RLC/MAC control blocks. An RLC/MAC control blocks shall always be encoded using the coding scheme CS-1 (see 3GPP TS 44.004), except in the following conditions:

– on a downlink PDCH-pair assigned to a TBF in RTTI configuration with BTTI USF mode, downlink RLC/MAC control blocks shall always be encoded using coding scheme MCS-0;

– on a downlink PDCH-pair assigned to a TBF in RTTI configuration with RTTI USF mode, downlink RLC/MAC control blocks shall always be encoded using either coding scheme CS-1 or coding scheme MCS-0; an MS can differentiate CS-1 blocks from MCS-0 blocks by examining the stealing bits.

– a mobile station that supports more than 20 timeslots in a DLMC configuration (see sub-clause 5.13) may send an EGPRS Packet Downlink Ack/Nack DLMC message using the coding scheme CS-1 or CS-3 as indicated by the PDAN Coding IE in the most recently received assignment message. However, a mobile station that has been commanded to use CS-3 shall use CS-1 for any given EGPRS Packet Downlink Ack/Nack DLMC message that includes a request for an uplink TBF.

10.3.1 Downlink RLC/MAC control block

10.3.1.1 Blocks encoded using CS-1

The Downlink RLC/MAC control block together with its MAC header is formatted as shown in figure 10.3.1.1.1.

Bit
8	7	6	5	4	3	2	1
Payload Type		RRBP		S/P		USF		MAC header
RBSN	RTI					FS	AC	Octet 1 (optional)
PR		TFI					D	Octet 2 (optional)
RBSNe			FSe	spare				Octet 2/3 (optional) see note
								Octet M
Control Message Contents								. . .
								Octet 21
								Octet 22
NOTE: This optional octet is included in case of extended RLC/MAC control message segmentation. Its presence is indicated through the combination of RBSN bit and FS bit equal to (RBSN=’1’ and FS=’0’)

Figure 10.3.1.1.1: Downlink RLC/MAC control block together with its MAC header

NOTE: The header octets and the control message contents octets shall be encoded following the field mapping convention defined in sub-clause 10.0b.3.1.

10.3.1.2 Blocks encoded using MCS-0

The downlink RLC/MAC control block header shall use the Header type 3 as shown in figure 10.3a.3.3.3 of subclause 10.3a.3.3. The RLC/MAC control block message contents are formatted as shown in figure 10.3.1.2.

Bit
8	7	6	5	4	3	2	1
RBSN	RTI					FS	AC	Octet 1 (optional)
PR		TFI					D	Octet 2 (optional)
RBSNe			FSe	spare				Octet 2/3 (optional) see note
								Octet M
Control Message Contents								. . .
								Octet 21
								Octet 22
NOTE: This optional octet is included in case of extended RLC/MAC control message segmentation. Its presence is indicated through the combination of RBSN bit and FS bit equal to (RBSN=’1’ and FS=’0’)

Figure 10.3.1.2.1: Downlink RLC/MAC control block message contents

NOTE: The optional header octets and the control message contents octets shall be encoded following the field mapping convention defined in sub-clause 10.0b.3.2.

10.3.1.3 Blocks encoded for EC-PACCH/D

A coding block payload content of up to 80 bits, including MAC header, has been defined for use on EC-PACCH/D where the USF is encoded separately. Depending on the value of the Payload Type bit, the payload size is either 75 or 67 bits and is coded to generate punctured bits for EC-PACCH/D and designed to provide compatibility with GPRS and EGPRS. The EC-PACCH/D RLC/MAC control block for EC-GSM-IoT, including the MAC header, is formatted as shown in figure 10.3.1.3.1 or 10.3.1.3.2.

The USF is encoded separately, see 3GPP TS 45.003. A different USF value may be included in each block when several blind physical layer transmissions are used in the downlink. If only EC TBFs are assigned on a PDCH, the inclusion of the USF should be regarded as optional.

Bit
3	2	1
	USF

				Bit
8		7	6	5	4		3	2	1
PR	Payload Type		RRBP			S/P				MAC header (5 bits)
										Octet 1
										Octet 2
Control Message Contents										…
										Octet 9

Figure 10.3.1.3.1: EC-GSM-IoT Downlink RLC/MAC control block together with its normal MAC header when Payload Type is set to 0

Bit
3	2	1
	USF

Bit

Payload Type

RRBP

S/P

PRe

RBSN

MAC header (13 bits)

TFI

Octet 1

Octet 2

Control Message Contents

…

Octet 9

Figure 10.3.1.3.2: EC-GSM-IoT Downlink RLC/MAC control block together with its extended MAC header when Payload Type is set to 1

10.3.2 Uplink RLC/MAC control block

The Uplink RLC/MAC control block together with its MAC header is formatted as shown in figure 10.3.2.1.

Bit
8	7	6	5	4	3	2	1
Payload Type				spare			R	MAC header
								Octet 1
								Octet 2
								Octet 3
Control Message Contents								. . .
								Octet 21
								Octet 22

Figure 10.3.2.1: Uplink RLC/MAC control block together with its MAC header

A coding block payload content of 64 bits has been defined for use on EC-PACCH/U. The payload is coded to generate punctured bits for EC-PACCH/U and designed to provide compatibility with GPRS and EGPRS. The EC-PACCH/U RLC/MAC control block for EC-GSM-IoT is without MAC header and formatted as shown in figure 10.3.2.2.

					Bit
8	7	6	5	4	3	2	1
								Octet 1
Control Message Contents								…
								Octet 8

Figure 10.3.2.2: EC-GSM-IoT Uplink RLC/MAC control block.

10.3a EGPRS and EC-GSM-IoT RLC data blocks and RLC/MAC headers

10.3a.0 General

The EGPRS and EC-GSM-IoT RLC data block consists of a FBI (downlink) or TI (uplink) field and an E field followed by an EGPRS RLC data unit. The EGPRS RLC data unit is a sequence of N2 octets that are numbered from 1 to N2.

NOTE: The octets of an EGPRS RLC data unit are not necessarily aligned with the octets of the RLC/MAC block. An octet of the EGPRS RLC data unit may thus span across the boundary between two consecutive octets of the RLC/MAC block.

The RLC/MAC block format convention of sub-clause 10.0b for EGPRS and EC-GSM-IoT applies when the components of the EGPRS and EC-GSM-IoT RLC data block are assembled into the RLC/MAC block.

FBI/TI

EGPRS RLC data unit

Figure 10.3a.0.1: Components of the EGPRS and EC-GSM-IoT RLC data block

The size of the EGPRS RLC data unit for each of the channel coding schemes is shown in table 10.3a.0.1.

Table 10.3a.0.1: EGPRS and EC-GSM-IoT RLC data unit size

Channel Coding Scheme	EGPRS RLC data unit size (N2) (octets)	Family
MCS-1	22	C
MCS-2	28	B
MCS-3 with padding	31	A padding
MCS-3	37	A padding / A
MCS-4	44	C
MCS-5	56	B
MCS-6 with padding	68	A padding
MCS-6	74	A
MCS-7	2×56	B
MCS-8	2×68	A padding
MCS-9	2×74	A
NOTE 1: The four families of EGPRS RLC data blocks C, B, A and A padding based on a common size basis (22, 28, 37 and 68 octets respectively) enable link adaptation retransmission as described in sub-clause 9. NOTE 2: Modulation and coding schemes of family A padding are compatible with Family A padding6 defined for EGPRS2.

The size of the RLC data unit for each of the channel coding schemes used in EGPRS2 is shown in tables 10.3a.0.3, 10.3a.0.4, 10.3a.0.5, and 10.3a.0.6.

Table 10.3a.0.3: RLC data unit size (EGPRS2-A downlink)

Channel Coding Scheme	EGPRS RLC data unit size (N2) (octets)	Family
MCS-1	22	C
MCS-2 with padding	26	B padding2
MCS-2	28	B padding2 / B
MCS-3 with padding	31	A padding6
MCS-3	37	A padding6
MCS-4	44	C
DAS-5	56	B
DAS-6	68	A padding6
MCS-6	74	NOTE 2
DAS-7	82	B padding2
MCS-7	2×56	B
DAS-8	2×56	B
MCS-8	2×68	A padding6
DAS-9	2×68	A padding6
DAS-10	2×82	B padding2
DAS-11	3×68	A padding6
DAS-12	3×82	B padding2
NOTE 1: The four families of RLC data blocks (C, B, A padding6, and B padding2) based on a common size basis (22, 28, 68 and 82 octets respectively) enable link adaptation retransmission as described in sub-clause 9. NOTE 2: MCS-6 is also used for EGPRS2-A downlink (see sub-clause 5.2.1).

Table 10.3a.0.4: RLC data unit size (EGPRS2-B downlink)

Channel Coding Scheme	EGPRS RLC data unit size (N2) (octets)	Family
MCS-1	22	C
MCS-2	28	B
MCS-3 with padding	31	A padding6
MCS-3	37	A padding6 / A
MCS-4	44	C
DAS-5	56	B
DBS-5	56	B
DAS-6	68	A padding6
MCS-6	74	A
DBS-6	74	A
MCS-7	2×56	B
DAS-8	2×56	B
DBS-7	2×56	B
MCS-8	2×68	A padding6
DAS-9	2×68	A padding6
MCS-9	2×74	A
DAS-10 with padding	2×74	A padding8
DBS-8	2×74	A
DBS-9	3×56	B
DAS-11	3×68	A padding6
DAS-12 with padding	3×74	A padding8
DBS-10	3×74	A
DBS-11	4×68	A padding6
DBS-12	4×74	A
NOTE 1: The five families of RLC data blocks (C, B, A, A padding6 and A padding8) based on a common size basis (22, 28, 37, 68 and 74 octets respectively) enable link adaptation retransmission as described in sub-clause 9.

Table 10.3a.0.5: RLC data unit size (EGPRS2-A uplink)

Channel Coding Scheme	EGPRS RLC data unit size (N2) (octets)	Family
MCS-1	22	C
MCS-2	28	B
MCS-3 with padding	27	A padding10
MCS-3	37	A padding10 / A
MCS-4	44	C
MCS-5	56	B
MCS-6 with padding	64	A padding10
MCS-6	74	A
UAS-7	2×56	B
UAS-8	2×64	A padding10
UAS-9	2×74	A
UAS-10	3×56	B
UAS-11	3×64	A padding10
NOTE 1: The four families of RLC data blocks (C, B, A, and A padding10) based on a common size basis (22, 28, 37 and 64 octets respectively) enable link adaptation retransmission as described in sub-clause 9.

Table 10.3a.0.6: RLC data unit size (EGPRS2-B uplink)

Channel Coding Scheme	EGPRS RLC data unit size (N2) (octets)	Family
MCS-1	22	C
MCS-2	28	B
MCS-3 with padding	31	A padding6
MCS-3	37	A padding6 / A
MCS-4	44	C
UBS-5	56	B
UBS-6 with padding	68	A padding6
UBS-6	74	A
UBS-7	2×56	B
UBS-8 with padding	2×68	A padding6
UBS-8	2×74	A
UBS-9	3×56	B
UBS-10 with padding	3×68	A padding6
UBS-10	3×74	A
UBS-11	4×68	A padding6
UBS-12	4×74	A
NOTE 1: The four families of RLC data blocks (C, B, A and A padding6) based on a common size basis (22, 28, 37 and 68 octets respectively) enable link adaptation retransmission as described in sub-clause 9.

10.3a.1 Downlink RLC data block

10.3a.1.1 EGPRS downlink RLC data block

The EGPRS downlink RLC data blocks are formatted according to figure 10.3a.1.1.1.

			Bit
			2	1
			FBI	E


Bit
8	7	6	5	4	3	2	1
Length indicator							E	Octet 1 (note) (optional)
. . .								. . .
Length indicator							E	Octet M (optional)
								Octet M+1
RLC data								. . Octet K-1
spare		DTR Blks		CI	TN/PDCH-pair			Octet K (optional)
								. . .
								Octet N2-1
								Octet N2

NOTE: If padding is used, then "Octet 1" shall be replaced by "Octet 7", see example in annex J.

Figure 10.3a.1.1.1: EGPRS downlink RLC data block

10.3a.1.2 EC-GSM-IoT downlink RLC data block

For an EC TBF, the downlink RLC data blocks are formatted according to figure 10.3a.1.2.1.

			Bit
			2	1
			FBI	E


Bit
8	7	6	5	4	3	2	1
Length indicator							E	Octet 1 (note) (optional)
. . .								. . .
Length indicator							E	Octet M (optional)
								Octet M+1
RLC data								. . Octet K
								. . .
								Octet N2-1
								Octet N2

NOTE: If padding is used, then "Octet 1" shall be replaced by "Octet 7", see example in annex J.

Figure 10.3a.1.2.1: EC-GSM-IoT downlink RLC data block

10.3a.2 Uplink RLC data block

10.3a.2.1 EGPRS Uplink RLC data block

The EGPRS uplink RLC data block is formatted according to figure 10.3a.2.1.1.

			Bit
			2	1
			TI	E

Bit
8	7	6	5	4	3	2	1
Length Indicator							E	Octet 1 (note 1) (optional)
spare					Selected PLMN Index			Octet 2 (note 3) (optional)
. . .								. . .
Length Indicator							E	Octet M (optional)
TLLI								Octet M+1 /
								Octet M+2 (optional)
								Octet M+3 /
								Octet M+4 /
Length Indicator = 122							E	Octet M+5 (optional)
Cell Identity								Octet M+6
Cell Identity								Octet M+7
Routing Area Identification								Octet M+8
								Octet M+9
								Octet M+10
								Octet M+11
								Octet M+12
								Octet M+13
MS Sync Accuracy				MS Transmission Offset				Octet M+14
Random ID (low)								Octet M+15
Random ID (high)								Octet M+16
Length Indicator = 119							E	Octet M+5 (optional)
MTA Signature								Octet M+17 Octet M+18 Octet M+19 Octet M+20
Length Indicator = 121							E	Octet M+5 (optional)
MS Sync Accuracy				MS Transmission Offset				Octet M+6
Length Indicator = 120							E	Octet M+5 (optional, Note 4)
DCN-ID (octet 1)								Octet M+6
DCN-ID (octet 2)								Octet M+7
Length Indicator = 118							E	Octet M+5 (optional)
FMA	MTA Report Instance			spare				Octet M+6
PFI							E	Octet M+8 /
RLC data								Octet M+9
								. . .
								Octet N2-1
								Octet N2

NOTE 1: If padding is used, then "Octet 1" shall be replaced by "Octet 7", see example in annex J.

NOTE 2: The field mapping convention for EGPRS (sub-clause 10.0b.3.2) applies. According to that, in particular regarding the TLLI field, the least significant byte of the TLLI value shall be mapped on octet M+1 and the most significant byte of the TLLI value shall be mapped on octet M+4 of the uplink EGPRS RLC data block.

NOTE 3: This octet is only included if the value of the first instance of the Length indicator in the RLC data block is 123.

NOTE 4: This octet and the following two octets are only included if both the network and MS support MS assisted Dedicated Core Network selection (see 3GPP TS 44.018).

Figure 10.3a.2.1.1: Uplink EGPRS RLC data block

10.3a.2.2 EC-GSM-IoT Uplink RLC data block

For an EC TBF, the uplink RLC data block is formatted according to figure 10.3a.2.2.1.

				Bit
				2	1
				TI	E

Bit
8		7	6	5	4		3	2	1
Length Indicator									E	Octet 1 (note 1) (optional)
spare							Selected PLMN Index			Octet 2 (note 3) (optional)
. . .										. . .
Length Indicator									E	Octet M (optional)
TLLI										Octet M+1 /
										Octet M+2 (optional)
										Octet M+3 /
										Octet M+4 /
Length Indicator = 122									E	Octet M+5 (optional)
Cell Identity										Octet M+6
										Octet M+7
Routing Area Identification										Octet M+8
										Octet M+9
										Octet M+10
										Octet M+11
										Octet M+12
										Octet M+13
MS Sync Accuracy					MS Transmission Offset					Octet M+14
Random ID (low)										Octet M+15
Random ID (high)										Octet M+16
Length Indicator = 119									E	Octet M+5 (optional)
MTA Signature										Octet M+17 Octet M+18 Octet M+19 Octet M+20
Length Indicator = 121									E	Octet M+5 (optional)
MS Sync Accuracy					MS Transmission Offset					Octet M+6
Length Indicator = 120									E	Octet M+5 (optional, Note 4)
DCN-ID (octet 1)										Octet M+6
DCN-ID (octet 2)										Octet M+7
Length Indicator = 118									E	Octet M+5 (optional)
FMA	MTA Report Instance					spare				Octet M+6
RLC data										Octet M+8
										. . .
										Octet N2-1
										Octet N2

NOTE 1: If padding is used, then "Octet 1" shall be replaced by "Octet 7", see example in annex J.

NOTE 2: The field mapping convention for EC-GSM-IoT (sub-clause 10.0b.3.2) applies. According to that, in particular regarding the TLLI field, the least significant byte of the TLLI value shall be mapped on octet M+1 and the most significant byte of the TLLI value shall be mapped on octet M+4 of the uplink EC-GSM-IoT RLC data block.

NOTE 3: This octet is only included if the value of the first instance of the Length indicator in the RLC data block is 123.

NOTE 4: This octet and the following two octets are only included if both the network and MS support MS assisted Dedicated Core Network selection (see 3GPP TS 44.018).

Figure 10.3a.2.2.1: Uplink EC-GSM-IoT RLC data block

10.3a.3 EGPRS and EC-GSM-IoT Downlink RLC/MAC header

10.3a.3.1 Header type 1: header for MCS-7, MCS-8 and MCS-9

For an EGPRS TBF without FANR activated, the EGPRS combined downlink RLC/MAC header for MCS‑7, MCS‑8 and MCS‑9 (header type 1) shall be formatted according to figure 10.3a.3.1.1.

Bit
8	7	6	5	4	3	2	1	Octet
TFI	RRBP		ES/P		USF			1
BSN1		PR		TFI				2
BSN1								3
BSN2							BSN1	4
CPS					BSN2			5

Figure 10.3a.3.1.1: EGPRS downlink RLC data block header (FANR not activated)
for MCS-7, MCS-8 and MCS-9

For an EGPRS TBF with FANR activated and for an EGPRS2 TBF (see sub-clause 5.2.1), the downlink RLC/MAC header for MCS-7, MCS-8 and MCS-9 shall be formatted according to figure 10.3a.3.1.2.

Bit
8	7	6	5	4	3	2	1	Octet
TFI	PANI	CES/P			USF			1
BSN1		PR		TFI				2
BSN1								3
BSN2							BSN1	4
CPS					BSN2			5

Figure 10.3a.3.1.2: EGPRS (FANR activated) / EGPRS2 downlink RLC data block header

For an EGPRS TBF without FANR activated in a DLMC configuration using an SNS of 8192, the EGPRS combined downlink RLC/MAC header for MCS‑7, MCS‑8 and MCS‑9 (header type 1) shall be formatted according to figure 10.3a.3.1.3.

Bit
8	7	6	5	4	3	2	1	Octet
TFI	BSN2	RRBP	ES/P		USF			1
BSN1				TFI				2
BSN1								3
BSN2							BSN1	4
CPS					BSN2			5

Figure 10.3a.3.1.3: DLMC EGPRS downlink RLC data block header (FANR not activated)
for MCS-7, MCS-8 and MCS-9

For an EGPRS TBF with FANR activated in a DLMC configuration using an SNS of 8192 and for an EGPRS2 TBF in a DLMC configuration using an SNS of 8192, the downlink RLC/MAC header for MCS-7, MCS-8 and MCS-9 shall be formatted according to figure 10.3a.3.1.4.

Bit
8	7	6		5	4	3	2	1	Octet
TFI	PANI	BSN2	CES/P			USF			1
BSN1					TFI				2
BSN1									3
BSN2								BSN1	4
CPS						BSN2			5

Figure 10.3a.3.1.4: DLMC EGPRS (FANR activated) / DLMC EGPRS2 downlink RLC data block header for MCS-7, MCS-8 and MCS-9

For an EC TBF, the combined downlink RLC/MAC header for MCS‑7, MCS‑8 and MCS‑9 (header type 1) shall be formatted according to figure 10.3a.3.1.5.

Bit
8	7	6			5	4		3	2	1		Octet
TFI	Spare			RRBP	ECS/P		USF				1
BSN1			PR			TFI					2
Spare	BSN2						BSN1				3
Spare	RRBP				CPS						4
Spare											5

Figure 10.3a.3.1.5: EC-GSM-IoT downlink RLC data block header for MCS-7, MCS-8 and MCS-9

10.3a.3.2 Header type 2: header for MCS-6, MCS-5, DAS-5, DAS-6 and DAS-7

For an EGPRS TBF without FANR activated, the EGPRS combined downlink RLC/MAC header for MCS‑5 and MCS‑6 (header type 2) shall be formatted according to figure 10.3a.3.2.1.

Bit
8	7	6	5	4	3	2	1	Octet
TFI	RRBP		ES/P		USF			1
BSN1		PR		TFI				2
BSN1								3
				CPS			BSN1	4

Figure 10.3a.3.2.1: EGPRS downlink RLC data block header (FANR not activated)
for MCS-5 and MCS-6

For an EGPRS TBF with FANR activated and for an EGPRS2 TBF (see sub-clause 5.2.1), the downlink RLC/MAC header for MCS-5 and MCS-6 shall be formatted according to figure 10.3a.3.2.2, whereas the RLC/MAC header for DAS-5, DAS-6 and DAS-7 shall be formatted as shown on figure 10.3a.3.2.2.

Bit
8	7	6	5	4	3	2	1	Octet
TFI	PANI	CES/P			USF			1
BSN1		PR		TFI				2
BSN1								3
				CPS			BSN1	4

Figure 10.3a.3.2.2: EGPRS (FANR activated) / EGPRS2 downlink RLC data block header
for MCS-5, MCS-6, DAS-5, DAS-6 and DAS-7

For an EGPRS TBF without FANR activated in a DLMC configuration using an SNS of 8192, the EGPRS combined downlink RLC/MAC header for MCS‑5 and MCS‑6 (header type 2) shall be formatted according to figure 10.3a.3.2.3.

Bit
8	7	6	5	4	3	2	1	Octet
TFI	spare	RRBP	ES/P		USF			1
BSN1				TFI				2
BSN1								3
				CPS			BSN1	4

Figure 10.3a.3.2.3: DLMC EGPRS downlink RLC data block header (FANR not activated)
for MCS-5 and MCS-6

For an EGPRS TBF with FANR activated in a DLMC configuration using an SNS of 8192 and for an EGPRS2 TBF in a DLMC configuration using an SNS of 8192, the downlink RLC/MAC header for MCS-5, MCS-6, DAS-5, DAS-6 and DAS-7 shall be formatted according to figure 10.3a.3.2.4.

Bit
8	7	6		5	4	3	2	1	Octet
TFI	PANI	spare	CES/P			USF			1
BSN1					TFI				2
BSN1									3
					CPS			BSN1	4

Figure 10.3a.3.2.4: DLMC EGPRS (FANR activated) / DLMC EGPRS2 downlink RLC data block header
for MCS-5, MCS-6, DAS-5, DAS-6 and DAS-7

For an EC TBF, the EGPRS combined downlink RLC/MAC header for MCS‑5 and MCS‑6 (header type 2) shall be formatted according to figure 10.3a.3.2.5.

Bit
8		7		6	5	4	3	2	1	Octet
TFI	Spare		RRBP		ECS/P		USF			1
BSN1			PR			TFI				2
RRBP			CPS				BSN1			3
						Spare				4

Figure 10.3a.3.2.5: EC-GSM-IoT downlink RLC data block header for MCS-5 and MCS-6

10.3a.3.3 Header type 3: header for MCS-4, MCS-3, MCS-2, MCS-1 and MCS-0 case

For an EGPRS TBF without FANR activated, the EGPRS combined downlink RLC/MAC header for MCS‑1, MCS‑2, MCS‑3 and MCS‑4 (header type 3) shall be formatted according to figure 10.3a.3.3.1.

Bit
8	7			6		5		4	3	2		1	Octet
TFI	RRBP					ES/P			USF				1
BSN1			PR				TFI						2
BSN1													3
		SPB			CPS						BSN1		4

Figure 10.3a.3.3.1: EGPRS downlink RLC data block header (FANR not activated)
for MCS-1, MCS-2, MCS-3 and MCS-4

For an EGPRS TBF with FANR activated and for an EGPRS2 TBF (see sub-clause 5.2.1), the downlink RLC/MAC header for MCS-1, MCS-2, MCS-3 and MCS-4 shall be formatted according to figure 10.3a.3.3.2.

Bit
8	7			6		5		4	3	2		1	Octet
TFI	PANI		CES/P						USF				1
BSN1			PR				TFI						2
BSN1													3
		SPB			CPS						BSN1		4

Figure 10.3a.3.3.2: EGPRS (FANR activated) / EGPRS2 downlink RLC data block header
for MCS-1, MCS-2, MCS-3 and MCS-4

For a TBF in RTTI configuration, the downlink RLC/MAC control block header for MCS-0 shall be formatted as defined in figure 10.3a.3.3.3.

Bit
8	7	6	5	4	3	2	1	Octet
Payload type	Spare		RRBP	S/P	USF			1
0	0	0	0	0	0	0	0	2
0	0	0	0	0	0	0	0	3
	0	0	CPS				Spare	4
NOTE2: Field indicated as ‘0’ will be replaced by an 18 bit CRC during the channel coding, see sub-clause 5.1.4a.1.4 in 3GPP TS 45.003.

Figure 10.3a.3.3.3: Downlink RLC/MAC control block header
for MCS-0.

For an EGPRS TBF without FANR activated in a DLMC configuration using an SNS of 8192, the EGPRS combined downlink RLC/MAC header for MCS‑1, MCS‑2, MCS‑3 and MCS‑4 (header type 3) shall be formatted according to figure 10.3a.3.3.4.

Bit
8	7		6		5		4	3	2		1	Octet
TFI	spare		RRBP		ES/P			USF				1
BSN1						TFI						2
BSN1												3
		SPB		CPS						BSN1		4

Figure 10.3a.3.3.4: DLMC EGPRS downlink RLC data block header (FANR not activated)
for MCS-1, MCS-2, MCS-3 and MCS-4

For an EGPRS TBF with FANR activated in a DLMC configuration using an SNS of 8192 and for an EGPRS2 TBF in a DLMC configuration using an SNS of 8192, the downlink RLC/MAC header for MCS-1, MCS-2, MCS-3 and MCS-4 shall be formatted according to figure 10.3a.3.3.2.

Bit
8	7			6		5		4	3	2		1	Octet
TFI	PANI		spare		CES/P				USF				1
BSN1							TFI						2
BSN1													3
		SPB			CPS						BSN1		4

Figure 10.3a.3.3.5: DLMC EGPRS (FANR activated) / DLMC EGPRS2 downlink RLC data block header
for MCS-1, MCS-2, MCS-3 and MCS-4

For an EC TBF, the EGPRS combined downlink RLC/MAC header for MCS‑1, MCS‑2, MCS‑3 and MCS‑4 (header type 3) shall be formatted according to figure 10.3a.3.3.6. Note that different USF values may be included in the different transmissions if blind physical layer transmissions are used in the downlink (when CC2, CC3 or CC4 is assigned for the transfer).

Bit
8		7		6	5	4	3	2	1	Octet
TFI	Spare		RRBP		ECS/P		USF			1
BSN1			PR			TFI				2
Spare	CC				SPB		BSN1			3
	Spare				RRBP		CPS			4

Figure 10.3a.3.3.6: EC-GSM-IoT downlink RLC data block header for MCS-1, MCS-2, MCS-3 and MCS-4

10.3a.3.4 Header type 4: header for DAS-8 and DAS-9

The combined downlink RLC/MAC header for DAS-8 and DAS-9 (header type 4) shall be formatted according to figure 10.3a.3.4.1.

Bit
8		7	6	5	4	3	2	1	Octet
TFI		PANI	CES/P			USF			1
BSN1			PR		TFI				2
BSN1									3
BSN2								BSN1	4
Spare	CPS					BSN2			5
								Spare	6

Figure 10.3a.3.4.1: Combined downlink RLC data block header
for DAS-8 and DAS-9.

For an EGPRS2 TBF in a DLMC configuration using an SNS of 8192 the combined downlink RLC/MAC header for DAS-8 and DAS-9 (header type 4) shall be formatted according to figure 10.3a.3.4.2.

Bit
8		7	6	5	4	3	2	1	Octet
TFI		PANI	BSN2	CES/P		USF			1
BSN1					TFI				2
BSN1									3
BSN2								BSN1	4
BSN2	CPS					BSN2			5
								Spare	6

Figure 10.3a.3.4.2: DLMC Combined downlink RLC data block header
for DAS-8 and DAS-9.

10.3a.3.5 Header type 5: header for DAS-11 and DAS-12

The combined downlink RLC/MAC header for DAS-11 and DAS-12 (header type 5) shall be formatted according to figure 10.3a.3.5.1.

Bit
8	7	6		5	4		3	2	1	Octet
TFI	PANI	CES/P					USF			1
BSN1		PR			TFI					2
BSN1										3
BSN2									BSN1	4
BSN3							BSN2			5
CPS			BSN3							6
			Spare			CPS				7

Figure 10.3a.3.5.1: Combined downlink RLC data block header
for DAS-11 and DAS-12.

For an EGPRS2 TBF in a DLMC configuration using an SNS of 8192 the combined downlink RLC/MAC header for DAS-11 and DAS-12 (header type 5) shall be formatted according to figure 10.3a.3.5.2.

Bit
8	7	6		5	4	3	2	1	Octet
TFI	PANI	BSN2	CES/P			USF			1
BSN1					TFI				2
BSN1									3
BSN2								BSN1	4
BSN3						BSN2			5
CPS			BSN3						6
			BSN2		BSN3	CPS			7

Figure 10.3a.3.5.2: DLMC Combined downlink RLC data block header
for DAS-11 and DAS-12.

10.3a.3.6 Header type 6: header for DBS-5 and DBS-6

The combined downlink RLC/MAC header for DBS-5 and DBS-6 (header type 6) shall be formatted according to figure 10.3a.3.6.1.

Bit
8	7	6		5	4	3	2	1		Octet
TFI	PANI		CES/P			USF				1
BSN		PR			TFI					2
BSN									3
		Spare			CPS			BSN		4

Figure 10.3a.3.6.1: Combined downlink RLC data block header
for DBS-5 and DBS-6.

10.3a.3.7 Header type 7: header for DBS-7 and DBS-8

The combined downlink RLC/MAC header for DBS-7 and DBS-8 (header type 7) shall be formatted according to figure 10.3a.3.7.1.

Bit
8		7	6	5	4	3	2	1	Octet
TFI	PANI		CES/P			USF			1
BSN1			PR		TFI				2
BSN1									3
BSN2								BSN1	4
Spare	CPS					BSN2			5
								Spare	6

Figure 10.3a.3.7.1: Combined downlink RLC data block header
for DBS-7 and DBS-8.

10.3a.3.8 Header type 8: header for DBS-9 and DBS-10

The combined downlink RLC/MAC header for DBS-9 and DBS-10 (header type 8) shall be formatted according to figure 10.3a.3.8.1.

Bit
8		7		6	5	4	3	2	1	Octet
TFI	PANI			CES/P			USF			1
BSN1			PR			TFI				2
BSN1										3
BSN2									BSN1	4
BSN 3							BSN2			5
CPS					BSN3					6
					Spare		CPS			7

Figure 10.3a.3.8.1: Combined downlink RLC data block header
for DBS-9 and DBS-10.

10.3a.3.9 Header type 9: header for DBS-11 and DBS-12

The combined downlink RLC/MAC header for DBS-11 and DBS-12 (header type 9) shall be formatted according to figure 10.3a.3.9.1.

Bit
8			7		6	5	4	3	2	1	Octet
TFI		PANI			CES/P			USF			1
BSN1				PR			TFI				2
BSN1											3
BSN2										BSN1	4
BSN 3								BSN2			5
BSN4						BSN3					6
CPS	BSN4										7
Spare	CPS										8
										Spare	9

Figure 10.3a.3.9.1: Combined downlink RLC data block header
for DBS-11 and DBS-12.

10.3a.3.10 Header type 10: header for DAS-10

The combined downlink RLC/MAC header for DAS-10 (header type 10) shall be formatted according to figure 10.3a.3.10.1.

Bit
8		7	6		5	4	3	2	1	Octet
TFI		PANI	CES/P				USF			1
BSN1			PR			TFI				2
BSN1										3
BSN2									BSN1	4
	Spare			CPS			BSN2			5

Figure 10.3a.3.10.1: Combined downlink RLC data block header
for DAS-10.

For an EGPRS2 TBF in a DLMC configuration using an SNS of 8192 the combined downlink RLC/MAC header for DAS-10 (header type 10) shall be formatted according to figure 10.3a.3.10.2.

Bit
8		7		6		5	4	3	2	1	Octet
TFI		PANI		BSN2	CES/P			USF			1
BSN1							TFI				2
BSN1											3
BSN2										BSN1	4
	BSN2		Spare		CPS			BSN2			5

Figure 10.3a.3.10.2: DLMC Combined downlink RLC data block header
for DAS-10.

10.3a.4 EGPRS and EC-GSM-IoT Uplink RLC/MAC header

10.3a.4.1 Header type 1: header for MCS-7, MCS-8 and MCS-9

The EGPRS combined uplink RLC/MAC header for MCS‑7, MCS‑8 and MCS‑9 (header type 1) shall be formatted according to figure 10.3a.4.1.1.

Bit
8	7	6	5	4	3	2	1	Octet
TFI		Countdown Value				SI	R	1
BSN1					TFI			2
BSN2		BSN1						3
BSN2								4
Spare	PI	RSB	CPS					5
		Spare						6

Figure 10.3a.4.1.1: EGPRS uplink RLC data block header (FANR not activated)
for MCS-7, MCS-8 and MCS-9.

For a EGPRS TBF with FANR activated, the uplink RLC/MAC header for MCS-7, MCS-8 and MCS-9 shall be formatted according to figure 10.3a.4.1.2.

Bit
8	7	6	5	4	3	2	1	Octet
TFI		Countdown Value				SI	R	1
BSN1					TFI			2
BSN2		BSN1						3
BSN2								4
PANI	PI	RSB	CPS					5
		Spare						6

Figure 10.3a.4.1.2: EGPRS uplink RLC data block header (FANR activated)
for MCS-7, MCS-8 and MCS-9.

The EC-GSM-IoT combined uplink RLC/MAC header for MCS‑7, MCS‑8 and MCS‑9 (header type 1) shall be formatted according to figure 10.3a.4.1.3.

Bit
8	7		6		5		4	3	2		1	Octet
TFI			Countdown Value						FOI		RI	1
BSN1								TFI				2
Spare						BSN2						3
DCCE				CPS								4
Spare				rTLLI						DCCE		5
		Spare										6

Figure 10.3a.4.1.3: EC-GSM-IoT uplink RLC data block header for MCS-7, MCS-8 and MCS-9.

10.3a.4.2 Header type 2: header for MCS-6 and MCS-5

The EGPRS combined uplink RLC/MAC header for MCS‑5 and MCS‑6 (header type 2) shall be formatted according to figure 10.3a.4.2.1.

Bit
8	7	6	5	4	3	2		1	Octet
TFI		Countdown Value				SI		R	1
BSN1					TFI				2
CPS		BSN1							3
Spare					PI	RSB	CPS		4
			Spare						5

Figure 10.3a.4.2.1: EGPRS uplink RLC data block header (FANR not activated)
for MCS-5 and MCS-6

For an EGPRS TBF with FANR activated and for an EGPRS2 TBF, the uplink RLC/MAC header for MCS-5 and MCS-6 shall be formatted according to figure 10.3a.4.2.2.

Bit
8	7	6	5		4	3	2		1	Octet
TFI		Countdown Value					SI		R	1
BSN1						TFI				2
CPS		BSN1								3
Spare				PANI		PI	RSB	CPS		4
			Spare							5

Figure 10.3a.4.2.2: EGPRS (FANR activated) / EGPRS2 uplink RLC data block header
for MCS-5 and MCS-6

The EC-GSM-IoT combined uplink RLC/MAC header for MCS‑5 and MCS‑6 (header type 2) shall be formatted according to figure 10.3a.4.2.3.

Bit
8		7	6	5		4	3	2	1	Octet
TFI			Countdown Value					FOI	RI	1
BSN1							TFI			2
Spare	DCCE						CPS			3
Spare					rTLLI					4
				Spare						5

Figure 10.3a.4.2.3: EC-GSM-IoT uplink RLC data block header for MCS-5 and MCS-6

10.3a.4.3 Header type 3 : header for MCS-4, MCS-3, MCS-2 and MCS-1

The EGPRS combined uplink RLC/MAC header for MCS‑1, MCS‑2, MCS‑3 and MCS‑4 (header type 3) shall be formatted according to figure 10.3a.4.3.1.

Bit
8	7	6	5	4	3	2	1	Octet
TFI		Countdown Value				SI	R	1
BSN1					TFI			2
CPS		BSN1						3
	Spare	PI	RSB	SPB		CPS		4

Figure 10.3a.4.3.1: EGPRS uplink RLC data block header (FANR not activated)
for MCS-1, MCS-2, MCS-3 and MCS-4

For an EGPRS TBF with FANR activated and for an EGPRS2 TBF, the uplink RLC/MAC header for MCS-1, MCS-2, MCS-3 and MCS-4 shall be formatted according to figure 10.3a.4.3.2.

Bit
8	7	6	5	4	3	2	1	Octet
TFI		Countdown Value				SI	R	1
BSN1					TFI			2
CPS		BSN1						3
	PANI	PI	RSB	SPB		CPS		4

Figure 10.3a.4.3.2: EGPRS (FANR activated)/EGPRS2 uplink RLC data block header
for MCS-1, MCS-2, MCS-3 and MCS-4

The EC-GSM-IoT combined uplink RLC/MAC header for MCS‑1, MCS‑2, MCS‑3 and MCS‑4 (header type 3) shall be formatted according to figure 10.3a.4.3.3.

				Bit
8	7	6	5	4	3	2	1	Octet
TFI		Countdown Value				FOI	RI	1
BSN1					TFI			2
DCCE			SPB		CPS/HCS			3
	Spare		rTLLI				DCCE	4

Figure 10.3a.4.3.3: EC-GSM-IoT uplink RLC data block header for MCS-1, MCS-2, MCS-3 and MCS-4

10.3a.4.4 Header type 4: header for UAS-7, UAS-8 and UAS-9

The combined uplink RLC/MAC header for UAS-7, UAS-8 and UAS-9 (header type 4) shall be formatted according to figure 10.3a.4.4.1.

Bit
8	7	6	5	4	3	2	1	Octet
TFI		Countdown Value				SI	R	1
BSN1					TFI			2
BSN2		BSN1						3
BSN2								4
Spare	PANI	PI	CPS					5
							Spare	6

Figure 10.3a.4.4.1: Combined uplink RLC data block header
for UAS-7, UAS-8 and UAS-9.

10.3a.4.5 Header type 5: header for UAS-10 and UAS-11

The combined uplink RLC/MAC header for UAS-10 and UAS-11 (header type 5) shall be formatted according to figure 10.3a.4.5.1.

Bit
8	7	6	5	4	3	2	1	Octet
TFI		Countdown Value				SI	R	1
BSN1					TFI			2
BSN2		BSN1						3
BSN2								4
BSN3								5
CPS						BSN3		6
				Spare		PANI	PI	7

Figure 10.3a.4.5.1: Combined uplink RLC data block header
for UAS-10, UAS-11.

10.3a.4.6 Header type 6: header for UBS-5 and UBS-6

The combined uplink RLC/MAC header for UBS-5 and UBS-6 (header type 6) shall be formatted according to figure 10.3a.4.6.1.

Bit
8	7	6		5	4	3	2	1	Octet
TFI		Countdown Value					SI	R	1
BSN						TFI			2
CPS		BSN							3
			Spare			PANI	PI	CPS	4

Figure 10.3a.4.6.1: Combined uplink RLC data block header
for UBS-5, UBS-6.

10.3a.4.7 Header type 7: header for UBS-7 and UBS-8

The combined uplink RLC/MAC header for UBS-7 and UBS-8 (header type 7) shall be formatted according to figure 10.3a.4.7.1.

Bit
8	7		6	5	4	3	2	1	Octet
TFI			Countdown Value				SI	R	1
BSN1						TFI			2
BSN2			BSN1						3
BSN2									4
Spare		PANI		PI	CPS				5

Figure 10.3a.4.7.1: Combined uplink RLC data block header
for UBS-7, UBS-8.

10.3a.4.8 Header type 8: header for UBS-9 and UBS-10

The combined uplink RLC/MAC header for UBS-9 and UBS-10 (header type 8) shall be formatted according to figure 10.3a.4.8.1.

Bit
8	7	6	5	4	3	2	1	Octet
TFI		Countdown Value				SI	R	1
BSN1					TFI			2
BSN2		BSN1						3
BSN2								4
BSN3								5
CPS						BSN3		6
				Spare		PANI	PI	7

Figure 10.3a.4.8.1: Combined uplink RLC data block header
for UBS-9, UBS-10.

10.3a.4.9 Header type 9: header for UBS-11 and UBS-12

The combined uplink RLC/MAC header for UBS-11 and UBS-12 (header type 9) shall be formatted according to figure 10.3a.4.9.1.

Bit
8	7	6		5		4	3	2	1	Octet
TFI		Countdown Value						SI	R	1
BSN1							TFI			2
BSN2		BSN1								3
BSN2										4
BSN3										5
BSN4								BSN3		6
CPS						BSN4				7
Spare			PANI		PI	CPS				8

Figure 10.3a.4.9.1: Combined uplink RLC data block header
for UBS-11, UBS-12.

10.3a.4.10 Header type 4: header for MCS-1’

The EC-GSM-IoT combined uplink RLC/MAC header for MCS-1’ shall be formatted according to figure 10.3a.4.10.1. This header type is used on UL when the MS is assigned uplink coverage class CC5 for EC-PDTCH.


				Bit
8	7	6	5			4		3	2			1	Octet
Countdown Value					DLCC					FOI	RI			1
rTLLI							SPB				Spare			2

Figure 10.3a.4.10.1: EC-GSM-IoT uplink RLC data block header for MCS-1’.

10.3a.5 Piggy-backed Ack/Nack field (SSN-based)

When the SSN-based encoding is used (see sub-clause 9.1.14.1), the Piggy-backed Ack/Nack (PAN) field consists of a beginning of window (BOW), a short starting sequence number (ShortSSN), a reported bitmap (RB) and a temporary flow identifier (TFI) fields. In the downlink direction, the TFI field shall always include a valid value. In the uplink direction, the TFI field, or the combined TFI-eTFI fields (in case of a DLMC configuration and eTFI is assigned), shall include a valid value only if multiple TBF procedures or EMST or EMSR are supported by both the network and the mobile station; in all other cases, the bits of these fields shall be set to ‘0’. The length of the PAN field is 25 bits except if an eTFI is assigned in which case the length of the PAN is 28 bits in the uplink direction. The size of the ShortSSN field (defined in sub-clause 10.4.23) varies between 7 and 11 bits as shown in Figure 10.3a.5.1 except for a DLMC configuration where the size of the ShortSSN field varies between 11 and 13 bits (see sub-clause 10.4.12) in the uplink direction as shown in Figure 10.3a.5.2. The remaining bits in the PAN field are reserved for the reported bitmap with a size varying between 6 and 12 bits.

The order of bits is as for the UNCOMPRESSED_RECEIVE_BLOCK_BITMAP field in the EGPRS Ack/Nack Description information element (see sub-clause 12.3.1) i.e. the lowest order bit in the RB field corresponds to the block with the sequence number from which the ShortSSN is derived.

Bit
8	7	6	5	4	3	2	1	Octet
ShortSSN							BOW	1
RB				ShortSSN / RB				2
TFI				RB				3
							TFI	4

Figure 10.3a.5.1: Piggy-backed Ack/Nack field (SSN-based)

Bit
8	7		6	5	4	3	2	1	Octet
ShortSSN								BOW	1
RB		ShortSSN / RB			ShortSSN				2
TFI					RB				3
					eTFI			TFI	4

Figure 10.3a.5.2: Uplink Piggy-backed Ack/Nack field (SSN-based, eTFI assigned)

10.3a.6 Piggy-backed Ack/Nack field (Time-based)

When the Time-based encoding is used (see sub-clause 9.1.14.1), the Piggy-backed Ack/Nack (PAN) field consists of a 20 bits reported bitmap, as described in sub-clause 9.1.15, plus 5 bits set to ‘0.

Codepoints are included so that the codepoints corresponding to blocks transmitted earlier are contained in the less significant bit(s) in the field.

Bit
8		7	6	5	4	3	2	1	Octet
Reported bitmap									1
Reported bitmap (continued)									2
0	0		0	0	Reported bitmap (cont)				3
								0	4

Figure 10.3a.6.1: Piggy-backed Ack/Nack field (Time-based)

10.4 Header fields

10.4.1 Uplink state flag (USF) field

The USF field is sent in all downlink RLC/MAC blocks and indicates the owner or use of the next uplink radio block on the same timeslot (see 3GPP TS 45.002). The USF field is three bits in length and eight different USF values can be assigned, except on PCCCH, where the value ‘111’ (USF=FREE) indicates that the corresponding uplink radio block contains PRACH.

10.4.2 Retry (R) bit

The Retry (R) bit shall indicate whether the mobile station transmitted the CHANNEL REQUEST message (see 3GPP TS 44.018), PACKET CHANNEL REQUEST message, EGPRS PACKET CHANNEL REQUEST message or MPRACH PACKET CHANNEL REQUEST message one time or more than one time during its most recent channel access. The mobile station shall send the same value for the R bit in each uplink RLC/MAC block of the TBF.

Table 10.4.2.1: Retry (R) bit

bit 1	Retry (R) bit
0	MS sent channel request message once
1	MS sent channel request message twice or more

10.4.3 Stall indicator (SI) bit

The Stall indicator (SI) bit indicates whether the mobile’s RLC transmit window can advance (i.e. is not stalled) or can not advance (i.e. is stalled). The mobile station shall set the SI bit in all uplink RLC data blocks.

Table 10.4.3.1: Stall indicator bit

bit 1	Stall indicator
0	MS RLC transmit window is not stalled
1	MS RLC transmit window is stalled
NOTE 1: The bit numbering is relative to the field position.

10.4.4 Supplementary/Polling (S/P) Bit

The S/P bit is used to indicate whether the RRBP field is valid or not valid in downlink GPRS RLC data blocks and downlink RLC/MAC control blocks using the coding scheme of CS-1and in downlink EC-GSM-IoT RLC/MAC control blocks on EC-PACCH/D.

Table 10.4.4.1: Supplementary/Polling (S/P) bit – GPRS case and RLC/MAC control

bit 4	S/P
0	RRBP field is not valid
1	RRBP field is valid

10.4.4a EGPRS Supplementary/Polling (ES/P) Field

The ES/P field is used to indicate whether the RRBP field is valid or not valid, and what fields the next uplink control block shall contain (see further clause 9).

NOTE: The type of Ack/Nack bitmap requested by this field is applicable only when the next uplink control block is used to send an EGPRS PACKET DOWNLINK ACK/NACK, EGPRS PACKET DOWNLINK ACK/NACK TYPE 2, EGPRS PACKET DOWNLINK ACK/NACK TYPE 3, EGPRS PACKET DOWNLINK ACK/NACK DLMC or MBMS DOWNLINK ACK/NACK message.

Table 10.4.4a.1: EGPRS Supplementary/Polling (ES/P) field (non-MBMS only)

bits 5 4	ES/P
0 0	RRBP field is not valid (no Polling)
0 1	RRBP field is valid – Extended Ack/Nack bitmap type FPB
1 0	RRBP field is valid – Extended Ack/Nack bitmap type NPB
1 1	RRBP field is valid – Extended Ack/Nack bitmap type NPB, measurement report included

Table 10.4.4a.2: EGPRS Supplementary/Polling (ES/P) field (MBMS only)

bits 5 4	ES/P
0 0	RRBP field is not valid (no Polling)
0 1	RRBP field is valid – Extended Ack/Nack bitmap type FPB
1 0	RRBP field is valid – Extended Ack/Nack bitmap type NPB
1 1	RRBP field is valid – Extended Ack/Nack bitmap type NPB, neighbouring cell measurement reports included

10.4.4b Combined EGPRS Supplementary/Polling (CES/P) Field

The CES/P field is used to indicate what fields the next uplink radio block reserved by this field shall contain (see further clause 9). The single uplink block is defined by a delay relative to the first TDMA frame (N) of the downlink block containing the CES/P value. The procedures defined for transmission of a PACCH block to the network as described in sub-clause 10.4.5 shall apply.

If the mobile station is polled for a Piggy-backed Ack/Nack, in case EFTA is not used at the time the CES/P field is received, the mobile station shall transmit the uplink radio block on the same timeslot as the block where the CES/P field was received (in case of a BTTI configuration) or on the uplink PDCH pair corresponding to the downlink PDCH pair where the block containing the CES/P field was received (in case of an RTTI configuration). In case EFTA is used at the time the CES/P field is received, the mobile station shall transmit the uplink radio block according to the uplink radio block transmission order as described in Annex N regardless of the timeslot or PDCH pair where the block containing the CES/P field was received. The mobile station need not monitor the USF in the associated downlink RLC/MAC block appearing just before the uplink block it shall transmit. However, when Extended Dynamic Allocation or Shifted USF operation is used, the corresponding USF monitoring procedure shall apply as described in sub-clause 8.1.1.2.1 and sub-clause 8.1.1.2.4 respectively.

Table 10.4.4b.1: Combined EGPRS Supplementary/Polling (CES/P) field

bits 6 5 4	CES/P
	Feedback	Reserved Block
		BTTI	RTTI
0 0 0	no Polling	–	–
0 0 1	Extended Ack/Nack bitmap type FPB, and if there is enough room left in RLC/MAC block, channel quality report(s)	(N+8 or N+9) mod 2715648	(N+6 or N+7) mod 2715648
0 1 0	Extended Ack/Nack bitmap type FPB, and if there is enough room left in RLC/MAC block, channel quality report(s)	(N+13) mod 2715648	(N+8 or N+9) mod 2715648
0 1 1	Piggy-backed Ack/Nack bitmap type FPB (see sub-clause 8.1.2.2) see note	(N+8 or N+9) mod 2715648	(N+6 or N+7) mod 2715648
1 0 0	Piggy-backed Ack/Nack bitmap type FPB (see sub-clause 8.1.2.2) see note	(N+13) mod 2715648	(N+8 or N+9) mod 2715648
1 0 1	Channel quality report(s), and if there is enough room left in RLC/MAC block, Extended Ack/Nack bitmap type NPB	(N+8 or N+9) mod 2715648	(N+6 or N+7) mod 2715648
1 1 0	Channel quality report(s), and if there is enough room left in RLC/MAC block, Extended Ack/Nack bitmap type NPB	(N+13) mod 2715648	(N+8 or N+9) mod 2715648
1 1 1	Extended Ack/Nack bitmap type NPB, and if there is enough room left in RLC/MAC block, channel quality report(s)	(N+8 or N+9) mod 2715648	(N+6 or N+7) mod 2715648
NOTE: In case where a PAN cannot be sent, the Extended Ack/Nack bitmap type NPB with measurement report included shall be transmitted on the allocated reserved block instead (see sub-clause 9.1.14.2).

In case of a DLMC configuration using an SNS of 8192 the CES/P field within the RLC data block header (see sub-clause 10.3a.3.1, 10.3a.3.2, 10.3a.3.3, 10.3a.3.4, 10.3a.3.5 and 10.3a.3.10) is coded as shown in Table 10.4.4b.2.

Table 10.4.4b.2: Combined EGPRS Supplementary/Polling (CES/P) field – DLMC Configuration

bits 5 4	CES/P
	Feedback	Reserved Block
	Feedback	BTTI	RTTI
0 0	no Polling	–	–
0 1	Extended Ack/Nack bitmap type FPB, and if there is enough room left in the RLC/MAC block, channel quality report(s)	(N+8 or N+9) mod 2715648	(N+6 or N+7) mod 2715648
1 0	Channel quality report(s), and if there is enough room left in the RLC/MAC block, Extended Ack/Nack bitmap type NPB	(N+8 or N+9) mod 2715648	(N+6 or N+7) mod 2715648
1 1	Piggy-backed Ack/Nack bitmap type FPB (see sub-clause 8.1.2.2) – see note	(N+8 or N+9) mod 2715648	(N+6 or N+7) mod 2715648
NOTE: In case where a PAN cannot be sent, the Extended Ack/Nack bitmap type NPB with channel quality report(s) included shall be transmitted on the allocated reserved block instead (see sub-clause 9.1.14.2).

10.4.4c EC-GSM-IoT Supplementary/Polling (ECS/P) Field

The ECS/P field is used to indicate whether the RRBP field is valid or not valid and, if valid, if a quality report is to be included in the next uplink control block.

Table 10.4.4c.1: EC-GSM-IoT Supplementary/Polling (ECS/P) field

bits 5 4	ECS/P
0 0	RRBP field is not valid (no Polling)
0 1	RRBP field is valid, Ack/Nack report to be included
1 0	RRBP field is valid, Ack/Nack report to be included. If there is enough room in the RLC/MAC block, a channel quality report shall also be included.
1 1	Reserved

10.4.5 Relative Reserved Block Period (RRBP) field

The RRBP value specifies a single uplink block in which the mobile station shall transmit either a PACKET CONTROL ACKNOWLEDGEMENT message, an EC PACKET CONTROL ACKNOWLEDGEMENT or EC PACKET CONTROL ACKNOWLEDGEMENT HIGHER CC message, a PACCH block or an EC-PACCH block to the network. If the RRBP field is received as part of an RLC/MAC block containing an RLC/MAC control block, the mobile station shall transmit a PACKET CONTROL ACKNOWLEDGEMENT or an EC PACKET CONTROL ACKNOWLEDGEMENT or EC PACKET CONTROL ACKNOWLEDGEMENT HIGHER CC message in the uplink radio block specified, except if:

– The received message is a Packet Paging Request, Packet Access Reject, or Packet Queuing Notification message, or

– It is specified elsewhere that the mobile station shall not respond to the polling request.

If the RRBP field is received as part of an RLC/MAC block containing an RLC/MAC control block containing a Packet Paging Request, Packet Access Reject, or Packet Queuing Notification message, or it is specified elsewhere that the mobile station shall not respond to the polling request, the mobile station shall ignore this RRBP field. The mobile station shall only react on RLC/MAC control blocks containing a valid RRBP field if the mobile station is addressed either in the downlink RLC/MAC control block header or in the control message itself. If the control message is segmented into more than one downlink RLC/MAC control blocks the mobile station shall react only on RLC/MAC control blocks containing a valid RRBP field if the mobile station is addressed in the downlink RLC/MAC control block header.

If the mobile station receives two or more RLC/MAC blocks containing an RLC/MAC control message with different RRBP values such that they specify the same uplink block, the mobile station shall transmit one PACKET CONTROL ACKNOWLEDGEMENT or an EC PACKET CONTROL ACKNOWLEDGEMENT or EC PACKET CONTROL ACKNOWLEDGEMENT HIGHER CC message in the specified uplink radio block.

If the RRBP field is received as part of a RLC/MAC block containing an RLC data block, the mobile station shall transmit a PACCH block or an EC-PACCH block in the specified uplink radio block. If the mobile station receives two or more RLC/MAC blocks containing an RLC data block with different RRBP values such they specify the same uplink radio block, the mobile station shall transmit one (EC-)PACCH block in the specified uplink radio block.

If the mobile station receives an RLC data block and an RLC/MAC control block with different RRBP values such that they specify the same uplink radio block, the mobile station shall transmit a PACKET CONTROL ACKNOWLEDGEMENT or an EC PACKET CONTROL ACKNOWLEDGEMENT or EC PACKET CONTROL ACKNOWLEDGEMENT HIGHER CC message in the specified uplink radio block.

If no uplink control timeslot is assigned to the mobile station and EFTA is not used at the time the RRBP field is received, the mobile station shall transmit the uplink radio block on the same timeslot as the block where the RRBP was received (in case of a BTTI configuration) or on the corresponding uplink PDCH pair to the downlink PDCH pair where the block containing the RRBP was received (in case of a RTTI configuration). If EFTA is used at the time the RRBP field is received however, the mobile station shall instead transmit the uplink radio block according to the uplink radio block transmission order as described in Annex N regardless of the timeslot or PDCH-pair where the block containing the RRBP was received.

If an uplink control timeslot is assigned to the mobile station, the mobile station shall transmit the uplink radio block on this uplink control timeslot (in case of a BTTI configuration) or on the uplink PDCH pair the uplink control timeslot belongs to (in case of an RTTI configuration).

NOTE: In case of an RTTI configuration, the network should not poll the mobile station on a downlink PDCH pair for which no corresponding uplink PDCH pair exists.

After receiving an RLC/MAC block containing a valid RRBP field the mobile station need not monitor the USF in the associated downlink RLC/MAC block appearing just before the uplink block it shall transmit. However, when Extended Dynamic Allocation or Shifted USF operation is used, the corresponding USF monitoring procedure shall apply as described in sub-clause 8.1.1.2.1 and sub-clause 8.1.1.2.4 respectively.

After receiving an RLC/MAC block containing a valid RRBP field for an EC TBF, the mobile station need not monitor the downlink RLC/MAC blocks during the radio block periods where it shall transmit the uplink response.

A polled control message shall always be sent in the uplink block specified by the corresponding valid RRBP field of a downlink RLC/MAC control block, and not in any other uplink block that may be allocated to the mobile station.

The network should use the RRBP field to schedule the transmission of a PACKET CONTROL ACKNOWLEDGEMENT or an EC PACKET CONTROL ACKNOWLEDGEMENT or EC PACKET CONTROL ACKNOWLEDGEMENT HIGHER CC message or an uplink (EC-)PACCH block as follows:

– For BTTI configuration, no later than the second last BTTI radio block, B(x‑2) mod 12, before the first BTTI radio block, B(x), where the mobile station shall be ready to transmit and receive using a new assignment.

– For RTTI configuration, no later than the second last RTTI radio block, B(x‑2)_b, before the first RTTI radio block, B(x)_a, where the mobile station shall be ready to transmit and receive using a new assignment or no later than the second last RTTI radio block, B(x‑1)_a, before the first RTTI radio block, B(x)_b, where the mobile station shall be ready to transmit and receive using a new assignment.

A mobile station that is scheduled an uplink block later than these times, may omit responding to the polling request. If a new assignment specifies an uplink TBF, and the TTI configuration of the uplink TBF specified is the same as the TTI configuration of the ongoing uplink TBF that this assignment modifies, or if the assignment does not specify any uplink TBF, then the mobile station may delay the access using the new assignment in order to respond to the polling request.

The network should not use the RRBP field to schedule the transmission of PACKET CONTROL ACKNOWLEDGEMENT, EC PACKET CONTROL ACKNOWLEDGEMENT or EC PACKET CONTROL ACKNOWLEDGEMENT HIGHER CC messages or uplink (EC-) PACCH blocks, in such way, that a mobile station has more than three such uplink blocks pending for transmission at any instant. A mobile station, that is scheduled such uplink blocks more frequent than that, may omit responding to the excessive polling requests.

The RRBP field shall be interpreted according to the TTI configuration in use for the mobile station on the PDCH (or on the PDCH pair) where the block containing the RRBP field is received at the time it is received, and, for a BTTI configuration, according to whether FANR is activated or not for the mobile station.

For non EC TBFs with FANR not activated, Table 10.4.5.1 specifies the coding of the RRBP field indicating the number of TDMA frames the mobile station shall wait before transmitting the uplink RLC/MAC block. The delay is relative to the first TDMA frame (N) of the downlink block containing the RRBP value. For definition of TDMA frame numbering, see 3GPP TS 45.002.

Table 10.4.5.1: Relative Reserved Block Period (RRBP) field (FANR not activated)

bit 6-5/7-6	Full-rate PDCH uplink block with TDMA frame number	Full-rate PDCH uplink block with TDMA frame number (DLMC configuration with SNS 2048)	Half-rate PDCH uplink block with TDMA frame number
0 0	(N+13) mod 2715648	(N+13) mod 2715648	reserved
0 1	(N+17 or N+18) mod 2715648	(N+17 or N+18) mod 2715648	(N+17 or N+18) mod 2715648
1 0	(N+21 or N+22) mod 2715648	(N+21 or N+22) mod 2715648	reserved
1 1	(N+26) mod 2715648	(N+26) mod 2715648	(N+26) mod 2715648

If the mobile station is operating on a half-rate PDCH and it receives an RLC/MAC block with a reserved RRBP value, it shall regard the RRBP field as not valid and shall ignore the polling.

For TBFs with FANR activated, Table 10.4.5.2 specifies the coding of the RRBP field indicating the number of TDMA frames the mobile station shall wait before transmitting the uplink RLC/MAC block.

Table 10.4.5.2: Relative Reserved Block Period (RRBP) field (FANR activated)

bit 6-5	PDCH uplink block with TDMA frame number (BTTI)	PDCH uplink block with TDMA frame number (RTTI)
0 0	(N+13) mod 2715648	reserved
0 1	(N+8 or N+9) mod 2715648	(N+8 or N+9) mod 2715648
1 0	reserved	(N+6 or N+7) mod 2715648
1 1	reserved	reserved
NOTE: Table 10.4.5.2 only applies to RLC/MAC control blocks encoded using CS-1, while the CES/P field is used in case of polling in RLC data blocks (see sub-clause 10.4.4b).

In downlink RLC/MAC Control blocks encoded using MSC-0, a 1-bit RRBP is defined (see subclause 10.3a.3.3). In this case the number of TDMA frames the mobile station shall wait before transmitting the uplink RLC/MAC block is indicated in Table 10.4.5.3.

Table 10.4.5.3: Relative Reserved Block Period (RRBP) field – 1 bit field

bit 5	PDCH uplink block with TDMA frame number
0	(N+6 or N+7) mod 2715648
1	(N+8 or N+9) mod 2715648

In a DLMC configuration using an SNS of 8192 for a downlink TBF where FANR is not activated, Table 10.4.5.4 specifies the RRBP field in the RLC data block header (see sub-clause 10.3a.3.1, 10.3a.3.2 and 10.3a.3.3) by indicating the number of TDMA frames the mobile station shall wait before transmitting the uplink RLC/MAC block. The delay is relative to the first TDMA frame (N) of the downlink block containing the RRBP value. For definition of TDMA frame numbering, see 3GPP TS 45.002.

Table 10.4.5.4: Relative Reserved Block Period (RRBP) field (FANR not activated) – DLMC Configuration

bit 6	PDCH uplink block with TDMA frame number
0	(N+6 or N+7) mod 2715648
1	(N+8 or N+9) mod 2715648

For EC TBFs, Table 10.4.5.5 specifies the coding of the RRBP field if it is received as part of an RLC/MAC block containing an RLC/MAC data block indicating the number of TDMA frames the mobile station shall wait before transmitting the uplink RLC/MAC block according to its uplink Coverage Class. The delay is relative to the first TDMA frame (N) of the downlink block containing the last blind physical layer transmission of the EC-PACCH or EC-PDTCH message, according to the USED_DL_COVERAGE_CLASS field. For definition of TDMA frame numbering, see 3GPP TS 45.002 [13].

Table 10.4.5.5: Relative Reserved Block Period (RRBP) field (EC TBF mode) if received as part of an RLC/MAC block containing an RLC/MAC data block

bit 6 5 4	Full-rate PDCH uplink block with TDMA frame number given UL CC1 or CC2 with 4 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC3 with 4 PDCH allocation or UL CC2 with 2 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC4 with 4 PDCH allocation or UL CC3 with 2 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC4 with 2 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC5 with 4 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC5 with 2 PDCH allocation
0 0 0	(N+13) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648 or (N+21 or N+22) mod 2715648 or (N+26) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648 or (N+21 or N+22) mod 2715648 or (N+26) mod 2715648 or (N+30 or N+31) mod 2715648 or (N+34 or N+35) mod 2715648 or (N+39) mod 2715648 or (N+43 or N+44) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648 or (N+21 or N+22) mod 2715648 or (N+26) mod 2715648 Or (N+30 or N+31) mod 2715648 or (N+34 or N+35) mod 2715648 or (N+39) mod 2715648 or (N+43 or N+44) mod 2715648 Or (N+47 or N+48) mod 2715648 or (N+52) mod 2715648 or (N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648 or (N+21 or N+22) mod 2715648 or (N+26) mod 2715648 Or (N+30 or N+31) mod 2715648 or (N+34 or N+35) mod 2715648 or (N+39) mod 2715648 or (N+43 or N+44) mod 2715648 Or (N+47 or N+48) mod 2715648 or (N+52) mod 2715648 or (N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648 Or (N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648 Or (N+82 or N+83) mod 2715648 or (N+86 or N+87) mod 2715648 or (N+91) mod 2715648 or (N+95 or N+96) mod 2715648 Or (N+99 or N+100) mod 2715648 or (N+104) mod 2715648 or (N+108 or N+109) mod 2715648 or (N+112 or N+113) mod 2715648
0 0 1	(N+17 or N+18) mod 2715648	(N+21 or N+22) mod 2715648 or (N+26) mod 2715648	(N+30 or N+31) mod 2715648 or (N+34 or N+35) mod 2715648 or (N+39) mod 2715648 or (N+43 or N+44) mod 2715648	(N+47 or N+48) mod 2715648 or (N+52) mod 2715648 or (N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648 or (N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648	(N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648 Or (N+82 or N+83) mod 2715648 or (N+86 or N+87) mod 2715648 or (N+91) mod 2715648 or (N+95 or N+96) mod 2715648 Or (N+99 or N+100) mod 2715648 or (N+104) mod 2715648 or (N+108 or N+109) mod 2715648 or (N+112 or N+113) mod 2715648	(N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648 Or (N+82 or N+83) mod 2715648 or (N+86 or N+87) mod 2715648 or (N+91) mod 2715648 or (N+95 or N+96) mod 2715648 Or (N+99 or N+100) mod 2715648 or (N+104) mod 2715648 or (N+108 or N+109) mod 2715648 or (N+112 or N+113) mod 2715648 Or (N+117) mod 2715648 or (N+121 or N+122) mod 2715648 or (N+125 or N+126) mod 2715648 or (N+130) mod 2715648 Or (N+134 or N+135) mod 2715648 or (N+138 or N+139) mod 2715648 or (N+143) mod 2715648 or (N+147 or N+148) mod 2715648 Or (N+151 or N+152) mod 2715648 or (N+156) mod 2715648 or (N+160 or N+161) mod 2715648 or (N+164 or N+165) mode 2715648
0 1 0	(N+21 or N+22) mod 2715648	(N+30 or N+31) mod 2715648 or (N+34 or N+35 ) mod 2715648	(N+47 or N+48) mod 2715648 or (N+52) mod 2715648 or (N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648	(N+82 or N+83) mod 2715648 or (N+86 or N+87) mod 2715648 or (N+91) mod 2715648 or (N+95 or N+96) mod 2715648 or (N+99 or N+100) mod 2715648 or (N+104) mod 2715648 or (N+108 or N+109) mod 2715648 or (N+112 or N+113) mod 2715648	(N+117) mod 2715648 or (N+121 or N+122) mod 2715648 or (N+125 or N+126) mod 2715648 or (N+130) mod 2715648 Or (N+134 or N+135) mod 2715648 or (N+138 or N+139) mod 2715648 or (N+143) mod 2715648 or (N+147 or N+148) mod 2715648 Or (N+151 or N+152) mod 2715648 or (N+156) mod 2715648 or (N+160 or N+161) mod 2715648 or (N+164 or N+165) mode 2715648	Reserved
0 1 1	(N+26) mod 2715648	(N+39) mod 2715648 or (N+43 or N+44) mod 2715648	(N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648	(N+117) mod 2715648 or (N+121 or N+122) mod 2715648 or (N+125 or N+126) mod 2715648 or (N+130) mod 2715648 or (N+134 or N+135) mod 2715648 or (N+138 or N+139) mod 2715648 or (N+143) mod 2715648 or (N+147 or N+148) mod 2715648	(N+169) mod 2715648 or (N+173 or N+174) mod 2715648 or (N+177 or N+178) mod 2715648 or (N+182) mod 2715648 Or (N+186 or N+187) mod 2715648 or (N+190 or N+191) mod 2715648 or (N+195) mod 2715648 or (N+199 or N+200) mod 2715648 Or (N+203 or N+204) mod 2715648 or (N+208) mod 2715648 or (N+212 or N+213) mod 2715648 or (N+216 or N+217) mode 2715648	Reserved
1 0 0	(N+30 or N+31) mod 2715648	(N+47 or N+48) mod 2715648 or (N+52) mod 2715648	(N+82 or N+83) mod 2715648 or (N+86 or N+87) mod 2715648 or (N+91) mod 2715648 or (N+95 or N+96) mod 2715648	(N+151 or N+152) mod 2715648 or (N+156) mod 2715648 or (N+160 or N+161) mod 2715648 or (N+164 or N+165) mod 2715648 or (N+169) mod 2715648 or (N+173 or N+174) mod 2715648 or (N+177 or N+178) mod 2715648 or (N+182) mod 2715648	Reserved	Reserved
1 0 1	(N+34 or N+35) mod 2715648	(N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648	(N+99 or N+100) mod 2715648 or (N+104) mod 2715648 or (N+108 or N+109) mod 2715648 or (N+112 or N+113) mod 2715648	(N+186 or N+187) mod 2715648 or (N+190 or N+191) mod 2715648 or (N+195) mod 2715648 or (N+199 or N+200) mod 2715648 or (N+203 or N+204) mod 2715648 or (N+208) mod 2715648 or (N+212 or N+213) mod 2715648 or (N+216 or N+217) mod 2715648	Reserved	Reserved
1 1 0	(N+39) mod 2715648	(N+65) mod 2715648 or (N+69 or N+70) mod 2715648	(N+117) mod 2715648 or (N+121 or N+122) mod 2715648 or (N+125 or N+126) mod 2715648 or (N+130) mod 2715648	(N+221) mod 2715648 or (N+225 or N+226) mod 2715648 or (N+229 or N+230) mod 2715648 or (N+234) mod 2715648 or (N+238 or N+239) mod 2715648 or (N+242 or N+243) mod 2715648 or (N+247) mod 2715648 or (N+251 or N+252) mod 2715648	Reserved	Reserved
1 1 1	(N+43 or N+44) mod 2715648	(N+73 or N+74) mod 2715648 or (N+78) mod 2715648	(N+134 or N+135) mod 2715648 or (N+138 or N+139) mod 2715648 or (N+143) mod 2715648 or (N+147 or N+148) mod 2715648	(N+255 or N+256) mod 2715648 or (N+260) mod 2715648 or (N+264 or N+265) mod 2715648 or (N+268 or N+269) mod 2715648 or (N+273) mod 2715648 or (N+277 or N+278) mod 2715648 or (N+281 or N+282) mod 2715648 or (N+286) mod 2715648	Reserved	Reserved
NOTE: Each RRBP value in Table 10.4.5.5 will assign only one valid uplink block given the downlink coverage class used, i.e. when the poll is received, and the uplink coverage class used. See 3GPP TS 45.002 [13] for the coverage class dependent channel mappings. The code points which indicates Reserved are not intended to be used.

For EC TBFs, Table 10.4.5.6 specifies the coding of the RRBP field if it is received as part of an RLC/MAC block containing an RLC/MAC control block indicating the number of TDMA frames the mobile station shall wait before transmitting the uplink RLC/MAC block according to its uplink Coverage Class. The delay is relative to the first TDMA frame (N) of the downlink block containing the last blind physical layer transmission of the EC-PACCH or EC-PDTCH message, according to the USED_DL_COVERAGE_CLASS field. For definition of TDMA frame numbering, see 3GPP TS 45.002 [13].

Table 10.4.5.6: Relative Reserved Block Period (RRBP) field (EC TBF mode) if received as part of an RLC/MAC block containing an RLC/MAC control block

bit 3 2	Full-rate PDCH uplink block with TDMA frame number given UL CC1 or CC2 with 4 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC3 with 4 PDCH allocation or UL CC2 with 2 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC4 with 4 PDCH allocation or UL CC3 with 2 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC4 with 2 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC5 with 4 PDCH allocation	Full-rate PDCH uplink block with TDMA frame number given UL CC5 with 2 PDCH allocation
0 0	(N+13) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648 or (N+21 or N+22) mod 2715648 or (N+26) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648 or (N+21 or N+22) mod 2715648 or (N+26) mod 2715648 or (N+30 or N+31) mod 2715648 or (N+34 or N+35) mod 2715648 or (N+39) mod 2715648 or (N+43 or N+44) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648 or (N+21 or N+22) mod 2715648 or (N+26) mod 2715648 Or (N+30 or N+31) mod 2715648 or (N+34 or N+35) mod 2715648 or (N+39) mod 2715648 or (N+43 or N+44) mod 2715648 Or (N+47 or N+48) mod 2715648 or (N+52) mod 2715648 or (N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648	(N+13) mod 2715648 or (N+17 or N+18) mod 2715648 or (N+21 or N+22) mod 2715648 or (N+26) mod 2715648 Or (N+30 or N+31) mod 2715648 or (N+34 or N+35) mod 2715648 or (N+39) mod 2715648 or (N+43 or N+44) mod 2715648 Or (N+47 or N+48) mod 2715648 or (N+52) mod 2715648 or (N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648 Or N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648 Or (N+82 or N+83) mod 2715648 or (N+86 or N+87) mod 2715648 or (N+91) mod 2715648 or (N+95 or N+96) mod 2715648 Or (N+99 or N+100) mod 2715648 or (N+104) mod 2715648 or (N+108 or N+109) mod 2715648 or (N+112 or N+113) mod 2715648
0 1	(N+17 or N+18) mod 2715648	(N+21 or N+22) mod 2715648 or (N+26) mod 2715648	(N+30 or N+31) mod 2715648 or (N+34 or N+35) mod 2715648 or (N+39) mod 2715648 or (N+43 or N+44) mod 2715648	N+47 or N+48) mod 2715648 or (N+52) mod 2715648 or (N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648 Or (N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648	N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648 Or (N+82 or N+83) mod 2715648 or (N+86 or N+87) mod 2715648 or (N+91) mod 2715648 or (N+95 or N+96) mod 2715648 Or (N+99 or N+100) mod 2715648 or (N+104) mod 2715648 or (N+108 or N+109) mod 2715648 or (N+112 or N+113) mod 2715648	(N+117) mod 2715648 or (N+121 or N+122) mod 2715648 or (N+125 or N+126) mod 2715648 or (N+130) mod 2715648 Or (N+134 or N+135) mod 2715648 or (N+138 or N+139) mod 2715648 or (N+143) mod 2715648 or (N+147 or N+148) mod 2715648 Or (N+151 or N+152) mod 2715648 or (N+156) mod 2715648 or (N+160 or N+161) mod 2715648 or (N+164 or N+165) mode 2715648 Or (N+169) mod 2715648 or (N+173 or N+174) mod 2715648 or (N+177 or N+178) mod 2715648 or (N+182) mod 2715648 Or (N+186 or N+187) mod 2715648 or (N+190 or N+191) mod 2715648 or (N+195) mod 2715648 or (N+199 or N+200) mod 2715648 Or (N+203 or N+204) mod 2715648 or (N+208) mod 2715648 or (N+212 or N+213) mod 2715648 or (N+216 or N+217) mode 2715648
1 0	(N+21 or N+22) mod 2715648	(N+30 or N+31) mod 2715648 or (N+34 or N+35 ) mod 2715648	(N+47 or N+48) mod 2715648 or (N+52) mod 2715648 or (N+56 or N+57) mod 2715648 or (N+60 or N+61) mod 2715648	(N+82 or N+83) mod 2715648 or (N+86 or N+87) mod 2715648 or (N+91) mod 2715648 or (N+95 or N+96) mod 2715648 Or (N+99 or N+100) mod 2715648 or (N+104) mod 2715648 or (N+108 or N+109) mod 2715648 or (N+112 or N+113) mod 2715648	(N+117) mod 2715648 or (N+121 or N+122) mod 2715648 or (N+125 or N+126) mod 2715648 or (N+130) mod 2715648 Or (N+134 or N+135) mod 2715648 or (N+138 or N+139) mod 2715648 or (N+143) mod 2715648 or (N+147 or N+148) mod 2715648 Or (N+151 or N+152) mod 2715648 or (N+156) mod 2715648 or (N+160 or N+161) mod 2715648 or (N+164 or N+165) mode 2715648	Reserved
1 1	(N+26) mod 2715648	(N+39) mod 2715648 or (N+43 or N+44) mod 2715648	(N+65) mod 2715648 or (N+69 or N+70) mod 2715648 or (N+73 or N+74) mod 2715648 or (N+78) mod 2715648	(N+117) mod 2715648 or (N+121 or N+122) mod 2715648 or (N+125 or N+126) mod 2715648 or (N+130) mod 2715648 Or (N+134 or N+135) mod 2715648 or (N+138 or N+139) mod 2715648 or (N+143) mod 2715648 or (N+147 or N+148) mod 2715648	(N+169) mod 2715648 or (N+173 or N+174) mod 2715648 or (N+177 or N+178) mod 2715648 or (N+182) mod 2715648 Or (N+186 or N+187) mod 2715648 or (N+190 or N+191) mod 2715648 or (N+195) mod 2715648 or (N+199 or N+200) mod 2715648 Or (N+203 or N+204) mod 2715648 or (N+208) mod 2715648 or (N+212 or N+213) mod 2715648 or (N+216 or N+217) mode 2715648	Reserved
NOTE: Each RRBP value in Table 10.4.5.6 will assign only one valid uplink block given the downlink coverage class used, i.e. when the poll is received, and the uplink coverage class used. See 3GPP TS 45.002 [13] for the coverage class dependent channel mappings.

10.4.5.1 Special requirements in dual transfer mode

If the mobile station in dual transfer mode is using PDCH/H, where the exclusive allocation is required, special requirements apply when the mobile station receives a valid RRBP field in a downlink RLC/MAC block:

– The mobile station may disregard the actual value of a valid RRBP field. The mobile station shall respond to the polling request at the TDMA frame number specified by one of the allowed RRBP values, regardless of which value that was actually received.

– If the mobile station receives more than one RLC/MAC block with a valid RRBP field, the mobile station shall respond to each one of the polling requests with a separate PACKET CONTROL ACKNOWLEDGEMENT message or PACCH block to the network.

– When the mobile station responds with a PACKET CONTROL ACKNOWLEDGEMENT message to a valid RRBP field, the mobile station shall use the RLC/MAC control block format. That is regardless of the CONTROL_ACK_TYPE parameter received in the broadcast information of the cell or the TYPE_OF_ACK parameter received in a PACKET POLLING REQUEST message.

If the mobile station in dual transfer mode is not using PDCH/H, the normal requirements apply when the mobile station receives a valid RRBP field in a downlink RLC/MAC block.

10.4.6 Countdown Value (CV) field

The Countdown Value (CV) field is sent by the mobile station to allow the network to calculate the number of RLC data blocks remaining for the current uplink RLC entity. The CV value shall be calculated according to the process described in sub-clause 9.3.1. The CV field is 4 bits in length and is encoded as a binary number with range 0 to 15.

A mobile station with an uplink EC TBF is required to send the Countdown Value in an RLC uplink data block in order to inform the network that there are more remaining RLC data blocks for the uplink EC TBF than it has previously signalled to the network. When transmitting the last RLC data block, the CV equal to zero shall always be included. The Follow-On Indicator (FOI) shall indicate the presence of a valid CV field.

10.4.6a Follow-On Indicator field (FOI)

The Follow-On Indicator bit is sent from the mobile station to the network to indicate the presence of a valid Countdown Value field in the uplink RLC data block header during an uplink EC TBF.

Table 10.4.6a.1: Follow On Indicator field

bit 2	FOI
0	Countdown Value not present
1	Countdown Value present

10.4.7 Payload Type field

The Payload Type field shall indicate the type of data contained in remainder of the RLC/MAC block. The encoding of the Payload Type field is shown in table 10.4.7.1.

Table 10.4.7.1: Payload Type field

bit 8 7	Payload Type
0 0	RLC/MAC block contains an RLC data block
0 1	RLC/MAC block contains an RLC/MAC control block that does not include the optional octets of the RLC/MAC control header
10	In the downlink direction, the RLC/MAC block contains an RLC/MAC control block that includes the optional first octet of the RLC/MAC control header. In the uplink direction, this value is reserved.
1 1	Reserved. In this version of the protocol, the mobile station shall ignore all fields of the RLC/MAC block except for the USF field

In downlink RLC/MAC Control blocks encoded using MSC-0 the encoding of the Payload Type field is shown in table 10.4.7.2.

Table 10.4.7.2: Payload Type field, MCS-0

bit 8	Payload Type
0	RLC/MAC block contains an RLC/MAC control block that does not include the optional octets of the RLC/MAC control block message shown in figure 10.3.1.2.1
1	RLC/MAC block contains an RLC/MAC control block that includes at least the first optional octet of the RLC/MAC control block message shown in figure 10.3.1.2.1

In downlink RLC/MAC Control blocks on EC-PACCH/D, the encoding of the Payload Type field is shown in table 10.4.7.3.

Table 10.4.7.3: Payload Type field on EC-PACCH/D

bit 7	Payload Type
0	The RLC/MAC control block, including the normal MAC header, is coded according to figure 10.3.1.3.1
1	The RLC/MAC control block, including the extended MAC header, is coded according to figure 10.3.1.3.2

10.4.8 Final block indicator (FBI) bit

The Final block indicator (FBI) bit indicates that the downlink RLC data block is the last RLC data block of the downlink TBF.

Table 10.4.8.1: Final block indicator bit

bit 1	Final block indicator
0	Current block is not last RLC data block in TBF
1	Current block is last RLC data block in TBF

10.4.8a Coding and Puncturing Scheme indicator field (CPS)

In EGPRS and EC-GSM-IoT headers, the Coding and Puncturing Scheme indicator field is used to indicate the kind of channel coding and puncturing used for data blocks (see 3GPP TS 45.003).

10.4.8a.1 Header type 1

Table 10.4.8a.1.1: Coding and Puncturing Scheme indicator field for Header type 1 in EGPRS TBF, EC TBF or downlink EGPRS2 TBF

bits 54321	CPS
00000	(MCS-9/P1 ; MCS-9/P1) (see NOTE 2)
00001	(MCS-9/P1 ; MCS-9/P2) (see NOTE 2)
00010	(MCS-9/P1 ; MCS-9/P3) (see NOTE 2)
00100	(MCS-9/P2 ; MCS-9/P1) (see NOTE 2)
00101	(MCS-9/P2 ; MCS-9/P2) (see NOTE 2)
00110	(MCS-9/P2 ; MCS-9/P3) (see NOTE 2)
01000	(MCS-9/P3 ; MCS-9/P1) (see NOTE 2)
01001	(MCS-9/P3 ; MCS-9/P2) (see NOTE 2)
01010	(MCS-9/P3 ; MCS-9/P3) (see NOTE 2)
01011	(MCS-8/P1 ; MCS-8/P1)
01100	(MCS-8/P1 ; MCS-8/P2)
01101	(MCS-8/P1 ; MCS-8/P3)
01110	(MCS-8/P2 ; MCS-8/P1)
01111	(MCS-8/P2 ; MCS-8/P2)
10000	(MCS-8/P2 ; MCS-8/P3)
10001	(MCS-8/P3 ; MCS-8/P1)
10010	(MCS-8/P3 ; MCS-8/P2)
10011	(MCS-8/P3 ; MCS-8/P3)
10100	(MCS-7/P1 ; MCS-7/P1)
10101	(MCS-7/P1 ; MCS-7/P2)
10110	(MCS-7/P1 ; MCS-7/P3)
10111	(MCS-7/P2 ; MCS-7/P1)
11000	(MCS-7/P2 ; MCS-7/P2)
11001	(MCS-7/P2 ; MCS-7/P3)
11010	(MCS-7/P3 ; MCS-7/P1)
11011	(MCS-7/P3 ; MCS-7/P2)
11100	(MCS-7/P3 ; MCS-7/P3)
	All the other values are reserved for future use
NOTE 1: The bit numbering is relative to the field position. NOTE 2: MCS-9 shall only be used for an EGPRS TBF, for an EC TBF or for a downlink EGPRS2-B TBF.

10.4.8a.2 Header type 2

In EGPRS, EC-GSM-IoT and in EGPRS2-A uplink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.2.1.

Table 10.4.8a.2.1: Coding and Puncturing Scheme indicator field for Header type 2 in EGPRS TBF, EC TBF or uplink EGPRS2-A TBF

bits 321	(first block) CPS
000	MCS-6/P1
001	MCS-6/P2
010	MCS-6/P1 with 6 octets padding (see NOTE 2)
011	MCS-6/P2 with 6 octets padding (see NOTE 2)
100	MCS-5/P1
101	MCS-5/P2
110	MCS-6/P1 with 10 octets padding (see NOTE 3)
111	MCS-6/P2 with 10 octets padding (see NOTE 3)
NOTE 1: The bit numbering is relative to the field position. NOTE 2: MCS-6 with 6 octets padding shall only be used for an EGPRS TBF or, in case of an uplink EGPRS2-A TBF, for retransmission of blocks originally transmitted using EGPRS. NOTE 3: MSC-6 with 10 octets padding shall only be used for an uplink EGPRS2-A TBF or, in case of an uplink EGPRS TBF, for retransmission of blocks originally transmitted using EGPRS2-A.

In EGPRS2 downlink, if the Downlink EGPRS Level assigned (see Table 11.2.7.1 and Table 12.10f.1) is EGPRS2-A, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.2.2.

Table 10.4.8a.2.2: Coding and Puncturing Scheme indicator field for
Header type 2 in downlink EGPRS2-A TBF

bits 321	CPS
000	MCS-6/P1 (see NOTE 2)
001	MCS-6/P2 (see NOTE 2)
010	DAS-5/P1
011	DAS-5/P2
100	DAS-6/P1
101	DAS-6/P2
110	DAS-7/P1
111	DAS-7/P2
NOTE 1: The bit numbering is relative to the field position. NOTE 2: In EGPRS2-A downlink, MCS-6 shall be used only for retransmissions of blocks originally transmitted using EGPRS.

In EGPRS2 downlink, if the Downlink EGPRS Level assigned (see Table 11.2.7.1 and Table 12.10f.1) is EGPRS2-B, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.2.3.

Table 10.4.8a.2.3: Coding and Puncturing Scheme indicator field for
Header type 2 in downlink EGPRS2-B TBF

bits 321	CPS
000	MCS-6/P1
001	MCS-6/P2
010	DAS-5/P1
011	DAS-5/P2
100	DAS-6/P1
101	DAS-6/P2
	All the other values are reserved for future use
NOTE: The bit numbering is relative to the field position.

10.4.8a.3 Header type 3

Table 10.4.8a.3.1: Coding and Puncturing Scheme indicator field for Header type 3 (non EC TBF)

bits 4321	First block CPS
0000	MCS-4/P1
0001	MCS-4/P2
0010	MCS-4/P3
0011	MCS-3/P1
0100	MCS-3/P2
0101	MCS-3/P3
0110	MCS-3/P1 with padding
0111	MCS-3/P2 with padding
1000	MCS-3/P3 with padding
1001	MCS-2/P1
1010	MCS-2/P2
1011	MCS-1/P1
1100	MCS-1/P2
1101	MCS-2/P1 with padding (see NOTE 2)
1110	MCS-2/P2 with padding (see NOTE 2)
1111	MCS-0 (see NOTE 3)
NOTE 1: The bit numbering is relative to the field position. NOTE 2: MCS-2 with padding shall only be used for a downlink EGPRS2-A TBF or, in case of a downlink EGPRS TBF, for retransmissions of blocks originally transmitted using EGPRS2‑A. NOTE 3: MCS-0 shall only be used for a downlink TBF.

The number of padding octets for uplink is indicated by the SPB field (see sub clause 10.4.8b).

In EC-GSM-IoT, the CPS field for MCS-1-4 in Header type 3 indicates the kind of channel coding and puncturing used for data block as defined in Table 10.4.8a.3.2.

Table 10.4.8a.3.2: CPS field for Header type 3 in EC TBF.

bits 3 2 1	CPS
0 0 0	MCS-4/P1
0 0 1	MCS-4/P2
0 1 0	MCS-3/P1
0 1 1	MCS-3/P2
1 0 0	MCS-3/P1 with padding
1 0 1	MCS-3/P2 with padding
1 1 0	MCS-2/P1
1 1 1	MCS-1/P1

A mobile station with an EC TBF of uplink coverage class CC2, CC3 or CC4 and capable of supporting CC5 on the uplink shall indicate the capability(CC5) to BSS using the CPS bit code in header type 3. The BSS shall interpret the CPS field of header type 3 as Higher Coverage Class Coding Scheme(HCS) field, if the uplink coverage class of EC TBF is CC2, CC3 or CC4, as defined in Table 10.4.8a.3.2a.

Table 10.4.8a.3.2a: HCS field for Header type 3 in EC TBF for higher UL coverage classes than CC1.

bits 3 2 1	HCS
0 0 0	reserved
…	…
1 0 1	reserved
1 1 0	CC5 is supported
1 1 1	CC5 is not supported

10.4.8a.4 Header type 4

In downlink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.4.1.

Table 10.4.8a.4.1: Coding and Puncturing Scheme indicator field
for Header type 4 in downlink

bits 4321	CPS
0000	DAS-9/P1 ; DAS-9/P1
0001	DAS-9/P1 ; DAS-9/P2
0010	DAS-9/P1 ; DAS-9/P3
0011	DAS-9/P2 ; DAS-9/P1
0100	DAS-9/P2 ; DAS-9/P2
0101	DAS-9/P2 ; DAS-9/P3
0110	DAS-9/P3 ; DAS-9/P1
0111	DAS-9/P3 ; DAS-9/P2
1000	DAS-9/P3 ; DAS-9/P3
1001	DAS-8/P1 ; DAS-8/P1
1010	DAS-8/P1 ; DAS-8/P2
1011	DAS-8/P2 ; DAS-8/P1
1100	DAS-8/P2 ; DAS-8/P2
	All the other values are reserved for future use
NOTE: The bit numbering is relative to the field position.

In uplink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.4.2.

Table 10.4.8a.4.2: Coding and Puncturing Scheme indicator field
for Header type 4 in uplink

bits 54321	CPS
00000	(UAS-9/P1 ; UAS-9/P1)
00001	(UAS-9/P1 ; UAS-9/P2)
00010	(UAS-9/P1 ; UAS-9/P3)
00011	(UAS-9/P2 ; UAS-9/P1)
00100	(UAS-9/P2 ; UAS-9/P2)
00101	(UAS-9/P2 ; UAS-9/P3)
00110	(UAS-9/P3 ; UAS-9/P1)
00111	(UAS-9/P3 ; UAS-9/P2)
01000	(UAS-9/P3 ; UAS-9/P3)
01001	(UAS-8/P1 ; UAS-8/P1)
01010	(UAS-8/P1 ; UAS-8/P2)
01011	(UAS-8/P2 ; UAS-8/P1)
01100	(UAS-8/P2 ; UAS-8/P2)
01101	(UAS-7/P1 ; UAS-7/P1)
01110	(UAS-7/P1 ; UAS-7/P2)
01111	(UAS-7/P2 ; UAS-7/P1)
10000	(UAS-7/P2 ; UAS-7/P2)
	All the other values are reserved for future use
NOTE: The bit numbering is relative to the field position.

10.4.8a.5 Header type 5

In downlink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.5.1 for EGPRS2-A TBF and 10.4.8a.5.1a for EGPRS2-B TBF and table 10.4.8a.5.3.

Table 10.4.8a.5.1: Bit 6 of Coding and Puncturing Scheme indicator field for
Header type 5 in downlink for EGPRS2-A TBF

bit 6	CPS
0	DAS-11
1	DAS-12
NOTE: The bit numbering is relative to the field position.

Table 10.4.8a.5.1a: Bit 6 of Coding and Puncturing Scheme indicator field for
Header type 5 in downlink for EGPRS2-B TBF

bit 6	CPS
0	DAS-11
1	DAS-12 with padding
NOTE: The bit numbering is relative to the field position.

For DAS-12 with padding, the first 8 data octets of the RLC data block are padded with zeros.

In uplink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.5.2 and table 10.4.8a.5.3.

Table 10.4.8a.5.2: Bit 6 of Coding and Puncturing Scheme indicator field for
Header type 5 in uplink

bit 6	CPS
0	UAS-10
1	UAS-11
NOTE: The bit numbering is relative to the field position.

Table 10.4.8a.5.3: Bits 1 to 5 of Coding and Puncturing Scheme indicator field for
Header type 5 common for downlink and uplink

bits 54321	CPS
00000	(P1 ; P1 ; P1)
00001	(P1 ; P1 ; P2)
00010	(P1 ; P1 ; P3)
00011	(P1 ; P2 ; P1)
00100	(P1 ; P2 ; P2)
00101	(P1 ; P2 ; P3)
00110	(P1 ; P3 ; P1)
00111	(P1 ; P3 ; P2)
01000	(P1 ; P3 ; P3)
01001	(P2 ; P1 ; P1)
01010	(P2 ; P1 ; P2)
01011	(P2 ; P1 ; P3)
01100	(P2 ; P2 ; P1)
01101	(P2 ; P2 ; P2)
01110	(P2 ; P2 ; P3)
01111	(P2 ; P3 ; P1)
10000	(P2 ; P3 ; P2)
10001	(P2 ; P3 ; P3)
10010	(P3 ; P1 ; P1)
10011	(P3 ; P1 ; P2)
10100	(P3 ; P1 ; P3)
10101	(P3 ; P2 ; P1)
10110	(P3 ; P2 ; P2)
10111	(P3 ; P2 ; P3)
11000	(P3 ; P3 ; P1)
11001	(P3 ; P3 ; P2)
11010	(P3 ; P3 ; P3)
	All the other values are reserved for future use
NOTE: The bit numbering is relative to the field position.

10.4.8a.6 Header type 6

In downlink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.6.1.

Table 10.4.8a.6.1: Coding and Puncturing Scheme indicator field for
Header type 6 in downlink

bits 321	CPS
000	DBS-5 P1
001	DBS-5 P2
010	DBS-6 P1
011	DBS-6 P2
	All the other values are reserved for future use
NOTE: The bit numbering is relative to the field position.

In uplink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.6.2.

Table 10.4.8a.6.2: Coding and Puncturing Scheme indicator field for
Header type 6 in uplink

bits 321	CPS
000	UBS-5 P1
001	UBS-5 P2
010	UBS-6 P1
011	UBS-6 P2
100	UBS-6 P1 with padding
101	UBS-6 P2 with padding
	All the other values are reserved for future use
NOTE: The bit numbering is relative to the field position.

10.4.8a.7 Header type 7

In downlink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.7.1 and table 10.4.8a.7.3.

Table 10.4.8a.7.1: Bit 4 of Coding and Puncturing Scheme indicator field for
Header type 7 in downlink

bit 4	CPS
0	DBS-7
1	DBS-8
NOTE: The bit numbering is relative to the field position.

In uplink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.7.2 and table 10.4.8a.7.3.

Table 10.4.8a.7.2: Bit 4 of Coding and Puncturing Scheme indicator field for
Header type 7 in downlink

bit 4	CPS
0	UBS-7
1	UBS-8
NOTE: The bit numbering is relative to the field position.

Table 10.4.8a.7.3: Bit 1 and 3 of Coding and Puncturing Scheme indicator field for
Header type 7 common for downlink and uplink

bits 321	CPS
000	(P1 ; P1)
001	(P1 ; P2)
010	(P2 ; P1)
011	(P2 ; P2)
100	(P1 ; P1) with padding
101	(P1 ; P2) with padding
110	(P2 ; P1) with padding
111	(P2 ; P2) with padding
NOTE: The bit numbering is relative to the field position.

10.4.8a.8 Header type 8

The Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.8.1 for uplink and table 10.4.8a.8.2 for downlink. DBS-9 and DBS-10, and also UBS-9 and UBS-10 use different modulations hence the CPS field need not distinguish between these coding schemes.

Table 10.4.8a.8.1: Coding and Puncturing Scheme indicator field for
Header type 8 in uplink

bits 654321	CPS
000000	(P1 ; P1 ; P1)
000001	(P1 ; P1 ; P2)
000010	(P1 ; P1 ; P3)
000100	(P1 ; P2 ; P1)
000101	(P1 ; P2 ; P2)
000110	(P1 ; P2 ; P3)
001000	(P1 ; P3 ; P1)
001001	(P1 ; P3 ; P2)
001010	(P1 ; P3 ; P3)
001011	(P2 ; P1 ; P1)
001100	(P2 ; P1 ; P2)
001101	(P2 ; P1 ; P3)
001110	(P2 ; P2 ; P1)
001111	(P2 ; P2 ; P2)
010000	(P2 ; P2 ; P3)
010001	(P2 ; P3 ; P1)
010010	(P2 ; P3 ; P2)
010011	(P2 ; P3 ; P3)
010100	(P3 ; P1 ; P1)
010101	(P3 ; P1 ; P2)
010110	(P3 ; P1 ; P3)
010111	(P3 ; P2 ; P1)
011000	(P3 ; P2 ; P2)
011001	(P3 ; P2 ; P3)
011010	(P3 ; P3 ; P1)
011011	(P3 ; P3 ; P2)
011100	(P3 ; P3 ; P3)
011101	(P1 ; P1 ; P1) with padding
011110	(P1 ; P1 ; P2) with padding
011111	(P1 ; P1 ; P3) with padding
100000	(P1 ; P2 ; P1) with padding
100001	(P1 ; P2 ; P2) with padding
100010	(P1 ; P2 ; P3) with padding
100011	(P1 ; P3 ; P1) with padding
100100	(P1 ; P3 ; P2) with padding
100101	(P1 ; P3 ; P3) with padding
100110	(P2 ; P1 ; P1) with padding
100111	(P2 ; P1 ; P2) with padding
101000	(P2 ; P1 ; P3) with padding
101001	(P2 ; P2 ; P1) with padding
101010	(P2 ; P2 ; P2) with padding
101011	(P2 ; P2 ; P3) with padding
101100	(P2 ; P3 ; P1) with padding
101101	(P2 ; P3 ; P2) with padding
101110	(P2 ; P3 ; P3) with padding
101111	(P3 ; P1 ; P1) with padding
110000	(P3 ; P1 ; P2) with padding
110001	(P3 ; P1 ; P3) with padding
110010	(P3 ; P2 ; P1) with padding
110011	(P3 ; P2 ; P2) with padding
110100	(P3 ; P2 ; P3) with padding
110101	(P3 ; P3 ; P1) with padding
110110	(P3 ; P3 ; P2) with padding
110111	(P3 ; P3 ; P3) with padding
	All the other values are reserved for future use
NOTE: The bit numbering is relative to the field position.

Table 10.4.8a.8.2: Coding and Puncturing Scheme indicator field for
Header type 8 in downlink

bits 654321	CPS
000000	(P1 ; P1 ; P1)
000001	(P1 ; P1 ; P2)
000010	(P1 ; P1 ; P3)
000100	(P1 ; P2 ; P1)
000101	(P1 ; P2 ; P2)
000110	(P1 ; P2 ; P3)
001000	(P1 ; P3 ; P1)
001001	(P1 ; P3 ; P2)
001010	(P1 ; P3 ; P3)
001011	(P2 ; P1 ; P1)
001100	(P2 ; P1 ; P2)
001101	(P2 ; P1 ; P3)
001110	(P2 ; P2 ; P1)
001111	(P2 ; P2 ; P2)
010000	(P2 ; P2 ; P3)
010001	(P2 ; P3 ; P1)
010010	(P2 ; P3 ; P2)
010011	(P2 ; P3 ; P3)
010100	(P3 ; P1 ; P1)
010101	(P3 ; P1 ; P2)
010110	(P3 ; P1 ; P3)
010111	(P3 ; P2 ; P1)
011000	(P3 ; P2 ; P2)
011001	(P3 ; P2 ; P3)
011010	(P3 ; P3 ; P1)
011011	(P3 ; P3 ; P2)
011100	(P3 ; P3 ; P3)
	All the other values are reserved for future use
NOTE: The bit numbering is relative to the field position.

10.4.8a.9 Header type 9

In downlink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.9.1 and table 10.4.8a.9.3.

Table 10.4.8a.9.1: Bit 8 of Coding and Puncturing Scheme indicator field for
Header type 9 in downlink

bit 8	CPS
0	DBS-11
1	DBS-12
NOTE: The bit numbering is relative to the field position.

In uplink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.9.2 and table 10.4.8a.9.3.

Table 10.4.8a.9.2: Bit 8 of Coding and Puncturing Scheme indicator field for
Header type 9 in uplink

bit 8	CPS
0	UBS-11
1	UBS-12
NOTE: The bit numbering is relative to the field position.

Table 10.4.8a.9.3: Bits 1 to 7 of Coding and Puncturing Scheme indicator field for
Header type 9 common for downlink and uplink

bits 7654321	CPS
0000000	(P1 ; P1 ; P1; P1)
0000001	(P1 ; P1 ; P1; P2)
0000010	(P1 ; P1 ; P1; P3)
0000011	(P1 ; P1 ; P2; P1)
0000100	(P1 ; P1 ; P2; P2)
0000101	(P1 ; P1 ; P2; P3)
0000110	(P1 ; P1 ; P3; P1)
0000111	(P1 ; P1 ; P3; P2)
0001000	(P1 ; P1 ; P3; P3)
0001001	(P1 ; P2 ; P1; P1)
0001010	(P1 ; P2 ; P1; P2)
0001011	(P1 ; P2 ; P1; P3)
0001100	(P1 ; P2 ; P2; P1)
0001101	(P1 ; P2 ; P2; P2)
0001110	(P1 ; P2 ; P2; P3)
0001111	(P1 ; P2 ; P3; P1)
0010000	(P1 ; P2 ; P3; P2)
0010001	(P1 ; P2 ; P3; P3)
0010010	(P1 ; P3 ; P1; P1)
0010011	(P1 ; P3 ; P1; P2)
0010100	(P1 ; P3 ; P1; P3)
0010101	(P1 ; P3 ; P2; P1)
0010110	(P1 ; P3 ; P2; P2)
0010111	(P1 ; P3 ; P2; P3)
0011000	(P1 ; P3 ; P3; P1)
0011001	(P1 ; P3 ; P3; P2)
0011010	(P1 ; P3 ; P3; P3)
0011011	(P2 ; P1 ; P1; P1)
0011100	(P2 ; P1 ; P1; P2)
0011101	(P2 ; P1 ; P1; P3)
0011110	(P2 ; P1 ; P2; P1)
0011111	(P2 ; P1 ; P2; P2)
0100000	(P2 ; P1 ; P2; P3)
0100001	(P2 ; P1 ; P3; P1)
0100010	(P2 ; P1 ; P3; P2)
0100011	(P2 ; P1 ; P3; P3)
0100100	(P2 ; P2 ; P1; P1)
0100101	(P2 ; P2 ; P1; P2)
0100110	(P2 ; P2 ; P1; P3)
0100111	(P2 ; P2 ; P2; P1)
0101000	(P2 ; P2 ; P2; P2)
0101001	(P2 ; P2 ; P2; P3)
0101010	(P2 ; P2 ; P3; P1)
0101011	(P2 ; P2 ; P3; P2)
0101100	(P2 ; P2 ; P3; P3)
0101101	(P2 ; P3 ; P1; P1)
0101110	(P2 ; P3 ; P1; P2)
0101111	(P2 ; P3 ; P1; P3)
0110000	(P2 ; P3 ; P2; P1)
0110001	(P2 ; P3 ; P2; P2)
0110010	(P2 ; P3 ; P2; P3)
0110011	(P2 ; P3 ; P3; P1)
0110100	(P2 ; P3 ; P3; P2)
0110101	(P2 ; P3 ; P3; P3)
0110110	(P3 ; P1 ; P1; P1)
0110111	(P3 ; P1 ; P1; P2)
0111000	(P3 ; P1 ; P1; P3)
0111001	(P3 ; P1 ; P2; P1)
0111010	(P3 ; P1 ; P2; P2)
0111011	(P3 ; P1 ; P2; P3)
0111100	(P3 ; P1 ; P3; P1)
0111101	(P3 ; P1 ; P3; P2)
0111110	(P3 ; P1 ; P3; P3)
0111111	(P3 ; P2 ; P1; P1)
1000000	(P3 ; P2 ; P1; P2)
1000001	(P3 ; P2 ; P1; P3)
1000010	(P3 ; P2 ; P2; P1)
1000011	(P3 ; P2 ; P2; P2)
1000100	(P3 ; P2 ; P2; P3)
1000101	(P3 ; P2 ; P3; P1)
1000110	(P3 ; P2 ; P3; P2)
1000111	(P3 ; P2 ; P3; P3)
1001000	(P3 ; P3 ; P1; P1)
1001001	(P3 ; P3 ; P1; P2)
1001010	(P3 ; P3 ; P1; P3)
1001011	(P3 ; P3 ; P2; P1)
1001100	(P3 ; P3 ; P2; P2)
1001101	(P3 ; P3 ; P2; P3)
1001110	(P3 ; P3 ; P3; P1)
1001111	(P3 ; P3 ; P3; P2)
1010000	(P3 ; P3 ; P3; P3)
	All other values are reserved for future use

10.4.8a.10 Header type 10

In downlink, the Coding and Puncturing Scheme indicator field indicates the kind of channel coding and puncturing used for data block as defined in table 10.4.8a.10.1 for EGPRS2-A TBF and in table 10.4.8a.10.2 for EGPRS2-B TBF.

Table 10.4.8a.10.1: Coding and Puncturing Scheme indicator field for
Header type 10 in downlink EGPRS2-A TBF

bits 21	CPS
00	DAS-10/P1 ; DAS-10/P1
01	DAS-10/P1 ; DAS-10/P2
10	DAS-10/P2 ; DAS-10/P1
11	DAS-10/P2 ; DAS-10/P2
NOTE: The bit numbering is relative to the field position.

Table 10.4.8a.10.2: Coding and Puncturing Scheme indicator field for
Header type 10 in downlink EGPRS2-B TBF

bits 21	CPS
00	DAS-10/P1 ; DAS-10/P1 both with padding
01	DAS-10/P1 ; DAS-10/P2 both with padding
10	DAS-10/P2 ; DAS-10/P1 both with padding
11	DAS-10/P2 ; DAS-10/P2 both with padding
NOTE: The bit numbering is relative to the field position.

For DAS-10 with padding, the first 8 data octets of the RLC data block are padded with zeros.

10.4.8b Split Block indicator field (SPB)

In EGPRS uplink, EC-GSM-IoT uplink and EGPRS2 uplink, the Split Block indicator is only used in header type 3 to indicate if some user data is retransmitted using 2 block resegmentation (see clause 9).

Table 10.4.8b.1: Split Block indicator field (uplink)

bits 2 1	SPB
0 0	No retransmission
0 1	Retransmission – first part of block with 10 octet padding
1 0	Retransmission – first part of block with no padding or 6 octet padding
1 1	Retransmission – second part of block
NOTE: The bit numbering is relative to the field position.

In case of EGPRS, 10 octet padding shall be used only for retransmissions of blocks originally transmitted using EGPRS2-A. In case of EGPRS2-A, 6 octet padding shall be used only for retransmissions of blocks originally transmitted using EGPRS.

In EGPRS downlink, EC-GSM-IoT downlink and EGPRS2 downlink, the Split Block indicator is only used in header type 3 to indicate if some user data is retransmitted using 2 or 3 block resegmentation (see clause 9).

Table 10.4.8b.2: Split Block indicator field (downlink)

bits 2 1	SPB
0 0	No retransmission
0 1	Retransmission – third part of block (Note 2)
1 0	Retransmission – first part of block
1 1	Retransmission – second part of block
NOTE 1: The bit numbering is relative to the field position. NOTE 2: In EGPRS downlink this code point is only used when retransmiting blocks at EGPRS level change from EGPRS2-A to EGPRS.

10.4.9 TLLI Indicator (TI) bit

The TLLI Indicator (TI) bit indicates the presence of an optional TLLI/G-RNTI field within the RLC data block.

Table 10.4.9.1: TLLI Indicator (TI) bit

bit 1	TLLI indicator (TI) bit
0	TLLI/G-RNTI field is not present
1	TLLI/G-RNTI field is present

10.4.9a Address Control (AC) bit

The Address Control (AC) bit is used to indicate the presence of the optional TFI/D octet in the header of downlink RLC/MAC control blocks.

Table 10.4.9a.1: Address Control (AC) bit

bit 1	Address Control (AC) bit
0	TFI/D octet is not present
1	TFI/D octet is present

10.4.9b Final Segment (FS) bit

The Final Segment (FS) bit indicates that the downlink RLC/MAC control block contains the final segment of an RLC/MAC control message except when it is sent using extended RLC/MAC control message segmentation. In case of extended RLC/MAC control message segmentation, the final segment of an RLC/MAC control message is indicated with the FSe bit as defined in sub-clause 10.4.9e while the FS bit is set to ‘0’ (see sub-clauses 9.1.12a and 10.4.12b).

Table 10.4.9b.1: Final Segment (FS) bit

bit 1	Final Segment (FS) bit
0	Current block does not contain the final segment of an RLC/MAC control message
1	Current block contains the final segment of an RLC/MAC control message
NOTE: The bit numbering is relative to the field position.

10.4.9c Radio Transaction Identifier (RTI) field

The Radio Transaction Identifier (RTI) field is used to group the downlink RLC/MAC control blocks that make up an RLC/MAC control message and identifies the segmented control message sequence with which the downlink RLC/MAC control block is associated. The RTI field is five bits in length with range 0 to 31.

10.4.9d Direction (D) bit

The Direction (D) bit indicates the direction of the TBF identified by the TFI field in the downlink RLC/MAC control block header.

Table 10.4.9d.1: Direction (D) bit

bit 1	Direction (D) bit
0	TFI field identifies an uplink TBF
1	TFI field identifies a downlink TBF

10.4.9e Final Segment extension (FSe) bit

The Final Segment extension (FSe) bit indicates that the downlink RLC/MAC control block contains the final segment of an RLC/MAC control message segmented using extended RLC/MAC control message segmentation (see sub-clauses 9.1.12a and 10.4.12b). The FSe bit is only present from the second RLC/MAC control block onwards.

Table 10.4.9e.1: Final Segment extension (FSe) bit

bit 5	Final Segment extension (FSe) bit
0	Current block does not contain the final segment of an RLC/MAC control message
1	Current block contains the final segment of an RLC/MAC control message

10.4.9f Reduced TLLI (rTLLI)

A mobile station in EC operation that has been indicated to use the enhanced access burst procedure shall only include the TLLI in the first RLC data block of the uplink EC TBF and the rTLLI in the RLC/MAC headers of the remaining RLC data blocks until the contention resolution is completed (see sub-clause 7a.2.1.2).

10.4.9g Reduced TLLI Indicator (RI)

The RI bit is used to indicate whether the rTLLI field is valid or not valid.

Table 10.4.9g.1: Reduced TLLI Indicator (RI)

bit

rTLLI field is not valid

rTLLI field is valid

10.4.10 Temporary Flow Identity (TFI) field

In the header of an RLC/MAC block for data transfer, the TFI identifies the Temporary Block Flow (TBF) to which the RLC data block belongs. For the downlink and the uplink TFI the TFI field is 5 bits in length and are encoded as a binary number with range 0 to 31. When eTFI is assigned it is 3 bits in length and is encoded as a binary number with range 0 to 7. TFI and eTFI (if assigned) together identify the downlink Temporary Block Flow (TBF). In downlink RLC/MAC control blocks, the TFI identifies the Temporary Block Flow (TBF) to which the RLC/MAC control message contained in the downlink RLC/MAC control block relates. If present, this field indicates the mobile station to which the control message is addressed; all other mobile stations shall analyse the distribution contents, depending on their protocol state, as specified in clauses 5 and 7 of the present document, except if the downlink RLC/MAC control block is sent using an eTFI in which case only the mobile station to which the control message is addressed shall analyse the content. If this field is present and the contents of the control message also contain a TFI addressing the mobile station, the mobile station shall ignore the TFI in the control message contents. If this field is not present all mobile stations shall interpret the contents of the control message, except if the downlink RLC/MAC control block is sent using an eTFI in which case only the mobile stations that support that eTFI shall interpret the contents of the control message.

If a valid TFI field or valid TFI-eTFI fields (see sub-clause 10.3a.5) are included in a PAN field, they identify the Temporary Block Flow (TBF) being acknowledged.

10.4.10a Power Reduction (PR) field

The Power Reduction (PR) field indicates the power level reduction of the current RLC block.

The coding of Power Reduction (PR) field is shown in Table 10.4.10a.1. There is one value of the PR field which indicates that the field shall be ignored by the MS.

If downlink power control is not used, the MS shall ignore the PR field.

If downlink power control is used and the PR field is not included in a downlink RLC/MAC control block, the MS shall act as if the block contained a usable PR field with value ‘0 0’.

Table 10.4.10a.1: Power Reduction (PR) field

bit 6 5	Power Reduction
0 0	0 dB (included) to 3 dB (excluded) less than BCCH level – P0
0 1	3 dB (included) to 7 dB (excluded) less than BCCH level – P0
1 0	7 dB (included) to 10 dB (included) less than BCCH level – P0
1 1	Not usable

The Power Reduction (PR) field in a downlink EC-GSM-IoT control block indicates the power level reduction of the current RLC/MAC control block. When PRe is not included, the coding of Power Reduction (PR) field for a downlink EC-GSM-IoT control block is shown in Table 10.4.10a.2.

Table 10.4.10a.2: Power Reduction (PR) field for EC-GSM-IoT control blocks

bit 8	Power Reduction
0	0 dB (included) to 3 dB (excluded) less than BCCH level – P0
1	3 dB (included) to 7 dB (excluded) less than BCCH level – P0

10.4.10b Power Reduction extension (PRe) field

The Power Reduction extension (PRe) field indicates the extended power level reduction of the current RLC/MAC control block. The PRe field is only included if the Payload Type, see table 10.4.7.3, is set to 1.

When included the PRe field, together with the PR field, gives the coding of the power reduction for a downlink EC-GSM-IoT control block as shown in Table 10.4.10b.1.

Table 10.4.10b.1: PR bit, PRe bit

PR	PRe	Power Reduction
0	0	0 dB (included) to 3 dB (excluded) less than BCCH level – P0
1	0	3 dB (included) to 7 dB (excluded) less than BCCH level – P0
0	1	7 dB (included) to 10 dB (included) less than BCCH level – P0
1	1	Reserved

10.4.11 Extension (E) Bit

The Extension (E) bit is used to indicate the presence of an optional octet in the RLC data block header.

Table 10.4.11.1: Extension (E) bit

bit 1	E bit
0	Extension octet follows immediately
1	No extension octet follows

In A/Gb mode, extension (E) bit after the PFI field is used for extensions of the protocol by allowing optional octets in the RLC data block header. However, when extensions of this protocol are developed, networks will treat all unknown optional octets as spare until the E bit of 1.

10.4.12 Block Sequence Number (BSN) field

The Block Sequence Number (BSN) field carries the sequence absolute Block Sequence Number (BSN’) modulo Sequence Number Space (SNS) (32 in EC-GSM-IoT, 128 in GPRS, 2 048 in EGPRS and 8192 in a DLMC configuration) of each RLC data block within the TBF.

In EC-GSM-IoT, the BSN is 5 bits in length and is encoded as a binary number with range 0 to 31.

In GPRS, the BSN is 7 bits in length and is encoded as a binary number with range 0 to 127.

In EGPRS, or in a DLMC configuration where a SNS of 2048 is used (see sub-clause 5.13), the BSN is 11 bits in length and is encoded as a binary number with range 0 to 2 047.

In a DLMC configuration where a SNS of 8192 is used (see sub-clause 5.13), the BSN is 13 bits in length and is encoded as a binary number with range 0 to 8191.

In case two to four RLC data blocks are sent within a RLC/MAC block, BSN2 to BSN4 are relative to BSN1, provided the difference between the second to fourth block number and the first block modulo SNS is less than Window Size (WS).

For example,

Second block number = [BSN1 + BSN2] modulo SNS

(e.g. SNS = 2 048, WS = 512, Block A block number = 10 and Block B block number= 2 000 then:

[Block A – Block B] modulo SNS = 58 < 512;

[Block B – Block A] modulo SNS = 1 990 > 512;

Then: Block #1 = Block B and Block #2 = Block A, BSN1 = 2 000 and BSN2 = 58).

In a DLMC configuration there are restrictions regarding the selection of RLC data blocks for inclusion within a given RLC/MAC block:

– In the RLC/MAC header for MCS-7, MCS-8 and MCS-9 13 bits for BSN1 and 11 bits for BSN2 are defined. For these MCSs the difference between the two RLC data blocks (Block A and Block B) shall be less than 2048.

– i.e. [Block A – Block B] modulo SNS < 2048 or [Block B – Block A] modulo SNS < 2048

– In the RLC/MAC header for DAS-11 and DAS-12 13 bits for BSN1, 12 bits for BSN2 and 11 bits for BSN3 are defined. For these MCSs the difference between two of the RLC data blocks (i.e. two out of Block A, B or C) shall be less than 2048.

– i.e. [Block X – Block Y] modulo SNS < 2048 or [Block Y – Block X] modulo SNS < 2048 where X is any one of Block A, B or C, and Y is any of the two remaining blocks.

For example,

SNS = 8192, WS = 4096:

BSN1=2000 (Block B block number=2000)

BSN2=58 (Block A block number=2058)

– [Block A – Block B] modulo 8192 = 58 < 4096

– [Block B – Block A] modulo 8192 = 8133 > 4096

then Block C block number shall fulfill [Block C – Block B] modulo SNS < 2048.

For example Block C block number = 4003, and BSN3=2003

– [Block C – Block B] modulo 8192 = 2003 < 2048

10.4.12a Reduced Block Sequence Number (RBSN) bit

The Reduced Block Sequence Number (RBSN) bit carries the sequence number of the downlink RLC/MAC control blocks. The RBSN bit is encoded as a binary number with range 0 to 1.

10.4.12b Reduced Block Sequence Number extension (RBSNe) field

The Reduced Block Sequence Number extension (RBSNe) field together with the RBSN bit indicate the sequence number of the downlink RLC/MAC control blocks of an RLC/MAC control message segmented using extended RLC/MAC control message segmentation. The RBSNe field is encoded as a binary number with range 0 to 7. Along with the FS bit and the FSe bit, they allow for extended RLC/MAC control message segmentation as shown in table 10.4.12b.1 (see sub-clause 9.1.12a).

Table 10.4.12b.1: RBSN bit, FS bit, RBSNe field, FSe bit

RBSN	FS	RBSNe	FSe
0	0	N/A	N/A	1^st RLC/MAC control block
1	0	0 0 0	0	2^nd RLC/MAC control block
1	0	0 0 1	0 / 1	3^rd / last RLC/MAC control block
1	0	0 1 0	0 / 1	4^th / last RLC/MAC control block
1	0	0 1 1	0 / 1	5^th/last RLC/MAC control block
1	0	1 0 0	0 / 1	6^th/last RLC/MAC control block
1	0	1 0 1	0 / 1	7^th/last RLC/MAC control block
1	0	1 1 0	0 / 1	8^th/last RLC/MAC control block
1	0	1 1 1	1	9^th and last RLC/MAC control block

10.4.13 More (M) bit

In GPRS TBF mode, the M bit, along with the E bit and the Length Indicator (LI), are used to delimit LLC PDUs within a TBF. When the M bit is present it indicates whether or not another LLC PDU follows the current one within the RLC data block. The function of the M and E bits when they occur in the same octet is defined in table 10.4.13.1.

In EGPRS TBF mode the M bit is not used, instead a special combination of the LI field is used to indicate presence of following LLC PDUs.

Table 10.4.13.1: M bit and E bit

bit M E
0 0	In Iu mode, the RLC data block belongs to the signalling radio bearer identified by SRBid. In A/Gb mode, if received by the mobile station it shall ignore all fields of the RLC/MAC block except for the fields of the MAC header
0 1	no LLC data after the current LLC PDU, no more extension octets
1 0	a new LLC PDU starts after the current LLC PDU and there is another extension octet, which delimits the new LLC PDU
1 1	a new LLC PDU starts after the current LLC PDU and continues until the end of the RLC information field, no more extension octets

10.4.14 Length Indicator (LI) field in GPRS TBF mode and DCCH TBF mode (Iu mode)

The Length Indicator is used to delimit Upper Layer PDUs within the RLC data block. Additionally for Iu mode, a Length Indicator of value 63 may be used to indicate the presence of filler information within the RLC data block. If the first length indicator in the RLC data block is set to 63, then the entire RLC data block contains filler information.

A Length Indicator of value 62 is used by a mobile station supporting network sharing to indicate the presence of a Selected PLMN Index field (see sub-clause 10.4.27) in the octet immediately following this Length Indicator. In this case, it shall always be the first Length Indicator in the RLC data block.

A Length Indicator of value 61 is used by a mobile station supporting MS assisted Dedicated Core Network selection and indicates the presence of a DCN-ID value (see sub-clause 10.4.30) in the two octets immediately following this Length Indicator.

The first Length Indicator (respectively, second length Indicator, if the first is of value 62, as described above) shall indicate the number of octets of the RLC data field belonging to the first Upper Layer PDU, the second Length Indicator (respectively third Length Indicator, if the first is of value 62, as described above) shall indicate the number of octets of the RLC data field belonging to the second Upper Layer PDU, etc. Only the last segment of any Upper Layer PDU of a TBF (either this segment carries the entire Upper Layer PDU or not) shall be identified with a Length Indicator within the corresponding RLC data block.

A singular case occurs when the end of the Upper Layer PDU would fit within the RLC data block but the addition of the corresponding Length Indicator octet (to indicate the Upper Layer PDU boundary) causes the Upper Layer PDU to extend into the next RLC data block. In this case, this additional LI field shall take the value 0 whatever is the length of the last but one Upper Layer PDU segment. The inclusion of a Length Indicator that indicates the presence of a Selected PLMN Index field will never correspond to an Upper Layer PDU and therefore will never result in this singular case.

The final RLC data block of a TBF shall have a Length Indicator field corresponding to the final Upper Layer PDU unless this PDU fills the RLC data block precisely without the LI field being added (i.e. the singular case mentioned above never applies in this situation).

The LI field is 6 bits in length and shall be encoded as a binary number with range 1 to 19, 29, 35 or 49, according to the coding scheme in use, i.e. CS-1, CS-2, CS-3 or CS-4 respectively. The value 0 shall indicate that no Upper Layer PDU boundary exists. In this case the M bit shall be set to’ 0′ and the E bit shall be set to ‘1’ on the transmitting side, while on the receiving side the M bit shall be ignored and the E bit shall be interpreted as having the value ‘1’. The value 61 or 62 may also be used as described above. In Iu mode, a value of 63 shall indicate the presence of filler information within the RLC data block. All other values are reserved, and in this version of the protocol, the mobile station shall ignore all fields of the RLC data block except for the USF field.

10.4.14a Length Indicator (LI) field in EGPRS TBF mode, EC TBF mode and TCH TBF mode (Iu mode)

The Length indicator is used to delimit Upper Layer PDUs within the RLC data block. Additionally for Iu mode, a Length Indicator of value 127 may be used to indicate the presence of filler information within the RLC data block. If the first length indicator in the RLC data block is set to 127, then the entire RLC data block contains filler information.

The first Length Indicator (respectively, second length Indicator, if the first is of value 123, as described below) shall indicate the number of octets of the RLC data field belonging to the first Upper Layer PDU, the second Length Indicator (respectively third Length Indicator, if the first is of value 123, as described below) shall indicate the number of octets of the RLC data field belonging to the second Upper Layer PDU, etc. Only the last segment of any Upper Layer PDU, including those with only one segment, shall be identified with a Length Indicator. The length indicator shall be placed in the RLC data block corresponding to the last segment of the Upper Layer PDU, unless the Upper Layer PDU without the corresponding LI field fills the RLC data block precisely. In this singular case, the Length Indicator shall be placed as the first Length Indicator in the next in sequence RLC data block and take the value 0. The inclusion of a Length Indicator that indicates the presence of a Selected PLMN Index field (see sub-clause 10.4.27) will never correspond to an Upper Layer PDU and therefore will never result in this singular case.

If the Upper Layer PDU does not fill the current RLC data block, a Length Indicator with value 127 (111 1111) shall be included as the last Length Indicator of the current RLC data block, indicating that there is no following Upper Layer PDU in this RLC data block. If the Upper Layer PDU does not fill the RLC data block and there is only one octet left, then the Length Indicator corresponding to the Upper Layer PDU is the last Length Indicator field that shall be included in the RLC data block.

During RLC non-persistent mode of operation, or, during RLC unacknowledged mode of operation if the network has commanded the usage of "Indication of Upper Layer PDU Start for RLC UM" for the TBF, and if the current RLC data block starts with the first segment of a new Upper Layer PDU, then a Length Indicator taking the value 126 shall be placed as the first Length Indicator in the RLC data block unless a Length Indicator with the value 0, signalling that the last segment of the previous Upper Layer PDU precisely fills the previous in sequence RLC data block, shall be included.

If the network and the mobile station support dynamic timeslot reduction (see sub-clause 8.1.8), a Length Indicator with value 125 indicates the presence of dynamic timeslot reduction control information which shall be included after the last Upper Layer PDU.

If EMSR is enabled, the transmission of an Upper Layer PDU can be suspended to transmit a higher priority Upper Layer PDU by including an LI with a value of 124 as the first LI field within the next transmitted RLC data block where an octet containing the TFI value associated with the higher priority Upper Layer PDU immediately follows the LI field. The transmission of the suspended Upper Layer PDU is resumed by including an LI with a value of 124 followed by an octet containing the TFI (and eTFI if assigned, see sub-clause 5.13) associated with the Upper Layer PDU whose transmission is resumed after the LI associated with the last segment of the higher priority Upper Layer PDU whose transmission is completed. The transition from the last segment of an Upper Layer PDU to the first segment of a new Upper Layer PDU associated with a different PFC can also occur within an RLC data block (i.e. no suspend occurs) in which case the transition is indicated by including an LI with a value of 124 followed by an octet containing the TFI (and eTFI if assigned) associated with the new Upper Layer PDU after the LI associated with the last segment of the Upper Layer PDU whose transmission is completed. In addition:

– If the last segment of the Upper Layer PDU without the corresponding LI field fills the RLC data block precisely and the next in sequence RLC data block is in the same radio block, then a Length Indicator with the value 0 shall be placed as the first Length Indicator in the next in sequence RLC data block.

– If the last segment of the Upper Layer PDU without the corresponding LI field fills the RLC data block precisely and the next in sequence RLC data block is in a different radio block, then a Length Indicator with the value 0 shall be placed as the first Length Indicator in the next in sequence RLC data block and the TFI in the RLC/MAC header associated with the next in sequence RLC data block and, if eTFI is assigned, the eTFI indicated by the CRC of the next in sequence RLC data block, shall correspond to the last segment of the Upper Layer PDU.

– When a Length Indicator having the value 124 is included in the same RLC data block as the last segment of the Upper Layer PDU and fills the RLC data block precisely then the first octet of the RLC data field of the next in sequence RLC data block shall include the TFI (and eTFI if assigned) corresponding to the Upper Layer PDU whose transmission is resumed (if a suspend occurred) or to a new Upper Layer PDU (if no suspend occurred).

A Length Indicator of value 123 is used by a mobile station supporting network sharing to indicate the presence of the Selected PLMN Index field (see sub-clause 10.4.27) in the octet immediately following this Length Indicator. In this case it shall always be the first Length Indicator in the RLC data block. The first Length Indicator used for the case of EMSR requires that at least one previous RLC data block has been sent for the uplink TBF whereas the first Length Indicator used to indicate the presence of the Selected PLMN Index field shall always occur within the very first RLC data block sent for the uplink TBF and as such they can never occur within the same RLC data block.

When performing the radio access part of the MTA procedure using the RLC Data Block method (see 3GPP TS 44.018 [11]) a Length Indicator of value 122 is used by a mobile station to indicate the presence of the “Cell Identity” field (2 octets) starting in the octet immediately following LI = 122, the “Routing Area Identification” field (6 octets) starting in the octet immediately following the last octet used for the Cell Identity” field, the “MS Sync Accuracy” field (4 bits) and the “MS Transmission Offset” field (4 bits) in the octet immediately following the last octet used for the “Routing Area Identification” field and the “Random ID” field (16 bits) in the two octets immediately following the octet used for the MS Sync Accuracy” and the “MS Transmission Offset” fields (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2). A single RLC data block is sent when performing the radio access part of the MTA procedure when using this method and does not include an Upper Layer PDU. As such, no additional payload beyond the 11 octets immediately following LI = 122 shall be carried by the RLC data block (i.e. an RLC data field shall not be included).

When performing the radio access part of the MTA procedure using the RLC Data Block method (see 3GPP TS 44.018 [11]) a Length Indicator of value 119 is used by a mobile station to indicate the presence of the “MTA Signature” field (4 octets) starting in the octet immediately following LI = 119 (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2). MS generates MTA signature using integrity protection algorithm (see 3GPP TS 43.020) with a concatenated string formed using cellid and transmission as input. A single RLC data block is sent when performing the radio access part of the MTA procedure when using this method and does not include an Upper Layer PDU. As such, no additional payload beyond the 4 octets immediately following LI = 119 shall be carried by the RLC data block (i.e. an RLC data field shall not be included).

When performing the radio access part of the MTA procedure using the RLC Data Block method (see 3GPP TS 44.018 [11]) a Length Indicator of value 118 is used by a mobile station to indicate the presence of the “MTA Report Instance” field and the “FMA” field starting in the octet immediately following LI = 118 (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2). A single RLC data block including these fields is sent when performing the radio access part of the MTA procedure with enhanced security provided according to the BSS Duplication Detection Method (see 3GPP TS 43.059 and 3GPP TS 49.031) and does not include an Upper Layer PDU. As such, no additional payload beyond the octet immediately following LI = 118 shall be carried by the RLC data block (i.e. an RLC data field shall not be included).

When sending a Page Response due to receiving a Page with a ‘positioning event’ indication (see 3GPP TS 44.018 [11] and 3GPP TS 44.031) a Length Indicator of value 121 is used by a mobile station to indicate the presence of the “MS Sync Accuracy” field (4 bits) and the “MS Transmission Offset” field (4 bits) starting in the octet immediately following following LI = 121 (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2). The LLC PDU (i.e. the Page Response) is carried within the RLC data field. When receiving an RLC Data Block with LI = 121 the BSS sends the SGSN an UL-UNITDATA PDU that includes the LLC PDU, the “MultilaterationTiming Advance”, “MS Synchronization Accuracy” and the “BTS Reception Accuracy” parameters.

A Length Indicator of value 120 is used by a mobile station supporting MS assisted Dedicated Core Network selection and indicates the presence of a DCN-ID value (see sub-clause 10.4.30) in the two octets immediately following this Length Indicator.

The final RLC data block of a TBF shall have a Length Indicator field corresponding to the final Upper Layer PDU unless the final Upper Layer PDU fills the RLC data block precisely. If the final Upper Layer PDU fills the final RLC data block precisely, the final Upper Layer PDU shall be sent without a corresponding Length Indicator field.

The Length Indicator field is 7 bits in length and shall be encoded as a binary number. The valid values are the values ranging from 0 to 74 for an EGPRS TBF, an EC TBF, an EGPRS2-A uplink TBF or an EGPRS2-B TBF, from 0 to 82 for an EGPRS2-A downlink TBF, from 0 to 103 in TCH TBF mode (Iu mode), and the values 118 to 127. All other values are reserved. A mobile station detecting a reserved Length Indicator value or an inconsistent encoding of the Length Indicator and E fields shall ignore the RLC data block.

The interpretation of the value contained in the length indicator with corresponding E bit is summarized in table 10.4.14a.1 and some examples are shown in annex B.

Table 10.4.14a.1: Interpretation of values of LI field and E bit

Value of LI in a RLC data block	Value of E bit in the same octet	Interpretation
k-th LI (k>0 integer): 0< value <75 (EGPRS/EC-GSM-IoT except EGPRS2-A downlink) 0< value <83 (EGPRS2-A downlink) 0< value <104 (TCH)		The value of the k-th LI is the number of octets of the k-th Upper Layer PDU, or the last segment of it, in the current RLC data block.
	0	There is at least one Upper Layer PDU following the k-th Upper Layer PDU in the current RLC data block.
	1	There is no more than one Upper Layer PDU following the k-th Upper Layer PDU in the current RLC data block.
1^st LI: value =0	0	The last Upper Layer PDU of the previous in sequence RLC data block ends at the boundary of that RLC data block and it has no LI in the header of that RLC data block. Thus the current RLC data block contains the first segment of all included Upper Layer PDUs.
1^st LI: value = 126	0	The current RLC data block contains the first segment of all included Upper Layer PDUs.
k-th LI (k>1 integer): 0< value <75 (EGPRS/EC-GSM-IoT except EGPRS2-A downlink) 0< value <83 (EGPRS2-A downlink) 0< value <104 (TCH)		The k-th LI contains the number of octets of the (k-1)-th Upper Layer PDU in the current RLC data block.
	0	There is at least one Upper Layer PDU following the (k-1)-th Upper Layer PDU in the current RLC data block.
	1	There is no more than one Upper Layer PDU following the (k-1)-th Upper Layer PDU in the current RLC data block.
k-th LI: value=127	1	The octets between the end of the Upper Layer PDU indicated by the (k-1)-th LI and the end of the current RLC data block are filling octets.
1^st LI: value=0	1	The previous RLC data block contains a Upper Layer PDU, or a part of it, that fills precisely the previous data block and for which there is no length indicator in that RLC data block. The current RLC data block contains a Upper Layer PDU that either fills the current RLC data block precisely or continues in the next RLC data block.
1^st LI: value = 126	1	The current RLC data block contains the first segment of an Upper Layer PDU that either fills the current RLC data block precisely or continues in the next RLC data block.
1^st LI: value=127 (Iu mode only)	1	All octets of the RLC Data block contain filling information.
k-th LI: value=125 (this value is not supported in EC operation)	0/1	The current RLC data block contains the dynamic timeslot reduction control information.
k-th LI:value=124 (this value is only allowed if EMSR is enabled)	0	An LI value of 124 serves as a TFI transition indicator and is immediately followed by an octet containing the TFI associated with the next Upper Layer PDU segment in bit positions 1 to 5 (where bit 5 is the most significant bit) and reserved bits in bit positions 6 to 8. If eTFI is assigned then it shall be indicated by bit positions 6 to 8 (where bit 8 is the most significant bit).
1^st LI:value=123 (this value is only allowed if network sharing is supported both by the network and the mobile station)	0/1	An LI value of 123 serves as a Selected PLMN Index field indicator and is immediately followed by an octet that contains the Selected PLMN Index field (see sub-clause 10.4.27).
LI: value=122 (this value is only used if the MS is performing the radio access part of the MTA procedure using the RLC Data Block method)	0/1	An LI value of 122 indicates the RLC data block includes the “Cell Identity”, “Routing Area Identification”, “MS Sync Accuracy”, “MS Transmission Offset”and “Random ID” fields and is immediately followed by 11 octets that contain this information. The first 2 octets immediately following LI = 122 contain the “Cell Identity” field, the next 6 octets contain the “Routing Area Identification” field, the next octet contains the “MS Sync Accuracy” field and the “MS transmission Offset” fields and the last 2 octets include the “Random ID” field.
LI: value=121 (this value is only used if the MS is sending a Page Response due to receiving a page with a positioning event indication)	0/1	An LI value of 121 indicates the RLC data block includes the “MS Sync Accuracy” and “MS Transmission Offset” fields which are included starting in the octet immediately following LI = 121.
LI:value=120 (this value is only allowed if MS assisted Dedicated Core Network selection is supported both by the network (see 3GPP TS 44.018) and the mobile station)	0/1	An LI value of 120 serves as a DCN-ID field indicator and is immediately followed by two octets that contains the DCN-ID field (see sub-clause 10.4.30).
LI: value=119 (this value is only used if the MS is performing the radio access part of the MTA procedure and has need to provide MTA Signature using the RLC Data Block method)	0/1	An LI value of 119 indicates the RLC data block includes the “MTA Signature” field.
LI: value=118 (this value is only used if the MS is performing the radio access part of the MTA procedure using the RLC Data Block method where enhanced security is provided using the BSS Duplication Detection Method)	0/1	An LI value of 118 indicates the RLC data block includes the “FMA” and “MTA Report Instance” fields and is immediately followed by the octet that contains these fields.
No LI field present	n.a.	The Upper Layer PDU that starts with the current RLC data block either fills the current RLC data block precisely or continues in the following in-sequence RLC data block

10.4.15 TLLI field

The TLLI field contains a TLLI encoded as the contents of the TLLI information element defined in 3GPP TS 44.018.

10.4.16 RLC data field

The RLC data field contains octets from one or more Upper Layer PDUs. The RLC data field may contain parts of one or two Upper Layer PDUs and all of an arbitrary number of Upper Layer PDUs. The E bit, the M bit, and the Length Indicator delimit the RLC data field into Upper Layer PDUs. If the last Upper Layer PDU of a downlink TBF or an uplink RLC data block with CV = 0 does not fill the entire RLC data field, an extension octet shall be used to indicate the number of valid RLC data octets. The remainder of the RLC data field shall be filled with filler octets with the value ‘00101011’. Only the last RLC data block of a downlink TBF or an uplink RLC data block with CV = 0 may contain filler octets. If an uplink TBF is continued after the RLC data block with CV = 0, the next Upper Layer PDU starts with the first octet of the RLC data field of the next in sequence RLC data block.

10.4.17 Control message contents field

The Control message contents field shall contain exactly one segment from one RLC/MAC control message field (i.e. RLC/MAC control block).

10.4.18 Resent Block Bit (RSB)

The Resent Block Bit (RSB) indicates whether any of the RLC data blocks contained within the EGPRS radio block have been sent previously. The setting of this field is shown in table 10.4.18.1.

Table 10.4.18.1: Resent block bit

bit
0	All of the RLC data blocks contained within the EGPRS radio block are being transmitted for the first time
1	At least one RLC data block contained within the EGPRS radio block has been transmitted before
NOTE: The use of this bit shall be reconsidered in future versions of the present document.

10.4.19 PFI Indicator (PI) bit

The PFI Indicator (PI) indicates the presence of the optional PFI field. The PI shall be ignored in Iu mode.

Table 10.4.19.1: PFI Indicator (PI) bit

bit	PFI Indicator (PI) bit
0	PFI is not present
1	PFI is present if TI field indicates presence of TLLI

10.4.20 Packet Flow Identifier (PFI) field

The PFI field contains a PFI value encoded as the contents of the PFI information element as defined in 3GPP TS 44.018. The use of PFI is not supported in EC operation.

10.4.21 PAN Indication (PANI) field

The PANI field indicates the presence of the PAN field.

Table 10.4.21.1: PAN Indication (PANI) field

bit	PANI
0	A PAN field is not included
1	A PAN field is included

10.4.22 Beginning of Window (BOW) field

The BOW (begin of window) bit shall be set if SSN = [V(Q) + 1] modulo SNS.

10.4.23 Short Starting Sequence Number (ShortSSN) field

The ShortSSN field contains the L least significant bits of an SSN. The size L of the ShortSSN field is determined from the window size as follows:

In RLC non-persistent mode, if the assigned window size is less than 64 the size of the ShortSSN field is 7 bits.

10.4.24 Carrier ID (CI) field

The CI field contains a carrier ID and shall be encoded as CI_DTR IE as defined in sub-clause 11.2.28. It indicates the carrier the mobile station shall monitor when DTR is used (see sub-clause 8.1.8). The timeslot or PDCH-pair to monitor on this carrier is indicated with the TN/PDCH-pair field.

When DTR is used in a DLMC configuration the mobile station shall ignore this field (see sub-clause 8.1.8.2).

10.4.25 TN/PDCH-pair field

This field contains the timeslot number (BTTI configuration) or the PDCH-pair number (RTTI configuration) the mobile station shall monitor on the indicated carrier (CI field) when DTR is used (see sub-clause 8.1.8).

10.4.26 DTR Blks

This field indicates the subset of downlink radio blocks the mobile station shall monitor for USFs and/or downlink RLC data blocks in DTR mode. The field is coded as in table 10.4.26.1, where the block numbers are specified in 3GPP TS 45.002.

Table 10.4.26.1: Radio blocks monitored in DTR mode

DTR Blks bit 6 5	BTTI Configuration	RTTI Configuration
DTR Blks bit 6 5	BTTI Configuration	BTTI USF mode	RTTI USF mode
0 0	All	All	All
0 1	B0, B2, B4, B6, B8, B10	B0_a, B0_b, B2_a, B2_b, B4_a, B4_b, B6_a, B6_b, B8_a, B8_b, B10_a, B10_b,	B0_a, B1_a, B2_a, B3_a, B4_a, B5_a, B6_a, B7_a, B8_a, B9_a, B10_a, B11_a,
1 0	B0, B4, B8	B0_a, B0_b, B4_a, B4_b, B8_a, B8_b,	B0_a, B2_a, B4_a, B6_a, B8_a, B10_a,
1 1 (NOTE)	reserved	reserved	reserved
NOTE: When received it shall be interpreted as ’00’.

10.4.27 Selected PLMN Index field

This field contains the index of the PLMN selected by a mobile station supporting network sharing. The index value refers either to the identity of the Common PLMN broadcast in the SYSTEM INFORMATION TYPE 3/4 message, or EC SYSTEM INFORMATION TYPE 2 message for EC-GSM-IoT, or to the identity of an Additional PLMN broadcast in the SYSTEM INFORMATION TYPE 22 message, or EC SYSTEM INFORMATION TYPE 4 message for EC-GSM-IoT, as described in Table 10.4.27.1.

Table 10.4.27.1: Selected PLMN Index field

bit 3 2 1	Selected PLMN Index
0 0 1	PLMN identity of the Common PLMN broadcast in SYSTEM INFORMATION TYPE 3/4. For EC-GSM-IoT, the PLMN identity of the Common PLMN is broadcast in EC SYSTEM INFORMATION TYPE 2.
0 1 0	PLMN identity of the first Additional PLMN in the network sharing information broadcast in SYSTEM INFORMATION TYPE 22. For EC-GSM-IoT, the PLMN identity of the first Additional PLMN in the network sharing information is broadcast in EC SYSTEM INFORMATION TYPE 4.
0 1 1	PLMN identity of the second Additional PLMN in the network sharing information broadcast in SYSTEM INFORMATION TYPE 22. For EC-GSM-IoT, the PLMN identity of the second Additional PLMN in the network sharing information is broadcast in EC SYSTEM INFORMATION TYPE 4.
1 0 0	PLMN identity of the third Additional PLMN in the network sharing information broadcast in SYSTEM INFORMATION TYPE 22. For EC-GSM-IoT, the PLMN identity of the third Additional PLMN in the network sharing information is broadcast in EC SYSTEM INFORMATION TYPE 4.
1 0 1	PLMN identity of the fourth Additional PLMN in the network sharing information broadcast in SYSTEM INFORMATION TYPE 22. For EC-GSM-IoT, the PLMN identity of the fourth Additional PLMN in the network sharing information is broadcast in EC SYSTEM INFORMATION TYPE 4.
	All other values are reserved

10.4.28 Coverage Class field (CC)

In EC operation, a 2-bit field is included in the downlink RLC data block header type 3 to signal the downlink Coverage Class used in the block. The Coverage Class indicates a predefined number of blind physical layer transmissions to be applied for each logical channel, where the use of blind physical layer transmissions can allow the mobile station to operate in extended coverage, see 3GPP TS 43.064. Coverage class 5 (CC5) is applicable only for UL TBFs. The field EC_Reduced_PDCH_Allocation in the EC SYSTEM INFORMATION TYPE 2 message specifies if an EC TBF uses normal allocation with 4 PDCHs or reduced allocation with 2 PDCHs in the coverage class CC2, CC3 or CC4 in the cell. The corresponding mapping of EC channels onto physical channels shall be as specified in 3GPP TS 45.002.

Table 10.4.28.1: Coverage Class field

bits 7 6	CC
0 0	Coverage Class 1, CC1
0 1	Coverage Class 2, CC2
1 0	Coverage Class 3, CC3
1 1	Coverage Class 4, CC4

10.4.29 Downlink Coverage Class Estimate (DCCE)

In EC operation, a 4-bit field is included in the uplink RLC data block header to signal the estimated downlink Coverage Class, see 3GPP TS 43.064, and, when CC1 is estimated, the extent to which the estimated C value (see 3GPP TS 45.008) exceeds the value indicated by the BT_Threshold_DL parameter sent in EC SI2 (see 3GPP TS 44.018). The C value will be reported in steps of 3 dB above the BT_Threshold_DL where BT_Threshold_DL indicates when blind physical layer transmissions are used.

Table 10.4.29.1: DCCE field

bits 4 3 2 1	DCCE	bits 4 3 2 1	DCCE
0 0 0 0	DL CC4	1 0 0 0	DL CC1; BT_Threshold_DL+15 dB ≤ C value < BT_Threshold_DL+18 dB
0 0 0 1	DL CC3	1 0 0 1	DL CC1; BT_Threshold_DL+18 dB ≤ C value < BT_Threshold_DL+21 dB
0 0 1 0	DL CC2	1 0 1 0	DL CC1; BT_Threshold_DL+21 dB ≤ C value < BT_Threshold_DL+24 dB
0 0 1 1	DL CC1; BT_Threshold_DL ≤ C value < BT_Threshold_DL+3 dB	1 0 1 1	DL CC1; BT_Threshold_DL+24 dB ≤ C value < BT_Threshold_DL+27 dB
0 1 0 0	DL CC1; BT_Threshold_DL+3 dB ≤ C value < BT_Threshold_DL+6 dB	1 1 0 0	DL CC1; BT_Threshold_DL+27 dB ≤ C value < BT_Threshold_DL+30 dB
0 1 0 1	DL CC1; BT_Threshold_DL+6 dB ≤ C value < BT_Threshold_DL+9 dB	1 1 0 1	DL CC1; BT_Threshold_DL+30 dB ≤ C value < BT_Threshold_DL+33 dB
0 1 1 0	DL CC1; BT_Threshold_DL+9 dB ≤ C value < BT_Threshold_DL+12 dB	1 1 1 0	DL CC1; BT_Threshold_DL+33 dB ≤ C value < BT_Threshold_DL+36 dB
0 1 1 1	DL CC1; BT_Threshold_DL+12 dB ≤ C value < BT_Threshold_DL+15 dB	1 1 1 1	DL CC1; BT_Threshold_DL+36 dB ≤ C value < BT_Threshold_DL+39 dB
NOTE: The bit numbering is relative to the field position.

10.4.30 Cell Identity

When the radio access part of the MTA procedure is performed using the RLC Data Block method, a 16 bit “Cell Identity” field is included in the uplink RLC data block (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2) and identifies the cell in which the MS received the RRLP Multilateration Timing Advance Request RRLP message (see 3GPP TS 44.031). The “Cell Identity” field is coded as per the value part of the “Cell Identity” information element defined in 3GPP TS 24.008.

10.4.31 Routing Area Identification

When the radio access part of the MTA procedure is performed using the RLC Data Block method a 48 bit “Routing Area Identification” field is included in the uplink RLC data block (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2). This field identifies the Routing Area Identification corresponding to cell in which the MS received the RRLP Multilateration Timing Advance Request message (see 3GPP TS 44.031). It is coded as per the value part of the “Routing Area Identification” information element defined in 3GPP TS 24.008.

10.4.32 MS Sync Accuracy

When the radio access part of the MTA procedure is performed using the RLC Data Block method the octet immediately following the 6 octet “Routing Area Identification” field contains the 4 bit “MS Sync Accuracy” field and the 4 bit “MS Transmission Offset” field (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2). The “MS Sync Accuracy” field is coded per the value part of the “MS Synchronization Accuracy” IE defined in 3GPP TS 49.031.

10.4.33 MS Transmission Offset

When the radio access part of the MTA procedure is performed using the RLC Data Block method the octet immediately following the 6 octet “Routing Area Identification” field contains the 4 bit “MS Sync Accuracy” field and the 4 bit “MS Transmission Offset” field (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2). The “MS Transmission Offset” field is coded as shown in Table 10.4.33.1.

Table 10.4.33.1: MS Transmission Offset information element

MS Transmission Offset (4 bits)

This field indicates the transmission offset applied by the MS when sending a RLC data block during the radio access part of the MTA procedure and is coded as follows:

Bit

4321

0000 MS Trans. Offset = -7/32 of symbol period

0001 MS Trans. Offset = -3/16 of symbol period

0010 MS Trans. Offset = -5/32 of symbol period

0011 MS Trans. Offset = -1/8 of symbol period

0100 MS Trans. Offset = -3/32 of symbol period

0101 MS Trans. Offset = -1/16 of a symbol period

0110 MS Trans. Offset = -1/32 of a symbol period

0111 MS Trans. Offset = 0

1000 MS Trans. Offset = 1/32 of a symbol period

1001 MS Trans. Offset = 1/16 of a symbol period

1010 MS Trans. Offset = 3/32 of a symbol period

1011 MS Trans. Offset = 1/8 of a symbol period

1100 MS Trans. Offset = 5/32 of symbol period

1101 MS Trans. Offset = 3/16 of symbol period

1110 MS Trans. Offset = 7/32 of symbol period

1111 MS Trans. Offset = 1/4 of symbol period

10.4.34 Random ID

When the radio access part of the MTA procedure is performed using the RLC Data Block method the 2 octets immediately following the octet that with the 4 bit “MS Sync Accuracy” field and 4 bit “MS Transmission Offset” field contain the “Random ID” field (see sub-clause 10.3a.2.1 and sub-clause 10.3a.2.2). The “Random ID” value sent by a MS performing the radio access part of the MTA procedure is selected from the set of the Random ID values provided by the RRLP Multilateration Timing Advance Request message (see 3GPP TS 44.031). Each Random ID value provided by the RRLP Multilateration Timing Advance Request message can only be used in one cell used during the MTA procedure.

10.4.35 Downlink Coverage Class (DLCC)

An EC TBF established with uplink coverage class CC5 shall include a 2 bit field in the uplink RLC data block header to signal the estimated downlink Coverage Class, see 3GPP TS 43.064.

Table 10.4.30.1: DLCC field

bits 2 1	DLCC
0 0	DL CC4
0 1	DL CC3
1 0	DL CC2
1 1	DL CC1
NOTE: The bit numbering is relative to the field position.

10.4.36 DCN-ID field

This field contains the DCN-ID value (as indicated to the RLC/MAC layer by upper layers) sent from a mobile station to a BSS when both the mobile station and BSS support MS assisted Dedicated Core Network selection, see 3GPP TS 24.008 [51] and TS 3GPP TS 23.401 [54].

Table 10.4.30.1: DCN-ID field

Bits

8 7 6 5 4 3 2 1

Octet 1

8 least most significant bits

(8 7 6 5 4 3 2 1)

Octet 2

8 most significant bits

(16 15 14 13 12 11 10 9)

10.4.37 MTA Signature

When the radio access part of the MTA procedure is performed using the RLC Data Block method, a four octet MTA signature is sent from the mobile station to the BSS if requested by the SMLC (see 3GPP TS 44.031). The mobile derives this based on cell-identifier and MS transmission offset parameters sent in all successful MTA attempts.

10.4.38 Final MTA Access (FMA)

This is field is set to ‘1’ when the RLC data block is transmitted in conjunction with the MS performing the last instance of the radio access part of the MTA procedure using the RLC Data Block method where enhanced security is provided using the BSS Duplication Detection Method. Otherwise, it is set to ‘0’.

10.4.39 MTA Report Instance

This is field is set according to the instance of the radio access part of the MTA procedure performed using the RLC Data Block method where enhanced security is provided using the BSS Duplication Detection Method. It is 3 bits long and is coded as shown in Table 10.4.39.1.

Table 10.4.39.1: MTA Report Instance field

bits 3 2 1	MTA Report Instance
0 0 0	1^st instance
0 0 1	2^nd instance
0 1 0	3^rd instance
0 1 1	4^th instance
1 0 0	5^th instance
NOTE: All remaining values are reserved. The bit numbering is relative to the field position.