07 TM51107EN03GLA3 Evolution

UMTS Evolution

TM51107EN03GLA3 © 2010 Nokia Siemens Networks

1

Contents

1 UMTS air interface technology 3 1.1 UMTS Release 5 4 2 Release 6 23 2.1 Multimedia Broadcast Multicast Service (MBMS) 26 2.2 WLAN 31 2.3 HSUPA 37 3 Release 7 43 4 Release 8 47 5 LTE 49 5.1 Introduction 50 5.2 LTE design goals 52 5.3 LTE basic concepts 53 5.4 OFDM 54 6 Exercises 65

UMTS Evolution

UMTS Evolution

TM51107EN03GLA3

© 2010 Nokia Siemens Networks 2

UMTS Evolution


3

1 UMTS air interface technology

UMTS Evolution

TM51107EN03GLA3


The following topic discuss about the evolutionary path of the UMTS R5 to the Long Term Evolution LTE Technology and list significant events in the evolution of 3G networks and beyond.

1.1 UMTS Release 5

UMTS Rel-5 was published in 2002. It is a major release, adding the following main features:

IMS

With the introduction of IMS, UMTS now has a standardized means of offering the multimedia services for which it was built.

High Speed Downlink Packet Access

High Speed Downlink Packet Access (HSDPA) is the first installment of HSPA. It enhances the UMTS air interface on the basis of 16-QAM and other techniques in order to introduce a downlink shared channel with packet rates up to a theoretical value of 14.4Mb/s.

The bandwidth offered by HSDPA is higher than the 2Mb/s required from a 3G Network.

A UMTS Network with HSDPA therefore already qualifies as “3.5G”.

3GPP System

The UMTS specification was extended in order to allow not just a UTRAN but also a GERAN to be attached to PS Domain and CS Domain. The result is called a 3GPP System.

Iu Flex

In earlier releases, the relation of RNCs and SGSNs/MSCs is strictly treelike and hierarchical: each SGSN serves several RNCs, and each RNC is attached to exactly one SGSN and MSC (cf. Figure 8a). This restriction was lifted, allowing many-to-many relations between SGSNs/MSCs and RNCs.

UMTS Evolution


5

1.1.1 HSDPA

This chapter presents High-speed Downlink Packet Access (HSDPA) for WCDMA – the key new feature included in the Release 5 specifications. The HSDPA concept has been designed to increase downlink packet data throughput by means of fast physical layer (L1) retransmission and transmission combining, as well as fast link adaptation controlled by the Node B (Base Transceiver Station (BTS)). This chapter is organized as follows: First, HSDPA key aspects are presented and a comparison to Release ’99 downlink packet access possibilities is made. Next, the impact of HSDPA on the terminal uplink (user equipment (UE)) capability classes is summarized and an HSDPA performance analysis is presented, including a comparison to Release ’99 packet data capabilities, as well as performance in the case of a shared carrier between HSDPA and non-HSDPA traffic. The chapter is concluded with a short discussion of evolution possibilities of HSDPA, including a description of the on-going work on uplink improvements in 3GPP.

1.1.1.1 HSDPA concept

The key idea of the HSDPA concept is to increase packet data throughput with methods known already from Global System for Mobile Communications (GSM)/Enhanced Data rates for Global Evolution (EDGE) standards, including link adaptation and fast physical layer (L1) retransmission combining. The physical layer retransmission handling has been discussed earlier but the inherent large delays of the existing Radio Network Controller (RNC)-based Automatic Repeat reQuest ARQ architecture would result in unrealistic amounts of memory on the terminal side. Thus, architectural changes are needed to arrive at feasible memory requirements, as well as to bring the control for link adaptation closer to the air interface. The transport channel carrying the user data with HSDPA operation is denoted as the High-speed Downlink Shared Channel (HS-DSCH). A comparison of the basic properties and components of HS-DSCH and DSCH is conducted in (Table 1).

A simple illustration of the general functionality of HSDPA is provided in (Figure 11.1, to be reproduced). The Node B estimates the channel quality of each active HSDPA user on the basis of, for instance, power control, ACK/NACK ratio, and HSDPA-specific user feedback. Scheduling and link adaptation are then conducted at a fast pace depending on the active scheduling algorithm and the user prioritization scheme. The channels needed to carry data and downlink/uplink control signaling are described later in this chapter.

With HSDPA, two of the most fundamental features of WCDMA, variable SF and fast power control, are disabled and replaced by means of adaptive modulation and coding (AMC), extensive multicode operation and a fast and spectrally efficient retransmission strategy.

UMTS Evolution

TM51107EN03GLA3


Feature DSCH HS-DSCH

Variable Spreading Factor Yes No

Fast power control Yes No

Adaptative modulation and coding (AMC)

No Yes

Multicode operation Yes Yes, extended

First L1 HARQ* No Yes

*HARQ: Hybrid Automatic Repeat reQuest

Table 1. Comparison of fundamental properties of DSCH and HS-DSCH

In the downlink, WCDMA power control dynamics is in the order of 20 dB, compared to the uplink power control dynamics of 70 dB. The downlink dynamics are limited by the intra-cell interference (interference between users on parallel code channels) and by the Node B implementation. This means that for a user close to the Node B, the power control cannot reduce power maximally, and on the other hand reducing the power to beyond 20 dB dynamics would have only marginal impact on the capacity. With HSDPA, this property is now utilized by the link adaptation function and AMC to select a coding and modulation combination that requires higher Ec/I0r, which is available for the user close to the Node B (or with good interference/channel conditions in the short-term sense). This leads to additional user throughput, basically for free. To enable a large dynamic range of the HSDPA link adaptation and to maintain a good spectral efficiency, a user may simultaneously utilize up to 15 multicodes in parallel. The use of more robust coding, fast Hybrid Automatic Repeat Request (HARQ) and multicode operation removes the need for variable SF.

To allow the system to benefit from the short-term variations, the scheduling decisions are done in the Node B. The idea in HSDPA is to enable a scheduling such that, if desired, most of the cell capacity may be allocated to one user for a very short time, when conditions are favorable.

In the optimum scenario, the scheduling is able to track the fast fading of the users.

The physical layer packet combining basically means that the terminal stores the received data packets in soft memory and if decoding has failed, the new transmission is combined with the old one before channel decoding. The retransmission can be either identical to the first transmission or contain different bits compared with the channel encoder output that was received during the last transmission. With this incremental redundancy strategy, one can achieve a diversity gain as well as improved decoding efficiency.

UMTS Evolution


7

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

New NodeB functionality, fast scheduling based on :

• Quality Feedback

• UE Capacity

• Ressource Availability

• Buffer Status

• QOS and Priority

Channel quality feedback (HS-DPCCH, DCH)

Channel quality indicator, PC commands, ACK/NACK

User data (HS-DSCH, HS-SCCH)

Fig. 1 General operation principle of HSDPA and associated channels

UMTS Evolution

TM51107EN03GLA3


1.1.1.2 HSDPA impact on Radio access network architecture

All Release ’99 transport channels are terminated at the RNC.

Hence, the retransmission procedure for the packet data is located in the serving RNC, which also handles the connection for the particular user to the core network. With the introduction of HS-DSCH, additional intelligence in the form of an HSDPA Medium Access Control (MAC) layer is installed in the Node B. This way, retransmissions can be controlled directly by the Node B, leading to faster retransmission and thus shorter delay with packet data operation when retransmissions are needed. Following figure presents the difference between retransmission handling with HSDPA and Release ’99 in the case in which the serving and controlling RNCs are the same. In the case where no relocation procedure is used in the network, the actual termination point could be several RNCs further into the network. With HSDPA, the Iub interface between Node B and RNC requires a flow control mechanism to ensure that Node B buffers are used properly and that there is no data loss due to Node B buffer overflow. The MAC layer protocol in the architecture of HSDPA can be seen in Fig. 1, showing the different protocol layers for the HS-DSCH. The RNC still retains the functionalities of the Radio Link Control (RLC), such as taking care of the retransmission.

UMTS Evolution


9

TM51107EN03GLA011 © Nokia Siemens Networks

UE BS RNC

Uu Iub

Packet

RLC: ACK/NACK

Retransmission

UE BS RNC

Uu Iub

Packet

L1: ACK/NACK

Retransmission

Rel ’99 DCH/DSCH

Rel 5 HS-DSCH

Fig. 2 Release ’99 and release 5 HSDPA retransmission control in the network

TM51107EN03GLA01/ 1 © Nokia Siemens Networks

IubBS RNC

Transport

Frame Protocol

Uu

RNC

WCDMA L1

MAC

RLC

Transport

Frame Protocol

MAC

RLC

WCDMA L1

MAC

HSDPA User Plane

Fig. 3 HSDPA protocol architecture

UMTS Evolution

TM51107EN03GLA3


In case the HS-DSCH transmission from the Node B fails after, for instance, exceeding the maximum number of physical layer retransmissions. Although there is a new MAC functionality added in the Node B, the RNC still retains the Release ’99/Release 4 functionalities. The key functionality of the new Node B MAC functionality (MAC-hs) is to handle the Automatic Repeat Request (ARQ) functionality and scheduling as well as priority handling. Ciphering is done in any case in the RLC layer to ensure that the ciphering

