lte signalling 1 eps overview - st3...

LTE Signalling 1 EPS Overview

2 NAS Protocols (EMM & ESM)

3 S1 and S11 Interface (S1AP & GTP)

4 Uu Interface I (RRC)

5 Uu Interface II (PDCP & RLC)

6 Uu Interface III (MAC)

7 Uu Interface IV (Layer 1)

8 X2 Interface (X2AP)

9 EPS Interworking

10 Signalling Flows

11

12

13

14 Apis Technical Training AB Tjärhovsgatan 21, 5th floor SE-116 28 Stockholm Sweden Tel +46-8-555 105 00 Fax +46-8-555 105 99 E-mail [email protected] www.apistraining.com

15 Foldouts

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 2008. 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: [email protected]

mailto:[email protected]

Apis Technical Training AB LSIG - Overview Copyright © Apis Technical Training AB 2008. All rights reserved. 1-1

1 EPS Overview

1.1 BACKGROUND ..................................................................................1-2

1.2 EVOLVED UTRA & UTRAN..............................................................1-4

1.2.1 Network Architecture................................................................1-4

1.2.2 Requirements on E-UTRA/E-UTRAN ......................................1-4

1.2.3 Overview of Technical Solutions..............................................1-5

1.2.4 Evolved HSPA (eHSPA) ..........................................................1-8

1.3 EVOLVED PACKET CORE...................................................................1-9

1.3.1 Network Architecture................................................................1-9

1.3.2 Requirements on the EPC .....................................................1-10

1.4 REFERENCES .................................................................................1-11


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 is part of 3GPP Release 8. The term ‘LTE’ has 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 work on LTE started with a workshop in 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 agreed that the E-UTRA/E-UTRAN standard should bring significant improvements to justify the standardization effort and that it should avoid unnecessary options (i.e. reduced overall complexity as compared to UMTS). 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 migration of the 3GPP system to a higher data rate, lower latency, packet optimized system that supports multiple RATs”. The EPC is a fully IP-based core network (‘all-IP’) supporting access not only via GERAN, UTRAN and E-UTRAN but also via WiFi, WiMAX and wired technologies such as xDSL. The SAE project is also a part of 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 combination of the E-UTRAN and the EPC is referred to as the Evolved Packet System (EPS).

Stage 1: March 2008Stage 2: June 2008Stage 3: December 2008 ?

E-UTRAN and EPCRelease 8

2010 ?LTE Advanced (LTE-A)Release 9 or 10

Stage 1: September 2005Stage 2: September 2006Stage 3: December 2007

IMS for NGNEvolved HSPA

Release 7

2005IMS with IP-CAN accessHSUPA

Release 6

2002IMS with GERAN/UTRAN accessHSDPA

Release 5

2001Split ArchitectureRelease 4

2000EDGE, UTRANRelease 99

1999AMRRelease 98

1998GPRSRelease 97

199714.4 kb/s, HSCSDRelease 96

1995GSM (basic configuration)Phase 2

1992GSM (interim configuration)Phase 1

Freeze yearCommentRelease/Phase

Stage 1: March 2008Stage 2: June 2008Stage 3: December 2008 ?

E-UTRAN and EPCRelease 8

2010 ?LTE Advanced (LTE-A)Release 9 or 10

Stage 1: September 2005Stage 2: September 2006Stage 3: December 2007

IMS for NGNEvolved HSPA

Release 7

2005IMS with IP-CAN accessHSUPA

Release 6

2002IMS with GERAN/UTRAN accessHSDPA

Release 5

2001Split ArchitectureRelease 4

2000EDGE, UTRANRelease 99

1999AMRRelease 98

1998GPRSRelease 97

199714.4 kb/s, HSCSDRelease 96

1995GSM (basic configuration)Phase 2

1992GSM (interim configuration)Phase 1

Freeze yearCommentRelease/Phase

Figure 1-1: 3GPP phases and releases

The Stage 2 set (general architecture, protocol structure and key concepts) of LTE/SAE standardisation documents where, according to 3GPP, completed in June 2008- though several key features where actually delayed until autumn 2008. The Stage 3 work (i.e. detailed protocol specifications) is, at the time of writing, expected for completion in December 2008. One should be aware that updates/changes/additions to the E-UTRAN/EPC specs are expected throughout 2008-09. Real-life deployment of LTE/SAE-based 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.


http://www.3gpp.org/

1.2 Evolved UTRA & UTRAN 1.2.1 Network Architecture

eNB

eNB

PCRF

PGW

HSS

SGW

MME

IMS/Internet/…S1-U

S1-MME

X2-C S11

Gx Rx

SGiS5Uu

Uu

X2-U

S6a

E-UTRA E-UTRAN EPC

eNB

eNB

PCRF

PGW

HSS

SGW

MME

IMS/Internet/…S1-U

S1-MME

X2-C S11

Gx Rx

SGiS5Uu

Uu

X2-U

S6aeNB

eNB

PCRF

PGW

HSS

SGW

MME

IMS/Internet/…IMS/Internet/…S1-U

S1-MME

X2-C S11

Gx Rx

SGiS5Uu

Uu

X2-U

S6a

E-UTRA E-UTRAN EPC

Figure 1-2: The Evolved Packet System (EPS), simplified

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 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. The eNBs are interconnected with each other by means of the X2-interface, e.g. for support of handovers without data loss. The X2-interface consists of a UP instance (X2-U) and a CP instance (CP) and is described in more detail in chapter 8. 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 and is (logically) divided into a UP instance (S1-U) and a CP instance (S1-MME). The S11-interface allows exchange of control signalling between the MME and the SGW and is a part of the EPC rather than the E-UTRAN. The S1- and S11-interfaces are described in chapter 3.

1.2.2 Requirements on E-UTRA/E-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). Benchmarking targets for data rates is set to 3-4 times those of HSPA as of R6 (5 MHz 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.4, 3, 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.

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 ‘de-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.4 MHz and at a later stage this may be increased to, say, 5 MHz.

• 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.

TDD2300 MHz – 2400 MHz2300 MHz – 2400 MHz40






TDD2010 MHz – 2025 MHz 2010 MHz – 2025 MHz 34


………...

FDD758 MHz – 768 MHz788 MHz – 798 MHz14


FDD[TBD] – [TBD][TBD] – [TBD]12

FDD1475.9 MHz – 1500.9 MHz1427.9 MHz – 1452.9 MHz11






FDD869 MHz – 894MHz824 MHz – 849 MHz5

FDD2110 MHz – 2155 MHz1710 MHz – 1755 MHz 4




DuplexMode

DownlinkFlow - Fhigh

UplinkFlow - Fhigh

E-UTRABand







TDD2010 MHz – 2025 MHz 2010 MHz – 2025 MHz 34


………...



FDD[TBD] – [TBD][TBD] – [TBD]12







FDD869 MHz – 894MHz824 MHz – 849 MHz5

FDD2110 MHz – 2155 MHz1710 MHz – 1755 MHz 4




DuplexMode

DownlinkFlow - Fhigh

UplinkFlow - Fhigh

E-UTRABand

Figure 1-3: E-UTRA frequency bands

The LTE physical layer specifications are written in such a way that it does not really matter on what physical carrier frequency the system is deployed. The table above shows the (currently) supported frequency bands, FDD and TDD, for LTE.


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:

• 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 higher reliability).

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. 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 OFDM-based E-UTRA physical layer is described in all its glorious detail in chapter 7. (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).

75 376

51 024

51 024

25 456

5 160

UplinkMax TB bits

transmitted per TTI

Yes

No

No

No

No

Uplink Support for

64QAM

4

2

2

2

1

DownlinkMax. spatial mux. layers

3 667 200

1 827 072

1 237 248

1 237 248

250 368

DownlinkTotal number of soft channel bits

[ 3434 ]151 376302 7525

[ 1832 ]75 376150 752 4

[ 1373 ]75 376102 0483

[ 687 ]51 02451 0242

[ 138 ]10 29610 2961

Total L2 buffer size

(kbyte)

DownlinkMax TB bits

received per TTI

DownlinkTotal DL-SCH bits received per TTI

UECategory

75 376

51 024

51 024

25 456

5 160

UplinkMax TB bits

transmitted per TTI

Yes

No

No

No

No

Uplink Support for

64QAM

4

2

2

2

1

DownlinkMax. spatial mux. layers

3 667 200

1 827 072

1 237 248

1 237 248

250 368

DownlinkTotal number of soft channel bits

[ 3434 ]151 376302 7525

[ 1832 ]75 376150 752 4

[ 1373 ]75 376102 0483

[ 687 ]51 02451 0242

[ 138 ]10 29610 2961

Total L2 buffer size

(kbyte)

DownlinkMax TB bits

received per TTI

DownlinkTotal DL-SCH bits received per TTI

UECategory

Figure 1-4: UE categories

There are 5 different UE categories defined for LTE operation. Each LTE UE category combines both downlink and uplink characteristics. This is in stark contrast to HSPA where terminal categories are defined separately for the downlink and for the uplink, giving rise to a large number of possible combinations- each of which must be included in the terminal test specifications.


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 into logical, transport and physical channels. The E-UTRA/E-UTRAN layer 3 and layer 2 protocols are described in chapters 2-6 and chapter 8.

1.2.4 Evolved HSPA (eHSPA)

SGSN

Iur

IMS / Internet /…GGSNIu/Gn Gi

RNC

NB

Iu

Gn

SGSN

Iur

IMS / Internet /…GGSNIu/Gn Gi

RNC

NB

Iu

Gn

SGSN

Iur

IMS / Internet /…IMS / Internet /…GGSNIu/GnIu/Gn GiGi

RNC

NBNB

IuIu

Gn

Figure 1-5: eHSPA 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 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 12Mb/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 ‘direct tunnel solution’) allowing IP packets to be routed directly between eHSPA NodeB and 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 R8 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’.


1.3 Evolved Packet Core 1.3.1 Network Architecture

Iu-PS

S1-MME

S1-U

SWnNon-trustedIP access

GERAN

UTRAN

TrustedIP access

Gb/Iu

HSS

S6a

IMS / Internet /…SGW

MME

S5 SGi

S11

S4S3

SGSN

S12 SPR

Gr

PCRF

Sp

Gx Rx

S2a

E-UTRANX2-C

X2-U

ePDG HSS/ AAA

SWm

S2b

PGW

S6b

OFCS

OCS

Gy

Gz

S10

Iu-PS

S1-MME

S1-U


GERAN

UTRAN

TrustedIP access

Gb/Iu

HSS

S6a


MME

S5 SGi

S11

S4S3

SGSN

S12 SPR

Gr

PCRF

Sp

Gx Rx

S2a

E-UTRANX2-C

X2-U

ePDG HSS/ AAA

SWm

S2b

PGW

S6b

OFCS

OCS

Gy

Gz

S10

Iu-PS

S1-MME

S1-U

SWnSWnNon-trustedIP access

Non-trustedIP access

GERANGERAN

UTRANUTRAN

TrustedIP accessTrusted

IP access

Gb/Iu

HSS

S6a

IMS / Internet /…IMS / Internet /…SGW

MME

S5 SGiSGi

S11

S4S3

SGSN

S12S12 SPR

Gr

PCRF

Sp

Gx RxRx

S2aS2a

E-UTRANX2-C

X2-UE-UTRAN

X2-C

X2-U

X2-C

X2-U

ePDG HSS/ AAA

SWm

S2bS2b

PGW

S6bS6b

OFCS

OCS

GyGy

Gz

S10S10

Figure 1-6: The Evolved Packet System (EPS), detailed

Figure 1-6 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 and to the SGW via the S11-interface. These interfaces are used for signalling related to UP bearer management. 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). The S12-interface is used for data transfer if the direct tunnel solution is supported in UTRAN. 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-interfaces).



Additional network nodes/functions, some shown in figure 1-6, may be present as well. For example, an evolved Packet Data Gateway (ePDG) is needed for non-trusted IP access and a Policy and Charging Rules Function (PCRF) is required for IMS controlled QoS and charging mechanisms. For the purpose of charging there may also be an Online Charging System (OCS) and/or an Offline Charging System (OFCS) present. The Home Subscriber Server (HSS) holds subscription profiles and security related parameters. Additional subscription/security databases may also be present, such as the Subscription Profile Repository (SPR) and the 'triple-A' server (AAA, short for Authentication, Authorization and Accounting).

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. 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 also dis-allows access using SIM) • The authentication framework should be independent from the used

access network technology. • 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.


1.4 References 23.401 GPRS enhancements for E-UTRAN access 23.402 Architecture enhancements for non-3GPP accesses 25.999 High Speed Packet Access (HSPA) evolution, FDD 36.300 E-UTRA/E-UTRAN; overall description; Stage 2

Apis Technical Training AB LSIG - NAS Copyright © Apis Technical Training AB 2008. All rights reserved. 2-1

2 NAS Protocols

2.1 INTRODUCTION .................................................................................2-2

2.1.1 NAS Functionality.....................................................................2-2

2.1.2 NAS Area Concepts and Identities ..........................................2-3

2.2 NAS SIGNALLING PROCEDURES .......................................................2-4

2.2.1 EMM Procedures .....................................................................2-4

2.2.2 ESM Procedures ......................................................................2-5

2.2.3 NAS States and State Transitions ...........................................2-6

2.3 NAS MESSAGE FORMATS.................................................................2-8

2.4 NAS SECURITY FUNCTIONS..............................................................2-9

2.4.1 Authentication and Key Agreement .........................................2-9

2.4.2 Ciphering and Integrity Protection..........................................2-11

2.5 REFERENCES .................................................................................2-12

2.1 Introduction

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

Figure 2-1: NAS protocol stack

2.1.1 NAS Functionality The Non Access Stratum (NAS) protocols are used for signalling exchange between the UE and the Mobility Management Entity (MME) in the EPC. As can be seen in figure 2-1, 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 and the S1AP layer in the MME. All NAS messages are therefore carried inside, or sent concatenated with, RRC and S1AP messages when transmitted over the radio interface and S1-interface respectively. As of EPS R8 there are only two NAS protocols defined: the EPS Mobility Management protocol (EMM) and the EPS Session Management protocol (ESM). The EMM protocol handles signalling related to UE mobility and signalling related to various security procedures. The ESM protocol handles signalling related to management of default and dedicated user plane bearers. The functionality of both protocols is very similar to the corresponding GSM/UMTS NAS protocols. The EMM protocol is modelled on the GPRS Mobility Management protocol (GMM) and the ESM protocol is modelled on the Session Management protocol (SM).


2.1.2 NAS Area Concepts and Identities The NAS layer makes use of so-called Tracking Areas (TA) for mobility management purposes. The concept of a Tracking Area is in all respects the same as the GSM/UMTS concept of a Routing Area (or Location Area). Hence, the TA is an operator defined group of cells that all ‘belong’ to the area served by one MME. One or more TA may be defined for each MME. The MME is aware of the location of an attached UE at the TA level through the TA Update procedure. The TA is typically, but not necessarily, the area within which the UE is paged for incoming calls. TAI = MCC + MNC + TAC, where

• TAI = Tracking Area Identity • MCC = Mobile Country Code (3 digits) • MNC = Mobile Network Code (3 digits) • TAC = Tracking Area Code (not defined, Sept-08)

As an operator option, there may also be MME Pool Areas defined. An MME Pool Area is defined as an area within which a UE may be served without need to change the serving MME. An MME Pool Area is served by one or more MMEs ("pool of MMEs") in parallel. MME Pool Areas are a collection of complete Tracking Areas. MME Pool Areas may overlap each other, as seen in figure 2-2.

TA 1 TA 2 TA 3 TA 6 TA 7

MME 2MME 1

TA 4 TA 5

MME 1 MME 2 MME 3

MCC (3) MNC (3) MMEGI (16) MMEC (8) M-TMSI (32)

PLMN X

MME Group 1 MME Group 2

MMEI

Pool BPool A

GUMMEI

UE

UE CTX

S-TMSI

Pool C

TA 5

MME 2MME 1 MME 1 MME 2 MME 3

GUTI:

GUTIS-TMSI

TA 1 TA 2 TA 3 TA 6 TA 7

MME 2MME 1

TA 4 TA 5

MME 1 MME 2 MME 3

MCC (3) MNC (3) MMEGI (16) MMEC (8) M-TMSI (32)

PLMN X

MME Group 1 MME Group 2

MMEI

Pool BPool A

GUMMEI

UE

UE CTX

S-TMSI

Pool C

TA 5

MME 2MME 1 MME 1 MME 2 MME 3

GUTI:

GUTIS-TMSI

TA 1 TA 2 TA 3TA 1 TA 2 TA 3 TA 6 TA 7TA 6 TA 7

MME 2MME 2MME 1MME 1

TA 4 TA 5

MME 1 MME 2

TA 4 TA 5

MME 1 MME 2 MME 3MME 3MME 3

MCC (3) MNC (3)MCC (3) MNC (3) MMEGI (16) MMEC (8) M-TMSI (32)

PLMN XPLMN X

MME Group 1MME Group 1 MME Group 2MME Group 2

MMEIMMEI

Pool BPool BPool APool A

GUMMEIGUMMEI

UEUE

UE CTX

S-TMSIS-TMSI

Pool C

TA 5

Pool CPool C

TA 5

MME 2MME 1 MME 1 MME 2 MME 3MME 2MME 1 MME 1 MME 2 MME 3

GUTI:

GUTIS-TMSI

GUTI:

GUTIS-TMSIGUTI

S-TMSI

Figure 2-2: MME pool areas The EPC uses the IMSI number as the permanent user identifier (or rather, USIM identifier). As in the legacy Core Network a temporary identifier is also used, for subscriber identity confidentiality reasons, in place of the IMSI whenever possible. The temporary identifier in the EPS is called the Globally Unique Temporary Identity (GUTI).



The use of the GUTI is very similar to the use of the legacy TMSI (CS domain) and PTMSI (PS domain) numbers. There is a difference however: the GUTI explicitly links with the MME Pool Area concept. The relationship can be seen in figure 2-2. Please note that the length of MCC and MNC is in digits, while the other fields are given in bits. GUTI = MCC + MNC + MMEGI + MMEC + M-TMSI, where

• MMEGI = MME Group Identifier (16 bits) • MMEC = MME Code (8) • M-TMSI = M- Temporary Mobile Subscriber Identity (32)

The MMEGI uniquely identifies a group ('pool') of MMEs within one network. The MMEC uniquely identifies an MME within one such group and the M-TMSI uniquely identifies one UE within one MME (the 'M' is just a label and is not an abbreviation for anything). The MMEGI together with the MMEC combines to the MME Identifier (MMEI). Thus, the MMEI uniquely identifies an MME within one core network. The MMEI together with MCC and MNC combines to the Globally Unique MME Identifier (GUMMEI). Thus, the GUMMEI uniquely identifies an MME on planet Earth. The GUTI is allocated when the UE performs initial registration (i.e. ‘Attach’) with an MME. The GUTI is then typically changed whenever the UE performs some EMM-procedure, such as TA Update. The S-TMSI is a shortened version of the GUTI that uniquely identifies the user within an MME Group (the 'S' is just a label and is not an abbreviation for anything). The shorter S-TMSI, rather than the complete GUTI, is used within most NAS messages.

2.2 NAS Signalling Procedures 2.2.1 EMM Procedures

The EMM procedures are divided into three groups: Common, Specific and Connection Management procedures. The Common procedures relate to security functions and are listed below.

• Authentication: user (USIM) authentication and NAS key agreement. The procedure uses EPS Authentication Vectors (a variant of the UMTS quintets).

• Security Mode Control (SMC): initiation of and control of the

NAS ciphering and integrity protection functions.

• GUTI Re-allocation: provision of a new GUTI to the UE.

• Identification: allows the MME to request either IMSI or IMEI from the UE when needed.


The Specific procedures relate to registration/de-registration functions.

• Attach: initial registration of the UE in one MME for EPS services. The attach procedure is always combined with ESM signalling to establish basic IP-connectivity ('default bearer'). The attach procedure may also be combined with IMSI Attach, whereby the UE also becomes registered in the legacy MSC Server (this is to support the 'CS Fallback' feature).

• Detach: de-registration from the network. May be performed

as a combined detach, whereby the UE becomes de-registered for EPS services and/or non-EPS services (i.e. IMSI Detach).

• Tracking Area Update (TAU): performed when the UE enters

a TA not currently in its stored list of TAIs (normal TAU) or at timer expiry (periodic TAU). May also be a combined update, whereby the UE also performs a Location Area Update towards the MSC Server.

The Connection Management procedures are used for mobile terminating or mobile originating connection management and will always trigger ESM protocol procedures (for the actual call/session setup signalling).

• Paging: used when the UE is in Idle mode and the network has downlink data or signalling pending. The UE responds by initiating the Service Request procedure (there is no explicit 'paging response' message defined).

• Service Request (SR): used when the UE is in Idle or

Connected mode and has uplink data or signalling pending. The network responds by initiating the Authentication and/or SMC procedure.

2.2.2 ESM Procedures The ESM procedures are divided into two groups: Network Initated procedures and UE Initiated procedures. The Network Initiated procedures are used for establishment, modification or release of default or dedicated EPS bearers and are listed below.

• Default EPS Bearer Context Activation: provides the UE

with basic IP-connectivity (a default bearer) to a given external Packet Data Network (PDN). The first default bearer is always established in conjunction with the Attach procedure. Subsequent default bearers, to other PDNs, are established when needed.

• Dedicated EPS Bearer Context Activation: provides the UE

with a bearer associated with a certain QoS and packet filter (Traffic Flow Template, TFT).


• EPS Bearer Context Modification: used by the network to modify the QoS and/or TFT for a given dedicated bearer.

• EPS Bearer Context Deactivation: used by the network to

release a given dedicated or default bearer. To release a default bearer is the same as to disconnect from the associated PDN. When the last default bearer is released the UE enters the detached state.

The UE Initiated procedures are used for establishment, modification or release of default or dedicated EPS bearers.

• UE Requested PDN Connection: request for basic IP-

connectivity (a default bearer) to a given external Packet Data Network (PDN). The first default bearer is always requested in conjunction with the Attach procedure. Subsequent default bearers, to other PDNs, are requested when needed. This procedure always triggers the network initiated Default EPS Bearer Context Activation procedure:

• UE Requested PDN Disconnection: used by the UE to

disconnect from a given PDN.

• UE Requested Bearer Resource Allocation: used by the UE to request a dedicated bearer associated with a certain QoS and TFT. This procedure triggers either the Default EPS Bearer Context Activation procedure or the EPS Bearer Context Modification procedure.

• UE Requested Bearer Resource Release: used by the UE to

release a dedicated bearer.

