3g Lte Info » RLC

Flexible RLC PDU Size (Release 7)

Prashant Panigrahi — Thu, 15 Apr 2010 09:04:41 +0000

Flexible RLC PDU Size was introduced in Release 7 in order to decrease RLC protocol overhead and to avoid sequence number stalling

Flexible RLC is used with MAC-ehs in Release 7. Mac-ehs is a new feature introduced in Release 7 to increase the downlink throughput.

RLC PDU Structure before Flexible RLC Size

In previous 3GPP releases RLC PDU size was semi static, e.g. 336 bits or 656 bits. An IP packet size is 1500 octets so many RLC PDUs are required to transmit a single IP packet. The detail description about this problem is described in the following examples.

Example # 1

Assumption RLC PDU size is 336 bits

Ethernet IP Packet Size: 1500 octets

1 RLC PDU size = 336 bits

Maximum RLC Data (RLC SDU) size = 336 – 16 = 320 bits = 40 octets

So minimum number of RLC PDUs required to transmit one Ethernet packet = 1500/40 = 37.5 ~ 38 PDUs

For 38 PDUs header added = 76 (38 * 2 (for fixed header)) + Length Indicators + Padding (If required)

Example # 2

Assumption RLC PDU size is 656 bits

Ethernet IP Packet Size: 1500 octets

1 RLC PDU size = 656 bits

Maximum RLC Data (RLC SDU) size = 656 – 16 = 640 bits = 80 octets

So minimum number of RLC PDUs required to transmit one Ethernet packet = 1500/80 = 18.75 ~ 19 PDUs

For 19 PDUs header added = 38 (19 * 2 (for fixed header)) + Length Indicators + Padding (If required)

Flexible RLC PDU Size

With the implementation of “Flexible RLC PDU Size” RLC overhead can be significantly decreased.

25.322 (4.2.1.3)

If flexible RLC PDU size is configured, the downlink AMD PDU size is variable up to the maximum RLC PDU size, and the Length Indicator size is configured by upper layers. The flexible RLC PDU size can be only configured in the downlink.

25.322 (9.2.2.9)

the length of RLC SDUs is constrained to a multiple of 8 bits

if "Flexible RLC PDU size" is configured (only applicable for downlink):

the last segment of an RLC SDU shall be concatenated with the first segment of the next RLC SDU in order to fill the data field up to the Maximum RLC PDU size. The "Length Indicator" field is used to point the borders between RLC SDUs.

if "Flexible RLC PDU size" is configured, the maximum size of the data field of the RLC PDU is 1503 octets.

CR 0342

The maximum size of the data field of the RLC PDU currently equals to the maximum MTU size of 1500 Byte used for Ethernet. However, if PDCP header needs to be included, the RLC PDU is not large enough to convey both the maximum MTU and the PDCP header. Since the PDCP header can be 0, 1 or 3 Byte, it is proposed that the maximum size of the data field should be 1503 octets.

25.322 (4.2.3)

In downlink, if flexible RLC PDU size is configured, RLC SDUs are segmented if the SDU is larger than the maximum RLC PDU size. Concatenation may be performed up to the maximum RLC PDU size.

Header Extension (HE) Enhancement in Release 7

A special value for Header Extension (HE) is introduced in Release 7.

10: The RLC AM PDU contains the last of the RLC SDU so no Length Indicator is required.

Value	Description
00	The succeeding octet contains data
01	The succeeding octet contains a length indicator and E bit
10	If “Use special value of the HE field” is configured, the succeeding octet contains data and the last octet of the PDU is the last octet of an SDU. Otherwise, this coding is reserved (PDUs with this coding will be discarded by this version of the protocol).
11	Reserved (PDUs with this coding will be discarded by this version of the protocol).

25.322 (11.3.2)

if the last octet of the PDU is the last octet of an SDU and there is no SDU concatenation inside the PDU, and the “use of the special value of the HE field” has been configured by higher layers, set the HE field to indicate that the last octet of the PDU is the last octet of an SDU. Set HE to 10

NOTE 1: In downlink, if "flexible RLC PDU size" is configured, the UTRAN should segment, and if possible concatenate the RLC SDUs into AMD PDUs with a size not larger than the maximum RLC PDU size.