mask stays identical for each retransmission to enable physical layer combining of retransmissions.

The type of scheduling to be carried out in Node B is not defined in 3GPP standardization, only some parameters, such as discard timer or scheduling priority indication, that can be used by RNC to control the handling of an individual user. As the scheduler type has a big impact on the resulting performance and QoS, example packet scheduler types are presented in this chapter in the performance section.

1.1.1.3 HSDPA terminal capability and achievable data rates

The HSDPA feature is optional for terminals in Release 5 with a total of 12 different categories of terminal (from a physical layer point of view) with resulting maximum data rates ranging between 0.9 and 14.4Mbps. The HSDPA capability is otherwise independent from Release ’99-based capabilities, but if HS-DSCH has been configured for the terminal, then DCH capability in the downlink is limited to the value given by the terminal. A terminal can indicate 32, 64, 128 or 384 kbps DCH capability, as described in Chapter 6.

The terminal capability classes are shown in Table below (to be reproduced). The first ten HSDPA terminal capability categories need to support 16 QAM, but the last two, categories 11 and 12, support only QPSK modulation. The differences between classes lie in the maximum number of parallel codes that must be supported and whether the reception in every 2 ms TTI is required. The highest HSDPA class supports 10 Mbps. Besides the values indicated in (Table 2), there is the soft buffer capability with two principles used for determining the value for soft buffer capability. The specifications indicate the absolute values, which should be understood in the way that a higher value means support for incremental redundancy at maximum data rate, while a lower value permits only soft combining at full rate. While determining when incremental redundancy can be applied also, one needs to observe the memory partitioning per ARQ process defined by the SRNC. There is a maximum of eight ARQ processes per terminal.

UMTS Evolution


11

Category Maximum number of parallel codes HS-DSCH

Minimum inter-TTI interval

Transport channel bits per TTI

ARQ type at maximum data rate

Achievable maximum data rate (Mbps)

1 5 3 7298 Soft 1.2

2 5 3 7298 IR 1.2

3 5 2 7298 Soft 1.8

4 5 2 7298 IR 1.8

5 5 1 7298 Soft 3.6

6 5 1 7298 IR 3.6

7 10 1 14411 Soft 7.2

8 10 1 14411 IR 7.2

9 15 1 20251 Soft 10.2

10 15 1 27952 IR 14.4

11 5 2 3630 Soft 0.9

12 5 1 3630 Soft 1.8

Table 2 HSDPA terminal capability categories

Category number 10 is intended to allow the theoretical maximum data rate of 14.4 Mbps, permitting basically the data rate that is achievable with rate 1/3 turbo coding and significant puncturing, resulting in the code rate close to 1. For category 9, the maximum turbo- encoding block size (from Release ’99) has been taken into account when calculating the values, thus resulting in the 10.2Mbps peak user data rate value with four turbo-encoding blocks. It should be noted that, for HSDPA operation, the terminal will not report individual values but only the category. The classes shown in Table 11.3 are as included in [4] with 12 distinct terminal classes. From a Layer 2/3 point of view, the important terminal capability parameter to note is the RLC reordering buffer size that basically determines the window length of the packets that can be ‘in the pipeline’ to ensure in-sequence delivery of data to higher layers in the terminal. The minimum values range from 50 to 150 kB, depending on the UE category.

Besides the parameter part of the UE capability, the terminal data rate can be largely varied by changing the coding rate as well. Table 11.4 shows the achievable data rates when keeping the number of codes constant (15) and changing the coding rate as well as the modulation. (Table 11.4, to be reproduced) shows some example bit rates without overhead considerations for different transport format and resource combinations (TFRCs).

UMTS Evolution

TM51107EN03GLA3


TFRC Modulation Effective code rate

Max throughput (Mbps)

1 QPSK 1 1.8

2 QPSK 2/4 3.6

3 QPSK 2 5.3

4 16 QAM 2/4 7.2

5 16 QAM 1 10.7

Table 3. Theoretical bit rates with 15 multicodes for different TFRCs

These theoretical data rates can be allocated for a single user or divided between several users. This way, the network can match the allocated power/code resources to the terminal capabilities and data requirements of the active terminals. In contrast to Release ’99 operation, it is worth noting that the data rate negotiated with the core network is typically smaller than the peak data rate used in the air interface. Thus, even if the maximum data rate negotiated with the core network was, e.g., 1Mbps or 2Mbps, the physical layer would use (if conditions permit) a peak data rate of, e.g., 3.6Mbps.

UMTS Evolution


13

1.1.1.4 HSDPA Performance

Since the two most basic features of WCDMA, fast power control and variable SF, have been disabled, a performance evaluation of HSDPA involves considerations that differ some what from the general WCDMA analysis. For packet data traffic, HSDPA offers a significant gain over the existing Release ’99 DCH and DSCH bearers. It facilitates very fast per-2 ms switching among users, which gives high trunking efficiency and code utilization for bursty packet services. Further, with the introduction of higher order modulation and reduced channel encoding, even very high radio quality conditions can be mapped into increased user throughput and cell capacity. Finally, advanced packet scheduling, which considers the user’s instantaneous radio channel conditions, can produce a very high cell capacity while maintaining tight end-to-end QoS control. In the following sub-sections, single user and multiuser issues are discussed separately. After this description, some examples of HSDPA system performance are given, looking first at the system performance in the ‘all HSDPA users’ scenario and then looking at the situation when operating the system in emigration phase, where a large number of terminals do not yet have HSDPA capability.

The HSDPA mode of operation encounters a change in environment and channel performance by fast adaptation of modulation, coding and code resource settings. The performance of HSDPA depends on a number of factors that include the following:

• Channel conditions: Time dispersion, cell environment, terminal velocity as well as experienced own cell interference to other cell interference ratio (Ior/Ioc). Compared to the DCHs, the average Ior/Ioc ratio at the cell edge is reduced for HSDPA owing to a lack of soft handover gain. Macro cell network measurements indicate typical values down to 5 dB compared to approximately 2 to 0 dB for DCH.

• Terminal performance: Basic detector performance (e.g. sensitivity and interference suppression capability) and HSDPA capability level, including supported peak data rates and number of multicodes.

• Nature and accuracy of radio resource management (RRM): Power and code resources allocated to the HSDPA channel and accuracy/philosophy of Signal to Interference power ratio (SIR) estimation and packet scheduling algorithms.

For a terminal with high detection performance, some experienced SIR would potentially map into a higher throughput performance experienced directly by the HSDPA user.

UMTS Evolution

TM51107EN03GLA3


1.1.2 IMS

The functional groups in a UMTS Network which have been discussed so far—UE, UTRAN, PS Domain and CS Domain—together provide the user with well-controlled connectivity, i.e. secure connectivity with QoS and mobility support. UMTS, however, is not just about connectivity.UMTS is about user services. This is where the IMS comes in. The IPMultimedia Subsystem (IMS) is a general platform that supports the delivery of IP-based multimedia services.

It is important to note that the IMS does not necessarily deliver the multimedia services itself. It mainly supports their delivery. It is easy to see why service support is crucial.

The previous generation of mobile Telecommunication Networks integrated tightly the services they delivered because of the technical requirements (e.g. telephony). UMTS thus abstracts from the

service, and provides service support, e.g. finding the IP address of the communication partner, and negotiating the codec. This way UMTS is somewhat flexible with regard to the services it delivers, and it is accessible to services that may be defined in the future. The services may be offered by the UMTS operator or by third party operators.

This flexibility, however, goes further. From a 3GPP perspective, the IMS can be accessed via the PS Domain. It can, however, also be accessed from other IP Networks. This means that the IMS must not employ solutions that rely on PS Domain specifics.

To summarize, 3GPP aims to align the delivery of IMS-based multimedia services wherever possible with the delivery of general IP-based services. Therefore, the general approach for the IMS is to adopt non-3GPP specific solutions, in particular IETF Protocols.

In this part, we will first look in more detail at the service support which the IMS provides. We will then cover the main architectural element and the relevant protocols.

IMS service Support

What does it mean to support service delivery? Support starts with locating the service. Users should not have to worry about the IP address through which a service can be obtained. The IMS finds the IP address for them. Similarly, when a service (e.g. IP telephony or video conferenc-ing) involves several users, they should not have to deal with the problem of finding each other’s current IP addresses. Users should have a menu from which they choose service and communication partners, and from then on the set-up, maintenance and tear-down of the communication session is dealt with by the IMS. Beyond locating services and users, this involves the authorization of users, the negotiation of codecs, ports and QoS, as well as, of course, charging. This charging is coordinated with that performed by the PSDomain so that, in the end, a single bill is delivered.

UMTS Evolution


15

Of course, for many services, an Application Server is necessary in addition to service support, e.g. a video streaming server. Such servers can be located inside or outside the IMS. In any event 3GPP is not responsible for specifying the services themselves.

1.1.2.1 Basic service support

