02 CT82352EN01GLA1 Air Interface Protocols

CT82352EN01GLA1 ©2014 Nokia Solutions and Networks. All rights reserved.

Air Interface Protocols

LTE Air Interface Course

2 CT82352EN01GLA1 ©2014 Nokia Solutions and Networks. All rights reserved.

Nokia Solutions and Networks Academy

Legal notice

Intellectual Property Rights

All copyrights and intellectual property rights for Nokia Solutions and Networks training documentation, product documentation and slide presentation material, all of which are forthwith known as Nokia Solutions and Networks training material, are the exclusive property of Nokia Solutions and Networks. Nokia Solutions and Networks owns the rights to copying, modification, translation, adaptation or derivatives including any improvements or developments. Nokia Solutions and Networks has the sole right to copy, distribute, amend, modify, develop, license, sublicense, sell, transfer and assign the Nokia Solutions and Networks training material. Individuals can use the Nokia Solutions and Networks training material for their own personal self-development only, those same individuals cannot subsequently pass on that same Intellectual Property to others without the prior written agreement of Nokia Solutions and Networks. The Nokia Solutions and Networks training material cannot be used outside of an agreed Nokia Solutions and Networks training session for development of groups without the prior written agreement of Nokia Solutions and Networks.


At the end of this module, you will be able to:

• Explain the protocol stack of the LTE air interface

• Name the functionalities of the single layers of the radio protocol

architecture

• Discuss the layer 2 data flow

• Give an example for the air interface protocols configuration

Module Objectives



Radio Protocols Architecture

RRC Tasks and States

Layer 2 Functions and Data Flow

Protocols Configuration Example



MAC

RLC

PDCP

Physical Layer

RRC

L

1

L

2

L

3

Radio Bearer

Logical Channel

Transport Channels

Control Plane User Plane

Physical Channels


Radio Protocols Architecture, cont.

The EUTRAN radio protocol model specifies the protocols terminated between UE and eNB. The protocol stack

follows the standard guidelines for radio protocol architectures (ITU-R M1035) and is thus quite similar to the

WCDMA protocol stack of UMTS.

The protocol stack defines three layers: the physical layer (layer 1), data link and access layer (layer 2) and

layer 3 hosting the access stratum and non-access stratum control protocols as well as the application level

software (e.g. IP stack).

physical layer: The physical layer forms the complete layer 1 of the protocol stack and provides the basic bit

transmission functionality over air. In LTE the physical layer is driven by OFDMA in the downlink and SC-FDMA

in the uplink. FDD and TDD mode can be combined (depends on UE capabilities) in the same physical layer.

The physical layer uses physical channels to transmit data over the radio path. Physical channels are

dynamically mapped to the available resources (physical resource blocks and antenna ports). To higher layers

the physical layer offers its data transmission functionality via transport channels. Like in UMTS a transport

channel is a block oriented transmission service with certain characteristics regarding bit rates, delay, collision

risk and reliability. Note that in contrast to 3G WCDMA or even 2G GSM there are no dedicated transport or

physical channels anymore, as all resource mapping is dynamically driven by the scheduler.

MAC (Medium Access Control): MAC is the lowest layer 2 protocol and its main function is to drive the transport

channels. From higher layers MAC is fed with logical channels which are in one-to-one correspondence with

radio bearers. Each logical channel is given a priority and MAC has to multiplex logical channel data onto

transport channels. In the receiving direction obviously demultiplexing of logical channels from transport

channels must take place. Further functions of MAC will be collision handling and explicit UE identification. An

important function for the performance is the HARQ functionality which is official part of MAC and available for

some transport channel types.


FDD | TDD - Layer 1

( DL: OFDMA, UL: SC-FDMA )

Medium Access Control (MAC)

Physical Channels

Transport Channels

RLC

(Radio Link

Control)

…

PDCP’

(Packet Data

Convergence

Protocol)

…

RLC

(Radio Link

Control)

PDCP’

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

Logical Channel

(E-)RRC

(Radio Resource Control)

IP / TCP | UDP | …

Application Layer

Radio Bearer

ROHC (RFC 3095)

Security

Segment./Reassembly

ARQ

Scheduling /

Priority Handling

HARQ

De/Multiplexing

CRC

Coding/Rate Matching

