UMTS RLC Status PDU: SUFI RLIST

Posted on September 23, 2009 by Prashant Panigrahi

Catch Up

You may need the following tutorial:

UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK
UMTS RLC Status PDU: SUFI LIST

RLIST (Relative- List) Super field

The SUFI RLIST consists of the following fields:

Type identifier field(RLIST)
LENGTH Filed
First Sequence Number(FSN)<7li>
Code Words (CW1, CW2, …, CWLENGTH )

The SUFI RLIST fields in the STATUS PDU are as follows:

Type = RLIST

LENGTH

FSN

CW-1

CW-2

—–

CW-1

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:

X1X2X30	When the last bit is 0, it signifies that the CW continues in next CW. The most significant bit is X1 within the codeword.
X1X2X31	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 CW2 and CW3 will be as follows:

CW2 = 0001 (Special error bust indicator is encoded here while the next CW will signify the length of the error burst)

CW3 = 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)

Step #5
The encoding of the SUFI RLIST as follows:

0	0	1	1	0	0	0	0
0	0	0	0	0	0	1	1
0	1	0	1	0	0	0	1
1	0	1	1

LENGTH

FSN

CW-1

CW-2

CW-3

Reference

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

UMTS RLC Status PDU: SUFI LIST

Posted on September 21, 2009 by Prashant Panigrahi

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.

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

Type = LIST

LENGTH

SN-1

L-1

SN-2

L-2

—–

SN-Length

L-Length

Example

clip_image001

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

0	0	0	1	1
1	0	0	0	0
0	0	1	0	0
1

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
WCDMA Design Handbook
UMTS Signaling: UMTS Interfaces, Protocols, Message Flows and Procedures Analyzed and Explained

UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK

Posted on September 21, 2009 by Prashant Panigrahi

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

0	0	0	1	0
0	0	0	0	0
1

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

Octet 2 & 3:
000000000100: LSN, Last Sequence Number: 4

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
WCDMA Design Handbook
UMTS Signaling: UMTS Interfaces, Protocols, Message Flows and Procedures Analyzed and Explained

SRNS Relocation in UMTS Network

Posted on September 17, 2009 by Naveed Mumtaz

SRNS relocation is a procedure used during mobility scenarios when Control of the Serving Radio Network Subsystem (SRNS) is changed to another Radio Network Subsystem (RNS)

Radio Network Subsystem (RNS): The RNS controls the allocation and release of radio resources to establish a connection between a UE and the UTRAN.

A single UE may be associated with one or more Radio Access Bearers (RABs). For instance a UE may simultaneously use one RAB for voice and one RAB for a packet call.

Radio Access Bearer (RAB): RAB is a logical connection between the UE and the UMSC/SGSN.

Iu Bearer: The connection between the RNC and the Core network is referred to as the Iu bearer.

Radio Bearer (RB): The connection between the RNC and the UE is referred to as the Radio Bearer (RB).

During Hard Handover when the UE moves away from the area that is covered by one RNS to a new RNS, there is a requirement to perform an inter-RNC handover between the Serving RNC (S-RNC) to the Target RNC (RNC_T) of the new RNS.

There are two ways to change the Serving RNC:

One possibility is that the Target RNC may immediately become the Serving RNC referred as the Combined Hard Handover and SRNS Relocation Procedure

In the other case known as the Serving RNS Relocation Procedure the user plane from the S-RNC extends to the Target RNC, in this situation the Target RNC is referred as the Drift RNC. The Interface between the Serving and the Drift RNC is the Iur interface described in the 3GPP TS 25.420.

NOTE: In either case the Serving RNC initiates the SRNS relocation procedure.

Relocation Procedure

RELOCATION REQUIRED	RELOCATION REQUEST
Information Element	Information Element
Message Type Relocation Type UE involved/UE not involved Cause Source ID Target ID Source RNC to Target RNC transparent Container	Message Type Relocation Type UE involved/UE not involved Cause Source RNC to Target RNC transparent Container
	RAB to be Setup
	RAB ID RAB Parameters User Plane Mode Transport Address Iu Transport Association RAB linking

Serving RNS Relocation Procedure

This procedure is only performed for a UE in CONNECTED state where the Iur interface carries both the control signaling and the user data.

The Serving SRNS Relocation procedure is used to move the connection between the RAN and the CN for the source SRNC to the RAN for the target RNC, from a "standing still position". In the procedure, the Iu links are relocated.

If the target RNC is connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is performed.