NOTE 2: In downlink, UTRAN can initiate the Polling function by assembling a POLL SUFI when “flexible RLC PDU size” is configured. If a POLL SUFI was assembled, UTRAN should schedule and submit to lower layer a STATUS PDU containing the POLL SUFI.

Example

Assumptions:

Ethernet Packet Size: 1500 Octets

Special HE is enabled.

Flexible RLC is set in Radio Bearer Setup

Reference

Radio Link Control (RLC) protocol specification (Release 7): http://www.3gpp.org/ftp/Specs/archive/25_series/25.322/25322-7a0.zip

CR 0342: Maximum RLC PDU Size: http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_40/docs/RP-080395.zip

UMTS Radio Link Protocol Decoder

Prashant Panigrahi — Tue, 12 Jan 2010 09:38:01 +0000

What is UMTS-RLCDecoder?

UMTS-RLCDecoder is small but powerful tool for decoding RLC header information both for Acknowledged Mode RLC PDUs and Unacknowledged Mode RLC PDUs.

RLC Unacknowledged Mode (UM) PDU Decoding

UMTS-RLCDecoder can decode:

UMD RLC Header information
1. UMD PDU Sequence Number
2. Extension bit
Length Indicator Decoding

RLC Acknowledged Mode (AM) PDU Decoding

UMTS-RLCDecoder can decode the RLC Acknowledged Mode Data (AMD) PDUs and Control PDUs.

AMD PDUs

AMD PDU Header Decoding
1. D/C Field
2. Sequence Number
3. Polling
4. Header Extension
Length Indicator Decoding

Control PDUs

Status PDUs
1. SUFI NO_MORE
2. SUFI ACK
3. SUFI LIST
4. SUFI RLIST
Reset and Reset-Ack PDUs

Download

UMTS RLC Status PDU: SUFI RLIST

Prashant Panigrahi — Wed, 23 Sep 2009 13:00:26 +0000

Catch Up

You may need the following tutorial:

RLIST (Relative- List) Super field

The SUFI RLIST consists of the following fields: 1. Type identifier field(RLIST) 2. LENGTH Filed 3. First Sequence Number(FSN) 4. Code Words (CW_1,CW_2,…, CW_LENGTH) The SUFI RLIST fields in the STATUS PDU are as follows:

Type = RLIST

LENGTH

FSN

CW₁

CW₂

……

CW_LENGTH

LENGTH

The LENGTH is a 4bits long field. The LENGTH field signifies the number of codewords (CW) in the super field of type RLIST.

FSN

The length of the FSN super field is of 12 bits. The FSN is the “Sequence Number” of the first erroneous AMD PDU in the RLIST. When the LENGTH field is populated as “0000” at that time FSN is only present in the SUFI and it is the only erroneous AMD PDU.

CW

CW or codeword field is of 4 bits long. The encoding of the codeword field is as follows:

Bit 1

Bit 2

Bit 3

Bit 4

The first three bits of the CW are part of the number and the last one bit is a status indicator. The encoding of the last bit of the CW field as 0 or 1 can be as following:

X₁X₂X₃0	When the last bit is 0, it signifies that the CW continues in next CW. The most significant bit is X₁within the codeword.
X₁X₂X₃1	When the last bit is 1, the number is terminated in this codeword. This is the most significant CW in the number.

By default, the number given by the CWs represents a distance between the previous indicated erroneous AMD PDU up to and including the next erroneous AMD PDU. One special value of CW is defined: 000 1: ‘Error burst indicator’ The error burst indicator means that the next CWs will represent the number of subsequent erroneous AMD PDUs (not counting the already indicated error position). After the number of errors in a burst is terminated with XXX 1, the next codeword will again by default be the least significant bits (LSB) of the distance to the next error. Special case while the STATUS PDU will be discarded: If the last CW, as indicated by the value of the LENGTH field, does not contain a "1" in its rightmost position, or the last CW, as indicated by the value of the LENGTH field does contain a "1" in its rightmost position, but is a special "error burst indicator" CW, the encoding of the RLIST SUFI is invalid, and the STATUS PDU is discarded.

Example

Suppose following erroneous PDU Sequence Numbers need to be reported in Rlist SUFI: 3, 5, 6, 7, 8, 9, 10 In this case there are a number of PDUs detected as erroneous starting from sequence number 5. So the encoding of the SUFI RLIST will be as follows:

Step #1

FSN = 3. So the four bit FSN field will be encoded as: FSN = 3 (%0000 0000 0011)

Step #2

The LENGTH = 3 LENGTH = 0011

Step #3

The next SN = 5. Distance = 5 – 3 = 2 CW1 = 0101 (As the distance is 2 and again the codeword is terminated here so the last bit is 1).

Step #4

Now there is error burst continues up to sequence number 10. So the special burst indicator will be used. So now the distance will be 5. So the encoding of the codewords CW₂ and CW₃ will be as follows: CW₂ = 0001 (Special error bust indicator is encoded here while the next CW will signify the length of the error burst) CW₃= 1011 (The distance from sequence number 5 to 10 is 5 and also the distance is terminated in this CW. So the last bit is 1)

The encoding of the SUFI RLIST as follows:

LENGTH

FSN

CW₁

CW₂

CW₃

Reference

Radio Link Control (RLC) protocol specification: 3GPP TS 25.322

UMTS RLC Status PDU: SUFI LIST

Prashant Panigrahi — Mon, 21 Sep 2009 11:47:14 +0000

Catch Up

UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK

LIST Super field

The List Super-Field consists of a type identifier field (LIST), a list length field (LENGTH) and a list of LENGTH number of pairs.

LENGTH

- Length: 4 bits
- The number of (SNi, Li) pairs in the super-field of type LIST.
- The value 0000 is INVALID and STATUS PDU is discarded.

SNi

Lenght: 12 bits
”Sequence number” of AMD PDU, which was not correctly received.

Li

Length: 4 bits
Number of consecutive AMD PDUs not correctly received following AMD PDU with”Sequence number” SNi.

Type = LIST

LENGTH

SN₁

L₁

SN₂

L₂

…

SN_LENGTH

L_LENGTH

Example

In this example:

RLC AMD PDUs with Sequence Number 0, 1, 2, 3, 6, 7 are received correctly
PDUs with sequence number 4 and 5 are missing.

Encoding of Status PDU

7	6	5	4	3	2	1	0
0	0	0	0	0	0	1	1
0	0	0	1	0	0	0	0
0	0	0	0	0	1	0	0
0	0	0	1
SUFI ACK + PADDING

Explanation

Octet #1:

0: D/C: Data or control PDU. As it is a control PDU this bit is set to 0.

000: Control PDU Type: 000 indicates it is a Status PDU.

0011: SUFI Type. This is SUFI LIST

Octet #2 and #3

0001: LENGTH field. This indicates the number of (SNi, Ni) pairs. Here there is only one pair

0000 0000 0100: (SNi): The start sequence number. This is the Sequence number of the missing PDU. Here the missing PDUs start from Sequence Number 4 (100).

0001: (Li): The number of consecutive missing PDUs following sequence number 4 (SNi). Here there is only 1 (Sequence number 5)

Rest of the Status PDU may be encoded for SUFI ACK and Padding.

Reference

Radio Link Control (RLC) protocol specification: 3GPP TS 25.322

UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK

Prashant Panigrahi — Mon, 21 Sep 2009 09:43:38 +0000

The STATUS PDU is used to exchange status information between two RLC AM entities.

Why STATUS PDU is required

by the receiving entity to inform the transmitting entity about missing PDUs at the receiving entity;

by the receiving entity to inform the transmitting entity about the size of the allowed transmission window;

by the transmitting entity to request the receiving entity to move the receiving window.

D/C

PDU Type

SUFI

SUFI 1

_ _ _ _ _ _ _

SUFI k

PADDING

NOTE: Status PDUs are octet aligned i.e. their length must be multiple of 8 bits.

Status PDU Parameters

D/C

This one bit field tells if the PDU is a Status PDU or AM Data PDU.

If D/C = 1, then the PDU is AM data PDU
If D/C = 0, then PDU is a Status PDU

PDU Type

The PDU type field indicates the type of Control PDU.

Bit	PDU Type
000	Status PDU
001	Reset PDU
010	Reset ACK
011 – 111	Reserved

SUFI: Super Field

Super-Field indicates which AMD PDUs are received correctly and which are missing.

SUFI has three sub-fields:

Type
Length
Value

Type field is 4 bits long and may have one of the following values:

Super-Field indicates which AMD PDUs are received correctly and which are missing.

SUFi has three sub-fields:

Type
Length
Value

Bits

Description

0000

No more data (NO_MORE)

0001

Window Size (WINDOW)

0010

Acknowledgement (ACK)

0011

List (LIST)

0100

Bitmap (BITMAP)

0101

Relative list (Rlist)

0110

Move Receiving Window (MRW)

0111

Move Receiving Window Acknowledgement (MRW_ACK)

1000

Poll (POLL)

1001-1111

Reserved

No more data SUFI

No more data SUFI indicates the end of a Status PDU. Everything after this SUFI will be regarded as padding and will be discarded.

NO_MORE SUFI is always the last SUFI if it is included in a STATUS PDU.

Acknowledgement Super Field

The ‘Acknowledgement’ super-field consists of a type identifier field (ACK) and a sequence number (LSN).
Acknowledges the reception of all AMD PDUs with "Sequence Number" < LSN (Last Sequence Number) that are not indicated to be erroneous in earlier parts of the STATUS PDU.
LSN is of 12 bits.
SUFI ACK is always the last SUFI if it is included in a Status PDU. So SIFI NO_MORE and SUFI ACK can not be included in the same Status PDU.

Example

Padding

Explanation

Octet 1:

0: D/C: Data or Control. As it is a Control PDU, this bit is set to 0.

000: Control PDU Type: It is a STATUS PDU, so 000.

0010: SUFI Type. 0010 means SUFI ACK

000000000100: LSN, Last Sequence Number: 4 (100)

LSN is encoded as 4, this means all PDUs with Sequence Number less than 4 are correctly received.

In this example PDUs with Sequence Number 0, 1, 2, 3 are correctly received.

Padding: The rest part of the Control PDU is padding.

NOTE: Other RLC SUFIs will be described in separate tutorials.

Reference

Radio Link Control (RLC) protocol specification: 3GPP TS 25.322

UMTS: RLC Length Indicator (RLC LI)

Prashant Panigrahi — Mon, 07 Sep 2009 11:58:03 +0000

The Length Indicator is used to indicate, each time, the end of an SDU occurs in the PDU. The Length Indicator points out the number of octets between the end of the last Length Indicator field and up to and including the octet at the end of an SDU segment. Length Indicators are included in the PDUs that they refer to. The size of the Length Indicator may be either 7 bits or 15 bits. A Length Indicator group is a set of Length Indicators that refer to a PDU. If there can be more than one Length Indicator, each specifying the end of an SDU in a PDU, the order of these Length Indicators must be in the same order as the SDUs that they refer to. In the case where the end of the last segment of an SDU exactly ends at the end of a PDU and there is no LI that indicates the end of the SDU, the next Length Indicator, shall be placed as the first Length Indicator in the following PDU and have value LI=0. In case this SDU was the last one to be transmitted, a PDU consisting of an RLC Header with LI=0 followed by a padding Length Indicator and padding may be transmitted. If a 7-bit Length Indicator is used for the following PDU then the LI with value LI=0000000 shall be placed as the first Length indicator and its SN shall be incremented by 2 before it is transmitted (this can only occur in UM). The LI may be represented in either 7-bits or 15 bits.

For AM Mode:

If AMD PDU Size is <= 126 octets then 7-bits LI be used. If AMD PDU Size is > 126 octets then 15-bits LI be used.

For UM Mode:

If UMD PDU Size is <= 125 octets then 7-bits LI be used. If UMD PDU Size is > 125 octets then 15-bits LI be used

Length Indicator(7 bits) Decimal Description

0	0	0	0	0	0	0	0	The previous RLC PDU was exactly filled with the last segment of an RLC SDU and there is no LI that indicates the end of the SDU in the previous RLC PDU.
1	1	1	1	1	0	0	124	UMD PDU: The first data octet in this RLC PDU is the first octet of an RLC SDU. AMD PDU: Reserved (PDUs with this coding will be discarded by this version of the protocol).
1	1	1	1	1	0	1	125	Reserved (PDUs with this coding will be discarded by this version of the protocol).
1	1	1	1	1	1	0	126	AMD PDU: The rest of the RLC PDU includes a piggybacked STATUS PDU. UMD PDU: Reserved (PDUs with this coding will be discarded by this version of the protocol).
1	1	1	1	1	1	1	127	The rest of the RLC PDU is padding. The padding length can be zero.