Interleaving

Modulation

Resource Mapping/MIMO

NAS Protocol(s)

(Attach/TA Update/…)


RLC (Radio Link Control): Each radio bearer possesses one RLC instance working in either

of the three modes: UM (Unacknowledged), AM (Acknowledged) or TM (Transparent). Which

mode is chosen depends on the purpose of the radio bearer. RLC can thus enhance the radio

bearer with ARQ (Automatic Retransmission on reQuest) using sequence numbered data

frames and status reports to trigger retransmission. Note that it shall be possible to trigger

retransmissions also via the HARQ entity in MAC. The second functionality of RLC is the

segmentation and reassembly that divides higher layer data or concatenates higher layer data

into data chunks suitable for transport over transport channels which allow a certain set of

transport block sizes.

PDCP (Packet Data Convergence Protocol): Each radio bearer also uses one PDCP

instance. PDCP is responsible for header compression (ROHC RObust Header Compression;

RFC 3095) and ciphering/deciphering. Obviously header compression makes sense for IP

datagram's, but not for signaling. Thus the PDCP entities for signaling radio bearers will usually

do ciphering/deciphering only.

RRC (Radio Resource Control): RRC is the access stratum specific control protocol for

EUTRAN. It will provide the required messages for channel management, measurement

control and reporting, etc.

NAS Protocols: The NAS protocol is running between UE and MME and thus must be

transparently transferred via EUTRAN. It sits on top of RRC, which provides the required

carrier messages for NAS transfer.


NAS Protocols Transfer

MME

eNB UE MME

NAS NAS

RRC RRC

PDCP PDCP

RLC RLC

MAC MAC

PHY PHY







The RRC protocol for EUTRAN is responsible for the basic configuration of the radio protocol stack. But one should note, that some radio management

functions (scheduling, physical resource assignment for physical channels) are handled by layer 1 and layer 2 autonomously. MAC and layer 1 signaling

has usually delays that are within 10 ms, whereas RRC signaling usually takes something around 100 ms and more to complete an operation.


FDD | TDD - Layer 1



Physical Channels

Transport Channels

RLC

(Radio Link

Control)

…

PDCP’

(Packet Data

Convergence

Protocol)

…

RLC

(Radio Link

Control)

PDCP’

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

Logical Channel

(E-)RRC



Application Layer

Radio Bearer

NAS System Information (BCCH)

E-UTRAN System Info. (BCCH)

Paging (PCCH)

RRC Connection Management

Temporary Identifiers UE-EUTRAN

NAS Protocol(s)


Allocation of Sign. Radio Bearers

E-UTRAN Security

Integrity protection for RRC msg.

Mgmt. of ptp radio bearers

Mobility Functions (LTE_ACTIVE)

UE measurement reporting/control

Inter-cell handover

Control of cell (re-)selection

UE context transfer between eNB

MBMS

Notification for MBMS services

Mgmt. of MBMS radio bearers

QoS control

Transfer of NAS messages


The RRC protocol for EUTRAN is responsible for the basic configuration of the radio protocol

stack. But one should note, that some radio management functions (scheduling, physical

resource assignment for physical channels) are handled by layer 1 and layer 2 autonomously.

MAC and layer 1 signaling has usually delays that are within 10 ms, whereas RRC signaling

usually takes something around 100 ms and more to complete an operation.

The RRC functional list is of course quite long.

System Information Broadcasting: The NAS and access stratum configuration of the

network and the cell must be available to any UE camping on a cell. This information is coded

as RRC message.

Paging: To locate an LTE_IDLE UE within a tracking area the RRC protocol defines a paging

signaling message and the associated UE behavior.

RRC Connection Management: The UE can have two major radio states:

RRC_CONNECTED or RRC_IDLE. To switch between the states an RRC connection

establishment and release procedure is defined. With the state RRC_CONNECTED the

existence of signaling radio bearers and UE identifiers (C-RNTI) is associated.

EUTRAN Security: Access layer security in EUTRAN consists of ciphering (PDCP) and

integrity protection for RRC messages.

Management of Point-to-Point Radio Bearers: Point-to-point radio bearers are signaling and

user data radio bearers for SAE bearers. RRC is used to create, modify and delete such radio