If the routing area is changed, this procedure is followed by an Intra-SGSN Routing Area Update procedure. The SGSN detects an Intra-SGSN routing area update by noticing that it also handles the old RA. In this case, the SGSN has the necessary information about the UE and there is no need to inform the HLR about new location of the UE.

Before the SRNS Relocation procedure and RA update, the UE is registered in the old SGSN. The source RNC is acting as a serving RNC (SRNC).

Serving SRNS Relocation procedure Signalling

NOTE: The sequence is valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation.

After the SRNS Relocation procedure and RA update, the UE is registered in the new SGSN. The UE is in the state CONNECTED Mode towards the new SGSN, and the target RNC is acting as the serving RNC.

Combined Hard Handover and SRNS Relocation Procedure

This procedure is only performed for an UE in CONNECTED state in case the Iur interface is not available.

The Combined Hard Handover and SRNS Relocation procedure is used to move the connection between the RAN and the CN for the source SRNC to the RAN for the target RNC, while performing a hard handover decided by the RAN.

In the procedure, the Iu links are relocated.

If the target RNC is connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is performed.

If the routing area is changed, this procedure is followed by an Intra-SGSN Routing Area Update procedure. The SGSN detects that it is an intra-SGSN routing area update by noticing that it also handles the old RA. In this case, the SGSN has the necessary information about the UE and there is no need to inform the HLR about the new UE location.

If the target RNC is connected to a different SGSN than the source SRNC, an Inter-SGSN SRNS Relocation procedure is performed. This procedure is followed by an Inter-SGSN Routing Area Update procedure.

Before the SRNS Relocation and Routing Area Update the UE is registered in the old SGSN and in the old MSC/VLR. The source RNC is acting as serving RNC.

Combined Hard Handover and SRNS Relocation Procedure Signalling

The sequence is valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation. Furthermore, this signaling flow is also applicable for BSS to RNS relocation and vice-versa, as well as BSS to BSS relocation.

After the SRNS relocation and RA update, the UE is registered in the new SGSN and in the new MSC/VLR. The UE is in CONNECTED mode towards the new SGSN and in MM IDLE state towards the new MSC/VLR. The target RNC is acting as serving RNC.

References:

UTRAN Iu interface RANAP signalling: 3GPP TS 25.413
General Packet Radio Service (GPRS);Service description;Stage 2: 3GPP TS 23.060
SRNS relocation in a UMTS network: Patent US 6,807,419

UMTS Security: Entity Authentication

Posted on September 15, 2009 by Prashant Panigrahi

Entity authentication is the procedure of mutual authentication of UE or USIM and the network. There are few fundamental requirements for this procedure:

First to permit the network to check whether the identity provided by the mobile station is acceptable or not;
Second to provide parameters enabling the mobile station to calculate a new UMTS ciphering key;
Third to provide parameters enabling the mobile station to calculate a new UMTS integrity key;
Fourth to permit the mobile station to authenticate the network.

Authentication Vectors

The Authentication Vectors are used in Entity Authentication and Security procedures.

The VLR/SGSN starts this procedure by requesting authentication vector to the HE/AuC.

When HE/AuC receives the request from the VLR/SGSN it retrieves the calculated authentication vectors AV (1…n) from the HLR database and sends it to the VLR/SGSN in Authentication data response.

The Authentication Vectors generation procedure in HE/AuC is as follows:

HE/AuC first generates a fresh sequence number SQN and an unpredictable challenge RAND.

After that the following will be calculated:

Message Authentication Code MAC = f1K (SQN || RAND || AMF), f1 is the message authentication function.

Expected response XRES = f2K (RAND)

Cipher key CK = f3K (RAND), f3 is a key generating function

Integrity key IK = f4K (RAND), f4 is a key generating function.

Anonymity key AK = f5K (RAND)

Authentication Procedure

The authentication procedure is as follows:

The steps are as follows:

Step#1

In the beginning both the USIM and the Network are not authenticated. That means USIM does not know whether the network is a real network and network does not know whether the USIM is a valid Subscriber.

Step#2

Network starts the authentication procedure by sending the User Authentication Request with the parameter RAND and AUTN.

Step#3

After UE receives RAND and AUTN, the USIM first computes the anonymity key AK = f5K (RAND) and retrieves the SQN = (SQN clip_image007 AK) clip_image007[1] AK

After that UE computes XMAC = f1K (SQN || RAND || AMF) and compares with MAC.

If both are different UE send user authentication reject back to the VLR/SGSN.

If the USIM finds the SQN is not in the correct range, it sends synchronization failure.

