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.