RLC LI Encoding In UM Mode

Assumptions

RLC PDU Size = 20 Octets.
Sequence No (7 Bits)
Extension (1 Bit)
LI (7 Bits)

SDU Data (in Hex): 01 02 03 04 05 Length Of SDU = 5 Octets

Encoded RLC PDU

Oct No	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20
RLC PDU	01	F9	0B	FE	01	02	03	04	05	00	00	00	00	00	00	00	00	00	00	00

Explanation

0	0	0	0	0	0	0	1	Seq No + Extn Bit
1	1	1	1	1	0	0	1	LI + Extn Bit
0	0	0	0	1	0	1	1	LI + Extn Bit
1	1	1	1	1	1	1	0	LI + Extn Bit

SDU From Upper Layer

Padding: Octet#10 to Octet#20

Padding to fill the PDU

RLC Header: The first 4 octets (indicated by blue) in the above PDU are RLC headers.

01: 0000 0001 :Sequence No – 0, Extension –1 (i.e. Next Octet contains a LI)

F9: 1111 1001 : LI = 124, Extension –1 (i.e. Next Octet contains a LI)

0B: 0000 1011 : LI = 5 (Length of the SDU), Extension – 1(i.e. Next Octet contains a LI)

FE: 1111 1110 : LI = 127 Extension –0 (i.e. Next Octet contains Data)

Data: Octet Numbers from 5 to 9 are the data octets containing SDU data.

Filler/Padding: Octet Numbers from 10 to 20 are the filler octets.

RLC LI Encoding In AM Mode

Assumptions

RLC PDU Size = 20 Octets.
D/C (1 bit) (1: Data, 0: Control)
Sequence No (12 Bits)
Polling bit (1 Bit) (1: Status Required)
Header Extension (2 Bits) (00: Data Follows, 01 LI follows)
LI (7 Bits)
Extension (1 Bit)

SDU Data (in Hex): 01 02 03 04 05 Length of SDU = 5 Octets

Oct No	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20
RLC PDU	80	01	0B	FE	01	02	03	04	05	00	00	00	00	00	00	00	00	00	00	00

1	0	0	0	0	0	0	0	D/C + Seq Part
0	0	0	0	0	0	0	1	Seq Part + P + HE
0	0	0	0	1	0	1	1	LI + Extn Bit
1	1	1	1	1	1	1	0	LI + Extn Bit

SDU From Upper Layer

Padding: Octet#10 to Octet#20

Padding to fill the PDU

RLC Header: The first 4 octets (indicated by blue) in the above PDU are RLC headers.

80: 1000 0000 01: 0000 0001: 01: D/C –1 Sequence No – 0, Polling – 0,HE–01 (i.e. Next Octet contains a LI)

0B: 0000 1011 : LI = 5 (Length Of A SDU), Extension – 1(i.e. Next Octet contains a LI)

FE: 1111 1110 : LI = 127, Extension –0 (i.e. Next Octet contains Data)

Data: Octet No 5 – 9 are the data octets containing SDU data.

Filler: Octet No 10 – 20 are the filler octets.

Reference

Radio Link Control (RLC) protocol specification: 3GPP TS 25.322

UMTS Logical Channels and Transport Channels

Prashant Panigrahi — Tue, 25 Aug 2009 09:56:29 +0000

Logical channels define ‘WHAT’ type of information is being transferred and transport channel defines ‘HOW’ the information is being transferred.

Logical Channels

Logical channels reside between Radio Link Control (RLC) and Medium Access Control (MAC) layer. There are broadly two categories of logical channels available.

Control Channels
Traffic Channels

Control Channels

Control channels are used to carry control plane information e.g. information from Radio Resource Control (RRC) Protocol.

Types of control channels

Broadcast Control Channel (BCCH)
Paging Control Channel
Dedicated Control Channel
Common Control Channel
Shared Channel Control Channel

Broadcast Control Channel

BCCH is a downlink channel and are used for broadcasting system information.

Paging Control Channel

PCCH is a downlink channel. This is used for carrying downlink paging information from UTRAN and Core Network.

Dedicated Control Channel