2.2.3 NAS States and State Transitions There are separate (but mutually dependent) protocol state machines for the EMM protocol and the ESM protocol. The EMM protocol state machine relates to whether the UE is properly registered in the network or not and whether there exists an active NAS Signalling Connection between the UE and MME or not. The ESM protocol state machine deals exclusively with the existence or not of EPS bearers. The EMM protocol state machine contains two sets of states: EMM states and ECM states (EPS Connection Management). The UE is either EMM Registered or EMM Deregistered, i.e. attached or not. The ECM states are only relevant in the EMM Registered state and reflect whether there is an active NAS Signalling Connection established (ECM Connected) or not (ECM Idle).

A NAS Signalling Connection is required for any exchange of NAS messages, with the exception of the very messages that triggers the establishment of the NAS Signalling Connection itself (e.g. Attach Request or Paging).

EMM DEREGISTERED

No MME context

EMM REGISTERED

MME context: IMSI, GUTI, TA list

IP-address, Security association

ECM CONNECTED

NAS Signalling ConnectionData transfer possible

ECM IDLE

No NAS Signalling ConnectionTracking Area Updates

Attach Detach

NAS ConnectionEstablishment

NAS ConnectionRelease

ESM INACTIVE

No PDN context

ESM ACTIVE

PDN Context(s):IP-address, APN, QoS Parameters

S5 IP-address & TEIDS11 IP-address & TEID

(S1-U IP-address & TEID)

Data Transfer Possible when ECM Connected

One Default BearerZero, one or more Dedicated Bearer

EPS BearerEstablishment

Last EPS BearerReleased

EMM DEREGISTERED

No MME context

EMM REGISTERED

MME context: IMSI, GUTI, TA list

IP-address, Security association

ECM CONNECTED

NAS Signalling ConnectionData transfer possible

ECM IDLE

No NAS Signalling ConnectionTracking Area Updates

Attach Detach

NAS ConnectionEstablishment

NAS ConnectionRelease

ESM INACTIVE

No PDN context

ESM ACTIVE








ESM INACTIVE

No PDN context

ESM ACTIVE










Figure 2-3: NAS states

The ESM states are quite straightforward: when at least one (default) bearer is established the UE is in the ESM Active state, otherwise it is in the ESM Inactive state. The ESM signalling needed to establish a bearer requires that the UE is properly registered in the network. It therefore naturally follows that the UE must be in the EMM Registered state whenever it is ESM Active. It also follows that there must be a NAS Signalling Connection present during the ESM signalling phase when a bearer is being established, i.e. the UE is then ECM Connected. However, there is no requirement to keep the NAS Signalling Connection active for the lifetime of an EPS bearer. Hence, the UE may very well be ECM Idle while being ESM Active. This makes sense, since the UE may be attached for days, weeks or even months on end (all the time having a default bearer active). The NAS states (MME related states) are aligned with the RRC states (eNodeB related states, see chapter 4). A UE in RRC Idle state is, from the MMEs point of view, in the NAS state ECM Idle. Paging or a request from higher layers to transmit uplink data or signalling will cause a transition from RRC Idle to RRC Connected, causing also a transition from ECM Idle to ECM Connected. This is not shown in figure 2-3 above.


2.3 NAS Message Formats The NAS messages have different format depending on if it is an EMM message or an ESM message and also on whether the message is security protected or not. All NAS messages are octet-aligned. All EMM messages except Service Request, which has a special format, consist of a Protocol Discriminator, a Security Header Type field, a Message Type field and zero, one or more additional Information Elements (IEs, or payload 'parameters'). All ESM messages consist of a Protocol Discriminator, an EPS Bearer Id field, a Procedure Transaction Id, Message Type field and zero, one or more additional IE. Any security protected NAS message also contains a security header appended at the beginning of the message. The security header consists of a Protocol Discriminator, a Security Header Type field, a NAS Sequence Number field and a Message Authentication Code field.

EPS Bearer Id

Procedure Transaction Id

Protocol Discriminator

Other Information Elements(Mand/Opt/Cond)

Message Type

12345678

Security Header Type

Message Type



12345678

EMM Message ESM Message


MessageAuthentication

Code (4 oct)


NAS Sequence Number

12345678

Security Header

EPS Bearer Id




Message Type

12345678

EPS Bearer Id




Message Type

EPS Bearer Id




Message Type

12345678 12345678


Message Type



12345678


Message Type




Message Type



12345678 12345678

EMM Message ESM Message



Code (4 oct)


NAS Sequence Number

12345678

Security Header



Code (4 oct)


NAS Sequence Number

12345678



Code (4 oct)


NAS Sequence Number



Code (4 oct)


NAS Sequence Number

12345678 12345678

Security Header

Figure 2-4: NAS message format Protocol Discriminator (PD). The PD identifies the NAS protocol (EMM or ESM) to which the message belongs. The PD is defined in TS 24.007 and shares the same value space as the GSM/UMTS NAS protocols. Security Header Type (SHT). The SHT indicates the presence or not of a security header, i.e. whether the message is security protected or not. Message Type (MT). The MT identifies a message (e.g. 'Attach Request').



EPS Bearer Id (EBI). The EBI field specifies the EPS bearer to which the message pertains. Implicitly it also specifies the specific ESM protocol instance to which the message is addressed (there is one ESM protocol entity active per EPS bearer). Procedure Transaction Id (PTI). The PTI allows distinguishing between different parallel bi-directional ESM message flows (or 'transactions'). The PTI also links a 'request' message with its 'response' message for a given transaction. Message Authentication Code (MAC). The MAC field is the output from the NAS integrity protection algorithm (see next section) and is used in the receiver for checking the integrity of the message. NAS Sequence Number (SN). The SN field is used as input to the NAS ciphering and integrity protection algorithms.

2.4 NAS Security Functions 2.4.1 Authentication and Key Agreement

The purpose of the authentication mechanism is to protect the network against unauthorized use. It also protects the subscribers, by denying the possibility for intruders to impersonate valid users (i.e. making calls on someone else's bill…). This is achieved by executing an authentication procedure (authentication challenge) whenever a subscriber requests some kind of service from the network (or initiates a signalling procedure). NAS signalling for authentication takes place between the UE and the MME but involves also the Home Subscriber Server (HSS), where the Authentication Vectors are stored/produced. The authentication procedure also includes network authentication. This process makes sure the UE knows that it is connected to a serving network that is authorised by the user's service provider. Authentication and Key Agreement (AKA) is the combined process of authenticating the user (and network) and calculating keys for NAS ciphering and integrity protection. A so-called ‘security context’ is established in the UE and in the MME after a successful AKA run. The AKA procedure must, according to the specifications, be performed at least during initial attach. After that it is up to the MME node involved when to perform a new AKA run. It may be performed whenever the UE wishes to execute some signalling procedure (e.g. tracking area update) or when the UE requests some form of service (e.g. establishment of dedicated bearers speech call) or both.


An EPS Authentication Vector (AV) is produced in the HSS (or in a co-located Authentication Centre, AuC) and consists of four parameters:

• RAND (128 bits) is input to a set of algorithms, together with the secret authentication key K, for calculation of RES, AUTN and KASME. The authentication key, K, is uniquely linked to one, and only one, IMSI number in the HSS/AuC. The RAND parameter from a selected AV is sent to the UE in an Authentication Request message whenever the MME wishes to perform an AKA run. This parameter is sometimes referred to as the ‘authentication challenge’ or ‘random challenge’.

• RES/XRES (length not defined, Sept-08) is the signed response

used for authentication. This parameter is sent in the Authentication Response message from the UE to the MME. The UE is regarded as authenticated if the RES provided by the UE matches the one stored in the selected AV in the MME. The term ‘XRES’ is short for expected RES and is just an indication that the RES (i.e. XRES) stored in the MME will be compared to another version of itself (i.e. the RES sent back from the UE).

• AUTN (112) is the authentication token used by the UE to validate

that the network is authorised. The AUTN is sent to the UE along with the RAND in the Authentication Request message. The AUTN is calculated in the HSS/AuC based on the Anonymity Key (AK) and the Message Authentication Code (MAC) in the same manner as in a GSM/UMTS HSS. Note: do not confuse this 'MAC' parameter with the 'MAC' present in a security protected NAS message, they are not the same!

• KASME (256) is the Access Security Management Entity key, where

'ASME' is to be understood as the MME in the EPS case. KASME is derived from an HSS/AuC produced Ciphering Key (CK) and integrity Key (IK), both 128 bits long. The CK and IK keys are, in turn, calculated in the same manner as in a GSM/UMTS HSS.

The EPS system uses a security key hierarchy (figure 2-5) with multiple levels. The base keys on the top level (CK and IK) are only visible to the UE and the home network domain databases (HSS/AuC). On the next level there is KASME, which is only visible to the UE and the visited MME. KASME 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). KASME is also used for derivation of an eNodeB key, KeNB. Finally, KeNB 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).

K

CK, IK

KASME

IKNASCKNAS

KeNB

CKUP CKCP IKCP

Never leaves Home Domain

Never leaves EPC(KASME is vPLMN specific)

Only used in access NW(KeNB is cell specific)

K

CK, IK

KASME

IKNASCKNAS

KeNB

CKUP CKCP IKCP

Never leaves Home Domain

Never leaves EPC(KASME is vPLMN specific)

Only used in access NW(KeNB is cell specific)

K

CK, IKCK, IK

KASMEKASME

IKNASCKNAS IKNASCKNAS

KeNBKeNB

CKUP CKCP IKCPCKUP CKCP IKCP

Never leaves Home DomainNever leaves Home Domain

Never leaves EPC(KASME is vPLMN specific)Never leaves EPC(KASME is vPLMN specific)

Only used in access NW(KeNB is cell specific)Only used in access NW(KeNB is cell specific)

Figure 2-5: EPS security key hierarchy

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.

2.4.2 Ciphering and Integrity Protection

Other IEs (one or more message)Standard Header

ProtocolDiscriminator

SecurityHeader Type

Encryption

Integrity

NAS SN

Other inputCKNAS

IKNASOther input

NAS SN

NAS SN

Security Header

MAC



SecurityHeader Type

Encryption

Integrity

NAS SN

Other inputCKNAS

IKNASOther input

NAS SN

NAS SN

Security Header

MAC



SecurityHeader Type


SecurityHeader Type

EncryptionEncryption

IntegrityIntegrity

NAS SNNAS SN

Other inputOther inputCKNASCKNAS

IKNASIKNASOther inputOther inputOther input

NAS SNNAS SN

NAS SNNAS SN

Security HeaderSecurity Header

MACMAC

Figure 2-6: Ciphering and integrity protection of NAS messages

A simplified version of the processing sequence for ciphering and integrity protection of NAS messages can be seen in figure 2-6 above. The message to be encrypted is fed to the encryption algorithm together with the NAS Ciphering Key, the NAS Sequence Number and additional input parameters. The output is an encrypted message (the NAS SN is not encrypted). The encrypted message is then fed to the integrity algorithm together with the NAS Integrity Key, the NAS SN and additional input parameters. The output is the calculated MAC, which is placed in the security header appended to the message.



2.5 References 24.007 Mobile radio interface layer 3; general aspects 24.301 Non-Access Stratum (NAS) protocol for EPS; stage 3 33.401 3GPP System Architecture Evolution: security architecture 33.821 Rationale and track of security decisions in LTE/SAE

Apis Technical Training AB LSIG - S1 and S11 Copyright © Apis Technical Training AB 2008. All rights reserved. 3-1

3 S1 and S11-interface (S1AP & GTP)

3.1 INTRODUCTION .................................................................................3-2

3.2 S1-INTERFACE .................................................................................3-3

3.2.1 S1-MME: S1AP Procedures ....................................................3-3

3.2.2 S1-MME: SCTP and Transport Protocols ................................3-4

3.2.3 S1-U: GTP-U Procedures ........................................................3-5

3.3 S11-INTERFACE ...............................................................................3-6

3.3.1 GTP-C Procedures...................................................................3-6

3.3.2 GTP Header Format.................................................................3-7

3.4 EPS QOS CONCEPTS ......................................................................3-8

3.4.1 User Plane Bearer Establishment............................................3-8

3.4.2 QoS Parameters ....................................................................3-10

3.5 REFERENCES .................................................................................3-12

3.1 Introduction

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

eNB MME

S1-MME

GTP-C

UDP

IP

L1/L2

GTP-C

UDP

IP

L1/L2

S11

SGW

GTP-U

UDP

IP

L1/L2

eNB

S1-U

GTP-U

UDP

IP

L1/L2

SGW

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

eNB MME

S1-MME

GTP-C

UDP

IP

L1/L2

GTP-C

UDP

IP

L1/L2

S11

SGW

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

eNB MME

S1-MMES1-MME

GTP-C

UDP

IP

L1/L2

GTP-C

UDP

IP

L1/L2

S11S11

SGW

GTP-U

UDP

IP

L1/L2

eNB

S1-U

GTP-U

UDP

IP

L1/L2

SGW

GTP-U

UDP

IP

L1/L2

eNB

S1-US1-U

GTP-U

UDP

IP

L1/L2

SGW

Figure 3-1: S1/S11 protocol stacks

The S1-interface connects E-UTRAN (eNBs) with the EPC. The S1-interface is an IP-based interface and can therefore be seen as a point to multi-point interface. The Control Plane (CP) instance of the S1-interface (S1-MME) uses the S1 Application Protocol (S1AP) for control signalling purposes between the eNB and the MME. The S1AP protocol runs on top of the Stream Control Transmission Protocol (SCTP). The User Plane (UP) instance of the S1-interface (S1-U) uses the GPRS Tunnelling Protocol- User plane (GTP-U) for user data tunnelling. The termination point on the EPC side for S1-U is the Serving Gateway, SGW. The S11-interface is, like the S1-interface, an IP-based point to multi-point interface. The S11-interface is used for signalling between the MME and the SGW (upper right in figure 3-1) and does not have a UP instance. The S11-interface uses the GPRS Tunnelling Protocol- Control plane (GTP-C) for control signalling purposes. Please see figure 1-2 for the network architecture corresponding to the protocol stacks above.



3.2 S1-Interface 3.2.1 S1-MME: S1AP Procedures

The S1AP protocol is used for control signalling exchange between eNB and MME. The S1 procedures are divided into Context management, EPS Bearer management, Handover, Location Reporting, Node management and 'Other' procedures. All UE associated signalling takes place over a logical S1 Connection. The UE-specific S1 Connection is identified in each node with an S1AP UE Identifier. Thus, all S1AP messages pertaining to a specific UE will carry two reference numbers: the S1AP UE Id selected by the eNB and the S1AP UE Id selected by the MME. One such pair of reference numbers uniquely identifies a UE context in a node.

Context Management Procedures 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: EPS 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 TA Update). The logical S1 Connection is established after successful execution of this procedure. UE Context Modification. The purpose of this procedure is to modify an already established UE context in the eNB (e.g. change the eNB security key). The procedure is always initiated from the MME. UE Context Release. The purpose of this procedure is to release the logical S1 Connection related to a specific UE (thus also releasing the associated UE context). The procedure may be initiated from the MME (e.g. due to completed NAS signalling transaction) or from the eNB (due to handover, timer expiry or other radio related reason).

EPS Bearer Management Procedures The EPS Bearer management procedures are 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 procedures are always initiated from the MME, with the exception of EPS Bearer Release that may be initiated from the eNB.

Handover Procedures 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.


Location Reporting Procedures These procedures allow the MME to request the current location (i.e. cell) of the UE. The eNB can be asked to report immediately or when the UE leavers the current cell.

Node Management Procedures S1 Setup. The purpose of the S1 Setup procedure is to exchange application level data needed for the eNB and MME to interoperate correctly on the S1-interface. This procedure shall be the first S1AP procedure triggered after the SCTP association (see below) has become operational. The eNB informs the MME about its eNB Identity number and which TAs it supports. The MME informs the eNB about its MME Identity number (GUMMEI) and which PLMNs it supports. Configuration Update. The purpose of this procedure is to exchange application level data that have changed since the last S1 setup procedure was executed. The procedure may be initiated from the eNB or the MME. Reset. The purpose of the Reset procedure is to initialise or re-initialise the S1AP UE contexts, in the event of a failure in the MME or eNB. This procedure does not affect the application level configuration data exchanged during the S1 Setup procedure.

Other Procedures 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 RRC Information Transfer procedure described in chapter 4).

3.2.2 S1-MME: SCTP and Transport Protocols The Stream Control Transmission Protocol (SCTP) is used to support the exchange of S1AP signalling messages between eNB and MME. 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 S1-MME interface instance is used, with different pairs of Stream Identifiers for S1-MME non-UE associated and UE associated procedures. An SCTP PDU consists of a header and one or more 'chunk' fields. The payload is either higher layer information (an S1AP message in this case) or SCTP layer control information. The chunk type 'DATA' is used for transport of higher layer information.

Common Header(12 bytes)

Set per association

at Initialisation

Registeredwith IANA

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

Source Port Destination Port

Verification Tag

Checksum

Chunk LengthChunk FlagsChunk TypeChunk Header

(4 bytes)

Transport Sequence Number

Payload Protocol Id

Chunk Values(variable)

Stream Identifier Stream Sequence Number (opt)

Payload or Control

Chunk LengthReservedType = DATA U B E

DATA, possibly segmented(e.g. X2AP or S1AP message)

General SCTP PDU Format

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

The ’DATA’ Chunk

Common Header(12 bytes)

Set per association

at Initialisation

Registeredwith IANA

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210


Verification Tag

Checksum


Verification Tag

Checksum

Chunk LengthChunk FlagsChunk Type Chunk LengthChunk FlagsChunk TypeChunk Header

(4 bytes)

Transport Sequence Number

Payload Protocol Id

Chunk Values(variable)

Stream Identifier Stream Sequence Number (opt)

Payload or Control

Chunk LengthReservedType = DATA U B E

DATA, possibly segmented(e.g. X2AP or S1AP message)

General SCTP PDU Format

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

The ’DATA’ Chunk

Figure 3-2: SCTP PDU format

The transport layer uses standard Internet Engineering Task Force (IETF) defined protocols, i.e. IP running over the selected data link and physical layer protocols. These transport layer protocols are not discussed further in this document.

3.2.3 S1-U: GTP-U Procedures The main task of the GTP-U protocol is encapsulation and tunnelling of user data packets between network nodes. It is used on the S1-interface, the X2-interface (between eNBs) and on a number of additional EPC User Plane 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’). Please see section 3.3.2 for a more detailed description of the GTP header.



3.3 S11-Interface The GTP protocol defined for EPS is very similar to the legacy GTP protocol in use already since the introduction of GPRS in Release 97. Some 3GPP standardisation documents refer to the 'EPS GTP' as Evolved GTP (eGTP). However, one could as well simply refer to the 'EPS GTP' as 'GTP version 2' (GTP version 1 was introduced in R99). The GTP Control Plane (GTP-C) protocol is used on a number of EPC interfaces. The exact set of GTP-C procedures in use is therefore interface-dependent. In the following, only those GTP-C procedures that are relevant for the S11-interface are described.

3.3.1 GTP-C Procedures The GTP version 2 specification does not divide GTP functions so much into 'procedures' as into 'scenarios'. For example, the specific GTP-C message (and thus also procedure) to use for releasing an EPS bearer in the SGW will be different depending on whether the release was UE initiated or eNB/MME initiated. A consequence of this is that there are several GTP-C messages/procedures that achieve, more or less, the same thing. For ease of reading the following descriptions do therefore not include all scenarios that will trigger a given GTP procedure. Instead, the reader is encouraged to consult the GTP version 2 specification: TS 29.274. Create Session. This procedure is initiated from the MME towards the SGW when the UE requests activation of a default EPS bearer due to initial Attach or when the SGW changes due to the UE performing a TA Update. Create Bearer. This procedure is initiated from the MME towards the SGW due to network initiated establishment of a dedicated EPS bearer. Allocate Bearer Resource. This procedure is initiated from the MME towards the SGW due to UE initiated establishment of a dedicated EPS bearer. Modify Bearer. This procedure is initiated from the MME towards the SGW when a dedicated bearer needs to be released due to network initiated S1 Release, or modified due to the UE performing TA Update that does not trigger change of SGW. Delete Session. This procedure is initiated from the MME towards the SGW due to UE initiated release of a default bearer. Release TFT Filter. This procedure is initiated from the MME towards the SGW due to UE initiated release of a dedicated EPS bearer.

Update User Plane. This procedure is initiated from the MME towards the SGW when a GTP tunnel needs to be modified (moved from one eNB to another) as a result of handover. Downlink Data Notification. This procedure is initiated from the SGW towards the MME in order to trigger paging for an incoming call/session. Echo. A GTP-C entity (within eNB, SGW, MME or other node) may send an Echo Request to find out if the peer GTP entity is 'alive'. The peer entity shall respond with an Echo Response message. This procedure is relevant for both GTP-C and GTP-U. Version Not Supported. This procedure is used to inform a peer GTP entity that the GTP version used in received message is not supported. The sending entity also includes an indication of the 'highest' version of the GTP protocol that it supports. This procedure is relevant for both GTP-C and GTP-U.

3.3.2 GTP Header Format A GTP PDU consists of a GTP header, zero one or more extension headers and a GTP message. The GTP message is either a GTP-C or a GTP-U message. Thus, GTP-C and GTP-U use the same header format but the use of a given header field is not necessarily the same for GTP-C and GTP-U.

Tunnel EndpointIdentifier, TEID

(4 oct)

12345678

Sequence Number(2 oct)

Spare Octets(2 oct)

Message Type

TFFSVersion SE FFS

Message Length excl mandatory header (2 oct)

CR Extension Header Type NEH

Mandatory Header(GTP-C and GTP-U)

All messages, exceptEcho Req/Resp and

Version Not Supported

All GTP-C messages

R8 extension: PDCPsequence number

Spare Extension Header Length

Extension Value(s)Padding if needed

(n x 4 oct)

Tunnel EndpointIdentifier, TEID

(4 oct)

12345678 12345678


Spare Octets(2 oct)


Spare Octets(2 oct)

Message Type

TFFSVersion SE FFS


Message Type

TFFSVersion SE FFS


CR Extension Header Type NEH

Mandatory Header(GTP-C and GTP-U)

All messages, exceptEcho Req/Resp and

Version Not Supported

All GTP-C messages

R8 extension: PDCPsequence number

Spare Extension Header Length

Extension Value(s)Padding if needed

(n x 4 oct)

Figure 3-3: GTP header format

The length of a GTP version 2 header is always a multiple of 4 octets, containing at least the mandatory part shown in the figure above. The usage of the different fields is described below:



Version: specifies the GTP protocol version (version 2 in this case). FFS: For Further Study (currently not standardised). T flag: signals the presence or not of the TEID field. E flag: signals the presence or not of the first extension header. S flag: signals the presence or not of the sequence number field. Message Type: specifies the GTP message (e.g. 'Echo Request'). Message Length: specifies the length in octets of the GTP message, excluding the mandatory 4-octet header. Tunnel Endpoint Identifier (TEID): together with an IP-address and a UDP port number, the TEID uniquely identifies a GTP tunnel. The TEID is unique per EPS bearer for GTP-U and per PDN connection for GTP-C. Sequence Number: allows in-order delivery of user plane PDUs (and re-ordering of forwarded user plane PDUs during handover) in the case of GTP-U. For GTP-C the sequence number links a 'request' message with its 'response', thus acting as a transaction identifier. Extension Header Type: specifies the type of extension header. The current R8 GTP standard only defines one extension header: the PDCP sequence number (passed between nodes during handover). Comprehension Required (CR): specifies to the receiving entity if the extension header must be understood or whether it can be skipped in case the receiver does not recognise it. Next Extension Header flag (NEH): indicates the presence or not of yet another extension header, immediately following the current one.

3.4 EPS QoS Concepts 3.4.1 User Plane Bearer Establishment

The EPS specifications separate between default bearers and dedicated bearers. With a default bearer is meant basic IP-connectivity between the UE and some external Packet Data Network (PDN). Such a bearer does not guarantee any level of QoS and is typically used for signalling purposes only (or service with very low requirements). With a dedicated bearer is meant any other bearer, besides the default bearer, that is established between the UE and the same PDN. There may be zero, one or more dedicated bearers active for each PDN (but only one default bearer).

There are different ways of establishing dedicated bearers: UE initiated, EPC initiated and IMS/PCC initiated bearer establishment. These different mechanisms can all be realised with a limited number of signalling procedures or, rather, blocks of procedures as seen (in microscopic text) in figure 3-4 below.

E: DedicatedBearerActivation

PCCProvisionCREATE BEARER REQ CREATE B. REQ

ESM: ACT DED EPS BEARER CTX REQ ESM: ACTIVATE DEDICATEDEPS BEARER CTX REQ

ESM: ACTIVATE DEFAULTEPS BEARER CTX ACC

ESM: ACT DED EPS BEARER CTX ACCPCC

Prov Ack

CREATE BEARER RESP CREATE B. RESP

D: UE InitiatedBearerResourceAllocation

ESM: BEARER RESOURCEALLOCATION REQ

ESM: BEARER RESOURCE ALLOC REQPull PCCProvision

REQUEST BEARERRESOURCE ALLOCATION

REQ BEARERRES. ALLOC.

C: IMS-basedSessionNegotiation

SIP/SDP

A: Paging GTP-U: DATAPAGING

DL DATA NOTIFICATIONPAGINGDATA

B: ServiceRequest EMM: SERVICE REQUEST EMM: SERVICE REQUEST

NAS/AS AUTHENTICATION & SMC

PGWSGWMMEeNB

S5: GTP-CS11: GTP-CS1-MME: S1APUu: RRC/NAS

PCRF

Gx: Diameter






Prov Ack








SIP/SDP


DL DATA NOTIFICATIONPAGINGDATA



PGWSGWMMEeNB

S5: GTP-CS11: GTP-CS1-MME: S1APUu: RRC/NAS

PCRF

Gx: Diameter






Prov Ack







Prov Ack













SIP/SDPC: IMS-basedSessionNegotiation

SIP/SDP


DL DATA NOTIFICATIONPAGINGDATAA: Paging GTP-U: DATA

PAGINGDL DATA NOTIFICATIONPAGING

DATA




NAS/AS AUTHENTICATION & SMCNAS/AS AUTHENTICATION & SMC

PGWSGWMMEeNBeNB

S5: GTP-CS11: GTP-CS1-MME: S1APUu: RRC/NAS S5: GTP-CS11: GTP-CS1-MME: S1APUu: RRC/NAS

PCRF

Gx: DiameterGx: Diameter

Figure 3-4: Procedures for EPS bearer establishment

The UE initiated establishment case is, perhaps, the mechanism most similar to how QoS is handled in legacy networks: the UE requests a certain QoS and the network responds either 'OK' or 'forget it'. For a connected mode UE this corresponds to step D in the figure followed by step E. In case the UE is in idle mode this must be preceded by step B, in order to establish a security protected NAS Signalling Connection first. The EPC initiated establishment case can be realised in a number of ways. Assuming that the UE is in idle mode we must start with paging (step A), to which the UE responds with a Service Request message (step B). The network will then push QoS parameters to the UE using the procedures in step E again (there is some GTP signalling required between steps B and E that is not visible in the figure). If the UE is already connected we can simply skip the paging and go straight for step E. The IMS/PCC initiated establishment case requires support for the IMS-based Policy and Charging Control framework (PCC), the details of which is far outside the scope of this course. In short though, neither the UE nor the EPC will in such a case be the entity selecting QoS parameters. Instead there will be a form of end-to-end 'negotiation' between the UE and whatever other entity is involved (e.g. another UE or a web server). This negotiation is done using the Session Initiation Protocol (SIP), step C in the figure above. This signalling is, from the point of view of the EPC, seen as just any other user plane IP packets being routed through the network.



However, control nodes within the IMS infrastructure will be perfectly aware of what those SIP messages contain and can then push down QoS policies to the PDN Gateway via the Policy and Charging Rules Function (PCRF). Several IMS/PCC-based scenarios can be foreseen depending on whether the UE is the entity initiating the SIP signalling or not and whether the UE is in idle or connected mode. Assume that the UE is not the entity that initiates the SIP signalling ('MT case'). If the UE is in idle mode we need to page the UE in order to deliver the first incoming SIP packet. This would then result in the sequence A, B, C and E. If the UE is already connected we skip steps A and B. Assume that the UE is the entity that initiates the SIP signalling ('MO case'). If the UE is in idle mode it must start with a Service Request, so that we can send the first outgoing SIP packet over a security-protected connection. The sequence then becomes B, C and E. There are more cases possible but the point here is that we can, with a limited number of carefully defined procedures, allow a large number of scenarios to be realised.

3.4.2 QoS Parameters The EPS QoS architecture has, from a parameter point of view, been substantially simplified as compared to legacy networks. As already mentioned, there are only two types of bearers: default bearers and dedicated bearers. Furthermore, an EPS bearer either has a guaranteed bit rate (GBR) or it has not. A default bearer is always a non-GBR bearer. Subscription data in the HSS sets a maximum limit, for each PDN, on the bit rate that the network should provide for a default bearer. This parameter is called the Aggregate Maximum Bit Rate (AMBR) and cannot be changed or overridden by the EPC. A dedicated bearer can be a GBR or a non-GBR bearer. The EPC, or the PCC framework, may also assign a (variable) Maximum Bit Rate (MBR) for each dedicated bearer. The MBR may, or may not, be part of the subscription profile stored in the HSS. Both default and dedicated bearers are, besides the above mentioned bit rates, also associated with a Traffic Flow Template (TFT) and a QoS Class identifier (QCI). The TFT is a specification of a packet filter to be applied to all IP packets sent over a given bearer. A TFT could, for example, only allow TCP/IP packets or UDP/IP packets or only packets with a certain port number or destination address (or any specific combination of port, address and protocol).

The QCI is a number that, in turn, links to the acceptable/allowed packet delay budget and packet loss rate. Some of the lower QCI-values are standardised while the rest are open for operator specific definitions. The (current) QCI table can be seen in the figure below.

Best effort TCP bulk datan.a.High (~500ms)9 (non-GBR)

…

Killer ApplicationOperator definedOperator definedUp to 256

Preferred TCP bulk datae.g. 10-6Medium (~250ms)8 (non-GBR)

TCP interactivee.g. 10-4Medium (~250ms)7 (non-GBR)

Interactive Gaminge.g. 10-3Low (~50ms)6 (non-GBR)

IMS signallinge.g. 10-6Low (~50 ms)5 (non-GBR)

StreamingLow (e.g.10-3)250 ms4 (GBR)

Conversational PS VideoMedium (e.g. 10-2)90ms3 (GBR)

VoIPMedium (e.g.10-2)50 ms2 (GBR)

Realtime GamingHigh (e.g.10-1)< 50 ms1 (GBR)

Example ServicesPacket Loss RatePacket Delay BudgetQoS Class Identifier

Best effort TCP bulk datan.a.High (~500ms)9 (non-GBR)

…

Killer ApplicationOperator definedOperator definedUp to 256

Preferred TCP bulk datae.g. 10-6Medium (~250ms)8 (non-GBR)

TCP interactivee.g. 10-4Medium (~250ms)7 (non-GBR)

Interactive Gaminge.g. 10-3Low (~50ms)6 (non-GBR)

IMS signallinge.g. 10-6Low (~50 ms)5 (non-GBR)

StreamingLow (e.g.10-3)250 ms4 (GBR)

Conversational PS VideoMedium (e.g. 10-2)90ms3 (GBR)

VoIPMedium (e.g.10-2)50 ms2 (GBR)

Realtime GamingHigh (e.g.10-1)< 50 ms1 (GBR)

Example ServicesPacket Loss RatePacket Delay BudgetQoS Class Identifier

Figure 3-5: QoS Class Identifiers (QCI)

The QoS parameters mentioned in this section are translated, in an implementation dependent way, into radio interface parameters that are passed to the eNB packet scheduler (MAC protocol), allowing realisation of Data Radio Bearers that fulfil the established QoS context.



3.5 References 23.203 Policy and Charging Control architecture 23.401 GPRS enhancements for E-UTRAN access (stage 2) 29.274 GPRS; evolved GPRS Tunnelling Protocol (eGTP) for EPS 36.413 E-UTRA S1 Application Protocol (S1AP) specification

Apis Technical Training AB LSIG - RRC Copyright © Apis Technical Training AB 2008. All rights reserved. 4-1

4 Uu-interface part I: Radio Resource Control (RRC)

4.1 INTRODUCTION .................................................................................4-2

4.2 RRC SIGNALLING PROCEDURES .......................................................4-3

4.2.1 System Information Broadcast .................................................4-3

4.2.2 Paging ......................................................................................4-3

4.2.3 RRC Connection Establishment ..............................................4-3

4.2.4 RRC Connection Reconfiguration............................................4-4

4.2.5 Security Mode Control..............................................................4-4

4.2.6 UL/DL Information Transfer......................................................4-4

4.2.7 UE Capability Transfer .............................................................4-4

4.2.8 Measurement Control and Reporting.......................................4-4

4.2.9 Handover..................................................................................4-5

4.3 RRC MESSAGE FORMAT ..................................................................4-6

4.3.1 ASN.1 and PER .......................................................................4-6

4.4 REFERENCES ...................................................................................4-8

4.1 Introduction

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

Figure 4-1: RRC protocol stack

The RRC protocol is responsible for all layer 3 control signalling exchange between the UE and the eNodeB. The RRC signalling almost exclusively relate to management of radio resources. The RRC protocol 'sits' on top of the Packet Data Convergence Protocol (PDCP) in the UE and the eNodeB. The PDCP protocol is, among other things, responsible for ciphering and integrity protection of RRC messages. The NAS protocols, see chapter 2, reside 'on top' of the RRC layer in the UE. The RRC protocol therefore acts as a 'transport container' whenever NAS messages needs to be transmitted over the radio interface (with the S1AP protocol being the corresponding NAS 'transport container' over the S1-interface). The RRC protocol is also responsible for configuring the lower layer protocols when needed. The lower protocols layers in the UE (PDCP, RLC, MAC, PHY) never take any ‘important decisions’ by themselves. They all rely on configuration orders from higher protocol layers, i.e. the RRC protocol. This ‘inter-layer’ communication is performed using so-called protocol primitives. A large number of such primitives, for different purposes, are defined between each protocol layer. For example, an incoming RRC message will be delivered step-by-step up through the protocol stack. This inter-layer message delivery is realised through the use of primitives. The RRC protocol then decodes the message and starts to configure the lower layers accordingly. This configuration of lower layers is also realised through the use of primitives.



4.2 RRC Signalling Procedures The functionality of the E-UTRAN RRC protocol is, on the procedure level, very similar to the UTRAN RRC protocol, with which the reader may be familiar. Some E-UTRAN RRC procedures are briefly described in the following.

4.2.1 System Information Broadcast The purpose of System Information (SI) broadcasting is to provide the UEs with essential parameters needed for communication with E-UTRAN. The SI parameters are grouped into System Information Blocks (SIBs), where a given System Information message may contain one or more SIB. SI messages are transmitted on either the Broadcast Channel (BCH) or the Downlink Shared Channel (DL-SCH). There are two special SIBs: the Master Information Block (MIB) and SIB1, which are never transmitted together with any other SIB (i.e. there is a separate message defined for each of the two). The MIB contains basic information about a cell such as the system bandwidth, the number of eNodeB transmit antennas and the current system frame number. The MIB is always broadcast with a Transmission Time Interval (TTI) of 40ms and is the only SI sent on BCH. SIB1 contains information relevant when the UE needs to evaluate whether it is allowed to access a cell or not. It carries the PLMN Id, TA code, cell id and control parameters for cell selection. It also contains scheduling information for all other SIBs broadcast in the cell (i.e. scheduling of SIB2, SIB3 etc). SIB1 is always broadcast with a TTI of 80ms. Other SIBs can have TTIs in the range 80-5120ms.

4.2.2 Paging The paging procedure is initiated to offer a CN initiated call/session or to indicate a change/update in system information. The paging identity is either the IMSI or, preferably, the S-TMSI. A correctly addressed and decoded Paging message will cause the UE to initiate the RRC Connection Establishment procedure (or to re-read SI).

4.2.3 RRC Connection Establishment This procedure will move the UE from the RRC Idle state to the RRC Connected state. 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.


The RRC Connection Establishment procedure results in Signalling Radio Bearer 1 (SRB1) being established. SRB1 may be established using a default configuration, thus reducing the amount of parameters that needs to be signalled. The signalling to establish SRB1 takes place on SRB0 with a fixed configuration defined in the RRC specification.

4.2.4 RRC Connection Reconfiguration This is a multi-purpose procedure for establishment, reconfiguration and release of SRBs or user plane Data Radio Bearers (DRBs), for executing handovers and for configuring measurements. The reconfiguration typically includes 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.

4.2.5 Security Mode Control Procedure used to instruct the UE to begin Access Stratum (AS) ciphering and integrity protection of RRC signalling and user plane data. Triggered by this procedure, the UE uses the KASME key (calculated through the NAS AKA procedure) to derive an eNodeB key, KeNB. KeNB is then in turn used to derive the ciphering and integrity keys needed for user plane and control plane security. Integrity protection of RRC signalling is mandatory in the specifications while ciphering is defined as optional.

4.2.6 UL/DL Information Transfer The purpose of this procedure is to transfer NAS (or non-3GPP) signalling over the radio interface. Please note that the NAS messages transferred will be doubly protected if NAS security, as well as AS security, is active. This procedure is in all respects identical to the UTRAN RRC 'Direct Transfer' procedure.

4.2.7 UE Capability Transfer The purpose of this is to transfer UE Radio Access Capability (RAC) information to the eNodeB. The procedure may be initiated by the UE (indication) or the eNodeB (request). RAC includes information regarding the UE's inter-RAT capabilities, measurement capabilities and capabilities/ restrictions related to lower layer protocols (PDCP, RLC, MAC, PHY).

4.2.8 Measurement Control and 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 and/or to support eNodeB self-optimization. The eNodeB uses the RRC Connection Reconfiguration message to specify what the UE should measure, where to measure, how/if to report and so on.


This allows the eNodeB to configure different measurements for different UEs, for example based on the type of service and the UE capabilities. It is also possible to specify multiple measurements for one and the same UE. To separate different measurement sessions for the same UE, the eNodeB always includes a Measurement Id in the measurement configuration message. The UE will include this Measurement Id in each Measurement Report it sends back. Thus, the Measurement Id can be seen as a ‘transaction identifier’, linking a given configuration message with a given report. There are several different types of measurements defined in the RRC specification. Some common examples are: intra-frequency, inter-frequency and inter-RAT measurements. A measurement type can be active throughout a call/session or only during a limited period of time. The UE can be ordered to send measurement reports periodically and/or to use so-called 'event reporting'. ‘Event reporting’ simply means that the UE can be ordered to ‘look out for’ a number of predefined events. An example of an event is when the received signal strength from a monitored neighbouring cell becomes higher than some set threshold, or becomes ‘better’ relative to the serving cell. Such an event could, for example, be used to trigger a handover. The currently defined events for E-UTRA operation are:

Event A1: Serving cell becomes better than threshold Event A2: Serving cell becomes worse than threshold Event A3: Neighbour cell becomes offset better than serving cell Event A4: Neighbour cell becomes better than threshold Event A5: Serving cell becomes worse than threshold1 and

Neighbour cell becomes better than threshold2

Event B1: Inter-RAT neighbour cell becomes better than threshold Event B2: Serving cell becomes worse than threshold1 and

Inter-RAT neighbour becomes better than threshold2. It is important to note that the 3GPP standardisation documents do not specify the exact method to perform or evaluate these measurements. What the standards tell us is what quantities that may be measured under certain circumstances and with what accuracy. How the actual measurements/ samples are taken and what decisions should be taken based on these measurements is out of the scope of the standards.

4.2.9 Handover 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.

4.3 RRC Message Format 4.3.1 ASN.1 and PER

Some of the higher layer protocols used in E-UTRAN are defined using Abstract Syntax Notation 1 (ASN.1). This is the case for the RRC, S1AP and X2AP protocols. ASN.1 is an internationally standardised, vendor independent, platform independent and language independent notation for specifying data structures in an abstract way. The purpose of ASN.1 is to make it possible to, in a well-structured and implementation independent way, specify a description of the contents of a message (abstract syntax) separately from how the message is actually encoded for transmission (transfer syntax). The ASN.1 definition (Sept-08) of the 'RRC Connection Reconfiguration' message can be seen in the figure below.

-- ASN1START

RRCConnectionReconfiguration ::= SEQUENCE {rrc-TransactionIdentifier RRC-TransactionIdentifier,criticalExtensions CHOICE {

c1 CHOICE{rrcConnectionReconfiguration-r8 RRCConnectionReconfiguration-r8-IEs,spare7 NULL,spare6 NULL, spare5 NULL, spare4 NULL,spare3 NULL, spare2 NULL, spare1 NULL

},criticalExtensions SEQUENCE {}

}}

RRCConnectionReconfiguration-r8-IEs ::= SEQUENCE {measurementConfiguration MeasurementConfiguration OPTIONAL, -- Need OPmobilityControlInformation MobilityControlInformation OPTIONAL, -- Need OPnas-DedicatedInformation NAS-DedicatedInformation OPTIONAL, -- Need OPradioResourceConfiguration RadioResourceConfiguration OPTIONAL, -- Need OPsecurityConfiguration SecurityConfiguration OPTIONAL, -- Cond Handoverue-RelatedInformation UE-RelatedInforamtion OPTIONAL, -- Need OP...

}

-- ASN1STOP

-- ASN1START

RRCConnectionReconfiguration ::= SEQUENCE {rrc-TransactionIdentifier RRC-TransactionIdentifier,criticalExtensions CHOICE {

c1 CHOICE{rrcConnectionReconfiguration-r8 RRCConnectionReconfiguration-r8-IEs,spare7 NULL,spare6 NULL, spare5 NULL, spare4 NULL,spare3 NULL, spare2 NULL, spare1 NULL

},criticalExtensions SEQUENCE {}

}}

RRCConnectionReconfiguration-r8-IEs ::= SEQUENCE {measurementConfiguration MeasurementConfiguration OPTIONAL, -- Need OPmobilityControlInformation MobilityControlInformation OPTIONAL, -- Need OPnas-DedicatedInformation NAS-DedicatedInformation OPTIONAL, -- Need OPradioResourceConfiguration RadioResourceConfiguration OPTIONAL, -- Need OPsecurityConfiguration SecurityConfiguration OPTIONAL, -- Cond Handoverue-RelatedInformation UE-RelatedInforamtion OPTIONAL, -- Need OP...

}

-- ASN1STOP

Figure 4-2: Example of ASN.1 definition (from TS 36.331)

In short: ASN.1 tells you what is included in a message, but does not tell you how that content should be encoded and transmitted using ‘zeroes’ and ‘ones’. In order to get the precise bit-level definition for a message ASN.1 needs support by encoding rules. These rules determine the actual bits (again platform- and language independent) to be transmitted for any message that can be defined using the notation. There are several encoding rules specified for use with ASN.1, such as Basic Encoding Rules (BER) and Packed Encoding Rules (PER), the latter being selected for E-UTRAN higher layer protocols. By strictly separating the abstract syntax from the transfer syntax it becomes possible (or at least easier) to make the protocol specifications less ambiguous and to reduce implementation dependencies in the specifications. In addition, with the help of off-the-shelf ASN.1 compilers



and the predefined encoding rules, the number of steps involved when implementing a specific protocol can be reduced. Packed Encoding Rules, PER, supposes that both the sender and the receiver of a message know what Information Elements to expect (and in what order) for each specific message. In order to reduce the number of transmitted bits, PER (usually) abandons the octet-alignment common in other protocol definitions, except on the message level (each full message is always a multiple of 8 bits). The presence or not of optional Information Elements is, when using PER, indicated with a single bit. An RRC message does not consist of a Header part and a Payload part, as is the case for many (most) other protocols. Everything in an RRC message is simply referred to as an Information Element or Information Element Group. All RRC messages contain a Message Type definition and most dedicated RRC messages also contain a Transaction Identifier. The Message Type identifies the message among all defined RRC messages, thus informing the receiver about what other IEs to expect in the message (and in what order). The Transaction Identifier is used for linking a 'request' message with its 'response' message (as in NAS ESM messages).


4.4 References 36.331 E-UTRA Radio Resource Control (RRC) protocol specification X.680 ASN.1: Specification of basic notation X.681 ASN.1: Information object specification X.691 ASN.1: Specification of Packed Encoding Rules (PER)

Apis Technical Training AB LSIG - PDCP and RLC Copyright © Apis Technical Training AB 2008. All rights reserved. 5-1

5 Uu-interface part II: PDCP & RLC Protocol

5.1 INTRODUCTION .................................................................................5-2

5.2 PDCP PROTOCOL............................................................................5-3

5.2.1 PDCP Procedures....................................................................5-3

5.2.2 PDCP PDU Format ..................................................................5-7

5.3 RLC PROTOCOL ..............................................................................5-8

5.3.1 RLC Modes ..............................................................................5-8

5.3.2 RLC Procedures.......................................................................5-9

5.3.3 RLC PDU Format ...................................................................5-10

5.4 REFERENCES .................................................................................5-12

5.1 Introduction

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

Figure 5-1: PDCP/RLC protocol stack (control plane)