The service support described above can be broken down into several sub-problems. The most basic problem is the following: a user would like to set up a communication session with an Application Server or another user. She knows the public identifier of the communication partner (e.g. a phone number), but does not know its current availability, location, IP address and so forth. The basic IMS architecture contains network elements called Call State Control Functions (CSCFs) that help resolve the public identifier into the currently preferred IP address. Furthermore,CSCFs support the user in determining other communication parameters that must be fixed before a session can start, e.g. ports, QoS and codecs.

Another basic service support feature provided by the IMS is a network element transcoding between codecs and a server supporting multi-party conferencing.

1.1.2.2 Advanced service support

Basic service support, as described above, is covered by the first release of the IMS in Rel-5. The subsequent releases of UMTS add a number of additional features. However, service support for mobile networks in general, including UMTS, is the responsibility of another organization, the Open Mobile Alliance (OMA). For example, digital rights management or Push-to-talk services are specified by OMA rather than by 3GPP.

Brief examples of advanced service support standardized by 3GPP are shown as following:

Presence Service:

The Presence Service [3GPP 23.141] provides the infrastructure for informing other users about one’s availability. For example, a user can set as default that she becomes available for communication sessions when she switches on her mobile device. However, the Presence Service also allows for the implementation of more complicated rules, e.g. “when I am in a meeting I am only reachable by email, except when it is an emergency call from my family”, or “When travelling I cannot receive video conferences”.

Instant Message Service

An Instant Message Service allows a user to send a message to another user in virtually real-time. Instant Message Services are popular today, and support of this feature was integrated into the IMS from the start [3GPP 23.228]. Of course, the InstantMessage Service can use the Presence Service to determine whether the receiver of the message is available.

UMTS Evolution

TM51107EN03GLA3


Push Service

The Push Service allows for the pushing of information from the network to the user without prior user action. Such information could include notification that mail has arrived, charging information, or—affording interesting business opportunities—advertisements. Work on the Push Service was abandoned for some time but has been taken up again lately.

1.1.2.3 Architecture

The basic architecture of the IMS is shown in following figure. This Figure also shows how IMS network elements interact with the network elements introduced in previous chapters.

UMTS Evolution


17

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


GSM/UMTS Core Network

GSM

UTRAN

GERAN

CS-MGW MGWIP/ATM

MSC-S

GMSC-S

SGW

PSTN/ISDN

SGSN SGSNIP

IP

CS-GW

CSCF

MRF

Internet

CSCF

HSSApplication Server

HLR

CS Domain

PS Domaincontrol

traffic

To SGSN, MSC-S, GMSC-S To CSCF, SGSN,

MSC-S, GMSC-S

Nb

Mc

Nc

Mc

GnGi

Mr

Mg

Mm

Go

Mw

Cx

SIP to UE via connectivity service

SIP

SIP

SIP

COPS

Fig. 4 Basic logical architecture of IMS

UMTS Evolution

TM51107EN03GLA3


The most important network element in the IMS is the CSCF. A CSCF is responsible for controlling and policing multimedia services. When a UE wishes to use amultimedia service, it contacts a CSCF via the Gm interface—Gm is of course a logical interface; the physical connectivity is provided via UTRAN and PSDomain and this is the path which packets take. CSCFs come in three flavors, Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) and Interrogating CSCF (I-CSCF), whose different roles will be explained in Chapter 15 on Session Control. CSCFs need access to a central user-database in the UMTS Network, e.g. in order to authorize a user.

To this end, the HLR is extended and henceforth becomes the Home Subscriber Server (HSS).

(Figure 3) shows several paths for user traffic from GGSN to external networks via the Gi interface. From bottom to top, there is

(a) A direct path, not involving IMS services.

(b) A path utilizing CSCF services only.

(c) A path utilizing additional IMS services, in this case a media service for, e.g. multimedia conferencing or transcoding. Media services are supported by a Media Resource Function which is split into a control node (Media Resource Function Controller or MRFC) and a user traffic transport node (Media Resource Function Processor or MRFP).We therefore find that the division of a network element into a control plane-node and user-plane node which was first exercised in the CS Domain has been taken up in the IMS.

(d) A path involving a gateway that allows for accessing an external circuit switched network, e.g. a PSTN. By means of this path it is possible for a user to make or receive IP-telephony calls to or from a circuit-switched network. The gateway enabling the translation is also split into a user-plane node (the Media Gateway or MGW) and a control-plane node (the Media Gateway Control Function or MGCF). The MGCF also translates the SS7 ISUP protocol into SIP. Additionally, a Signaling Gateway (SGW) is introduced for translating the signaling bearer, i.e. MTP or ATM, into IP. The Breakout Gateway Control Function (BGCF) selects the appropriate network to interwork with.

An essential network element in (Figure 10.1, same as above) is of course the Application Server (AS) which provides the actual multimedia services. The AS can be operated by a third party and is then located outside the IMS. It can also be operated by the operator of the UMTSNetwork, in which case it is located in the IMS and can have an interface to the HSS.

(Figure 10.1, same as above) shows the basic architecture only. The IMS can be home to a rather large number of additional nodes with specialized functionality, e.g. to support Presence Services or Push Service. These nodes will be introduced later as needs be.

UMTS Evolution


19

1.1.2.4 CSCF

CSCFs are the main control nodes in the IMS. When a user wishes to utilize IMS services, he registers with a CSCF using his Public User Identity. This identity is stored on the ISIM application of the UICC and takes the form of a Uniform Resource Identifier (e.g. sip:[email protected] [RFC 2396] or tel:þ49-30-1234567 [RFC 2806]). Somebody trying to contact Arthur the phone number þ49-30-1234567 can use the CSCF infrastructure to locate the corresponding UE and set up a communication session. CSCFs thus perform the following tasks:

• Security: The CSCFs authorize UEs and their users based on subscription information which is stored in the HSS.

• Session control: The CSCFs support session establishment, maintenance and tear-down as described above.

• QoS: The CSCF, particularly the P-CSCF, collaborates with a Policy Decision Function (PDF) to authorize the QoS a user may reserve for a session. Via the Gq and Go interface the GGSN is instructed which QoS a user may reserve for a particular session. The GGSN only admits the corresponding PDP Context when its QoS matches this target.

• Charging: CSCFs collect charging-relevant information such as the start and stop time of a service and send it to a charging gateway.

Note that the CSCF is a pure control node. It does not transport user traffic.

UMTS Evolution

TM51107EN03GLA3


1.1.2.5 IP connectivity access network

Extensive access-independence is an important feature of the IMS; its services cannot only be used from the PS Domain but also from other IP Networks called IP Connectivity Access.

Networks (IP-CANs) are illustrated in following figure. Of course, this means that the IMS is designed so that it makes few assumptions about the nature of the access.

This design allowed, e.g. ETSI to standardize access to the IMS from fixed Telecommunication Networks, and CableLabs, a consortium of cable operators-who were originally known as offering cable TV, to standardize access to the IMS via cable.

UMTS Evolution


21

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


3GPP IP-CAN

UTRAN PS DomainUE

IMSOther Mobile IP-CANMS

Fixed IP-CANFixed Host

Fig. 5 Access to the IMS from IP-CANs

UMTS Evolution

TM51107EN03GLA3


1.1.2.6 Protocols

The general approach for the IMS is to adopt non-3GPP specific IP-based solutions. In particular, the IMS employs IETF Protocols that are also employed outside UMTS. However, as the IMS had some requirements that went beyond what was available, 3GPP and IETF collaborated in order to provide extensions to existing protocols.

1.1.2.6.1 User-Plane

The protocol stack of the IMS user-plane is rather simple, namely IP together with a transport layer protocol (e.g. TCP, UDP) as appropriate. For real-time applications, the Real Time Protocol (RTP) [RFC 3550] is stacked on top of UDP. RTP adds an additional header containing a time stamp which allows the receiver to play the packets at the right point in time, in other words to remove the jitter which the IP Network may have introduced. RTP is always employed together with the Real Time Control Protocol (RTCP) which delivers monitoring data on QoS and reports on how data was received.

1.1.2.6.2 Control-Plane

The structure of the IMS control-plane is somewhat different from the structure of the PS Domain control-plane (and very different from the structure of the CS Domain control-plane).

The IMS in fact illustrates a convergence of Telecommunication Networks and the Internet.

The IMS control protocol stack consists of a limited number of IETF Protocols. These protocols are specific to the functionality they carry out, as in a Computer Network; they are not specific to the communicating network elements, as in the PS Domain. Furthermore, the IMS control protocols run over a generic IP protocol stack, i.e. UDP/IP or TCP/IP, as the case may be.

Therefore, the illustration of the IMS control-plane depicts only the actual control protocol for each reference point, rather than entire protocol stacks.

The main protocol in the IMS is the Session Initiation Protocol (SIP) [RFC 3261] which is utilized for session control between UE, CSCFs, AS and other control nodes (e.g. MRCF and

MGCF). Diameter is the protocol for authentication and authorization between HSS and CSCFs. QoS control between CSCF and GGSN is performed by the Common Open Policy Service Protocol (COPS) or Diameter. Finally, control-plane nodes control their corresponding user-plane nodes with the MEGACO protocol.

UMTS Evolution


23

