Sie sind auf Seite 1von 84

LTE- Long Term Evolution 1 LTE/SAE Introduction

2 Orthogonal FDM

3 Multi-antenna Systems

4 E-UTRA Physical Layer

5 E-UTRA Layer 2 and 3

6 The X2- and S1-interface

7 The Evolved Packet Core

8 LTE/SAE Signalling
Procedures
9

10

11

12

13

Apis Technical Training AB


14
Tjärhovsgatan 21, 5th floor
SE-116 28 Stockholm
Sweden
Tel +46-8-555 105 00
Fax +46-8-555 105 99 15 Foldouts
E-mail info@apistraining.com
www.apistraining.com
The use of a term in this document should not be interpreted in a manner that would affect the
validity or legal status of any proprietary rights that may be attached to that term.

This is a training document and as such simplifies what are often highly complex
technological issues. The system or systems described here should therefore be seen in that
light, i. E. as simplifications rather than generalizations.

Due to ongoing progress in methodology, design, its contents are furthermore subject to
revision without prior notice.

Apis Technical Training AB assumes no legal responsibility for any error or damage resulting
from the use of this document.

Copyright © Apis Technical Training AB 2007. All rights are reserved.

This training material is the confidential and proprietary property of Apis Technical Training
AB. It is to be used solely for the purpose for which it was produced and is not to be copied or
otherwise reproduced without the prior written permission of Apis Technical Training AB.

To our best knowledge, the information in this document is accurate as per


the date of publication.

Other than by prior written agreement, Apis Technical Training AB will not update or
otherwise advise of errors in the document which may be brought to our attention.

All trademarks are trademarks of their respective owners.

Apis Technical Training AB. welcomes customer feedback as part of a process of ongoing
development of our documentation in order to better meet our customers' needs. Please
submit your comments to our Head Office in Stockholm.

Apis Technical Training AB


Tjärhovsgatan 21, 5th floor
SE-116 28 Stockholm
Sweden
E-mail: info@apistraining.com
1 LTE/SAE Introduction
1.1 BACKGROUND ............................................................... 1-2
1.2 EVOLVED UTRA & UTRAN........................................... 1-3
1.2.1 Network Architecture................................................................1-3
1.2.2 Requirements on E-UTRA/UTRAN..........................................1-4
1.2.3 Overview of Technical Solutions..............................................1-5
1.3 EVOLVED PACKET CORE, EPC....................................... 1-7
1.3.1 Network Architecture................................................................1-7
1.3.2 Requirements on the EPC .......................................................1-8
1.4 EVOLVED HSPA (HSPA+) ............................................ 1-9
1.5 REFERENCES .............................................................. 1-10

Apis Technical Training AB


LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-1
1.1 Background
3GPP Long Term Evolution (LTE) is the name given to a project within
the Third Generation Partnership Project (3GPP) to improve the UMTS 3G
mobile system standard to cope with future requirements. Goals include
improving efficiency, lowering costs, reducing complexity, improving
services, making use of new spectrum opportunities and better integration
with other open standards (such as WLAN and WiMAX). Thus, the term
‘LTE’ really means a standardisation project. The final outcome from this
project will be a new set of standards defining the functionality and
requirements of an evolved, packet based, radio access network and a new
radio access. The new radio access network is referred to as the ‘Evolved
UTRAN’ (E-UTRAN) and the new radio access is referred to as the
‘Evolved UTRA’ (E-UTRA). The LTE project belongs to 3GPP Release 8.

The term ‘LTE’ has recently become more or less synonymous to the
(proper) terms ‘Evolved UTRA’ (the new radio access) and ‘Evolved
UTRAN’ (the new radio access network). With this in mind, the author has
taken the freedom to use the terms ‘LTE’ and ‘E-UTRA’ interchangeably
for the new OFDM-based radio interface. The term ‘E-UTRAN’ explicitly
means the whole radio access network (i.e. it includes the eNBs, the X2-
interface and the S1-interface).

The work on LTE started with a workshop, 2-3 Nov 2004 in Toronto,
Canada. The workshop was open to members and non-members of 3GPP.
Operators, vendors and research institutes presented contributions with
views and proposals on the future evolution of 3G. A set of high level
requirements were initially identified:
• Reduced cost per transmitted bit
• More services at lower cost with better user experience
• Flexibility of use of existing and new frequency bands
• Simplified architecture, open interfaces
• Reasonable terminal power consumption.

It was also recommended that the E-UTRAN should bring significant


improvements to justify the standardization effort and that it should avoid
unnecessary options. A feasibility study on the UTRA & UTRAN Long
Term Evolution was then started in December 2004. The objective was "to
develop a framework for the evolution of the 3GPP radio access
technology towards a high data rate, low latency and packet optimized
radio access technology". The study focused on supporting services
exclusively from the Packet Switched (PS) domain.

In parallel to, and coordinated with, the LTE project there is also a 3GPP
standardisation project relating to the core network. This project is called
System Architecture Evolution (SAE) and aims at standardising the
Evolved Packet Core (EPC). The SAE project was started in December
2004, with the objective to “develop a framework for an evolution or
Apis Technical Training AB
LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-2
migration of the 3GPP system to a higher data rate, lower latency, packet
optimized system that supports multiple RATs”. The EPC will be a fully
IP-based core network (‘all-IP’) supporting access not only via GERAN,
UTRAN and E-UTRAN but also WiFi, WiMAX and wired technologies
such as xDSL. The SAE project also belongs to 3GPP Release 8.

A short introduction to the Evolved UTRA/N can be found in section 1.2


in this chapter, and an introduction to the EPC in section 1.3. The Stage 2
set (general architecture, protocol structure and key concepts) of LTE
standardisation documents is, according to 3GPP, to be completed at the
time of writing this document (Oct 2007). The completion date for the
Stage 3 work (i.e. detailed protocol specifications) is still a bit uncertain,
but a reasonable estimate is ‘early 2008’. The Stage 2 set of SAE
standardisation documents are (again according to 3GPP) to be completed
by March 2008, with Stage 3 following shortly afterwards. One should be
aware that major updates/changes/additions to the E-UTRAN/EPC specs
are expected throughout 2008-09. Real-life deployment of LTE/SAE
networks should therefore not be expected until 2009-10.

The reader is strongly encouraged to regularly check the 3GPP website


(www.3gpp.org) for new versions of the standardisation documents referenced at the
end of each chapter in the current document.

1.2 Evolved UTRA & UTRAN


1.2.1 Network Architecture
Evolved UTRAN Evolved Packet Core

eNB

X2

S1

X2 MME
eNB
SGW

X2

eNB

Figure 1-1: The Evolved UTRAN architecture

The Evolved UTRAN consists of the evolved NodeB (eNB), providing the
E-UTRA User Plane (UP) and Control Plane (CP) protocol terminations
towards the UE. The eNBs are interconnected with each other by means of
Apis Technical Training AB
LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-3
the X2-interface, e.g. for support of handovers without data loss. The eNBs
are connected by means of the S1-interface to the EPC. The S1-interface
supports a many-to-many relation between eNBs and MME/SGWs (see
section 1.3.1). The X2- and S1-interfaces are described in in chapter 6.

The eNB can be seen as a combination of the UMTS NodeB and Radio
Network Controller, hosting functions like dynamic resource allocation
(through packet scheduling) and radio resource management.

1.2.2 Requirements on E-UTRA/UTRAN


At the onset of the LTE project a series of requirement targets relating to
performance, complexity and interworking were defined. Some of these
are listed below:
• Peak data rate: at least 100 Mb/s DL and 50 Mb/s UL (assuming
20 MHz system bandwidth).
• Control Plane (CP) latency: transition time less than 100 ms from
an idle state to an active state, and less than 50 ms between a
dormant state (such as R6 CELL_PCH) and an active state.
• User Plane (UP) latency: less than 5 ms in unloaded condition
(single user with single data stream) for small IP packet.
• CP capacity: at least 200 users per cell should be supported in the
active state (5 MHz system bandwidth).
• Mobility: E-UTRAN should be optimized for low mobile speed (0-
15 km/h) and higher speeds (15-120 km/h) should be supported
with high performance. Mobility shall be maintained between 120-
350 km/h (up to 500 km/h depending on the frequency band).
• Coverage: the throughput and mobility targets above should be met
for 5 km cells with a slight degradation for 30 km cells. Cells range
up to 100 km should be possible.
• Spectrum flexibility: E-UTRA shall operate in different spectrum
allocations of different sizes, including 1.25, 1.6, 2.5, 5, 10, 15 and
20 MHz in both UL and DL. Operation in paired (FDD) and
unpaired (TDD) spectrum shall be supported.
• Interworking: co-existence in the same geographical area and co-
location with GERAN/UTRAN on adjacent channels. E-UTRAN
terminals supporting also UTRAN/GERAN operation should be
able to support measurement of, and handover from/to, both
UTRAN and GERAN. The interruption time during a handover of
real-time services between E-UTRAN and UTRAN/GERAN
should be less than 300ms.
• Architecture: the E-UTRAN architecture shall be packet based,
supporting real-time and conversational class traffic. The
architecture shall minimize the presence of "single points of
failure".
• Complexity: minimised number of options and avoidance of
redundant mandatory features.

Apis Technical Training AB


LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-4
1.2.3 Overview of Technical Solutions
The E-UTRA radio interface makes exclusive use of shared channels for
both data and signalling transfer. In this respect the E-UTRA is similar to
the 3GPP R5/R6 High Speed Packet Access, HSPA. The selected radio
access technology, however, is very different to HSPA. Where HSPA uses
WCDMA, the E-UTRA uses Orthogonal Frequency Division Multiplexing
(OFDM).

OFDM splits the available system bandwidth into hundreds, or even


thousands, of narrow-band so-called ‘sub-carriers’. This means that a high
bitrate data stream to a given UE is split by the eNB into a large number of
narrow-band, low bitrate, data streams. The received parallel data streams
(sub-carriers) are then ‘multiplexed’ by the UE in order to re-create the
original high bitrate data stream. This has several advantages over
WCDMA:

• Better spectral efficieny. More information can be sent using the


same system bandwidth as compared to a single-carrier system.

• Flexible/scalable spectrum allocation. The system bandwidth can


be expanded in increments (by ‘adding’ more sub-carriers) as more
spectrum becomes available to the operator. For example, the
initial system roll-out may use a system bandwidth of 1.25 MHz
and at a later stage this may be increased to, say, 2.5MHz (and then
5MHz, 10MHz and so on).

• Better performance under multipath fading conditions. Multipath


effects leads to so-called frequency selective fading, which is much
more damaging to a wideband signal than to a narrowband signal
(the sub-carrier).

There are, of course, drawbacks with OFDM as well. One such drawback
is that an OFDM signal exhibits a very high peak-to-average power ratio
(PAPR). This is not really a problem on the network side, but leads to very
inefficient use of power amplifiers, and hence high power consumption, in
a mobile terminal. The E-UTRA system therefore uses a variant of OFDM
for uplink transmission that reduces PAPR. This variant of OFDM is
called Single-Carrier Frequency Division Multiple Access (SC-FDMA).
Despite the name, there is very little that differentiates SC-FDMA from
‘classic’ OFDM. Chapter 2 contains more information on OFDM.

The use of Multiple Input Multiple Output antenna arrays (MIMO) is an


integral part of the E-UTRA standard. The standard supports up to four
transmit/receive antennas while the expected baseline configuration is two
transmit antennas at the eNB and two receive antennas at the UE. In short,
MIMO can be used in two different ways:

Apis Technical Training AB


LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-5
• To transmit more information over the radio interface without
using more bandwidth than a single antenna system. The number of
antennas used increases the system capacity in a linear manner, i.e.
two antennas allows twice the amount of information to be
transmitted (or, equivalently, the bitrate is doubled).

• To transmit the same information, with the same bitrate as a single


antenna system, but with less output power (or, equivalently, with
higher reliability).

An overview of various MIMO techniques and the mechanisms selected


for E-UTRA can be found in chapter 3.

The E-UTRA physical layer channel processing chain (channel coding and
modulation) is very similar to what is used today for HSPA. It was agreed
at an early stage in the standardisation process that Turbo coding should be
used for error correction purposes and that the supported data modulation
schemes should be QPSK, 16QAM, and 64QAM for downlink and uplink.

Figure 1-2: Constellation diagrams for QPSK (left), 16QAM (middle) and 64QAM (right)

The mapping of modulation symbols onto physical channel resources is


very different compared to HSPA though. The nature of OFDM gives rise
to the concept of 2-dimensional radio resources. The information to be
transmitted over the radio interface is mapped onto a 2-dimensional time-
frequency ‘resource grid’. The E-UTRA physical layer is described in all
its glorious detail in chapter 4.

(A common misunderstanding is that OFDM, by itself, makes very high


bit rates possible. This is not true. Rather, the very high bit rates mentioned
for E-UTRA are made possible first and foremost by a higher transmission
bandwidth (up to 20MHz), higher order modulation (64QAM) and the
support for MIMO with up to four antennas).

The channel and protocol architecture for E-UTRAN layer 2 and layer 3 is
quite similar to the one used in UTRAN today. For example, the UE
protocol stack is close to identical and the channel hierarchy is still divided

Apis Technical Training AB


LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-6
into logical, transport and physical channels. The E-UTRAN protocol/
channel architecture is described in chapter 4.

The exact functionality of the layer 2 and layer 3 protocols in E-UTRAN


is, at the time of writing, far from decided. An overview of the expected
functionality can be found in chapter 5.

1.3 Evolved Packet Core (EPC)


1.3.1 Network Architecture
GERAN/ Gb/Iu
SGSN
UTRAN

S3 S4

S1-MME S11
MME

S1-U S5 SGi
E-UTRAN SGW PGW IMS / Internet /…

S2
Non-3GPP
access

Figure 1-3: the Evolved Packet Core network architecture

Figure 1-3 shows the network architecture of the Evolved Packet Core
(EPC). The EPC consists of three main nodes: the Mobility Management
Entity (MME), the Serving Gateway (SGW) and the Packet Data Network
Gateway (PGW). The MME may be co-located with the SGW, and the
SGW may be co-located with the PGW. Hence, the standard allows a
completely collapsed ‘one-node’ core network or a distributed (easily
scalable) core network, or any possible ‘combination’ in-between.

The MME connects to the E-UTRAN via the S1-MME interface and is
present solely in the CP. It is responsible for handling mobility and
security procedures, such as network Attach, Tracking Area updates
(similar to Location/Routing Area updates) and authentication. The MME
also connects to the SGSN via the S3-interface.

The SGW connects to the E-UTRAN via the S1-U interface and is present
solely in the UP. Its prime responsibility is routing and forwarding of user
IP-packets. It acts as a UP anchor when the UE moves between 3GPP
radio access technologies (S4-interface).

Apis Technical Training AB


LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-7
The PGW connects to the SGW via the S5-interface and to external packet
data networks (or IMS) via the SGi-interface. It is responsible for the
enforcing of QoS and charging policies. It also acts as a UP anchor when
the UE moves between 3GPP and non-3GPP radio access (S2-interface).

It should be noted that additional network nodes/functions, not shown in


figure 1-3, might be present as well. For example, a Packet Data Gateway
(PDG) is needed for non-trusted IP access and a Policy and Charging
Rules Function (PCRF) is required for IMS controlled QoS and charging
mechanisms. The EPC is described further in chapter 7.

1.3.2 Requirements on the EPC


A (rather long) list of general requirements has been set up as guidelines
for the standardisation work related to the EPC. Some of those are:
• 3GPP and non-3GPP access systems shall be supported.
• Scalable system architecture and solutions without compromising
the system capacity (e.g. by separating CP from UP).
• CP response time shall be such that the UE can move from an idle
state to one where it is sending/receiving data in less than 200 ms.
• Basic IP connectivity is established during the initial access phase
(hence, the UE is ‘always-on’).
• The Mobility Management (MM) solution shall be able to
accommodate terminals with different mobility requirements
(fixed, nomadic and mobile terminals).
• The MM functionality shall allow the network operator to control
the type of access system being used by a subscriber.
• MM procedures shall provide seamless operation of both real-time
(e.g. VoIP) and non real-time applications.
• In order to maximise users' access opportunities, the architecture
should allow a UE that is roaming to use a non-3GPP access (e.g.
WLAN) network with which the VPLMN has a business
agreement. For example, it should be possible for a user to use a
WLAN access network with which only the visited operator has a
direct relationship (not the home operator).
• The evolved system shall support Ipv4 and Ipv6 connectivity.
• Access to the evolved system shall be possible with R99 USIM.
(Please note that this does not explicitly allow access using SIM)
• The authentication framework should be independent from the used
access network technology.
• Radio interface multicast capability shall be a built-in feature.
• The SAE/LTE system shall support network-sharing functionality.
• It shall be possible to support service continuity between IMS over
SAE/LTE access and the Circuit Switched (CS) domain.
• It shall be possible for the operator to provide the UE with access
network information pertaining to locally supported 3GPP and non-
3GPP access technologies.

Apis Technical Training AB


LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-8
1.4 Evolved HSPA (HSPA+)
Iu
RNC cSGSN

Iur Gn

Iu/Gn Gi
NB xGGSN IMS / Internet /…

Figure 1-4: Evolved HSPA network architecture

A parallel 3GPP R8 project to LTE and SAE is the Evolved High Speed
Packet Access, eHSPA, project (also referred to as HSPA+). The proposed
eHSPA features represent a logical evolution from today’s HSDPA and
HSUPA systems. Roughly speaking, the eHSPA project focuses on three
areas:

• Optimising HSPA for real-time packet data services, like VoIP. A


large part of achieving this goal relates to a more efficient use of
the HSPA control channels.

• Increasing the system and user throughput. This is achieved by the


introduction of higher order modulation (64QAM) and MIMO for
HSPA. The theoretical maximum bit rate is around 40Mb/s for the
DL and around 20Mb/s for the UL.

• Simplifying the network architecture. The eHSPA NodeB will take


on parts of, or all of, the functionality of the RNC. In addition, the
SGSN will be removed from the User Plane path (the so-called
‘one-tunnel solution’) allowing IP packets to be routed directly
between eHSPA NodeB and GGSN. This can be seen in figure 1-4
above, where ‘cSGSN’ is the SGSN Controller, and ‘xGGSN’ is
the enhanced GGSN.

Thus, E-UTRA/E-UTRAN and Evolved HSPA have many concepts in


common (collapsed architecture, 64QAM, MIMO). As a matter of fact, the
performance (bit rates, spectral efficiency etc) of eHSPA is very close to
the performance of E-UTRA with 5MHz channel bandwidth. This has led
to some level of debate whether to refer to eHSPA as a ‘migration path’ or
a ‘complement’ or a ‘competing technology’.

Apis Technical Training AB


LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-9
1.5 References
23.401 GPRS enhancements for Long Term Evolution (LTE)
23.402 3GPP SAE: Architecture enhancements for non-3GPP accesses
23.882 3GPP SAE: Report on technical options and conclusions
25.912 Feasibility study for E-UTRA and E-UTRAN
25.913 Requirements for E-UTRA and E-UTRAN
25.999 High Speed Packet Access (HSPA) evolution, FDD
36.300 E-UTRA/E-UTRAN; overall description; Stage 2

Apis Technical Training AB


LTE - LTE/SAE Introduction
Copyright © Apis Technical Training AB 2007. All rights reserved. 1-10
2 OFDM
2.1 OFDM BASICS ............................................................. 2-2
2.1.1 Introduction ..............................................................................2-2
2.1.2 Sub-carriers and Multiplexing ..................................................2-3
2.1.3 Orthogonality............................................................................2-4
2.1.4 Cyclic Prefixes..........................................................................2-6
2.2 OFDM SIGNAL GENERATION ......................................... 2-7
2.3 SC-FDMA.................................................................... 2-8
2.4 REFERENCES .............................................................. 2-10

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-1
2.1 OFDM Basics
(The theory behind OFDM is very mathematical in its nature. The following is just a brief
overview in ‘layman’s terms’ to convey the basic characteristics of OFDM. For a deeper
understanding of OFDM it is recommended to consult a textbook on the subject)

2.1.1 Introduction
Orthogonal Frequency Division Multiplexing (OFDM) is a digital multi-
carrier modulation scheme that uses a large number of closely-spaced
orthogonal sub-carriers. Each sub-carrier is modulated with a
conventional modulation scheme (such as 16QAM) at a low symbol rate,
maintaining data rates similar to conventional single-carrier modulation
schemes in the same bandwidth. The primary advantage of OFDM over
single-carrier schemes is its ability to cope with severe channel conditions
without complex equalization filters. Low symbol rate makes the use of a
guard interval between symbols affordable, making it possible to handle
time-spreading and inter-symbol interference (ISI).

OFDM has only become widely used during the last decade or so, but the
technology as such is about 50 years old (it was first used around 1957 in
an experimental communications system developed for the US Navy).
During the 70’s and 80’s several important theoretical contributions from
various sources made it possible to implement more efficient and robust
OFDM-based systems. Today, OFDM has proved itself as the preferred
radio access technology in a wide variety of communication systems.
Some examples of OFDM use: IEEE 802.11a/g (WLAN/WiFi), IEEE
802.16 (WiMAX), Digital Audio Broadcasting (DAB), Digital Video
Broadcasting (DVB-T and DVB-H) and Asynchronous Digital Subscriber
Line (ADSL).

Some advantages of OFDM:


• Allows adaptation to severe channel conditions without very
complex equalization methods
• Robust against narrow-band co-channel interference
• Robust against Inter-Symbol Interference (ISI) and fading caused
by multipath propagation
• High spectral efficiency
• Efficient implementation using FFT
• Low sensitivity to time synchronization errors
• Facilitates Single Frequency Networks (i.e. synchronised broadcast
from several transmitters).

Some disadvantages of OFDM:


• Sensitive to Doppler shift
• Sensitive to frequency synchronization problems
• High peak-to-average power ratio (PAPR), requiring more
expensive transmitter circuitry and lowering power efficiency.

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-2
2.1.2 Sub-carriers and Multiplexing
As we have already mentioned in chapter 1, OFDM spreads the data to be
transmitted over a large number of sub-carriers- typically more than a
thousand. The data rate to be conveyed by each of these sub-carriers is
correspondingly reduced, thus transforming a single high bitrate channel to
many low bitrate channels.

It follows that the modulation (OFDM) symbol length is in turn extended,


which dramatically reduces the system’s sensitivity to inter-symbol
interference due to multipath effects (i.e. different versions, or ‘echoes’, of
the same signal travelling different paths over the radio interface and
arriving at the receiver at different points in time, causing interference).
This is true as long as the maximum delay of the ‘echoes’ is smaller than
the OFDM symbol time duration.
LONG delay SHORT delay
(or short symbols) (or long symbols)

Main Path: n-1 Symbol n n+1 n-1 Symbol n n+1

Delayed Path: Symbol n-3 Symbol n-2 Symbol n-1 Symbol n

Both cause ISI Causes ISI Adds constructively


or destructively

Figure 2-1: multipath delays versus symbol length

With hundreds or thousands of sub-carriers available it becomes quite


straightforward how to multiplex users on the radio interface. Simply
allocate different sets of sub-carriers to different users (this is the ‘FDM’
in OFDM). More complex multiplexing schemes can be implemented by
allowing users to share the available sub-carriers both in the frequency
domain (FDM) and the time domain (TDM).

f
FDM: Sub-carrier multiplexing

Sub-carrier n

Sub-carrier 1
t
Radio frame 1 Radio frame m

TDM: radio frame multiplexing

Figure 2-2: OFDM multiplexing using both FDM and TDM

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-3
Furthermore, sub-carrier frequency hopping schemes may be applied to
reduce fading effects that are frequency selective. The transmitter (base
station) can also order the receivers (mobile stations) to send feedback
information in the form of channel quality reports. This allows dynamic
channel dependent scheduling in the base station, making sure that each
mobile station is always allocated a subset of sub-carriers where it
experiences the least amount of interference. A graphical representation of
frequency selective fading effects can be seen in figure 2-3 below.

Figure 2-3: frequency selective fading effect on OFDM sub-carriers

E-UTRA combines OFDM with FDM and TDM multiplexing schemes as


well as sub-carrier frequency hopping and channel dependent scheduling.

2.1.3 Orthogonality
In traditional FDM different users are allocated different frequencies, or
channels, for their transmission (e.g. analog 1G systems such as NMT). To
avoid interference between these channels the FDM frequencies must be
spaced apart- there must be a guard band between them. This leads to
waste of the available frequency spectrum.

FDM: guard band between carriers OFDM: carriers can be packed tighter

Saving bandwidth

Figure 2-4: FDM versus OFDM (spectrum efficiency)

In OFDM, the frequencies of the individual sub-carriers are chosen in such


a way that they do not interfere with each other- they are orthogonal (this
is the ‘O’ in OFDM). The demodulator for one sub-carrier does not 'see'
Apis Technical Training AB
LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-4
the modulation of the others, so there is no crosstalk between sub-carriers
even though their spectra overlap. This allows us to ‘pack’ the sub-carriers
much more densely than in a traditional FDM system, thus increasing
spectrum efficiency.

All the sub-carriers allocated to a given user are transmitted in parallel.


Fortunately, the apparently very complex processes of modulating (and
demodulating) thousands of sub-carriers simultaneously are equivalent to
Discrete Fourier Transform (DFT) operations for which efficient Fast
Fourier Transform (FFT) algorithms exist, allowing affordable mass-
produced transceivers.

To ensure orthogonality the sub-carriers must have a common, precisely


chosen frequency spacing (‘carrier spacing’). This frequency spacing is
exactly the inverse of the OFDM symbol duration, called the active symbol
period, over which the receiver will demodulate the signal. In the case of
E-UTRA the carrier spacing is 15kHz (7.5kHz for MBMS dedicated cells).

Received signals are


evaluated at their maximum

Figure 2-5: orthogonal OFDM sub-carriers (frequency domain)

Figure 2-5 shows a few sub-carriers represented in the frequency domain


(compare figure 2-3). The receiver will demodulate (or sample) each sub-
carrier precisely where it has it maximum value. Due to the ‘precisely-
chosen frequency spacing’ all other sub-carrier have the value zero at this
precise frequency, despite that they overlap, thus not creating any
interference at all.

However, this nice relationship between sub-carriers can be destroyed,


resulting in loss of orthogonality and severe bit error rates as a result. The
bit errors can be rectified to some extent with the use of error correcting
codes, so called Forward Error Correction (FEC). A combination of FEC
and OFDM is called Coded OFDM (COFDM). In E-UTRA, OFDM is
combined with Turbo coding.

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-5
Such loss of orthogonality can be caused by frequency synchronisation
errors due to slight differences in the local oscillators, used for frequency
generation, in the transmitter and the receiver. Another cause is Doppler
effects arising from the relative motion between the transmitter and the
receiver- an effect that must be taken seriously in any mobile system!

2.1.4 Cyclic Prefixes


As mentioned earlier, OFDM is robust against multipath fading due to the
long OFDM symbol duration. However, there will always be some inter-
symbol interference due to multipath echoes, even for OFDM. A further
refinement therefore adds the concept of a guard interval. Each OFDM
symbol is transmitted for a total symbol period that is longer than the
active symbol period by a period called the guard interval or guard period.

Guard Useful
period part

Main Path: n-1 CP Symbol n n+1

Delayed Path: n-1 n

ISI only
during CP

Figure 2-6: guard interval with cyclic prefix

This means that the receiver will experience neither inter-symbol nor inter-
carrier interference provided that any echoes present in the signal have a
delay that does not exceed the guard interval. Naturally, the addition of the
guard interval reduces the data capacity by an amount dependent on its
length. Different systems use different (relative) lengths of the guard
interval, common values being 5-25% of the OFDM symbol length.

There are several ways to ‘fill’ the guard interval with information (to
avoid turning the transmitter on and off abruptly). A common mechanism
is the use of a so-called cyclic prefix. A cyclic prefix (CP) is created
simply by selecting the last part of an OFDM symbol, make a copy of it
and place the copy in front of the symbol (hence the term ‘prefix’). The
concept of a guard interval is illustrated in figure 2-6 above.

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-6
By doing so, a continuous signal is created (easier to implement) and any
multipath delayed echoes will only cause interference in the CP part of the
received OFDM symbol. The receiver treats the CP portion of the OFDM
symbol as ‘rubbish’ and removes it prior to demodulating the information.

E-UTRA defines a ‘normal’ length and an ‘extended’ length of the CP, to


cater for the different requirements of small versus large cells. There are
also different CP lengths defined for MBMS transmission, when multiple
synchronised eNBs act as a Single Frequency Network (SFN).

2.2 OFDM Signal Generation

S
I
Coding F Add
RF
Modulation F CP

T
P
fo

Figure 2-7: the OFDM transmitter using IFFT

There are several ways to realize an OFDM transmit-receive chain. For


example, the addition of a cyclic prefix is not mandatory and filtering/
equalization of the baseband signal (the ‘RF’ box in fig 2-7) can be done in
many different ways. Thus, figure 2-7 below does not represent the way to
create an OFDM signal.

Coding and Modulation: this step is any conventional Forward Error


Correction (FEC) mechanism, such as convolutional coding, and any
conventional modulation scheme, such as QPSK or 64QAM.

Serial-to-Parallel: a group of modulation symbols are ‘fed’ to the Inverse


Fast Fourier Transform (IFFT) in parallel. The number of modulation
symbols fed to IFFT equals the number of assigned sub-carriers.

Inverse Fast Fourier Transform: each modulation symbol is used for


modulating one sub-carrier, in effect acting as a complex wight setting the
amplitude and phase of the sub-carrier. These modulated sub-carriers are
then summed together, creating one OFDM symbol.

Cyclic Prefix: the last portion of the OFDM symbol is copied and
appended at the ‘front’ of the symbol. This creates a guard interval with
well-defined content.

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-7
RF processing: the OFDM symbols are used for modulation of the actual
carrier frequency. In addition, various pulse shaping or filtering techniques
may be applied at this stage.

The receiving side uses the process in reverse. The IFFT process must be
inverted in order to retrieve the information content of the individual sub-
carriers. This is done with the Fast Fourier Transform (FFT). Hence, the
inverse of the Inverse-FFT is, of course, the FFT.

2.3 SC-FDMA
In chapter 1 it was mentioned that one drawback with OFDM was its high
peak-to-average power ratio (PAPR). This is a direct consequence of using
DFT (FFT) to create the OFDM symbols. The DFT effectively stacks
sinewaves ‘on top’ of each other. It can then of course happen that a large
portion of the used sub-carriers happen to have their maximum value at the
same time, resulting in a dramatic peak in the total amplitude (or power) of
the signal. This puts very high demands on the power amplifier in the
signal processing chain and is not desirable in a small portable device,
such as a mobile phone, with limited battery capacity.

0
S M 0
F a 0
Coding 0 I
F p
Modulation F Add

T p RF
F CP
P i

T
n
g 0 fo
0

Figure 2-8: the SC-FDMA transmitter using FFT spreading

The solution for this in the E-UTRA specification is to use a variant of


OFDM called Single-Carrier Frequency Division Multiple Access (SC-
FDMA) for uplink transmission. Figure 2-8 shows the processing cain for
an SC-FDMA transmitter.

A comparison to figure 2-7 reveals that two additional steps have been
added to the processing chain: an FFT transform and a sub-carrier
mapping stage (the dotted box in figure 2-8). As for ‘classic’ OFDM, a
block of modulation symbols are fed in parallel into the transform stage,
which is now FFT instead of IFFT. The FFT process will now spread each
modulation symbol over all sub-carriers instead of using 1-to-1 mapping.

In other words, the input signal (modulation symbols) will be spread over
the available bandwidth (the available sub-carriers) very much like in a
single-carrier system. (It could be worth knowing that SC-FDMA is also
referred to as ‘DFT-spread OFDM’)

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-8
The sub-carrier mapping stage (‘mapping’ in figure 2-8) then feeds the
FFT-output to a subset of the IFFT-inputs, with all other inputs set to zero.
Thus FFT has size=N and the IFFT has size=M, with M>N. The output
from the IFFT stage is now called an SC-FDMA symbol, to which we add
a cyclic prefix in the normal manner.

Thus, the result of the additional FFT stage is that the created signal
exhibits single-carrier properties (the ‘SC’ in SC-FDMA). Furthermore,
different users will be ordered to transmit on different, orthogonal,
‘chunks’ of subcarriers (the ‘FDM’ in SC-FDMA).

There are different ways of selecting which specific sub-carriers that


should be part of the ‘chunk’ for a given user. For localized SC-FDMA, a
set of consecutive sub-carriers are selected (e.g. use sub-carrier number
20-40). For distributed SC-FDMA, the sub-carriers are evenly distributed
(e.g. use sub-carrier 5, 10, 15 etc). A third option is to select sub-carriers
that are neither consecutive nor evenly distributed, but selected according
to some other pattern. This gives us randomized SC-FDMA. Currently, the
only option allowed for E-UTRA uplink is localized SC-FDMA.

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-9
2.4 References
25.912 Feasibility study for E-UTRA and E-UTRAN
36.211 E-UTRA; Physical channels and modulation
36.300 E-UTRA E-UTRAN; overall description; Stage 2

http://en.wikipedia.org/wiki/OFDM
This Wikipedia article gives a good introduction to OFDM and contains
numerous references to other websites, white papers and textbooks about
OFDM and related topics.

Apis Technical Training AB


LTE - OFDM
Copyright © Apis Technical Training AB 2007. All rights reserved. 2-10
3 Multi-antenna
Systems
3.1 MULTIPLE ANTENNA SYSTEMS ........................................ 3-2
3.1.1 SIMO/MISO: Receive/Transmit Diversity.................................3-2
3.1.2 MIMO: Multiple Input Multiple Output.......................................3-4
3.2 MIMO TECHNIQUES ...................................................... 3-5
3.2.1 Spatial Multiplexing (SM) .........................................................3-5
3.2.2 Space-Time Coding (STC).......................................................3-5
3.2.3 MU-MIMO and SU-MIMO.........................................................3-6
3.2.4 MIMO and OFDM.....................................................................3-6
3.3 MIMO FOR E-UTRA ..................................................... 3-7
3.4 REFERENCES ................................................................ 3-9