The Packet Data Convergence protocol (PDCP) provides services in the form of Radio Bearers to the RRC layer in the Control Plane (figure 5-1) and to the application layer in the User Plane in the UE (not shown). The CP service is called a Signalling Radio Bearer (SRB) and the UP service is called a Data Radio Bearer (DRB). Each EPS bearer (default or dedicated) is associated with one Radio Bearer that, in turn, is associated with one PDCP entity. The main PDCP functions are data transfer, header compression and Access Stratum (AS) security. PDCP is a layer 2 protocol. The Radio Link Control (RLC) protocol offers link control over the radio interface for user data and control signalling (figure 5-1 shows the CP). The Service Access Point (SAP) between RLC and the Medium Access Control protocol (MAC) is referred to as a Logical Channel. Each RLC entity uses one single Logical Channel. The main RLC functions are data transfer, segmentation/concatenation and retransmission (ARQ). RLC is a layer 2 protocol.


5.2 PDCP Protocol PDCP Tx

CP: IntegrityProtection

Sequence Numbering

Ciphering

UP: HeaderCompression

Add PDCP Header

PDCP Rx

CP: IntegrityVerification

De-ciphering

UP: HeaderDe-compression

Remove PDCP Header

UP: Reordering

PDCP Tx


Sequence Numbering

Ciphering


Add PDCP Header

PDCP Rx


De-ciphering


Remove PDCP Header

UP: Reordering

PDCP Tx


Sequence Numbering

Ciphering


Add PDCP Header

PDCP Tx


Sequence Numbering

Ciphering


Add PDCP Header

PDCP Rx


De-ciphering


Remove PDCP Header

UP: Reordering

Figure 5-2: PDCP architecture

The PDCP protocol machine (in UE and eNB) may have one or more PDCP entity active simultaneously. One PDCP entity is always associated with one (Data or Signalling) Radio Bearer, and thus with one RLC entity and one Logical Channel. The active PDCP entities are logically independent of each other and may perform different functions (e.g. apply different header compression and use different RLC modes). As seen in figure 5-2, the PDCP functions for the CP include sequence numbering, integrity protection and ciphering. The PDCP functions for the UP include sequence numbering, header compression and ciphering. PDCP PDUs that are not associated with higher layer Service Data Units (SDUs) are not encrypted. Such PDUs contain only control parameters relating to the compression function itself.

5.2.1 PDCP Procedures

Sequence Numbering All PDCP PDUs are associated with a PDCP sequence number. PDCP Sequence control is only applied for RBs that are configured for RLC Acknowledged Mode (AM) operation. The purpose is to detect missing/ duplicated PDCP PDUs after a handover and to, if necessary, initiate retransmission of missing PDUs.

Header Compression The PDPC protocol is responsible for header compression. The method used is the Robust Header Compression mechanism (ROHC) as defined in RFC 3095 and other RFCs. Header compression is applied in order to reduce the protocol overhead (e.g. TCP/IP or RTP/UDP/IP headers) in the transmitted user data.


There is a considerable gain in doing this since most Internet Engineering Taskforce (IETF) protocol headers (figure 5-3) contain many static fields. Header compression is especially important for services with small IP payload sizes, such as VoIP. As an example, in a streaming application the RTP/UDP/IP header is 40 bytes long (60 bytes for IPv6). ROHC compresses these 40 (or 60) bytes into only 1 or 3 bytes. Thus, the compressor on the transmitting side converts the large overhead to only a few bytes, while the decompressor on the receiving side does the opposite.

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

Total length

Chunk Flags

Version, IHL

Payload (TCP, UDP etc)

IP Header

Type of service

Identification Flags, Fragment Offset

Time To Live Protocol ID Header Checksum

Source IP-address

Destination IP-address

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

Payload (GTP, RTP etc)

UDP Header

Destination PortSource Port

ChecksumLentgth

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

TCP Header


Payload (HTTP, FTP etc)

WindowOffset, Flags

Urgent PointerChecksum

Sequence Number

Acknowledgement Number

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

Total length

Chunk Flags

Version, IHL


IP Header

Type of service



Source IP-address


0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

Total length

Chunk Flags

Version, IHL


IP Header

Type of service



Source IP-address


0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210


UDP Header


ChecksumLentgth

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210


UDP Header

Destination PortSource Port Destination PortSource Port

ChecksumLentgth ChecksumLentgth

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

TCP Header



WindowOffset, Flags


Sequence Number


0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

TCP Header

Destination PortSource Port Destination PortSource Port


WindowOffset, Flags



WindowOffset, Flags WindowOffset, Flags

Urgent PointerChecksum Urgent PointerChecksum

Sequence Number


Sequence Number


Figure 5-3: IETF header formats

Control information needed for the compression/decompression function is exchanged between UE and eNB as in-band signalling, using the PDCP payload field to convey the ROHC control parameters. (This is the 'PDCP PDUs not associated with higher layer SDUs' mentioned earlier.)


The specific ROHC profile to use for a given EPS bearer is configured with RRC signalling. The ROHC profiles currently valid for the EPS system are listed below.

RFC 5225IP0x0104

RFC 5225ESP/IP0x0103

RFC 5225UDP/IP0x0102

RFC 5225RTP/UDP/IP0x0101

RFC 4996TCP/IP0x0006

RFC 3843, RFC 4815IP0x0004

RFC 3095, RFC 4815ESP/IP0x0003

RFC 3095, RFC 4815UDP/IP0x0002

RFC 3095, RFC 4815RTP/UDP/IP0x0001

RFC 4995No compression0x0000

ReferenceUsageProfileIdentifier

RFC 5225IP0x0104

RFC 5225ESP/IP0x0103

RFC 5225UDP/IP0x0102

RFC 5225RTP/UDP/IP0x0101

RFC 4996TCP/IP0x0006

RFC 3843, RFC 4815IP0x0004

RFC 3095, RFC 4815ESP/IP0x0003

RFC 3095, RFC 4815UDP/IP0x0002

RFC 3095, RFC 4815RTP/UDP/IP0x0001

RFC 4995No compression0x0000

ReferenceUsageProfileIdentifier

Figure 5-4: ROHC profiles

A ROHC compressor is in one of three main states. In Initialization and Refresh (IR) state, the compressor has just been created or reset, and full packet headers are sent. In First-Order (FO) state, the compressor has detected and stored the static fields (such as IP addresses and port numbers) on both sides of the connection. The compressor is also sending dynamic packet field differences in FO state. Thus, FO state is essentially static and pseudo-dynamic compression. In Second-Order (SO) state, the compressor is suppressing all dynamic fields such as RTP sequence numbers, and sending only a logical sequence number and partial checksum to cause the other side to predictively generate and verify the headers of the next expected packet. In general, FO state compresses all static fields and most dynamic fields. SO state is compressing all dynamic fields predictively using a sequence number and checksum.

Integrity Protection and Ciphering Integrity protection is only applied in the CP. The complete un-ciphered PDCP PDU is integrity protected. The integrity algorithm and key to be used is configured through RRC/NAS signalling. The Integrity Key (IK) is derived from KeNB that, in turn, is derived from K

B

ASME calculated as a part of the NAS AKA procedure. The RRC Security Mode Control procedure provides the UE with additional parameters needed for proper operation of the integrity function (such as an indication of the integrity algorithm to use).



Note: as the RRC message that activates the integrity protection function is itself integrity protected with the configuration included in this RRC message, this message needs first be decoded by RRC before the integrity protection verification could be performed. The parameters required by PDCP for integrity protection are listed below:

• BEARER. This is the identity number of the radio bearer.

• DIRECTION. Direction of transmission (UL=0, DL=1).

• IK. The integrity key.

• COUNT. This is the PDCP sequence number and an overflow counter called the Hyperframe Number (HFN).

• MESSAGE. This is the complete message to be protected.

These parameters are fed into the commanded version of the EPS Integrity Algorithm (EIA). Currently defined EIA versions are 'SNOW 3G' and Advanced Encryption Standard (AES). The output is the Message Authentication Code for Integrity (MAC-I). The MAC-I field is appended to the PDCP PDU and transmitted to the receiver. The receiver verifies the integrity of the PDCP PDU by calculating the expected MAC (X-MAC) based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, the integrity of the PDCP PDU is verified. Ciphering is applied in both CP and UP. The data part of the PDCP PDU and the MAC-I is encrypted. Ciphering is not applicable to PDCP Control PDUs. The ciphering algorithm and key to be used is configured through RRC/NAS signalling. Different keys are used for the CP and the UP. The Ciphering Keys (CK) are derived from KeNB that, in turn, is derived from KASME calculated as a part of the NAS AKA procedure. The RRC Security Mode Control procedure provides the UE with additional parameters needed for proper operation of the ciphering function (such as an indication of the encryption algorithm to use). The parameters required by PDCP for ciphering are listed below:

• BEARER. This is the identity number of the radio bearer.

• DIRECTION. Direction of transmission (UL=0, DL=1).

• CK. The ciphering key.

• COUNT. This is the PDCP sequence number and HFN.

These parameters are fed into the commanded version of the EPS Encryption Algorithm (EEA). Currently defined EEA versions are the same as for integrity protection, i.e. SNOW 3G and AES. SNOW 3G results in a stream cipher and AES results in a block cipher. (The details on how the output from the algorithm is used for encrypting the payload are thus different.)

PDCP Behaviour at Handover The behaviour of PDCP at handover is different for SRBs, DRBs in RLC AM and DRBs in RLC UM. For SRBs, the UE will, after a successful handover, reset the PDCP sequence number and discard all stored PDCP PDUs. I.e. there is no recovery mechanism defined. For UM DRBs, the UE will maintain the PDCP sequence number in the receive direction and reset the sequence number in the transmit direction. The header compression function is reset. For AM DRBs, the UE will maintain the PDCP sequence numbers, in both receive and transmit direction, start a timer called the 'Flush timer' and reset the header compression function. While the Flush timer is running, the PDCP protocol will perform re-ordering of received PDCP PDUs. The reason for this is that, on the network side, there will be temporary forwarding of data PDUs from the old eNB to the new eNB, at the same time as the SGW continues to transmit new data PDUs to the new eNB. This may result in PDCP PDUs arriving in the UE in the wrong order, or PDUs being duplicated. Furthermore, the first uplink PDCP PDU sent by the UE in the new cell will be a PDCP Status report indicating the downlink PDUs that have been successfully received and the PDUs that needs to be retransmitted. In the same manner, the eNB will provide the UE with a report on uplink PDCP PDUs. As a result, the missing (or unacknowledged) PDCP PDUs will be retransmitted in the uplink and the downlink.

5.2.2 PDCP PDU Format

Bitmap (variable)

12345678

PDCP Control PDU: SN Status

D/C First Missing SN (FMS)PDU Type

First Missing SN (FMS)

Reserved Sequence Number


Code (4 oct)

PDCP Data PDU: SRB

DATA(RRC message)

12345678

D/C

Sequence Number

Sequence Number

PDCP Data PDU: DRB long SN

Reserved

DATA(Un/compressed IP)

12345678

Bitmap (variable)

12345678




Bitmap (variable)

12345678 12345678






Code (4 oct)

PDCP Data PDU: SRB

DATA(RRC message)

12345678



Code (4 oct)

PDCP Data PDU: SRB

DATA(RRC message)

12345678 12345678

D/C

Sequence Number

Sequence Number


Reserved


12345678

D/C

Sequence Number

Sequence Number


Reserved


12345678 12345678

Figure 5-5: PDCP PDU format


A PDCP PDU is either a Data PDU, carrying higher layer information, or a Control PDU, carrying PDCP signalling. A PDCP Data PDU carrying a CP payload (i.e. SRB) consists of a Sequence Number (SN, 5 bits), the DATA, or payload, field and the MAC-I. A PDCP Data PDU carrying a UP payload (i.e. DRB) consists of a SN (7 or 12 bits depending on RLC mode), the DATA field and a Data/Control indicator (1 bit). The D/C bit set to '0' indicates a Control PDU. There are currently only two different types of Control PDUs defined: Status Report and Header Compression Feedback Information (given by the PDU Type field). The Status Report contains the First Missing SN (FMS) and an optional bitmap indicating whether the PDCP PDU with sequence number 'FMS + bit-position' needs to be retransmitted or not. The Header Compression Feedback Information PDU contains the ROHC control information mentioned earlier.

5.3 RLC Protocol RLC UM Tx

SegmentationConcatenation

TransmissionBuffer

Add RLCHeader

RLC UM Rx

Remove RLCHeader

SDUReassembly

Receive BufferReordering

RLC AM


TransmissionBuffer

Add RLCHeader


Remove RLCHeader

SDUReassembly


Routing(D/C bit)

RetransmissionBuffer

RLCControl

RLC UM Tx


TransmissionBuffer

Add RLCHeader

RLC UM Rx

Remove RLCHeader

SDUReassembly


RLC UM Tx


TransmissionBuffer

Add RLCHeader

RLC UM Rx

Remove RLCHeader

SDUReassembly


RLC AM


TransmissionBuffer

Add RLCHeader


Remove RLCHeader

SDUReassembly


Routing(D/C bit)


RLCControl

RLC AM


TransmissionBuffer

Add RLCHeader


Remove RLCHeader

SDUReassembly


Routing(D/C bit)


RLCControl

Figure 5-6: RLC architecture

The UE may use multiple RLC entities simultaneously, with each entity configured to operate in one of three modes: Acknowledged Mode (AM), Unacknowledged Mode (UM) and Transparent Mode (TM).

5.3.1 RLC Modes

Acknowledged Mode (AM) With AM operation 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. RLC-AM can be used for the DTCH and DCCH logical channels.

Apis Technical Training AB

LSIG - PDCP and RLC Copyright © Apis Technical Training AB 2008. All rights reserved. 5-8


Unacknowledged Mode (UM) As the term suggests, there are no acknowledgements or retransmissions with UM operation. 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. RLC-UM can be used for the DTCH, DCCH, MTCH and MCCH logical channels.

Transparent Mode (TM) The TM mode, finally, is used for minimum protocol overhead (the TM mode PDU has no header). The only 'function' provided by the RLC-TM entity is message buffer in the transmit direction. RLC-TM operation is only used for the BCCH, CCCH and PCCH logical channels.

5.3.2 RLC Procedures

Data Transfer For both RLC-AM and RLC-UM operation, the transmitter will apply segmentation and/or concatenation of higher layer PDUs as required. The aim of this function is to make as efficient use of the currently available 'space' within the lower layer MAC PDU as possible. The transmitter then adds the RLC header (see section 5.3.3). For both RLC-AM and RLC-UM operation, the receiver will apply reordering of received higher layer PDUs (or PDU segments), remove the RLC header and, if necessary, perform reassembly of higher layer SDUs. For data transfer, the 'only' difference between UM and AM operation is that retransmission (ARQ) and re-segmentation applies to RLC-AM operation but never to RLC-UM operation.

ARQ and Re-segmentation The concept of retransmission is very simple. Whenever one end (e.g. eNB) sends something to the other end (e.g. UE) it retains a copy of the data it sent until the recipient has acknowledged that it received it without errors. Any method of using ACK/NACKs and retransmissions is commonly referred to as Automatic Repeat reQuest (ARQ). The RLC protocol uses the Status PDU to carry ACK/NACKs from the receiver to the transmitter. The Status PDUs may be sent periodically or when the transmitting RLC entity explicitly requests status information. The procedure with which the transmitting RLC entity requests a Status report is called Polling and is indicated to the receiver by setting the Poll-bit in the RLC header.

Polling may be triggered periodically, when the transmit buffer is empty (last-PDU polling), when a certain number of RLC PDUs have been sent or when a certain volume of data has been sent. Re-segmentation is applied when the transmitter has received NACK for one or more PDU and the available lower layer resources (MAC payload size) no longer fit the size of the RLC PDU(s) to be retransmitted.

5.3.3 RLC PDU Format UMD PDU: long SN

DATA(one or more SDU/segment)

12345678Reserved FI

SNE =1 SN

LI 1E =1LI 1 E LI 2

LI 2…

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

AMD PDU


12345678FISN

E =1 SN

LI 1E =1LI 1 E LI 2

LI 2…

D/C=1 RF=0 P Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

AMD PDU Segment 12345678

FISN

E =1 SN


LI 1E =1LI 1 E LI 2

LI 2…

D/C=1 RF =1 P

SOLSFSO

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

STATUS PDU12345678

CPT =000ACK_SN

ACK_SN

NACK_SN 1

…NACK_SN 2

SOstart 1

D/C=0E1 =1 NACK

SN 1

E1 =1NACKSN 1 E2 =1

E1 E2

SOstart 1SOstart 1 SOend 1

SOend 1SO

end 1

NACK_SN 2

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 8

UMD PDU: long SN


12345678Reserved FI

SNE =1 SN

LI 1E =1LI 1 E LI 2

LI 2…

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

UMD PDU: long SN


12345678 12345678Reserved FI

SNE =1 SN

LI 1E =1LI 1 E LI 2

LI 2…

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

AMD PDU


12345678FISN

E =1 SN

LI 1E =1LI 1 E LI 2

LI 2…

D/C=1 RF=0 P Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

AMD PDU


12345678 12345678FISN

E =1 SN

LI 1E =1LI 1 E LI 2

LI 2…

D/C=1 RF=0 P Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

AMD PDU Segment 12345678

FISN

E =1 SN


LI 1E =1LI 1 E LI 2

LI 2…

D/C=1 RF =1 P

SOLSFSO

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

AMD PDU Segment 12345678 12345678

FISN

E =1 SN


LI 1E =1LI 1 E LI 2

LI 2…


LI 1E =1 LI 1E =1LI 1 E LI 2

LI 2…

D/C=1 RF =1 P

SOLSF SOLSFSO

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

STATUS PDU12345678

CPT =000ACK_SN

ACK_SN

NACK_SN 1

…NACK_SN 2

SOstart 1

D/C=0E1 =1 NACK

SN 1

E1 =1NACKSN 1 E2 =1

E1 E2


SOend 1SO

end 1

NACK_SN 2

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 8

STATUS PDU12345678 12345678

CPT =000ACK_SN

ACK_SN

NACK_SN 1

…NACK_SN 2

SOstart 1

D/C=0E1 =1 NACK

SN 1

E1 =1NACKSN 1 E2 =1

E1 E2


SOend 1SO

end 1

NACK_SN 2

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 8

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 8

Figure 5-7: RLC PDU format

An RLC PDU is either a data PDU or a Control PDU. The RLC Data PDUs have different format depending on the mode of operation used (AM, UM or TM). The Data PDUs consist of a header and one or more RLC Service Data Unit (SDU) or segment thereof. The exception is the TM Data PDU (TMD), which only contains an RLC SDU and no header. The UM Data PDU (UMD) header contains a long (10 bit) or short (5 bit) Sequence Number (SN), the Framing Info (FI) field, Extension bit (E) and zero, one or more Length Indicator (LI). The E-bit in the first octet indicates the presence, or not, of the first LI-field. The E-bit preceding a given LI-field then indicates whether this is the last LI or not. Thus, all LIs present in the PDU are 'stacked' one after the other between the mandatory header and the Data field. The LIs indicate the boundaries (octet number) between SDUs or SDU segments in the Data field. The FI-field indicates whether the first and/or last SDU in the Data part is segmented or not (i.e. if it 'spills over' to/from the next/previous RLC PDU).



The AM Data PDU (AMD) header contains, in addition to the FI/E/SN/LI-fields discussed above, the Data/Control-bit (D/C), the Poll-bit (P) and the Re-segmentation Flag field (RF). The RF-field specifies whether the first part of the Data field is a complete SDU or a re-segmented SDU. Two more fields are needed when a re-segmented SDU is present: the Last Segment Flag (LSF) and the Segment Offset (SO). The LSF-field indicates whether or not the last byte of the SDU segment corresponds to the last byte of the complete SDU. The SO-field indicates the position of the SDU segment in bytes within the original AMD PDU. There is currently only one type of RLC Control PDU defined: the Status PDU. Thus, the Control PDU Type field (CPT) currently has only one value defined (CPT=000). The purpose of the Status PDU is to convey ACK/NACKs for received RLC PDUs and/or PDU segments. The ACK_SN field specifies the next expected AMD PDU SN. In other words, all PDUs up to but not including SN=ACK_SN have been properly received by the peer RLC entity, excluding those AMD PDUs indicated in the STATUS PDU with NACK_SN. The Extension bit (E1) is used for stacking multiple NACK_SNs after each other, in very much the same way as the LI-fields in the Data PDUs. The SOstart and SOend fields specify that a portion (segment) of the AMD PDU with SN=NACK_SN needs to be retransmitted. The extension bit (E2) indicates whether a given NACK_SN is associated with a SOstart/end pair or not.


5.4 References RFC3095 Robust Header Compression (ROHC) framework and four

profiles: RTP, UDP, ESP and uncompressed RFC3843 ROHC: a compression profile for IP RFC4815 ROHC: corrections and clarifications to RFC3095 RFC4995 ROHC framework RFC4996 ROHC; a profile for TCP/IP RFC5225 ROHC Version 2: profiles for RTP, UDP, ESP and UDP Lite 36.322 E-UTRA; Radio Link Control (RLC) protocol specification 36.323 E-UTRA; Packet Data Convergence Protocol (PDCP)

protocol specification

Apis Technical Training AB LSIG - MAC Copyright © Apis Technical Training AB 2008. All rights reserved. 6-1

6 Uu-interface part III: Medium Access Control (MAC)

6.1 INTRODUCTION .................................................................................6-2

6.2 MAC CONTROL PROCEDURES ..........................................................6-3

6.2.1 Random Access .......................................................................6-3

6.2.2 Uplink Time Alignment .............................................................6-4

6.2.3 Uplink Scheduling Requests ....................................................6-4

6.2.4 Buffer Status Reporting............................................................6-5

6.2.5 Power Headroom Reporting ....................................................6-5

6.2.6 DRX Operation.........................................................................6-5

6.3 SCHEDULING OF DATA ......................................................................6-6

6.3.1 DL-SCH Scheduling .................................................................6-7

6.3.2 UL-SCH Scheduling .................................................................6-9

6.3.3 Scheduling Algorithms ...........................................................6-10

6.4 HYBRID-ARQ OPERATION ..............................................................6-14

6.4.1 E-UTRA HARQ Mechanisms .................................................6-14

6.5 MAC PDU FORMATS .....................................................................6-17

6.6 REFERENCES .................................................................................6-19

6.1 Introduction

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

Figure 6-1: MAC protocol stack

