04.603GPPGeneral Packet Radio Service (GPRS)Mobile Station (MS) - Base Station System (BSS) interfaceRadio Link Control / Medium Access Control (RLC/MAC) protocolRelease 1999TS

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, whereas the same RLC/MAC block structure is used for control message transfers.

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.

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

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

10.0a.2 EGPRS RLC/MAC block for data transfer

The RLC/MAC block for EGPRS data transfer consists of a combined RLC/MAC header and one or two RLC data blocks.

Figure 10.0a.2.1: RLC/MAC block structure for data transfer for EGPRS

Each RLC data blocks contain octets from one or more LLC PDUs.

Depending on the modulation and coding scheme (see 3GPP TS 04.04 and 3GPP TS 05.03) 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 each transfer direction, uplink and downlink, three different header types are defined. 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 For MCS-1, MCS-2, MCS-3 and MCS-4.

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

The RLC/MAC block for control message transfer consists of a MAC header and an RLC/MAC control block.

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

10.0b RLC/MAC block format conventions

10.0b.1 Numbering convention

The physical layer transfers RLC/MAC blocs, 11‑bit and 8‑bit control messages in physical blocks of the packet data channel . The physical block formats are specified in 3GPP TS 04.04. 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 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. 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/PACCH block format), 11 bits or 8 bits (using the PRACH uplink/PACCH uplink short acknowledgement block formats, see 3GPP TS 04.04). 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 04.04) 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 RLC data blocks

The different components of the RLC/MAC block carrying an EGPRS 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 RLC data blocks.

10.0b.3.1 Field mapping convention for GPRS RLC data blocks, RLC/MAC control blocks, 11‑bit and 8‑bit control messages

When a field within a GPRS RLC data block or an 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 RLC data blocks

When a field within an EGPRS 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 05.03). 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

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.

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.

Figure 10.2.2.1: Uplink RLC data block with MAC header

NOTE 2: 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.

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

10.3.1 Downlink RLC/MAC control block

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

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

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.

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

10.3a EGPRS RLC data blocks and RLC/MAC headers

The EGPRS 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 applies when the components of the EGPRS RLC data block are assembled into the RLC/MAC block.

Figure 10.3a.1: Components of the EGPRS RLC data block

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

Table 10.3a.1: EGPRS RLC data unit size

NOTE: The three families of EGPRS RLC data blocks based on a common size basis (22, 28 and 37 octets) enable link adaptation retransmission as described in chapter 9.

10.3a.1 EGPRS downlink RLC data block

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

Figure 10.3a.1.1: EGPRS downlink RLC data block

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

10.3a.2 EGPRS Uplink RLC data block

The EGPRS uplink RLC data block are formatted according to Figure 10.3a.2.1.

Figure 10.3a.2.1: Uplink EGPRS RLC data block

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.

10.3a.3 EGPRS Downlink RLC/MAC header

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

The EGPRS combined downlink RLC/MAC header for MCS‑7, MCS‑8 and MCS‑9 (header type 1) is formatted according to figure 10.3a.3.1.1.

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

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

The EGPRS combined downlink RLC/MAC header for MCS‑5 and MCS‑6 (header type 2) is formatted according to figure 10.3a.3.2.1.

Figure 10.3a.3.2.1: EGPRS 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 and MCS-1 case

The EGPRS combined downlink RLC/MAC header for MCS‑1, MCS‑2, MCS‑3 and MCS‑4 (header type 3) is formatted according to figure 10.3a.3.3.1.

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

10.3a.4 EGPRS 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) is formatted according to figure 10.3a.4.1.1.

Figure 10.3a.4.1.1: EGPRS 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) is formated according to Figure 10.3a.4.3.1.

Figure 10.3a.4.3.1: EGPRS 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) is formatted according to figure 10.3a.4.3.1.

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

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 05.02). 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 04.08), PACKET CHANNEL REQUEST message, or EGPRS 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

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

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.

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

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 chapter 9).

Table 10.4.4a.1: EGPRS Supplementary/Polling (ES/P) field

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 or a PACCH block to the network. If the RRBP field is received as part of an RLC/MAC block containing an RLC/MAC control block containing any message except Packet Paging Request, Packet Access Reject, and Packet Queueing Notification, the mobile station shall transmit a PACKET CONTROL ACKNOWLEDGEMENT message in the uplink radio block specified. 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 Queueing Notification message, 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 eitherin 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 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 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 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 an PACKET CONTROL ACKNOWLEDGEMENT message in the specified uplink radio block.

The mobile station shall always transmit the uplink radio block on the same timeslot as the block where the RRBP was received. 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.

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 not use the RRBP field to schedule the transmission of a PACKET CONTROL ACKNOWLEDGEMENT message or an uplink PACCH block later than the second last block, B(x‑2) mod 12, before the first block, B(x), 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 that may omit responding to the polling request or 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 messages or uplink 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.