Step#4

UE sends expected response RES to the VLR/SGSN.

If RES = XRES, then the authentication procedure completes

Message sequence from UE point of view

[UE <-- NW] DOWNLINK DIRECT TRANSFER (IDENTITY REQUEST)

[UE --> NW] UPLINK DIRECT TRANSFER (IDENTITY RESPONSE)

[UE <-- NW] DOWNLINK DIRECT TRANSFER (AUTHENTICATION REQUEST)

[UE --> NW] UPLINK DIRECT TRANSFER (AUTHENTICATION RESPONSE)

[UE <-- NW] SECURITY MODE COMMAND

[UE --> NW] SECURITY MODE COMPLETE

References

3G Security: Security architecture: 3GPP TS 33.102

MAC PDU Structure for non-HSPA Transport Channels

Posted on September 10, 2009 by Prashant Panigrahi

This tutorial describes about the MAC PDU structure when HS-DSCH and E-DCH transport channel are not used. MAC PDUs are also called the MAC Transport Blocks (TB). MAC PDU is a bit string. The MAC PDU is consists of the MAC header and the MAC SDU (RLC PDU) The MAC header size and content depends on the type of logical channel used. The structure of the MAC PDU is as follows.

NOTE: The MAC header may have none of the parameters in some cases.

MAC PDU Header Parameters

TCTF: Target Channel Type Field

TCTF field tells the type of logical channel mapped on a Transport Channel. The following combinations can be possible:

Transport Channel: FACH

For FDD Mode:

TCTF	Designation
00	BCCH
01000000	CCCH
01000001-01001111	Reserved
01010000	MCCH
01010001-01011110	Reserved
01011111	MSCH
0110	MTCH
0111	Reserved
10000000	CTCH
10000001-10111111	Reserved
11	DCCH or DTCH over FACH

For TDD Mode

TCTF	Designation
000	BCCH
001	CCCH
010	CTCH
01100	DCCH or DTCH over FACH
01101	MCCH
01110	MTCH
01111	MSCH
100	SHCCH
101-111	Reserved

Transport Channel: RACH

Fore FDD Mode

TCTF	Designation
00	CCCH
01	DCCH or DTCH over RACH
10-11	Reserved

For TDD Mode

TCTF	Designation
00	CCCH
0100	DCCH or DTCH Over RACH
0101 – 0111	Reserved
10	SHCCH
11	Reserved

Transport Channel: USCH or DSCH (Only in TDD Mode)

TCTF	Designation
0	SHCCH
1	DCCH or DTCH over USCH or DSCH

C/T Field

The C/T field is used to identify the logical channel when multiple logical channels are mapped on the same transport channel. Example: In case of SRB (Signalling Radio Bearer), four SRBs are mapped on the same transport channel. C/T is 4 bit long.

C/T field	Designation
0000	Logical channel 1
0001	Logical channel 2
…	…
1110	Logical channel 15
1111	Reserved

UE-Id

UE-Id is used to identify a UE on common transport channel. There are mainly two types of identifiers are used:

U-RNTI: UTRAN Radio Network Temporary Identity

U-RNTI is always used in the downlink. The length of the U-RNTI is 32 bits. The U-RNTI is normally associated with connection to a Serving RNC (SRNC).

C-RNTI: Cell Radio Network Temporary Identity

The C-RNTI is used on DCCH or DTCH on uplink and may be used on DCCH on downlink. The length of the C-RNTI is 16 bits. The C-RNTI is normally associated with connection to a controlling RNC (CRNC).

UE-Id Type

The UE-Id type is used to ensure the correct decoding of the UE-Id field in the MAC header.

UE-Id Type field 2 bits	UE-Id Type
00	U-RNTI
01	C-RNTI
10	Reserved
11	Reserved

MBMS-Id

MBMS-Id is used to identify the MTCH for an MBMS service on FACH. MBMS-Id is always used on downlink.

MBMS-Id field	MBMS logical channel identity [7]
0000	1
0001	2
…	…
1110	15
1111	Reserved

Example

In case of Signalling Radio Bearer (SRB), four DCCH logical channels are multiplexed on one DCH transport channel. For SRBs the RLC PDU size is 144 bits.

MAC PDU

C/T

RLC PDU

C/T field can have the value from 0000 to 0011.

References

Medium Access Control (MAC) protocol specification: 3GPP TS 25.321

UMTS: RLC Length Indicator (RLC LI)

Posted on September 7, 2009 by Prashant Panigrahi

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