The MAC protocol performs multiplexing of one or several upper layer Protocol Data Units (PDUs) onto one Transport Block (TB) that is then delivered to the physical layer for further processing and transmission. Another way of saying this is that MAC performs multiplexing of PDUs from one or more logical channel onto one transport channel. The logical channel is either a Dedicated Control Channel (DCCH) or a Dedicated Traffic Channel (DTCH). The transport channel is, for DL transmission, called the Downlink Shared Channel (DL-SCH) and, for UL transmission, the Uplink Shared Channel (UL-SCH). The eNB MAC protocol is also responsible for DL-SCH and UL-SCH resource allocation through dynamic scheduling. The scheduler within the MAC protocol manages DL/UL-SCH resources between UEs or groups of UEs. The scheduler determines which UE (or group of UEs) to be serviced on a per-TTI basis. The scheduler takes QoS and channel conditions into account for each UE. The scheduling function is described in section 6.3. MAC also handles error correction through Hybrid Automatic Repeat reQuest (HARQ) operation. HARQ retransmissions take current channel conditions into account, i.e. adaptive retransmission are applied. The HARQ function is described in section 6.4. Finally, the MAC protocol is responsible for some lower layer control signalling, such as the Random Access procedure and the Timing Advance update procedure. This lower layer signalling is, in the specs, referred to as either 'MAC control' or L1/L2 control'. The MAC control procedures are described in section 6.2. This last section in this chapter (section 6.5) describes the MAC PDU formats used for data transmission and MAC control signalling.



6.2 MAC Control Procedures The MAC protocol is responsible for controlling many of the fundamental procedures that make E-UTRA what it is. The most important procedures are listed below:

• Random Access

• Scheduling of DL and UL data transmission (section 6.3)

• UL and DL HARQ operation (section 6.4)

• Uplink time alignment

• Handling of uplink scheduling requests

• Buffer status reporting

• Power headroom reporting

• Downlink discontinuous reception (DRX)

Note: Parts of the text in the following sections are taken from, or is based on, MAC specification: TS 36.321. It should be stressed that the MAC specification, and hence the descriptions here, does not specify exactly the functionality of a ‘real-life’ eNB or UE. To quote the MAC spec itself: “The objective is to describe the MAC architecture and the MAC entity from a functional point of view. The description in this sub-clause is a model and does not specify or restrict implementations.”

6.2.1 Random Access The Random Access (RA) procedure is used for several purposes: initial access in a cell, access in target cell after handover, access in order to send a Scheduling Request and access when the Timing Advance timer in the UE has expired. The initial access RA procedure includes allocation of a new Cell Radio Network Temporary Identity (C-RNTI) and is always followed by a contention resolution procedure, to make sure that only one UE in the cell uses this C-RNTI. The UE initiates the procedure by selecting a RA Preamble and a Physical Random Access Channel (PRACH) resource to use for the procedure. The Preamble and PRACH resource selection function uses parameters in system information as well as fixed rules in the specifications. The PRACH is mapped to the RACH transport channel. The eNB maps the Preamble to a Random Access RNTI (RA-RNTI). The eNB responds with a RA Response (RAR) message to the UE that includes the Preamble id, the C-RNTI, Timing Advance and an uplink Grant for the first uplink layer 3 (RRC) message. The UE verifies the Preamble id and prepares the first layer 3 message for transmission according to the uplink Grant. The RAR message is sent on the DL-SCH and is addressed to the RA-RNTI on the Physical Downlink Control Channel (PDCCH).


At this point the RA procedure as such is completed and the contention resolution procedure is executed. The first uplink layer 3 message (RRC Connection Request) contains the S-TMSI of the UE. The S-TMSI is sent back to the UE in the first downlink layer 3 message (RRC Connection Setup). This downlink message is addressed to the C-RNTI on PDCCH. The UE verifies the S-TMSI, transmits a HARQ ACK/NACK in the uplink and the contention resolution procedure ends. The C-RNTI is from then on regarded as unique in this cell. If the UE does not find its own S-TMSI in any downlink layer 3 message it goes back to 'square one' again and initiates a new Preamble transmission. The C-RNTI allocation and contention resolution can be skipped when the RA procedure is used for any other purpose than initial access (i.e. the UE already has a unique C-RNTI allocated).

6.2.2 Uplink Time Alignment The purpose of the Uplink Time Alignment procedure is to instruct the UE to adjust its uplink transmissions so that the uplink signal does not arrive out-of-sync at the eNB (not too early, not too late). This applies to both the Physical Uplink Shared Channel (PUSCH) and the Physical Uplink Control Channel (PUCCH). In order words, the changes in radio wave propagation delay must be taken into account as the distance between the UE and the eNB changes. The control parameter used for this purpose is the Timing Advance (TA). The Uplink Time Alignment procedure is executed on demand, initiated by the eNB or initiated by the UE. When the eNB detects that the TA needs to be adjusted it simply issues a Timing Advance MAC control element to the UE in the next downlink MAC PDU. The UE initiated procedure relies on a timer, the Time Alignment Timer (TAT). The TAT is started/restarted whenever the UE receives a new TA. When the timer expires, the UE shall release all PUCCH resources and initiate the RA procedure in order to get a new TA value. The timer is configurable per UE and is only valid in one cell.

6.2.3 Uplink Scheduling Requests The purpose of the uplink Scheduling Request (SR) procedure is to request UL-SCH resources (i.e. PUSCH resources). Two scenarios are possible: either the UE has a valid PUCCH assignment or it does not. If the UE has a valid PUCCH resource it simply transmits a SR on the PUCCH until uplink resources are granted by the eNB. If no PUCCH resource is configured the UE will execute the RA procedure until a RA Response with a valid grant is received. The UE then uses this grant to transmit the SR.


6.2.4 Buffer Status Reporting The Buffer Status Reporting (BSR) procedure is used to provide the eNB with information about the amount of data in the UL buffers of the UE. There are three types of BSR: periodic, regular or padding. The periodic BSR is transmitted when a UE specific BSR timer expires. The regular BSR is triggered at serving cell change (i.e. handover) or when UL data arrives in the UE transmission buffer and the data has higher priority than data already existing in the buffer. The padding BSR is triggered when UL resources are allocated and the number of MAC PDU padding bits (see section 6.5) is larger than the size of the BSR MAC control element. The BSR specifies, per logical channel group, how many bytes that are still awaiting uplink transmission. This number includes all data in the RLC and PDCP layers. RLC and MAC header sizes are not considered in the buffer size computation.

6.2.5 Power Headroom Reporting The Power Headroom Reporting (PHR) procedure is used to provide the eNB with information about the difference between the UE's current transmit power and the maximum possible transmit power (according to the UE's power class). The difference is reported as a positive value in the PHR MAC control element. The procedure is also used to indicate to the eNB by how much the commanded transmit power exceeds the UE's maximum possible transmit power. This is indicated with a negative value in the PHR MAC control element. The PHR is sent periodically and is also triggered when the calculated pathloss has changed more than 'DL_PathlossChange' dB since last report.

6.2.6 DRX Operation The eNB may configure the UE (RRC signalling) with a Discontinuous Reception (DRX) cycle that allows it to monitor the PDCCH in a semi-periodic manner (as opposed to every 1ms TTI). The DRX operation is governed by a Long DRX cycle, a DRX Inactivity Timer, a DRX Retransmission Timer and, optionally, a Short DRX cycle and a DRX Short Cycle Timer. When DRX is configured, the UE 'wakes up' at the beginning of the DRX cycle and monitors the PDCCH for a configured number of TTIs. This period is called the On-Duration. If no assignment is detected on the PDCCH, the UE goes back to 'sleep' until the next On-Duration. Thus the (Long or Short) DRX cycle length sets the periodicity of the On-Duration.

If, during the On-Duration, an uplink or downlink assignment is detected on the PDCCH the UE stays awake and starts the DRX Inactivity Timer. Any subsequent PDCCH assignment for an initial transmission (i.e. not for a retransmission) will reset the timer. The UE re-enters DRX when the Inactivity Timer expires. Uplink HARQ operation is independent of DRX operation, meaning that the UE always wakes up to read downlink ACK/NACKs on the PHICH for each of its UL transmissions on the PUSCH. Downlink HARQ operation is also independent of DRX operation, with the exception of the DRX Retransmission Timer. This timer sets how many TTIs the UE stays awake monitoring the PDCCH when a retransmission is expected (i.e. the UE has sent an uplink NACK).

6.3 Scheduling of Data

PHY

MAC

Logical ChannelMultiplexing

Logical ChannelDe-multiplexing

MAC Control

Packet Scheduler(DL/UL)

UL-SCH

PUSCH

HARQ Entity HARQ Entity

Proc1

PDU

Proc8

PDU

……Proc

1

PDU

Proc8

PDU

……

PUCCH

DCCH DTCH

RLC

CQI SR A/NA/N

BSRPHR

DCCH DTCH

DL-SCH

PDSCH PDCCH PHICH

PHY

MAC



MAC Control


UL-SCH

PUSCH


Proc1

PDU

Proc8

PDU

……Proc

1

PDU

Proc8

PDU

……

PUCCH

DCCH DTCH

RLC

CQI SR A/NA/N

BSRPHR

DCCH DTCH

DL-SCH

PDSCH PDCCH PHICH

PHY

MAC



MAC Control


UL-SCH

PUSCH


Proc1

PDU

Proc8

PDU

……Proc

1

PDU

Proc1

PDU

Proc8

PDU

Proc8

PDU

……Proc

1

PDU

Proc8

PDU

……Proc

1

PDU

Proc1

PDU

Proc8

PDU

Proc8

PDU

……

PUCCH

DCCH DTCH

RLC

CQI SR A/NA/N

BSRPHR

DCCH DTCH

DL-SCH

PDSCH PDCCH PHICH

Figure 6-2: MAC architecture

Figure 6-2 shows the overall MAC architecture as seen in the eNB. The central 'box' corresponds to the MAC Control entity and the UL/DL packet schedulers. The left hand side corresponds to downlink data transmission (to UE) and the right hand side to uplink data transmission (from UE). Shown in the figure are also the HARQ entities for DL and UL. The MAC protocol receives data from, and delivers data to, higher layers over logical channels. Note that the word 'data' within the MAC layer means both user plane data (DTCH) and control plane signalling (DCCH).



6.3.1 DL-SCH Scheduling The DL-SCH carries data for E-UTRA users with a fixed Transmission Time Interval (TTI) of 1ms. One or two Transport Blocks (TB) per UE are delivered to the physical layer per 1ms TTI on the DL-SCH (two TBs is only applicable for MIMO operation). One DL-SCH TB is the same as one MAC Protocol Data Unit (PDU). The size of DL-SCH TBs transmitted to the same UE may vary from TTI to TTI. The allowed sizes of DL-SCH transport blocks (MAC PDUs) are defined in tables in the specifications. (One such table can be found at the end of chapter 7.) The MAC PDUs delivered from MAC to the physical layer will be channel coded and modulated before transmission using a selected set of OFDM-generated Physical Resource Blocks (see chapter 7). The channel coding process always uses a Turbo coder with Rate=1/3 (‘one bit in produces three bits out’) for error correction. The output from the Turbo coder is three different sets of bits called Systematic bits, Parity1 bits and Parity2 bits. The Systematic bits are identical to the Turbo coder input data bits, while the Parity bits carry information about the data bits. The physical layer also performs rate matching (puncturing) if necessary/ desired. The purpose of rate matching is to adapt the number of coded information bits to transmit to the currently available physical channel resources. ‘Puncturing’ means removing some of the coded information bits in order to achieve this. The puncturing process will thus lead to a higher effective code rate (and thus also throughput) over the radio interface, at the cost of less reliability. The puncturing is done according to the selected Redundancy Version (RV). The RV is selected by the packet scheduler and tells the physical layer what bits to remove from each of the three output sets from the Turbo coder (Systematic, Parity1, and Parity2). Thus, by changing the RV for a transmission, different levels of reliability can be achieved. This is referred to as Adaptive Coding. Rate matching is discussed in chapter 7. The E-UTRA specs also allow the eNB to change dynamically between the QPSK, 16QAM and 64QAM modulation schemes. Hence, the packet scheduler makes use of Adaptive Coding and Modulation (AMC) in order to adapt to the current channel conditions. In addition, a TB processed with a given Modulation and Coding Scheme (MCS) may be transmitted using a smaller or larger bandwidth by assigning different numbers of Physical Resource Blocks (PRBs) for the transmission. Yet another degree of freedom is available since the eNB may choose to use single-antenna transmission or multi-antenna transmission (Tx diversity or MIMO). All in all, the eNB packet scheduler needs to select the TB size, MCS, RV, number of PRBs and antenna mapping for each DL-SCH transmission in such a way that the available radio resources are used efficiently and that the UE does not experience too many bit errors.

eshushi

高亮

eshushi

高亮


In order to make good decisions the eNB obviously needs to have the proper input parameters available. The eNB needs information about, at least, the following:

• Availability of radio resources

• UE capabilities (per UE)

• Radio bearer QoS requirements (per UE)

• The current downlink channel conditions (per UE)

• How long time since UE X was last served

• UEs that have retransmissions pending.

The availability of radio resources for data transmission is indicated to MAC from the physical layer on a per-TTI basis. The amount of DL radio resources available at a given instant can be influenced by, for example, inter-cell interference and downlink power management procedures. The currently available number of PDCCHs is also a factor. UE capabilities are received from the MME as part of the S1AP Initial Context Setup procedure and specify, among other things, the maximum TB size the UE supports and if the UE supports MIMO operation or not. QoS parameters are received from the MME as part of the S1AP default/dedicated bearer establishment procedure. These QoS parameters are standardised (GBR, QCI etc) and need to be 'translated' into parameters that the packet scheduler can use/understand- such as scheduling weights, priority levels, HARQ parameters etc. This kind of 'translation' is not standardised and is fully a question of implementation. The downlink channel conditions per UE are provided to the packet scheduler by means of Channel Quality Indicator reports (CQI). Each UE is configured (through RRC signalling) to periodically send such CQI reports to the eNB. The physical layer passes the received CQI index values to the MAC layer, as indicated in figure 6-2. The standardised CQI index values can be seen in figure 6-3. The UE performs measurements (based on downlink Reference Signals) and reports the corresponding CQI index. Each CQI index corresponds to a combination of modulation scheme and effective code rate (i.e. the code rate after rate matching) that the UE expects it can receive with a transport block error probability not exceeding 0.1. In case of MIMO operation, the CQI reporting is extended to also include a Precoding Matrix Indicator (PMI). The eNB uses the PMI for selection of the Space Time Coding (STC) precoding matrix to apply for the next MIMO transmission to the UE. See chapter 7 for more information on MIMO and STC.

eshushi

高亮

The UE can be ordered to report a system bandwidth-wide CQI and/or to report the CQI for a subset of the downlink system bandwidth. The CQI is reported periodically (with a UE specific period) but can also be explicitly requested by the eNB through the PDCCH.

5.55475.11524.52343.90233.32232.73052.40631.91411.47661.17580.87700.60160.37700.23440.1523

SpectralEfficiency

94887377266656746661649037860244930819312078

Coding Ratex 1024

64QAM64QAM64QAM64QAM64QAM64QAM16QAM16QAM16QAMQPSKQPSKQPSKQPSKQPSKQPSK

Out of Range

Modulation

11109876543210

CQI Index

15141312

5.55475.11524.52343.90233.32232.73052.40631.91411.47661.17580.87700.60160.37700.23440.1523

SpectralEfficiency

94887377266656746661649037860244930819312078

Coding Ratex 1024

64QAM64QAM64QAM64QAM64QAM64QAM16QAM16QAM16QAMQPSKQPSKQPSKQPSKQPSKQPSK

Out of Range

Modulation

11109876543210

CQI Index

15141312

Figure 6-3: CQI index table

The time passed (or, equivalently, the number of TTIs) since a given UE was last scheduled is, of course, an internal variable known to the packet scheduler. Pending retransmissions are also known to the eNB, through uplink ACK/NACKs. How the eNB packet scheduler prioritizes between initial transmissions and retransmissions is an implementation issue.

6.3.2 UL-SCH Scheduling The UL-SCH carries data from E-UTRA users with a fixed TTI of 1ms. One, and only one, Transport Block can be transmitted per TTI by the UE (there is no MIMO operation for the uplink). The UE is never allowed to transmit in the uplink unless an explicit uplink Grant has been issued for the PUSCH. The uplink control channel, PUCCH, is semi-statically configured for each UE and does not need an explicit Grant. Scheduling of uplink data on the UL-SCH is in many respects similar to scheduling of downlink data on the DL-SCH, as described above. For example, the eNB packet scheduler must take into account UE capabilities, QoS requirements and (uplink) channel conditions. There is one fundamental difference though. For the downlink, the packet scheduler and the data buffers are all located in the same place: the eNB. For the uplink, the data buffers are distributed (one in each UE) and the MAC protocol in the eNB has to perform ‘remote’ packet scheduling.


eshushi

高亮

eshushi

高亮

eshushi

高亮


For this reason the packet scheduler in the eNB needs additional input. First of all, it needs to know which UE, or UEs, that actually has any data to transmit in a given TTI. This is handled through the uplink Scheduling Requests (SR) procedure discussed in section 6.2.3. It is desirable that the eNB has knowledge of the amount of data that is awaiting transmission in each UE. This is handled through the Buffer Status Reporting (BSR) procedure (section 6.2.4). Further, the eNB packet scheduler needs to know if the UE has enough power available for a (possibly) larger Grant. This is handled through the Power Headroom Reporting (PHR) procedure (section 6.2.5). The use of SR, BSR and PHR is indicated in figure 6-2. Finally, the eNB must make sure that each UE is allocated a chunk of OFDM subcarriers that results in overall favourable uplink radio conditions. This is achieved by ordering the UE, or group of UEs, to transmit a Sounding Reference Signal (SRS). The eNB uses the SRS to estimate what subcarriers that are best suited for the UEs uplink transmissions. Thus, the SRS may result in UL resources being 'moved around' between UEs.

6.3.3 Scheduling Algorithms The goal of the packet scheduler in the eNB can be specified as to maximize the system throughput while at the same time satisfying the agreed QoS level for each user. These two aspects are often at odds with each other, making scheduling a non-trivial task. There are many issues to consider when designing a packet scheduler, like for example:

• What types of packet data services are expected?

• What are the statistical properties of the expected data traffic?

• What will the average channel holding time for each UE be?

• How sensitive should the scheduler be to radio quality changes?

• Should a certain minimum QoS level be guaranteed?

A packet scheduler can be implemented that is very efficient at scheduling for a particular type of service, say Web browsing. But that same scheduler might perform terribly for a different type of service, say video streaming. Designing a packet scheduler that performs reasonably well for all types of (foreseeable) packet data services will inevitably lead to compromises- there really are no free lunches. There are many different scheduling algorithms defined for various purposes. Some are used practically, e.g. in routers and computer operating systems, while others are (so far) theoretical constructs. Many of these can be applied in very different fields. For example, the First-In First-Out (FIFO) algorithm can be used in a warehouse as well as the CPU of a PC. It is important to note that there is no such thing as a standardized ‘LTE Scheduling Algorithm’. The ‘inner workings’ of the packet scheduler in the eNB will therefore always be implementation dependent.

eshushi

高亮

eshushi

高亮

eshushi

高亮

eshushi

高亮

eshushi

高亮

eshushi

高亮

eshushi

高亮

eshushi

高亮

eshushi

高亮


There are several vendor-specific algorithms that have been implemented for High Speed Packet Access (HSPA) that may, or may not, be re-used for LTE. The descriptions below are intended to give the reader a good idea of the basic properties of the respective algorithm in its purest form. A real-life implementation can of course include various tweaks and twists to this baseline functionality. As mentioned earlier, there are differences between downlink and uplink scheduling. It is therefore very likely that different algorithms, or at least different internal control parameters, are applied for the downlink and the uplink schedulers. In the following we will briefly touch upon four different approaches to scheduling, focusing on downlink scheduling.

Maximum C/I As the name implies, this scheduling algorithm favors UEs who experience good channel conditions. The eNB scheduler, based on the maximum C/I algorithm, will compare the CQI reports sent from the UEs in the cell and then schedule the next transmission to the UE who reports the highest CQI value. Thus, this scheduling algorithm serves, in each TTI, the user with the largest instantaneous supportable data rate. No other users will be scheduled until the queue of the highest-CQI UE is empty, or another UE reports an even higher CQI value. If no constraints are imposed through the users’ QoS, the maximum C/I algorithm will provide the highest system throughput of all the algorithms discussed here. However, the UEs experiencing poor radio channel conditions are allocated very little time resources, and are thus starved for throughput. Ultimately, their connections will be dropped (TCP timeouts etc) without the network satisfying their service. Therefore, this scheduler does not fully meet the QoS needs of services where data is expected within a certain time. The maximum C/I scheduler is in practice limited to 'best effort' type of services. So, the maximum C/I algorithm provides the highest system throughput. But the cost is that the fairness level will be very low. Some users get all/most resources while others get little or nothing. From a network operator’s point of view one would suspect that using only a pure maximum C/I scheduler would likely not maximise the profit, because the level of customer dis-satisfaction would be high due to many customers experiencing long or permanent outages.

Round Robin (RR) In this scheme the users are served in a strictly cyclic order in time, ignoring the channel quality conditions (no CQI reports needed for prioritising between UEs). Thus, a time-sharing approach is used, where TTIs are allocated cyclically to the active users.


An obvious advantage of this method is its simplicity, and that it ensures a fair distribution of (time) resources among the users in the cell. From the point of view of system throughput versus fairness, the RR scheduler can be seen as the absolute opposite to the maximum C/I scheduler. However, it does not at all take into consideration the relative priorities of the users’ data flows (all are treated equal). Nor does it consider the amount of buffered data awaiting transmission for a given UE. As a consequence, the cell throughput will be sub-optimised. Using this scheduling scheme will lead to decreased service performance with increased number of users, since the resource is shared strictly in time. It might therefore be difficult to fulfil agreed QoS levels, again with the exception of best effort services. One should also keep in mind that the end user is only concerned about his/her absolute service performance, and not about his/her relative performance compared to the rest of the users.

Proportional Fair (PF) The maximum C/I and RR algorithms favor either system throughput or fairness, respectively. The Proportional Fair algorithm tries to achieve a balance between the two. The PF scheduler serves the user with the maximum priority function. The ‘priority function’ can be seen as a simple mathematical formula that takes into account the potentially achievable data rate at the present moment (CQI) and the average throughput of the user. The PF algorithm can be expressed as:

[priority] = [CQI] / [average throughput]

From the relation above one can see that a low CQI user might still get a high priority, due to a low average throughput. The PF algorithm can be modified to include also the relative channel quality, by adding the average CQI for all users (avCQIall) and the average CQI for the given UE (avCQIuser):

[priority] = [CQI] / [average throughput] • [avCQIall] / [avCQIuser]