Table 10.4.5.1 indicates 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 05.02.

Table 10.4.5.1: Relative Reserved Block Period (RRBP) field

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.

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

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

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

10.4.8a Coding and Puncturing Scheme indicator field (CPS)

In EGPRS header, the Coding and Puncturing Scheme indicator field is used to indicate the kind of channel coding and puncturing used for data blocks.(see 05.03)

10.4.8a.1 Header type 1:

Table 10.4.8a.1.1: Coding and Puncturing Scheme indicator field for Header type 1

NOTE: The bit numbering is relative to the field position.

10.4.8a.2 Header type 2

Table 10.4.8a.2.1: Coding and Puncturing Scheme indicator field for Header type 2

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

NOTE: The bit numbering is relative to the field position.

10.4.8b Split Block indicator field (SPB)

In EGPRS, the Split Block indicator is only used in header type 3 to indicate if some user data is retransmitted using 2 block resegmentation (see Chapter 9)

Table 10.4.8b.1: Split Block indicator field

NOTE: The bit numbering is relative to the field position.

10.4.9 TLLI Indicator (TI) bit

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

Table 10.4.9.1: TLLI Indicator (TI) bit

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

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.

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

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

10.4.10 Temporary Flow Identity (TFI) field

In RLC data blocks, 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.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. 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.

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 depends on downlink power control mode (mode A and B defined in BTS_PWR_CTRL_MODE bit sent in assignment messages).

For mode A, 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.

Table 10.4.10a.1 gives values for mode A.

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

Table 10.4.10a.2 gives values for mode B.

Table 10.4.10a.2: Power Reduction (PR) field for mode B

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

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) (128 in GPRS and 2048 in EGPRS ) of each RLC data block within the TBF.

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

In EGPRS, the BSN is 11 bits in length and is encoded as a binary number with range 0 to 2047.

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

Second block number = [BSN1 + BSN2] modulo SNS

(e.g. SNS = 2048, WS = 512, Block A block number = 10 and Block B block number= 2000 then:

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

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

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

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

10.4.14 Length Indicator (LI) field in GPRS TBF mode

The Length Indicator is used to delimit LLC PDUs within the RLC data block. The first Length Indicator shall indicate the number of octets of the RLC data field belonging to the first LLC PDU, the second Length Indicator shall indicate the number of octets of the RLC data field belonging to the second LLC PDU, etc. Only the last segment of any LLC PDU of a TBF (either this segment carries the entire LLC 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 LLC PDU would fit within the RLC data block but the addition of the Length Indicator octet (to indicate the LLC PDU boundary) causes the LLC 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 LLC PDU segment.

The final RLC data block of a TBF shall have a Length Indicator field corresponding to the final LLC 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 final RLC data block of an uplink TBF shall have a Length Indicator field with the value 0 if the final LLC PDU is incompletely transmitted by the mobile station.

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 LLC 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’. 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

The Length indicator is used to delimit LLC PDUs within the RLC data block. The first Length Indicator shall indicate the number of octets of the RLC data field belonging to the first LLC PDU, the second Length Indicator shall indicate the number of octets of the RLC data field belonging to the second LLC PDU, etc. Only the last segment of any LLC 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 LLC PDU, unless the LLC PDU without the corresponding LI field fills the RLC data block precisely. In that 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.

If the LLC 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 LLC PDU in this RLC data block. If the LLC PDU does not fill the RLC data block and there is only one octet left, then the Length Indicator corresponding to the LLC PDU is the last Length Indicator field that shall be included in the RLC data block. In case the LLC PDU cannot be transmitted completely in the current RLC data block and will not be continued in the next in-sequence RLC data block, the corresponding Length Indicator shall have the value 127.The final RLC data block of a TBF shall have a Length Indicator field corresponding to the final LLC PDU unless the final LLC PDU fills the RLC data block precisely. If the final LLC PDU fills the final RLC data block precisely, the final LLC 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 and the value 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 the 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

10.4.15 TLLI field

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

10.4.16 RLC data field

The RLC data field contains octets from one or more LLC PDUs. The RLC data field may contain parts of one or two LLC PDUs and all of an arbitrary number of LLC PDUs. The E bit, the M bit, and the Length Indicator delimit the RLC data field into LLC PDUs. If the last LLC PDU of the TBF does not fill the entire RLC data field, an extension octet shall be used to indicate the number of valid RLC data octets and the remainder of the RLC data field shall be filled with filler octets with the value ‘00101011’. Only the last RLC data block of the TBF may contain filler octets.

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

NOTE: The use of this bit shall be reconsidered in future versions of this specification.

10.4.19 PFI Indicator (PI) bit

The PFI Indicator (PI) indicates the presence of the optional PFI field.

Table 10.4.19.1: PFI Indicator (PI) bit

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