RLC

5.6 RLC

The RLC layer provides a reliable link between the BSS and the MS, allowing transmission of RLC blocks in acknowledged or unacknowledged mode during an uplink or downlink TBF. The RLC layer is responsible for the segmentation of LLC frames into RLC data blocks. Before being transmitted on the radio interface, these blocks are numbered by the transmitter so that the receiver is able to detect undecoded data blocks and request their selective retransmission. When all the RLC data blocks belonging to one LLC frame have been received, the RLC layer at the receiver side ensures the reassembly of the LLC frame.

The RLC layer also provides a similar mechanism for the transmission of RLC/MAC control messages from the BSS to the mobile.

5.6.1 Transmission Modes

The RLC automatic repeat request (ARQ) functions support two modes of operation:

RLC acknowledged mode;
RLC unacknowledged mode.

In RLC acknowledged mode, the RLC ensures the selective retransmission of RLC data blocks that have not been correctly decoded by the receiver. This mode is used to achieve a high reliability in LLC PDU sending. In RLC unacknowledged mode, RLC data blocks that have not been correctly decoded are not retransmitted by the sending entity. This mode is used for applications that are tolerant of error and that request a constant throughput, such as streaming applications (video or audio streaming).

In uplink, the requested RLC mode is indicated in the PACKET RESOURCE REQUEST message in case of two-phase access and is by default RLC acknowledged mode in case of one-phase access. In downlink, the RLC mode is indicated within the assignment message by the RLC_MODE parameter. During the TBF, the RLC mode cannot be changed. Any change in the RLC mode previously requires the release of the TBF.

5.6.2 Segmentation and Reassembly of LLC PDUs

5.6.2.1 Segmentation of LLC PDUs into RLC Data Blocks

The segmentation of LLC PDUs allows the transport through the radio interface of LLC PDUs, whose size can be much larger than the data unit length of a single RLC data block. The segmentation of LLC PDUs is done in a dynamic way. It means that a change of coding scheme bringing about the decrease or the increase of the RLC data block unit length could happen at any time during the transmission. Depending on the CS used to encode the transmit RLC data block, the LLC PDU will be segmented in variable size data units as described in Figure 5.22.

Figure 5.22: Segmentation mechanism.

The LLC PDUs are segmented in the same order as they are received by the transmit entity. Each RLC data block resulting from the segmentation of an LLC PDU is numbered using the BSN field of the RLC header. The BSN ranges from 0 to 127.

For one TBF, the first segmented RLC data block of the first LLC frame is numbered with BSN = 0, the next one with BSN = 1, and so on. The RLC data blocks are numbered modulo 128.

As described in Figure 5.22, if the contents of an LLC PDU do not fill an integer number of RLC data blocks, the beginning of the next LLC PDU and the end of the previous LLC PDU are placed in the same radio block. The LI, extension (E), and more (M) fields of the RLC data block header are used to delimit the consecutive LLC PDUs within one RLC data block.

The E field is used to indicate the presence of an optional extension octet in the RLC data block header. When set to 1 the E bit indicates that no extension octet follows. The M field is used to indicate (when set to 1) the presence of a new LLC PDU that starts after the current LLC PDU.

The combination M = 0 and E = 1 indicates that there is no LLC PDU after the current one and there are no more extension octets. The combination M = 1 and E = 0 indicates that a new LLC PDU starts after the current one and there is an extension octet that delimits the new one. The combination M = 1 and E = 1 indicates that a new LLC PDU starts after the current one and continues until the end of the block. The LI field is used to delimit the LLC PDUs within the RLC data block. The first LI of the RLC data block indicates the number of octets of the RLC data unit belonging to the first LLC PDU.

Figure 5.22 provides an example of how the E, M, and LI fields are used for LLC PDUs delimitation within RLC data blocks.

5.6.2.2 Reassembly of LLC PDUs from RLC Data Blocks

After having received all the RLC data blocks belonging to an LLC PDU, the reassembly involves removing the RLC header of each RLC data block and reassembling the data unit using the BSN sequencing.

In case of RLC unacknowledged mode, some RLC data blocks may not have been decoded during the transfer. The RLC data units not received must be substituted with fill bits having the value 0.