The PF scheduler thus ensures that users with good (relative) channel conditions are favoured, which increases the system throughput. At the same time the PF scheduler ensures that users with bad (relative) channel conditions still get a certain share of the cell resources, since their priority function will be favoured by a low average throughput. The sometimes favouring of ‘bad channel users’ increases the fairness level. As a result, the PF scheduler achieves a reasonable balance between system throughput and resource fairness.


LWDF The three scheduling algorithms mentioned above have a serious drawback in common: none of them is very suitable for real-time services. The reason is that such services have requirements on packet delays as well as on minimum (guaranteed) bit rates. In addition, for some real-time services, such as streaming, the packet loss rate must be kept below a manageable threshold. The delay requirement means that the scheduler must take into account the packet age, i.e. how long time a certain packet has been waiting in the transmission buffer, when making scheduling decisions. This is what the Largest Weighted Delay First (LWDF) scheduling algorithm does. The LWDF algorithm computes the priority function of a given user in the same way as PF (with or without the average CQI term) but adds two more terms. The first term is a constant (k) that is QoS or, perhaps, subscription dependent (e.g. different APNs may link to different priority levels). The second term relates to packet age and is expressed as the packet queuing delay, or Head-of-Line delay, divided by the maximum allowed packet queuing time, or Packet Due Time. The Head-of-Line delay (HoL) is the queuing delay experienced by the packet that currently occupies the front of the queue (for this user). The Packet Due Time (PDT) can, for example, be derived from the QoS Class Identifier (QCI) signalled from the MME. The priority function for the LWDF scheduler can thus be expressed as:

[priority] = k • [PF] • [HoL] / [PDT]

The term [PF] above represents the Proportional Fair priority function, as described in the previous section. Note that the term [HoL] / [PDT] ranges from zero to one and becomes closer to one when the head-of-line packet delay approaches the due delay. In this way, users with packet delays close to their deadline violation will be favoured. To conclude the scheduling section, it should be said that the concept of scheduling in wireless systems using shared radio resources is the subject of much research taking place at company R&D departments, universities and other research institutes. There is no doubt that different vendors will implement different approaches to scheduling in their first-release eNBs. And there is no doubt that these initial scheduling mechanisms will have to be replaced, or at least 're-tuned', as the LTE networks become more and more mature, serving more and more users and offering more and more complex services.


6.4 Hybrid-ARQ Operation The concept of reliability is crucial to most forms of data communication. Reliable data transmission can be defined as the reception of data PDUs at one end of a link in the same order as the PDUs where transmitted at the other end, without loss and without duplicates. Reliable transmission should also include the constraint that data is delivered to the receiver within a reasonable period of time (avoiding ‘out-of-date’ PDUs). Protocols which provide reliable communication use a combination of positive/negative acknowledgement (ACK/NACK) of received data PDUs and retransmission of negatively acknowledged PDUs. The concept of retransmission is very simple. Whenever one end (e.g. eNB) sends something to the other end (e.g. UE) it retains a copy of the data it sent until the recipient has acknowledged that it received it without errors. The method of using ACK/NACKs and retransmissions is commonly referred to as Automatic Repeat reQuest (ARQ). There is a large number of different ARQ protocols in use in today’s data and telecommunication networks, one example being the Transmission Control Protocol (TCP) used on the Internet. They all rely on the same basic concept of ACK/NACKs and retransmission, but the exact methods used varies between them. The following section describe the ARQ/HARQ mechanisms selected for the E-UTRA MAC protocol. The ARQ/HARQ mechanisms for the downlink and the uplink are, in most respects, identical. The following information therefore pertains to both DL and UL, unless otherwise stated.

6.4.1 E-UTRA HARQ Mechanisms So-called Stop-and-wait ARQ (SAW-ARQ) has been selected for the MAC-level retransmission functionality. SAW-ARQ is a very simple kind of ARQ protocol, in which the communication is done one PDU at a time. After sending each PDU the sender waits for an ACK and doesn't send any further PDUs until the ACK is received. If a NACK is received the PDU (or rather the copy of the PDU) is retransmitted. If an ACK is received the copy is removed from the buffer and the next PDU is transmitted (storing a copy of this next PDU in the transmit buffer). A hybrid-ARQ (HARQ) scheme uses also an error correcting code in conjunction with the error detection and retransmissions. Consequently, the receiver tries to decode the received PDU first and only requests a retransmission if it cannot correct all the errors. In the E-UTRA system, this error correcting code is nothing but the Turbo (de)coder mentioned earlier. Thus, the combination of layer 2 ARQ (MAC) with layer 1 error correction (Turbo coding) gives us Hybrid-ARQ. There are two main types of hybrid ARQ, denoted HARQ type-I and HARQ type-II.


In a HARQ type-I system the same version of a PDU is sent each time that the receiver asks for a retransmission of that PDU. The PDU is thus sent with exactly the same error detection and error correction codes applied. In this scheme a received PDU is discarded if the decoding fails. Each retransmission will thus not add any new information. This can be taken one step further by using ‘Chase combining’, after its inventor David Chase. With Chase combining, the receiver of a PDU will not discard it if the decoding fails. A normal retransmission is requested and the retransmitted packet will then be combined with the original (erroneous) packet prior to decoding. Thus, the receiver makes use of the packet that caused the retransmission request. Chase combining relies on the fact that the probability of exactly the same bit-error pattern to occur in two separate transmissions is extremely low. In a sense you could say that Chase combining relies on bit-errors to ‘cancel each other out’. This can be taken one step further still by using HARQ type-II, or Incremental Redundancy. In a HARQ type-II system the first transmission usually includes the information bits and a limited amount of redundant bits for error detection and error correction. These redundant bits are only intended for determining the reliability of the transmission, as if it was a pure ARQ scheme. If a retransmission is needed, additional redundant bits are sent which are then combined with the stored previously received information and redundant bits. Each retransmission will therefore add new information that was previously not available, thereby creating a single combined packet that is more reliable than any of its constituent parts. This mechanism, through which additional redundant bits are added step-by-step (i.e. retransmission-by-retransmission), is what gives HARQ type-II its better-known name: Incremental Redundancy. This way a stronger code with a lower code rate is obtained, after one or more retransmission, increasing the probability of successful decoding. In E-UTRA, selecting different Redundancy Versions (RV) produces the different 'versions' of one and the same packet. At the receiver the received packet is de-punctured, according to its specific RV, and then combined with previous version(s) of itself prior to decoding. When the same RV is used all the time we are back to Chase combining. Thus, Chase combining can be considered a special case of Incremental Redundancy. To summarise, the simple SAW-ARQ scheme is combined with the possibility of using different Redundancy Version in the rate matching process. This combination gives us SAW-HARQ where each transmitted PDU must be acknowledged before we are allowed to transmit the next. Remember that the TTI used in E-UTRA is only 1ms. The creation and sending of an ACK/NACK takes a certain amount of time. So does the processing of the ACK/NACK in the transmitter and the preparation of a new transmission (or a retransmission). Add to that the time needed for the UE to decode the PDCCH and we can easily see that all this is simply impossible to execute within the confines of a single TTI!


This kind of ‘ping-pong’ behaviour of the SAW protocol is relatively simple to implement but leads to very inefficient use of the radio channel. This is remedied by dividing the SAW protocol into multiple processes. Where one process has stopped and is awaiting its ACK, the next process can send the next PDU, stop and wait for an ACK etc. With a proper number of processes this will allow continuous data transmission. This is referred to as N-channel SAW-ARQ, with ‘N’ being the number of processes. For E-UTRA the number of processes has been set to 8, thus giving us 8-channel SAW-HARQ as the full label for the MAC-level retransmission scheme. What we have said so far is valid for both downlink and uplink HARQ. The concluding paragraphs specifies the differences between downlink and uplink, with regards to HARQ. In the downlink, the HARQ operation is asynchronous. This means that it is up to the eNB to, for a given UE, select the HARQ process to schedule in a given TTI (there is no need to schedule them strictly cyclically). As a consequence the eNB must indicate to the UE, on the PDCCH, to what HARQ process each transmission pertains. The UE must respond with ACK/NACK to each downlink transmission with exactly 4ms after the In the uplink, the HARQ operation is synchronous. This means that there is an implicit relation between the HARQ process number and the TTI (frame and subframe number) used by the UE for the uplink transmission. It is therefore no need to explicitly specify to the eNB to what HARQ process a given transmission pertains. The HARQ timing relations for the uplink are as follows: PDCCH assignment of uplink resources refers to uplink PUSCH transmission four TTIs later (4ms later) and a downlink ACK/NACK on PHICH refers to uplink PUSCH transmission four TTIs earlier (4ms earlier). The HARQ Round-Trip-Time (RTT) can then be defined as the time from initial transmission to a new transmission (or retransmission) for the same HARQ process. This gives us a fixed HARQ-RTT for the uplink of 8ms. The agreed upon timing relations are also the reason why the number of HARQ processes in E-UTRA has been set to 8 instead of some other number. The HARQ timing relations for the downlink are different. PDCCH assignment of downlink resources refers to the same TTI. In other words, the PDCCH and the associated PDSCH are transmitted in the same subframe. An uplink ACK/NACK on PUCCH refers to downlink PDSCH transmission four TTIs earlier (4ms earlier). However, for a given HARQ process, there is no fixed timing relation defined between uplink ACK/NACK and a new transmission or retransmission. The reason for this is that HARQ operation is asynchronous in the downlink. The HARQ-RTT for the downlink is therefore not fixed to a certain number of TTIs, but is instead subject to eNB scheduling decisions.

In the downlink, HARQ retransmissions are adaptive. This means that it is up to the eNB to, for a given UE and HARQ process, select the MCS and RV to use for a retransmission. As a consequence, DL retransmissions must always be scheduled on the PDCCH. In the uplink, HARQ retransmissions are eNB controlled- they may be adaptive or non-adaptive. If the eNB only issues a NACK on the PHICH to trigger a retransmission the UE will use the same MCS as for the initial transmission and a RV according to a predefined sequence (resulting in non-adaptive retransmission). If the NACK on the PHICH is accompanied by a scheduling assignment on the PDCCH, the UE will follow the commanded MCS and RV (adaptive retransmission). This is summarised in the table below.

Adaptive retransmission-NACK

No retransmission. Keep TB in HARQ buffer. PDCCH may trigger (adaptive) retransmission.

-ACK

Adaptive retransmission according to PDCCHRetransmissionACK or NACK

New transmission according to PDCCHNew transmissionACK or NACK

UE BehaviourPDCCHseen by UE

PHICHseen by UE

Adaptive retransmission-NACK

No retransmission. Keep TB in HARQ buffer. PDCCH may trigger (adaptive) retransmission.

-ACK

Adaptive retransmission according to PDCCHRetransmissionACK or NACK

New transmission according to PDCCHNew transmissionACK or NACK

UE BehaviourPDCCHseen by UE

PHICHseen by UE

Figure 6-4: Uplink HARQ operation

6.5 MAC PDU Formats A MAC PDU consists of a header; zero, one or more higher layer Service Data Units (SDU); zero, one or more MAC control elements and, if needed, padding. The header part is shown as grey fields in the figure below. A MAC PDU is always byte aligned (i.e. a multiple of 8 bits in length). The purpose of padding is to, if needed, adapt the size of the MAC PDU to the commanded transport block size by adding one or more padding octets. The overall structure of a MAC PDU is the same for the DL-SCH and the UL-SCH. The only difference is what MAC control elements that may be included. Figure 6-4 shows an example of a MAC PDU for the UL-SCH carrying a mix of control elements, SDUs and padding. Shown in the figure are also the definitions of the LCID field for the uplink and the downlink. As can be seen, the LCID specifies the logical channel identity to which a higher layer SDU pertains, the type of control element included or the presence of padding. A MAC PDU header consists of one or more sub-headers, with each sub-header corresponding to either an SDU, a control element or padding. The example in figure 6-4 shows four sub-headers. The fields labelled 'R' are reserved for future use and have no current definition.


A MAC PDU sub-header consists of at least a Logical Channel ID field (LCID) and an Extension flag (E). If needed, a Length field and a Format field (F) are also present.

MAC PDU: UL-SCH

SDU 1(One RLC PDU)

12345678

LengthLength

LCID = 11101R R E =1LCID = 00010R R E =1

F = 1

LengthLCID = 00001R R E =1

F = 0LCID = 11111R R E =0

Buffer StatusLCG

SDU 2(One RLC PDU)

Padding

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 8

Sub-header 1

Sub-header 2

Sub-header 3

Sub-header 4

Short Buffer Status Report11101

Power Headroom Report11011

C-RNTI11100

Long Buffer Status Report11110

Padding11111

Reservedyyyyy-11010

LogCH ID00001-yyyyy

CCCH00000

LCID Values UL-SCHIndex



C-RNTI11100


Padding11111

Reservedyyyyy-11010

LogCH ID00001-yyyyy

CCCH00000


UE Contention Resolution ID11100

Timing Advance11101

DRX Command11110

Padding11111

Reservedxxxxx-11011

LogCH ID00001-xxxxx

CCCH00000

LCID Values DL-SCHIndex


Timing Advance11101

DRX Command11110

Padding11111

Reservedxxxxx-11011

LogCH ID00001-xxxxx

CCCH00000


MAC PDU: UL-SCH

SDU 1(One RLC PDU)

12345678

LengthLength

LCID = 11101R R E =1LCID = 00010R R E =1

F = 1


F = 0LCID = 11111R R E =0

Buffer StatusLCG

SDU 2(One RLC PDU)

Padding

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 8

Sub-header 1

Sub-header 2

Sub-header 3

Sub-header 4

MAC PDU: UL-SCH

SDU 1(One RLC PDU)

12345678 12345678

LengthLength

LCID = 11101R R E =1LCID = 00010R R E =1

F = 1


F = 0LCID = 11111R R E =0

Buffer StatusLCG

SDU 2(One RLC PDU)

Padding

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 8

Oct 1

Oct 2

Oct 3

Oct 4

Oct 5

Oct 6

Oct 7

Oct 8

Sub-header 1

Sub-header 2

Sub-header 3

Sub-header 4



C-RNTI11100


Padding11111

Reservedyyyyy-11010

LogCH ID00001-yyyyy

CCCH00000




C-RNTI11100


Padding11111

Reservedyyyyy-11010

LogCH ID00001-yyyyy

CCCH00000



Timing Advance11101

DRX Command11110

Padding11111

Reservedxxxxx-11011

LogCH ID00001-xxxxx

CCCH00000



Timing Advance11101

DRX Command11110

Padding11111

Reservedxxxxx-11011

LogCH ID00001-xxxxx

CCCH00000


Figure 6-5: MAC PDU example- UL-SCH PDU with Buffer Status and padding

The first sub-header in figure 6-4 corresponds to the Short Buffer Status Report (BSR) immediately following the header part. The BSR has a fixed length so no length field is required in the sub-header. The E flag indicates that another sub-header follows (E=1). The abbreviation 'LCG' is short for Logical Channel Group. Sub-headers 2 and 3 correspond to the two SDUs following the BSR. The SDUs are associated with two different logical channels as indicated by the LCID fields. The Length field in each sub-header indicates the length in bytes of the corresponding SDU. The F field indicates if a long (F=1) or short (F=0) Length field follows. The long Length format is used when the corresponding SDU or control element is 128 bytes in length or longer. The fourth sub-header indicates the presence of padding at the end of the MAC PDU. The receiver calculates the number of padding octets present by subtracting the total length of the rest of the MAC PDU from the commanded transport block size for the transmission (hence no need for a Length field in this sub-header). This is the last sub-header (E=0).



6.6 References 36.213 E-UTRA; physical layer procedures 36.321 E-UTRA; Medium Access Control (MAC) protocol

specification

Apis Technical Training AB LSIG - Physical Layer Copyright © Apis Technical Training AB 2008. All rights reserved. 7-1

7 Uu-interface part IV: Physical Layer

7.1 INTRODUCTION .................................................................................7-2

7.2 CHANNEL ARCHITECTURE .................................................................7-3

7.2.1 Logical Channels......................................................................7-3

7.2.2 Transport Channels..................................................................7-4

7.2.3 Physical Channels....................................................................7-6

7.2.4 Physical Signals .......................................................................7-7

7.3 OFDM BASICS.................................................................................7-9

7.3.1 Background and History...........................................................7-9

7.3.2 Subcarriers and Multiplexing..................................................7-10

7.3.3 Orthogonality..........................................................................7-11

7.3.4 Cyclic Prefixes........................................................................7-12

7.3.5 OFDM Signal Generation.......................................................7-12

7.4 MIMO BASICS................................................................................7-13

7.4.1 Background and History.........................................................7-13

7.4.2 SIMO/MISO: Receive/Transmit Diversity...............................7-14

7.4.3 MIMO: Multiple Input Multiple Output.....................................7-14

7.4.4 Spatial Multiplexing and STC.................................................7-15

7.4.5 SU-MIMO and MU-MIMO.......................................................7-15

7.4.6 MIMO Techniques in E-UTRA ...............................................7-16

7.5 LAYER 1 PROCESSING CHAIN..........................................................7-17

7.5.1 Downlink Shared Channel (DL-SCH).....................................7-17

7.5.2 Uplink Shared Channel (UL-SCH) .........................................7-21

7.6 RESOURCE MAPPING......................................................................7-22

7.6.1 Radio Frame Structure...........................................................7-22

7.6.2 Resource Definitions ..............................................................7-23

7.6.3 Downlink Subframe................................................................7-25

7.6.4 Downlink Synchronisation Pattern .........................................7-27

7.6.5 Uplink Subframe.....................................................................7-27

7.7 RESOURCE ASSIGNMENTS ..............................................................7-29

7.8 REFERENCES .................................................................................7-31

7.1 Introduction

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

Figure 7-1: Physical layer protocol stack

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. 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 include 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, much of the content in this chapter pertains to both FDD and TDD, even though the focus is on FDD. (The expected market preferences dictate that the majority of deployed systems will be FDD.) Section 7.2 describes the overall (layer 1-3) E-UTRA channel architecture. A general overview of OFDM and MIMO is given in sections 7.3 and 7.4, respectively. The E-UTRA layer 1 processing chain for the uplink and downlink data channels is described in section 7.5. Section 7.6 deals with the mapping of uplink and downlink data and control channels onto 2-dimensional time-frequency radio resources and radio frames.


7.2 Channel Architecture

PDCP

PHY

RLC

MAC

RRC

PUSCH

MUX/DEMUX

IETF

PUCCHPDCCHPBCH PCFICH

SCHEDULING/ PRIORITY

PRACH

SRB DRBSRB DRBSRB SRBSRB

CCCHPCCH DTCHBCCH MTCHDCCH MCCH

PDSCH

HARQ HARQ

PMCH

RACH MCHDL-SCHPCHBCH UL-SCH

CONTROL PLANE USER PLANE

Logical Channels

TransportChannels

PhysicalChannels PHICH

PDCP

PHY

RLC

MAC

RRC

PUSCH

MUX/DEMUX

IETF



PRACH



PDSCH

HARQ HARQ

PMCH


CONTROL PLANE USER PLANE

Logical Channels

TransportChannels


PDCP

PHY

RLC

MAC

RRC

PUSCH

MUX/DEMUX

IETF



PRACH



PDSCH

HARQ HARQ

PMCH


CONTROL PLANE USER PLANEUSER PLANE

Logical Channels

TransportChannels


Figure 7-2: E-UTRAN channel architecture

There are three different channel ‘levels’ in the E-UTRAN 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 Data Radio Bearers (DRB) above the Packet Data Convergence protocol in figure 7-2. The SRBs are used for RRC control signalling and the DRBs are used for any form of data traffic.

7.2.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.



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.

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


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. System Information Block 1 (SIB1) contains the most often repeated non-BCH SI and is mapped onto the DL-SCH. SIB1 contains the PLMN id, Tracking Area Code (TAC) and the cell id. It may also contain scheduling information for additional SIBs (i.e. scheduling for SIB2 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.


7.2.3 Physical Channels

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 subcarrier 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 subframe (the size, in OFDM symbols, of the PDCCH control area is indicated by the PCFICH channel). 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: an uplink grant received in subframe n corresponds to uplink data transmission in subframe n+3. The PDCCH can be transmitted with 4 different formats Physical Control Format Indicator Channel (PCFICH). The sole purpose of this physical channel is to indicate the size, in OFDM-symbols, of the control area 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 (subcarriers) used for data transmission and the downlink resource used by the PHICH. UL transmission in subframe n generates ACK/NACK in subframe n+3. 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. The channel coding, modulation and subcarrier allocation is selected by the eNB. 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 with 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. Physical Random Access Channel (PRACH). The PRACH carries the random access preambles (see below) during the random access procedure.

7.2.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 third subcarrier and CIR estimates for subcarriers that do not carry reference signals are computed via interpolation. 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 eNB 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 506 unique sequences possible, meaning that the sequences are reused if the system consists of more than 506 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 eNB 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 a PUSCH or PUCCH transmission. The Sounding RS is used (when needed) to facilitate frequency dependent scheduling by the eNB. By ordering the UE (or group of UEs) to transmit a Sounding RS using the full system bandwidth (or a subset thereof) the eNB can estimate which subcarriers 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 eNB 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 1.25 kHz subcarriers allocated for random access by the eNB. There are 64 possible preamble sequences per cell. 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 eNB controls the UE output power by means of a-periodic transmit power commands as part of the uplink grants on the PDCCH.


7.3 OFDM Basics 7.3.1 Background and History

Orthogonal Frequency Division Multiplexing (OFDM) is a digital multi-carrier modulation scheme that uses a large number of closely spaced orthogonal subcarriers. Each subcarrier 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.

7.3.2 Subcarriers and Multiplexing

f

FDM

: Sub

-car

rier m

ultip

lexi

ng

t

TDM: radio frame multiplexing

Sub-carrier 1

Sub-carrier n

Radio frame 1 Radio frame m

f

FDM

: Sub

-car

rier m

ultip

lexi

ng

t

TDM: radio frame multiplexing

Sub-carrier 1

Sub-carrier n

Radio frame 1 Radio frame m

Figure 7-3: OFDM multiplexing

The OFDM transmitter spreads the data to be transmitted over a large number of subcarriers- typically more than a thousand. The data rate to be conveyed by each of these subcarriers is correspondingly reduced, thus transforming a single high bit rate channel to many low bit rate 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. With hundreds or thousands of subcarriers available it becomes quite straightforward how to multiplex users on the radio interface. Simply allocate different sets of subcarriers to different users (this is the ‘FDM’ in OFDM). More complex multiplexing schemes can be implemented by allowing users to share the available subcarriers both in the frequency domain (FDM) and the time domain (TDM). Furthermore, subcarrier 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 subcarriers where it experiences the least amount of interference. E-UTRA combines OFDM with FDM and TDM multiplexing schemes as well as subcarrier frequency hopping and channel dependent scheduling.


7.3.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.

In OFDM, the frequencies of the individual subcarriers 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 subcarrier does not 'see' the modulation of the others, so there is no crosstalk between subcarriers even though their spectra overlap. This allows us to ‘pack’ the subcarriers more densely than with traditional FDM, thus increasing spectrum efficiency. All the subcarriers allocated to a given user are transmitted in parallel. Fortunately, the apparently very complex processes of modulating (and demodulating) thousands of subcarriers simultaneously are equivalent to Discrete Fourier Transform (DFT) operations for which efficient Fast Fourier Transform (FFT) algorithms exist. To ensure orthogonality the subcarriers must have a common, precisely chosen carrier spacing (the distance between the peaks in the figure). 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 15 kHz (7.5 kHz for MBMS dedicated cells and 1.25 kHz for the PRACH).

Received signals areevaluated at their maximum

Received signals areevaluated at their maximum

Figure 7-4: Subcarrier orthogonality

The figure above shows a few subcarriers represented in the frequency domain (compare figure 7-3). The receiver will demodulate (or sample) each subcarrier precisely where it has it maximum value. Due to the ‘precisely-chosen frequency spacing’ all other subcarrier have the value zero at this precise frequency, despite that they overlap, thus not creating any interference at all.


7.3.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. 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’). 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).