Apis Technical Training AB


LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-1
3.1 Multiple Antenna Systems
(The theory behind MIMO is, like OFDM, highly mathematical in its nature. This chapter
provides an overview in ‘layman’s terms’ to convey the basics of MIMO. For a fuller/
deeper understanding of MIMO it is recommended to consult a textbook on the subject)

Any wireless communications system with one transmit (Tx) antenna and
one receive (Rx) antenna is referred to as operating in Single Input Single
Output (SISO) mode. More antennas (Tx and/or Rx) can be added in order
to increase either throughput or reliability. Systems with multiple Tx/Rx
antennas are divided into Single Input Multiple Output (SIMO), Multiple
Input Single Output (MISO) or Multiple Input Multiple Output (MIMO).

Simple multi-antenna systems have been around, in one form or another,


for over 50 years (Guglielmo Marconi used multiple antenna transmission
to transmit a Morse signal across the Atlantic Ocean, from England to
Newfoundland, in 1901). But until quite recently, the amount of signal
processing needed has been too expensive to be practical for large-scale
deployment and implementation in small mobile devices. Important factors
driving MIMO acceptance today is the advent of in-expensive high-speed
Digital Signal Processors (DSPs) and significant research breakthroughs in
information theory over the last decade.

MIMO is currently used in various WLAN systems (IEEE 802.11 family)


and in WiMAX (IEEE 802.16 family) to name a few. MIMO is also an
integral part of the 3GPP R8 standards pertaining to eHSPA and LTE.

3.1.1 SIMO/MISO: Receive/Transmit Diversity

TX RX

Figure 3-1: a SIMO system

In a SIMO system the transmitter has one antenna and the receiver has
two, or more, physically separated antennas (the physical separation
distance has a direct relationship with the wavelength of the carrier). This
allows for receive diversity (Rx diversity). With Rx diversity the receiver
picks up two (or more) ‘versions’ of the same transmitted signal. The
receiver may then either:

Apis Technical Training AB


LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-2
• select the best input (from one of the antennas), for example based
on signal-to-noise ratio (SNR). This is called switched diversity.
• combine the input from all antennas, for example through a process
called Maximum Ratio Combining (MRC).

With MRC, channel compensation is applied to each received signal


before being linearly combined to create a single, composite, received
signal. Rx diversity using MRC is used in challenging propagation
conditions when signal strength is low and/or multipath conditions are
severe. MRC uses the fact that it is statistically very unlikely that a given
signal will undergo deep fading on all Rx channels simultaneously. The
possibility of deep frequency selective fades in the composite signal is
therefore significantly reduced. Thus, MRC enhances link reliability but it
does not increase the nominal system data rate.

TX RX

Figure 3-2: a MISO system

In a MISO system the transmitter has two or more physically separated


antennas and the receiver has one antenna. This allows for transmit
diversity (Tx diversity). With Tx diversity, the transmitter sends redundant
‘copies’ of a signal to the receiver. Tx diversity is based on the ‘hope’ that
at least one of the copies will be received in a good enough state to allow
reliable decoding.

One way of realizing Tx diversity is to make use of Space-Time Coding


(STC). STC allows the transmitter to use diversity in both the space and
time domain. This means that the signal is transmitted through multiple
antennas (space) at different points in time (the ‘ST’ in STC). In the simple
case of two antennas, a super-position of 2 modulation symbols (e.g.
QPSK symbols) is transmitted on both antennas simultaneously. The very
same modulation symbols are then transmitted again with a (very) slight
delay. In addition, the modulation symbols will be coded, or weighted,
differently for the second, slightly delayed, transmission (the ‘C’ in STC).

As for Rx diversity, Tx diversity enhances link reliability but does not


increase the nominal system data rate. However, with a more reliable data
channel it is possible to use less output power (resulting in higher system
capacity) or to use less robust channel coding (resulting in higher effective
throughput).
Apis Technical Training AB
LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-3
3.1.2 MIMO: Multiple Input Multiple Output
As might be suspected from the discussion above, a MIMO system uses
multiple antennas at transmitter and receiver. Just like the diversity
schemes mentioned above the whole point of using multiple antennas is to
increase the system capacity (in terms of number of users/cell, coverage,
throughput etc) without having to increase the system bandwidth. Using
the laws of information theory, it can be shown that the diversity schemes
mentioned in section 3.1.1 increase the system capacity logarithmically
with the number of antennas. Symmetric MIMO configurations (same
number of Tx and Rx antennas) on the other hand, increase the system
capacity linearly with the number of antennas. As an example, with four
Tx/Rx antennas one can quadruple the system throughput! The cost, of
course, is increased complexity.

TX RX

Figure 3-3: a MIMO system with two transmit and two receive antennas (2x2)

The ‘magic’ of MIMO lies in its ability to take multipath reception, which
used to be an unavoidable and undesired by-product of radio propagation,
and convert it into an advantage that actually multiplies transmission speed
and improves throughput. A MIMO system uses the additional signal paths
to transmit more information and recombine the signals on the receiving
end. It follows naturally that the diversity modes, mentioned in section
3.1.1, as well as ‘true’ MIMO mode can be used in a system with multiple
Tx and Rx antennas.

For MIMO, mathematical algorithms are used in order to spread the user
data across multiple transmitting antennas. The signals transmitted are
defined in 3 dimensions: time, frequency and space. At the receiver, the
different signals from each antenna must be identified and separately
decoded during the recombination process. Hence, the (mathematical)
technique of separating out different paths on the radio link is what allows
a MIMO system to transmit multiple signals at the same time on the same
frequency, in effect multiplying the capacity of the channel with the
number of antennas.

Apis Technical Training AB


LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-4
3.2 MIMO Techniques
3.2.1 Spatial Multiplexing (SM)
Spatial Multiplexed (SM) MIMO systems increase spectral efficiency by
utilizing signal processing algorithms to exploit multipath propagation on
the MIMO communication link. Independent data streams, using the same
time-frequency resource, are sent over different transmit antennae. The
receiver is able to separate the multiple data streams by using (known)
channel information about each propagation path. The multiple streams of
a SM transmission must also be orthogonal to each other. Catastrophic
interference would follow otherwise. The orthogonality is achieved by
multiplying the transmitted streams with a so-called linear precoding
matrix.

One should not confuse spatial multiplexing with spatial diversity (which is
not ‘true’ MIMO). The purpose of spatial diversity is to increase the
diversity order of a link to mitigate fading by coding a signal across space
and time so that a receiver could receive the replicas of the signal and
combine those received signals constructively. Spatial multiplexing
transmits not replicas of the same signal but different signals.

SM achieves higher data rates by re-using the same frequency resources


over multiple spatial dimensions, in effect creating (spatially separate)
parallel channels ‘for free’ on the same bandwidth. For example, using two
transmit and receive antennas one could transmit two separate data
streams, each with data rate 5 Mb/s, resulting in a data rate of 10 Mb/s to
the same terminal. At the receiver, multiple antennas are required to
demodulate the data streams based on their spatial characteristics (the
number of receive antennas is equal to the possible number of separate
data streams).

3.2.2 Space-Time Coding (STC)


Space-Time Coding (STC) was mentioned above, in section 3.1.1, as a
way of realizing Tx diversity. The same theoretical framework is used also
for true MIMO operation. STC-MIMO systems provide diversity gain to
combat unwanted multipath effects. As already mentioned, time-delayed
copies of the same signal, coded differently, are sent over the transmit
antennae. The use of multiple antennas at both ends of the link creates
additional independently faded signal paths, thereby increasing the
maximum diversity gain that can be achieved. Space-Time Codes are split
into two main types: trellis codes and (less complex) block codes.

Depending on the specific STC method used, the receiver may or may not
have to be aware of the characteristics of the channel in order to detect the
multiple data streams properly. The use of SM or STC in MIMO is not
mutually exclusive, some systems allows dynamic switching between the
two modes.
Apis Technical Training AB
LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-5
3.2.3 MU-MIMO and SU-MIMO
MIMO transmission can be divided into multi-user and single-user MIMO
(MU-MIMO and SU-MIMO). The difference between the two is that in
SU-MIMO all the streams carry data to/from the same user while in the
case of MU-MIMO the data for different users is multiplexed onto a single
time-frequency resource. Hence, SU-MIMO is used either to increase the
reliability of the channel (i.e. diversity) or to increase the throughput to a
single user in a multiplicative manner while MU-MIMO can be seen as yet
another way of multiplexing data to/from different users.

In the case of, say, a 2x2 antenna MU-MIMO configuration, two mobile
terminals can transmit/receive their data streams simultaneously using the
same physical radio resource. Clearly, MIMO is a very powerful way of
serving more users without increasing the system bandwidth.

Obviously, some form of ‘stream identifier’ is needed in both cases. For


SU-MIMO, the receiver must be able to separate one antenna stream from
the other(s) in order to perfom efficient combining. In the SU-MIMO case,
this is achieved by adding a code layer to the transmission- in effect using
a basic Code Division Multiplexing (CDM) scheme.

For MU-MIMO, the transmitter (mobile station) must be able to ‘tag’ its
stream(s), allowing the reciever (base station) to figure out who was
transmitting. This is done using a mobile specific reference signal that is
transmitted together with the actual data.

The use of transmitter specific codes and reference signals does not only
allow the receiver to figure out who was transmitting. It also enables
accurate channel estimation, which is crucial in MIMO systems.

3.2.4 MIMO and OFDM


OFDM is particularly well matched to MIMO applications since it is very
tolerant to the effects of multipath fading (remember that MIMO actually
creates and relies upon multipath signals). OFDM in the downlink
direction can be designed to provide good support for MIMO technologies,
as mechanisms such as frequency domain scheduling allow for creating
signal-to-noise conditions where MIMO works much better compared to
more uniform interference conditions. In short, it can be said that the
(mathematical) MIMO model is based on a narrow band non-frequency
selective channel, which is precisely what OFDM (with a proper guard
interval) offers.

Apis Technical Training AB


LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-6
3.3 MIMO for E-UTRA
All of the previously mentioned MIMO techniques (SM, STC, SU-MIMO,
MU-MIMO) are supported in E-UTRA. However, the current specification
is a bit ambiguous as to what must be supported and to what may be
supported. For sure, MIMO is seen as an integral part of the E-UTRA
specification, and if an E-UTRAN network supports MIMO there are very
clear rules in the standard as how to implement it in terms of precoding
matrices, layer mapping etcetera. Furthermore, it is perfectly clear in the
standard that the expected baseline configuration shall be two transmit
antennas at the eNB and two receive antennas at the UE (allowing also Tx
diversity as described earlier).

The apparent ‘ambiguity’ in the standard is certainly not due to uncertainty


or lack of knowledge, but rather due to preparedness for the future. The
modern concept of MIMO is a relatively young research field where
significant ‘jumps’ in knowledge could happen at any time. The goal of
the standardization process, regarding MIMO, is therefore to incorporate it
as an (expected) possibility rather than as an absolute demand. Care is
taken not to standardise the use of MIMO to the smallest detail since that
might make it difficult, or impossible, to incorporate future improvements
of multi-antenna algorithms in an efficient manner.

As already stated above the (expected) baseline antenna configuration in


E-UTRA for MIMO (and/or Tx diversity) is two transmit antennas at the
eNB and two receive antennas at the UE. Even higher-order downlink
MIMO and antenna diversity (four TX and two or four RX antennas) will
also be supported in the first (R8) release of LTE. The possible/allowed
MIMO modes of operation at the eNB are (at the time of writing):
• Spatial Multiplexing , for one or more* UEs (SU/MU-MIMO)
• Beamforming (not ‘true’ MIMO)
• Single-stream Tx diversity (not ‘true’ MIMO).

*) The Spatial Multiplexing of data streams for different UEs using the same time-
frequency resource is, in the standard, denoted as Spatial Division Multiple Access
(SDMA) or Multi-User MIMO (MU-MIMO)

The LTE standard allows (semi-static) switching between the SU-MIMO


and MU-MIMO modes on a per UE basis. Both SU- and MU-MIMO in
LTE uses fixed codebooks with precoding matrices that are known to eNB
and UE. The UE reports the desired precoding matrix to use, but there is
no requirement for the eNB to actually use this value. As a consequence,
the precoding matrix selected by the eNB must be signalled to the UE.

The MIMO mode that can be used is, of course, restricted by the UE
capability, e.g. the number of UE receive antennas, and is determined
taking into account the slow channel variation. The selected MIMO mode
is adapted slowly (e.g. set at the beginning of a data session or adapted
with a period of several 100ms) in order to reduce the feedback control
signalling required to support MIMO mode adaptation.
Apis Technical Training AB
LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-7
It should be noted that for lower data rates it is more efficient to transmit
using a single stream rather than with spatial multiplexing. It can be shown
that for a given low rate and a given total transmit power single stream
transmission achieves a lower frame error rate. Therefore, MIMO for LTE
will most probably use single stream transmission (perhaps using Tx
diversity) for lower data rates and spatial multiplexing for the higher data
rates. The “crossover point” at which it becomes more efficient to transmit
with spatial multiplexing rather than spatial diversity depends on many
factors, the number of receive antennas at the UE being one and the
distance between transmitter and receiver being another. In general it can
be said that SM is most useful when the distance between the transmitter
and the receiver is relatively small.

Apis Technical Training AB


LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-8
3.4 References
25.912 Feasibility study for E-UTRA and E-UTRAN
36.211 E-UTRA; Physical channels and modulation
36.300 E-UTRA E-UTRAN; overall description; Stage 2

Apis Technical Training AB


LTE - MIMO
Copyright © Apis Technical Training AB 2007. All rights reserved. 3-9
4 E-UTRA Physical
Layer
4.1 INTRODUCTION .............................................................. 4-2
4.2 RADIO FRAME STRUCTURE ............................................ 4-3
4.2.1 Frame Type 1...........................................................................4-3
4.2.2 Frame Type 2...........................................................................4-4
4.3 CHANNEL ARCHITECTURE .............................................. 4-5
4.3.1 Logical Channels......................................................................4-5
4.3.2 Transport Channels..................................................................4-6
4.3.3 Physical Channels....................................................................4-8
4.3.4 Physical Signals .......................................................................4-9
4.4 LAYER 1 PROCESSING CHAIN ....................................... 4-11
4.4.1 Downlink Shared Channel (DL-SCH).....................................4-11
4.4.2 Uplink Shared Channel (UL-SCH) .........................................4-15
4.5 RESOURCE MAPPING ................................................... 4-16
4.5.1 Resource Definitions ..............................................................4-16
4.5.2 Downlink Subframe ................................................................4-17
4.5.3 Downlink Cell Search Pattern ................................................4-19
4.5.4 Uplink Subframe: PUSCH ......................................................4-19
4.5.5 Uplink Subframe: PUCCH......................................................4-20
4.6 REFERENCES .............................................................. 4-21

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-1
4.1 Introduction
The E-UTRA physical layer (PHY) offers a highly efficient means of
conveying data and control information between the eNodeB and the UE.
The E-UTRA PHY employs some advanced technologies that are quite
new to cellular applications. These include Orthogonal Frequency Division
Multiplexing (OFDM) and Multiple Input Multiple Output (MIMO) data
transmission, as described in chapters 2 and 3.

On the other hand, the LTE standardisation project aims at reusing legacy
solutions wherever possible. A reader who is familiar with the UTRAN
channel and protocol architecture will therefore feel quite ‘at home’ with
the E-UTRAN channel and protocol architecture. The LTE standardisation
project also aims at reducing the overall system complexity, resulting in a
simplified layered architecture as compared to UTRAN.

The E-UTRA specifications describe both Frequency Division Duplex


(FDD) and Time Division Duplex (TDD) to separate UL and DL traffic.
The overall channel architecture, layer 1 processing chain and resource
mapping is the same for both. Thus, the content in this chapter pertains to
both FDD and TDD, unless otherwise stated. (The expected market
preferences dictate that the majority of deployed systems will be FDD.)

The generic radio frame structure (‘frame Type 1’) and the TDD specific
radio frame structure (‘frame Type 2’) is described in section 4.2. The E-
UTRA channel architecture, focusing on the physical channels and
physical signals, is described in section 4.3. The associated layer 2 and
layer 3 protocol architecture is dealt with separately in chapter 5. The layer
1 processing chain for the uplink and downlink data channels is described
in section 4.4. Section 4.5 deals with the mapping of uplink and downlink
data and control channels onto 2-dimensional time-frequency radio
resources.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-2
4.2 Radio Frame Structure
4.2.1 Frame Type 1
1 Radio Frame = 10ms

#0 #1 #2 #3 #4 #5 #6 #7 #18 #19

slot 0 slot 19

1 slot = 1 subframe = 1ms


0.5ms