bearers including the associated lower layer configuration (logical channels, RLC mode,

transport channels, multiplexing


FDD | TDD - Layer 1



Physical Channels

Transport Channels

RLC

(Radio Link

Control)

…

PDCP’

(Packet Data

Convergence

Protocol)

…

RLC

(Radio Link

Control)

PDCP’

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

RLC

(Radio Link

Control)

PDCP

(Packet Data

Convergence

Protocol)

Logical Channel

(E-)RRC



Application Layer

Radio Bearer

NAS System Information (BCCH)

E-UTRAN System Info. (BCCH)

Paging (PCCH)

RRC Connection Management

Temporary Identifiers UE-EUTRAN

NAS Protocol(s)


Allocation of Sign. Radio Bearers

E-UTRAN Security

Integrity protection for RRC msg.

Mgmt. of ptp radio bearers

Mobility Functions (LTE_ACTIVE)

UE measurement reporting/control

Inter-cell handover

Control of cell (re-)selection

UE context transfer between eNB

MBMS

Notification for MBMS services

Mgmt. of MBMS radio bearers

QoS control

Transfer of NAS messages


Mobility Functions: When a UE is in state LTE_ACTIVE, the mobility control is at the eNB.

This includes handover from one EUTRAN cell to another or also inter-system changes. To

assist handover decisions in the eNB RRC defines procedures for measurement control and

reporting. In LTE_IDLE mode the UE performs automatic cell re-selection, RRC takes control

over this process within the UE.

MBMS (Multimedia Broadcast Multicast Service): RRC is used to inform UEs about

available MBMS services in a cell and is also used to track UEs that registered for a certain

multicast service. This allows the eNB to manage MBMS radio bearers which are usually point-

to-multipoint.

QoS Control: The RRC protocol will be QoS aware, allowing implementation of radio bearers

with different QoS within the UE.

Transfer of NAS Messages: NAS messages are sent and received through the EUTRAN

protocol stack. RRC provides carrier services for such messages.


RRC States for EUTRAN

RRC_IDLE RRC_CONNECTED

• UE in DRX (NAS

configuration);

• UE receives BCCH;

• UE monitors PCH;

• Cell reselection;

• No RRC context in e-

NodeB

• UE in DRX/DTX (e-Node B

configuration);

• UE uses mainly

DCCH/DTCH;

• UL/DL data transmission

possible;

• UE monitors PDCCH to get

scheduling assignments;

• UE reports channel quality

(CQI) to e-NodeB to assist

channel dependent

scheduling;

• Neighbor cell

measurements by UE

(automatic UE detection);

• Handover;

• e-NodeB knows UE’s cell;

• RRC context in e-NodeB;

RRC Connection Establishment

(via CCCH)

RRC Connection Release

(via DL-SCH)


RRC States for EUTRAN, cont.

RRC will use one or two radio bearers exclusively used for signaling (Signaling Radio

Bearers). One will be for high, the other for low priority. The PDCP entities of these

signaling radio bearers will be used for ciphering, but not for header compression.

The RRC protocol in EUTRAN defines two state for a UE: RRC_IDLE and

RRC_CONNECTED. In the first state, the UE is not attached to a eNB and does free cell re-

selection. In the second state the UE is connected to a eNB and the eNB handles all

mobility related aspects of the UE via handovers. There is of course a close relationship

between LTE-states and RRC states








FDD | TDD - Layer 1

( … UL: SC-FDMA )

Multiplexing

HARQ

Scheduling/Priority

…

Segment-

ation

TrCH

Transport Block

(1 per TTI) TB ACK|NACK

MAC

ARQ

Segment-

ation

ARQ

Segment-

ation

ARQ

…

LogCH LogCH LogCH

RLC

Security

ROHC

Security

ROHC

Security

…

PDCP RB RB RB

Segment-

ation

ARQ

LogCH

ROHC

Security

RB

IP (user plane)

NAS

(E-)RRC

…

…


For layer 2 let us first take a look into the uplink.

Data transmission is handled through the protocol stack according to the following flow:

1. Data is generated by either signaling control protocols (RRC, NAS) or by some application on the UE’s IP

stack. An associated chunk of bits is sent to layer 2 within the appropriate radio bearer.

2. The first protocol that handles the data frame is PDCP. For IP datagrams it will compress the IP (or

IP/TCP, IP/UDP, IP/UDP/RTP) header according RFC 3095 (ROHC). Note that this is not applicable to

signaling radio bearers. The second step within PDCP is encryption of the data packet.

3. Next comes RLC. For all radio bearers the associated RLC instance has to perform segmentation or

concatenation or padding to generate bit frames (RLC PDU) that will fit into the transport channels. If the

RLC entity of a radio bearer works in acknowledged mode (AM), then the data is sent through the ARQ

function, which will buffer the packet in a retransmission buffer until the frame has been positively

acknowledged. If the RLC entity is not in acknowledged mode, this step is obviously skipped.

4. RLC PDUs from all logical channels arrive then at the MAC protocol. Here the UE’s uplink scheduler has

to decide, which logical channel will be served and multiplexed onto a transport channel. It is possible to

combine several data units from different logical channels in one transport block, a multiplexer handles

this.

5. The lower part of the MAC entity is the HARQ (Hybrid Automatic Retransmission on reQuest) entity. Note

that only certain transport channel types (UL-SCH) can have this unit. Here the assembled transport block

from the multiplexer will be stored in one of the HARQ’s buffers and simultaneously sent to the physical

layer. If the eNB receives the transport block correctly, it will send an ACK indication via a special physical

channel. This would delete the transport channel from the buffer. If no indication or a NACK indication is

received, the HARQ entity will retransmit the transport block. Each retransmission can be done with

different encoding in the physical layer. Therefore MAC will tell the physical layer, whether a transport

block is new or is the nth retransmission.

6. The physical layer takes the transport block and encodes it for transmission on air.


FDD | TDD - Layer 1

( … DL: OFDMA )

Multiplexing UE#1

HARQ

Scheduling/Priority

…

Segment-

ation

TrCH

TB Transport Block(s) TB

AC

K|N

AC

K

MAC

ARQ

Segment-

ation

ARQ

…

LogCH LogCH

RLC

Security

ROHC

Security …

PDCP RB RB

IP (user plane)

NAS

(E-)RRC

…

…

…

…

UE #1

Multiplexing UE#N

HARQ

Segment-

ation

TrCH

TB Transport Block(s) TB

AC

K|N

AC

K

ARQ

Segment-

ation

ARQ

LogCH LogCH

RLC

Security

ROHC

Security …

PDCP RB RB

IP (user plane)

NAS

(E-)RRC

…

…

…

UE #N

PCCH

(Paging)

BCCH

(SysInfo)

PCH BCH

(E-)RRC


DL Data Flow:

Of course the eNB has to process the radio bearers of several UE.

Thus the scheduler in the eNB has to balance the traffic between different users. This is done by taking each

radio bearer as individual quality of service instance into account.

Furthermore the MAC layer supports mapping of several logical channels to the transport channel.

RNTI types are defined to handle the mapping of the different types of logical channels.

• C-RNTIs for DCCH and DTCH;

• C-RNTI

• Temporary C-RNTI

• Semi-persistent C-RNTI

• P-RNTI for PCCH;

• RA-RNTI for Random Access Response on DL-SCH;

• Temporary C-RNTI for CCCH during the random access procedure;

• SI-RNTI for BCCH.

I.e. the MAC scheduling via PDCCH is performed by using the appropriate RNTI.

A MAC PDU consist of a MAC header and there might be MAC control elements, MAC SDUs and Padding.

The header itself is made of subheaders.

The subheader consists of various fields:

R: Reserved bit

LCID: Logical Channel ID

E: Extension bit tells if more subheader will follow

F: Indicates the length of the length field (7 or 15 bit)

L: Length field gives the length of the corresponding MAC SDU or control element in byte


Index to LCID values relation for UL-SCH.

Index LCID values

00000 CCCH

00001-01010 Identity of the logical channel

01011-11011 Reserved

11010 Power headroom report

11011 C-RNTI

11100 Truncated BSR

11101 Short BSR

11110 Long BSR

11111 Padding


Index to LCID values relation for UL-SCH, cont.

MAC maps different logical channels and signaling data to the UL-SCH.

This is done on basis of an LCID for UL-SCH:

The transmission path through layer 2 for downlink is similar to that of the uplink direction.

Of course the eNB has to process the radio bearers of several UE.

Thus the scheduler in the eNB has to balance the traffic between different users. This is done by taking each radio bearer as individual quality of service instance into account.


Index to LCID values relation for DL-SCH.

Index LCID values

00000 CCCH

00001-01010 Identity of the logical channel

01011-11011 Reserved

11100 UE Contention Resolution Identity

11101 Timing Advance

11110 DRX Command

11111 Padding


Index to LCID values relation for DL-SCH, cont. Furthermore the MAC layer supports mapping of several logical channels to the transport channel.

RNTI types are defined to handle the mapping of the different types of logical channels.

• C-RNTIs for DCCH and DTCH;

• C-RNTI

• Temporary C-RNTI

• Semi-persistant C-RNTI

• P-RNTI for PCCH;

• RA-RNTI for Random Access Response on DL-SCH;

• Temporary C-RNTI for CCCH during the random access procedure;

• SI-RNTI for BCCH.

I.e. the MAC scheduling via PDCCH is performed by using the appropriate RNTI.

A MAC PDU consist of a MAC header and there might be MAC control elements, MAC SDUs and Padding. The header itself is made of subheaders.

The subheader consists of various fields:

R: Reserved bit

LCID: Logical Channel ID

E: Extension bit tells if more subheader will follow

F: Indicates the length of the length field (7 or 15 bit)

L: Length field gives the length of the corresponding MAC SDU or control element in byte


Structure of the MAC PDU

MAC Control

element 1...

R/R/E/LCID

sub-header

MAC header

MAC payload

R/R/E/LCID[/F/L]

sub-header

R/R/E/LCID/F/L

sub-header

R/R/E/LCID/F/L

sub-header... R/R/E/LCID/F/L

sub-header

R/R/E/LCID padding

sub-header

MAC Control

element 2MAC SDU MAC SDU

Padding

(opt)

LCIDR

F L

R/R/E/LCID/F/L sub-header with

7-bits L field

R/R/E/LCID/F/L sub-header with

15-bits L field

R E LCIDR

F L

R E

L

Oct 1

Oct 2

Oct 1

Oct 2

Oct 3

LCIDR

R/R/E/LCID sub-header

R E Oct 1








Protocols Configuration Example - Downlink

RRC

SRB1 SRB2 DRB1 DRB2

AM AM AM AM

DCCH1 DCCH2 DTCH1 DTCH2

DL-SCH

PDSCH

NAS

E-mail FTP

UDP TCP

IP IP

RLC

MAC

Physical Layer

Logical Channels

Transport Channels

Physical Channels

PDCP Integrity&ciphering Ciphering&ROHC


Protocols Configuration Example – Downlink, cont.

In this example it is assumed that the user is having in parallel 2 downlink applications: an E-Mail download and

an FTP (File Transfer Protocol) download. The target is to show how the air interface protocols could be

configured for this scenario.

It is further assumed that the signaling for the connection setup is already done (i.e. the UE is already in the

RRC_CONNECTED state). However, it is assumed that security activation (ciphering) has still to be done.

Configuration Description

Protocol Configuration for the Control Plane: The NAS Signaling it is transferred using the RRC protocol. This is

done with the help of the Signaling Radio Bearers SRBs. In the LTE implementation there are 3 SRBs:

•SRB0 is for RRC messages using the CCCH logical channel (not shown in the example because the

assumption is that the UE is already in RRC_CONNECTED state)

•SRB1 is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages

prior to the establishment of SRB2, all using DCCH logical channel;

•SRB2 is for NAS messages, using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is always

configured by E-UTRAN after security activation.

The SRB1 is established during the RRC Connection establishment procedure (using the SRB 0). After having

initiated the initial security activation procedure, E-UTRAN initiates the establishment of SRB2.

Once security is activated, all RRC messages on SRB1 and SRB2, including those containing NAS or non-

3GPP messages, are integrity protected and ciphered by PDCP. NAS independently applies integrity protection

and ciphering to the NAS messages.

The SRBs are transported using the acknowledged mode RLC. The SRBs will be further mapped to the logical

channel DCCH (Dedicated Control Channels).


Protocols Configuration Example - Downlink

RRC

SRB1 SRB2 DRB1 DRB2

AM AM AM AM

DCCH1 DCCH2 DTCH1 DTCH2

DL-SCH

PDSCH

NAS

E-mail FTP

UDP TCP

IP IP

RLC

MAC

Physical Layer

Logical Channels

Transport Channels

Physical Channels

PDCP Integrity&ciphering Ciphering&ROHC


Protocols Configuration Example - Downlink, cont.

Protocol Configuration for the User Plane: The E-Mail application will be transmitted using UDP

(connectionless protocol) and the FTP Application will be sent using the TCP (connection oriented). The

reason for this is that the transmission of the FTP should be more reliable from the QoS point of view. This

is also the reason why 2 different user plane data radio bearers (DRBs) have to be used for this scenario.

Both applications are then using the IP (Internet Protocol). The DRBs are established using the signaling

radio bearers SRBs.

The user plane radio bearers are transported further using the acknowledged mode RLC. The radio bearer

1 which is caring the e-mail will be mapped on the logical channel DTCH1 (Dedicated Traffic Channel) and

the radio bearer 2 which is caring the FTP download will be mapped on the DCCH2. The logical channels

will be further explained in chapter 5.

Common Configuration for control plane and the user plane:

The logical channels belonging to both the user plane and the control plane, i.e. DCCH1, DCCH2, DTCH1

and DTCH2 are mapped by the MAC layer to the same transport channel. In downlink the transport channel

is DL-SCH (Downlink Shared Channel).

The physical layer is mapping the transport channel DL-SCH to the physical channel PDSCH (Physical

Downlink Shared Channel).

The details of the DL-SCH, PDSCH as well as the mapping of the logical channels to the transport channels

and to the physical channels are discussed later.


Data Flow Example

Header Header Payload Payload

PDCP

Header

PDCP

Header

PDCP PDU PDCP PDU

PDCP SDU PDCP SDU

RLC

Header

RLC

Header

RLC

Header RLC SDU RLC SDU RLC SDU

MAC

Header

MAC

Header RLC PDU RLC PDU

Transport block Transport block CRC CRC

E-Mail (IP packet) FTP Download (IP packet)

H H Payload Payload PDCP

RLC

MAC

PHY

PDU = Protocol Data Unit

SDU = Service Data Unit


Data Flow Example, cont.

In this example, two IP packets are transmitted over the air interface:

The first IP packet it is assumed to come from the E-Mail application and the second IP packet is coming

from the FTP download.

One IP packet is containing the header and the payload. The header length is dependent on the IP version

used: IPv4 or IPv6 (a higher length for IPv6). The payload is containing the user data (E-Mail or FTP transfer)

together with UDP/TCP control fields.

PDCP layer: The IP packets are passed through the PDCP layer which is performing IP header compression

and ciphering. Therefore a PDCP header is required. The PDCP SDU (Service Data Unit – data coming from

higher layers to the PDCP layer) together with the PDCP header are forming together the PDCP – PDU

(Protocol Data Unit). The PDCP PDUs are passed down to the RLC layer.

RLC layer: the RLC configuration is AM (acknowledged mode) for both applications from this example. The

second functionality of the RLC layer is segmentation/ reassembly. In the example shown the segmentation

process is illustrated for the data coming from the second application (the FTP transfer). An RLC header is

needed for both reliable data transfer (acknowledge mode) and to be able to perform reassembly at the

receiver side.

MAC layer: the MAC layer is multiplexing together a number of RLC PDUs(Packet Data Units) to form a

Transport Block. How many RLC PDUs are to be multiplexed in one transport bloc is dependent on the

transport block size which is sent over the air interface in on TTI (Transmission Time Interval) = 1 ms. The

size of the transport block is decided by the scheduler which should take into account the quality of the radio

link (link adaptation mechanism): it depends on the chosen Modulation and Coding Scheme (MCS), the

number of resources allocated on the air interface. Thus, the link adaptation mechanism affects both the RLC

and MAC processing (segmentation at RLC and multiplexing at the MAC layer). Thus, the MAC layer should

add one header to indicate the multiplexing of the RLC PDUs into the transport block.

Physical Layer: the physical layer attaches one CRC (cyclic redundancy coding) for error correction reasons.

Details on the transport channel processing at the physical layer are provided in chapter 6.

Documents

02 CT82352EN01GLA1 Air Interface Protocols