7.3.5 OFDM Signal Generation 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 the figure) can be implemented in many different ways. Thus, figure 7-5 below does not represent the way to create an OFDM signal.

S

P

IFFT

AddCP RF

…

CodingModulation

fo

S

P

IFFT

AddCP RF

…

CodingModulation

fo

S

P

IFFT

AddCP RF

…

CodingModulation

fo

Figure 7-5: An OFDM transmitter

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 subcarriers. Inverse Fast Fourier Transform: each modulation symbol is used for modulating one subcarrier, in effect acting as a complex wight setting the amplitude and phase of the subcarrier. These modulated subcarriers 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. 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 runs the process in reverse. The IFFT process must be inverted in order to retrieve the information content of the individual subcarriers. This is done with the Fast Fourier Transform (FFT). Hence, the inverse of the Inverse-FFT is, of course, the FFT.

7.4 MIMO Basics 7.4.1 Background and History

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.


7.4.2 SIMO/MISO: Receive/Transmit Diversity 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:

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

7.4.3 MIMO: Multiple Input Multiple Output 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 above 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. 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 in the receiver. 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.

7.4.4 Spatial Multiplexing and STC 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 linear precoding matrix. Space-Time Coding (STC) was mentioned above as a way of realizing Tx diversity. The same theoretical framework is used also for true MIMO operation in order to multiply the data streams with a properly selected precoding matrix.

7.4.5 SU-MIMO and MU-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.


7.4.6 MIMO Techniques in E-UTRA All of the previously mentioned MIMO techniques (SM, STC, SU-MIMO, MU-MIMO) are supported in E-UTRA. However, the current specification allows variations as to what must be supported by the UE and the network. 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 downlink Tx diversity as described earlier). One should also note that 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 a 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 even impossible, to incorporate future improvements of MIMO 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 E-UTRA 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.

7.5 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.

7.5.1 Downlink Shared Channel (DL-SCH)

LayerMapping

Modulation

REMapper

REMapper

…

OFDMSignal

Generation

OFDMSignal

Generation…

Precoding

…

L1 HARQRate Matching

S P1 P2

Turbo CodingR = 1/3

DL-SCH

CRC24Attachment

Cell SpecificScrambling

Modulation

LayerMapping

Modulation

REMapper

REMapper

…

OFDMSignal

Generation

OFDMSignal

Generation…

Precoding

…


S P1 P2

Turbo CodingR = 1/3

DL-SCH

CRC24Attachment


Modulation

LayerMapping

Modulation

REMapper

REMapper

…

OFDMSignal

Generation

OFDMSignal

Generation…

Precoding

……


S P1 P2

Turbo CodingR = 1/3

DL-SCH

CRC24Attachment


ModulationModulationModulation

Figure 7-6: DL-SCH layer 1 processing chain

Figure 7-6 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 two transport block (MAC PDU) per 1ms TTI.

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.



Turbo 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 interleaver 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. 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.

Scrambling The bits in the code word are scrambled with a cell specific physical layer scrambling sequence prior to modulation.

Modulation

Figure 7-7: QPSK, 16QAM and 64QAM modulation

The DL-SCH uses QPSK, 16QAM or 64QAM modulation mapping, resulting in modulation symbols carrying 2, 4 or 6 coded bits respectively.



The 'dotted' modulation box in the figure indicates that, in MIMO mode, there may be two Transport Blocks processed in parallel by layer 1 before the modulation step. CRC attachment, Turbo coding etc is then performed on a per-TB basis.

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 earlier.

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 7.6.

OFDM Signal Generation OFDM symbols are then created using the assigned number of subcarriers 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. The final step, not shown in figure 7-6, involves conversion from digital signals to an analog waveform. This is not standardised in detail and is hence implementation specific and not covered further in this document.

7.5.2 Uplink Shared Channel (UL-SCH)

Modulation

REMapper

SC-FDMASignal

Generation


S P1 P2

Turbo CodingR = 1/3

UL-SCH

CRC24Attachment

UE SpecificScrambling

Data/ControlMultiplexing

Channel Coding

”PUCCH bits”

Interleaving

TransformPrecoding (FFT)

Modulation

REMapper

SC-FDMASignal

Generation


S P1 P2

Turbo CodingR = 1/3

UL-SCH

CRC24Attachment



Channel Coding

”PUCCH bits”

Interleaving


Modulation

REMapper

SC-FDMASignal

Generation


S P1 P2

Turbo CodingR = 1/3

UL-SCH

CRC24Attachment



Channel Coding

”PUCCH bits””PUCCH bits”

Interleaving


Figure 7-8: UL-SCH layer 1 processing chain

Only differences to DL-SCH coding are described in the following.

Data/Control Multiplexing The PUSCH and PUCCH physical channels are never sent simultaneously. Instead, the ‘PUCCH’ control bits will be multiplexed with the PUSCH data bits. The control bits are 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 earlier. That is, the modulation symbols are spread over the entire allocated bandwidth.

RE Mapping & SC-FDMA Signal Generation There is ever only one antenna port used for the uplink (no need for layer mapping and STC precoding). The last step creates SC-FDMA symbols instead of OFDM symbols.


7.6 Resource Mapping 7.6.1 Radio Frame Structure

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

slot 0

#7

slot 19

1 Radio Frame = 10ms

1 slot =0.5ms

1 subframe = 1ms

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

slot 0

#7

slot 19


1 slot =0.5ms

1 subframe = 1ms

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

slot 0

#7

slot 19


1 slot =0.5ms

1 subframe = 1ms

Figure 7-9: E-UTRA radio frame (FDD)

All bandwidth options have the same basic Transmission Time Interval (TTI) of 1ms. As shown in figure 7-9, 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 subcarrier spacing of 15 kHz. In addition there is also reduced subcarrier spacing, 7.5 kHz, for MBMS-dedicated cells. In case of 15 kHz subcarrier spacing there are two CP lengths defined, 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 subcarrier 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 subcarrier spacing there is only a single cyclic prefix length, TCP-low = 1024×Ts, corresponding to 3 OFDM symbols per slot.


7.6.2 Resource Definitions

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

OFDM symbols

Subc

arrie

rs


PhysicalResource

Block

ResourceElement

Control ChannelElement

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

PhysicalResource

Block

OFDM symbols

Subc

arrie

rs

ResourceElement

Control ChannelElement

Figure 7-10: Resource grid

Note: the mapping of physical channels to resource elements described in this section assumes the use of frame Type 1 and normal cyclic prefix. 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 subcarriers 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 (Nsymb=7 in the normal CP-length case). The number of resource blocks, NRB, that may be assigned (on a per-TTI basis) to the UE can range from NRB-min = 1 to NRB-max = 100. The system bandwidth is also expressed in multiples of PRBs, with 6 PRB corresponding to a 1.4 MHz system and 100 PRB to a 20 MHz system. The 2-dimensional time-frequency resource can visually be represented as a resource grid as depicted in Figure 7-10. Each little box within the grid represents a single subcarrier for one symbol period and is referred to as a Resource Element (RE). Figure 7-10 shows the resource grid for the E-UTRA FDD frame (Frame Type 1) using the normal cyclic prefix length, resulting in each PRB containing 84 REs.

Each RE corresponds, in terms of channel coded information content, to one QPSK/xQAM modulation symbol (i.e. 2, 4 or 6 channel coded bits). Note that for MIMO operation there is a resource grid present for each transmitting antenna. The main downlink control channels (PDCCH) use a slightly different concept. They are formed by aggregation of Control Channel Elements (CCE). Each CCE is, in turn, an aggregation of 9 RE Groups (REG), distributed over 1, 2 or 3 consecutive OFDM-symbols in the beginning of each subframe. Each REG consists of 4 consecutive REs that are "not used for other purposes". The last sentence means that the 4 REs in a REG need not be strictly consecutive, since some REs are 'consumed' by antenna Reference Signals (see figures 7-12 and 7-13).

* Number of PDCCH payload bits is system bandwidth dependent

UE attempts decoding of each configured PDCCH format/payload sizeBlind decodings resulting in code rate > ¾ are ignored by UE

57628814472

Number ofPDCCH bits *

7236189

Number ofRE Groups

8421

Number ofCCEs

3210

PDCCHFormat

57628814472


7236189

Number ofRE Groups

8421

Number ofCCEs

3210

PDCCHFormat

Size (in CCEs)Aggregation LevelType

2168284

24

66

Number ofPDCCH

Candidates

0, 1A, 1C, 3, 3A

0, 1, 1A, 1B, 2

DCIFormats

1616

126

84

21

Common

UE Specific

Search Space


2168284

24

66

Number ofPDCCH

Candidates

0, 1A, 1C, 3, 3A

0, 1, 1A, 1B, 2

DCIFormats

1616

126

84

21

Common

UE Specific

Search Space

* Number of PDCCH payload bits is system bandwidth dependent

UE attempts decoding of each configured PDCCH format/payload sizeBlind decodings resulting in code rate > ¾ are ignored by UE

57628814472


7236189

Number ofRE Groups

8421

Number ofCCEs

3210

PDCCHFormat

57628814472


7236189

Number ofRE Groups

8421

Number ofCCEs

3210

PDCCHFormat


2168284

24

66

Number ofPDCCH

Candidates

0, 1A, 1C, 3, 3A

0, 1, 1A, 1B, 2

DCIFormats

1616

126

84

21

Common

UE Specific

Search Space


2168284

24

66

Number ofPDCCH

Candidates

0, 1A, 1C, 3, 3A

0, 1, 1A, 1B, 2

DCIFormats

1616

126

84

21

Common

UE Specific

Search Space

Figure 7-11: PDCCH formats and search spaces

Different code rates (i.e. different levels of robustness) for the PDCCH are realized by aggregating different numbers of 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. This gives rise to the concept of Search Spaces within which the UE performs blind decoding, looking for so-called PDCCH candidates. The term 'DCI' in the table is short for Downlink Control Information and represents the control signalling content of the PDCCH. There are four main formats of the DCI. Minor variations, or sub-formats, are labeled 1A, 1B, 1C etc.