DCCH is a point to point bi-directional logical channel used to transmit dedicated control information between network and UE. This channel is commonly established through RRC connection establishment procedure.

Common Control Channel

CCCH is a bi-directional channel used to transfer control information between the UE and the network. CCCH is used when UEs have no RRC connection available.

Shared Control Channel

Bi-directional channel that transmits control information for uplink and downlink shared channels between network and UEs. This channel is for TDD only.

MBMS point-to-multipoint Control Channel (MCCH)

A point-to-multipoint downlink channel used for transmitting control information from the network to the UE. This channel is only used by UEs that receive MBMS.

MBMS point-to-multipoint Scheduling Channel (MSCH)

A point-to-multipoint downlink channel used for transmitting scheduling control information, from the network to the UE, for one or several MTCHs carried on a CCTrCH. This channel is only used by UEs that receive MBMS.

Traffic Channels

Dedicated Traffic Channel

DTCH is a point to pint bi-directional channel dedicated to one UE, for transfer of user information.

Common Traffic Channel

A point to multipoint unidirectional channel to carry user information for all or a group of specified UEs.

MBMS point-to-multipoint Traffic Channel (MTCH)

A point-to-multipoint downlink channel used for transmitting traffic data from the network to the UE. This channel is only used for MBMS.

Transport Channels

There are broadly two types of transport channels available.

Common Transport Channel
Dedicated Transport Channel

Common Transport Channel

Random Access Channel (RACH)

A contention based uplink channel used for transmission of relatively small amounts of data, e.g. for initial access or non-real-time dedicated control or traffic data.

Forward Access Channel (FACH)

Common downlink channel without closed-loop power control used for transmission of relatively small amount of data. In addition FACH is used to carry broadcast and multicast data.

Downlink Shared Channel (DSCH)

A downlink channel shared by several UEs carrying dedicated control or traffic data, used in TDD mode only.

Uplink Shared Channel (USCH)

An uplink channel shared by several UEs carrying dedicated control or traffic data, used in TDD mode only.

Broadcast Channel (BCH)

A downlink channel used for broadcast of system information into an entire cell.

Paging Channel (PCH)

A downlink channel used for broadcast of control information into an entire cell allowing efficient UE sleep mode procedures. Currently identified information types are paging and notification. Another use could be UTRAN notification of change of BCCH information.

High Speed Downlink Shared Channel (HS-DSCH)

A downlink channel shared between UEs by allocation of individual codes, from a common pool of codes assigned for the channel.

Dedicated Transport Channel

Dedicated Channel (DCH)

A channel dedicated to one UE used in uplink or downlink.

Enhanced Dedicated Channel (E-DCH)

A channel dedicated to one UE used in uplink only. The E-DCH is subject to Node-B controlled scheduling and HARQ.

Logical Channels and Transport Channels mapping

Mapping in Uplink

NOTE: The color green indicates a logical channel can be mapped on a transport channel.

Mapping in Downlink

NOTE: The color green indicates a logical channel can be mapped on a transport channel.

UMTS: Radio Link Protocol (RLC) Overview 25.322

3gLteInfo — Fri, 21 Aug 2009 09:42:55 +0000

Radio Interface Architecture

Why RLC is required?

Larger pieces of data are not suitable to be sent over the air interface where bit faults are common.
Smaller pieces can be individually retransmitted
Retransmissions on higher Protocol level take too long time. Therefore it is better to have the retransmission as close to the biggest trouble source (i.e. The radio interface)

RLC main functionalities

Segmentation and reassembly.
Concatenation.
Padding.
Transfer of user data.
Error correction.
In-sequence delivery of upper layer PDUs.
Duplicate detection.
Flow control.
Sequence number check.
Protocol error detection and recovery.
Ciphering.
SDU discard.
Out of sequence SDU delivery.
Duplicate avoidance and reordering.

Data flow between layers

Data flow for transparent RLC

Data flow for non-transparent RLC

Model of RLC Sublayer