5.6.3 Transfer of RLC Data Blocks

5.6.3.1 In Acknowledged RLC Mode

Sliding Window Mechanism

The transfer of RLC data blocks in the acknowledged RLC mode is controlled by a selective ARQ mechanism. This retransmission mechanism relies on the identification of each RLC data block, thanks to its BSN.

The RLC protocol relies on a sliding window mechanism. The size of this window for GPRS is 64 blocks. This window ensures that the gap, in term of block number, between the oldest unacknowledged block and the next-in-sequence block to be transmitted is always lower than 64. The sending side is not allowed to transmit a block when its BSN modulo 128 is higher than (BSN of the oldest unacknowledged block + 64) modulo 128. In this case, the RLC protocol is stalled. In this situation, the transmit entity is only allowed to retransmit the RLC data blocks that have not yet been acknowledged.

At the beginning of the TBF, the transmitter starts sending RLC data blocks in sequence. The oldest unacknowledged block is then the one numbered with BSN = 0. New RLC data blocks can be sent as long as their BSN is lower than 63.

Each time an acknowledgment message is received from the receiver, the transmitter updates its list of unacknowledged RLC blocks and starts their retransmission from the oldest unacknowledged one. When the acknowledgement message indicates that the oldest unacknowledged block has been received and decoded at receiver side, the RLC window slides up to the next-oldest unacknowledged block indicated by the message. If the protocol was previously stalled, it is not anymore.

The receiver maintains a table that contains the state of all the RLC data blocks within the window. At the beginning of the TBF, the receiver expects to receive the block with BSN = 0. Since the RLC blocks are sent in sequence by the sending side, the receiver can deduce from a correctly decoded block all the previously sent blocks that have not been decoded. Whenever an RLC block is decoded, it is marked as "decoded" within the table.

In case of a downlink TBF (the sending entity is the network), the PACKET DOWNLINK ACK/NACK message that contains the information on which blocks have not been decoded at the mobile side is always sent by the mobile on a BSS order (polling). In case of uplink TBF, the decision to send a PACKET UPLINK ACK/NACK message is also made by the network.

Each such message acknowledges all correctly received RLC data blocks up to an indicated BSN, thus "moving" the beginning of the sending window on the transmit side. Additionally, a bitmap is used to indicate BSNs of erroneously received RLC data blocks. The sending side then retransmits the erroneous RLC data blocks.

Figure 5.23 shows how the sliding window mechanism works on the transmit side as well as on the receive side. In the first state of the transmitter, the RLC data blocks with BSN 120, 12, and 37 have been transmitted but are unacknowledged. The next block that will be transmitted has BSN = 38. The receiver has not decoded the block with BSN = 12 and the last correctly decoded block was BSN = 36. The RLC data block with BSN = 37 that has been previously sent is not decoded by the receiver.

Figure 5.23: Sliding window mechanism.

The transmitter sends the RLC block with BSN = 38 that is decoded by the receiver. This latter detects that the RLC block with BSN = 37 has not been decoded and BSN = 38 is the newest received RLC block.

At the next step, the receiver sends an acknowledgment message indicating that all the blocks until BSN = 38 have been received except BSN = 12 and BSN = 37. Upon receipt of this message, the transmitter updates its state table and the window is moved up to BSN = 12. The transmitter retransmits the block with BSN = 12. This block is decoded by the receiver that updates its received state table.

RLC Data Block Transfer During Uplink TBF

The MS transmits uplink RLC data blocks during allocated uplink PDTCH occurrence. The network sends a PACKET UPLINK ACK/NACK message when needed on the downlink PACCH. This message indicates the uplink RLC data blocks that have been correctly received and which ones have not been correctly decoded. Figure 5.24 shows a scenario for uplink transfer.

Figure 5.24: RLC data block transfer during an uplink TBF.

The PACKET UPLINK ACK/NACK message contains the following information:

Uplink TFI. This identifies the uplink TBF.
Channel coding command. The network may request the use of another coding scheme based on measurements performed on the uplink.
ACK/NACK description. This contains three parameters: The FINAL_ACK_INDICATION indicates whether the entire TBF is being acknowledged. It is used for uplink TBF release. The STARTING_SEQUENCE_NUMBER is the BSN corresponding to the end of the window plus 1. The RECEIVE_BLOCK_BITMAP is a bitmap representing whether a BSN is ACK or NACK. The bitmap starts from the STARTING_SEQUENCE_NUMBER backwards.

Note that if fixed allocation is used for the uplink transfer, the BSS may allocate more uplink resources within the PACKET UPLINK ACK/NACK message by including a fixed-allocation bitmap.

RLC Data Block Transfer During Downlink TBF

During downlink transfer, the BSS transmits downlink RLC data blocks to the mobile. Whenever needed, the network requests the sending of a PACKET DOWNLINK ACK/NACK message from the mobile on PACCH.

The network polls the mobile in an RLC data block in order to request the sending of a PACKET DOWNLINK ACK/NACK message. The polling is performed using the S/P and RRBP fields of the downlink control block MAC header. Figure 5.25 gives a scenario for downlink transfer.

Figure 5.25: RLC data block transfer during a downlink TBF.

The PACKET DOWNLINK ACK/NACK message contains the following information:

Downlink TFI. This identifies the downlink TBF.
ACK/NACK description: This is the same as for the PACKET UPLINK ACK/NACK message, listed above.
Channel quality report. The network uses these measurements for network-controlled cell reselection and for dynamic CS adaptation.

Note that the mobile may request the establishment of an uplink TBF by including a channel request description within the message.

5.6.3.2 In Unacknowledged RLC Mode

In RLC unacknowledged mode, the sending side transmits the RLC data blocks in sequence. The blocks are numbered so that the receiver is able to detect undecoded data blocks. The data blocks that are not decoded by the receiver are not retransmitted. On the receiver side, when all the RLC data blocks belonging to one LLC frame have been received, the LLC frame is reassembled.

During an uplink TBF, the network may send a PACKET UPLINK ACK/NACK message that is used to order a new CS for the mobile or to allocate more uplink resources in case of fixed allocation (in which case a new allocation bitmap is sent to the mobile). During a downlink TBF, the network will request the sending of PACKET DOWNLINK ACK/NACK messages thanks to the polling mechanism in order to receive the channel quality report from the mobile. In spite of the non-retransmission of undecoded RLC data blocks by the network, the mobile provides the RECEIVE_BLOCK_BITMAP within this message. The network can use this bitmap to estimate the downlink BLER. Note that this evaluation is also possible in RLC acknowledged mode but the evaluation is more complex due to the retransmissions.

5.6.4 Segmentation and Reassembly of RLC/MAC Control Messages

The RLC/MAC control messages contain a lot of optional fields and in some configuration the RLC/MAC message does not fit into one radio block encoded with CS-1. It is possible in the downlink direction to segment one RLC/MAC message into two RLC/MAC control blocks. This possibility is not provided in the uplink direction.

When the network has to transmit one RLC/MAC message within two RLC/MAC control blocks, the optional octet 1 is used to control the transaction (see Table 5.2). The RLC/MAC control message is identified by the RTI field of the header. The RBSN field indicates the sequence number of the RLC/MAC control block. The FS field indicates whether the FS of the RLC/ MAC control message is contained in the RLC/MAC control block or not.

Note that when the network wants to provide a PR value within the header of a downlink RLC/MAC control block, it must include the optional octet 2 in the header. Or if the message can fit within one radio block, the network must indicate within the optional octet 1 that the message is not segmented. In this case, the network indicates RBSN = 0 and FS = 1.

Figure 5.26 describes an example of PACKET UPLINK ASSIGNMENT message sending with segmentation.

Figure 5.26: Example of RLC/MAC control message segmentation.

The network may request the sending of a PACKET CONTROL ACKNOWLEDGMENT message during the sending of the segmented message. The polling is performed using the S/P and RRBP fields of the downlink control block MAC header of both downlink blocks.

By using the CRTL_ACK field, the mobile indicates within the PACKET CONTROL ACKNOWLEDGMENT message whether the two radio blocks have been correctly decoded and if not, which one must be retransmitted.