7.6.3 Downlink Subframe The resource grid for a downlink subframe is illustrated below (again, 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 the figure (one per slot).

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

Slot #4

12 S

ub-c

arrie

rs

RE for PDCCH, PCFICH and PHICH

Slot #5

RE for PDSCH

RE for antenna RS

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

Slot #4

12 S

ub-c

arrie

rs


Slot #5

RE for PDSCH

RE for antenna RS

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

Slot #4

12 S

ub-c

arrie

rs


Slot #5

RE for PDSCH

RE for antenna RS

Figure 7-12: Downlink subframe

Downlink Physical Control Channels The PHICH channel (ACK/NACK for uplink transmissions) is located in the 1st OFDM symbol of the subframe and occupies 3 REGs (12 REs) evenly distributed over the system bandwidth. 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 REGs (16 REs) evenly distributed over the system bandwidth. The exact 'location' of the resources used for the PCFICH are calculated by the UE based on the current physical cell identity, i.e. the PCFICH resource mapping is cell specific.


The PDCCHs are mapped onto the remaining REs in the 1-3 first OFDM symbols in the first slot of each subframe (2 symbols in the figure). 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 (the white REs in the figure). Thus, all the 84 REs in each Physical Resource Block cannot be used for actual data transmission.

Downlink Reference Signals

Slot # i

12 S

ub-c

arrie

rs

R1

R1

R1

R1

R1

R1

R1

R1

Slot # i+1

R1 RS for antenna port 1 RS for antenna port 2

Slot # i Slot # i+1

R2

R2

R2

R2

R2

R2

R2

R2

R2REs that cannot be used

Slot # i

12 S

ub-c

arrie

rs

R1

R1

R1

R1

R1

R1

R1

R1

Slot # i+1


Slot # i Slot # i+1

R2

R2

R2

R2

R2

R2

R2

R2


Slot # i

12 S

ub-c

arrie

rs

R1

R1

R1

R1

R1

R1

R1

R1

Slot # i+1


Slot # i Slot # i+1

R2

R2

R2

R2

R2

R2

R2

R2


Figure 7-13: Antenna reference signals (2 antenna ports)

Figure 7-12 on the previous page shows the antenna RSs (black REs) in case only one antenna port is used. Figure 7-13 below shows the, more realistic, case when 2 antennas are used at the eNB. Please note that the two grids are transmitted simultaneously on the two 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. 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 3rd subcarrier in a repeated, symmetric, time-frequency pattern. Note also that while one transmitter antenna is sending its Reference Signal, the other antenna is idle.


7.6.4 Downlink Synchronisation Pattern 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 subcarrier in the system. This center subcarrier is called the Direct Current (DC) subcarrier and never carries any information.

Slot #0 Slot #1

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

36

36

DC

Antenna RS (1 port) REs for PBCHSecondary SS

Primary SS

Slot #0 Slot #1

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

36

36

DC


Primary SS

Slot #0 Slot #1Slot #0 Slot #1

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

36

36

DC


Primary SS

Antenna RS (1 port)Antenna RS (1 port) REs for PBCHREs for PBCHSecondary SSSecondary SS

Primary SSPrimary SS

Figure 7-14: Synchronisation and PBCH pattern

The Primary and Secondary SS are transmitted in slot 0 and 10 on 62 subcarriers centered on the DC subcarrier. The Secondary SS occupies the 6th OFDM symbol and the Primary SS occupies the 7th. The Primary SS gives the UE slot synchronisation. The Secondary SS gives the UE frame synchronisation (it 'looks' slightly different in slot 0 and slot 10). The PBCH is transmitted on 72 subcarriers centered around the DC subcarrier 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 7-14, including Reference Signals for one antenna port (small black rectangles in the figure).

7.6.5 Uplink Subframe As mentioned earlier, the PUSCH physical channel is never transmitted at the same time as the PUCCH subchannel by any single UE. A PUSCH transmission may consist of anything from 1 PRB up to all the available system bandwidth in the uplink, while a PUCCH transmission always consists of 2 PRBs located at opposite 'ends' of the subcarrier spectrum. As a consequence, the resource mapping for the two channels look quite different.


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

Slot #4

12 S

ub-c

arrie

rs

Slot #5

RE for Demodulation RSRE for PUSCH

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

Slot #4

12 S

ub-c

arrie

rs

Slot #5

RE for Demodulation RSRE for PUSCH

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

Slot #4

12 S

ub-c

arrie

rs

Slot #5

RE for Demodulation RSRE for PUSCHRE for PUSCH

Figure 7-15: PUSCH subframe

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 subcarriers as those assigned for the associated PUSCH transmission and occupies the 4th SC-FDMA symbol in each slot.

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

Slot #4

12 S

ub-c

arrie

rs

Slot #5

Demodulation RS

RE for PUCCH

12 Sub-carriers

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

Slot #4

12 S

ub-c

arrie

rs

Slot #5

Demodulation RS

RE for PUCCH

12 Sub-carriers

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

Slot #4

12 S

ub-c

arrie

rs12

Sub

-car

riers

Slot #5

Demodulation RS

RE for PUCCH

Demodulation RS

RE for PUCCH

12 Sub-carriers

12 Sub-carriers

Figure 7-16: PUCCH subframe (PUCCH format 0 and 1)

The PUCCH resource is defined by a UE specific code and two consecutive PRBs with frequency hopping at slot boundary. The frequency hopping is implicitly understood to be from one 'end' of the subcarrier spectrum to the other. Demodulation RS occupies the 3rd-5th symbol for PUCCH format 0 and 1, and the 2nd and 6th for format 2 (not shown).


7.7 Resource Assignments For both downlink and uplink assignments, the eNB provides the UE with a Modulation and Coding Scheme index (IMCS) on the PDCCH. The Modulation and Coding Scheme index is then used as input to the following table in order to find out the Modulation Order (Qm) and the Transport Block index (ITBS).

25627246262362522624

1241311412104119410929828727626525424323222121020

21623

26628Reserved229Reserved430Reserved631

206221962118620176191661815617154161441513414

TB Size IndexITBS

Modulation OrderQm

MCS IndexIMCS

25627246262362522624

1241311412104119410929828727626525424323222121020

21623


206221962118620176191661815617154161441513414

TB Size IndexITBS

Modulation OrderQm

MCS IndexIMCS

25627246262362522624

1241311412104119410929828727626525424323222121020

21623


206221962118620176191661815617154161441513414

TB Size IndexITBS

Modulation OrderQm

MCS IndexIMCS

25627246262362522624

1241311412104119410929828727626525424323222121020

21623


206221962118620176191661815617154161441513414

TB Size IndexITBS

Modulation OrderQm

MCS IndexIMCS

Figure 7-17: Modulation Order and Transport Block size index

The Modulation Order tells the UE what modulation has been used by the eNB (downlink assignment on PDSCH) or shall be used by the UE (uplink assignment for PUSCH). Qm= 2, Qm= 4 and Qm= 6 corresponds to QPSK, 16QAM and 64QAM respectively. An additional parameter on PDCCH (NRB) specifies the number of PRBs allocated for the transmission. This PRB parameter is system bandwidth dependent as well as PDCCH format dependent, meaning that the UE must make use of system information (the MIB) and the PDCCH format information for this parameter to make sense.


When the number of PRBs has been determined, the UE then finds the exact size of the transport block by combining the TB index and the number of assigned PRBs into the following table.

19921864180017361608148013841288116010649689048407446805845044563923202882322001521208856

3

132012561192112810641000904840776696632600552488440376320296248232176152120104724832

2

3922481203202321042881763202321527220012048152104401207232884824563216

1

NPRB

………………………………………………………………………

…

………………………………………………………………………

…

753763285626637763170425616643057624573362833623

22920114481219848991211175688760101584079929141126968812216620071029651606876043925722436244573628563458422162362418001279213840

11050

550562737622510242545621468882292020438162138419392321984818366961833617328561641616305761526415283361411214254561296013

ITBS

19921864180017361608148013841288116010649689048407446805845044563923202882322001521208856

3

132012561192112810641000904840776696632600552488440376320296248232176152120104724832

2

3922481203202321042881763202321527220012048152104401207232884824563216

1

NPRB

………………………………………………………………………

…

………………………………………………………………………

…

753763285626637763170425616643057624573362833623

22920114481219848991211175688760101584079929141126968812216620071029651606876043925722436244573628563458422162362418001279213840

11050

550562737622510242545621468882292020438162138419392321984818366961833617328561641616305761526415283361411214254561296013

ITBS

Figure 7-18: Transport Block size table

The table in 7-18 is valid for the non-MIMO (or 1 TB) case. Note also that the table has been truncated- the full table has 110 columns.



7.8 References 36.211 E-UTRA; Physical channels and modulation 36.212 E-UTRA; Multiplexing and channel coding 36.213 E-UTRA; Physical layer procedures 36.300 E-UTRA E-UTRAN; overall description; Stage 2

Apis Technical Training AB LSIG - X2 Interface Copyright © Apis Technical Training AB 2008. All rights reserved. 8-1

8 X2-interface (X2AP)

8.1 INTRODUCTION .................................................................................8-2

8.2 X2-C INTERFACE..............................................................................8-3

8.2.1 Basic Mobility Procedures........................................................8-3

8.2.2 Global Procedures ...................................................................8-3

8.3 X2-U INTERFACE..............................................................................8-4

8.4 SELF-ORGANISING NETWORKS..........................................................8-5

8.4.1 Self-configuration .....................................................................8-5

8.4.2 Self-optimisation.......................................................................8-6

8.4.3 Self-healing ..............................................................................8-6

8.5 THE HOME ENODEB .........................................................................8-7

8.5.1 Node Configuration ..................................................................8-7

8.5.2 Access Restriction....................................................................8-8

8.5.3 Mobility .....................................................................................8-8

8.5.4 Security ....................................................................................8-9

8.5.5 QoS and Interference...............................................................8-9

8.6 REFERENCES .................................................................................8-11

8.1 Introduction

X2AP

SCTP

IP

L1/L2

eNB

X2-C

X2AP

SCTP

IP

L1/L2

eNBX2 Control Plane

GTP-U

UDP

IP

L1/L2

eNB

X2-U

GTP-U

UDP

IP

L1/L2

eNBX2 User Plane (only at HO)

X2AP

SCTP

IP

L1/L2

eNB

X2-C

X2AP

SCTP

IP

L1/L2

eNBX2 Control Plane

X2AP

SCTP

IP

L1/L2

eNB

X2-C

X2AP

SCTP

IP

L1/L2

eNB

X2AP

SCTP

IP

L1/L2

X2AP

SCTP

IP

L1/L2

eNB

X2-C

X2AP

SCTP

IP

L1/L2

X2AP

SCTP

IP

L1/L2

eNBX2 Control Plane

GTP-U

UDP

IP

L1/L2

eNB

X2-U

GTP-U

UDP

IP

L1/L2


GTP-U

UDP

IP

L1/L2

eNB

X2-U

GTP-U

UDP

IP

L1/L2

eNB

GTP-U

UDP

IP

L1/L2

GTP-U

UDP

IP

L1/L2

eNB

X2-U

GTP-U

UDP

IP

L1/L2

GTP-U

UDP

IP

L1/L2


Figure 8-1: X2-interface protocol stacks

The X2-interface connects eNBs together. The X2-interface is an IP-based interface and can therefore be seen as a point to multi-point interface. The Control Plane (CP) instance of the X2-interface (X2-C) uses the X2 Application Protocol (X2AP) for control signalling purposes between eNBs. The X2AP protocol, like the S1AP protocol, runs over SCTP. The X2AP protocol is used for control signalling exchange between eNBs. It supports Global and Basic Mobility procedures. Global procedures are signalling procedures that do not relate to a specific UE. An example of a Global procedure is eNB Configuration Update. Basic Mobility procedures are signalling procedures that do relate to a specific UE. An example of this is Handover. The User Plane (UP) instance of the X2-interface (X2-U) uses the GPRS Tunnelling Protocol- User plane (GTP-U) for user data tunnelling. The X2-U interface is used only during handover.



8.2 X2-C Interface 8.2.1 Basic Mobility Procedures

The Basic Mobility procedures are all associated with a specific UE. All UE associated signalling takes place over a logical X2 Connection. The UE-specific X2 Connection is identified in each node with an X2AP UE Identifier. Thus, all X2AP messages pertaining to a specific UE will carry two reference numbers: the X2AP UE Id selected by the source eNB and the X2AP UE Id selected by the target eNB. One such pair of reference numbers uniquely identifies a UE context in a node.

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. Inter/intra-eNB handovers are always hard handovers.

SN Status Transfer This procedure is used at handover to pass PDCP Sequence Numbers (SN) from the source eNB to the target eNB. This allows the target to perform re-ordering of downlink PDCP PDUs and to provide the UE with a PDCP Status report for uplink retransmission of PDCP PDUs (see chapter 5).

UE Context Release 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.

8.2.2 Global Procedures

X2 Setup The purpose of the X2 Setup procedure is to exchange application level data needed for two eNBs to interoperate properly on the X2-interface. This procedure shall be the first X2AP procedure triggered after the SCTP association (see chapter 3) has become operational. The eNBs use this procedure to exchange lists of served cells.


eNB Configuration Update The purpose of this procedure is to exchange application level data that have changed since the last X2 setup procedure was executed (i.e. to exchange updated lists of served cells).

Reset The purpose of the Reset procedure is to align the resources in eNB1 and eNB2 in the event of an abnormal failure. The procedure is initiated by eNB1 and resets all ongoing X2-procedures between the two and all eNB1-related context information stored in eNB2, with the exception of configuration data exchanged with the X2 Setup procedure.

Load Indication The purpose of the Load Indication procedure is to transfer interference information between eNBs for interference coordination purposes. The initiating eNB sends an 'uplink interference indication' to another eNB indicating in which parts of the spectrum it experiences low, medium and high interference. It also specifies in which parts of the spectrum it is especially sensitive to uplink interference. The interference is specified per Physical Resource Block (PRB, see chapter 7). The initiating eNB also specifies, again per PRB, if the downlink output power used by the other eNB is OK or not. Thus, the Load Indication procedure provides important input for the E-UTRAN Inter-Cell Interference Coordination (ICIC) function that may be used for node self-optimisation purposes (see section 8.4.2).

8.3 X2-U Interface The UP instance of the X2-interface (X2-U) is only used during inter-eNB handovers. The purpose of X2-U is to allow temporary forwarding of user data packets from the source eNB to the target eNB. This includes both downlink and uplink packets. The GPRS Tunneling Protocol (GTP-U) is used for encapsulation and tunneling of user data packets on the X2-U interface (see chapter 3 for more information on GTP-U). Note: the GTP-C protocol is never used on X2. There is always two X2-U GTP tunnels established: one for forwarding of downlink user data (from SGW) and one for forwarding of uplink user data (from UE or buffered in source).


8.4 Self-organising Networks With the term Self-organizing Networks (SON) is meant the functionality in network elements for self-configuration, self-optimization and self-healing without (or with minimal) manual intervention.

8.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.


8.4.2 Self-optimisation 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.

8.4.3 Self-healing Self-healing simply means that a network node (e.g. eNB) automatically triggers appropriate recovery actions in order to solve or mitigate faults. The trigger for self-healing is an alarm. The self-healing node monitors alarms and when it finds an alarm that can be solved automatically it gathers more necessary correlated information (measurements, internal test results etc). It then performs a 'deeper' analysis and, based on the result, triggers appropriate recovery actions to solve the fault automatically. The self-healing function should also generate appropriate notifications regarding the fault and the actions taken.


8.5 The Home eNodeB 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.

8.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.


8.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 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.

8.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.

8.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.

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


8.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 32.822 Telecommunication mgmt; study on self-optimization and

self-healing OAM requirements 36.423 E-UTRAN; X2 Application Protocol (X2AP)

Apis Technical Training AB LSIG - EPS Interworking Copyright © Apis Technical Training AB 2008. All rights reserved. 9-1

9 EPS Interworking

9.1 INTRODUCTION .................................................................................9-2

9.2 BASIC REQUIREMENTS......................................................................9-3

9.3 PS INTERWORKING...........................................................................9-4

9.3.1 3GPP Access ...........................................................................9-4

9.3.2 Non-3GPP Access ...................................................................9-5

9.3.3 Optimised Mobility Mechanisms ..............................................9-6

9.4 CS INTERWORKING ..........................................................................9-7

9.4.1 The CS "Problem" ....................................................................9-7

9.4.2 CS Fallback..............................................................................9-7

9.4.3 Voice Call Continuity (VCC).....................................................9-9

9.5 REFERENCES .................................................................................9-10

9.1 Introduction Iu-PS

S1-MME

S1-U


GERAN

UTRAN

TrustedIP access

Gb/Iu

HSS

S6a


MME

S5 SGi

S11

S4S3

SGSN

S12 SPR

Gr

PCRF

Sp

Gx Rx

S2a

E-UTRANX2-C

X2-U

ePDG HSS/ AAA

SWm

S2b

PGW

S6b

OFCS

OCS

Gy

Gz

S10

Iu-PS

S1-MME

S1-U


GERAN

UTRAN

TrustedIP access

Gb/Iu

HSS

S6a


MME

S5 SGi

S11

S4S3

SGSN

S12 SPR

Gr

PCRF

Sp

Gx Rx

S2a

E-UTRANX2-C

X2-U

ePDG HSS/ AAA

SWm

S2b

PGW

S6b

OFCS

OCS

Gy

Gz

S10

Iu-PS

S1-MME

S1-U

SWnSWnNon-trustedIP access

Non-trustedIP access

GERANGERAN

UTRANUTRAN

TrustedIP accessTrusted

IP access

Gb/Iu

HSS

S6a

IMS / Internet /…IMS / Internet /…SGW

MME

S5 SGiSGi

S11

S4S3

SGSN

S12S12 SPR

Gr

PCRF

Sp

Gx RxRx

S2aS2a

E-UTRANX2-C

X2-UE-UTRAN

X2-C

X2-U

X2-C

X2-U

ePDG HSS/ AAA

SWm

S2bS2b

PGW

S6bS6b

OFCS

OCS

GyGy

Gz

S10S10

Figure 9-1: EPS network architecture

The figure above shows the overall Evolved Packet System (EPS) network architecture. As can be seen, there are interfaces defined between the nodes/functions in the Evolved Packet Core (EPC) and other, non-LTE, Radio Access Technologies (RATs). The purpose of these interfaces is to allow the UE to access the EPC (and the corresponding services) from a wide variety of access technologies. One can therefore say that the EPC is 'access agnostic', i.e. it should not matter what radio access technology the UE is currently using- the same services should be available anyway (in the best of worlds…). This is clearly reflected in some of the basic requirements that where agreed upon early in the EPS standardisation process. These requirements where listed in chapter 1, and are here discussed in a little more detail in section 9.2. This is in order to provide the reader with proper background information before describing various mobility scenarios in more detail in the subsequent sections. Mobility to/from 3GPP defined (i.e. GERAN/UTRAN) and non-3GPP defined packet switched (PS) access networks/technologies is discussed in section 9.3. That section also discusses the "optimised mobility solutions" that have been defined for certain specific non-3GPP access technologies. Interworking with legacy circuit switched (CS) networks is of particular interest. The reason being that the EPS is a fully IP-based network, where all forms of CS transmission/services have been eliminated! Some of the, more probable, proposed solutions for CS interworking are described in section 9.4.



9.2 Basic Requirements In the beginning… there was circuit switched GSM, and no interworking problems existed. Then, in R97, GPRS was introduced and suddenly a whole range of questions popped up. Can a terminal support both CS and PS connections simultaneously? What about paging co-ordination? Can the CS core network domain be interconnected with the PS domain? What happens with a voice call when a packet session is established? Much has happened since then. Today there are multi-RAT capable terminals and network operators that deploy multiple access technologies, all connected to the same core network and/or service layer. The people taking part in the initial standardisation process for E-UTRAN and EPC of course knew all this. Let's re-visit some of the basic requirements that where agreed upon. "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 at handover of real-time services between E-UTRAN and UTRAN/GERAN should be less than 300ms." This, in effect, just means that the handover mechanisms defined for EPS should, in some sense, be backwards compatible to those used in GERAN/UTRAN. The source access system (e.g. E-UTRAN) decides about starting a handover and provides the necessary information to the target system (e.g. UTRAN) in the format required by the target system. In other words, if we stick to standard 3GPP-defined signalling procedures everything should be OK. "3GPP and non-3GPP access systems shall be supported." Interworking with WLAN was introduced already in R6. However, this was 3GPP-defined WLAN access and not just any WLAN access point. The requirement above goes a lot further than that. The term 'non-3GPP access system' means exactly that: any form of access not standardised by 3GPP. This includes other wireless technologies such as WiMAX and CDMA2000, but also fixed access technologies such as xDSL. Thus, the EPC should be able to, in a well-controlled manner, handle connections to/from pretty much any access network technology in which the UE can be allocated an IP-address. "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." We have a situation where multi-band, multi-RAT, multi-radio terminals are roaming in an environment where they can be served by multiple technologies and multiple operators. The seemingly simple process of network selection after power-on can then take quite some time. And it is


not trivial to figure out what services are best handled over what access technology. Then there are the questions of roaming agreements, QoS policies, security and charging to consider. For these, and other, reasons a new network function has been proposed: the Access Network Discovery and Selection Function (ANDSF). A logical interface, S14, between the UE and the ANDSF (in the home domain) has been defined, but no specific signalling protocol has yet (Sept-08) been decided upon. The purpose of the ANDSF is to provide the UE with lists of available, local, access technologies. It will also be possible for the home network operator to, via the ANDSF, provide the UE with local inter-RAT mobility policies, such as preferred and/or restricted access technologies/networks. "It shall be possible to support service continuity between IMS over SAE/LTE access and the Circuit Switched (CS) domain." As can be understood from the above quotation, the 'CS problem' alluded to earlier was foreseen already at start of the standardisation process. The R7 IMS specifications introduced a service called Voice Call Continuity (VCC) that allows transfer of a call from the PS core network domain to the CS core network domain. The meaning of the stated requirement is thus that the EPS should support VCC (or something similar).

9.3 PS Interworking 9.3.1 3GPP Access

The GTP-based S3-interface allows MME ↔ SGSN communication, such as retrieval of UE contexts due to idle mode mobility. An example of this is when the UE moves from an E-UTRAN cell to a UTRAN cell, thus triggering a Routing Area update towards the SGSN. This is, in effect, no different to any inter-SGSN Routing Area update. The SGSN need not even be R8, since the MME must be able to perform a fallback from GTP version 2 to GTP version 1 when necessary. The same interface is used for signalling at PS handover involving the MME and the SGSN. The signalling messages needed for a well-defined, real-time, PS handover where introduced in R6. Thus, the SGSN and the access network node (BSC or RNC) must be at least R6 nodes. It is the task of the MME to convert a 'PDN context' to a 'PDP context' and to convert from the EPS-defined QoS parameters to QoS parameters that the SGSN can understand (i.e. the 'QoS profile' as part of the PDP context). After an E-UTRAN to GERAN/UTRAN PS handover, the user plane remains anchored in the SGW (it acts as a GGSN towards the SGSN). A new GTP-U tunnel is established on the S4-interface or, if UTRAN supports the direct-tunnel mentioned in chapter 1, the S12-interface.


9.3.2 Non-3GPP Access Non-3GPP access is either 'trusted' or 'non-trusted'. The word 'trusted' should not be interpreted in the human sense to 'trust someone'. Instead it is a way of classifying other access networks in terms IP-level security mechanisms and/or inter-operator business agreements. Trusted non-3GPP IP-access connects to the PGW with the S2a-interface using the Proxy Mobile IP protocol (PMIP) or Mobile Ipv4 (MIPv4). Non-trusted non-3GPP IP-access needs an Evolved Packet Data Gateway (ePDG) in the connection path. The S2b-interface uses PMIP and connects the PGW with the 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 SWn-interface. The ePDG may require interaction with an Authentication, Authorization and Accounting server (AAA-server) and/or HSS, using the SWm-interface. The AAA-server either executes the AAA-functions or, alternatively, provides necessary data for the ePDG to do so. A non-3GPP access network, be it trusted or non-trusted, will not support the protocols and procedures needed to execute a well-defined, real-time, PS handover. Thus, service continuity cannot be guaranteed. The purpose of defining mobility scenarios between E-UTRAN and non-3GPP access networks in the specs is all about connectivity continuity and IP-level security. The UE shall be allowed to move freely between these access technologies without having to renew the PGW-allocated application-level IP-address that is associated with its default bearers. The UE (and the PGW) shall also be guaranteed a secure IP-connection. This is all handled by adopting IETF-defined mobility solutions. More specifically, a Mobile IP tunnel is established between the UE and the PGW (S2a-interface, trusted access) or between the UE and the ePDG (SWn-interface, non-trusted). The result of this is that an IPsec protected connection is maintained between the UE and its home domain (the PGW). There are many IETF-defined mechanisms with which to establish such tunnels. The specific mechanism to use depends on the version of the IP-protocol used (IPv4 or IPv6), the UE capabilities, the EPC network configuration and the non-3GPP authentication framework selected.

9.3.3 Optimised Mobility Mechanisms The MIP-based mobility discussed above is, in the 3GPP specs, referred to as 'non-optimised mobility'. 'Optimised mobility' mechanisms have been defined especially for mobility between E-UTRAN and mobile WiMAX and between E-UTRAN and CDMA2000 systems. The solutions defined for the two are very similar and are here treated as one. A protocol tunnelling mechanism has been defined to support handover to WiMAX/CDMA2000. This means that non-3GPP signalling messages are sent transparently to the target system, with the eNB and MME acting as relay points. Tunnelling is achieved over the E-UTRA radio interface by encapsulating tunnelled non-3GPP messages in the RRC UL Information Transfer and DL Information Transfer messages.

S101

IMS / Internet /…PGWE-UTRAN SGW

MME

HRPD/1xRTT

WiMAX

S102 S103 S2a

S101-interface: allows tunneling of (non-3GPP) handover/mobility signalling.

S102-interface: allows the VCC and/or CS Fallback features towards 1xRTT.

S103-interface: allows forwarding of DL data during mobility from E-UTRAN to HRPD.

S2a-interface: a User Plane interface betwwen a WiMAX Access Service Network (ASN) node and the PGW

S101


MME

HRPD/1xRTT

WiMAX

S102 S103 S2aS101


MME

HRPD/1xRTT

WiMAX

S102 S103 S2a

S101-interface: allows tunneling of (non-3GPP) handover/mobility signalling.

S102-interface: allows the VCC and/or CS Fallback features towards 1xRTT.

S103-interface: allows forwarding of DL data during mobility from E-UTRAN to HRPD.

S2a-interface: a User Plane interface betwwen a WiMAX Access Service Network (ASN) node and the PGW

Figure 9-2: Interworking with WiMAX and/or CDMA2000

The S101-interface connects the MME with the target system, as seen in figure 9-2. When the (tunnelled) signalling to prepare and execute the handover has taken place over the S101-interface, the user plane is re-directed from E-UTRAN to the target system. In the WiMAX case, the user plane connection is the S2a-interface mentioned earlier. In the CDMA2000 case, the user plane connection is the S103-interface. The figure also shows the S102-interface, for CS Fallback to 1xRTT (see section 9.4.2). The abbreviation 'HRPD' is short for High Rate Packet Data, which is the CDMA2000 equivalent of HSPA. The abbreviation '1xRTT' can best be spelled out as "Radio Transmission Technology with 1 radio channel" which is the CDMA2000 equivalent of CS UTRAN.


Pre-registration by the UE in the target system is needed, at least for the HRPD case. Pre-registration allows the UE to establish a presence with the HRPD system in advance of a cell re-selection or handover. E-UTRAN does not need to know whether a specific UE is pre-registered or not (the procedure is transparent to E-UTRAN). The UE is responsible for maintaining the HRPD context, for example by performing periodic re-registrations if needed.

9.4 CS Interworking 9.4.1 The CS "Problem"

The potential problem of interworking with legacy Circuit Switched (CS) networks lies in the fact that the EPS is an all-IP network and that there are no mandatory interfaces defined between the MME and the MSC Server. A VoIP call (Voice or Video call over IP) may very well be handed over to GERAN/UTRAN provided that the target system supports PS Handover signalling and can handle the strict QoS requirements for real-time services in the PS domain. Further, if there were an interface defined towards legacy MSC Servers, where and when would the conversion between PS VoIP packets and CS AMR speech frames take place? A number of companies/representatives have proposed various solutions to this conundrum at EPS-related standardisation meetings. Two of these solutions have been agreed upon to be 'realistic' in the sense that they do not require any major changes to the core EPS specifications and that they do not add unreasonable complexity to the system. These solutions are 'CS Fallback' and 'Voice Call Continuity'.

9.4.2 CS Fallback GERAN/UTRAN

Gb/Iu


S4

MME

S3

SGSN

PGW

MSCServer

A/Iu

SGs

E-UTRAN

SGs-interface: allows ’CS Fallback’, where the UE is paged in E-UTRAN and the call is setup in GERAN/UTRAN

GERAN/UTRAN

Gb/Iu


S4

MME

S3

SGSN

PGW

MSCServer

A/Iu

SGs

E-UTRAN

SGs-interface: allows ’CS Fallback’, where the UE is paged in E-UTRAN and the call is setup in GERAN/UTRAN

Figure 9-3: SGs-interface for CS Fallback

The 'CS Fallback for EPS' feature enables fallback from E-UTRAN access to UTRAN/GERAN CS domain access or to CDMA2000 1xRTT CS domain access. It covers the speech service as well as CS data, SMS and non-call related Supplementary Services (e.g. USSD).



The feature requires the introduction of the SGs-interface between the MME and the MSC Server. The SGs-interface is used for executing mobility management and paging procedures between EPS and the CS domain and is also used for the transfer of mobile originating/terminating SMS. The S102-interface is the SGs-interface equivalent when the target system is CDMA2000 1xRTT (see figure 9-2). The feature builds on dual registration. A CS Fallback capable UE will request a combined EPS/IMSI Attach from the MME. The MME uses the SGs-interface to relay the registration to the MSC Server. The UE will then maintain the dual registration by initiating combined TA/LA Updates. When the MSC Server receives an incoming call for the UE, it will initiate paging over the SGs-interface. The MME sends an S1AP paging message, together with a CS Fallback Indicator, to the eNB. The UE is then paged and an RRC Connection is established in the normal manner. The eNB then immediately triggers a handover to the target system. This step may be preceded by a short period during which the UE is ordered to perform, and report, measurements on the target system. The UE moves to the target system/cell and sends a 'Handover Complete' message (the exact name of the message depends on the target system and its capabilities). Completion of the handover means that the UE now has an 'RRC Connection' in the target system/cell. This connection is used to send a Paging Response to the MSC Server. Normal call setup signalling is then used to establish the call in the target system. The CS Fallback feature for mobile originating calls is very similar. In that case the UE sends an EMM Service Request message with a CS Fallback Indicator to the MME. The rest of the signalling is the same as above, with the exception that the UE sends a CM Service Request message instead of a Paging Response to the MSC Server. The SGs-interface is modelled on the legacy MSC ↔ SGSN Gs-interface. The L3 protocol is called the SGs Application Protocol (SGsAP), which is based on the Gs-interface BSSAP+ protocol. The Combined EPS/IMSI Attach and TA/LA Update procedures are based on the legacy combined GPRS/IMSI Attach and RA/LA Update procedures.

9.4.3 Voice Call Continuity (VCC) GERAN/UTRAN

Gb/Iu


S4

MME

S3

SGSN

PGW

MSCServer

A/Iu

SV

E-UTRAN

SV-interface: allows PS-to-CS domain transfer via a Voice Call Continuity (VCC) capable MSC server

GERAN/UTRAN

Gb/Iu


S4

MME

S3

SGSN

PGW

MSCServer

A/Iu

SV

E-UTRAN

SV-interface: allows PS-to-CS domain transfer via a Voice Call Continuity (VCC) capable MSC server

Figure 9-4: SV-interface for VCC

The full name of the feature is 'Single Radio Voice Call Continuity' (SR-VCC), enabling transfer of voice calls between PS access and CS access when the UE is not capable of transmitting/receiving in both of those access networks simultaneously (hence 'single radio'). The EPS SR-VCC feature is based on the VCC feature introduced for IMS in R7 and requires explicit support in the UE, the eNB, the MME and the MSC Server. It is also required that the voice call has been setup as an IMS telephony session and that the call remains anchored in IMS after the transfer. It should be noted that SR-VCC is defined as a service. It is possible that subscription data in the HSS dictate that the service is not allowed under certain circumstances, such as when the UE is in a visited network. It should also be noted that SR-VCC from UTRAN/GERAN CS access to E-UTRAN is not specified in R8. The SR-VCC feature transfers an ongoing call between the PS and the CS domain. This is in contrast to the CS Fallback feature, which transfers a call even before it has been established. The transfer of a call from the EPS domain to the CS domain with SR-VCC is similar to a normal handover. Based on measurement reports, the eNB takes a handover decision. The eNB sends a handover request to the MME, with an indication that this is a SR-VCC handover. The MME triggers the SR-VCC procedure with the MSC Server via the SV-interface (figure 9-4). The SV-interface protocol is not yet defined (Sept-08). The MSC Server then initiates the session transfer towards IMS and coordinates it with the CS handover to the target cell. The MSC Server sends a response back to the MME when radio resources have been prepared in the target cell. The response includes the radio interface Handover Command message for the UE. The UE moves to the target cell and transmits a Handover Complete message. The MSC Server then concludes the session transfer towards the IMS, at which point the downlink flow of VoIP packets is switched towards the CS access network.



9.5 References 23.216 Single Radio Voice Call Continuity (SRVCC) 23.272 CS Fallback in Evolved Packet System (EPS); stage 2 23.401 GPRS enhancements for E-UTRAN access 23.402 Architecture enhancements for non-3GPP accesses 36.300 E-UTRA/E-UTRAN; overall description; Stage 2

lte signalling 1 eps overview - st3...

Documents