2 Release 6

UMTS Evolution

TM51107EN03GLA3


Rel-6 was published in 2005. It is also a major release featuring, among others, the

following:

IMS supporting services

The specification of services for mobile networks is the responsibility of the Open Mobile Alliance (OMA). 3GPP therefore standardized only a small number of supporting services, e. g. Push Service, Instant Message Service and Presence Service.

I-WLAN

A trusted WLAN Access Network is defined as alternative access to the 3GPP Core Network. The WLAN and 3GPP Core Network communicate with each other using standard IETF Protocols. The I-WLAN, however, is neither architecturally nor functionally equivalent to a UTRAN or GERAN. For example, the I-WLAN does not support mobility.

GAN

The goal of GAN is to attach a generic IP-based Access Network to the 3GPP Core Network via the A/Gb interface. This is achieved by using an additional network element, masking the GAN to the Core Network. A number of 3GPP-specific protocols is employed to this end. Functionally and architecturally, a GAN is equivalent to a GERAN.

Update of the charging architecture

A harmonized charging architecture was introduced for bearer-, subsystem- and service- level. Pre-Rel-6, for each level and each domain an independent charging architecture had been developed.

Flow-based Charging

Until the advent of Flow-based Charging, charging is only possible with the resolution of a bearer: when two or more service-level flows utilize the same bearer, they cannot be differentiated. Flow-based Charging supports service-specific charging on the bearer-level of any resolution and, furthermore, allows for the coordination of charging on the bearer subsystem- and service-levels.

High Speed Uplink Packet Access

High Speed Uplink Packet Access (HSUPA) extends the downlink HSPA from Rel-5 by adding a dedicated uplink channel with bandwidth up to 5.76Mb/s—since uplink a sufficient number of codes has been available, there is no need to introduce shared channels. HSUPA in Rel-6 is, however, specified only for FDD.

UMTS Evolution


25

Multimedia Broadcast Multicast Service

As we already know, UMTS designers are somewhat concerned about saving resources on the radio interface. In scenarios such as multicast of sport events, multi-party conferencing or broadcast of emergency information it may happen that several UEs in a cell receive the same data stream. The Multimedia Broadcast Multicast

Service (MBMS) [GPP 23.246] enables a resource efficient data transfer to many UEs in parallel: by means of an additional network element in the Core Network and new protocols, the data is sent only once to each cell and all UEs access the same channel for receiving it.

Most of Rel-6 is currently in the trial phase. The exception is HSUPA of which a number of networks have already been deployed.

UMTS Evolution

TM51107EN03GLA3


2.1 Multimedia Broadcast Multicast Service (MBMS)

A new service introduced in 3GPP Release 6 specifications is Multimedia Broadcast Multicast Service (MBMS). There are two high level modes of operation in MBMS:

• Broadcast mode, which allows sending audio and video. The already existing Cell Broadcast Service (CBS) is intended for messaging only. The broadcast mode is expected to be a service without charging and there are no specific activation requirements for this mode.

• Multicast mode allows sending multimedia data for the end users that are part of a multicast subscription group. End users need to monitor service announcements regarding service availability, and then they can join the currently active service. From the network point of view, the same content can be provided in a point-to-point fashion if there are not enough users to justify the high power transmission. A typical example in 3GPP has been the sport results service where, for example, ice hockey results would be available as well as video clips of the key events in different games of the day. Charging is expected to be applied for the multicast mode.

From the radio point of view, MBMS is considered an application independent way to deliver the MBMS User Services, which are intended to deliver to multiple users simultaneously. The MBMS User Services can be classified into three groups as follows:

1. Streaming services, where a basic example is audio and video stream;

2. File download services;

3. Carousel service, which can be considered as a combination of streaming and file download.

In this kind of service, an end user may have an application which is provided data repetitively and updates are then broadcast when there are changes in the content.

For MBMS User Services, an operator controls the distribution of the data. Unlike CBS, the end user needs first to join the service and only users that have joined the service can see the content. The charging can then be based on the subscription or based on the keys which enable an end user to access the data. The MBMS content can be created by the operator itself or by a third party and, as such, all the details of what an MBMS service should look like will not be specified by 3GPP, but left for operators and service providers. One possible MBMS high level architecture is shown in (Figure 5), where the IP multicast network refers here to any server providing MBMS content over the Internet.

UMTS Evolution


27

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


MBMS content and service announcements

BS

UE

UE

RNC SGSNIP Multicast

Network

UEs receiving MBMS announcements and/or MBMS content

Fig. 6 Example MBMS high level architecture

UMTS Evolution

TM51107EN03GLA3


The data rates range is from the 10 kbps text-based information to the 384 kbps video distribution on MBMS. The codecs are expected to be the current ones – such as AMR for voice – to ensure a large interoperability base for different terminals for the services being provided.

Depending on the number of users that have joined to receive the content via the MBMS, the network can select whether to use point-to-point or point-to-multipoint transmission. In the former case, DCH is used as the transport channel (or should be used) and in the case where several UEs want to receive the same service, FACH is used as the transport channel in a particular cell for the MBMS content. On the physical layer, the FACH is mapped on S-CCPCH and DCH respectively of the DPDCH.

In the case of point-to-point connection, the logical channel can be DCCH or DTCH with all the mapping in Release ’99 possible. For the point-to-multipoint case, there are two new logical channels, namely:

• MBMS point-to-multipoint Control Channel (MCCH), which carries the related control information; MBMS point-to-multipoint Traffic Channel (MTCH), which carries the actual user data.

UMTS Evolution


29

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


MBMS p-t-p control

MBMS p-t-m

Radio Bearer Setup

UE CRNC SRNC

Uu Iur

Decision to move to point-to-point connection: Iur signaling for CRNC

Radio Bearer Setup Complete

MBMS data p-t-p

Fig. 7 MBMS point-to-point and point-to-multipoint transmissions

UMTS Evolution

TM51107EN03GLA3


The UTRAN shall decide, based on the number of UEs in a particular cell, which mode of MBMS operation to use, and if the situation changes, the network can transfer the UEs between different states of MBMS reception. Typically, there need to be more than just a few UEs to receive the same content in order to make the use of a broadcast channel without power control efficient enough.

As the MBMS content flow may vary, MBMS-specific paging can be used to save the terminal power. The bits not used in Release ’99 on the Paging Indicator Channel (PICH), can be used for MBMS purposes to prevent UEs from continuous FACH decoding.

As such, the MBMS does not cause direct changes to the physical layer. There are, however, a few items to note. MBMS data can be detected with selective combining. The physical layer is not impacted as this is based on selection in the RLC layer and a UE may decode the MBMS data from a new cell quickly, assuming the UTRAN provides on the MCCH the MBMS neighboring cell information to allow the UE the necessary details for decoding the data from the other cell if the same service was provided there. Otherwise, UE would need to wait until related information was broadcast in the new cell, and only then determine whether the same service could be continued there or not.

In 3GPP standardization, the issue of whether there should be additional channel coding (outer coding) for extra protection of MBMS data was also discussed. It was decided, however, that at most there could be some application level added protection to tolerate frame losses due to mobility and other challenges related to non-power controlled point-to-multipoint transmission.

UMTS Evolution


31

2.2 WLAN

Traditionally, mobile Telecommunication Networks have had their own, specific, Radio Access Network. The early releases of UMTS already exhibited some flexibility in that a

3GPP Core Network can modularly connect to any 3GPP-standardized RAN, i.e. UTRAN and GERAN.

With Rel-6, 3GPP is breaking new ground: it introduces greater flexibility by specifying how a UE can access the 3GPP Core Network via a WLAN Access Network.

The rational for integrating WLAN as an Access Network into the 3GPP System is, of course, the potential for creating operator revenue.

• On the one hand, by 2006 WLAN hotspots had become commonplace. In fact, many 3GPP operators that run a 3GPP System have themselves entered the WLAN hotspot market. However, they usually operate WLAN and UMTS as independent networks. It is of course desirable to create synergies by sharing the subscriber base and by allowing subscribers to move between the two network types.

• 3GPP operators can also benefit from interworking with WLAN hotspots operated by third parties. For example, new customers can be gained when users of a WLAN hotspot can access the 3GPP System directly, e.g. for using IMS services, without additional bureaucratic overhead.

• Furthermore, WLAN equipment costs less than UMTS equipment, both in purchase price and in operation. It is therefore advantageous for 3GPP operators to extend their coverage with WLAN Access Networks, in areas where the virtues of a UTRAN—seamless handover and QoS support—are not so important or too expensive.

Interestingly, 3GPP developed two independent solutions for WLAN integration: Interworking WLAN (I-WLAN) and Generic Access Network (GAN), the latter also known as Unlicensed Mobile Access (UMA). In fact, GAN is not only applicable to WLAN but also to any wireless broadband IP-based Access Network or Radio Access Network, e.g. Bluetooth

UMTS Evolution

TM51107EN03GLA3


2.2.1 Interworking WLAN

