Вы находитесь на странице: 1из 22


Air Interface Protocols

Air Interface Protocols
Air Interface Protocols
Air Interface Protocols
Air Interface Protocols
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
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.

Air Interface Protocols
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.

Air Interface Protocols
Air Interface Protocols
Air Interface Protocols
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

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, ).

(continued on the next slide)

Air Interface Protocols
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.

Air Interface Protocols
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
Air Interface Protocols
Air Interface Protocols
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 UEs 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 UEs
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.

(continued on the next slide)

Air Interface Protocols
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
HARQs 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 (see last part of this
register) for transmission on air.

Air Interface Protocols
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.

Air Interface Protocols
Air Interface Protocols
Air Interface Protocols
Air Interface Protocols
Air Interface Protocols
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
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).

Air Interface Protocols
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 DTCH2. 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 in chapter 5.

Air Interface Protocols
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 scond IP packet is
comming 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 comming 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 segmenatation/ reasembly. In the example
shown the segmentation process is ilustrated for the data comming 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 reasembly 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.