Figure 4-1: E-UTRA frame Type 1

All bandwidth options have the same basic Transmission Time Interval
(TTI) of 1ms. As shown in figure 4-1, the E-UTRA radio frames are 10 ms
in duration, divided into 10 sub-frames of 1ms duration. Thus, the
subframe length coincides with the TTI. Each subframe is further divided
into two slots, each of 0.5ms duration.

As mentioned earlier, the downlink transmission scheme is based on


conventional OFDM with cyclic prefix and the uplink transmission
scheme is based on SC-FDMA with cyclic prefix. Both downlink and
uplink use the same cyclic prefix lengths and the same sub-carrier spacing
of 15 kHz. In addition there is also a reduced sub-carrier spacing, 7.5 kHz,
for MBMS-dedicated cells. In the case of 15 kHz sub-carrier spacing there
are two cyclic prefix lengths, corresponding to 7 and 6 OFDM/SC-FDMA
symbols per slot respectively:

• Normal cyclic prefix: TCP = 160×Ts (symbol #0) and TCP = 144×Ts
(symbol #1 to #6). The slightly longer CP in the first symbol is in
order to preserve the 0.5ms slot timing.

• Extended cyclic prefix: TCP-e = 512×Ts (all symbols). The extended


CP is intended for large cells, where larger delay spreads for
multipath echoes are to be expected.

The parameter Ts above is called the ‘basic time unit’ and is defined as
being Ts = 1/ (2048 × Δf) seconds, where Δf is the sub-carrier spacing. The
length of Ts corresponds to the 30.72 MHz sample clock for the 2048-point
FFT used with the 20 MHz system bandwidth.

In case of 7.5 kHz sub-carrier spacing there is only a single cyclic prefix
length, TCP-low = 1024×Ts, corresponding to 3 OFDM symbols per slot.

The generic frame Type 1 can also be used for TDD operation in unpaired
spectrum. DL/UL switching points within the frame are then generated by
not transmitting in certain symbols (creating a guard period between
uplink and downlink transmissions in different sub-frames).
Apis Technical Training AB
LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-3
4.2.2 Frame Type 2
1 Half-frame = 5 ms

1 Radio Frame

#0 #1 #2 #3 #4 #5 #6 #0 #5 #6

DL UL

Uplink Pilot Timeslot


1 Slot =
Guard Period 1 Subframe
Guard Intervals
Downlink Pilot Timeslot

Figure 4-2: E-UTRA frame Type 1

Frame structure Type 2 is only applicable to TDD, with the sole purpose of
being backwards compatible with the 1.28Mcps TDD option in UMTS.
1.28Mcps TDD is the Chinese 3G standard, also known as Low Chip-rate
TDD (LCR-TDD) or Time Division Synchronous Code Division Multiple
Access (TD-SCDMA).

Each 10ms radio frame consists of two half-frames of length 5ms each.
The structure of each half-frame in a radio frame is identical. Each half-
frame consists of seven slots and three special fields: the downlink pilot
timeslot (DwPTS), the guard period (GP) and the uplink pilot timeslot
(UpPTS). A subframe is defined as one slot. This frame structure is
identical to the one used for TD-SCDMA.

Subframe 0 and DwPTS are always reserved for downlink transmission


and UpPTS and subframe 1 are always reserved for uplink transmission.

For frame structure Type 2 the CP length in the downlink is TCP = 224×Ts
(normal CP) and TCP-e = 512×Ts (extended CP) corresponding to 9 and 8
OFDM symbols per slot respectively.

For the uplink the situation is slightly less straightforward when it comes
to CP lengths. There are several CP lengths used within each slot,
depending on the size of the allocated uplink resource and the index of the
SC-FDMA symbol within a slot. The normal CP length is 192, 204, 224,
320, 1024 and 2048×Ts, corresponding to 9 SC-FDMA symbols. The
extended CP length is 423, 456, 472, 560, 1024 and 2048×Ts,
corresponding to 8 SC-FDMA symbols.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-4
4.3 Channel Architecture
CONTROL PLANE USER PLANE

RRC PDCP

SRB SRB SRB SRB SRB RB RB

RLC

Logical
Channels BCCH PCCH CCCH DCCH MCCH MTCH DTCH

MAC
SCHEDULING/ PRIORITY

MUX/DEMUX

HARQ HARQ

Transport
Channels
BCH RACH PCH DL-SCH MCH UL-SCH

PHY

Physical
Channels PBCH PRACH PHICH PCFICH PDCCH PDSCH PMCH PUSCH PUCCH

Figure 4-3: E-UTRAN channel architecture

There are three different channel ‘levels’ in the E-UTRA channel


architecture: Logical channels, Transport channels and Physical channels.
The logical channels describe the type of information to be transmitted, the
Transport channels describe in what format the information is to be
transmitted and the physical channels provide the transmission media
through which the information is actually transmitted.

Some logical channels can be mapped to one of several different transport


channels, depending on the transmission characteristics needed. Flows
from several logical channels can, in the same time instant, be mapped to
the same transport channel. Thus, there is not necessarily a one-to-one
relationship between logical and transport channels.

Please note also the ‘location’ of Signalling Radio Bearers (SRB) and
Radio Bearers (RB) above the Radio Link Control protocol in figure 4-3.
The SRBs are used for RRC control signalling and the RBs are used for
any form of data traffic.

4.3.1 Logical Channels


A logical channel is an information stream dedicated to the transfer of a
specific type of information over the radio interface. Logical channels are
provided between the Radio Link Control (RLC) and Medium Access
Control (MAC) protocol layers in UE and eNodeB. There is a general
classification of logical channels into two groups: Control Channels and
Traffic Channels.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-5
Control Channels
Broadcast Control Channel (BCCH). Downlink channel for broadcasting
system information. BCCH is mapped onto the BCH and DL-SCH
transport channels.

Paging Control Channel (PCCH). Downlink channel that carries paging


information. Always mapped onto the PCH transport channel.

Common Control Channel (CCCH). This is a bi-directional channel for


transmitting initial RRC control signalling between the UE and eNodeB.
The CCCH logical channel is always mapped onto the UL/DL-SCH
transport channels.

Dedicated Control Channel (DCCH). Point-to-point bi-directional channel


for sending dedicated RRC control signalling between the UE and the
eNodeB. This channel is always mapped onto the UL/DL-SCH transport
channels.

Multicast Control Channel (MCCH, optional). A point-to-multipoint


downlink only channel used for transmitting Multimedia Broadcast
Multicast Service (MBMS) control information from the network to the
UE. This channel is only used by UEs that receive MBMS transmissions.
The MCCH is mapped to the MCH transport channel in case of an
MBMS-dedicated cell or a cell taking part in Single Frequency Network
(SFN) transmission. For mixed traffic cells the MCCH is mapped onto the
DL-SCH transport channel.

Traffic Channels
Dedicated Traffic Channel (DTCH). Point-to-point channel dedicated to
one UE (uplink or downlink or both) for transmission of user data. Always
mapped onto the UL/DL-SCH transport channels.

Multicast Traffic Channel (MTCH, optional). A point-to-multipoint


downlink only channel for transmission of multimedia traffic (e.g. mobile
TV) from the network to the UE. This channel is only used by UEs that
receive MBMS transmissions. The MTCH is mapped to the MCH
transport channel in case of an MBMS-dedicated cell or a cell taking part
in Single Frequency Network (SFN) transmission. For mixed traffic cells
the MTCH is mapped onto the DL-SCH transport channel.

4.3.2 Transport Channels


Transport channels are offered from PHY to MAC for signalling or data
transport. Different transport channels are defined by how and with what
characteristics the information is transmitted on the physical layer.
Information on transport channels is delivered to/from the physical layer in
the form of Transport Blocks (TB).

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-6
One or two Transport Blocks are delivered per Transmission Time Interval
(TTI). The TTI length selected for E-UTRA is 1ms for most transport
channels. A Transport Format (TF) is a combination of TB size (in bits),
TTI length and layer 1 channel coding and modulation selected for a given
transmission.

Downlink Transport Channels


Broadcast Channel (BCH). Carries part of the System Information (SI) in
a cell. The SI transmitted over BCH is contained in the Master Information
Block (MIB) that carries information such as system bandwidth, number
of eNodeB antennas for MIMO operation and the transmit power used for
downlink reference signals (Reference Signal Transmit Power, RSTP).
The BCH is mapped onto the PBCH physical channel.

The MIB also carries the scheduling information for Scheduling Unit 1
(SU-1). SU-1 contains the most often repeated non-BCH SI and is mapped
onto the DL-SCH. SU-1 contains the PLMN id, Tracking Area Code
(TAC) and the cell id. It may also contain scheduling information for
additional SI (i.e. scheduling for SU-2 etc).

Paging Channel (PCH). The PCH carries paging messages from eNodeB
to the UE (or group of UEs). The PCH is mapped onto the same physical
resource as the DL-SCH.

Downlink Shared Channel (DL-SCH). This is the main downlink resource


in E-UTRA. It carries data (DTCH or MTCH) and signalling (BCCH,
CCCH, DCCH and MCCH). The DL-SCH uses hybrid-ARQ (HARQ),
channel dependent packet scheduling and adaptive modulation and coding.
The DL-SCH is mapped onto the PDSCH physical channel.

Multicast Channel (MCH). Carries MBMS data and control information in


case of an MBMS-dedicated cell or a cell taking part in SFN transmission.
The MCH is mapped onto the PMCH physical channel.

Uplink Transport Channels


Random Access Channel (RACH). Uplink channel used to carry control
information from the UE to the eNodeB. The RACH is used for initial
access, when the UE is not known in the eNodeB. It is also used when a
known UE wishes to transmit on the PUSCH or PUCCH, but does not
have a valid uplink grant (or when the last assigned timing advance value
has expired). The corresponding physical channel is the PRACH.

Uplink Shared Channel (UL-SCH). This is the main uplink resource in E-


UTRA. It carries data (DTCH) and signalling (CCCH and DCCH). The
UL-SCH uses hybrid-ARQ (HARQ), channel dependent packet scheduling
and adaptive modulation and coding. The UL-SCH is mapped onto the
PUSCH physical channel.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-7
4.3.3 Physical Channels
The E-UTRA specifications define a physical channel as “a set of resource
elements carrying information originating from higher layers” (please refer
to section 4.5 for an explanation of the ‘resource element’ concept).

Downlink Physical Channels


Physical Broadcast Channel (PBCH). This channel carries the MIB from
the BCH transport channel. The PBCH uses a TTI of 40ms.

Physical Downlink Shared Channel (PDSCH). This is the main downlink


radio resource in a cell, carrying data and/or higher layer signalling. The
PDSCH is allocated to different UEs on a per-TTI basis (i.e. every 1ms).
The channel coding, modulation and sub-carrier allocation is dynamic.
Since the PDSCH is a shared resource, and since the Transport Format
used is dynamic, all downlink transmissions must be explicitly addressed
to the receiving UE. This is done on the PDCCH.

Physical Downlink Control Channel (PDCCH). The downlink control


channel is used for indications of downlink transmission on PDSCH as
well as for allocation of uplink resources on PUSCH/PUCCH. The
PDCCH signalling is located in the first 1-3 OFDM symbols in each 1ms
long sub-frame. It consists of: UE identity, Transport Format, downlink
resource allocation and hybrid-ARQ information related to DL-SCH (and
PCH). In addition it contains uplink grant, Transport Format and transmit
power commands for uplink transmissions on the PUSCH or PUCCH.
Transmission of control signalling from these groups is mutually
independent, e.g. an uplink grant can be transmitted to a UE regardless of
whether the same UE is receiving downlink data or not.

Multiple physical downlink control channels are supported and a UE


monitors a set of control channels. Control information for DL-SCH on the
PDCCH relates to downlink data transmission in the same subframe.
Control information for UL-SCH on the PDCCH relates to uplink data
transmission in a future subframe. Exactly what is meant by ‘future
subframe’ has not been decided at the time of writing but will probably be
in the order of 3-4 sub-frames after reception of the PDCCH. The PDCCH
can be transmitted with 4 different formats, which may change on a per
sub-frame basis. This necessitates the use of the PCFICH channel.

Physical Control Format Indicator Channel (PCFICH). The sole purpose


of this physical channel is to indicate the format used for the PDCCH
transmission in the same sub-frame.

Physical HARQ Indicator Channel (PHICH). The purpose of this channel


is to transmit ACK/NACKs related to uplink transmissions on the PUSCH.
Thus, each PHICH is addressed to a single UE at a time. There is an
implicit relation between the uplink resource (sub-carriers) used for data
transmission and the downlink resource used by the PHICH.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-8
The exact timing relationship between uplink data transmission on PUSCH
and downlink ACK/NACK on PHICH has not been decided at the time of
writing but 2-4ms seem to be reasonable.

Physical Multicast Channel (PMCH). This channel carries MBMS data


and control in case of an MBMS-dedicated cell or SFN transmission.

Uplink Physical Channels


Physical Uplink Shared Channel (PUSCH). This is the main uplink radio
resource in a cell, carrying data and/or higher layer signalling. The
PUSCH is allocated to different UEs on a per-TTI basis (i.e. every 1ms).
The channel coding, modulation and sub-carrier allocation is dynamic.
Since the PUSCH is a shared resource, and since the Transport Format
used is dynamic, all uplink transmissions must be explicitly allocated to a
given UE. This is done on the PDCCH as mentioned above.

Physical Uplink Control Channel (PUCCH). The PUCCH conveys uplink


control information in the form of channel quality indicator (CQI), uplink
scheduling requests and ACK/NACKs for data received on the PDSCH.
This channel is never transmitted simultaneously with PUSCH data,
meaning that the ‘PUCCH’ control information is instead transmitted on
the PUSCH if an uplink grant for data transmission exists in the UE. It can
be assumed that the options for CQI reporting will allow both periodic and
‘on-demand’ reporting. The exact content and meaning of the CQI values
as well as the timing between downlink data and uplink ACK/NACK has
not been decided at the time of writing.

Physical Random Access Channel (PRACH). The PRACH carries the


random access preambles (see below) during the random access procedure.

4.3.4 Physical Signals


The E-UTRA specifications define a physical channel as “a set of resource
elements carrying information originating from higher layers”. Similarly, a
physical signal is defined as “a set of resource elements not carrying
information originating from higher layers”. Hence they constitute “pure”
layer 1 information, in the sense that they originate from layer 1 on the
transmitting side and are never visible from higher protocol layers on the
receiving side.

Downlink Physical Signals


There are two types of downlink physical signals: Reference Signals (RS)
and Synchronisation Signals (SS). The Reference Signals are used by the
UE for channel estimation purposes (to determine the so-called channel
impulse response, CIR). A different RS is transmitted from each antenna
port to facilitate MIMO and/or Tx diversity operation. The UE must get an
accurate CIR from each transmitting antenna. Therefore, when a reference
signal is transmitted from one antenna port the other antenna ports in the
cell are idle. Reference signals are sent on every sixth sub-carrier and CIR
Apis Technical Training AB
LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-9
estimates for sub-carriers that do not carry reference signals are computed
via interpolation. The exact mapping of the RSs can be seen in figure 4-8
in section 4.5.2 below.

Reference Signals are generated as the product of an orthogonal sequence


and a pseudo-random sequence. These sequences are standardised and
hence known to the UE. From system information (the parameter RSTP
mentioned earlier) the UE also knows the output power used by the
eNodeB for RS transmission. Specified Reference Signals are assigned to
each cell within a network.

There are two types of Synchronization Signals: the Primary SS and the
Secondary SS. The SSs convey network timing information and are used
by the UE during the cell search procedure (e.g. after power-on or cell re-
selection). The Primary SS provides the UE with slot synchronisation and
the Secondary SS provides frame synchronisation. The combination of
Primary and Secondary SS also act as a cell-specific identifier called the
Physical Cell identity. Overall there are 510 unique sequences possible,
meaning that the sequences are reused if the system consists of more than
510 cells. Synchronization Signals use the same type of pseudo-random
orthogonal sequences as the Reference Signals.

Uplink Physical Signals


Three different uplink physical signals are defined: the Demodulation RS,
the Sounding RS and the Random Access Preamble. All uplink physical
signals discussed are derived from predefined so-called Zadhoff-Chu
sequences. The Demodulation RS, as the name suggests, is used by
eNodeB for coherent demodulation of uplink transmissions (i.e. the RS is
used for channel estimation). The Demodulation RS is always sent by the
UE as part of each PUSCH or PUCCH transmission.

The Sounding RS is used (when needed) to facilitate frequency dependent


scheduling by the eNodeB. By ordering the UE (or group of UEs) to
transmit a Sounding RS using the full system bandwidth (or a subset
thereof) the eNodeB can estimate which sub-carriers that are best suited,
from a radio condition point of view, for the UEs uplink transmissions.
The Sounding RS can also be used in cases where the eNodeB does not
receive enough uplink data or control signalling to properly update the
timing advance and/or transmit power commands for a given UE (or group
of UEs).

The Random Access Preamble is used for the random access procedure,
when the UE wishes to initiate uplink transmission and does not have a
valid uplink grant. The UE transmits a random access burst consisting of a
long cyclic prefix, the preamble itself and a guard period during which
there is no signal transmitted. The burst is sent on blocks of 72 contiguous
sub-carriers allocated for random access by the eNodeB. There are 64
possible preamble sequences per cell.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-10
From the physical layer perspective, the random access procedure
encompasses the transmission of Random Access Preambles until a
Random Access Response is received (or the maximum allowed number of
preambles have been sent without response). The UE will ramp up its
output power for each random access burst transmission until it gets a
reply, thus providing a simple initial power control scheme. After this, the
eNodeB controls the UE output power by means of a-periodic transmit
power commands as part of the uplink grants on the PDCCH.

4.4 Layer 1 Processing Chain


The layer 1 processing is different for different transport/physical
channels. Most of the physical control channels use convolutional coding
with a code rate of 1/3 (meaning 1 bit input to the convolutional coder
produces 3 bits output) and only QPSK modulation. The processing of the
physical control channels is not treated further in this document. The
following sections look closer at the processing of the main transport
channels in E-UTRA: DL-SCH and UL-SCH.

4.4.1 Downlink Shared Channel (DL-SCH)


DL-SCH

CRC
Scrambling
Attachment

Code Block
Modulation
Segmentation

Turbo Coding Layer


R = 1/3 Mapping


L1 HARQ
Precoding
Rate Matching

Code Block RE … RE
Concatenation Mapper Mapper

OFDM OFDM
Signal … Signal
Generation Generation

Figure 4-4: downlink layer 1 processing chain

Figure 4-4 above shows the processing chain for the DL-SCH transport
channel. Data arrives to layer 1 over the DL-SCH transport channel in the
form of one or more transport block (MAC PDU) per 1ms TTI.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-11
CRC Attachment
A 24-bit Cyclic Redundancy Check field (CRC) is added for error
detection. This information is used in the receiver, after decoding the
transport block, to check if the transport block has been correctly decoded
or if there are residual bit errors. The receiver transmits a HARQ ACK if
the block is successfully decoded or a HARQ NACK if errors are detected.

Code Block Segmentation


This step is performed if the number of bits output from the CRC
attachment stage is higher than 6144, which is the maximum number of
input bits the Turbo coder can handle. The result after segmentation is an
integer number of equally sized blocks, possibly with padding bits added.

Channel Coding
The error correcting coder selected for DL-SCH is a Parallel Concatenated
Convolutional Code (PCCC) with two 8-state constituent encoders and one
turbo code internal interleaver (simply called ‘the Turbo coder’ in the
following). The coding rate of the Turbo encoder is 1/3. This is the same
Turbo code used as in R6 UMTS, with the exception that the internal
interleavers works differently.

Turbo codes are error correcting codes with performance coming very
close to the Shannon limit, the theoretical limit of maximum information
transfer rate over a noisy channel. Thus, Turbo codes make it possible to
increase available bandwidth without increasing the power of a
transmission, or to decrease the power used to transmit at a certain data
rate. The main drawback is the relatively high decoding complexity.

The Turbo coder consists of two recursive convolutional coders that each
operate (differently) on the input bit sequence. The output from the coder
is three sub-blocks of bits: the Systematic bits, which are identical to the
input sequence, and the Parity1 bits and Parity2 bits, which are the output
sequences from the two internal convolutional coders. The number of
input bits divided by the total number of output bits is referred to as the
coding rate (R). In general, if the number of Systematic bits is m and the
number of Parity1 and Parity2 bits is n/2 respectively, the coding rate
becomes m/(m+n). The Turbo coder used in E-UTRA produces an equal
number of Systematic, Parity1 and Parity2 bits. Hence, the coding rate
becomes R=1/3.

Thus, two redundant but different sub-blocks of Parity bits are sent
together with the uncoded payload (the Systematic bits). The two sets of
Parity bits are used by the Turbo decoder in the receiver to calculate the
probability that the payload bits have been decoded correctly. Each of the
two convolutional decoders generate a ‘hypothesis’ for the payload. The
hypothesis bit-patterns are compared and if they differ the decoders
exchange the derived likelihoods they have for each bit in the hypotheses.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-12
Each decoder incorporates the derived likelihood estimates from the other
decoder to generate a new hypothesis for the bits in the payload. Then they
compare these new hypotheses. This iterative process continues until the
two decoders come up with the same hypothesis for the Systematic bits.

The DL-SCH always applies an R=1/3 Turbo code for error correction.
However, all bits from the three output sequences (Systematic, Parity1,
Parity2) are not always sent. The number of bits from each set that are
actually transmitted depends on the applied L1 HARQ rate matching.

L1 HARQ Rate Matching


Rate matching (RM) means that bits on a (channel coded) transport
channel are repeated or punctured, with the purpose of adapting the
number of bits at the output of the channel coder to the total number of bits
available on the physical channel. The RM method used in E-UTRA is
based on a concept called a circular buffer. The Systematic bits are written
into a portion (one third) of a rate matching buffer. The Parity1 and parity2
bits are scrambled and interleaved and then written into the remaining two-
thirds of the buffer.

A subset of all the bits in the buffer are then read out and transmitted. The
subset is selected simply by letting an offset define where to start reading
consecutive bits in the buffer (e.g. ‘start reading from bit-position 50’).
The offset is decided based on the Redundancy Version (RV) selected for
the transmission. Thus, the exact set of bits at the output of the HARQ-RM
depends on the number of input bits from the Turbo coder, the number of
bits to be transmitted and the selected RV.

This process makes it easy to select different sets of coded bits from the
same Transport Block to be transmitted each time a re-transmission is
requested, thus allowing Incremental Redundancy operation - also known
as HARQ type-II. A type-II HARQ scheme makes use of the transport
blocks that cause retransmission requests (i.e. erroneous transport blocks
are not discarded). An erroneous transport block will be stored and later
combined with retransmitted version(s) of itself; thereby creating a single
combined transport block that is more reliable than any of its constituent
parts. The versions of one and the same transport block are produced by
selecting different RVs.

Code Block Concatenation


If the Code Block Segmentation stage mentioned earlier resulted in more
than one code block, they will all have been processed separately up to this
point. The Code Block Concatenation stage simply concatenates the Turbo
coded and rate matched blocks into a single so-called code word prior to
further processing. This stage does not add, remove or alter any bits.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-13
Scrambling
The bits in the code word are scrambled with a cell specific scrambling
sequence prior to modulation.

Modulation
Standard QPSK, 16QAM or 64QAM modulation mapping, resulting in
complex modulation symbols carrying 2, 4 or 6 coded bits respectively.

Layer Mapping
The modulation symbols from one or two (scrambled) code words are
mapped onto 1, 2, 3 or 4 antenna ports. Thus, this step is related to MIMO
or Tx diversity operation. Basically, a layer corresponds to a spatial
multiplexed channel. For E-UTRA the defined configurations are 1x1,
2x2, 3x2 and 4x2 MIMO/diversity. Note that while there are as many as
four transmitting antennas (four layers) there are only a maximum of two
receivers and thus a maximum of two spatial multiplexed data streams
(two code words). For a 1x1 or a 2x2 system there is a simple 1:1
relationship between layers and transmitting antenna ports. However, for a
3x2 and 4x2 system there are still only two spatial multiplexed channels.
Therefore, there is redundancy on one or both data streams. The Layer
Mapping stage specifies exactly how the extra transmitter antennas are to
be employed.

Precoding
This step is also related to MIMO or Tx diversity. Precoding is applied to
allow the UE to separate the different antenna streams. There are different
standardised code books defined for the cases of spatial multiplexing (SU-
MIMO and MU-MIMO) and Tx diversity. This corresponds to the Space-
Time Coding discussed in chapter 3.

Resource Element Mapping


The precoded code words are mapped onto a number of 2-dimensional
time-frequency Resource Elements available for the transmission. This
step is described in more detail in section 4.5.

OFDM Signal Generation


OFDM symbols are created, as described in chapter 2, using the number of
sub-carriers allocated for the transmission. A cyclic prefix is appended to
each OFDM symbol and the symbols (with CP) are then mapped onto 2
consecutive radio frame slots constituting a subframe. The Resource
Element Mapping stage and the OFDM Signal Generation stage takes
place separately for each antenna port assigned for the transmission.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-14
4.4.2 Uplink Shared Channel (UL-SCH)
UL-SCH

CRC Code Block


Attachment Concatenation

Code Block
Scrambling
Segmentation

Turbo Coding Uplink control Transform


R = 1/3 bits Precoding

L1 HARQ RE
Channel Coding
Rate Matching Mapper

SC-FDMA
Data/Control
Signal
Multiplexing
Generation

Figure 4-5: uplink layer 1 processing chain

The processing chain for the UL-SCH transport channel is very similar to
the one for the DL-SCH. Only differences are described in the following.

Data/Control Multiplexing
Since the PUSCH and the PUCCH physical channels are never transmitted
simultaneously, there is instead a possibility to multiplex the ‘PUCCH’
control information with the uplink data transmitted on the PUSCH. The
control information is channel coded separately prior to this stage.

Scrambling
Scrambling with a UE specific scrambling sequence.

Transform Precoding
This is the ‘FFT-spreading’ step as described for the uplink in chapter 2.
That is, the modulation symbols are spread over the entire allocated
bandwidth, creating a single-carrier signal.

RE Mapping & SC-FDMA Signal Generation


The difference to DL-SCH is that there is ever only one antenna port used
for the uplink (no need for layer mapping and precoding). Furthermore, the
last step will create SC-FDMA symbols instead of OFDM symbols.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-15
4.5 Resource Mapping
Note: the mapping of physical channels to resource elements described in
this section assumes the use of frame Type 1 and normal cyclic prefix.

4.5.1 Resource Definitions


#0 #1 #2 #3 #4 #5 #18 #19

Control
Channel
Element

Physical
Sub-carriers

Resource
Block

Resource
Element

OFDM symbols

Figure 4-6: Physical Resource Block (PRB)

The downlink and uplink resources assigned to UEs for the DL-SCH and
UL-SCH transmission are referred to as Physical Resource Blocks (PRB).
A PRB consists of 12 consecutive sub-carriers in the frequency domain. In
the time domain a PRB consists of Nsymb OFDM (or SC-FDMA)
symbols, where Nsymb is the number of symbols during a slot (7 in this
case). The number of resource blocks, NRB, that may be assigned to the UE
can range from NRB-min = 6 to NRB-max = 100.

The 2-dimensional time-frequency resource can be represented as a


resource grid as depicted in Figure 4-6. Each little box within the grid
represents a single sub-carrier for one symbol period and is referred to as a
Resource Element (RE). Figure 4-6 shows the resource grid for frame
Type 1 using the normal cyclic prefix length, resulting in each PRB
containing 84 REs. Note that in MIMO operation there is a resource grid
for each transmitting antenna.
Apis Technical Training AB
LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-16
The downlink control channels use a slightly different concept. They are
formed by aggregation of Control Channel Elements (CCE). Each CCE is,
in turn, an aggregation of 1, 2, 4 or 8 mini-CCEs, where each mini-CCE
consists of 4 REs. Thus, a CCE varies in size between 4 and 32 REs.

Different code rates (i.e. different levels of robustness) for the PDCCH are
realized by aggregating different numbers of CCEs or mini-CCEs. Because
multiple CCEs can be combined to reduce the effective coding rate the
UE’s PDCCH assignment can be based on the channel quality information
reported (CQI), increasing the chance that the PDCCH can be correctly
decoded even for UEs experiencing bad channel conditions. 1, 2, 4 and 8
control channel elements can be aggregated to yield approximate code
rates of 2/3, 1/3, 1/6 and 1/12 for the PDCCH.

4.5.2 Downlink Subframe


#0 #1 #2 #3 #4 #5 #18 #19
12 Sub-carriers

Slot #4 Slot #5

RE for PDCCH, PCFICH and PHICH

RE for PDSCH

RE for antenna RS

Figure 4-7: subframe with PDSCH, PDCCH, PDCCH, PCFICH and PHICH

The resource grid for a downlink subframe is illustrated in figure 4-7


(frame type 1 using normal cyclic prefix length and one antenna port). The
grid is shared between all downlink physical channels and signals. Only
two PRBs are shown in figure 4-7.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-17
Downlink Physical Control Channels
The PHICH channel (ACK/NACK for uplink transmissions) is located in
the 1st or 3rd OFDM symbol of the subframe and always occupies 3 mini-
CCEs (12 REs). The resources used for the PHICH are configured on a
semi-static basis, i.e. the UE knows where to look for it (in terms of REs).

The PCFICH channel signals the number of OFDM symbols (1-3) used for
PDCCH signaling in each subframe. The PCFICH is transmitted in the
first OFDM symbol of the subframe and occupies 4 mini-CCEs (16 REs).

The PDCCH is mapped onto the remaining REs in the 1-3 first OFDM
symbols in the first slot of each subframe. This enables support for micro-
sleep, i.e. the UE can wake up within one symbol and, seeing no
assignment, go back to sleep within one symbol for battery life savings
and reduced buffering. It also allows reception of downlink data, if the UE
finds an assignment, in the very same subframe, thus reducing latencies.

Downlink Shared Channel, DL-SCH


The DL-SCH uses the REs ‘remaining’ after allocation of PCFICH,
PDCCH, PHICH and downlink RSs. Thus, all the 84 REs in each Physical
Resource Block cannot be used for actual data transmission!

Downlink Reference Signals


Figure 4-7 above shows the antenna RSs (black REs) in case only one
antenna port is used. Figure 4-8 below shows the case when 2 ports are
used. Please note that the two grids are transmitted simultaneously on the
two antenna ports.

Slot # i Slot # i+1 Slot # i Slot # i+1

R1 R1 R2 R2
12 Sub-carriers

R1 R1 R2 R2

R1 R1 R2 R2

R1 R1 R2 R2

R1 RS for antenna port 1 R2 RS for antenna port 2


REs that cannot be used

Figure 4-8: mapping of antenna reference signals (2 antenna ports)

Antenna RSs are transmitted on equally spaced sub carriers within the first
and third from-last OFDM symbol of each slot. In order to successfully
receive a MIMO transmission the UE must determine the channel impulse
response for each transmitting antenna, as already mentioned.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-18
In E-UTRA the channel impulse responses are determined by sequentially
transmitting known reference signals from each transmitting antenna. Note
that the RSs are transmitted on every 6th sub-carrier in a repeated,
symmetric, time-frequency pattern. Note also that while one transmitter
antenna is sending its Reference Signal, the other antenna is idle.

4.5.3 Downlink Cell Search Pattern


Slot #0 Slot #1
#0 #1 #2 #3 #4 #5 #6 #0 #1 #2 #3 #4 #5 #6
36

DC

36

Antenna RS (1 port) Secondary SS REs for PBCH


Primary SS

Figure 4-9: primary and secondary synchronisation signals and PBCH

During cell search the UE needs to find the Primary and Secondary
Synchronisation Signals as well as the Physical Broadcast Channel
(PBCH). These are all mapped around the center sub-carrier in the system.
This center sub-carrier is called the Direct Current (DC) sub-carrier and
never carries any information.

The Primary and Secondary SS are transmitted in slot 0 and 10 on 64 sub-


carriers centered around the DC sub-carrier. The Secondary SS occupies
the 6th OFDM symbol and the Primary SS occupies the 7th. The PBCH is
transmitted on 72 sub-carriers centered around the DC sub-carrier in the 4th
and 5th OFDM symbol in slot 0 and the 1st and 2nd OFDM symbol in slot 1,
over 4 consecutive radio frames. Slots 0 and 1 are shown in fig 4-9,
including Reference Signals for one antenna port.

4.5.4 Uplink Subframe: PUSCH


For the uplink the PRBs are shared between the PUSCH, for actual data
transmission, and the uplink Demodulation RSs. The Demodulation RS is
transmitted using the same sub-carriers as those assigned for the associated
PUSCH transmission and occupies the 4th SC-FDMA symbol in each slot.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-19
Note that figure 4-10 below only shows two PRBs, while the minimum UE
allocation is 6 PRBs (i.e. 36 sub-carriers).

#0 #1 #2 #3 #4 #5 #18 #19

12 Sub-carriers

Slot #4 Slot #5

RE for PUSCH RE for Demodulation RS

Figure 4-10: PUSCH subframe with demodulation signal

4.5.5 Uplink Subframe: PUCCH

#0 #1 #2 #3 #4 #5 #18 #19
12 Sub-carriers

RE for PUCCH

Demodulation RS
12 Sub-carriers

Slot #4 Slot #5

Figure 4-11: PUCCH subframe with demodulation signal

The PUCCH resource is defined by a UE specific code and two


consecutive PRBs with frequency hopping at slot boundary. Demodulation
RS occupies the 3rd, 4th and 5th SC-FDMA symbol in each slot.

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-20
4.6 References
36.211 E-UTRA; Physical channels and modulation
36.212 E-UTRA; Multiplexing and channel coding
36.213 E-UTRA; Physical layer procedures

Apis Technical Training AB


LTE - Physical Layer
Copyright © Apis Technical Training AB 2007. All rights reserved. 4-21
5 E-UTRA Layer 2 & 3
5.1 INTRODUCTION .............................................................. 5-2
5.2 LAYER 2 & 3 PROTOCOLS .............................................. 5-3
5.2.1 Non Access Stratum (NAS) .....................................................5-3
5.2.2 Radio Resource Control (RRC) ...............................................5-3
5.2.3 Packet Data Convergence Protocol (PDCP) ...........................5-4
5.2.4 Radio Link Control (RLC) .........................................................5-6
5.2.5 Medium Access Control (MAC)................................................5-6
5.3 UE STATES (RRC AND NAS) ........................................ 5-8
5.4 PDU FORMATS ............................................................. 5-9
5.5 REFERENCES .............................................................. 5-11

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-1
5.1 Introduction
CONTROL PLANE USER PLANE

RRC PDCP

SRB SRB SRB SRB SRB RB RB

RLC

Logical
Channels BCCH PCCH CCCH DCCH MCCH MTCH DTCH

MAC
SCHEDULING/ PRIORITY

MUX/DEMUX

HARQ HARQ

Transport
Channels
BCH RACH PCH DL-SCH MCH UL-SCH

PHY

Physical
Channels PBCH PRACH PHICH PCFICH PDCCH PDSCH PMCH PUSCH PUCCH

Figure 5-1: E-UTRA channel and protocol architecture

The E-UTRA layer 2 and layer 3 protocol architecture can be seen in


figure 5-1 above (same as figure 4-3, previous chapter). The protocols are
by name and (proposed) function similar to the protocol architecture used
in UTRAN. There are two main differences though:

• Firstly, the E-UTRA protocols are, on the network side, all located
in the eNodeB while they are distributed over Serving-RNC, Drift-
RNC and NodeB in the UTRAN case.
• Secondly, the E-UTRA ‘versions’ of these protocols will, when
they are completely standardised, all be simplified in terms of
complexity and functionality when compared to the UTRAN
counterparts.

Section 5.2 deals with the proposed functionality of the E-UTRA layer 2/3
protocols. Section 5.3 describes the UE state machine related to the RRC
and NAS protocols. Section 5.4 shows the PDU formats defined for the E-
UTRA layer 2 and layer 3 protocols.

At the time of writing (Oct-07) the specifications pertaining to these


protocols are all immature drafts. The reader is therefore strongly advised
to regularly check for updated versions of the standardisation documents
listed at the end of this chapter.

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-2
5.2 Layer 2 & 3 Protocols
5.2.1 Non Access Stratum (NAS)
The Non-access Stratum (NAS) protocols are used between the UE and the
Evolved Packet Core (the MME to be more precise) and are therefore,
strictly speaking, not E-UTRA protocols. All NAS signalling exchange
takes place transparently through the radio access network (i.e. the
eNodeB will never interpret these messages).

The NAS layer sits ‘on top’ of the RRC layer in the UE (not shown in
figure 5-1). All NAS messages are either carried inside, or sent
concatenated with, RRC messages when transmitted over the radio
interface.

There will probably be only two LTE/SAE NAS protocols defined: The
EPC Mobility Management protocol (EMM) and the Session Management
protocol (SM).

The EMM protocol is very similar to the corresponding GSM/UMTS MM


and GMM protocols. EMM is responsible for procedures such as:
• Paging of UE in idle mode.
• Network Attach, i.e. UE registration in the MME and establishment
of basic IP-connectivity.
• Authentication and NAS key agreement (read more about security
in the PDCP section).
• Tracking Area update (the concept of a ‘Tracking Area’ is fully
analogous to the Location/Routing Area concept).
• SAE-TMSI (S-TMSI) allocation.

The SM protocol is responsible for the establishment and management of


default and dedicated SAE bearers and is similar to the GPRS/UMTS SM
protocol (which is responsible for management of PDP contexts). The
SAE bearer and QoS concepts are discussed further in chapter 7.

5.2.2 Radio Resource Control (RRC)


The RRC protocol is responsible for all layer 3 control signalling exchange
between the UE and the eNodeB. It is expected that the functionality, on
the procedure level, will be very similar to the UTRAN RRC protocol.
Some RRC procedures are briefly described in the following.

Broadcast of System Information


The purpose of System Information (SI) is to provide the UEs with
essential parameters needed for communication with E-UTRAN. A few
examples of broadcasted information: description of the random access
channel, neighbour cell lists, definition of paging groups, periodic update
timers, area identities (PLMN, Tracking area, cell).

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-3
RRC Connection Establishment
This procedure will move the UE from the RRC Idle state to the RRC
Connected state (see section 5.3). An RRC Connection is always needed
whenever the UE wishes to send/receive control signalling or data to/from
the network. The RRC Connection procedure is always co-ordinated with
a NAS signalling procedure, such as Attach, resulting in the establishment
of basic IP-connectivity for the UE.

Access Stratum (AS) Security Mode Control


Procedure used to instruct the UE to begin ciphering and integrity
protection of RRC signalling and user plane data. See the PDCP section
below for more information about LTE/SAE security.

Management of Radio Bearers


Procedures for establishment, reconfiguration and release of user plane
radio bearers, including configuration of ARQ (RLC) and HARQ (MAC)
operation. It is also possible to configure semi-persistent scheduling rules
(e.g. DRX cycles and pre-defined transport formats) for predictable
services such as VoIP.

Measurement Control/Reporting
The eNodeB may start, modify or stop a number of measurements in the
UE (independently of each other). The measurement reporting can be done
periodically or be event triggered. These procedures are used in the RRC
Connected state to prepare for handovers.

Handover Control
This procedure includes the necessary control signalling to execute hard
handovers between eNodeBs or between eNodeB and some other Radio
Access Technology (RAT). E-UTRAN will support handover to/from at
least GERAN, UTRAN, mobile WiMAX and CDMA2000 systems.

5.2.3 Packet Data Convergence Protocol (PDCP)


The PDPC protocol is responsible for header compression (Robust Header
Compression, ROHC, as defined in RFC 3095), access stratum security
and for in-sequence delivery of user plane packets during handover.

Up until recently, there was much debate within the LTE project whether
PDCP should be responsible for both User Plane (UP) and Control Plane
(CP) security, or only for UP security. It was also debated whether PDCP
should reside in the eNodeB or in the SGW. The decision was finally taken
to let PDCP reside in the eNodeB and, as a consequence, to be responsible
for both UP and CP security.

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-4
The LTE/SAE system uses a security key hierarchy (figure 5-2) with
multiple levels. The base keys on the top level (Ciphering Key, CK, and
Integrity Key, IK) are only visible to the UE and the home network
domain databases (HSS/AuC).

On the next level there is a so-called Access Security Management Entity


(ASME) key, which is only visible to the UE and the visited MME (the
‘ASME’ node in figure 5-2 is the MME in case of the Evolved Packet
Core). The ASME key is derived from the base CK/IK pair and passed
from HSS to the MME.

The ASME key is, in turn, used for derivation of the ciphering and
integrity keys needed to protect NAS signalling messages (i.e. signalling
between UE and MME).

USIM / AuC K

CK, IK

UE / HSS

KASME
UE / ASME

KNAS enc KNAS int KeNB

UE / MME

KeNB-UP-enc KeNB-RRC- int KeNB-RRC-enc

UE / eNB

Figure 5-2: LTE/SAE security key hierarchy (from TR 33.821)

The ASME key is also used for derivation of an eNodeB key. The eNodeB
key, in turn, is used for derivation of keys for ciphering and integrity
protection of RRC signalling messages and a key for the ciphering of user
data over the radio interface (i.e. between UE and eNodeB).

This hierarchy allows the keys in the Home domain, the (visited) EPC
domain and the Access domain to be cryptographically separate, while still
being produced by the same set of Home domain controlled base keys.

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-5
5.2.4 Radio Link Control (RLC)
The Radio Link Control (RLC) protocol offers link control over the radio
interface for user data and control signalling. One UE may use multiple
RLC entities simultaneously, with each entity configured to operate in one
of three modes: Acknowledged Mode (AM), Unacknowledged Mode
(UM) or Transparent Mode (TM).

In AM mode the RLC layer guarantees that all PDUs delivered to the
higher layer are received without errors. This guarantee is ensured by
means of RLC-level acknowledgements (ACK) and retransmission
requests (NACK) as well as through interaction with the MAC level
HARQ functionality. ACK/NACK is indicated with Status Reports (RLC
Control PDUs) sent from receiver to transmitter.

As the term suggests, there are no acknowledgements or retransmissions in


the UM mode. Hence delivery of data cannot be guaranteed. Any
erroneous RLC PDUs received are either discarded or delivered to higher
layers with an indication that they contain errors. The TM mode, finally, is
used for minimum protocol overhead (the TM mode PDU has no header).

The service the RLC layer provides to the User Plane (PDCP protocol) is
called a Radio Bearer (RB). The RLC mode to use is configured with the
Radio Bearer Establishment procedure.

The service the RLC layer provides to the Control Plane (RRC protocol) is
called a Signalling Radio Bearer (SRB). The SRBs are configured during
the RRC Connection Establishment procedure. It is expected that only two
types of SRBs will be used in E-UTRA: one low priority SRB and one
high priority SRB.

5.2.5 Medium Access Control (MAC)


The main functions of the MAC protocol are to perform multiplexing of
one or several upper layer PDUs onto transport blocks, to perform UL and
DL resource allocation through dynamic scheduling and to handle error
correction through HARQ operation.

The scheduling function manages DL-SCH and UL-SCH radio resources


between HARQ entities (i.e. between UEs). The scheduler determines
which UE (or group of UEs) to be serviced each 1ms TTI. The exact
scheduling algorithm used is implementation dependent but should
preferably take into account:
• Availability of radio resources
• Data stream priority levels (for each UE)
• The current channel conditions (for each UE)
• The amount of data awaiting transmission (for each UE)
• How long time since UE X was last served
• Users that have retransmissions pending.

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-6
The scheduler selects a proper Modulation and Coding Scheme (MCS) and
Redundancy Version (RV) for each scheduled MAC PDU based on each
scheduled UEs current channel condition, the retransmission status and,
possibly, on the UE capabilities. The RV is used as input to the HARQ
layer 1 rate matching function discussed in chapter 4.

One HARQ Entity within MAC handles the HARQ functionality for one
user. The HARQ protocol selected for E-UTRA is of the ‘Stop-and-Wait’
type (SAW). This means that it is not allowed to transmit a PDU with
sequence number ‘N’ until the PDU with sequence number ‘N-1’ is
positively acknowledged.

Remember that the TTI used in E-UTRA is only 1ms. Each time the UE
receives data in a 1ms TTI it must, according to the SAW protocol, send
back either an ACK (‘everything OK, please send next PDU’) or a NACK
(‘please retransmit the PDU’). The creation and sending of an
ACK/NACK takes a certain amount of time. So does the processing of the
ACK/NACK in the NodeB. And so does the scheduling of a new
re/transmission to this UE.

All this is simply impossible to execute before the start of the next 1ms
TTI. The consequence is then that it becomes impossible to schedule
transmissions in consecutive 1ms TTIs to the same UE, resulting in waste
of resources- or at least waste of time. (The same logic holds, of course,
for uplink transmissions).

The solution is to allow each HARQ Entity to work with several processes
simultaneously. When one HARQ process is awaiting ACK/NACK for a
transmitted MAC PDU, the scheduler can order transmission of the next
MAC PDU from the next HARQ process, that then stops and awaits
ACK/NACK, and so on. It is expected that 8 HARQ processes will be
sufficient to allow continuous transmission to/from a given UE. Thus, the
shortest HARQ round-trip time is expected to be 8ms.

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-7
5.3 UE States (RRC and NAS)

LTE IDLE RRC IDLE

LTE ACTIVE RRC CONNECTED

LTE DETACHED

Figure 5-3: UE states and state transitions

From a radio resource point of view there are two operational states for the
UE: RRC Idle State and RRC Connected State. In the RRC Idle state the
UE is unknown in E-UTRAN and will remain so until it requests the
establishment of an RRC Connection. Such a request can be triggered by
higher protocol layers in the UE (i.e. mobile originating service request) or
by the paging procedure (initiated from the EPC).

In RRC Idle state the UE moves around in the network and change from
one cell to another through the process of cell reselection. It continuously
monitors the broadcasted system information and the paging channel. No
data/signalling transmission or reception, except paging and system
information, is possible in the RRC Idle state.

The RRC Connected state allows data or signalling to be sent or received.


The UE enters the Connected state through the establishment of an RRC
connection. The UE is always allocated a cell specific identifier, the Cell
Radio Network Temporary Identity (C-RNTI) when in Connected state.
The C-RNTI is, among other things, used for addressing the UE on the
downlink resource assignment channel, the PDCCH. UE mobility is
network controlled through handovers. The UE may have a DRX cycle
configured in order to allow ‘sleep periods’ in-between monitoring the
PDCCH. RRC Connection Release brings the UE back to RRC Idle state.

The NAS states (EPC related states) are aligned with the RRC states. A
UE in RRC Idle state is, from the MMEs point of view, in the NAS state
LTE Idle. In this state the UE is registered in the MME and has an IP-
address allocated. Whenever the UE detects a change of Tracking Area it
performs a Tracking Area update towards the MME.

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-8
Paging or a request from higher layers to transmit uplink data or signalling
will cause a transition from LTE Idle to the LTE Active state. In LTE
Active state the UE has at least one SAE bearer allocated, allowing uplink
or downlink data/signalling transfer to take place. The S-TMSI is used to
identify/ address the UE in NAS signalling messages. The UE can never
be in LTE Active state without also being in RRC Connected state.
Transition from LTE Active to LTE Idle can, for example, be triggered by
user inactivity.

In the LTE Detached state there is no information known about the UE in


the eNodeB or the MME. No data or signalling transfer is possible. This
state is left/entered through the Attach/Detach procedures.

5.4 PDU Formats


RRC Message or IP Packet

PDCP PDU Seq. No PDCP SDU MAC-I

RLC PDU Seq. No E Length Ind. E RLC SDU 1 .....

MAC PDU LCID1 L1 E1 MAC SDU 1 ..... Pad

Figure 5-4: layer 2 and layer 3 PDU formats

Figure 5-4 shows the PDU formats for (from top to bottom) the PDCP,
RLC and MAC protocols. The payload of a given protocol is referred to as
a Service Data Unit (SDU). PDCP PDUs only carry one SDU while RLC
and MAC PDUs may carry multiple SDUs.

The PDCP protocol takes as input either an RRC message (CP) or an IP


packet (UP). RRC messages are encrypted and integrity protected. The
integrity protection results in a Message Authentication Code for Integrity
(MAC-I) field being added at the end of the PDCP PDU. User plane
packets are encrypted and compressed but never integrity protected. The
PDCP protocol also adds a one or two byte long sequence number, unless
configured for transparent operation where no sequence number is present.

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-9
The RLC protocol takes as input PDCP PDUs. Several PDCP PDUs may
be concatenated into one and the same RLC PDU. The RLC protocol may
also perform segmentation, meaning that only part of a given PDCP PDU
is fitted within one RLC PDU. An RLC sequence number is added for
ARQ operation, sequence control and SDU reassembly purposes. One or
more length indicator is added to indicate the presence of multiple SDUs,
or SDU segments. The presence of the length indicators themselves is
indicated with an extension bit (E) following the sequence number and
each present length indicator. Thus, the E-bit following the last length
indicator will indicate ‘no more length indicator fields present’.

The MAC protocol takes as input RLC PDUs. Several RLC PDUs may be
concatenated into one and the same MAC PDU. One MAC PDU is the
same as one Transport Block. Thus, one and the same Transport Block
may carry information from more than one logical channel (figure 5-1).
The identity number of the logical channel where a given MAC SDU
originated is indicated with the Logical Channel Identity field (LCID). The
length (in bits) of each MAC SDU is indicated with the Length field (L).
There is one LCID/L pair for each MAC SDU in the payload field. The
presence of yet another LCID/L pair is indicated with the extension bit (E)
following the previous pair. Thus, the E-bit following the last LCID/L pair
will indicate ‘no more LCID/L fields’. Padding may be added if the total
length of the LCID/L/E fields and the associated MAC SDUs do not
exactly match the number of bits to be transmitted on the assigned physical
resource.

One or two Transport Blocks per 1ms TTI are delivered to the physical
layer for further processing, as described in chapter 4.

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-10
5.5 References
24.801 3GPP System Architecture Evolution: CT WG1 aspects (NAS)
33.821 Rationale and track of security decisions in LTE/SAE
36.321 E-UTRA; Medium Access Control (MAC) protocol
36.322 E-UTRA; Radio Link Control (RLC) protocol
36.323 E-UTRA; Packet Data Convergence Protocol (PDCP)
36.331 E-UTRA; Radio Resource Control (RRC) protocol

Apis Technical Training AB


LTE - Layer 2 and 3 protocols
Copyright © Apis Technical Training AB 2007. All rights reserved. 5-11
6 X2 and S1-interface
6.1 INTRODUCTION .............................................................. 6-2
6.2 THE X2-INTERFACE ....................................................... 6-3
6.2.1 X2-interface Protocols..............................................................6-3
6.3 THE S1-INTERFACE ....................................................... 6-5
6.3.1 S1-interface Protocols..............................................................6-5
6.4 SELF-ORGANIZING NETWORKS ....................................... 6-7
6.4.1 Self-configuration .....................................................................6-7
6.4.2 Self-optimization.......................................................................6-8
6.5 HOME ENB ................................................................... 6-8
6.5.1 Node Configuration ..................................................................6-9
6.5.2 Access Restriction....................................................................6-9
6.5.3 Mobility ...................................................................................6-10
6.5.4 Security ..................................................................................6-11
6.5.5 QoS and Interference.............................................................6-11
6.6 REFERENCES .............................................................. 6-12

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-1
6.1 Introduction
Evolved UTRAN Evolved Packet Core

S1-MME
eNB MME

X2-C X2-U
S11

eNB SGW
S1-U

Figure 6-1: the X2-interface and the S1-interface

The X2-interface connects the eNBs within E-UTRAN together. The X2-
interface is an IP-based interface and can therefore be seen as a point to
multi-point interface (the eNB may communicate with every other eNB).

The Control Plane (CP) instance of the X2-interface (X2-C) uses the X2
Application Protocol (X2AP) for control signalling purposes between
eNBs. The User Plane (UP) instance of the X2-interface (X2-U) uses the
GPRS Tunnelling Protocol- User plane (GTP-U) for user data tunnelling
between eNBs. The X2-interface is described in section 6.2.

The S1-interface connects the Evolved UTRAN with the Evolved Packet
Core (EPC). The termination point for the S1-interface on the E-UTRAN
side is the eNB, and on the EPC side the Mobility Management Entity
(MME) and the Serving Gateway (SGW). The S1-interface is, like the X2-
interface, an IP-based point to multi-point interface.

The CP instance of the S1-interface (S1-MME) uses the S1 Application


Protocol (S1AP) for control signalling purposes between eNB and MME.
The UP instance of the S1-interface (S1-U) uses GTP-U for user data
tunnelling between eNB and SGW. The S1-interface is described in
section 6.3. Section 6.4 deals with network self-organization issues and
section 6.5 contains an overview on the so-called home eNB.

At the time of writing (Oct-07) all specifications pertaining to the X2- and
S1-interfaces are all immature drafts. The reader is therefore strongly
advised to regularly check for updated versions of the standardisation
documents listed at the end of this chapter.
Apis Technical Training AB
LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-2
6.2 The X2-interface
6.2.1 X2-interface Protocols

eNB eNB

X2AP X2AP

SCTP SCTP
IP IP
Data Link Layer Data Link Layer
Physical Layer Physical Layer
X2-C

User Data User Data

GTP-U GTP-U
UDP UDP
IP IP
Data Link Layer Data Link Layer
Physical Layer Physical Layer
X2-U

Figure 6-2: X2-interface protocols for CP (top) and UP (bottom)

X2 Application Protocol (X2AP)


The X2AP protocol is used for control signalling exchange between eNBs.
It supports Common and Dedicated procedures. Common procedures are
signalling procedures that do not relate to a specific UE. An example of a
Common procedure is Load Indication. Dedicated procedures are
signalling procedures that do relate to a specific UE. An example of this is
Handover. Currently specified X2AP procedures include:

• Handover. Initiated by the source eNB by sending a Handover


Request message to the target eNB. The target eNB reserves the
necessary radio resources and sends a Handover Request
Acknowledge message back to the source eNB. The ACK message
contains a complete radio interface Handover Command message,
to be sent to the UE, and the preferred Target eNB IP-address for
data forwarding over X2 during the handover execution phase.

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-3
• Release resource. After a successful handover, the Target eNB
initiates this procedure to inform the Source eNB that it can now
stop data forwarding over X2 and release all resources for this UE.

• Load Indication. The purpose of the Load Indication procedure is


to transfer an uplink ‘Interference Overload Indication’ between
intra-frequency neighboring eNBs for interference coordination
purposes. The Overload Indication is sent when the eNB
experiences too high interference level on some resource blocks.
This procedure is linked to the E-UTRAN Inter-Cell Interference
Cancellation (ICIC) function, that allows eNBs to ‘agree’ on what
set of OFDM sub-carriers to use at overlapping cell borders.

Stream Control Transmission Protocol (SCTP)


The Stream Control Transmission Protocol (SCTP) is used to support the
exchange of X2 Application Protocol (X2AP) signalling messages
between two eNBs. SCTP is a session-oriented protocol providing
connection-oriented, error-free, flow-controlled, in-sequence transfer of
signalling messages over IP. It is in many respects similar to TCP, but
there are some differences. One such difference is that SCTP is message
oriented while TCP is byte oriented. Another difference is that the in-
sequence delivery is optional for SCTP (i.e. it can be ‘turned off’) while it
is always mandatory for TCP.

SCTP makes use of so-called Stream Identifiers to identify a logical


signalling connection (‘stream’) between two network nodes. A single
SCTP association per X2-C interface instance is used, with different pairs
of Stream Identifiers for X2-C common and dedicated procedures.

A UE specific Context Identity is assigned by the Source eNB (i.e. the one
sending a message) and the Target eNB (the one receiving a message) for
signalling related to dedicated X2-C procedures. The purpose of the UE
Context Identity is to distinguish UE specific X2-C signalling transport
bearers from each other. The UE Context Identity is conveyed in all X2AP
messages pertaining to the specific UE.

GPRS Tunnelling Protocol- User Plane (GTP-U)


This is the same protocol as used in GPRS and UMTS (release 8). The
main task of the GTP-U protocol is encapsulation and tunnelling of user
data packets between network nodes. It is used on the X2-interface for
forwarding of packets during handover execution, on the S1-interface
(between eNB and SGW) and on a number of additional EPC interfaces.

Each user data IP-packet is encapsulated by adding a GTP header. The


header contains, among other things, a Tunnel Endpoint Identifier (TEID).
The TEID is a locally allocated reference number that uniquely identifies a
GTP tunnel in the node that allocated it. Thus, a GTP tunnel has two
TEIDs associated with it (one in each ‘end’).

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-4
Transport Layer Protocols
The transport layer uses standard Internet Engineering Task Force (IETF)
defined protocols, i.e. UDP/IP running over the selected data link and
physical layer protocols. These transport layer protocols are not discussed
further in this document.

6.3 The S1-interface


6.3.1 S1-interface Protocols

eNB MME

S1AP S1AP

SCTP SCTP
IP IP
Data Link Layer Data Link Layer
Physical Layer Physical Layer
S1-MME

eNB SGW

User Data User Data

GTP-U GTP-U
UDP UDP
IP IP
Data Link Layer Data Link Layer
Physical Layer Physical Layer
S1-U

Figure 6-3: S1-interface protocols for CP (top) and UP (bottom)

As seen by comparing figures 6-2 and 6-3 the protocols for the X2- and
S1-interfaces are close to identical, with the Application Protocol in the
Control Plane being the only difference. Hence only the S1AP protocol is
described here.

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-5
S1 Application Protocol (S1AP)
The S1AP protocol is used for control signalling exchange between eNB
and MME. All S1 procedures relate to a specific UE and are in that sense
‘dedicated’, even though the S1 specification does not use the term.
Currently specified S1AP procedures include:

• Paging. Enables the MME to page the UE in a specific eNB. The


MME initiates the paging procedure by sending a Paging message
to each eNB with cells belonging to the Tracking Area(s) in which
the UE is registered. The paging response back to the MME is
initiated on the NAS layer and is forwarded to MME by the eNB as
part of the NAS Signalling Transport procedure.

• NAS Signalling Transport. This procedure provides means to


transport NAS messages to/from a given UE over the S1-interface.
(This procedure is in all respects the same as the UTRAN Direct
Transfer procedure).

• Initial Context Setup. This procedure supports the establishment of


the necessary overall initial UE Context in the eNB to enable fast
Idle-to-Active transition. The UE Context includes: SAE Bearer
context, security context, roaming restriction, UE capability info,
“subscriber type” info etc. The procedure is always initiated from
the MME, typically in combination with network registration
(Attach or Tracking area update).

• SAE Bearer Management. The SAE Bearer management function


is responsible for establishing, modifying and releasing E-UTRAN
resources for user data transport with a given QoS (once an initial
UE context is available in the eNB). The procedure is always
initiated from the MME, with the exception of SAE Bearer Release
that may be initiated from the eNB.

• Handover. Handover preparation and execution signalling over the


S1-interface is only needed during inter-RAT handover or when
there is no X2-interface present between the Source eNB and the
Target eNB. For a normal X2-interface initiated inter-eNB handover
a S1AP Handover Notification message is sent from the Target eNB
to the MME after the UE has been successfully transferred to the
new cell.

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-6
6.4 Self-organizing Networks
With the term Self-organizing Networks (SON) is meant the functionality
in network elements for self-configuration and self-optimization without
(or with minimal) manual intervention.

6.4.1 Self-configuration
Self-configuration is defined as the process where newly deployed network
nodes (i.e. eNBs) are configured by automatic installation procedures in
order to get the necessary basic configuration for system operation. This
process works in the pre-operational state. Pre-operational state is
understood as the state from when the eNB is powered up and has
backbone connectivity until the RF transmitter is switched on.

After power-up the eNB needs to make its presence know to the MME, or
MMEs, in the network. This requires that the eNB knows the transport IP-
address of the MME(s). An initial remote IP endpoint to be used for SCTP
initialisation is provided to the eNB for each MME in the pre-operational
state (the exact mechanism for this is not yet standardised). For each MME
the eNB tries to initialize a so-called SCTP association (RFC 2960), using
the known initial remote IP endpoint, until SCTP connectivity is
established.

Once SCTP connectivity has been established the eNB and MME are in a
position to exchange application level configuration data needed for the
two nodes to interwork correctly. During this process the eNB provides
relevant information to the MME (e.g. eNB ID, list of supported Tracking
Area(s) etc).

The MME similarly provides relevant information to the eNB (e.g. MME
ID, PLMN ID etc). When the application layer initialization is successfully
concluded, and has been mutually acknowledged by the two peer nodes,
the dynamic configuration procedure is completed and the S1-MME
interface is operational. It is expected that some form of mutual node
authentication procedure is needed prior to initiating this process (i.e. to
detect fake or ‘impersonated’ nodes).

The eNB can then download additional configuration software, either


from/via the MME or from some network management system. This may
include configuration parameters such as: cell-id, neighbour cells (cell-ids,
IP addresses), sub-carrier allocation, reference signal mapping, reference
signal power, antenna tilt etc.

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-7
6.4.2 Self-optimization
Self-optimization is defined as the process through which UE and eNB
measurements are used to auto-tune the network. This process works in the
operational state. Operational state is understood as the state where the RF
interface is switched on (i.e. the eNB is being used for real traffic).

The current draft specification clearly states that the UE shall (‘shall’ is the
same as ‘must’ in 3GPP language) support measurements and procedures
that can be used for self-configuration and self-optimisation of the E-
UTRAN system. It should also be possible to associate the measurements
for self-optimisation purposes with location information (e.g. the UE may
provide GPS coordinates to the eNB).

Such UE-assisted measurements can be used to, for example, optimize


neighbour cell lists. The active RRC connections and their accompanying
measurements can be used to gather needed information about neighbours.
Known neighbours can be checked if they are really appropriate
concerning radio conditions and new ones can be included based on
information about detected cells received from the UEs.

The radio measurements of eNB and UEs together with call events like
call drops, failed or ‘ping-pong’ handovers etc may also influence the
handover algorithm used. For example, if certain (average) measurement
values fall below a certain threshold a (pre-configured) modified handover
algorithm may be used until the problem disappears.

Furthermore, through the use of OFDM the opportunity exists to distribute


radio interface resources in a dynamic way to optimise the traffic situation
or interference situation based on statistical measurements of power and
interference level for single sub-carriers or groups of sub-carriers. This
may be performed as an intra eNB process, but may also be linked to the
X2-interface Load Indication (ICIC) procedure.

6.5 Home eNB


The ‘home base station’ is not really a new concept since many people
today have wireless LAN access points in their homes in conjunction with
their broadband access. The standardisation work in 3GPP regarding home
base stations belongs to Release 8 and incorporates both UTRAN NodeBs
and E-UTRAN eNBs. The following description focuses on the E-UTRAN
case but many of the questions and considerations raised apply equally
well to the UTRAN case. It is expected that the home eNB will connect to
the MME/SGW using the standard S1-interface and to other eNBs using
the standard X2-interface.

There are many fundamental issues that must be solved before home eNBs
can be fully and securely included in the LTE/SAE ‘macro’ architecture,
some of which are touched upon in the following.

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-8
6.5.1 Node Configuration
Installation of the home eNB should require a minimum amount of manual
intervention, both from the user and the operator. The existence of
functions for Self-organizing Networks (SON) is expected because the:
• number of home eNBs may become very large
• subscribers may switch on and off the home eNB frequently
• operator may not be able to access the home eNB physically.

The home eNB shall therefore be able to download the latest firmware and
software to be used, as part of an initial or periodic activation procedure. A
possible solution is that the eNB downloads the initial configuration from
a known configuration server prior to powering up the radio interface.

Thus, initialisation of the home eNB should be automated and require no


manual configuration by either the user or network operator. The
initialisation process should include also configuration of neighbour
relationships, which requires the presence of the X2-interface.

It must therefore be possible for the home eNB to trigger establishment


and release of the X2-interface between the home eNB and Macro eNBs,
as well as accept incoming X2-interface connection requests from Macro
eNBs. This is also applicable for the X2 connection to another home eNB.

It should be possible for both the owner and the network operator to cause
the home eNB to download and install the latest software updates or
configuration files. There may also be a function present that allows the
operator to switch off the home eNB remotely.

6.5.2 Access Restriction


Naturally, the eNB should only allow access for a single subscriber (or
group of subscribers) while all other subscribers must be barred from using
it. The cell served by the home eNB is referred to as a Closed Subscriber
Group (CSG) cell. As the term suggests, only a UE from a specific user
group should be allowed access to that cell.

This access restriction is needed because some backhaul links for this type
of deployment are not considered to provide adequate QoS to support a
large numbers of UEs. There may also be regulatory issues with sharing
the backhaul link/eNB access in that location. Finally, the backhaul link
may be owned by or paid for by the subscriber and he/she may not be too
happy to share the link with others!

The user group associated with a specific home eNB needs to be updated,
under the supervision of the network operator, by the subscriber which is
registered as the owner of the home eNB. When a subscriber is added to
the user group by the registered owner the UE of the subscriber should be
able to (almost) immediately camp on the cell of the home eNB and then
acquire service through the home eNB. This is especially important in the

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-9
deployment scenario where this subscriber has no other means to access
the network, i.e. there is no macro-layer coverage available.

A UE should not camp on or access a CSG cell if it is not part of the user
group that is allowed to access that CSG cell. The exact mechanisms for
this is currently still under investigation.

6.5.3 Mobility
The home eNB/CSG cells are part of the network of the operator, and
therefore the design needs to support mobility of UEs between the macro-
layer network and the home eNB/CSG cells. This is true for both Idle state
behaviour (cell re-selection) and Connected state behaviour (handover).

The home eNBs will be deployed in order to improve network coverage, to


improve network capacity and to offer differentiated billing models. As the
user billing could be dependent on whether the UE is using the home eNB
or not it is important that the UE, when it is in range, automatically camps
on the home eNB. This can be done by setting broadcasted re-selection
parameters in such a way that the UE will always prioritize the CSG cell.

It is also important that UEs camped on the home eNB do not cause
excessive signalling load or processing load if/when the UEs moves
frequently between the macro-layer network and the home eNB (e.g.
excessive Tracking Area update signalling should be avoided). A possible
solution to this is to, during automated initialization, make sure the home
eNB belongs to the same Tracking Area as the surrounding macro eNBs.

As discussed above the home eNBs will have an associated user group
defining which UEs can access the home eNB. The handover procedure
needs to take the user group of the Target home eNB into account when
deciding whether to handover a UE to a specific home eNB.

As the number of home eNBs in the network will become large the
proportion of measurements made by a UE which could be wasted may
become large, to the point where it affects the mobility performance of the
UE/system as well as draining the battery of the UE. It is therefore
necessary for the UE to, somehow, be able to avoid unnecessary
measurements of home eNBs where it does not belong to the user group.

It should be noted that, due to the expected high number of home eNBs
and the nature of their deployment, it would not be practical to change the
configuration for the mobility procedures (measurements, handover etc) in
the macro layer nodes whenever a home eNB is deployed/dismissed.

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-10
6.5.4 Security
The operator’s network must be protected from cases where the user (or
someone else) is ‘tampering’ with the home eNB in an un-desired manner.
Thus, the implementation of the home eNB must offer appropriate security
protecting home eNB users and the connected network from security
threats arising from accessing the backhaul link or internal interfaces (or
configuration data) within the home eNB.

To protect both the operator and the eNB owner it is desirable that mutual
authentication, between home eNB and network, and establishment of a
secure connection with a Security Gateway (SeGW) is part of the home
eNB initialization process. The exact security mechanism to be used and
the location of the SeGW function is not yet decided.

Furthermore, since the home eNB will be a small, easily portable, device it
is desirable for the operator that the home eNB recognises when it is
operated in a different country to the HPLMN and, as a result, deactivates
itself. Such a function can be important for charging reasons.

6.5.5 QoS and Interference


The user should expect the same (or higher) QoS level when connected
through the home eNB as when using an ‘ordinary’ eNB. It therefore
makes sense for the UE to be able to display whether it is attached to a
home eNB or to a macro eNB, regardless if it is in Idle or Connected state.

The home eNB should not be allowed to cause excessive interference in


the local radio environment. The home eNB must therefore continually or
periodically perform measurements, and/or request measurements from the
UE, to modify the current site-specific configuration. This is needed in
order to dynamically adapt the radio resource and parameter settings to the
local environment (within the constraints imposed by the operator).
Further, the operator can (remotely) define the maximum output power
that a UE can use on the home eNB.

Related to both QoS and interference issues it will be possible for the
network operator to query the home eNB to send a report of the node
status. The report should contain: information gathered from eNB self-
testing activities, average data throughput, radio configuration (frequency
and power), dropped calls and mobility flows (e.g. handovers between the
home and macro layer).

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-11
6.6 References
25.820 3G home NodeB study item technical report
32.816 Telecommunication mgmt; study on mgmt in LTE and SAE
32.821 Telecommunication mgmt; study on SON for home NodeB
36.410 E-UTRAN; S1 general aspects and principles
36.413 E-UTRAN; S1 Application Protocol (S1AP)
36.420 E-UTRAN; X2 general aspects and principles
36.423 E-UTRAN; X2 Application Protocol (X2AP)

Apis Technical Training AB


LTE - X2 and S1-interface
Copyright © Apis Technical Training AB 2007. All rights reserved. 6-12
7 Evolved Packet Core
7.1 EPC NETWORK ARCHITECTURE ..................................... 7-2
7.1.1 Baseline EPC Network Architecture ........................................7-2
7.1.2 EPC Architecture for MBMS.....................................................7-5
7.2 EPC QUALITY OF SERVICE ............................................ 7-7
7.2.1 EPC Bearer Concepts..............................................................7-7
7.2.2 QoS Parameters ......................................................................7-8
7.3 REFERENCES ................................................................ 7-9

Apis Technical Training AB


LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-1
7.1 EPC Network Architecture
Section 7.1.1 presents the network architecture as it is most often
displayed in the current specifications. However, the standardised network
architecture for the Evolved Packet Core (EPC) is very flexible and allows
various network configurations to be realised. Rather than specifying
monolithic network nodes, the standard identifies functional entities that
may be physically co-located or distributed according to product
development and deployment scenarios. For instance, the MME may be
co-located with the SGW that, in turn, may be co-located with the PGW
that, in turn may be co-located with the PCRF etc.

The nodes/functions and interfaces needed for MBMS transmission are


described separately in section 7.1.2.

7.1.1 Baseline EPC Network Architecture


UTRAN
Iu
SGSN
GERAN Gb

Gr

HSS S3 S4 S12

S6a

S1-MME S11
MME PCRF
Rx+

S10 S7

E-UTRAN SGW PGW IMS / Internet /…


S1-U S5 SGi
(S8a/b)

3GPP
IP-access
S2c S2b
Non-3GPP
Trusted
IP-access S2a
Non-3GPP
Non-trusted ePDG AAA To HSS
IP-access Wn* Wm* Wx*

Figure 7-1: baseline EPC network architecture

Figure 7-1 shows the EPC network architecture for the non-roaming case.
That is, the access network and the core network both belong to the same
operator. The roaming case primarily affects the S5 and S7-interfaces. The
legacy interfaces (Gr, Iu and Gb in fig 7-1) are not described here.

For several of the EPC interfaces it has not yet been decided what
application signalling protocol to use. In the following, the mentioning of a
specific signalling protocol is simply omitted in such cases.

Mobility Management Entity (MME). The MME manages and stores


contexts (i.e. information lists) relating to UEs in both LTE Idle and LTE
Active state. The UE context contains parameters such as: IMSI, S-TMSI,
current Tracking Area, security keys, UE capabilities and currently
assigned EPC bearer QoS.

Apis Technical Training AB


LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-2
The MME is responsible for handling mobility management procedures
such as Paging, Attach/Detach and Tracking Area updates. It handles
security procedures such as Authentication and allocation of temporary
identities (S-TMSI).

It is also responsible for the transfer of UE contexts (in a backwards


compatible format) to the SGSN in inter-RAT mobility scenarios. MME to
SGSN signalling takes place over the S3-interface using the GPRS
Tunnelling Protocol- Control plane (GTP-C).

The MME connects to the E-UTRAN (eNB) with the S1-MME interface.
This interface uses the S1 Application Protocol (S1AP), as described in
chapter 6.

When needed, the MME updates the HSS with UE location information
and retrieves subscription and authentication data. This is done over the
S6a-interface using either the Mobile Application Part (MAP) protocol or
the DIAMETER protocol. For inter-MME user mobility, the S10-interface
is used for UE context transfer between MMEs.

The S11-interface connects the MME to the SGW. This interface is used
for paging initiation (SGW to MME), handover/re-routing indications and
establishment of EPC bearers (MME to SGW).

Home Subscriber Server (HSS). The HSS holds subscription profiles and
security related information for each registered subscriber. It is an evolved
version of the 2G/3G Home Location Register (HLR) that also includes
the functionality of the Authentication Centre (AuC).

Serving Gateway (SGW). The SGW terminates the downlink data path for
UEs in LTE Idle state and initiates paging (to MME) when downlink data
arrive for the UE. It manages and stores UE contexts (user IP-address,
EPC bearer QoS, eNB/PGW IP-addresses and TEIDs). The SGW connects
to E-UTRAN (eNB) via the S1-U interface using the GTP-U protocol.

During, and after, a handover to GERAN/UTRAN the SGW acts as User


Plane anchor, forwarding downlink user IP-packets to the SGSN via the
S4-interface (GTP-U). In case the UTRAN system has a ‘Direct Tunnel’
architecture (SGSN eliminated from the User Plane) this forwarding takes
place over the S12-interface (GTP-U).

In the non-roaming case the S5-interface connects the SGW with the PGW
for uplink and downlink user IP-packet transfer. In the roaming case the
SGW is located in the visited network and the PGW in the home network,
connected via the S8a/b-interface. The S5 and S8a-interfaces use GTP-U
while S8b uses Proxy Mobile Ipv6, PMIP (RFC 3775).

Apis Technical Training AB


LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-3
Packet Data Network Gateway (PGW). The PGW (also called PDN GW)
is the connection between the EPC and external packet data networks, over
the SGi-interface. It is responsible for allocation of user IP-addresses. The
PGW also acts as the User Plane anchor for mobility to/from IP-access
networks other than UTRAN/GERAN.

These ‘other IP-access networks’ are divided into three groups: 3GPP IP-
access, trusted non-3GPP IP-access and non-trusted non-3GPP IP-access.
Examples of non-GERAN/UTRAN access networks are: WLAN, xDSL,
CDMA2000 and WiMAX.

The 3GPP IP-access is the Interworking WLAN access (I-WLAN), first


defined in Release 6, connected to PGW with the S2c-interface using the
Dual Stack Mobile Ipv6 protocol (DS-MIPv6).

Trusted non-3GPP IP-access connects to the PGW with the S2a-interface


using PMIP or Mobile Ipv4, MIPv4 (RFC 3344). Non-trusted non-3GPP
IP-access needs an ePDG in the connection path. The S2b-interface
(PMIP) connects the PGW with the ePDG.

Evolved Packet Data Gateway (ePDG). The ePDG performs access


authentication when the UE tries to connect to the home domain. If
needed, it performs QoS authorization and generates charging information
for the packet data session. It may also perform packet filtering/policing
functions.

The ePDG connects to the non-trusted access network with the Wn*-
interface. The ePDG may require interaction with an AAA-server, using
the Wm*-interface.

Authentication, Authorization and Accounting server (AAA). This


function either executes the AAA-functions or, alternatively, provides
necessary data for the ePDG to do so. The AAA-server may need to
download subscription information from the HSS via the Wx*-interface.

Policy and Charging Rules Function (PCRF). The PCRF provides


operator specific (or UE specific) QoS policies and charging rules to the
PGW when an EPC bearer is to be established. The S7-interface uses the
DIAMETER protocol.

In a roaming scenario there may be interaction between a local (visited)


PCRF and the home domain PCRF. This inter-PCRF interface is called the
S9-interface (DIAMETER). The PCRF retrieves the necessary policy and
charging parameters from the proper IMS Application Function (AF) over
the Rx+-interface.

Apis Technical Training AB


LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-4
7.1.2 EPC Architecture for MBMS
The MBMS Service
The Multimedia Broadcast Multicast service (MBMS) allows multimedia
content (messages, audio, video etc) to be efficiently transmitted to all
users, or a well-defined group of users, in a given cell (or cells). The
service was first introduced in 3GPP Release 6, supporting MBMS
transmissions over the GERAN and UTRAN radio access networks.
MBMS is really two services in one:

• The broadcast service (or mode) where the transmitted content can
be received by all terminals in a given area without restriction
(provided the terminal supports MBMS of course). This service
does not require any subscription support and no charging will be
incurred.

• The multicast service (or mode) is transmitted solely to terminals


that have actively joined a particular multicast group. This service
may require subscription support and may also be charged for by
the operator.

The MBMS service requires its own infrastructure (i.e. network nodes) and
its own set of logical, transport and physical channels. A brief overview of
the network architecture for MBMS within the EPC and the required
functionality in E-UTRAN/E-UTRA is given in the following sections.

MBMS Architecture

MBMS Gateway
M3
MCE MBMS1

M2 Sm

M1 SGmb
Content
eNB MBMS2 eBM-SC
Provider

Figure 7-2: EPC network architecture for MBMS

Evolved Broadcast Multicast Service Centre (eBM-SC)


The eBM-SC provides functions for general MBMS service provisioning
and delivery. It serves as an entry point for the content provider and
authorises, schedules and delivers MBMS transmissions to the EPC. The
eBM-SC connects to the MBMS GW via the SGmb-interface.

Apis Technical Training AB


LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-5
MBMS Gateway (MBMS GW)
The MBMS GW is a logical entity whose function is the synchronised
sending/broadcasting of MBMS data packets over the M1-interface to each
eNB transmitting the service. The MBMS GW also performs MBMS
session control signalling (e.g. session start/stop time) towards the eNBs
(or MCE) over the M3-interface. The MBMS GW may be functionality
split into MBMS1 (Control Plane) and MBMS2 (User Plane) functions. If
so, they are connected through the Sm-interface.

Multicell/multicast Coordination Entity (MCE)


The MCE is a logical entity that may, or may not, be physically co-located
with eNB. If it is co-located with the eNB, the M2-interface does not exist.
Its task is to allocate the radio resource (time/frequency resource and the
modulation and coding scheme) to be used by all eNBs taking part in
MBSFN transmission (see 7.2.3). Note: if the MCE exists as a stand-alone
function, it should logically belong to E-UTRAN and not the EPC.

E-UTRAN Support for MBMS


For the MBMS service in E-UTRAN, a group of cells can be ‘combined’
to achieve an MBMS Single Frequency Network (MBSFN) transmission.
An MBSFN transmission is a simulcast transmission technique realised by
the transmission of identical waveforms at the same time on the same
frequency from multiple cells. A fundamental requirement for multi-cell
MBSFN deployment is inter-site synchronization for which the cells
should be synchronized to within a few microseconds

An MBSFN transmission from multiple cells is seen as a single cell


transmission by the UE. Signals from all MBSFN cells arrive at the UE
and are dealt with in the same manner as multipath delayed signals. In this
manner the UE can combine the energy from multiple transmitters with no
additional receiver complexity. If the UE is close to one MBSFN eNB and
relatively distant from a second MBSFN eNB, the amount of delay
between the two signals can be substantial. For this reason, the MBSFN
transmissions in E-UTRAN are supported using a 7.5 kHz sub-carrier
spacing, as opposed to 15kHz in the ‘normal’ case, and a much longer
cyclic prefix.

MBSFN cells also use a common MBSFN-specific reference signal from


all participating eNBs to facilitate channel estimation. As a consequence of
the MBSFN transmission scheme, the UE can roam between cells with no
handover required. Signals from various cells will vary in strength and in
relative delay, but in aggregate the received signal is still dealt with in the
same way as conventional single-cell OFDM transmissions.

Furthermore, a cell in E-UTRAN is either an MBMS-dedicted cell or an


MBMS/unicast mixed cell. In an MBMS-dedicated cell the Multicast
Traffic Channel (MTCH) and Multicast Control Channel (MCCH) are
mapped on the Multicast Channel (MCH) transport channel. Such a cell
has no uplink resources.
Apis Technical Training AB
LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-6
In an MBMS/unicast mixed cell the MTCH and MCCH are mapped on the
Downlink Shared Channel (DL-SCH) or, in case of MBSFN transmission,
the MCH. The MBMS packets and the ‘regular’ unicast packets are time-
multiplexed on the DL-SCH through MAC-layer packet scheduling.
Uplink resources exist as normal, but the use of HARQ operation (and
hence uplink ACK/NACKs) for MBMS transmission is optional.

Both MBMS-dedicated and MBMS/unicast mixed cells can partake in


MBSFN transmissions.

7.2 EPC Quality of Service


7.2.1 EPC Bearer Concepts
An EPC Bearer (sometimes called Evolved Packet System, EPS, Bearer)
is a combination of one or more Service Data Flows (SDFs). An SDF can
most easily be seen as a uni-directional flow of data relating to a specific
service (thus a VoIP call requires both an uplink and a downlink SDF).
The SDFs are defined between the UE and the PGW.

Quality of Service (QoS) is defined per EPC Bearer, meaning that all
SDFs mapped to the same EPC Bearer will have the same QoS. Each EPC
Bearer is associated with an uplink Traffic Flow Template (TFT) in the
UE and a downlink TFT in the PGW. A TFT is a set of rules on how to
perform IP packet filtering.

An EPC Bearer is either a default bearer or a dedicated bearer. The


default bearer provides the UE with always-on IP-connectivity and is
established when the UE attaches to the network. Any EPC Bearer that is
established after this point is called a dedicated bearer.

The initial QoS parameter values for the default bearer are assigned by the
network based on subscription data (the MME sets those initial values
based on subscription data retrieved from HSS). The PGW may change
those values based on interaction with the PCRF or based on local policy
configurations.

A dedicated EPC Bearer is either a GBR bearer or a non-GBR bearer,


depending on if network resources relating to a Guaranteed Bit Rate
(GBR) have been associated with the EPC Bearer or not. A default bearer
is always a non-GBR bearer.

A Radio Bearer transports the packets of an EPC Bearer between the UE


and the eNB. There is one-to-one mapping between an EPC Bearer and a
Radio Bearer.

Apis Technical Training AB


LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-7
7.2.2 QoS Parameters
Each EPC Bearer (GBR or non-GBR) is associated with an Allocation and
Retention Priority (ARP) value, a Maximum Bit Rate (MBR) and a
Label.

The main purpose of the ARP is to decide whether a bearer


establishment/modification request can be accepted or needs to be rejected
in case of resource limitations. In addition, the ARP can be used by the
eNB to decide which bearer(s) to drop during exceptional resource
limitations (e.g. at handover). It should be noted that the ARP is not
intended to be used as input to the eNB packet-scheduling algorithm.

A Label is an operator-defined value (1, 2, 3, …) that is used as an internal


reference to eNB specific parameters that control Radio Bearer packet
treatment (e.g. HARQ operation, scheduling weights, packet queue
management, admission thresholds etc).

There are also 3GPP standardised Label characteristics, relating to specific


combinations of Bearer Type (GBR or non-GBR), Layer 2 Packet Delay
Budget (L2PDB) and Layer 2 Packet Loss Rate (L2PLR). The purpose of
these parameters is to support the configuration of MAC packet scheduling
and layer 2 ARQ and HARQ functions (e.g. the setting of scheduling
priority weights and the number of HARQ retransmissions).

Apis Technical Training AB


LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-8
7.3 References
23.234 3GPP system to WLAN interworking: system description
23.246 MBMS; architecture and functional description
23.401 GPRS enhancements for E-UTRAN access
23.402 Architecture enhancements for non-3GPP accesses
23.882 3GPP SAE: report on technical options and conclusions
36.300 E-UTRA/E-UTRAN; overall description Stage 2
36.938 Improved network controlled mobility between LTE and
3GPP2/WiMAX radio technologies

Apis Technical Training AB


LTE - Evolved Packet Core
Copyright © Apis Technical Training AB 2007. All rights reserved. 7-9

Das könnte Ihnen auch gefallen