Work on I-WLAN started in the 3GPP SA1 working group with a feasibility study [3GPP22.934]. Six consecutive interworking scenarios were defined, each building on the one preceding it and each being more powerful than the one before. The idea was to define an evolutionary path from the isolated co-existence of WLAN and 3GPP technology to fully seamless system interoperation. The technical solution for interworking should not affect the

WLAN specification; it is only a 3GPP issue.

1st Scenario—Common billing and customer care

In this scenario, the user has a single subscription that enables her to access independently both the 3GPP PLMN and a (set of)WLAN hotspot(s)—she can access the Internet from the

WLAN, but she cannot access the 3GPP network. However, she receives a single bill covering both 3GPP and WLAN usage. In other words, in this scenario the only relation between the 3GPP System and the WLAN is that they share subscribers. Since billing is outside the scope of 3GPP, the support of this scenario does not require any update of a 3GPP specification.

2nd Scenario—3GPP-based access control and charging

In this scenario, the subscriber also has a single subscription for both a 3GPP PLMN and WLAN hotspots. As in the 1st scenario, she accesses the 3GPP PLMN and the WLAN hotspots independently and it is not possible to use 3GPP services when being attached to a WLAN. However, subscriber information is stored exclusively in the 3GPP Core Network.

Consequently, when the subscriber accesses a WLAN hotspot, the authentication and authorization information is pulled from the 3GPP network. Charging is also performed in the 3GPP network. For the WLAN operator and the 3GPP operator, the advantage of this scenario is that subscriber handling is simplified.

3rd Scenario—Access to 3GPP packet-switched services

This scenario builds on the first two scenarios, and also allows the UE to set-up a bearer to the PS Domain for accessing packet-based services in the 3GPP System, e.g. IMS services. It is, however, not yet possible to handover from the WLAN access to the UTRAN.

4th Scenario—Service continuity

This scenario additionally supports handover between the WLAN and UTRAN: services, e.g. a streaming video service, continue to work after the handover; they do not need to be set-up again. However, the handover does not need to be seamless and might be noticeable to the subscriber.

UMTS Evolution


33

5th Scenario—Seamless service

With this scenario, the handover between WLAN and UTRAN becomes seamless for packet- based services.

6th Scenario—Access to 3GPP circuit-switched services

This last scenario adds access to CS-Domain supported services from theWLAN––without, of course, implementing circuit-switched technology in the WLAN. For circuit-switched services, handover between WLAN and UTRAN will also be seamless. We thus see how each scenario offers more functionality than the previous one. The document [3GPP 22.934] describes the scenarios and is of course just a feasibility study. For

I-WLAN, 3GPP has provided technical specifications for comparatively simple scenarios only: in Rel-6, the 2nd Scenario and 3rd Scenario are included. Further scenarios, e.g. mobility between heterogeneous access systems, are only included in Rel-8 when the topic is approached in a much more general fashion.

2.2.1.1 WLAN architecture

Let us look at the relation between I-WLAN hotspot and the 3GPP System in more detail. The I-WLAN hotspot accepts all users that are authenticated by the 3GPP System. Users are charged by the 3GPP System, and the I-WLAN operator is reimbursed by the 3GPP operator: one might say that the I-WLAN hotspot and the 3GPP PLMN have a kind of roaming relationship, with the I-WLAN hotspot in the role of a VPLMN. However, this analogy has a shortcoming: the I-WLAN is an Access Network; it is not a full PLMN.

Therefore, when an I-WLAN is interworking with a 3GPP System, some core network functions must be performed in the 3GPP System. In any event, we may safely assume that an I-WLAN has a long-term relationship of trust with the 3GPP System involving a shared secret and a secure tunnel.

Of course, the I-WLAN has a relationship of trust only with one or two 3GPP PLMNs—we exclude the case that has no relationship of trust at all as not being relevant for our discourse.

This means, from the UE’s perspective, that we can have either of the two situations, illustrated in (Figure 18.1, to be reproduced):

Non-roaming case

A UE has a subscription with PLMN A, its HPLMN. The I-WLAN happens to have a relationship of trust with the same PLMN A. Thus, when the UE accesses the I-WLAN, authentication information is pulled directly from the HPLMN.

Roaming case

The UE has a subscription with PLMNA as before. The I-WLAN, however, has a relationship of trust with another PLMN B. When the UE accesses the I-WLAN, the authentication information must thus be pulled from the PLMN A via PLMN B. Of course, this is only possible if the two PLMNs have a Roaming Agreement.

UMTS Evolution

TM51107EN03GLA3


2.2.1.2 I-WLAN basic functionality

The steps for a UE from choosing to attach to an I-WLAN to being able to send the first packet are analogous to the steps a UE performs when connecting to a UMTS network:

• The UE establishes WLAN radio connectivity using the WLAN this step is analogous to RRC Connection set-up.

• The UE discovers that it can use its 3GPP Systems subscription to access theWLAN. While 3GPP does not yet provide a mechanism for this, the IEEE is working on this problem and expects to publish the corresponding amendment as 802.11u in 2009.

• .The UE authenticates with the AAA Server in its HPLMN using an IETF-standardized

• procedure, along the lines discussed in Chapter 13, Section 13.5.1.2.TheUEthen receives an IP address from the I-WLAN. This IP address is called the UEs local IP address. The UE can now access the Internet via the WLAN according to 2nd Scenario—this step is analogous to GPRSAttach, except that a GPRS-attached UE does not yet have an IP address and cannot access the Internet

• . For the 3rd Scenario, the UE must also set-up a bearer to the 3GPP Core Network: the UE locates the PDG via a DNS query. It then uses IKE to establish a SecurityAssociation with the

• PDG in order to establish the IPsec tunnel between UE and PDG. In the course of this procedure, the UE and PDG also authenticate each other. The PDG additionally pulls authorization information from the AAA Server, and pulls an IP address from, e.g., a DHCP server. This IP address it allocates to the UE as the remote IP address. The remote IP address is used for the packets inside the IPsec tunnel, to access packet switched services. This final step is analogous to PDP Context establishment. We may observe how the I-WLAN mechanisms defined by the IEEE and IETF Protocols are combined to rebuild UMTS functionality.

UMTS Evolution


35

2.2.1.3 I-WLAN mobility

The mobility of the UE—beyond WLAN link-layer mobility is not covered up to Rel-7. For the upcoming Rel-8, mobility between IWLAN and a 3GPPSystem is specified for pre-Rel-8 3GPP architectures [3GPP 23.327]. Indeed, Rel-8, which already prepares 4G, includes major architectural updates and solves the mobility problem more fundamentally, for the Access Networks of any technology. That includes the Access Network Discovery and Selection, Handover and the “Optimized” Handover.

2.2.1.4 I-WLAN security

The authentication scenario follows the usual WLAN procedure: the authentication is between the UE (the Supplicant), the I-WLAN Access Point (the front end) and the AAA Server (the back end), with possibly an AAA Proxy Server in-between. The identifier which the UE presents to the AAA Server is a Network Access Identifier (NAI) just as for the IMS. A NAI has the format user@realm, with “user” containing the IMSI of the subscription. Since “realm” identifies the subscribers HPLMN, an AAA Proxy Server is able to find the appropriate AAA Server.

The back end protocol between I-WLAN Access Point and AAA Server is RADIUS or Diameter, encapsulating EAP with the EAP-AKA authentication method. In other words, the actual authentication method between UE and 3GPP System is always AKA, independent of whether the UE attaches via UTRAN or via I-WLAN.

2.2.1.5 I-WLAN QOS

The original access via I-WLAN in Rel-6 is without QoS support. However, for Rel-7, 3GPP gave some thought to how to guarantee QoS in the 3rd Scenario; by contrast, the 2nd Scenario only provides Internet access, in which case QoS support is not considered important.

The proposal is to signalQoS between PDG and UE using DiffServCode Points (DSCPs) in the tunnel external IP header. Presumably, the routers along the path are DiffServ-enabled.

The DSCP information can also be used to provide link-layer QoS on the WLAN air interface.

UMTS Evolution

TM51107EN03GLA3


2.2.1.6 I-WLAN charging

The charging solution for the I-WLAN [3GPP 32.353] follows the same principles and architectures as charging for 3GPP Systems in general. In particular, both offline and

online charging is supported. We discuss only the location of the CTFs, the entities collecting Charging information and the choice of correlation identifiers.

In the 1st Scenario, the I-WLAN sends CDRs to the Billing System. In the 2nd Scenario, the I-WLAN collects per-user Charging information. In the 3rd Scenario, bearer-level charging is performed.

CTFs are located as follows:

• One CTF is assumed to be in the I-WLAN itself, but 3GPP does not determine where exactly the CTF resides in the I-WLAN. As Charging information, it collects uplink and downlink data volumes as well as—in the case of the 3rd Scenario-the duration of a bearer. Since 3GPP aims to specify the I-WLAN so that all 3GPP-specifics are located in the 3GPP System, the IETF-specified architecture and IETF Protocols are employed to report Charging information: The I-WLAN CTF reports to the AAA Server, or AAA Proxy Server in roaming scenarios, using the RADIUS or Diameter protocol. The AAA Server is located in the 3GPP System, and acts as a proxy for the I-WLAN CTF, interfacing with the online and offline charging systems. Note that the support of online charging—with its credit-control features—requires a special RADIUS extension, the RADIUS prepaid extension, to be implemented between the I-WLAN CTF and the (Proxy) AAA Server.