TM (Transparent mode)
UM (Unacknowledged mode)
AM (Acknowledged mode

Transparent Mode (TM) RLC

Services provided to upper layer

Segmentation and reassembly
Transfer of user data
SDU discard

If segmentation is configured by upper layers and a RLC SDU is larger than the TMD PDU size, the transmitting TM RLC entity segments RLC SDUs to fit the TMD PDU size without adding RLC headers.

All the TMD PDUs carrying one RLC SDU are sent in the same TTI and no segment from another RLC SDU are sent in that TTI.

Unacknowledged Mode (UM) RLC Entity

Services provided to upper layer

Segmentation and reassembly.
Concatenation.
Padding.
Transfer of user data.
Ciphering.
Sequence number check.
SDU discard.

Acknowledged Mode RLC Entity

Services provided to upper layer

Segmentation and reassembly.
Concatenation.
Padding.
Transfer of user data.
Error correction.
In-sequence delivery of upper layer PDUs.
Duplicate detection.
Flow Control.
Protocol error detection and recovery.
Ciphering.
SDU discard.

RLC Error Correction

RLC Protocol Data Unit

Data PDUs

TMD PDU (Transparent Mode Data PDU)
UMD PDU (Unacknowledged Mode Data PDU)
AMD PDU (Acknowledged Mode Data PDU)

Control PDUs

Status PDU and Piggybacked STATUS PDU
Reset PDU
Reset-ACK PDU

TMD PDU (Transparent Mode Data PDU)

The TMD PDU is used to transfer user data when RLC is operating in transparent mode.
No overhead is added to the SDU by RLC.
The data length is not constrained to be a multiple of 8 bits.

UMD PDU (Unacknowledged Mode Data PDU)

The UMD PDU is used to transfer user data when RLC is operating in unacknowledged mode.
The length of the data part shall be a multiple of 8 bits.

UMD PDU Header Details

Sequence Number

Sequence number of UMD PDU encoded in binary.
SN is of length 7 bits
It is used for reassembly

Length Indicator

LI is used to indicate the end of a SDU in a PDU.
Lenth is 7 or 15 bits

E (Extension Bit)

E bit tells ”What there in the next field”

If E = 0 : Next field is data or status PDU or a complete SDU
If E 0 1 : Next filed is Length Indicator (LI) followed by extension bit (E).

AMD PDU (Acknowledged Mode Data PDU)

The length of the data part shall be a multiple of 8 bits.
The AMD PDU header consists of the first two octets, which contain the "Sequence Number".

AMD PDU Header Details

D/C

Indicates whether a data or control PDU

If D/C = 1 : Its a data PDU
If D/C = 0 : Its a control PDU

Sequence Number

Length of sequence number is 12 bits i.e after SN reaches 4095 there will be a rollover.
SN is used for retransmission and reassembly

P bit

Polling bit is used to request a status report from the receiver.

If P = 0 : No status requested
If P = 1 : Status requested

Header Extension is of 2 bits and it indicates the next bit is data or ”Length Indicator” and E bit.

If HE = 00 : Next octet is data
If HE = 01 : Next octet is LI and E bit
If HE = 10 : Next value is the data and last octet of the PDU is the last octet of the SDU.
If HE = 11 : Reserved, discarded by protocol

Status PDU

The length of the STATUS PDU shall be a multiple of 8 bits.
Status PDU is used for transmission of status information.

Status PDU Header Details

PDU Type

PDU type indicates the Control PDU type

000 : Status PDU
001 : Reset PDU
010 : Reset-Ack PDU
011 – 111 : Reserved

SUFI

Super-Field indicates which AMD PDUs are received correctly and which are missing.

SUFi has three sub-fields:

Type
Length
Value

Reset and Reset-Ack PDU

RESET PDU

The RESET PDU is used in acknowledged mode to reset all protocol states, protocol variables and protocol timers of the peer RLC entity in order to synchronies the two peer entities.

RESET ACK PDU

The RESET ACK PDU is an acknowledgement to the RESET PDU.

Reset/Reset-Ack PDU Header

RSN

Reset Sequence Number is of 1 bit length.
RSN is the sequence number of the transmitted RESET PDU.
Initial value of this field is 0.

This field is used to make RESET/RESET-ACK PDU octet aligned.
The value of R1 is 000.

HFNI

Hyper Frame Number Indicator is of 2o bits.
It is used to indicate the HFN to the peer entity.
With the help of this HFN in UE and UTRAN can be synchronised.

RLC State Model

RLC TM State Model

RLC UM State Model

RLC AM State Model

Reference

Radio Link Control (RLC) protocol specification: 3GPP TS 25.322