• Another CTF is located in the PDG—applicable only in the 3rd Scenario. The PDG can also meter the traffic volume and duration of a bearer. Having an additional CTF in the PDG allows for differentiating the 2nd Scenario from the 3rd Scenario traffic: only the 3rd Scenario, traffic passes the PDG. In fact, the PDG supports charging not only with bearer resolution it also supports Flow-based Charging, i.e. it contains a PCEF that receives its charging rules from the PCRF.

It is still a subject of debate whether an additional CTF is assigned to the WAG, e.g. in order to verify the amount of traffic relayed between VPLMN and HPLMN.

Correlation identifiers are necessary for the Billing System to recognize that Charging information generated by different CTFs belongs to the same service usage and the same user.

In the I-WLAN case, both the I-WLAN CTF and the PDG generate a correlation identifier. In the 3rd Scenario, they exchange the identifiers via the AAA Server when the PDG requests authorization of a bearer.

UMTS Evolution


37

2.2.1.7 I-WLAN policy control

Last but not least we look at policy control in the I-WLAN. The general idea of policy control is binding services to bearer; particularly for charging and QoS requests. The general 3GPP policy architecture is applied straightforwardly to the 3rd Scenario of I-WLAN [3GPP 23.203]. The PDG contains a PCEF pulling policies from the PCRF for Flow-based Charging and for QoS control. Note that the PDG thus receives two types of QoS policies: per-subscription QoS authorization policies from the AAA Server, and per-bearer QoS policies from the PCRF. On the basis of these policies, the PDG filters the UEs packets. For example, it may remark the DiffServ markings, i.e. the DSCPs or even drop the packet.

2.3 HSUPA

Following the creation of the Release 5 specifications with HSDPA during the first half of 2002, the next natural direction of interest was to see if something similar could be done for the uplink. The 3GPP Release 6 feasibility study for Enhanced Uplink for UTRA FDD was started in Autumn 2002, with the focus on evaluating potential performance enhancements for the uplink dedicated transport channels. The scope of the study was either to enhance the uplink performance in general, or to enhance the uplink performance for background, interactive and streaming traffic classes. More concretely, the target was to improve the uplink air interface capacity utilization and end user experience by increasing both the cell throughput and the coverage of the higher bit rates in the uplink. For the uplink, increasing the coverage of higher data rates, already now possible, was of greater interest than increasing the theoretical peak data rates. Possibilities for delay reductions in the packet data transmission and in setting up the dedicated connections were also studied. 3GPP concluded the studies in March 2004 and, consequently, a work item was initiated.

The techniques that were studied for enhancing the uplink dedicated transport channels were, for the most part, the familiar ones discussed earlier in this chapter for HSDPA, such as:

• Fast HARQ terminated at Node B;

• Fast Node B based uplink scheduling;

• Higher order modulation.

UMTS Evolution

TM51107EN03GLA3


Unfortunately, the fundamental differences between uplink and downlink data transmission make it impossible simply to introduce the HSDPA solutions in the uplink as they are already seen in the downlink. The key difference between uplink and downlink is the handling of the total transmission power resource. In the downlink direction, the power resource is centralized, while in the uplink, the power resource available for an individual user is limited by the terminal power amplifier capabilities. Thus, it can be claimed that a pure time division approach, which is in place with a maximum data rate in HSDPA, would not make sense in the WCDMA uplink. Further with uplink, the power control operation has much larger dynamics compared to the downlink, where the interference between the codes limits the dynamics, thus giving an occasional ‘free lunch’ for the higher order modulation/ coding as the symbol energy cannot be reduced after a certain point. The benefit from higher order modulation in HSDPA also comes from avoiding channelization code limitations, while uplink, with user-specific scrambling, could utilize more codes and remain with lower order modulation than 16 QAM. Additionally, the power control cannot be abandoned in the case of continuous uplink transmission due to the near–far problem.

Another area requiring specific attention is the operation in soft handover, where the receiving base station in the uplink will vary as a function of the terminal movement and changes in radio conditions.

2.3.1 Fast hybrid ARQ in the uplink

The simple principle of fast HARQ is to allow the Node B to ask for the UE to retransmit the uplink packet if it was not received correctly. Moreover, the Node B can use different methods for combining the multiple transmissions of a single packet, hence reducing the required received Ec=N0 of individual transmissions. An N-channel stop-and-wait HARQ protocol, similar to the one used in HSDPA, is also considered for the uplink. Different HARQ protocols and combining methods with HSDPA were covered earlier in this chapter. The operation of uplink HARQ retransmission in comparison to Release ’99 RLC level retransmission is depicted in following figure.

UMTS Evolution


39

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


UE BS RNC

Uu Iub

Packet

RLC: ACK/NACK

Retransmission

UE BS RNC

Uu Iub

Packet

L1: ACK/NACK

Retransmission

Rel ’99 Uplink DCH

Uplink E-DCH

Correctly Received Packet

Combining of the packets

Fig. 8 Release '99 and Enhanced Uplink retransmission control

UMTS Evolution

TM51107EN03GLA3


With fast HARQ, the BLER target of the first transmission could be significantly higher, as the delay experienced from the retransmission of an erroneously received packet is dramatically reduced when compared to RLC level retransmission. A higher BLER target reduces the UE transmission power required for a given data rate. Hence, for the same cell loading, the cell capacity can be increased. Considering a fixed data rate, lower energy per bit contributes to range improvement as well. There is, however, a penalty in increasing the BLER target too much, since having a large number of retransmissions starts to show in the average delay seen by the UE, even if the peak delay values are not seen very often due to avoidance of RLC retransmission. The effective throughput for a fixed data rate is also reduced with high BLER, as an increasing number of packets are transmitted more than once.

Allowing a large number of physical layer retransmissions makes the RLC level retransmission probability close to zero. This would benefit especially delay and delay variance sensitive services, as the slow RLC retransmissions would be eliminated. If the initial BLER target was already low, e.g. below 10%, the average delay is not reduced that drastically, as most of the transmissions will anyway go through at the first attempt.

However, the maximum delay seen from the case when one or more RLC retransmissions are needed reduces significantly. Hence, maximum delay and delay variance are reduced but the cell capacity and data rate coverage are not affected. Finding a balance between the different parameterization of the HARQ, penalties in the system level and gains in the link

level requires careful study, and it could prove beneficial to set the operating point for the HARQ separately for different kinds of service.

HARQ operation in SHO introduces one additional complexity component not present in HSDPA HARQ. In a CDMA system, the gain from soft handover comes from one Node B receiving a packet correctly, while another Node B is failing in decoding. Hence, one Node B sends a positive acknowledgement to the UE and the other sends a negative acknowledgement. In such a case, the network has received the packet and the UE should not send the same packet again and respectively the HARQ procedure in the Node B with failed packet should recover from this. The RNC needs to ensure the in-sequence delivery to higher layers and to make the selection combining for the packets received from different Node Bs.

An additional problem due to the limited UE power is the possibility of the UE not having enough transmission power to maintain the same data rate for retransmission that was used for the initial transmission.

UMTS Evolution


41

2.3.2 Fast packet scheduling in the uplink

Currently, the uplink scheduling is RNC based, and thus, due to signaling delays, its nature is more statistical than dynamic. The RNC gives the UEs a set of data rates (TFCs) based on the uplink load measurement reports from the Node Bs and traffic volume measurement reports from the UEs. Due to the higher layer signaling required between the nodes, the scheduling delay and scheduling period cannot be very short. To ensure that the uplink remains non-congested all the time, a relatively

conservative data rate allocation approach must be applied. Otherwise, the probability of uplink overload becomes too high.

With the physical layer scheduling in Node B, the scheduling period could be shorter and the physical layer measurement information readily available in Node B could be used as a basis for scheduling. This enables more up-to-date scheduling decisions and, thus, better use of the available uplink air interface capacity.

Significant shortening of the scheduling periods allows for more dynamic control over the uplink air interface capacity. Whenever one UE stops transmitting or reduces its transmission data rate, the freed capacity can quickly and efficiently be allocated to other UEs. The side benefit of this is that the target operating point of the uplink load can be closer to the maximum load level without increasing the probability of overloading the uplink, as the uplink noise rise probability distribution can be made narrower.

2.3.3 Changes to the physical channel structure

The fundamental question in introducing an enhanced dedicated channel in the uplink is, how will the Release ’99 channel structures be affected? The uplink data transmission may remain unchanged and only the signaling may give new requirements to Layer 1. However, it is just as possible that an enhanced dedicated physical data channel will be introduced parallel to existing DPDCH.

Similarly, several options on how to convey the new signaling over the air interface are being investigated, as follows:

• Uplink signaling: The alternatives on the table are to have the signaling embedded on the uplink DPDCH or DPCCH, or to have a separate code channel added, similar to HS-DPCCH with HSDPA.

• Downlink signaling: Similarly, using the DPDCH and DPCCH can be considered, as well as a shared (e.g. similar to HS-SCCH) or separate new dedicated code channel for signaling.

For the downlink, a dedicated code channel is practically out of the question due to code limitations in the downlink. Also, the modification of HS-SCCH needed for HSDPA transmission would not be backwards compatible with Release 5 HSDPA UEs and is most probably out of the question. The more uplink code channels are introduced, the worse the UE peak to average power ratio will grow, so there is a motivation not to let the number of uplink code channels grow without any limits.

UMTS Evolution

TM51107EN03GLA3


2.3.4 Transmission time interval duration

Finally, introducing a shorter Transmission Time Interval (TTI) for uplink is also under discussion. The motivation for the 2 ms TTI introduced for HSDPA downlink was due to the lack of power control being employed for HS-PDSCH transmission. Such motivation is absent in the uplink as disabling uplink power control would reduce the system capacity. The motivation for a shorter TTI in the uplink is mainly due to the possibility of reducing HARQ retransmission delay. The challenge for the 2 ms TTI comes from the resulting uplink range with limited power resources in the terminal. With an equal amount of data in the TTI, it is possible to transmit less energy during 2 ms than 10 ms. Additionally, the interleaving gain is reduced when moving to 2 ms. Thus, even if shorter TTIs were used, for the cell edge operation, the use of 10 ms TTI will be part of the specification.

UMTS Evolution


43

3 Release 7

UMTS Evolution

TM51107EN03GLA3


Rel-7 was published at the end of 2007. Among others, the following features are part of Rel-7:

PCC

Whereas in previous releases, the authorization of QoS in the PS Domain by the IMS and Flow-based Charging relies on an independent mechanism, Policy and Charging Control (PCC) provides a single policy infrastructure in order to handle both kinds of policies. Furthermore, PCC is applicable to any IP-CAN, and to any service network.

Together with the introduction of PCC, the COPS protocol between GGSN and PCF/PCRF was abandoned and replaced by Diameter.

• HSPAþ

This is an enhancement of the HSPA technology, in particular towards higher

bandwidth—

28Mb/s downlink and 11Mb/s uplink. This is achieved by employing 16-QAM and

MIMO.

HSUPA for TDD The specification of HSUPA has been extended to also work with TDD.

IMS support of UEs behind NATs

The original 3GPP idea is that of the UE as a single piece of equipment connected directly to the RAN. Of course, it is also possible for the subscriber to set-up a home network of devices, e.g. laptop and mobile phone, and to facilitate UMTS Network access for all devices via the mobile phone. In this case the UE consists of several pieces of equipment and one UICC.

What is more, the subscriber may install a Network Address Translator (NAT) and a firewall between the UE and the UMTSNetwork. The NAT separates the address spaces of the subscriber’s home network and UMTS Network: In the home network a private address space is used, while towards the outside, the IP address assigned by the GGSN is employed.

In other words, the NAT translates the IP address and may be even the port number of any packet traversing it.

NATs are known to create considerable problems in cases where the IP address, respectively the port number, appears in “unexpected” places, i.e. somewhere else than in the IP header, respectively the transport header: the NAT cannot translate them. For example, the payload of a SIP signaling message can contain the IP address of the originator of a session. AUE behind a NAT is not aware of its outside IP address and would of course include its local IP address. As a result, the recipient of the SIP message is unable to contact the UE.

UMTS Evolution


45

3GPP specifies two solutions for this problem. One solution is employing an Application Level Gateway (ALG), as defined in [RFC 2663], co-located with the P-CSCF. The ALG performs deep packet inspection and has application-specific knowledge that allows it to translate appropriately, e.g. IP addresses in session descriptions, possibly in interaction with the NAT.

Alternatively, the Session Traversal Utilities for NAT (STUN) [ID STUN] is employed. The STUN specification includes a STUN Server in the external network—the IMS in our case—which the entity behind a NAT—the UE in our case—can query in order to learn its external address. This allows the UE to include right away the correct address in its session description. Of course, the UE must be aware that it is supposed to contact the STUN Server.

UMTS Evolution

TM51107EN03GLA3


UMTS Evolution


47

4 Release 8 Concurrently with the work on Rel-7, 3GPP is concentrating on feasibility studies for its next Rel-8. Rel-8 will contain a major update of the 3GPP architecture and the radio interface, known as Evolved Packet System (EPS) or Long Term Evolution/System Architecture

Evolution (LTE/SAE). Rel-8 will move the 3GPP System towards 4G. The EPS architecture will support multiple Access Networks, of both the 3GPP and the non- 3GPP variety, including mobility between these Access Networks. The EPS air interface will support peak data rates of 100Mb/s downlink, and 50Mb/s uplink. Simultaneously, the architecture and protocols will be simplified, and IETF Protocols will play a major role. Of course, backwards compatibility with the existing 3GPP System must be maintained. We can thus look forward to an interesting balancing act.

UMTS Evolution

TM51107EN03GLA3


UMTS Evolution


49

5 LTE Long Term Evolution (LTE) is the next step forward in cellular 3G services. Expected in the 2008 time frame, LTE is a 3GPP standard that provides for an uplink speed of up to 50 megabits per second (Mbps) and a downlink speed of up to 100 Mbps. LTE will bring many technical benefits to cellular networks. Bandwidth will be scalable from 1.25 MHz to 20 MHz. This will suit the needs of different network operators that have different bandwidth allocations, and also allow operators to provide different services based on spectrum. LTE is also expected to improve spectral efficiency in 3G networks, allowing carriers to provide more data and voice services over a given bandwidth. This technical white paper provides an overview of the LTE physical layer (PHY), including technologies that are new to cellular such as Orthogonal Frequency Division Multiplexing (OFDM) and Multiple Input Multiple Output (MIMO) data transmission.

UMTS Evolution

TM51107EN03GLA3


5.1 Introduction

The LTE PHY is a highly efficient means of conveying both data and control information between an enhanced base station (eNodeB) and mobile user equipment (See LTE network elements in figure 8). The LTE PHY employs some advanced technologies that are new to cellular applications. These include Orthogonal Frequency Division Multiplexing (OFDM) and Multiple Input Multiple Output (MIMO) data transmission. In addition, the LTE PHY uses Orthogonal Frequency Division Multiple Access (OFDMA) on the downlink (DL) and Single Carrier – Frequency Division Multiple Access (SC-FDMA) on the uplink (UL). OFDMA allows data to be directed to or from multiple users on a subcarrier-by-subcarrier basis for a specified number of symbol periods. Due to the novelty of these technologies in cellular applications, they are described separately before delving into a description of the LTE PHY. Although the LTE specs describe both Frequency Division Duplexing (FDD) and Time Division Duplexing (TDD) to separate UL and DL traffic, market preferences dictate that the majority of deployed systems will be FDD. This paper therefore describes LTE FDD systems only.

UMTS Evolution


51

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


SAE Gateway

Evolved Packet Core (EPC)Evolved UTRAN (E-UTRAN)

Evolved NodeB(eNB)

LTE-UE Serving Gateway

PDN Gateway

MME

PCRF

PDN

HSS

MME: Mobility Management Entity

PCRF: Policy and Charging Rule Function

LTE-Uu

X2

S1-U

S1-MME

S11

S6a

S5/S8 SGi

S7

Rx+

Fig. 9 LTE network elements

UMTS Evolution

TM51107EN03GLA3


5.2 LTE design goals

The LTE PHY is designed to meet the following goals [1]:

1. Support scalable bandwidths of 1.25, 2.5, 5.0, 10.0 and 20.0 MHz

2. Peak data rate that scales with system bandwidth

a) Downlink (2 Ch MIMO) peak rate of 100 Mbps in 20 MHz channel

b) Uplink (single Ch Tx) peak rate of 50 Mbps in 20 MHz channel

3. Supported antenna configurations

a) Downlink: 4x2, 2x2, 1x2, 1x1

b) Uplink: 1x2, 1x1

4. Spectrum efficiency

a) Downlink: 3 to 4 x HSDPA Rel. 6

b) Uplink: 2 to 3 x HSUPA Rel. 6

5. Latency

a) C-plane: <50 – 100 msec to establish U-plane

b) U-plane: <10 msec from UE to server

6. Mobility

a) Optimized for low speeds (<15 km/hr)

b) High performance at speeds up to 120 km/hr

a) Maintain link at speeds up to 350 km/hr

7. Coverage

a) Full performance up to 5 km

b) Slight degradation 5 km – 30 km

c) Operation up to 100 km should not be precluded by standard

UMTS Evolution


53

5.3 LTE basic concepts

It’s worth taking a look at some of the basic technologies involved. Many methods employed in LTE are relatively new in cellular applications. These include OFDM, OFDMA, MIMO and Single Carrier Frequency Division Multiple Access (SC-FDMA).

LTE employs OFDM for downlink data transmission and SC-FDMA for uplink transmission. OFDM is a well-known modulation technique, but is rather novel in cellular applications. A brief discussion of the basic properties and advantages of this method is therefore warranted.

UMTS Evolution

TM51107EN03GLA3


5.4 OFDM

Unlike single carrier systems described above, OFDM communication systems do not rely on increased symbol rates in order to achieve higher data rates. This makes

the task of managing ISI much simpler. OFDM systems break the available bandwidth into many narrower sub-carriers and transmit the data in parallel streams. Each subcarrier is modulated using varying levels of QAM modulation, e.g. QPSK, QAM, 64QAM or possibly higher orders depending on signal quality. Each OFDM symbol is therefore a linear combination of the instantaneous signals on each of the subcarriers in the channel. Because data is transmitted in parallel rather than serially, OFDM symbols are generally MUCH longer than symbols on single carrier systems of equivalent data rate.

There are two truly remarkable aspects of OFDM. First, each OFDM symbol is preceded by a cyclic prefix (CP), which is used to effectively eliminate ISI. Second, the sub-carriers are very tightly spaced to make efficient use of available bandwidth, yet there is virtually no interference among adjacent sub-carriers (Inter Carrier Interference, or ICI). These two unique features are actually closely related. In order to understand how OFDM deals with multipath distortion, it’s useful to consider the signal in both the time and frequency domains. The OFDM symbol consists of two major components: the CP and an FFT period (TFFT). The duration of the CP is determined by the highest anticipated degree of delay spread for the targeted application. When transmitted signals arrive at the receiver by two paths of differing length, they are staggered in time as shown in following figure.

UMTS Evolution


55

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Signal Delay < CP

CP = 4.6875 μsec

TFFT = 66.667 μsec

Signals with varying delays are combined at receiver front end

Baseband processor strips off CP, resulting in RECT functions in time domain

Fig. 10 OFDM eliminates ISI via Longer Symbol Periods and a Cyclic Prefix

UMTS Evolution

TM51107EN03GLA3


Within the CP, it is possible to have distortion from the preceding symbol. However, with a CP of sufficient duration, preceding symbols do not spill over into the FFT period; there is only interference caused by time-staggered “copies” of the current symbol. Once the channel impulse response is determined (by periodic transmission of known reference signals), distortion can be corrected by applying an amplitude and phase shift on a subcarrier-by-subcarrier basis. Note that all of the information of relevance to the receiver is contained within the FFT period. Once the signal is received and digitized, the receiver simply throws away the CP. The result is a rectangular pulse that, within each subcarrier, is of constant amplitude over the FFT period.

The rectangular pulses resulting from decimation of the CP are central to the ability to space subcarriers very closely in frequency without creating ICI. Readers may recall that a uniform rectangular pulse (RECT function) in the time domain results in a SINC function (sin(x) / x) in the frequency domain as shown in following figure. The LTE FFT Period is 67.77 μsec. Note that this is simply the inversion of the carrier spacing (1 / Δf). This results in a SINC pattern in the frequency domain with uniformly spaced zero-crossings at 15 kHz intervals—precisely at the center of the adjacent subcarrier. It is therefore possible to sample at the center frequency of each subcarrier while encountering no interference from neighboring subcarriers (zero-ICI).

UMTS Evolution


57

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Fig. 11 FFT of OFDM Symbol Reveals Distinct Subcarriers

UMTS Evolution

TM51107EN03GLA3


5.4.1 OFDMA

OFDMA is employed as the multiplexing scheme in the LTE downlink. Perhaps the best way to describe OFDMA is by contrasting it with a packet-oriented networking scheme such as 802.11a. In 802.11a, Carrier-Sense Multiple Access (CSMA) is the multiplexing method. Downlink and uplink traffic from the fixed access point (AP) to mobile user stations (STAs) is by means of PHY layer packets. As explained below, OFDMA makes much more efficient use of network resources.

5.4.2 OFDMA and LTE generic frame structure

OFDMA is an excellent choice of multiplexing scheme for the 3GPP LTE downlink. Although it involves added complexity in terms of resource scheduling, it is vastly superior to packet-oriented approaches in terms of efficiency and latency. In OFDMA, users are allocated a specific number of subcarriers for a predetermined amount of time. These are referred to as physical resource blocks (PRBs) in the LTE specifications. PRBs thus have both a time and frequency dimension. Allocation of PRBs is handled by a scheduling function at the 3GPP base station (eNodeB).

UMTS Evolution


59

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


0 1 2 3 10 11 19… …

0 1 2 3 4 5 6

Frame 10 msec

Sub Frame 1 msec Slot 0.5 msec

7 OFDM Symbols (short cyclic prefix)

0 1 2 3 4 5 6

cyclic prefix

Fig. 12 LTE Generic Frame Structure

UMTS Evolution

TM51107EN03GLA3


In order to adequately explain OFDMA within the context of the LTE, we must study the PHY layer generic frame structure. The generic frame structure is used with FDD. Alternative frame structures are defined for use with TDD.

However, TDD is beyond the scope of this paper. Alternative frame structures are therefore not considered.

As shown LTE frames are 10 msec in duration. They are divided into 10 subframes, each subframe being 1.0 msec long. Each subframe is further divided into two slots, each of 0.5 msec duration. Slots consist of either 6 or 7 ODFM symbols, depending on whether the normal or extended cyclic prefix is employed.

5.4.3 MIMO and MRC

The LTE PHY can optionally exploit multiple transceivers at both the base station and UE in order to enhance link robustness and increase data rates for the LTE downlink. In particular, maximal ratio combining (MRC) is used to enhance link reliability in challenging propagating conditions when signal strength is low and multipath conditions are challenging. MIMO is a related technique that is used to increase system data rates.

UMTS Evolution


61

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Baseband XVCR Baseband

XVCR-A

XVCR-B

Conventional Single Channel

Receiver with Antenna Diversity

MRC/MIMO Receiver Configuration

(2 channel)

Fig. 13.

UMTS Evolution

TM51107EN03GLA3


This receiver structure uses multiple antennas, but it is not capable of supporting MRC/MIMO. The basic receiver topology for both MRC and MIMO is shown in Figure 12.b. MRC and MIMO are sometimes referred to as “multiple antenna” technologies, but this is a bit of a misnomer. Note that the salient difference between the receivers shown in Figures 11.a and 11.b is not multiple antennas, but rather multiple transceivers. With MRC, a signal is received via two (or more) separate antenna/transceiver pairs. Note that the antennas are physically separated, and therefore have distinct channel impulse responses. Channel compensation is applied to each received signal within the baseband processor before being linearly combined to create a single composite received signal. When combined in this manner, the received signals add coherently within the baseband processor. However, the thermal noise from each transceiver is uncorrelated. Thus, linear combination of the channel compensated signals at the baseband processor results in an increase in SNR of 3 dB on average for a two-channel MRC receiver in a noise-limited environment.

5.4.4 SC-FDMA

LTE uplink requirements differ from downlink requirements in several ways. Not surprisingly, power consumption is a key consideration for UE terminals. The high PAPR and related loss of efficiency associated with OFDM signaling are major concerns. As a result, an alternative to OFDM was sought for use in the LTE uplink. Single Carrier – Frequency Domain Multiple Access (SC-FDMA) is well suited to the LTE uplink requirements. The basic transmitter and receiver architecture is very similar (nearly identical) to OFDMA, and it offers the same degree of multipath protection. Importantly, because the underlying waveform is essentially single-carrier, the PAPR is lower.

Unlike OFDM, the underlying SC-FDMA signal represented by the discrete subcarriers is—not surprisingly—single carrier. This is distinctly different than OFDM because the SC-FDMA subcarriers are not independently modulated. As a result, PAPR is lower than for OFDM transmissions.

As mentioned above, SC-FDMA subcarriers can be mapped in one of two ways: localized or distributed as shown in following figure. However, the current working assumption is that LTE will use localized subcarrier mapping. This decision was motivated by the fact that with localized mapping, it is possible to exploit frequency selective gain via channel-dependent scheduling (assigning uplink frequencies to UE based on favorable propagation conditions).

UMTS Evolution


63

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Localized Subcarriers Distributed Subcarriers

f f

Fig. 14 SC-FDMA subcarriers can be mapped in either localized or distributed mode

UMTS Evolution

TM51107EN03GLA3


UMTS Evolution


65

6 Exercises

UMTS Evolution

TM51107EN03GLA3


Which of the followings are not true about HSDPA?

Some of HSDPA terminal categories need to support the 16 QAM modulation.

Some of HSDPA terminal categories need to support the QPSK modulation.

Scheduling and link adaptation are conducted in RNC.

With HSDPA, variable Spreading Factor is not used any more.

Ciphering is done in the MAC layer. In IMS, the CSCF supports:

The Quality Of Service policy.

The user traffic.

Connection to HSS to authorize users.

Collection of charging-relevant information and send it to the Charging Gateway.

In case of the I-WLAN security process, the protocol used between an I-WLAN Access Point and AAA server can be:

Radius

LDAP

SNMP

L2TP

Diameter

UMTS Evolution


67

Explain briefly the following technologies used in LTE:

SC-FDMA:

__________________________________________________________________

___________________________________________________________________

OFDM :

__________________________________________________________________

___________________________________________________________________

MIMO :

__________________________________________________________________

___________________________________________________________________

UMTS Evolution

TM51107EN03GLA3


Documents

07 TM51107EN03GLA3 Evolution