LTE Technology

LTE/ E PS

Book revision 5.0.1

Table of Contents

1. Introduction .…………………..………………………….……...… 5

2. Architecture ..……………………………………………………… 15

3. OFDMA & SC-FDMA ..…………………………………………... 37

4. E-UTRAN ..………………………………………………………... 81

5. Core Network ..…………………………………………………….. 117

6. Policy Control & Charging ..………………………………..……... 143

7. Traffic Cases ..………………………….. ………………………… 153

8. Security ……………………………………………………………. 185

9. EPS Management .…………………………………………………. 207

10. Services ..…………………………………………………………... 219

11. CS Fallback and SMSoSGs ……………………………………….. 267

12. Acronyms & Abbreviations .…………………...………………...... 283

3

Copyright © 2011 Leliwa Sp. z o.o.

LTE/EPS Technology

This page is intentionally left blank

4


1 Introduction

Chapter 1

TDMA, CDMA and OFDMA............................................................................ 7

3GPP evolutionary approach ............................................................................. 8

LTE system requirements ................................................................................ 10


5



6


1 Introduction

Many times, one technology or the other is positioned as having fundamental advantages over another. However, any of these three approaches, when fully optimised, can effectively match the capabilities of any other. For example,

GSM, which is based on TDMA, thanks to innovations like synchronised frequency hopping, AMR, and EDGE for data performance optimisation, is able to effectively compete with the capacity and data throughput of CDMA based systems.

Today, the main question is whether OFDM provide any inherent advantage over TDMA or CDMA. For systems employing less than 10 MHz of bandwidth, the answer is ‘no’. Because it transmits mutually orthogonal subchannels at a lower symbol rate, the fundamental advantage of OFDM is that it elegantly addresses the problem of Inter Symbol Interference (ISI) induced by multipath and greatly simplifies channel equalisation. As such,

OFDM systems, assuming they employ all the other standard techniques for maximizing spectral efficiency, may achieve slightly higher spectral efficiency than CDMA systems. However, advanced receiver architectures, including options such as practical equalisation approaches and interference cancellation techniques, are already commercially available in chipsets and can nearly match this performance advantage. It is with larger bandwidths (10 to 20 MHz), and in combination with advanced antenna approaches such as

Multiple Input Multiple Output (MIMO) or Adaptive Antenna Systems

(AAS), that OFDM enables less computationally complex implementations than those based on CDMA.

Hence, OFDM is more readily realisable in mobile devices. However, studies have shown that the complexity advantage of OFDM may be quite small (that is, less than a factor of two) if frequency domain equalisers are used for

CDMA-based technologies. Still, the advantage of reducing complexity is one reason 3GPP chose OFDM for its LTE project. It is also one reason newer

WLAN standards, which employ 20 MHz radio channels, are based on

OFDM. In other words, OFDM is currently a favoured approach under consideration for radio systems that have extremely high peak rates. OFDM also has an advantage in that it can scale easily for different amounts of available bandwidth. This in turn allows OFDM to be progressively deployed in available spectrum by using different numbers of subcarriers.

An OFDMA technology such as LTE can also take better advantage of wider radio channels (for example, 10 MHz) by not requiring guard bands between radio carriers (for example, HSPA carriers). In recent years, the ability of

7



OFDM to cope with multipath has also made it the technology of choice for the design of Digital Broadcast Systems (DBS).

In 5 MHz of spectrum, as used by UMTS/HSPA, continual advances with

CDMA technology (realised in HSPA+) through approaches such as equalisation, MIMO, interference cancellation, and high-order modulation will allow CDMA to largely match OFDMA-based systems.

Because OFDMA has only modest advantages over CDMA in 5 MHz channels, the advancement of HSPA is a logical and effective strategy. In particular, it extends the life of operators’ large 3G investments, reducing overall infrastructure investments, decreasing capital and operational expenditures, and allowing operators to offer competitive services.

Rather than emphasising any one wireless approach, 3GPP’s evolutionary plan is to recognise the strengths and weaknesses of every technology and to exploit the unique capabilities of each one accordingly. GSM, based on a

TDMA approach, is mature and broadly deployed. Already extremely efficient, there are nevertheless opportunities for additional optimisations and enhancements.

Standards bodies have already defined ‘evolved EDGE’, that doubles the performance of current EDGE systems.

2006 2007 2008

3GPP GSM EDGE Radio Access Network Evolution

EDGE

DL: 474 kbps

UL: 474 kbps

Evolved EDGE

DL: 1.9 Mbps

UL: 947 kbps

3GPP UMTS Radio Access Network Evolution

HSDPA

DL: 14.4 Mbps

UL: 384 kbps

In 5 Mhz

HSDPA/HSUPA

DL: 14.4 Mbps

UL: 5.76 Mbps

In 5 Mhz

3GPP Long Term Evolution

Rel 7 HSPA+

DL: 28 Mbps

UL: 11.5 Mbps

In 5 Mhz

2009 2010

Rel 8 HSPA+

DL: 42 Mbps

UL: 11.5 Mbps

In 5 Mhz

LTE 2X2 MIMO

DL: 173 Mbps

UL: 58 Mbps

In 20 Mhz

LTE 4X4 MIMO

DL: 326 Mbps

UL: 86 Mbps

In 20 Mhz

CDMA 2000 Evolution

EV-DO Rev 0

DL: 2.4 Mbps

UL: 153 kbps

In 1.25 Mhz

EV-DO Rev A

DL: 3.1 Mbps

UL: 1.8 Mbps

In 1.25 Mhz

Mobile WiMAX Evolution

Fixed WiMAX

EV-DO Rev B

DL: 14.7 Mbps

UL: 4.9 Mbps

In 5 Mhz

UMB 2X2 MIMO

DL: 140 Mbps

UL: 34 Mbps

In 20 Mhz

UMB 4X4 MIMO

DL: 280 Mbps

UL: 68 Mbps

In 20 Mhz

Wave 1

DL: 23 Mbps

UL: 4 Mbps

10 Mhz 3:1 TDD

Wave 2

DL: 46 Mbps

UL: 4 Mbps

10 Mhz 3:1 TDD

IEEE 802.16m

Figure 1-1 Different wireless technologies and their evolution

2011

8


1 Introduction

The evolved data systems for UMTS, such as HSPA and HSPA+, introduce enhancements and simplifications that help CDMA based systems match the capabilities of competing systems, especially in 5 MHz spectrum allocations.

Given some of the advantages of an OFDM approach, 3GPP has specified

OFDMA as the basis of its LTE effort. LTE incorporates best-of-breed radio techniques to achieve performance levels beyond what will be practical with

CDMA approaches, particularly in larger channel bandwidths. However, in the same way that 3G coexists with 2G systems in integrated networks, LTE systems will coexist with both 3G systems and 2G systems. Multimode devices will function across LTE/3G or even LTE/3G/2G, depending on market circumstances.

The development of GSM and UMTS/HSPA happens in stages referred to as

3GPP releases, and equipment vendors produce hardware that supports particular versions of each specification. It is important to realise that the

3GPP releases address multiple technologies. For example, R7 optimises

VoIP for HSPA but also significantly enhances GSM data functionality with

Evolved EDGE. A summary of the different 3GPP releases follows:

•

Release 99 ( completed) - First deployable version of UMTS.

Enhancements to GSM data (EDGE). Provides support for

GSM/GPRS/EDGE/WCDMA radio-access networks.

•

Release 4 (completed). Multimedia messaging support. First steps toward using IP transport in the CN.

•

Release 5 (completed): HSDPA. First phase of IMS. Full ability to use

IP-based transport instead of just ATM in the CN.

•

Release 6 (completed): HSUPA. Enhanced multimedia support through Multimedia Broadcast/Multicast Services (MBMS).

Performance specifications for advanced receivers. WLAN integration option. IMS enhancements. Initial VoIP capability.

•

Release 7 (completed): Provides enhanced GSM data functionality with Evolved EDGE. Specifies HSPA Evolution (HSPA+), which includes higher order modulation and MIMO. Also includes fine-tuning and incremental improvements of features from previous releases. Results include performance enhancements, improved spectral efficiency, increased capacity, and better resistance to interference. Continuous Packet Connectivity (CPC) enables efficient

‘always-on’ service and enhanced uplink VoIP capacity as well as reductions in call setup delay for PoC. Radio enhancements include 64

QAM in the downlink and 16 QAM in the uplink.

•

Release 8 (completed): Comprises further HSPA Evolution features such as simultaneous use of MIMO and 64 QAM. Includes work item

9


LTE/EPS Technology for dual-carrier HSPA (DC-HSPA) wherein two WCDMA radio channels can be combined for a doubling of throughput performance.

Specifies OFDMA-based 3GPP LTE. Defines EPC.

•

Release 9 (under development): Will include HSPA and LTE enhancements including HSPA multi-carrier operation.

•

Release 10 (under development): Will specify LTE-Advanced that meets the requirements set by ITU’s IMT-Advanced 4G project.

LTE system requirements

LTE is focusing on optimum support of Packet Switched (PS) services. Main requirements for the design of an LTE system were identified in the beginning of the standardisation work on LTE and have been captured in 3GPP TR

25.913. They can be summarised as follows:

•

Data rate: Peak data rates target 100 Mbps DL and 50 Mbps UL for

20 MHz spectrum allocation, assuming 2 receive antennas and 1 transmit antenna at the terminal (these requirement values are already exceeded by the current LTE specification),

•

Throughput & spectrum efficiency: Target for downlink average user throughput per MHz and for spectrum efficiency is 3-4 times better than release 6. Target for is 2-3 times better than release 6.

•

Latency: The one-way transit time between a packet being available at the IP layer in either the UE or radio access network and the availability of this packet at IP layer in the radio access network/UE shall be less than 5 ms. Also C-plane latency shall be reduced, e.g. to allow fast transition times of less than 100 ms from camped state to active state.

•

Channel bandwidth: Scalable bandwidths of 5, 10, 15, 20 MHz shall be supported. Also bandwidths smaller than 5 MHz shall be supported for more flexibility, i.e. 1.4 MHz and 3 MHz.

•

Interworking: Interworking with existing UTRAN/GERAN systems and non-3GPP systems shall be ensured. Multimode terminals shall support handover to and from UTRAN and GERAN as well as inter-RAT measurements. Interruption time for handover between

E-UTRAN and UTRAN/GERAN shall be less than 300 ms for real time services and less than 500 ms for non real time services.

10


1 Introduction

•

Multimedia Broadcast Multicast Services (MBMS): MBMS shall be further enhanced and is then referred to as E-MBMS.

•

Costs: Reduced CAPEX and OPEX including backhaul shall be achieved. Cost effective migration from R6 UTRA radio interface and architecture shall be possible. Reasonable system and terminal complexity, cost and power consumption shall be ensured. All the interfaces specified shall be open for multi-vendor equipment interoperability.

•

Mobility: The system should be optimised for low mobile speed (0-15 km/h), but higher mobile speeds shall be supported as well including high speed train environment as special case.

•

Spectrum allocation: Operation in paired (Frequency Division

Duplex / FDD mode) and unpaired spectrum (Time Division Duplex /

TDD mode) is possible.

•

Co-existence: Co-existence in the same geographical area and collocation with GERAN/UTRAN shall be ensured. Also, co-existence between operators in adjacent bands as well as crossborder coexistence is a requirement.

•

Quality of Service: End-to-end Quality of Service (QoS) shall be supported. VoIP should be supported with at least as good radio and backhaul efficiency and latency as voice traffic over the UMTS circuit switched networks

•

Network synchronisation: Time synchronisation of different network sites shall not be mandated.

data rate: DL 100 Mbps & UL 50 Mbps (already exceeded),

throughput & spectrum efficiency: DL 3-4 x R6, UL 2-3 x R6,

latency: U-plane one way ≤ 5 ms, C-plane ≤ 100 ms,

channel bandwidth: 5, 10, 15, 20 MHz and smaller,

interworking: GERAN/UTRAN and non-3GPP,

MBMS, cost reduction,

mobility (optimised for low speeds 0-15 km/h),

spectrum allocation: FDD & TDD,

QoS,

time synchronisation between sites not mandatory.

Figure 1-2 Requirements for the LTE system

11



LTE uses OFDMA on the downlink, which is well suited to achieve high peak data rates in high spectrum bandwidth. WCDMA radio technology is basically as efficient as OFDM for delivering peak data rates of about 10 Mbps in 5

MHz of bandwidth. However, achieving peak rates in the 100 Mbps range with wider radio channels would result in highly complex terminals, and it is not practical with current technology. This is where OFDM provides a practical implementation advantage. Scheduling approaches in the frequency domain can also minimise interference, thereby boosting spectral efficiency. approach is also highly flexible in channelization, and LTE will operate in various radio channel sizes ranging from 1.25 to 20 MHz.

On the uplink, however, a pure OFDMA approach results in high Peak to

Average Ratio (PAR) of the signal, which compromises power efficiency and, ultimately, battery life. Hence, LTE uses an approach called SC-FDMA, which is somewhat similar to OFDMA but has a 2 to 6 dB PAR advantage over the OFDMA method used by other technologies such as IEEE 802.16e.

LTE capabilities include:

•

Downlink peak data rates up to 326 Mbps with 20 MHz bandwidth.

•

Uplink peak data rates up to 86.4 Mbps with 20 MHz bandwidth.

•

Operation in both TDD and FDD modes.

•

Scalable bandwidth up to 20 MHz, covering 1.25, 2.5, 5, 10, 15, and

20 MHz. Channels that are 1.6 MHz wide are under consideration for the unpaired frequency band, where a TDD approach will be used.

•

Increased spectral efficiency over R6 HSPA by a factor of two to four.

•

Reduced latency, to 10 ms Round Trip Time (RTT), and to less than

100 ms transition time from inactive to active.

The overall intent is to provide an extremely high-performance radio-access technology that offers full vehicular speed mobility and that can readily coexist with HSPA and earlier networks. Because of scalable bandwidth, operators will be able to easily migrate their networks and users from HSPA to LTE over time.

2x2 MIMO /16QAM

4x4 MIMO /64QAM

Figure 1-3 LTE bitrates (20 MHz channel)

12


1 Introduction

The RTT for E-UTRAN is around 7 ms, one way delay 3,5 ms and HARQ

RTT 5 ms.

UE

TTI + frame alignment eNode B

1 ms 1.5 ms 1 ms

1 ms

HARQ RTT 5 ms

1.5 ms

Figure 1-4 LTE user plane delay

1 ms


13



14


2 Architecture

Chapter 2

Non-roaming architecture ................................................................................ 17

Roaming architecture ....................................................................................... 25

Arch. for non-3GPP access .............................................................................. 27

Interfaces.......................................................................................................... 29

Geographical network structure ....................................................................... 31

Identities........................................................................................................... 33


15



16


2 Architecture

Fig. 2-1 describes the overall Evolved Packet System (EPS) architecture, not only including the Evolved Packet Core (EPC) and Evolved UMTS

Terrestrial Radio Access Network (E-UTRAN), but also other blocks, in order to show the relationship between them.

UE

UTRAN

GERAN

S10

E-UTRAN

MSC

Sv

SGSN

S6d

Sv

MME

MME

S3 HSS

SGs

S6a

S13

S1

-MME

S11

S1

-U

S-GW

EIR

S5

S4

S12 red colour indicates new

PCRF

Gx

P-GW

Rx

SGi

Figure 2-1 Evolved Packet System (EPS) architecture

Operator’s

IP

Services

(e.g. IMS,

PSS, etc.)

The Evolved Packet Core (EPC) network is composed of several new functional entities:

•

Mobility Management Entity (MME),

•

Serving Gateway (S-GW),

•

Packet Data Network (PDN) Gateway (P-GW).

The EPC makes also use of the existing 2G GSM/3G UMTS network nodes, namely:

•

Home Subscriber Server (HSS),

•

Equipment Identity Register (EIR),

•

Policy and Charging Rules Function (PCRF).

17



Some additional nodes are also required for interworking with other

(non-LTE) Radio Access Technologies (RATs). Example of such node is

SGSN that is used for interworking with GERAN and UTRAN.

The Mobility Management Entity (MME) is in charge of all control plane functions related to subscriber and session management. From that perspective, the MME supports as follows:

•

Non-Access Stratum (NAS) signalling, i.e. signalling between UE and the Evolved Packet Core (EPC) network – this relates to all signalling procedures related with terminal location management (e.g. Tracking

Area Update procedure) and procedures used to setup an EPS bearer

(connection for user data).

•

Inter Core Network (CN) node signalling for handling mobility between different types of 3GPP access networks, e.g. signalling with

SGSN exchanged over S3 interface.

•

Security procedures – this relates to end-user authentication, end-user equipment check, as well as initiation and negotiation of ciphering and integrity protection algorithms.

•

Tracking Area (TA) list management.

•

Idle UE reachability, e.g. control and execution of paging.

•

Selection of other CN nodes: o S-GW and P-GW for the purpose of user data transmission, o MME for handovers with MME change, o SGSN for handovers to GERAN or UTRAN.

•

Roaming, i.e. MME handles interface toward subscriber’s HPLMN

HSS.

The MME is linked through the S6a interface to the HSS which supports the database containing all the user subscription information.

Two logical Gateways exist:

•

Serving GW (S-GW),

•

PDN GW (P-GW).

18


2 Architecture

The P-GW and the S-GW may be implemented in one physical node or separated physical nodes.

MME S6a HSS

S1

-MME

E-UTRAN S11

S1

-U

IP/IMS

S-GW P-GW SGi

Figure 2-2 S-GW and P-GW in one physical node

Also the S-GW and the MME may be implemented in one physical node or separated physical nodes.

E-UTRAN S1

MME

S-GW

S6a HSS

S5 P-GW SGi

IP/IMS

Figure 2-3 MME and S-GW in one physical node

The Serving Gateway (S-GW) is the gateway which terminates the interface towards E-UTRAN. For each UE associated with the EPS, at a given point of time, there is a single S-GW.

The functions of the S-GW, include:

•

Packet routing and forwarding,

•

Transport level packet marking in the uplink and the downlink, e.g. setting the DiffServe Code Point, based on the QoS Class Identifier

(QCI) of the associated EPS bearer,

•

Downlink packet buffering and initiation of network triggered

Service Request procedure for Idle UEs,

•

The local mobility anchor point for inter-eNodeB handover and assistance in packet reordering during inter-eNodeB handover,

•

Mobility anchoring for inter-3GPP mobility (relaying the traffic between 2G/3G system and P-GW,

•

Charging and accounting,

•

Lawful interception.

19



The PDN GW is the gateway which terminates the SGi interface towards the

PDN. If a UE is accessing multiple PDNs, there may be more than one PDN

GW for that UE.

PDN GW functions include:

•

Transport level packet marking in the uplink and the downlink,

•

UE IP address allocation,

•

Per-user based packet filtering (by e.g. deep packet inspection),

•

UL and DL service level charging ,

•

UL and DL service level rate enforcement,

•

UL and DL service level gating control,

•

Charging and accounting,

•

Lawful Interception,

•

DHCP functions,

The Serving GPRS Support Node (SGSN), in addition to the functions handled earlier in 2G/3G network, is responsible for:

•

Inter EPC node signalling for mobility between 2G/3G and

E-UTRAN,

•

PDN and Serving GW selection,

•

MME selection for handovers to E-UTRAN.

The Policy and Charging Rules Function (PCRF) is responsible for policy-control decision-making, as well as for controlling the flow-based charging functionalities in the Policy Control Enforcement Function (PCEF) which resides in the P-GW. The PCRF provides the QoS authorisation that decides how a certain flow will be treated in the PCEF and ensures that this is in accordance with the user’s subscription profile.

The servers belonging to the PDN (e.g. IMS P-CSCF) can initiate via dialogue with PCRF the establishment of the EPS bearer towards the UE.

20


2 Architecture

The Home Subscriber Server (HSS) is the concatenation of the Home

Location register (HLR) and the Authentication Centre (AuC) – two functions being already present in 2G GSM and 3G UMTS networks. The HLR part of the HSS is in charge of storing and updating when necessary the database containing all the user subscription information, including:

• user identification and addressing – this corresponds to the

International Mobile Subscriber Identity (IMSI) and Mobile

Subscriber ISDN Number (MSISDN),

• user profile information – this includes service subscription states and user-subscribed Quality of Service (QoS) information,

The AuC part of the HSS is in charge of generating security information from user identity keys. This security information is provided to the HLR and further communicated to other entities in the network. Security information is mainly used for:

• mutual network-terminal authentication,

• radio path ciphering and integrity protection, to ensure data and signalling transmitted between network and the terminal is neither eavesdropped nor altered.

Introduced from the very beginning of the GSM network standardisation,

HLR and AuC boxes were eventually joined together in a single HSS node as

IMS was defined by the 3GPP. In its extended role, the HSS of Evolved

UMTS networks integrates both HLR and AuC features, including classical

MAP features (for support of CS and PS sessions), IMS-related functions, and all necessary functions related to the new EPC.

I/S-CSCF

IMS

Cx

HSS

S6a

MME

EPC

GMSC

C

D

HLR

AUC

Gc

S6d

Gr

GGSN

VLR

2G/3G CS domain

SGSN

2G/3G PS domain

Figure 2-4 HSS structure and external interfaces

21



There are actually three main cases in which the HSS is actively involved:

•

At user registration – the HSS is interrogated by the corresponding CN node as the user attempts to register to the network in order to check the user subscription rights. This can be done by either the MSC/VLR, the SGSN, I-CSCF or the MME, depending on the type of network and registration being requested;

•

In the case of terminal location update – as the terminal changes location areas, the HSS is kept updated and maintains a reference of the last known area (e.g. MSC/SGSN number, MME/SGSN/S-CSCF address);

•

In the case of user-terminated CS or IMS session request – the HSS is interrogated and provides a reference of the CN node corresponding to the current user location.

Coming back to the first releases of the UMTS standard, the UTRAN architecture was initially very much aligned with GSM access network

(GERAN) concepts. As described in Fig. 2-5, the UTRAN network is composed of the radio equipment (known as NodeB or Base Station) in charge of transmission and reception over the radio interface, and the Radio

Network Controller (RNC) in charge of NodeB configuration and radio resource allocation. A single RNC may possibly control a large number of

NodeBs over the Iub interface.

In addition, an inter-RNC Iur interface was defined to allow UTRAN call anchoring at the RNC level and macro-diversity between different NodeBs controlled by different RNCs. Macro-diversity was a consequence of

CDMA-based UTRAN physical layer, as means to reduce radio interference and preserve network capacity. The initial UTRAN architecture resulted in a simplified NodeB implementation, and a relatively complex, sensitive, high-capacity and feature-rich RNC design. In this model, the RNC had to support resources and traffic management features as well as a significant part of the radio protocols. Compared with UTRAN, the E-UTRAN OFDM-based structure is quite simple. It is only composed of one network element: the evolved NodeB (eNB).

The 3G RNC inherited from the 2G BSC has disappeared from E-UTRAN and the eNB is directly connected to the Core Network (CN) using S1 interface. As a consequence, the features supported by the RNC have been distributed between the eNB and the CN entities.

22


2 Architecture

Core Network

Iu Iu

Core Network

RNC

Iub

Iub

NodeB

Iur RNC

Iub

Iub

S1 S1

X2 eNodeB

NodeB

NodeB

NodeB

UTRAN E-UTRAN

Figure 2-5 UTRAN and E-UTRAN architectures eNodeB

An eNodeB can be implemented either as a single-cell equipment providing coverage and services in one cell only, or as a multi-cell node, where each cell is covering a given geographical sector. omnidirectional eNodeB sectorised eNodeB

Figure 2-6 Omnidirectional and sectorised eNodeBs

A new X2 interface has been defined between eNBs, working in a meshed way (meaning that all eNBs may possibly be linked together). The main purpose of this interface is to minimise packet loss due to user mobility. As the terminal moves across the access network, unsent or unacknowledged packets stored in the old eNB queues can be forwarded to the new eNB thanks to the X2 interface.

23



S1

Core Network

S1

X2

Tx Re-Tx

Tx Re-Tx

HO

Figure 2-7 X2 interface

From a high-level perspective, the new E-UTRAN architecture is actually moving towards WLAN network structures and WiFi or WiMAX base stations’ functional definition. eNodeB – as WLAN access points – support all L1 and L2 features associated to the E-UTRAN OFDM physical interface, and they are directly connected to the network routers. There is no more intermediate controlling node (as the 2G BSC or 3G RNC was).

This has a merit of a simpler network architecture (fewer nodes of different types, which means simplified network operation) and allows better performance over the radio interface.

From the functional perspective, the eNB supports a set of legacy features, all related to physical layer procedures for transmission and reception over the radio interface:

• modulation and de-modulation,

• channel coding and decoding.

Besides, the eNB includes additional features, coming form the fact that there are no more Base Station controllers in the E-UTRAN architecture:

•

radio resource control: this relates to the allocation, modification and release of resources for the transmission over the radio interface between the user terminal and the eNB.

•

mobility management: this refers to a measurement processing and handover decision.

• full L2 protocol: this refers detection and possibly correction of errors that may occur in the physical layer (this function in UTRAN was fully or for some services partially handled by RNC).

24


2 Architecture

Roaming architecture

This section describes the roaming case, where both the visited and the home networks are EPC networks. Two alternative architectures are shown, depending on whether UE traffic has to be routed to the HPLMN or not.

User traffic routed to the HPLMN

Fig. 2-8 presents the EPC architecture support for roaming cases with

HPLMN routed traffic. In this example, a user has subscribed to HPLMN A, but is currently under the coverage of the VPLMN B. This kind of situation may happen while the user is travelling to another country, or in case in which a national roaming agreement has been set up between operators, so as to decrease the investment effort for national coverage. In such a roaming situation, part of the session is handled by the VPLMN. This includes E-

UTRAN access network support, session signalling handling by the MME, and user plane routing through the local S-GW. Thanks to local MME and S-

GW, the VPLMN is then able to built and send charging tickets to the subscriber home operator, corresponding to the amount of data transferred and

QoS allocated.

UE

VPLMN HPLMN

UTRAN

SGSN

GERAN

S10

E-UTRAN

S3

MME

MME

S1

-MME

S11 S4 S12

S1

-U

S-GW

S6a

S8

HSS

PCRF

Gx

P-GW

Rx

Operator’s

IP

Services

(e.g. IMS,

PSS, etc.)

SGi

Figure 2-8 Roaming architecture (HPLMN routed traffic)

However, since the terminal user has no subscription with the VPLMN, the

Visited EPC needs to be linked to the HSS of the user home network, at least to retrieve the user-specific security credential needed for authentication and ciphering. In the roaming architecture , the session path goes through the

25



Home P-GW over the S8 interface, so as to apply policy and charging rules in the home network corresponding to the user’s subscription parameters.

The S8 interface is in fact a roaming variant of S5 reference point, to support both signalling and data transfer between S-GW located in VPLMN and

P-GW located in the HPLMN.

Briefly, in such a model, the VPLMN provides the access connectivity (which also involves the basic session signalling procedures supported by the Visited

MME, with the support of the Home HSS), whereas the HPLMN still provides the access to external networks, possibly including IMS-based services.

In the previous model, the call is still anchored to the Home P-GW, hence the

‘home routed traffic’ denomination. The user packet routing in such a scheme may, however, be quite inefficient in terms of cost and network resources as the Home P-GW and Visited S-GW may be very far from each other. This is the reason why the 3GPP standard also allows the possibility of the user traffic to be routed via a Visited P-GW, as an optimisation. This may be very beneficial in the example of public Internet access – as routing the traffic to the HPLMN does not add any value to the end user – and even more in the case of an IMS session established between a roaming user and a subscriber of the visited network. In the last case, local traffic routing avoids a complete round trip of user data trough the HPLMN anchors.

Fig. 2-9 and describe possible network architecture in the case where the traffic is routed locally – or the ‘local breakout’ case. Both gateways are part of the VPLMN.

UE

VPLMN HPLMN

UTRAN

SGSN

HSS

GERAN

MME

S3 hPCRF Rx

Home

Operator’s

Services

S10 S9

E-UTRAN

MME

S1

-MME

S11 S4 S12

S1

-U

S-GW

S6a

S5 vPCRF

Gx

P-GW

Rx

SGi

Figure 2-9 Roaming architecture (local breakout)

Visited

Operator’s

PDN

26


2 Architecture

If the networks make use of PCRF, one of the possible solutions is that the enforcement of the HPLMN policies (QoS and charging policies) by the

Visited P-GW is performed through the interaction of Home and Visited

PCRF. Possibly, the Visited PCRF may add/modify policies according to those defined in the VPLMN. The related reference point between PCRFs is referred as S9.

A non-3GPP IP Access Network is defined as a trusted non-3GPP IP Access

Network if the 3GPP EPC system chooses to trust such non-3GPP IP access network. The 3GPP EPC system operator may choose to trust the non-3GPP

IP access network operated by the same or different operators, e.g. based on business agreements.

Note that specific security mechanisms may be in place between the trusted non-3GPP IP Access Network and the 3GPP EPC to avoid security threats. It is assumed that an IPSec tunnel between the UE and the 3GPP EPC is not required.

On the contrary, an untrusted non-3GPP IP Access Network is an IP access network where 3GPP network requires use of IPSec between the UE and the

3GPP network in order to provide adequate security mechanism acceptable to

3GPP network operator. An example of such untrusted non-3GPP IP access is

WLAN and it is made trusted in the Interworking WLAN specifications developed within 3GPP.

In the current standardisation documents, a trusted non-3GPP IP access is also referred to as the non-3GPP IP access, and an untrusted non-3GPP IP accesses are accommodated by is also referred to as the WLAN 3GPP IP access.

Fig. 2-10 represents the network architecture providing IP connectivity to the

EPC using non-3GPP type of access. This architecture is independent from the access technology, which could be WiFi, WiMAX or any other kind of access type. This picture applies to the trusted WLAN access, corresponding to the situation where the WLAN network is controlled by the operator itself or by another entity (local operator or service provider) which can be trusted due to the existence of mutual agreements.

27



PCRF

S7

P-GW

Trusted non 3GPP

IP Access

S2a

Ta

3GPP AAA

Server

Wx

HSS MME S-GW

E-UTRAN

Non-3GPP network

3GPP network

Rx

SGi

Operator’s

IP

(services:

IMS, PSS, etc…)

Figure 2-10 Trusted Non-3GPP IP Access architecture

As described below, some new network nodes and interfaces are needed to support non-3GPP access types. In contrast, on terminal side, no changes are required except some slight software adaptations. This comes from the fact that Authentication Authorisation Accounting (AAA) mechanisms for mutual authentication and access control are based on known IETF protocols but make use of the 3GPP UICC stored credentials.

The 3GPP AAA server’s role is to act as an inter-working unit between the

3GPP world and IETF standard-driven WLAN networks from the security perspective. Its purpose is to allow end-to-end authentication with WLAN terminals using 3GPP credentials. For that reason, the 3GPP AAA Server has an access to the HSS through Wx interface, so as to retrieve user-related subscription information and 3GPP authentication vectors.

From the 3GPP AAA Server, the Ta interface has been defined with the trusted access network, aiming at transporting authentication, authorisation and charging-related information in a secure manner.

From the user plane perspective, the user data are transmitted from the

WLAN to the P-GW through the new S2a interface. As in legacy EPC architecture, the P-GW still serves as an anchor point for the user traffic.

In such a model, the 3GPP Anchor and MME UPE nodes are not needed any more. Terminal location management is under the responsibility of the

WLAN Access as well as the packet session signalling and does not need any support from 3GPP EPC nodes (aside from the provision of 3GPP security credentials). In the example of a 802.11 WiFi access point, user association

(the process by witch a WiFi terminal connects to an access point), security features as well as radio protocols are handled by the access point itself.

28


2 Architecture

In addition to the trusted model, the standard defines another model, for the situations where WLAN is untrusted. This model is described in Fig. 2-11. As an example, this may correspond to a business entity deploying a WLAN for its internal use and willing to offer 3GPP connectivity to some of its customers. In such a case, the WLAN-3GPP interconnection looks a bit different due to additional mechanism to maintain legacy 3GPP infrastructure security and integrity.

PCRF

S7

P-GW

Untrusted non 3GPP

IP Access

Wn

Ta ePDG

Wm

3GPP AAA

Server

Wx

HSS

S2b

MME S-GW

E-UTRAN

Non-3GPP network

3GPP network

Rx

SGi

Operator’s

IP

(services:

IMS, PSS, etc…)

Figure 2-11 Untrusted Non-3GPP IP Access architecture

This model introduced a evolved Packet Data Gateway (ePDG) node which concentrates all the traffic issued or directed to the WLAN network. Its main role is to establish a secure tunnel for user data transmission with the terminal using IPSec and filter unauthorised traffic.

In this model, the new Wm interface is introduced for the purpose of exchanging user-related information from the 3GPP AAA Server to the ePDG. This will allow the ePDG to enable proper user data tunnelling and encryption to the terminal.

It is important to note, that the interfaces shown in Fig. 2-1 are logical interfaces, i.e. they have no close relation with the physical network structure and transmission. The connectivity between nodes will be handled by IP network, operating on longer distances on top of SDH transmission network and possibly on shorter distances on Carrier Ethernet, Gigabit Ethernet or

29


LTE/EPS Technology even ADSL technologies. In such case the logical interface between two nodes exist if only they are able to exchange information across IP network.

This means also, that they are aware of their functions and IP addresses, which are configured either statically by means of O&M commands or dynamically by means of some signalling protocols.

HSS

SGSN

P-GW

S-GW

MME eNodeB eNodeB

PCRF

S-GW

MME

EIR P-GW eNodeB

Figure 2-12 Interfaces & connectivity

The protocol stacks used across the EPS interfaces are listed in Fig. 2-13. eNB ↔ MME eNB ↔ S-GW

MME ↔ SGSN

S-GW ↔ SGSN

S-GW ↔ P-GW

MME ↔ HSS

SGSN ↔ HSS vS-GW ↔ hP-GW vPCRF ↔ hPCRF

MME ↔ MME

MME ↔ S-GW

S-GW ↔ RNC

MME ↔ EIR

S-GW ↔ PDN

MME ↔ MSC

MME/SGSN ↔ MSC eNB ↔ eNB

P-GW ↔ PCRF

PCRF ↔ AF

Figure 2-13 Protocols on EPS interfaces

30


2 Architecture

For all mobiles being in idle mode, location management is an important item, as the network needs to know the current terminal location at any time in case of mobile-terminated packet arrival. However, idle mode procedures do not require the network to know each terminal location with the high degree of accuracy (such as the cell level). For that reason, the concept of Tracking

Area (TA) has been introduced.

A TA is defined as a set of contiguous cells and the TAs do not overlap each other The identity of the TA the cell belongs to, or Tracking Area Identity

(TAI), is part of the system information broadcast on Broadcast Control

Channel (BCCH). When the network needs to join the UE, a paging message is sent in all the cells which belong to the TAs, the UE is registered to.

The current terminal TA is signalled to the EPC at initial registration and when UE changes the zones. In addition, the current TA is periodically updated, even if it does not change, so that the EPC network does not keep alive a context for an UE which is no longer reachable in the network. This can happen if the terminal fails to de-register or runs out of coverage.

The standard leaves the possibility for the terminal to be registered into multiple TAs. In this situation, the terminal does not perform any TA update as long as it remains under the coverage of the TAs it was registered to (like

TA1, TA2 and TA3 in Fig. 1-7), with the exception of periodic TA update.

TA#4

TA#5

TA#1

TA#2

TA#6

TA#8

TA#3

TA#9

TA#7

TA update

Figure 2-14 Tracking Area (TA)

31



The list of TAs that the UE is registered to is communicated by the network during the TA update process. The UE considers it is registered to the whole

TA list until it enters a TA which does not belong to the list, or gets an update list from the network, e.g. on the occasion of periodic TA update.

The concept of location area, such as the TA, is not new to EPS, a sit was introduced at the beginning of GSM system. Later on, when GPRS and

UMTS were introduced, this principle become more complex. In UMTS, as presented in Fig. 2-15, no less than four types of areas are being used:

•

Location Area (LA), which is a type of area supported by the CS CN domain,

•

Routing Area (RA), which is the equivalent of the LA for the PS CN domain,

•

UTRAN Registration Area (URA), which is a registration area for the use of the UMTS access network - UTRAN,

•

Cell, which provides the best accuracy localisation information.

RA #1

LA #1

RA #2

LA #2

RA #3 RA #4

LA #3

RA #5

URA #1 URA #2 URA #3

Figure 2-15 UMTS location areas

RA is defined in such a way that a LA may include one or more RA. URA was introduced to provide flexibility in UTRAN terminal location management, in connection with the protocol states which were introduced in the UTRAN RRC layer. As it is managed by the UTRAN, URA has no relation with the CN’s LA and RA.

LA and RA are quite similar to the concept of TA, as being a non-overlapping group of cells. However, the URA concept has no equivalent in E-UTRAN.

The possibility of defining overlapping URA was introduced as a way to decrease the signalling load impact of ‘URA update’, similarly to the ‘TA list registration’ concept presented above.

32


2 Architecture

From the perspective of the terminal location management, EPS has been simplified, as there is only one type of CN domain (the EPC) and no registration area has been defined for the access network – like the UTRAN’s

URA. This will also have an impact on RRC state management simplification.

Similarly to GSM/UMTS, EPS uses a number of descriptors to identify subscribers. In Fig. 2-16 the EPS nodes are presented together with the identities used by these nodes for various identification purposes.

PDP address

IMSI

IMEI

GUTI

P-TMSI

UE

P-TMSI IMSI IMEI

UTRAN

SGSN

GERAN

IMEI

E-UTRAN

IMSI

IMSI

Static PDP address

IMEI IMSI

GUTI

HSS

MME

EIR

IMEI

IMEI

S-GW

MSISDN PDP address

Figure 2-16 EPS identities

IMSI

IMEI

MSISDN

PDP address

P-GW

The unique identity for mobile subscriber is called International Mobile

Subscriber Identity (IMSI). IMSI consists of three parts:

MCC - Mobile Country Code (three digits),

MNC - Mobile Network Code (2-3 digits),

MSIN - Mobile Station Identification (up to 10 digits).

This number is stored on the USIM and acts as the unique database search key in the HSS, MME and SGSN.

33



MCC MNC

National MSI

International MSI

Figure 2-17 IMSI

MSIN

The Mobile Subscriber Integrated Services Digital Network number

(MSISDN) is a number, which uniquely identifies a mobile telephone subscription in the public switched telephone network numbering plan. These are the digits dialled when calling the mobile subscriber. The MSISDN consists of three parts:

CC - Country Code,

NDC - National Destination Code,

SN - Subscriber Number.

CC NDC SN

National Mobile Number

International Mobile ISDN Number

Figure 2-18 MSISDN

The Packet Data Protocol (PDP) address is an IP address of the mobile user.

The PDP address can be allocated dynamically or configured statically in HSS subscription profile.

The International Mobile Equipment Identity (IMEI) is a number uniquely identifying the user equipment hardware. The EIR stores IMEIs of all mobile terminals that have been ever present on a market. The IMEIs of terminals that are free to use any GSM/UMTS/EPS/IMS network are present on white list, whereas the IMEIs of terminals that have been stolen are placed on the black list.

34


2 Architecture

TAC SNR

IMEI

Figure 2-19 IMEI

spare

TAC - Type Approval Code - Is a 8 digits length code that identifies the particular type of the mobile equipment.

SNR - Serial Number (6 digits)

Spare - (1 digit)

The IMEI (14 digits) is complemented by a check digit. The check digit is not part of the digits transmitted when the IMEI is checked. The Check Digit is intended to avoid manual transmission errors, e.g. when customers register stolen mobile equipment at the operator's customer care desk.

The MME allocates a Globally Unique Temporary Identity (GUTI) to the UE.

The GUTI has two main components:

•

Globally Unique MME Identifier (GUMMEI) uniquely identifying the

MME which allocated the GUTI,

•

M-TMSI uniquely identifying the UE within the MME that allocated the GUTI.

GUTI/IMSI

GUTI ↔ IMSI

MME

IMSI

SGSN

S-GW

HSS

P-GW

IMSI new GUTI

IMSI

GUTI new GUTI

Figure 2-20 Globally Unique Temporary Identity (GUTI)

35



GUMMEI is constructed from MCC, MNC and MME Identifier (MMEI).

In turn the MMEI is constructed from an MME Group ID (MMEGI) and an

MME Code (MMEC).

For paging, the mobile is paged with the S-TMSI. The S-TMSI is constructed from the MMEC and the M-TMSI.

The operator needs to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.

The GUTI is used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more efficient radio signalling procedures.

GUMMEI

MCC MNC MMEGI MMEC

MMEI

Figure 2-21 GUTI structure

S-TMSI

M-TMSI

The Tracking Area Identity (TAI) is the identity used to identify Tracking

Areas (TAs). The Tracking Area Identity is constructed from the MCC, MNC and Tracking Area Code (TAC).

MCC MNC TAC

Figure 2-22 Tracking Area Identity (TAI)

36


3 OFDMA & SC-FDMA

Chapter 3

OFDMA & SC

Introduction...................................................................................................... 39

Fourier transform ............................................................................................. 44

Discrete Fourier Transform.............................................................................. 51

Orthogonality of frequencies ........................................................................... 53

Channel separation in FDMA .......................................................................... 54

Channel separation in OFDMA ....................................................................... 61

Transmission example ..................................................................................... 63

Implementation ................................................................................................ 65

Advantages and disadvantages ........................................................................ 69

OFDMA ........................................................................................................... 78

SC-FDMA........................................................................................................ 78


37



38


3 OFDMA & SC-FDMA

Multiple access in telecommunications systems refers to techniques that enable multiple users to share limited network resources efficiently. A telecommunications network has finite resources that are usually defined in terms of bandwidth. When there is more than one user to access such limited bandwidth, an multiple access scheme must be put in place to control the share of bandwidth among multiple users so that everyone can use services provided by the network and to make sure that no single user spends all available resources.

From a very early stage of modern communications, researchers have been working on finding the best multiple access scheme to follow the above simple rule of resource sharing among multiple users. Very visible and fundamental ways of sharing bandwidth, frequency and time separation, were chosen as the beginning of multiple access generation.

In the first multiple access communications systems, the available frequency spectrum for a given system was divided into some frequency channels where each channel occupies a portion of total available bandwidth and is given to a single user. Multiple users using separate frequency channels could access the same system without significant interference from other users concurrently operating in the system. It is the simplest way of having an scheme in a multi-user system, and it is referred to as Frequency Division Multiple Access

(FDMA). time f1 f2 f3 f4 f5 f6 f7 frequency

Figure 3-1 Frequency Division Multiple Access

39



With the same concept, Time Division Multiple Access (TDMA) schemes came to start the digital communications era by dividing the time axis into portions or time slots, each assigned to a single user to transmit data information. TDMA schemes thus came into effect through frame and multiframe concepts: a user could send a large data file within time slots of periodical frames. Data from a single user always sits in the same time slot position of a frame, so at the receiver all information from that portion can be collected and aggregated to shape the original transmitted packet. TDMA, together with Pulse Code Modulation (PCM), has become an effective way of sharing the available system resources not only in wireless communications but in wired communications since then. TDMA has kept its dominance in wired and wireless systems for many years. Many cellular standards such as the GSM/GPRS adopted TDMA as their multiple access scheme. time

TS 1

TS 2

TS 3

TS 4 frequency

Figure 3-2 Time Division Multiple Access

As is clear from the above simple review, in both FDMA and TDMA techniques, the number of channels or time slots is fixed for a given system, and a single channel is allocated to a single user for the whole period of communications.

This was not only a concept to have a simple multiple access technique in the early stage of modern telecommunications, but was based on the dominant service in mind at the time, voice communications. Having a fixed channel or time slot assignment could guarantee the service quality for real-time and constant-bit-rate voice telephony, the main service at that time. By increasing the number of services from simple voice to more burst data transmissions, fixed channel assignment has shown its lack of efficiency in utilising the scarce spectrum, especially with the exponential increase in number of users.

40


3 OFDMA & SC-FDMA

With this idea in mind, Code Division Multiple Access (CDMA) schemes based on spread spectrum technology started to come into commercial systems, different from their original environment mainly in military applications. In a CDMA system the relatively narrowband user’s information is spread into a much wider spectrum using a high clock chip rate. Using different uncorrelated codes by each user, it is possible to send multiple users’ information on the same frequency spectrum without significant difficulty in detecting the desired signal at the receiver side as long as the correct spreading code is known to the receiver. The signal from each user will have very low power and be seen by others as background noise. Therefore, as long as the total power of noise (i.e., multi-user interference) is less than a threshold, it is possible to detect the desired signal using the spreading code used to encode the signal at the transmitter. Using spread spectrum techniques, CDMA has become a dynamic channel allocation multiple access scheme that has no rigid channel allocation limitation for individual users.

The number of users is also not fixed as in TDMA and FDMA, and a new user can be added to the system at any time. The upper limit for the maximum number of simultaneous users in the system using the same frequency spectrum is decided by the effect of total power of multi-user interference; thus, adding new users to a CDMA system will only cause graceful degradation of signal quality. CDMA is thus seen as an multiple access scheme that has no fixed maximum number of users as opposed to TDMA and FDMA schemes. code code 4 code 3 code 2 time code 1 frequency

Figure 3-3 Code Division Multiple Access

With the exponential increase in the number of users for mobile cellular communications and the development of 3G wireless cellular systems,

CDMA, with its proven capacity enhancement over TDMA and FDMA, has been chosen as the main multiple access scheme for 3G mobile cellular systems.

41



CDMA schemes have some impressive advantages TDMA and FDMA do not have. One is tolerance to the effects of multipath propagation. In CDMA we can apply a Rake diversity technique that can improve performance against severe multipath fading channels. Another advantage in cellular mobile systems based on CDMA is that we can achieve efficient frequency reuse.

Because users are distinguished by their own codes, every cell can use the same frequency (i.e. frequency re-use of one); therefore, we can obtain higher spectral efficiency. Additionally, soft handover among cells is achievable.

On the other hand, a considerable problem in CDMA is interference from other users. A value of cross-correlation is usually non-zero in CDMA, and it limits channel capacity. In cellular mobile systems with CDMA, we face also the near-far problem. A signal transmitted by a user who is far from the base station can easily be blocked by a signal from a nearby user. To solve the near-far problem, we should therefore introduce a power control technique in

CDMA systems to maintain the quality of signals from far users. Thus, the base station should frequently send power control information to every user.

Another important multiple access scheme is Space Division Multiple Access

(SDMA) that can provide high channel capacity in mobile cellular systems. In

SDMA, as its name indicates, users are separated in a spatial way, which is very different from the multiple access schemes discussed earlier. In this scheme generally an adaptive array antenna technique is adopted. The adaptive array antenna can make the beam pattern flexible as needed, and therefore it is possible to make each suitable beam pattern correspond to one user. One remarkable advantage is that every user can share the same channel resource such as frequency and/or time. This property suggests that SDMA can easily enhance channel capacity by collaborating with other multiple access schemes such as FDMA, TDMA, and CDMA. One disadvantage of

SDMA is that the multiple access gain is considerably influenced by the location of users. We face the difficulty of separating two users who are placed near the base station. The other problem is the complexity of hardware for tracking the signals. The mobile terminal continuously and sometimes rapidly changes its location. In order to keep a high C/I, there is a need for an accurate and rapid tracking algorithm. In SDMA, in addition to inter-cell handover, we have to consider an internal handover technique, which will occur when the beams from two users get close and finally cross over each other.

42


3 OFDMA & SC-FDMA

Orthogonal Frequency Division Multiple Access (OFDMA) is a multi-carrier transmission technique that has been recently recognised as an excellent method for high speed wireless data communication. Its history dates back to the 1960s, but it has recently become popular because economical integrated circuits that can perform the high speed digital operations necessary have become available. OFDMA effectively squeezes multiple modulated carriers tightly together, reducing the required bandwidth but keeping the modulated signals orthogonal so they do not interfere with each other. Today, the technology is used in such systems as ADSL as well as wireless systems such as IEEE 802.11a/g (Wi-Fi) and IEEE 802.16 (WiMAX). It is also used for wireless digital audio and video broadcasting. OFDMA was also chosen by

3GPP for LTE/E-UTRAN system.

It is based on FDMA, which is a technology that uses multiple frequencies to simultaneously transmit multiple signals in parallel. Each signal has its own frequency range (subcarrier) which is then modulated by data. Each sub-carrier is separated by a guard band to ensure that they do not overlap.

These sub-carriers are then demodulated at the receiver by using filters to separate the bands. time frequency f1 f2 f3 f4 f5 f6 f7

Figure 3-4 Orthogonal Frequency Division Multiple Access

OFDMA is similar to FDMA but much more spectrally efficient by spacing the sub-channels much closer together (until they are actually overlapping).

This is done by finding frequencies that are orthogonal, which means that they are perpendicular in a mathematical sense, allowing the spectrum of each sub-channel to overlap another without interfering with it. In Fig. 3-5, the effect of this is seen as the required bandwidth is greatly reduced by removing guard bands and allowing signals to overlap. In order to demodulate the signal, a Discrete Fourier Transform (DFT) is needed. Fast Fourier transform

(FFT) chips are commercially available, making this a relatively easy operation.

43



FDM

f

OFDM

f

Figure 3-5 FDM & OFDM – channels spacing

In its most basic form, each data sub-carrier could be on or off to indicate a one or zero bit of information. However, either QPSK or 16QAM or even a higher order modulation is typically employed to increase the data throughput.

The Fourier transform decomposes or separates a waveform or function into sinusoids of different frequency which sum to the original waveform. It identifies or distinguishes the different frequency sinusoids and their respective amplitudes. The Fourier transform is used in many fields of science as a mathematical or physical tool to alter a problem into one that can be more easily solved.

The Fourier transform of f

( )

is defined as

F

=

∞

∫

− ∞ f e

− j 2

π xs dx .

Applying the same transform to F

( )

gives f

=

∞

∫

− ∞

F e

− j 2

π xs dx .

If f f

( )

( )

is an odd function of x , that is

When f

is an even function of x , that is

( ) f

( ) f

= − f

( )

, than

, than f f w

=

( ) ( )

is neither even nor odd, it can often be split into even or odd

. If

. parts.

To avoid confusion, it is customary to write the Fourier transform and its inverse so that they exhibit reversibility:

44


3 OFDMA & SC-FDMA

F f

=

∞

∫

− ∞ f

= ∫

−

∞

∞

F e

− j 2

π xs dx e j 2

π xs ds so that f

=

∞

∫ ∫

− ∞





−

∞

∞ f e

− j 2

π xs dx



 e j 2

π xs ds as long as the integral exists and any discontinuities, usually represented by multiple integrals of the form quantity

1 [ f

2

F

( )

is often represented as f

~

+ f x

−

]

, are finite. The transform

and a Fourier transform is often represented by the operator F .

Since the Fourier transform function f

( )

F

( )

is a frequency domain representation of a

the s characterises the frequency of the decomposed cosinusoids and sinusoids and is equal to the number of cycles per unit of x. If a function or waveform is not periodic then the Fourier transform of the function will be a continuous function of frequency. f(x) |f(s)| x s

Figure 3-6 Fourier transform

It is often useful to think of functions and their transforms as occupying two domains. These domains are officially referred to as the function and transform domains, but in most physics applications they are simply called the time and frequency domains respectively. Operations performed in one domain have corresponding operations in the other. For example, the convolution operation in the time domain becomes a multiplication operation in the frequency domain, that is true, F

( )

⊗

G

( )

↔ f

( ) ( ) f

( ) ( )

↔

F

( ) ( )

. The reverse is also

. Such theorems allow one to move between domains so that operations can be performed where they are easiest or most advantageous.

45


LTE/EPS Technology f(t) |F(f)| t

Figure 3-7 Time and frequency domain

This section presents examples of some practical functions and their Fourier transforms.

In the time domain the function is given as f

( )

= cos

( )

, where f is frequency. The Fourier transform of this function is (i.e. its frequency domain representation) is given as

F

( )

=

1

2

[

δ ( s

− f

) ( s

+ f

) ] f(t) F(s) t s

Figure 3-8 Fourier transform of a cosine


( )

= sin

( )

, where f is frequency. The Fourier transform of this function is (i.e. its frequency domain representation) is given as

F

=

1

2 i

[ δ ( s

− f

) ( s

+ f

) ]

46


f

3 OFDMA & SC-FDMA

Fourier transform of a unit


=

1 .

The Fourier transform of this function is (i.e. its frequency domain representation) is given as

F . f(t) F(s) t s

Figure 3-9 Fourier transform of a unit

Fourier transform of a Dirac


=

 ∞



 0 ,

, t t

=

≠

0

0

.


F

( )

=

1 . f(t) F(s) t s

Figure 3-10 Fourier transform of a Dirac delta function

Fourier transform of a


= rect

=











0

0 , 5

1 if if if t t t

>

=

0

0 ,

, 5

5

<

0 , 5

.

47




F

= sin

( )

. s f(t) F(s) t s

Figure 3-11 Fourier transform of a rectangular pulse


= e

− π t

2

.


F

( )

= e

− π t

2

. f(t) F(s) t s

Figure 3-12 Fourier transform of a Gaussian function

Some basic Fourier transform properties

Adding two functions together adds their Fourier transforms together:

F (f+g)= F (f)+ F (g).

This property is illustrated in Fig. 3-13, where we have a Fourier transform of two cosine functions and a Fourier transform of their superposition.

48


3 OFDMA & SC-FDMA

F (f) f(t) t g(t) F (g) t f(t)+g(t)

F (f+g) t

Figure 3-13 Fourier transform linearity (part 1)

Multiplying a function by a scalar constant multiplies its Fourier transform by the same constant:

F (a · f)=a · F (f).

This property is illustrated in Fig. 3-14, where we have a Fourier transform of two cosine functions of different amplitude. f(t) F (f) t a

·

f(t) a

·

F (f) t

Figure 3-14 Fourier transform linearity (part 2)


49


Translating a function leaves the magnitude unchanged and adds a constant to the phase.

If f

2

= f

1

(t − a)

F

1

= F (f

1

)

F

2

= F (f

2

) then

| F

2

| = | F

1

|

Φ ( F

2

) = Φ ( F

1

) − 2 π sa

If f

2

= f

1

(a · t)

F

1

= F (f

1

)

F

2

= F (f

2

) than

F

2

=

1 a

F

1



 s a





This property is illustrated in Fig. 3-15, where we have a Fourier transform of two rectangular pulses of different length. f(t) F (f) t f(a · t)

F (a

· f) t

Figure 3-15 Change of scale

50


3 OFDMA & SC-FDMA

Total ‘energy’ of the signal, calculated as the sum of squares of the function and its transform is the same.

−

∞

∫

∞

|f(t)|² dt =

−

∞

∫

∞

| F (s)|² ds

The Fourier transform of the signal can be used to find the spectrum of the signal, that is to calculate the image or distribution of components of any electromagnetic radiation arranged in the progressive series according to wavelength or frequency.

The most important parameters of the signal are amplitude and phase, hence the Fourier transform is very often presented as amplitude spectrum and phase spectrum of the signal.

Fig. 3-16 illustrates the amplitude and phase spectrum of the rectangular pulse. f(t) t

|

F

|

π

(

F

)

0

Figure 3-16 Amplitude and phase spectrum of the rectangular pulse

Because a digital computer works only with discrete data, numerical computation of the Fourier transform of f(t) requires discrete sample values of

f(t) which are called later in this section f k

. In addition, a computer can compute the transform F(s) only at discrete values of s that is, it can only provide discrete samples of the transform, F r

. If f(kT) and F(rs

0

) are the k-th

51


LTE/EPS Technology and r-th samples of f(t) and F(s), respectively, and N

0

is the number of samples in the signal in one period T

0

, then f k

=

Tf

=

T

0

N

0 f and

F r

=

F where s

0

=

2

π

T

0

.

The Discrete Fourier Transform (DFT) is defined as

F r

=

N k

0 ∑

=

−

1

0 f k e

− ir

Ω

0 k where

Ω

0

=

2

π

N

0

. Its inverse is f k

=

1

N

0

N r

0 ∑

=

−

1

0

F r e ir

Ω

0 k .

These equations can be used to compute transforms and inverse transforms of appropriately sampled data.

2

1

0

-1

-2

0

1

0.2

0.4

0.6

0.8

1 t[s]

0.5

0

0 2 4 6 8 czestotliwosc w Hz

10 12 14 f[Hz]

Figure 3-17 Discrete Fourier Transform (DFT)

Please note, that the spectrum samples are valid till the half of the sampling frequency, i.e. in Fig. 3-17 the valid spectrum is from 0 to 7 Hz.

52


3 OFDMA & SC-FDMA

The Fast Fourier Transform (FFT) is a DFT algorithm developed by John

Tukey and James Cooley in 1965 which reduces the number of computations on the order of N 2

0

to N

0 log N

0

. The algorithm is simplified if to be a power 2, but it is not a requirement.

The carriers in telecommunications are all sine / cosine wave. The area under one period of sine or cosine wave is zero.

0 0

+ + +

-

T T

Figure 3-18 Area under sine / cosine wave over one period

Let’s take a sine wave of frequency m and multiply it by a sinusoid (sine or cosine) of a frequency n, where both m and n are integers. The integral or the area under this product is given by f

= sin m

ω t

× sin n

ω t .

m=1 , n=4

0 0

T T

Figure 3-19 Sine wave multiplied by its own harmonic

53



Since, by the simple trigonometric relationship, the product of two sinusoids of frequencies n and m is equal to a sum of two sinusoids of frequencies (n-m) and (n+m), the integral of this product is sin m

ω t

× sin n

ω t

= ∫

2

π

0

1

2 cos

( m

− n

) ω t dt

−

2

π

∫

0

1

2 cos

( m

+ n

) ω t dt

=

0

These two components are each a sinusoid, so the integral is equal to zero over one period.

When a sinusoid of frequency n is multiplied by a sinusoid of frequency m/n, the area under the product is zero. In general for all integers n and m, sinmx, cosmx, sinnx, cosnx are all orthogonal to each other. These frequencies are called harmonics.

Having a bandwidth that goes from frequency a to b, it is possible to subdivide this into a several equal frequency channels. system bandwidth a ch #1 ch #2 ch #3 ch #4 ch #5 ch #6

Figure 3-20 Channel separation in FDMA ch #n b f

The frequencies a and b can be anything, integer or non-integer since no relationship is implied between a and b. Same is true of carrier frequencies which are based on frequencies that do not have any special relationship to each other.

Before the digital signal can be sent over the air interface first it has to be filtered and than modulated. Filtering is aimed at shaping the signal bandwidth and modulation is responsible for ‘moving’ the data onto the carrier frequency in order to send it, i.e. modulation moves the spectrum of the signals into higher frequency

54


3 OFDMA & SC-FDMA

Filtering data signal pulse shaping

Modulation cos( ω t)

RF

10

0

-10

-20

-30

-40

-50

0 0.1

0.2

0.3

0.4

Frequency

0.5

0.6

-10

-20

-30

10

0

-40

-50

-60

0 0.1

0.2

0.3

0.4

Frequency

0.5

0.6

80

60

40

20

0

-20

-40

0.2

0.4

0.6

0.8

1 1.2

Frequency

1.4

1.6

1.8

x 107

Figure 3-21 Filtering and modulation processes

Transmission of modulated signals over the air interface requires a frequency channel of a proper width. The wider the channel, the more data can be sent.

The relation between the channel width and maximum data rate possible to be sent over that channel depends among others on the used modulation scheme.

Theoretically the spectrum of a rectangular-shaped signal is infinite. f

Figure 3-22 Spectrum of rectangular-shaped signal

In order to be able to allocate different frequency channels to different transmissions and for different applications, the spectrum of a signal must be filtered and thus limited. f

LPF

G

1

0

Figure 3-23 Filtering of rectangular pulse (frequency domain) f

55



Filtering however affects the signal appearance in time-domain: the more limited spectrum the more disturbed signal and the more difficult detection.

The rectangular signal after channel filtering becomes more ‘spread’ and delayed in time (so called signal ringing appears) and can possibly interfere with subsequent signals, causing in effect higher Bit Error Rate (BER).

Therefore a trade-off must be achieved: on one hand the need is to avoid

Adjacent Channel Interference (ACI), and on the other hand the requirement is to limit Inter Symbol Interference (ISI). This is a compromise between spectral efficiency and BER. ringing

LPF t

Figure 3-24 Filtering of rectangular pulse (time domain) t

For the above reasons filtering is commonly known also as pulse shaping.

One of the most popular types of filters used in telecommunications for pulse-shaping is a Root Raised Cosine (RRC) filter. The typical values of roll-off factor (parameter α ) are around 0.25. In general, the roll-off factor can vary between 0 and 1, resulting in different bandwidth of the filtered signal.

The lower the α the more limited the spectrum.

0.9

1 gain

α

= 0.1

= 0.3

α

= 0.5

0.8

0.7

0.6

0.5

0.4

0.3

0.2

0.1

0

0 50 100 150 200 250

α

= 0.7

α

= 0.9

frequency

300

Figure 3-25 Root Raised Cosine filter

The impulse response of the RRC filter is also dependent on the α parameter, as depicted in Fig. 3-26, the lower the roll-off factor the more ringing can be observed.

RRC filter has an interesting property that makes its application efficient. It may be noticed that independently on the roll-off factor, ringing is zero at certain time instants. If sampling of the signal is done at those time instants, theoretically there is no ISI. Practically ISI appears due to timing jitter, which is bigger for lower α values.

56


3 OFDMA & SC-FDMA

1

0.8

0.6

0.4

-0.2

-0.4

0.2

0

= 0.3

α

= 0.01

t1 t2 t3 t4 t5 t6 t7 t8 t9

Figure 3-26 Root Raised Cosine filter – impulse response

There are three major classes of digital modulation techniques used for transmission of digitally represented data:

•

Amplitude Shift keying (ASK),

•

Frequency Shift keying (FSK),

•

Phase Shift keying (PSK).

All convey data by changing some aspect of a base signal, the carrier wave,

(usually a sinusoid) in response to a data signal. In the case of PSK, the phase is changed to represent the data signal. There are two fundamental ways of utilising the phase of a signal in this way:

• by viewing the phase itself as conveying the information, in which case the demodulator must have a reference signal to compare the received signal's phase against; or

• by viewing the change in the phase as conveying information - differential schemes, some of which do not need a reference carrier (to a certain extent).

A convenient way to represent PSK schemes is on a constellation diagram.

This shows the points in the Argand plane where, in this context, the real and imaginary axes are termed the in-phase and quadrature axes respectively due to their 90° separation. Such a representation on perpendicular axes lends itself to straightforward implementation. The amplitude of each point along the in-phase axis is used to modulate a cosine (or sine) wave and the amplitude along the quadrature axis to modulate a sine (or cosine) wave.

In PSK, the constellation points chosen are usually positioned with uniform angular spacing around a circle. This gives maximum phase-separation between adjacent points and thus the best immunity to corruption. They are

57


LTE/EPS Technology positioned on a circle so that they can all be transmitted with the same energy.

In this way, the moduli of the complex numbers they represent will be the same and thus so will the amplitudes needed for the cosine and sine waves.

Two common examples are Binary Phase Shift Keying (BPSK) which uses two phases, and Quadrature Phase Shift Keying (QPSK) which uses four phases, although any number of phases may be used. Since the data to be conveyed are usually binary, the PSK scheme is usually designed with the number of constellation points being a power of 2.

BPSK is the simplest form of PSK. It uses two phases which are separated by

180° and so can also be termed 2-PSK. It does not particularly matter exactly where the constellation points are positioned, and in this figure they are shown on the real axis, at 0° and 180°. This modulation is the most robust of all the PSKs since it takes serious distortion to make the demodulator reach an incorrect decision. It is, however, only able to modulate at 1 bit/symbol (as seen in the figure) and so is unsuitable for high data-rate applications when bandwidth is limited.

Sometimes known as quaternary or quadriphase PSK or 4-PSK, QPSK uses four points on the constellation diagram, equispaced around a circle. With four phases, QPSK can encode two bits per symbol, shown in the diagram with Gray coding to minimise the BER - twice the rate of BPSK. Analysis shows that this may be used either to double the data rate compared to a

BPSK system while maintaining the bandwidth of the signal or to maintain the data rate of BPSK but halve the bandwidth needed.

Although QPSK can be viewed as a quaternary modulation, it is easier to see it as two independently modulated quadrature carriers. With this interpretation, the even (or odd) bits are used to modulate the in-phase component of the carrier, while the odd (or even) bits are used to modulate the quadrature-phase component of the carrier. BPSK is used on both carriers and they can be independently demodulated.

QPSK systems can be implemented in a number of ways. An illustration of the major components of the transmitter and receiver structure are shown in

Fig. 3-27.

The binary data stream is split into the in-phase and quadrature-phase components. These are then separately modulated onto two orthogonal basis

58


3 OFDMA & SC-FDMA functions. In this implementation, two sinusoids are used. Afterwards, the two signals are superimposed, and the resulting signal is the QPSK signal. Note the use of polar non-return-to-zero encoding.

digital signals analogue signals

+1

1 0 0 1 NRZ coder

-1 cos(

ω t)

I binary bitstream

11000110

QPSK signal oscillator

1 0 1 0 NRZ coder phase shift sin(

ω t)

Q

Figure 3-27 QPSK transmitter

The modulated signal is shown below for a short segment of a binary data stream. The two carrier waves are a cosine wave and a sine wave, as indicated by the signal-space analysis above. Here, the odd-numbered bits have been assigned to the in-phase component and the even-numbered bits to the quadrature component. The total signal - the sum of the two components - is shown at the bottom. Jumps in phase can be seen as the PSK changes the phase on each component at the start of each bit-period. The topmost waveform alone matches the description given for BPSK above.

1 0 0 1

I

1 0 1 0

Q

0

11 00 01

T s

2T s

3T s

Figure 3-28 QPSK signal in time domain

10

QPSK

4T s

59



BPSK transmitter can be implemented in a very similar way, with that difference, that only in-phase component is used.

1 digital signal binary bitstream 1 0 0 1 analogue signal

NRZ coder

+1

-1

BPSK signal cos(

ω t) oscillator

Figure 3-29 BPSK transmitter

0 0 1

BPSK

0 T s

2T s

3T s

Figure 3-30 BPSK signal in time domain

4T s

Bandwidth efficiency

The symbol rate that can be carried by a PSK carrier of a certain bandwidth, is given by:

R s

=

2 B l

=

B p

Where

This relation assumes a perfect filtering with roll-off equal to zero. Since this is unachievable, we use root raised cosine filtering which for a roll-off of α gives the following relationship.

R s

=

1

B p

+ α

So if we need three carriers, each of data rate 20 Mbps and we assume usage of BPSK, the R would be equal to 20 Msps. For the α =0,25 this results in the required bandwidth B p

=

R s

(

1

+ α )

=

20 Msps

⋅

( 1

+

0 , 25 )

=

25 MHz . If additionally we assume guard band β =10%, each carrier may be placed 27,5

MHz apart. The frequencies would not be orthogonal but in FDMA we do not care about this. It is the guard band that helps keep interference under control.

60


3 OFDMA & SC-FDMA

(1+ α )(1+ β )R s

(1+ α )R s

R s f ch n-1 ch n ch n+1

Figure 3-31 FDMA bandwidth efficiency

All together to support 3 · 20 Mbps = 60 Mbps, with BPSK modulation, we need 3 · 27,5 MHz = 82,5 MHz, which gives bandwidth efficiency of 60 Mbps

/ 82,5 MHz = 0,73 bpHz.

Without assumptions about the symbol rate and the type of the modulation we can write that the bandwidth efficiency is:

E b

=

1

(

1

+

)( β ) [spHz]

For the typical values of α =0,25 β =0,1

C hannel separation in OFDMA

In OFDMA, the sub-carrier frequencies are chosen so that the sub-carriers are orthogonal to each other, meaning that cross-talk between the sub-channels is eliminated and inter-carrier guard bands are not required. This greatly simplifies the design of both the transmitter and the receiver; unlike conventional FDMA, a separate filter for each sub-channel is not required.

The transmission of rectangular pulses is central to the ability to space subcarriers very closely in frequency domain without creating Inter Carrier

Interference (ICI). We may recall that a uniform rectangular pulse in the time domain results in a function sin(x)/x in the frequency domain as shown in

Fig. 3-32. The LTE’s OFDMA symbol period is 66.6(6) µ s (1/15 kHz), which results in sin(x)/x pattern in the frequency domain with uniformly spaced zero-crossings at 15 kHz intervals.

61


LTE/EPS Technology t

66.6 µ s

(1/15 kHz) f

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

Figure 3-32 OFDMA - spectrum of the rectangular pulse

Modulation moves the spectrum of the signals into a proper frequency, very close to the next modulated subcarrier, so that centres of the subcarriers are located at the zero crossings of other subcarriers’ spectrum, i.e. subcarrier separation is 15 kHz. Having a combined signal of N sub-carriers in the baseband frequency it is than possible to shift the entire spectrum of N sub-carriers into a suitable RF band. f

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

Figure 3-33 OFDMA signal spectrum

On the receiver side, it is therefore possible, to detect the phase of the signal at the centre frequency of each subcarrier while encountering no interference from neighbouring subcarriers.

Bandwidth efficiency

QPSK signal produces a spectrum such that its bandwidth is equal to

(1+ α ) R s

. In OFDM, the adjacent carriers can overlap in the manner shown below. The addition of two sub-carriers carriers (red and pink colours) to the existing sub-carrier (brown colour) now allows transmitting 3 bandwidth of -2 of 0,75 spHz, which is comparable to the efficiency of the FDMA system.

62


3 OFDMA & SC-FDMA

However when more and more carriers are added, the efficiency is growing, reaching for a large number of subcarriers efficiency closed to 1 spHz.

Without making any assumptions about the number of sub-carriers N, the effective bandwidth

E b

=

N

N

⋅

+

R s

1

.

R s

1 2 3 N

Figure 3-34 OFDMA bandwidth efficiency f

Transmission example

In LTE we have N carriers, where N can be anything from 72 to 1200 in present technology and depends on the environment in which the system will be used.

Let’s examine the bit sequence (see Fig. 3-35) we wish to transmit and show the development of the OFDM signal using 4 sub-carriers. Let’s now write these bits in four rows, since this demonstration will use only four sub-carriers. We have effectively done a serial to parallel conversion.

..., 1 , 1 , 1 , 0 , 0 , 1 , 1 , 1 , 0 , 0 , 1 , 1 , 1 , 0 , 1 , 0 , 0 , 0 , 0 , 1 , 1 , 0 , 0 , 1

...0

, 1 , 1 , 0 , 1 , 1

...1

, 1 , 1 , 1 , 0 , 0

...1

, 0 , 0 , 0 , 0 , 0

...1

, 1 , 0 , 1 , 0 , 1

Fig. 3-35 Serial to parallel conversion

Each row represents the bits that will be carried by one sub-carrier. Let’s start with the first carrier, c

1

.

We have chosen QPSK as our modulation scheme for this example. Note that it is possible to use any other modulation method, BPSK, 16QAM, 64QAM or even higher.

c

1

c

2

c

3

c

4

63



On c

1 we need to transmit 0,1,1,0,1,1, which is shown below superimposed on the BPSK carrier frequency c

1

.

01 10 11

Figure 3-36 Modulated sub-carrier 1

The next carrier is c

2

, which is the next orthogonal/harmonic to c

1

, takes the bits in the second row, i.e. 1,1,1,1,0,0.

11 11 00


The next two carriers c

3

,c

4

are modulated with 1,0,0,0,0,0 and 1,1,0,1,0,1 respectively.

10 00 00

11


01 01

64



3 OFDMA & SC-FDMA

What we have done is taken the bit stream, distributed the bits, one bit at a time to each sub-carrier as shown below. Now its it time to add all of these modulated carriers to create the OFDM signal. Note how much it varies compared to the underlying constant amplitude sub-carriers.

1 1 1 0 0 1 1 1 0 0 1 1 1 0 1 0 0 0 0 1 1 0 0 1

Figure 3-40 OFDM signal

The basic block diagram of the OFDM transmitter is shown in Fig. 3-41. constellation mapping

X

0

Re

D/A

X

1 s[n] s(t)

CP f

X

N-2

X

N-1

Im

D/A

Figure 3-41 OFDM transmitter

The incoming data are first serial to parallel converted in order to create N data streams for N sub-carriers.

65



The constellation mapper, that works independently for each sub-carrier, converts input data into complexed valued constellation points, according to a given constellation. BPSK, QPSK, 16 QAM and 64QAM are the typical constellations for wireless applications.

BPSK QPSK 16QAM 64QAM

Figure 3-42 Typical constellations for wireless applications

The amount of data transmitted on each subcarrier depends on the constellation, e.g. BPSK and 16QAM transmit one and four data bits per sub-carrier, respectively. Which constellation to choose depends on the channel quality. In a high interference channel a small constellation like

BPSK is favourable, since the required Signal-to-Noise Ratio (SNR) in the receiver is low, whereas in a low interference channel a larger constellation is more beneficial due to the higher bit rate.

Please note that, the complex value going out from a constellation mapper is in fact a value of the Fourier transform for the frequency of the sub-carrier. In other words, the values going out from the constellation points are giving the spectrum of the OFDM signal sampled at the frequencies of sub-carriers.

11

Q {Im} j

(11)

2

π /4

1 I {Re}

1+j

1

+ j

=

2 e

− j

π

4

QPSK

2

| F |

(

F )

π /4 c n-1 c n c n+1

-3 π /4 c n-1 c n c n+1

Figure 3-43 Constellation mapper output = spectrum sample

66


3 OFDMA & SC-FDMA

An Inverse Fast Fourier Transform (IFFT or FFT

-1

) is computed on each set of symbols, giving a set of complex time-domain samples.

As this step can be quite confusing below two extra diagrams presents the

‘straight forward’ method of OFDM signal generation and the method based on IFFT computation. As can be seen there is no difference in terms of output signal from the transmitter, however the second method requires much less processing power. c

1 c

2 c

3 c n

Σ

D/A

Figure 3-44 OFDM signal generation (approach 1)

Re

D/A f

Im

D/A

90 0 s(t)

Figure 3-45 OFDM signal generation (approach 2)

The Cyclic Prefix (CP) is a copy of the last n samples from the IFFT, which are placed at the beginning of the OFDM symbol. The function of the CP is described later in this chapter.

67



The real and imaginary components of the digital samples coming from the

CP insertion block are first converted to the analogue domain using

Digital-to-Analogue Converters (DACs).

The analogue signals are then used to modulate cosine and sine waves at the carrier frequency, f c

, respectively. These signals are then summed to give the transmission signal, s(t).

The basic block diagram of the OFDM receiver is shown in Fig. 3-46. r(t)

90 0 f

A/D

Re

CP

Y

0 symbol detection

Y

1

FFT

Y

N-2

A/D

Im

Figure 3-46 OFDM receiver

Y

N-1 ŝ [n]

The receiver picks up the signal r(t), which is then quadrature-mixed down to baseband using cosine and sine waves at the carrier frequency. This also creates signals centered on 2f c

, so low-pass filters are used to reject these. The baseband signals are then sampled and digitised using Analogue-to-Digital

Converters (ADCs), and a forward FFT is used to convert back to the frequency domain.

This returns N parallel streams, each of which is converted to a binary stream using an appropriate symbol detector. These streams are then re-combined into a serial stream, s(t), which is an estimate of the original binary stream at the transmitter.

68


3 OFDMA & SC-FDMA

A dvantages and disadvantages

When information is transmitted over a wireless channel, the signal can be distorted due to multipath. Typically (but not always) there is a line-of-sight path between the transmitter and receiver. In addition, there are many other paths created by signal reflection off buildings, vehicles and other obstructions as shown in Fig. 3-47.

Figure 3-47 Multipath propagation

Signals travelling along these paths all reach the receiver, but are shifted in time by an amount corresponding to the differences in the distance travelled along each path.

To date, cellular systems have used single carrier modulation schemes almost exclusively. Although LTE uses OFDM rather than single carrier modulation, it’s instructive to briefly discuss how single carrier systems deal with multipath-induced channel distortion. This will form a point of reference from which OFDM systems can be compared and contrasted.

The term delay spread describes the amount of time delay at the receiver from a signal travelling from the transmitter along different paths. In cellular applications, delay spreads can be several microseconds. The delay induced by multipath can cause a symbol received along a delayed path to ‘bleed’ into a subsequent symbol arriving at the receiver via a more direct path. This effect is depicted in Fig. 3-48 and is referred to as Inter Symbol Interference

(ISI). In a conventional single carrier system symbol times decrease as data rates increase. At very high data rates (with correspondingly shorter symbol periods), it is quite possible for ISI to exceed an entire symbol period and spill into a second or third subsequent symbol.

69


LTE/EPS Technology symbol duration signal received via direct path

ISI ISI ISI ISI delayed signal received via longer path

Figure 3-48 Inter Symbol Interference (ISI)

It’s also helpful to consider the effects of multipath distortion in the frequency domain. Each different path length and reflection will result in a specific phase shift. As all of the signals are combined at the receiver, some frequencies within the signal band undergo constructive interference (linear combination of signals in-phase), while others encounter destructive interference (linear combination of signals out-of-phase). The composite received signal is distorted by frequency selective fading (see Fig. 3-49). signal bandwidth signal bandwidth multipath distortions f

Tx

Figure 3-49 Frequency selective fading

Rx

Single carrier systems compensate for channel distortion via time domain equalisation by one of two methods:

•

Channel inversion: A known sequence is transmitted over the channel prior to sending information. Because the original signal is known at the receiver, a channel equaliser is able to determine the channel response and multiply the subsequent data-bearing signal by the inverse of the channel response to reverse the effects of multipath.

•

Rake equalisers (CDMA systems) to resolve the individual paths and then combine digital copies of the received signal shifted in time to enhance the receiver Signal-to-Noise Ratio (SNR).

In either case, channel equaliser implementation becomes increasingly complex as data rates increase. Symbol times become shorter and receiver sample clocks must become correspondingly faster. ISI becomes much more severe - possibly spanning several symbol periods.

The finite impulse response transversal filter is a common equaliser topology.

As the period of the receiver sample clock decreases, more samples are f

70


3 OFDMA & SC-FDMA required to compensate for a given amount of delay spread. The number of delay taps increases along with the speed and complexity of the adaptive algorithm.

τ τ τ τ τ

∑

adaptive algorithm

Figure 3-50 Traversal filter channel equalizer

For LTE data rates (up to 100 Mbps) and delay spreads (approaching 17 µ s), this approach to channel equalisation becomes impractical. As we will discuss below, OFDM eliminates ISI in the time domain, which dramatically simplifies the task of channel compensation.

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, 16QAM, 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 sub carriers 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 (no 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.

To understand how OFDM deals with ISI induced by multipath, consider the time domain representation of an OFDM symbol shown in Fig. 3-51. The

OFDM symbol consists of two major components: the CP and an FFT period

(T

FFT

). 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 Fig. 3-51.

71


LTE/EPS Technology delay < CP

T

FFT

=66,667 µ s

CP=4,6875 µ s baseband processor strips off CP

Figure 3-51 ISI elimination (longer symbol period & cyclic prefix)

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-bysubcarrier basis.

Note that all of the information of relevance to the receiver is contained within the FFT period. Once the signal is received and digitised, 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.

An OFDMA signal offers also an advantage in channel that has a frequency selective fading response. As we can see in Fig. 3-52, when OFDM signal is laid against the frequency selective response of the channel, only some of the sub-carriers are affected. Instead of the whole symbol being knocked out, just a small subset of the (1/N) bits is lost. With proper coding, this can be recovered. channel quality

Figure 3-52 OFDM and frequency selective fading f

The BER performance of an OFDM signal in a fading channel is much better then the performance of QPSK/FDM which is a single carrier wideband signal. Although the underlying BER of a OFDM signal is exactly the same as the underlying modulation, that is if 8PSK is used to modulate the

72


3 OFDMA & SC-FDMA sub-carriers, then the BER of the OFDM signal is same as the BER of 8PSK signal in Gaussian channel. But in channels that are fading, the OFDM offers far better BER than a wide band signal of exactly the same modulation. The advantage here is coming from the diversity of the multi-carrier such that the fading applies only to a small subset.

Cy clic prefix

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.

CP CP CP CP

Figure 3-53 Cyclic prefix

CP CP

Cyclic prefix can not be a blank space in the signal, as the signals in practice must be continuous.

The first choice to fill the cyclic prefix space is to run the preceding symbol longer, i.e. to extend the symbol into the empty space, so the actual symbol is more than one cycle. In that case however, the start of the symbol that is vital for the correct bit(s) detection is still in the dangerous zone, as the discontinuity of the signal causes distortion in both time and frequency domain.

CP CP CP CP CP CP

Figure 3-54 Cyclic prefix as an extension of the preceding symbol

The second and a correct choice is to fill the cyclic prefix space by the copy of the current symbol’s tail. In that case the start of the symbol is outside the delay spread zone and at the beginning of the symbol the signal is perfectly continuous, which means that there are no distortions in the area where the signals samples are taken.

73



CP CP CP CP

CP CP

Figure 3-55 Cyclic prefix as a copy of the current symbol’s tail

This procedure is called adding a Cyclic Prefix (CP). In theory since OFDM, has a lot of carriers, it must be done to each and every carrier. In reality since

OFDM signal is a linear combination, it is possible to add cyclic prefix just once to the composite OFDM signal. copy copy

Figure 3-56 Addition of the cyclic prefix (part 1)

Prefix is added just once to the composite signal after doing IFFT. After the signal has arrived at the receiver, first prefix is removed, to get back the perfectly periodic signal so it can be FFT’d to get back the symbols on each carrier. serial to parallel conversion add cyclic prefix remove cyclic prefix

FFT parallel to serial conversion

Figure 3-57 Addition of the cyclic prefix (part 2)

74


3 OFDMA & SC-FDMA

Fig. 3-58 presents the spectrum of the OFDM signal. Note that the out of band signal is down by 50 dB without any pulse shaping or filtering.

-0.5

-0.4

-0.3

-0.2

-0.1

[dB]

0.0

0.1

0.2

0.3

0.4

0.5

-50

-100

-150

-200

Figure 3-58 Spectrum of the OFDM signal (1024 sub-carriers)

Compare this to the spectrum of a QPSK signal, note how much lower the sidebands are for OFDM and how much less in the variance.

-0.5

-0.4

-0.3

-0.2

-0.1

[dB]

0.0

0.1

0.2

0.3

0.4

0.5

-20

-40

-60

-80

-100

Figure 3-59 The spectrum of a QPSK signal

OFDM systems can achieve zero-ICI if each subcarrier is sampled precisely at its center frequency. The time-sampled OFDM signal is converted into the frequency domain by means of an FFT.

Let’s consider a specific LTE example. LTE defines transmission bandwidths from 1.25 MHz up to 20 MHz. In the case of 1.25 MHz transmission bandwidth, the FFT size is 128. In other words, 128 samples are taken within

75


LTE/EPS Technology the FFT period of 66.67 µ s. Therefore, Ts = 0.52086 µ s, and the received signal is represented by frequencies at 15 kHz, 30 kHz, 45 kHz… These frequencies are the exact centre frequencies of the signal subcarriers - unless frequency errors are encountered in the down conversion process.

The FFT is done at baseband frequency, after the received signal has been down converted from the RF carrier frequency. Down conversion is typically performed by means of direct conversion. The received signal is mixed with a signal produced by the receiver’s Local Oscillator (LO). Ideally, the carrier signal and the receiver LO are at the identical frequency. Unfortunately, this is not always the case.

The transmitter and receiver local oscillators will invariably drift, so active means must be taken to keep them synchronised. Each base station periodically sends synchronisation signals which are used by the UE for this purpose. Even so, other sources such as Doppler shifts and oscillator phase noise can still result in frequency errors. Uncorrected frequency errors will result in ICI as shown in Fig. 3-60. For these reasons, the signal frequency must be tracked continuously. Any offsets must be corrected in the baseband processor to avoid excessive ICI that might result in dropped packets.

FFT points zero ICI f

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

Figure 3-60 Demodulated signal without frequency offset frequency error

ICI f

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

15 kHz

Figure 3-61 Demodulated signal with frequency offset

76


3 OFDMA & SC-FDMA

PA PR

The other major drawback to OFDM is a high Peak-to-Average Power Ratio

(PAPR). The instantaneous transmitted RF power can vary dramatically within a single OFDM symbol. The OFDM symbol is a combination of all of the subcarriers. Subcarrier voltages can add in-phase at some points within the symbol, resulting in very high instantaneous peak power – much higher than the average power.

t

Figure 3-62 OFDM signal amplitude variations

A high PAPR drives dynamic range requirements for A/D and D/A converters. Even more importantly, it also reduces efficiency of the transmitter RF power amplifier. Single carrier systems sometimes use constant envelope modulation methods, such as Gaussian Minimum Shift

Keying (GMSK) or Phase Shift Keying (PSK). The information in the signal of a single carrier system is conveyed by varying the instantaneous frequency or phase while the signal amplitude remains constant. The RF power amplifier does not require a high degree of linearity. In fact, the power amplifier can be driven so hard that the signal is ‘clipped’ as the signal swings between the minimum and maximum voltages. Harmonic distortion due to clipping can be eliminated by output filtering. When RF power amplifiers are operated in this manner, they can achieve efficiencies on the order of 70%.

In contrast, OFDM is not a constant envelope modulation scheme. Over the duration of an OFDM symbol, there can be several large peaks. The RF power amplifier must be capable of handling peak voltage swings without clipping, thus requiring a larger amplifier to handle a given average power. Efficiency is therefore lower. RF power amplifier efficiencies for OFDM signals can be less than 20%. Although there are measures that can be taken to reduce voltage peaks, PAPR for OFDM results in RF power amplifier efficiencies that are generally lower than for single-carrier constant envelope systems.

77



Orthogonal Frequency Division Multiple Access (OFDMA) is a multiple access scheme which is an extension of OFDM to accommodate multiple simultaneous users.

The traffic multiplexing is performed by allocating each user a pattern of frequency-time slots, depending on its data rate. Fig. 3-63 illustrates the resource distribution between user channels, common control channels and reference symbols. Common control channels bring classically some information about on the network, the cell, etc. Reference symbols are useful to perform the identification of the channel response. Thanks to these known symbols, channel response can be interpolated both in time and frequency and simply equalised. time pilot control channel user 1 user 2 user 3 frequency

Figure 3-63 OFDMA – time-frequency allocation pattern

Despite the benefits of OFDM and OFDMA, they suffer a number of drawbacks including: high PAPR; a need for an adaptive or coded scheme to overcome spectral nulls in the channel; and high sensitivity to frequency offset.

Single Carrier – Frequency Division Multiple Access (SC-FDMA), which utilises single carrier modulation and frequency domain equalisation is a technique that has similar performance and essentially the same overall

78


3 OFDMA & SC-FDMA complexity as those OFDMA system. One prominent advantage over

OFDMA is that the SC-FDMA single has lower PAPR because of its inherent single carrier structure. SC-FDMA has drawn great attention as an attractive alternative to OFDMA, especially in the uplink communications where lower

PAPR greatly benefits the mobile terminal in terms of transmit power efficiency. s[n] x

0 x

N-1

X

0

X

N-1

X

˜

0 x

1

FFT

(N point)

X

1

˜

X

1

Subcarrier mapping

(N → M)

˜

X

M-2

(M point)

˜

X

M-1

Re

Im

CP

D/A f

D/A

90

0 s(t)

Figure 3-64 SC-FDMA transmitter r(t)

90

0 f

A/D

Re

CP

Y

˜

0

Y

0 y

0

FFT

(M point)

Y

˜

1

˜

Y

M-2

Subcarrier demapping

(M → N)

˜

Y

M-1

Y

1

Y

N-1

(N point) y

1 y

N-1

A/D

Im

Figure 3-65 SC-FDMA receiver ŝ [n]

A block diagram of a SC-FDMA transmitter is shown in Fig. 3-64.

SC-FDMA can be regarded as a DFT-spread OFDMA, where time domain symbols are transformed to frequency domain by DFT before going through

OFDMA modulation. The orthogonality of the users stems from the fact that each user occupies different subcarriers in the frequency domain, similar to the case of OFDMA. Because the overall transmit signal is a single carrier signal, PAPR is inherently low compared to the case of OFDMA which produces a multicarrier signal.

DFT

(N point)

Subcarrier mapping

IDFT

(M point)

N

T

N

T

M>N

=

T

⋅

N

M

N, M number of data symbols

T,

~

T symbol durations

N

T

Figure 3-66 SC-FDMA signal generation

79



Fig. 3-66 details the generation of SC-FDMA transmit symbols. There are M subcarriers, among which N (N<M) subcarriers are occupied by the input data. In the time domain, the input data symbol has symbol duration of T seconds and the symbol duration is compressed to T

~

=

( )

⋅

T after going through SC-FDMA modulation.

There are two methods to choose the subcarriers for transmission as shown in

Fig. 3-67. In the distributed subcarrier mapping mode, DFT outputs of the input data are allocated over the entire bandwidth with zeros occupying in unused subcarriers, whereas consecutive subcarriers are occupied by the DFT outputs of the input data in the localised subcarrier mapping mode. x x

1

0 zeros

~

X

0 x

0 x

1 zeros ~

X

0 zeros x

2 x

N

−

1

Distributed mode

~

X

M

−

1 x

N

−

1 zeros

~

X

M

Localised mode

−

1

Figure 3-67 Subcarrier mapping modes

Distributed and localised subcarrier mapping modes are also shown in

Fig. 3-68, where two subscribers are sharing the entire bandwidth of the

SC-FDMA system.

Distributed mode

f

Localised mode

Figure 3-68 Subcarrier mapping modes (spectral view) f

80


4 E-UTRAN

Chapter 4

Introduction...................................................................................................... 83

Duplex mode .................................................................................................... 83

Frequency bands .............................................................................................. 86

Inter-cell interference....................................................................................... 90

LTE physical layer ........................................................................................... 94

MIMO ............................................................................................................ 100

Channels......................................................................................................... 104

Data transfer................................................................................................... 110


81



82


4 E-UTRAN

The E-UTRAN consists of eNodeBs (eNBs), providing the E-UTRA user plane and control plane protocol terminations towards the UE. The eNBs are interconnected with each other by means of the X2 interface. The eNBs are also connected by means of the S1 interface to the EPC, more specifically to the MME by means of the S1-MME and to the S-GW by means of the S1-U.

The S1 interface supports a many-to-many relation between MMEs / S-GWs and eNBs.

The E-UTRAN architecture is illustrated in Fig. 4-1 below.

MME/S-GW MME/S-GW

E-UTRAN

S1

S1 S1

S1

X2 eNB eNB

X2 X2 eNB

Figure 4-1 E-UTRAN architecture

In full duplex systems there is a necessity to separate the transmission between two users taking place in both directions at the same time.

The first method is to separate the transmission in both directions in frequency domain by allocating a separate frequency channel for each direction. The signals are not interfering with each other because there is a certain duplex distance between these two frequencies. Such system is called

83



Frequency Division Duplex (FDD) and is used by cellular systems of the first, second and third generation like NMT, AMPS, GSM and D-AMPS, and

UMTS.

In case of the Time Division Duplex (TDD) transmissions in both directions are implemented on the same frequency channel. This frequency channel is divided into time slots. Each timeslot can be used either for reception or for transmission. The switchover between transmission and reception is so frequent that a quasi-simultaneous full-duplex communication is possible.

UMTS and DECT are examples of the systems using TDD.

FDD time

TDD time frequency frequency

Figure 4-2 FDD and TDD

In order to further increase E-UTRA bandwidth flexibility, the E-UTRAN supports both FDD and TDD modes of operation. Moreover, most of the design parameters are common to FDD and TDD modes to reduce the complexity of the terminal.

There are three main advantages of using the TDD mode compared to the

FDD:

•

No need for paired frequency band - the spectrum allocated for

IMT-2000 is asymmetric, which means that it cannot be used entirely by only FDD mode, as it requires symmetric bands. Thus the solution is to allocate the remaining asymmetric part to TDD systems. The

TDD mode also can be used in the regions where the available frequency resources are limited.

84


4 E-UTRAN

•

Symmetric frequency channel - as UL and DL use the same frequency channel, the dynamic channel characteristics remain similar for transmission and reception. This means that based on received signals the transmitter can predict the fast fading conditions of the assigned frequency channel.

•

Asymmetric data transfer capability - in the TDD mode the available resources may be dynamically allocated between UL and DL according to current needs in a cell. This advantage meets the demand of asymmetric services like Web browsing or database access.

Deployment of the TDD mode brings also the problems of inter- and intra-cell interference between UL and DL.

In FDD the UL versus DL interference problem practically does not exists due to huge frequency separation. In TDD mode the basic problem is that in adjacent cells the same chunk may be allocated for different directions. If a

UE tries to receive on a slot that is used by other terminal for transmission, the interference level increases dramatically, especially if the users are close to each other and/or transmission is with high power. A similar scenario may apply for the eNB, which can block a UE reception in another eNB. That is why, the TDD mode often requires synchronisation between various transmitters and receivers in different cells in order to coordinate allocation of chunks not only between cell but also between DL and UL direction. eNB #1

UE #2

UE #1 eNB #1

UE #1 eNB #2

UE #2

Figure 4-3 TDD intra-cell interference eNB #2

85



LTE supports transmission in paired and unpaired spectrum, two duplex modes are supported: FDD (supporting full duplex and half duplex operation), and TDD.

Full duplex FDD:

UL f

1

DL f

2

Half duplex FDD:

UL

DL

TDD:

UL/DL

Figure 4-4 FDD (full and half duplex) and TDD f f f

1

2

1

Part of the requirements for E-UTRAN is the ability to cope with various spectrum allocations from much less than 5 MHz to much more than 5MHz, accommodating future 3G spectrum allocations. Ultimately, the maximum achievable data rate available should be 326 Mbps in 20 MHz. The OFDM and SC-FDMA technologies should then allow a smooth migration from

1.4 MHz bandwidth to 20 MHz through 1.4, 3, 5, 10 and 15 MHz steps. In

E-UTRAN channel bandwidth very often is expressed in units called

Resource Block (RB). The RB is the smallest amount of radio resources that can be allocated for a certain purpose. In frequency domain RB corresponds to 180 kHz or 12 subcarriers.

86

Figure 4-5 Channel bandwidth


4 E-UTRAN

Please note that the channel bandwidth is greater than the total bandwidth occupied by all the RBs inside (N

RB

·180 kHz) i.e. transmission bandwidth configuration, since some part of the channel bandwidth near to channel edge is not used for RBs in order to minimise adjacent channel interference.

Channel Bandwidth [MHz]

Transmission Bandwidth Configuration [RB]

Transmission

Bandwidth [RB]

Active Resource Blocks

DC carrier (downlink only)

Figure 4-6 Channel bandwidth and transmission bandwidth configuration

E-UTRA is designed to operate in the majority frequency bands allocated for

PLMN use. The detailed definition of all the supported bands is presented in

Fig. 4-7. The channel raster is 100 kHz for all bands, which means that the carrier centre frequency must be an integer multiple of 100 kHz.

Figure 4-7 E-UTRA frequency bands


87


The carrier frequency in the UL and DL is designated by the E-UTRA

Absolute Radio Frequency Channel Number (EARFCN). The carrier frequency in MHz for the UL and DL is given by equations shown in Fig. 4-8.

0 .

.

1

0 .

.

1

(

(

(

(

−

UL

)

)

)

)

Figure 4-8 DL/UL EARFCN

0 – 599

1200 – 1949

1950 – 2399

2400 – 2649

2650 – 2749

2750 – 3449

3450 – 3799

3800 – 4149

4150 – 4749

4750 – 4999

5000 – 5179

5180 – 5279

5280 – 5379

13000 – 13599

13600 – 14199

14200 – 14949

14950 – 15399

15400 – 15649

15650 – 15749

15750 – 16449

16450 – 16799

16800 – 17149

17150 – 17749

17750 – 17999

18000 – 18179

18180 – 18279

18280 – 18379

27750 – 28249

28250 – 28649

28650 – 29649

Figure 4-9 EARFCN – DC carrier relation

28250 – 28649

28650 – 29649

With the idea of creating a globally accepted 3G standard arose a need to define a new spectrum for IMT-2000, which would be used in all over the world. In 1992 The World Administrative Radio Conference held in

Malaga-Torremolinos (WARC-92) identified frequencies for the future third generation systems. The following frequency bands have been allocated:

88


4 E-UTRAN

•

1885-1980 MHz, 2010-2025 MHz and 2110-2170 MHz for the terrestrial components,

•

1980-2010 MHz and 2170-2200 for the satellite component.

Terrestrial MSS

2010 2025 2110

Terrestrial MSS

Figure 4-10 Frequency allocations for IMT-2000

The WARC-92 allocations were made with the assumption that speech still would be a major service in 3G networks and only low data rate services were considered. With the continuously growing amount of traffic in 2G networks and the converging trends in the telecommunications world a need for additional frequencies arose. New frequencies were allocated at the

WARC-2000 conference in Istanbul. As it was difficult to reach a worldwide consensus, no exact bands have been indicated for specific use, but an agreement was signed that no 3G systems would be deployed outside allocated additional bands, and that regional/national regulators would decide the local use of the frequencies. Thus, the following frequency ranges has been identified:

•

806-960 MHz

•

1710-1885 MHz

•

2500-2690 MHz

In the range below 1GHz, the frequencies currently used by 2G systems have been also included to facilitate the migration of these systems to 3G.

The actual allocations of the recommended frequencies for IMT-2000

(International Telecommunication Union) differ from country to country.

Most of the Europe and Asia follow the WARC-92 recommendations with slight modifications. Fig. 4-11 shows the details on European allocations.

Since, there are no any new frequency allocations for E-UTRAN, existing operators have to divide their existing frequency allocation between UTRAN and E-UTRAN. Typical operator in Europe has three FDD channels (2 x 3 x 5

MHz) and two TDD channels (2 x 5 MHz).

89



DECT

TDD FDD ↑ TDD FDD ↓

MSS MSS f [MHz]

Figure 4-11 IMT-2000 spectrum allocations in Europe

Several adjacent UTRA FDD or TDD channels can form a single channel for a single EUTRA channel that can be FDD or TDD. Moreover in case of FDD operation it is not required for the bandwidth to be equal in both directions.

To make the best use of the whole available spectrum and limit the complexity of frequency planning, it is planned usually to use the whole spectrum in any cell, i.e. the re-use factor is set to 1. However, granted that in that case, the cell edge users may suffer from interference of neighbouring cells, some approaches to mitigate these interferences may be required.

Three approaches to Inter-Cell Interference (ICI) mitigation are currently being considered.

• randomisation,

• cancellation,

• co-ordination/avoidance.

In addition, the use of beam-forming antenna solutions at the base station is a general method that can also be seen as a means for DL inter-cell-interference mitigation.

It should be noted that the different approaches could, at least to some extent, complement each other i.e. they are not necessarily mutually exclusive.

ICI randomisation aims at randomising the interfering signal(s) and thus to allow for interference suppression at the UE in line with the processing gain.

Methods considered for inter-cell-interference randomisation includes: cell-specific scrambling, applying (pseudo) random scrambling after channel coding/interleaving and/or cell-specific interleaving, also known as

Interleaved Division Multiple Access (IDMA).

A third means for randomisation is to apply different kinds of frequency hopping.

90


4 E-UTRAN

ICI cancellation aims at interference suppression at the UE beyond what can be achieved by just exploiting the processing gain.

Two methods have been discussed

•

Spatial suppression by means of multiple antennas at the UE.

•

Interference cancellation based on detection/subtraction of the inter-cell interference. One example is the application of cell-specific interleaving (IDMA) to enable inter-cell-interference cancellation.

The common theme of ICI co-ordination/avoidance is to apply restrictions to the DL resource management (configuration for the common channels and scheduling for the non-common channels) in a coordinated way between cells.

These restrictions can be in the form of restrictions to what time/frequency resources are available to the resource manager or restrictions on the transmit power that can be applied to certain time/frequency resources. Such restrictions in a cell will provide the possibility for improvement in SIR, and cell-edge data-rates/coverage, on the corresponding time/frequency resources in a neighbour cell. The coordination between the cells can range from a static coordination to a more or less dynamic coordination based on different types of measurements, e.g. UE measurements and traffic distribution.

When a request for time-frequency resource (chunk) takes place, it is suggested that the chunks not used in adjacent cells should be granted at first, as shown in Fig. 4-12. Synchronisation between adjacent base stations makes it possible to dynamically allocate chunks over the entire frequency band. eNB 1 eNB 2 frequency used by eNB 1 spare used by eNB 2

Figure 4-12 Chunk allocation


91


When the system is heavy-loaded, the same chunk has to be reused in neighbouring cells. In this scenario, whitening techniques should be adopted to distinguish the base stations using the same chunk. And some non-orthogonal multiple access schemes, such as IDMA and scrambling, could be considered for inter-cell separation. eNB 1 eNB 2 frequency used by eNB 1 multiplexing eNB 1 & eNB 2 used by eNB 2

Figure 4-13 Chunk allocation (heavy load)

When in a heavy load condition, the network is forced to allocate the same chunk twice in two neighbouring cells, instead of just relying on ICI randomisation, it is possible to optimise the resource allocation. The optimisation of resource is based on measurements performed by the UE and communicated to the base station (CQI, path loss, average interference, etc.)

92 frequency

Figure 4-14 Allocation optimisation (before)


4 E-UTRAN frequency

Figure 4-15 Allocation optimisation (after)

A slightly reduced variant of the method presented above leads to, so called soft frequency reuse method. In that method the total available bandwidth is divided first into primary band and secondary band. The primary band is planned with frequency reuse pattern of 1/3 and served by high power transmission with good SNR. The secondary band is planned with frequency reuse pattern of 1/1 and is using remaining power.

1/3

1/1

1/1

1/3

1/3

1/1

Figure 4-16 Soft frequency reuse (part 1)

The chunks on primary band are then mostly allocated to the cell edge users, whereas the chunks on secondary band are allocated for the cell centre users.

The measurement reported by UE are then used to switch the users between primary and secondary band in case if their position in the cell is changed.

93



The entire concept is very similar to Overlaid/Underlaid (OL/UL) or

Inner/Outer cell concept known from GERAN.

1/3 1/1 1/1 1/3 frequency

Figure 4-17 Soft frequency reuse (part 2)

The multiple access scheme for the LTE physical layer is based on OFDM with a Cyclic Prefix (CP) in the downlink, and on SC-FDMA with a CP in the uplink.

In the downlink direction, the transmitted signal in each slot is described by a resource grid of

DL

N

RB

RB

N

SC

subcarriers and N

DL symb

OFDM symbols, where:

•

N

DL

RB

is a downlink bandwidth configuration, expressed in multiples of

N

RB sc

,

•

N

RB sc

is a resource block size in the frequency domain, expressed as a number of subcarriers,

•

N

DL symb

is a number of OFDM symbols in a downlink slot.

94


4 E-UTRAN

The resource grid structure is illustrated in Fig. 4-18. The N

DL

RB

value is from 6 up to 100 and depends on the transmission bandwidth configured in the cell.

1 DL slot T slot

Resource element (k,l)

Resource block k=0 l=0

Figure 4-18 Downlink resource grid

A simplified view on downlink resource grid is also presented in Fig. 4-19.

On that diagram some of the parameters are taking their most popular values used for point-to-point transmission.

15 kHz

Resource element

QPSK – 2 bits,

16QAM – 4 bits,

64QAM – 6 bits, f

Resource block

(12 x 7 = 84 resource elements) (T slo t =

0

.5

m O s, 7 ne

O

slo t

FD

M

sy m bo ls) t

12 subcarriers, 180 kHz

Figure 4-19 Resource grid (simplified)

95



The number of OFDM symbols in a slot depends on the cyclic prefix length and subcarrier spacing configured, see Fig. 4-20. For the typical carrier spacing 15 kHz and normal CP, N

RB sc

=12 and N

DL symb

=7.

In the uplink direction, the transmitted signal in each slot is described by a similar resource grid of N

UL

RB

N

RB sc

subcarriers and N

UL symb

SC-FDMA symbols.

Resource blocks are used to describe the mapping of certain physical channels to resource elements. Physical and virtual resource blocks are defined.

Physical resource blocks is identified in the frequency domain by physical resource block number n

PRB

, that takes values from 0 to N

DL

RB

−

1 .

A virtual resource block is of the same size as a physical resource block.

Virtual resource blocks are numbered from 0 to N

DL

RB

−

1 . Two types of virtual resource blocks are defined:

•

Virtual resource blocks of localised type

•

Virtual resource blocks of distributed type

Virtual resource blocks of localised type are mapped directly to physical resource blocks such that virtual resource block n

VRB

corresponds to physical resource block n

PRB

= n

VRB

.

96 symbols

Figure 4-20 Localised virtual RB mapping to physical RB


4 E-UTRAN

Virtual resource blocks of distributed type are mapped to physical resource blocks such that virtual resource block n

VRB

corresponds to physical resource block n

PRB

= f ( n

VRB

, n s

) , where n s

is the slot number within a radio frame. The virtual-to-physical resource block mapping is different in the two slots of a subframe. symbols

Figure 4-21 Distributed virtual RB mapping to physical RB

Radi o frames

The size of various fields in the time domain is expressed as a number of time units T s

=

1 /

(

∆ f

×

N

)

, where f =15 kHz (subcarrier spacing) and N=2048

(maximum FFT size). In frequency domain, the size is expressed as multiples of

∆ f . Physically, T s represents somehow the achievable data rate period that could handle the system for a binary modulation.

The radio frame structure type 1 is used for FDD (for both full duplex and half duplex operation) and has a duration of 10 ms and consists of 20 slots with a slot duration of 0.5 ms, numbered from 0 to 19. Two adjacent slots form one sub-frame of length 1ms.

Uplink and downlink transmissions are separated in the frequency domain. In half-duplex FDD operation, the UE cannot transmit and receive at the same time while there are no such restrictions in full-duplex FDD.

97


LTE/EPS Technology radio frame, T f

= 10ms slot, T slot

= 0.5 ms

#1 #2 #3 #0 #18 #19 subframe

Figure 4-22 Frame structure type 1 (FDD)

Frame structure type 2 is applicable to TDD. Each radio frame of length 10 ms consists of two half-frames of length 5 ms each. Each half-frame consists of five subframes of length 1 ms. The supported uplink-downlink configurations are listed in Fig. 4-24 where, for each subframe in a radio frame, ‘D’ denotes the subframe is reserved for downlink transmissions, ‘U’ denotes the subframe is reserved for uplink transmissions and ‘S’ denotes a special subframe with the three fields DwPTS, GP and UpPTS with the total length of 1 ms. All subframes, which are not special subframes, are defined as two slots of length 0,5 ms in each subframe. radio-frame, 10 ms half-frame, 5 ms

DwPTS

GP

UpPTS slot subframe subframe

#0 subframe

#1 subframe

#2 subframe

#3 subframe

#4 subframe

#5 subframe

#6 subframe

#7 subframe

#8 subframe

#9

Figure 4-23 Frame structure type 2 (TDD)

Uplink-downlink configurations with both 5 ms and 10 ms downlink-to-uplink switch-point periodicity are supported.

In case of 5 ms downlink-to-uplink switch-point periodicity, the special subframe exists in both half-frames.

In case of 10 ms downlink-to-uplink switch-point periodicity, the special subframe exists in the first half-frame only.

Subframes 0 and 5 and DwPTS are always reserved for downlink transmission. UpPTS and the subframe immediately following the special subframe are always reserved for uplink transmission.

98


4 E-UTRAN

Figure 4-24 Uplink-downlink allocations (TDD)

Some of the symbols in both DL & UL resource blocks instead of being used for data transmission are used to transmit predefined signals (i.e. known by both transmitter and receiver), that are known as reference symbols or pilot symbols. These signals are required for the following three purposes:

• channel quality measurements,

• channel estimation for coherent demodulation/detection,

• cell search and initial acquisition.

The reference symbols are arranged in the time-frequency domain so that they are time and frequency spaced, allowing correct interpolation of the channel. resource blocks resource element symbols reference signal

Figure 4-25 Reference signal for 1 Tx antenna system


99


In the context of wireless transmissions, it is common knowledge that depending on the surrounding environment, a transmitted radio signal usually propagates through several different paths before it reaches the receiver, which is often referred to as multipath propagation. The radio signal received by the receiver antenna consists of the superposition of the various multipaths with different phase shifts. In such environment, the channel gain can sometimes become very small so that a reliable transmission is not always possible. To deal with this problem, communication engineers have thought of many possibilities to increase the so-called diversity. The higher the diversity is, the lower is the probability of a small channel gain.

Some common diversity techniques are time diversity and frequency diversity, where the same information is transmitted at different time instants or in different frequency bands, as well as spatial diversity, where one relies on the assumption that fading is at least partly independent between different points in space.

The concept of spatial diversity leads directly to an expansion of the Single

Input Single Output (SISO) system. This enhancement is denoted as Single

Input Multiple Output (SIMO) system. In such a system, we equip the receiver with multiple antennas. Doing so usually can be used to achieve a considerable performance gain, i.e. better link budget, but also co-channel interference can be better combated. At the receiver, the signals are combined

(i.e. if the phases of the transmission are known, in a coherent way) and the resulting advantage in performance is referred to as the diversity gain obtained from independent fading of the signal paths corresponding to the different antennas. This idea is well known and is used in many established communication systems, for example in the GSM and also UMTS. It is clear that in the above described way, a base station can improve the uplink reliability and signal strength without adding any cost, size or power consumption to the mobile device.

As far as the ability to achieve performance in terms of diversity is concerned, system improvements are not only limited to the receiver side. If the transmitter side is also equipped with multiple antennas, we can either be in the Multiple Input Single Output (MISO) or Multiple Input Multiple Output

(MIMO) case. A lot of research has been performed in recent years to exploit the possible performance gain of transmit diversity. The ways to achieve the predicted performance gain due to transmit diversity are various. Most of them are, loosely speaking, summarised under the concept of Space-Time

Coding (STC).

100


4 E-UTRAN

SISO SIMO

MISO MIMO

Figure 4-26 Multiple antenna systems classification

Besides the advantages of spatial diversity in MIMO systems, they can also offer a remarkably gain in terms of information rate or capacity. This improvement is linked with the afore mentioned multiplexing gain. In fact, the advantages of MIMO are far more fundamental as it may have appeared to the reader so far. The underlying mathematical nature of MIMO systems, where data is transmitted over a matrix rather than a vector channel, creates new and enormous opportunities beyond the just described diversity effects.

A simplified vision of a 2x2 MIMO system is shown in Fig. 4-27. h

11

S

1

Z

1 h

12

Tx

S

2 h

21 h

22

Z

2

Rx

Figure 4-27 2x2 MIMO basic model

101



The base station transmits two different signals via two antennas. The symbol transmitted on the first antenna port is denoted by s

1

, and the symbol transmitted on the second antenna port is denoted by s

2

. Consequently, the symbol received are denoted by z

1

and z

2

.

In the simplified model, there are four channel path. The channel response for each path is denoted by h t,r

, where t is the transmit antenna port number and r is a receive antenna port number.

The entire transmission process can be described by the set of two equations

(one equation for each RX antenna):





 z z

2

1

=

= h

11 h

12

⋅ s

1

⋅ s

1

+

+ h

21 h

22

⋅ s

2

⋅ s

2

Assuming, that the receiver has accurate channel estimates, based on those estimates and the received symbol values, receiver is able to solve the above set of equations and get the values of the originally transmitted symbols.

Thus, theoretically, by using 2x2 MIMO, it is possible to double the transmission rate.

In case of multiple transmit antennas, there are separate reference signal patterns for each antenna port. Additionally each antenna element remains completely silent on resource element used as a reference signal on another antenna. Thanks to this arrangement a transmission path from any transmitting antenna to any receiving antenna can be easily measured and estimated separately. antenna port 1 antenna port 2

102

Figure 4-28 Reference signals for 2 Tx antennas system


antenna port 1 antenna port 2 antenna port 3

4 E-UTRAN antenna port 4

Figure 4-29 Reference signals for 4 Tx antennas system

For example, in order to estimate the h

11

and h

12

values correctly, receiver has to wait for the moment when the first antenna transmits the reference signal.

The set of equations from the previous section is than simplified, as the second antenna is silent (i.e. there is no s

2

):





 z

1 z

2

=

= h

11 h

12

⋅

⋅ s

1 s

1

, and the h

11

and h

12

values can be easily calculated. In order to calculate the remaining h t,r

values it is necessary to repeat this procedure, separately for each transmitting antenna.





 z z

2

1

=

= h

11 h

12

⋅ s

1 ref

⋅ s

1 ref





 z z

2

1

=

= h

21 h

22

⋅ s

2 ref

⋅ s

2 ref





 z z

2

1

=

= h

11 h

12

⋅ s

1

⋅ s

1

+

+ h

21 h

22

⋅ s

2

⋅ s

2

Figure 4-30 MIMO channels estimation

Transmission with multiple input and multiple output antennas (MIMO) are supported with configurations in the downlink with two or four transmit antennas and two or four receive antennas, which allow for multi-layer transmissions with up to four streams. Multi-user MIMO i.e. allocation of different streams to different users is supported in both UL and DL.

103



As for the most radio communication systems, the radio interface of

E-UTRAN faces many challenges. In terms of requirements, the E-UTRAN shall be able to transmit high-rate and low-latency information in the most efficient way. However, not all the information flows require the same protection against transmission errors or QoS handling.

In general, it is crucial, especially in the case of radio mobility, that the

E-UTRAN signalling message are transmitted as fast as possible, using the best error-protection scheme. On the other hand, voice or data streaming applications can accept a reasonable frame loss due to radio transmission.

Interactive connection-oriented applications (such as Web browsing) are also different, as the end-to-end retransmission can help to recover from radio propagation problem issues.

In order to be flexible and allow different schemes for data transmission, the

E-UTRAN specification introduce several types of channels:

• logical channels,

• transport channels,

• physical channels.

Logical channels are described by the type of information they carry, or in other words they corresponds to data-transfer services offered by the radio interface protocols to upper layers. Logical channels can be divided into two categories: the control channels (for the transfer of control plane information) and the traffic channels (for the transfer of user plane information).

Control logical channels Traffic logical channels

BCCH Broadcast Control Channel ↓

PCCH Paging Control Channel ↓

CCCH Common Control Channel ↕

MCCH Multicast Control Channel ↓

DTCH Dedicated Traffic Channel ↕

MTCH Multicast Traffic Channel ↓

DCCH Dedicated Control Channel ↕

Figure 4-31 Logical channels

104


4 E-UTRAN

The E-UTRAN logical control channels are:

•

Broadcast Control Channel (BCCH) – This is a downlink common channel, used by the network to broadcast E-UTRAN system information to the terminals present in the radio cell. This information is used by the terminal, e.g. to know serving cell network operator, to get information about the configuration of the cell common channels, how to access to the network, etc.

•

Paging Control Channel (PCCH) – is a downlink common channel which transfers paging information to terminals present in the cell, e.g. in case of mobile-terminated communication session.

•

Common Control Channel (CCCH) is a bi-directional channel, used to establish connection between UE and E-UTRAN.

•

Multicast Control Channel (MCCH) – is a downlink channel used for the transmission of Multimedia Broadcast and Multicast Service

(MBMS) information to one or several terminals.

•

Dedicated Control Channel (DCCH) – is a point-to-point bi-directional channel supporting control information between a given terminal and the network. In the DCCH context, the control information only includes the 3GPP specific signalling (RRC and

NAS). The application level signalling (e.g. SIP and SDP) is not handled by the DCCH.

The E-UTRAN logical traffic channels are:

•

Dedicated Traffic Channel (DCCH) – is a point-to-point bi-directional channel, used between a given terminal and the network.

It can support the transmission of user data, which include the data themselves as well as application level signalling associated to data flow (e.g. SIP and SDP).

•

Multicast Traffic Channel (MTCH) – is a point-to-multipoint downlink data channel for the transmission of traffic data, associated to the MBMS service, from the network to one or several terminals.

Tra nsport channels

Transport channels are described by how and with what characteristics data are transferred over the radio interface. For example, the transport channels describe how the data are protected against transmission errors, the type of channel coding, CRC protection or interleaving which is being used, the size of data packets sent over the radio interface, etc. All this set of information is known as the Transport Format (TF).

105



Transport channels

BCH Broadcast Channel ↓

PCH Paging Channel ↓

MCH Multicast Channel ↓

RACH Random Access Channel ↑

UL-SCH Uplink Shared Channel ↑

DL-SCH Downlink Shared Channel ↓

Figure 4-32 Transport channels

The E-UTRAN transport channels are:

•

Broadcast Channel (BCH) – is a downlink channel associated to the

BCCH logical channel. The BCH has a fixed and predefined TF, and covers the whole cell area.

•

Paging Channel (PCH) – is a downlink channel associated to the

PCCH.

•

Multicast Channel (MCH) – is a downlink channel associated to

MBMS traffic or control information transfer.

•

Downlink Shared Channel (DL-SCH) – is a downlink channel used to transport traffic or control information.

•

Uplink Shared Channel (UL-SCH) – is an uplink equivalent of the

DL-SCH.

•

Random Access Channel (RACH) – is an uplink channel is a specific channel supporting limited control information, e.g. during early phases of communication establishment or in case of RRC state change.

The physical channels correspond to a set of resource elements carrying information originating from higher layers. The physical channels are the actual implementation of the transport channels over the radio interface. They are only known to the physical layer of E-UTRAN and their structure is tightly dependent on physical interface OFDMA/SC-FDMA characteristics.

106


4 E-UTRAN

Downlink physical channels Uplink physical channels

PDSCH Physical Downlink Shared Channel ↓

PBCH Physical Broadcast Channel ↓

PMCH Physical Multicast Channel ↓

PCFICH Physical Control Format Indicator Channel ↓

PDCCH Physical Downlink Control Channel ↓

PHICH Physical Hybrid ARQ Indicator Channel ↓

PUSCH Physical Uplink Shared Channel ↑

PUCCH Physical Uplink Control Channel ↑

PRACH Physical Random Access Channel ↑

Figure 4-33 Physical channels

The following downlink physical channels are defined:

•

Physical Downlink Shared Channel (PDSCH) – which carries user data and higher-layer signalling. As for the HSDPA system, the radio channel is allocated dynamically in an opportunistic way, i.e. its is a channel with PS characteristics.

•

Physical Broadcast Channel (PBCH) – which carries BCH transport channel and some of the BCCH logical channel information, i.e.

Master Information Block (MIB),

•

Physical Multicast Channel (PMCH) – which carries multicast/broadcast information,

•

Physical Control Format Indicator Channel (PCFICH) – which informs the UE about the number of OFDM symbols used for the

PDCCH.

•

Physical Downlink Control Channel (PDCCH) - which carries scheduling assignments for the downlink and uplink,

•

Physical Hybrid ARQ Indicator Channel (PHICH) – which carries

ACK and NACK eNB responses to uplink transmission, relative to the

HARQ mechanism.

The following uplink physical channels are defined:

•

Physical Uplink Shared Channel (PUSCH) – which carries user data and higher-layer signalling,

•

Physical Uplink Control Channel (PUCCH) – which carries control information, including ACK and NACK responses from the terminal to downlink transmission, relative to HARQ mechanism,

•

Physical Random Access Channel (PRACH) – which carries the random access preamble sent by the terminals to access to the network.

107



In addition to physical channels, the physical layer makes use of physical signals. A signal corresponds to a set of resource elements used by the physical layer but does not carry information originating from higher layers.

The following physical signals are defined:

•

Reference signal (DL & UL),

•

Synchronisation signal (DL only).

Fig. 4-34 represents the mapping between logical, transport and physical channels presented above.

BCCH PCCH CCCH DCCH DTCH MCCH MTCH

BCH PCH UL-SCH DL-SCH MCH RACH

PBCH PUSCH PDSCH PMCH

Figure 4-34 E-UTRAN channel mapping

PRACH

PCCH and BCCH logical channels have particular transport and physical characteristics so that the transport and physical channel mapping is specific to them. The mapping of the BCCH on the BCH. The mapping of the BCCH on the BCH and DL-SCH transport channel is not an option. This comes from the fact that the System Information (SI) is actually composed of two parts:

•

Critical system information (MIB) which has a fixed format and requires frequent update – this one is mapped on the PBCH.

•

Dynamic and less critical information which is mapped on a transport channel offering more flexibility in terms of bandwidth and repetition period – the DL-SCH.

On the other hand, some logical channels can benefit from different possible options as regards to mapping to the transport channel. Typically, this is the case for the MCCH and MTCH channels, which are mapped on a specific

MCH transport channel in case of multi-cell MBMS service provision. When an MBMS service is provided in a single cell, MCCH and MTCH channels are mapped over conventional DL-SCH channels.

108


4 E-UTRAN

The other physical channels (such as PUCCH, PDCCH, PCFICH and PHICH) do not carry information from upper layers (such as RRC signalling or user data). They are only intended for the purpose of physical layer, as they carry information related to the coding of physical blocks, or HARQ-related information. This is the reason why those channels are not mapped to any of the transport channels.

The RACH is a specific case of transport channel, having no logical channel equivalent. This comes from the fact that the RACH only carriers RACH preamble (which is basically the very first set of bits the terminal sends to the network to request access). Once access is granted by the network and physical uplink resources are allocated to the terminal, the RACH is no longer used by the terminal.

UTRAN and UTRAN c hannels

The E-UTRAN channel model has been inherited from the UTRAN channel model. The concept of separation between logical, transport and physical channels was already present in the initial UTRAN model.

UTRAN and E-UTRAN models share almost the same logical channel structure, showing that radio layers from both systems will actually provide the same types of services to upper layers, i.e.:

•

Broadcast and paging services (associated to BCCH and PCCH), which are the basis of all cellular systems,

•

Dedicated – or point-to-point – information transfer (supported by

DCCH and DTCH).

•

Multicast – or point-to-multipoint – information transfer (supported by

MCCH and MTCH).

However, when looking at the transport channel level, the two models are completely different. The DCH present in the UTRAN model has disappeared from the E-UTRAN model, which only supports shared transport channels.

This channel was designed for constant bit rate and real-time constraining services, such as voice or streaming applications.

In the E-UTRAN model, all point-to-point data services are packetised, and supported by only one kind of transport channel: DL/UL-SCH. This is an interesting evolution, as the radio interface concepts are following the same

‘all-IP’ direction as the Packet Core and service evolution. This newly introduced DL/UL-SCH can actually be seen as an evolution of both

HS-DSCH and E-DCH, supporting HSDPA and HSUPA respectively.

109



At the end, the channel model of E-UTRAN looks much simpler, as the number of transport channels and cross-mapping between channel types has been greatly simplified and reduced.

BCCH PCCH CTCH MCCH MSCH MTCH CCCH DCCH DTCH

BCH PCH FACH DCH HS-DSCH

P-CCPCH S-CCPCH DPCH

Figure 4-35 UTRAN channel mapping (downlink)

HS-PDSCH

DCCH CCCH DTCH

DCH RACH E-DCH

DPDCH PRACH E-DPDCH

Figure 4-36 UTRAN channel mapping (uplink)

In a cellular system, the radio channel conditions experienced by different downlink communication links will typically vary significantly, both in time and between different positions within the cell. In general, there are several reasons for these variations and differences in instantaneous radio channel conditions:

110


4 E-UTRAN

•

The channel conditions will differ significantly between different positions within the cell, due to distance dependent path loss and location dependent shadowing.

•

The channel conditions will vary due to variations in the interference level. The interference level will depend on the position within the cell, with typically higher interference level close to the cell border.

However, the interference level will also depend on the instantaneous transmission activity of neighbour cells. The transmission activity of a cell could vary significantly, especially when bursty high rate data traffic contributes a major part of the overall traffic. Note that there may not only be interference from other cells. In case of a time dispersed channel, downlink orthogonality will be lost, causing own cell interference.

• The instantaneous channel conditions will vary rapidly due to multipath fading. The rate of these variations depends on the speed of the mobile terminal. Typically there will be significant variations during a fraction of a second.

In 2G and 3G (non-HSPA) systems, power control is used to compensate for differences and variations in the instantaneous downlink radio channel conditions. In principle, power control allocates a proportionally larger part of the total available cell power to communication links with bad channel conditions. This ensures similar service quality to all communication links, despite differences in the radio channel conditions. At the same time, radio resources are more efficiently utilised when they are allocated to communication links with good channel conditions. Thus, from an overall system throughput point of view, power control is not the most efficient means to allocate available resources.

In general, the goal is to ensure sufficient received energy per information bit for all communication links, despite variations and differences in the channel conditions. Power control achieves this by adjusting the transmission power while keeping the data rate constant.

For services that do not require a specific data rate, such as many best effort services, adjusting the data rate, while keeping the transmission power constant, can also control the energy per information bit. This can be referred to as rate control and rate adjustment. It is also often referred to as (fast) link adaptation, although, in principle, power control can also be seen as a kind of link adaptation.

There are different means by which the data rate can be adjusted to compensate for variations and differences in the instantaneous channel conditions:

111



• by adjusting the channel coding rate - the use of channel coding with higher coding rate allows for higher data rates at the expense of less robustness to channel impairments,

• by adjusting the modulation scheme - the use of higher order modulation, such as 16QAM, allows for more bits per modulation symbol and thus for higher data rates. However, this is achieved at the expense of less robustness to channel impairments.

user data coding

Figure 4-37 Link adaptation

Hybrid Automatic Repeat Request (HARQ) is a technique combining

Forward Error Correction (FEC) and ARQ methods that save information from previous failed attempts to be used in future decoding.

HARQ is an implicit link adaptation technique. Whereas conventional link adaptation uses explicit C/I or similar measurements to set the modulation and coding format, HARQ uses link layer acknowledgements (ACK/NACK) for retransmission decisions.

Data Block #1

Data Block #2

Data Block #3

NACK

Data Block #2

ACK

Figure 4-38 HARQ with soft combining

112


4 E-UTRAN

For a re-transmission, HARQ may use a different modulation scheme, RBs set, transmission power or MIMO scheme. As a result, the number of channel bits available for a re-transmission may differ from that of the initial transmission.

To minimise the number of additional retransmission requests, HARQ uses two soft combining schemes to ensure proper message decoding:

•

Chase Combining (CC) involves sending an identical version of an erroneously detected packet; received copies are combined by the decoder prior to decoding.

•

Incremental Redundancy (IR) involves sending a different set of bits incrementally to be combined with the original set, thus increasing the amount of redundant data and the likelihood of recovering from errors introduced on the air. turbo encoder systematic parity 1 parity 2 rate matching (puncturing) original transmission retransmission

Chase Combining (CC)

Figure 4-39 Chase combining principle turbo encoder systematic parity 1 parity 2 rate matching (puncturing) original transmission retransmission

Incremental Redundancy combining (IR)

Figure 4-40 Incremental redundancy principle

113



The advantage of CC is that requires less ultra fast memory for the soft combining process, however it is less efficient in error correction in comparison to IR.

The eNB scheduler (for unicast transmission) dynamically controls which time/frequency resources are allocated to a certain user at a given time.

Downlink control signalling informs UEs what resources and respective transmission formats have been allocated. The scheduler can dynamically choose the best multiplexing strategy from the available methods, e.g. localised or distributed allocation. Obviously, scheduling is tightly interacting with link adaptation and HARQ.

The decision of which user transmission to multiplex within a given subframe may, for example, be based on:

• minimum and maximum data rate,

• available power to share among mobiles,

•

BER target requirements according to the service,

• latency requirements, depending on the service,

•

QoS parameters and measurements,

• payload buffered in the eNB/UE ready for scheduling,

• pending retransmissions,

•

CQI (Channel Quality Indicator) reports from the UEs,

•

UE capabilities, sleep cycles and measurement gaps/periods.

Methods to reduced the control signalling overhead, e.g. pre-configuring the scheduling instants (e.g. semi-persistent scheduling for applications like

VoIP), similar to methods defined for UTRAN/HSPA Continuous Packet

Connectivity (CPC) are still possible.

114

Figure 4-41 Fast channel dependent scheduling


4 E-UTRAN

RRC

User plane

System info broadcast

Control plane

Paging RRC

Ciphering, integrity

PDCP

RLC

ROHC, ciphering

ROHC, ciphering radio bearers

Segm.

ARQ

Segm.

ARQ logical channels

ROHC, ciphering

Segm.

ARQ scheduling / priority handling

MAC

PHY

MUX

HARQ transport channels channel coding physical channels

HARQ channel coding

Figure 4-42 LTE-Uu protocols

Segm.

ARQ

HARQ channel coding

The Radio Resource Control (RRC) supports all the signalling procedures between the terminal and eNB. This includes mobility procedures as well as terminal connection management. The signalling from the EPC Control Plane

(e.g. for terminal registration or authentication) is transferred to the terminal through the RRC protocol, hence the link between the RRC and upper layers.

The Packet Data Convergence Protocol (PDCP) layer (whose main role consists of header compression and implementation of security such as encryption and integrity) is offered to radio bearers by E-UTRAN lower layers. Each of these bearers corresponds to a specific information flow such as User plane data (e.g. voice frames, streaming data, IMS signalling) or

Control plane signalling (such as RRC or NAS signalling).

The Radio Link Control (RLC) layer provides to the PDCP layer basic

OSI-like L2 services such as packet data segmentation and Automatic Repeat

Request (ARQ) as an error correction mechanism. There is one-to-one mapping between each RLC input flow and logical channel provided by RLC to the MAC layer.

The Medium Access Control (MAC) layer’s main task is to map and multiplex the logical channels onto the transport channels after having performed priority handling on the data flows received from the RLC layer.

The MAC also supports HARQ, which is a fast repetition process.

Finally, the MAC delivers the transport flows to the Physical layer, which will apply the channel coding and modulation before transmission over the radio.

115




116


5 Core Network

Chapter 5

MME in Pool.................................................................................................. 119

Signalling Transport (SIGTRAN).................................................................. 124

User data transfer ........................................................................................... 131

Diameter......................................................................................................... 135

Quality of Service .......................................................................................... 137


117



118


5 Core Network

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes, introduced in UMTS R5, overcomes the strict hierarchy, which restricts the connection of a RAN node to just one CN node. This restriction in

GSM/UMTS results from routing mechanisms in the RAN nodes which differentiate only between information to be sent to the PS or to the CS domain CN nodes and which do not differentiate between multiple CN nodes in each domain. The Intra Domain Connection of RAN Nodes to Multiple CN

Nodes introduces a routing mechanism (and other related functionality), which enables the RAN nodes to route information to different CN nodes within the CS or PS domain, respectively.

GGSN GGSN

SGSN SGSN SGSN

RNC RNC RNC RNC RNC

Figure 5-1 Network hierarchy GSM/UMTS R4-

RNC

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes introduces further the concept of ‘pool-areas’ which is enabled by the routing mechanism in the RAN nodes. A pool-area is comparable to an MSC or

SGSN service area as a collection of one or more RAN node service areas. In difference to an MSC or SGSN service area a pool-area is served by multiple

CN nodes (MSCs or SGSNs) in parallel which share the traffic of this area between each other. Furthermore, pool-areas may overlap which is not possible for MSC or SGSN service areas. From a RAN perspective a pool-area comprises all LA(s)/RA(s) of one or more RNC/BSC that are served by a certain group of CN nodes in parallel. One or more of the CN nodes in this group may in addition serve LAs/RAs outside this pool-area or may also serve other pool-areas. This group of CN nodes is also referred to as MSC pool or SGSN pool respectively.

119



GGSN GGSN

SGSN SGSN SGSN

RNC RNC RNC RNC RNC RNC

Pool area 1

Figure 5-2 Network hierarchy GSM/UMTS R5+

Pool area 2

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes enables a few different application scenarios with certain characteristics. The service provision by multiple CN nodes within a pool-area enlarges the served area compared to the service area of one CN node. This results in reduced inter CN node updates, handovers and relocations and it reduces the HSS update traffic.

The configuration of overlapping pool-areas allows to separate the overall traffic into different MS moving pattern, e.g. pool-areas where each covers a separate residential area and all the same city centre. Other advantages of multiple CN nodes in a pool-area are the possibility of capacity upgrades by additional CN nodes in the pool-area or the increased service availability as other CN nodes may provide services in case one CN node in the pool-area fails.

A user terminal is served by one dedicated CN node of a pool-area as long as it is in radio coverage of the pool-area.

The fact that the BSC can co-operate with the several SGSN does not implies that the separate physical interfaces are required since the IP network can be used between BSCs and SGSNs to switch the traffic delivered on the same physical interfaces to different recipients connected to that network.

SGSN

1

SGSN

2

SGSN

3

IP network

120

BSC

1

BSC

2

BSC

3

BSC

4

BSC

5

Figure 5-3 SGSNs in Pool (physical view with Gb/IP)

BSC

6


5 Core Network

Similarly to GSM/UMTS, where the MSC/SGSN in Pool is already quite popular solution, the EPS network may utilise the solution called MME in

Pool. However, some aspects of the CN nodes pool solution for GSM/UMTS and EPS networks are different:

•

There is only one CN domain in EPS, that is PS domain, so there is only necessity for the MME nodes to be pooled,

•

The MME in Pool concept is introduced in the first release of the standard for the EPS network, so right from the beginning all

MMEs/eNBs can support MME in Pool specific procedures. (In

GSM/UMTS there was a necessity to solve backward compatibility problems between MSCs/SGSNs capable and non-capable of supporting pool area concept.)

•

The temporary UE identity GUTI that holds the binding between the

UE and it’s serving MME in EPS has a structure that directly supports the concept of the MME in Pool, in contradiction to GSM/UMTS where TMSI/P-TMSI structure was modified for that purpose. Since new R5 TMSI/P-TMSI structure has to be backward compatible with

R4, the solution is slightly less efficient, introduces some extra signalling load and in some cases may result in the situation where subscriber are not subjected to inter MSC/SGSN load distribution.

Figure 5-4 MME in Pool

A pool-area is an area within which a UE may roam without a need to change the serving MME node. A pool-area is served by one or more MMEs nodes in parallel. The complete service area of a eNB (i.e. all the cells being served by one eNB) belongs to the same one or more pool-area(s). A eNB service area may belong to multiple pool-areas, which is the case when multiple overlapping pool-areas include this eNB node service area. If TA spans over multiple eNB service areas then all these eNB service areas have to belong to the same MME pool-area.

Additionally, when the TA list, the UE is registered to, spans over multiple eNB service areas then also all these eNB service areas have to belong to the same MME pool area.

121


LTE/EPS Technology eNB eNB eNB eNB

MME

MME

MME eNB

An MME pool-area is an area within which an MS roams without a need to change the serving MME.

Figure 5-5 MME pool area

MME selection and a ddressing

Each time the UE leaves the current MME pool area, the eNB runs MME selection function. The MME selection function selects an available MME for serving a UE. The selection is based on network topology, i.e. the selected

MME serves the UE’s location and in case of overlapping MME service areas, the selection may prefer MMEs with service areas that reduce the probability of changing the MME.

The selected MME allocates a Globally Unique Temporary Identity (GUTI) to the UE. The GUTI has two main components:

•

Globally Unique MME Identifier (GUMMEI) uniquely identifying the

MME which allocated the GUTI,

•

M-TMSI uniquely identifying the UE within the MME that allocated the GUTI.

S-TMSI

GUMMEI

MCC MNC MMEGI MMEC

MMEI

GUMMEI Globally Unique MME Identifier

MMEGI MME Group ID

MMEC MME Code

MMEI MME Identifier

M-TMSI

Figure 5-6 GUTI structure

122


5 Core Network

The GUTI structure directly supports the concept of the MME pool area.

Since during each identification the UE, not only identifies itself but also the

MME that has allocated its temporary identity. Therefore, even in case of intra MME pool area mobility, each eNB easily can route the data from the

UE to the MME which holds the user subscription and session information.

eNB MME

(GUMMEI #1)

GUTI (GUMMEI #2)

MME

(GUMMEI #2)

GUTI (GUMMEI #2)

eNB

MME

(GUMMEI #3)

MME selection

GUTI/GUMMEI allocation

GUMMEI routing

Figure 5-7MME in Pool and GUTI

In case of inter MME pool area mobility the new eNB, can easily discover that the UE is coming from another pool area, the eNB is not a part of. In that case the eNB runs the MME selection process that will choose the new MME for the UE, which in turn allocates the new GUTI. The new GUTI (that includes the new MME’s identity) is used from that moment to route signalling messages from the UE to the selected MME, until the MME pool area is changed.

The MME Load Balancing functionality permits UEs that are entering into an

MME Pool Area to be directed to an appropriate MME in a manner that achieves load balancing between MMEs. This is achieved by setting an MME weight factor (called MME Relative Capacity) for each MME, such that the probability of the eNB selecting an MME is proportional to its capacity. The

MME Relative Capacity parameter is typically set according to the capacity of an MME node relative to other MME nodes.

123



MME relative capacity

MME

10 eNB

10

20

MME

MME

Figure 5-8 Load balancing

The MME Load Re-balancing functionality permits UEs that are registered on an MME (within an MME Pool Area) to be moved to another MME.

An example use for the MME Load Re-balancing function is for the O&M related removal of one MME from an MME Pool Area.

MME

MME

MME

Figure 5-9 Load re-balancing

Signall ing Transport (SIGTRAN)

Signalling Transport (SIGTRAN) is a new set of standards defined by the

International Engineering Task Force (IETF). This set of protocols has been defined in order to provide the architectural model of signalling transport over

IP networks.

124


5 Core Network

To reliably transport signalling messages over IP networks, the IETF

SIGTRAN working group devised the Stream Control Transmission Protocol

(SCTP). SCTP allows the reliable transfer of signalling messages between signalling endpoints in an IP network.

Opposed to TCP connection, an SCTP association can take advantage of a multihomed host using all the IP addresses the host owns. This feature is one of the most important ones in SCTP as it gives some network redundancy that is really valuable when dealing with signalling. In the older signalling systems, like SS7, every network component is duplicated, and the idea of loosing a TCP connection due to the failure of one of the network cards was one of the major problems that made SCTP necessary.

endpoint/socket = IP address + TCP port number

connection

IP path

Figure 5-10 Singlehomed protocol (TCP)

endpoint/socket = IP address es + SCTP port number association

IP path s

Figure 5-11 Multihomed protocol (SCTP)

125



IP signalling traffic is usually composed of many independent message sequences between many different signalling endpoints. SCTP allows signalling messages to be independently ordered within multiple streams

(unidirectional logical channels established from one SCTP endpoint to another) to ensure in-sequence delivery between associated endpoints. By transferring independent message sequences in separate SCTP streams, it is less likely that the retransmission of a lost message will affect the timely delivery of other messages in unrelated sequences (problem called

head-of-line blocking). Because TCP/IP does enforce head-of-line blocking, the SCTP is better suited, rather than TCP/IP, for the transmission of signalling messages over IP networks. application

5 4 3 2 1

TCP connection

Re-Tx 1

4

5

2

3 buffered

Figure 5-12 Head-Of-Line (HOL) blocking – single TCP connection

2 1

Stream 0

Stream

0

SCTP user

Stream

1

Stream

2

SCTP association

6 5

Stream 1

46 45

Stream 2

2

5

6

45

46 buffered delivered delivered

Figure 5-13 SCTP association with several streams

TCP is stream oriented, and this can be also an inconvenience for some applications, since usually they have to include their own marks inside the stream so the beginning and end of their messages can be identified. In addition, they should explicitly make use of the push facility to ensure that the complete message has been transferred in a reasonable time.

126


TCP user

5 Core Network

TCP user

TCP

TCP

Figure 5-14 Stream oriented protocol (TCP)

Opposed to TCP, an SCTP is message oriented. This means that the SCTP is aware of the upper layer protocol data structures, thus always a complete messages, well separated from each other are deliver to the SCTP user on the receiving side.

SCTP user

SCTP user

SCTP

SCTP

Figure 5-15 Message oriented protocol (SCTP)

SCTP is using and new method for association establishment. It completely removed the problem of the so-called SYN attack in TCP. This attack is very simple and can affect any system connected to the Internet providing

TCP-based network services (such as an HTTP, FTP or mail server).

Let us see in short how this basic attack is performed. In TCP, the establishment phase consists of a three-way handshake. These three packets are usually called SYN (from Synchronisation, as it has the SYN flag set, used only during the establishment), SYN-ACK (it has both the SYN and

ACK flags set) and ACK (this is a simple acknowledgement message with the

ACK flag set).

The problem is that the receiver of the SYN not only sends back the

SYN-ACK but also keeps some information about the packet received while waiting for the ACK message (a server in this state is said to have a half-open connection).

127



Client

SYN

SYN ACK

Server

Ack No. = 0, Seq. No. = Tag A

Ack No. = Tag A , Seq. No. = Tag B

TCB

ACK Ack No. = Tag B , ...

Figure 5-16 Establishment procedure (TCP)

The memory space used to keep the information of all pending connections is of finite size and it can be exhausted by intentionally creating too many half-open connections. This makes the attacked system unable to accept any new incoming connections and thus provokes a denial of service to other users wanting to connect to the server. There is a timer that removes the half-open connections from memory when they have been in this state for so long, and that will eventually make the system to recover, but nothing will change if the attacker continues sending SYN messages.

SYN

SYN

SYN

SYN

Fake IP address A

Fake IP address B

Fake IP address C

Fake IP address ...

SYN

ACK

RST

SYN

AC

K

RST

SY

N A

CK

S

Y

N

A

C

K

R

ST

Figure 5-17 SYN attack in TCP

As we see, the attacker uses IP spoofing, making it unable to receive the

SYN-ACK segments produced, which is not a problem since it will never answer them. All those SYN-ACK segments will be lost unless there is any host with TCP service listening to the port and addresses used as the source of the SYN segment. In that case that host will answer with a segment carrying the RST (from Reset) flag set and the attacked system will delete the information for that specific half-open connection.

SCTP gives no chance of success to this kind of attacks with its cookie mechanism. When the designers of SCTP started to think about how to deal

128


5 Core Network with SYN flooding, they quickly saw that two things were necessary in order not to make a new transport protocol with the same weakness:

•

The server (the initiate of a new association) should not use even a byte of memory until the association is completely established.

•

There must be a way to recognise that the client (the initiator of the association) is using its real IP address.

Usually, to meet the second requirement, the server sends some kind of key number to the client who will only receive that information if the source address used in its IP datagram is the real one. Once the client has that information, it can then send a confirmation to the server using that key number thus proving that it was telling the truth. This means that the server needs to save somewhere that key number as well so there is a way it can verify that the key number was the right one. But then comes the problem of being forced to store that value somewhere and using some memory resources while waiting for the answer that might never come.

Therefore, the idea was: why not instead of storing that information in our system we make it to stay all the time in the network or in the client's memory? Of course, one immediately thinks that if a datagram coming from the client is the one that is going to provide us the information to check against the client's answer, we have not done anything but making worse the situation. The client will tell us whatever it wants and then it could just completely open an association sending us a simple message.

But this is not necessarily true if we manage to convert the two problems into another one: the server has to sign with a secret key the information sent to the client. So, when it receives that information back from the client, it can recognise due to the signature and using the secret key, that it did send exactly that information, which is unmodified, and so we can be as confident on it as if it had never left the server's buffers.

Client

INIT

INIT ACK

Server

COOKIE

TCB

(COOKIE)

COOKIE ECHO (COOKIE)

TCB

COOKIE ACK

Figure 5-18 Cookie (SCTP association establishment)

129



Traditionally, on all the interfaces in GSM/UMTS CN, as well as, on interfaces connecting CN with the RAN, the SS7 is used. However the traditional SS7 protocols stack is not a good solution for the networks with IP transport since it still requires traditional TDM based interfaces to carry SS7 signalling links. That is way, majority of the GSM/UMTS operators are replacing traditional SS7 protocol stack with SIGTRAN. However, since it is just the modification of the traditionally SS7 protocol stack, only the MTP and sometimes additionally SCCP protocols are replaced by SIGTRAN, whereas the upper layers remains unchanged. This requires an extra set of protocols called the SIGTRAN User Adaptation Layers (UALs) introducing some extra cost, consuming processing power of the signalling nodes and adding also some complexity to the system. In fact, SIGTRAN in the today networks is only emulating the behaviour of the transport layers of the SS7.

Q.931

V5.2

ISUP BSSAP MAP CAP

M2PA

MTP3

M2UA

SCCP

M3UA

TCAP

SCTP

IP

SUA IUA V5UA

Figure 5-19 SIGTRAN protocol suite

The User Adaptation Layers are named according to the service they replace, rather than the user of that service. For example, M3UA adapts SCTP to provide the services of MTP3, rather then providing a service to MTP3.

SIGTR AN in EPS

Since EPS is introducing a completely new set of the signalling protocols, these protocols were designed to operate directly on top of SCTP, without need for any User Adaptation Layers. Hence, the protocol stack is not only more elegant, but also it is much more efficient. Instead of emulating the

130


5 Core Network behaviour of the traditional SS7 the, the SCTP can provide its services directly to the top most protocols, so they are now ready to fully utilise capabilities of the SCTP. Thanks to the fact, that there is less protocols in the stack the new system behaves better in terms of both, transmission bandwidth utilisation, as well as processing power consumption in the end devices.

S1AP X2AP

SCTP

IP

SGsAP

Figure 5-20 SIGTRAN in EPS

Diameter

The EPS nodes are interconnected via a private IP network of the operator, thus when communicating between each other they are using IP addresses from that private IP network.

The IP address allocated to the user is in fact belonging to the external PDN addressing space, as it is used between the UE and the servers in the external network.

IP address allocation

IP eNB

IP

S-GW

IP

IP private

IP IP

P-GW

IP

IP private or public

Figure 5-21 Tunnelling

This means that on the interface which carries user data, user IP packets going to and from PDN have to be send inside other IP packets going between EPS nodes.

131



IP

S-GW

IP

P-GW

IP

Figure 5-22 User IP packet encapsulation

GPRS Tunnelling Protocol (GTP) is a group of IP-based communications protocols used to carry user IP packets within GSM, UMTS and EPS networks. GTP can be decomposed into two separate protocols: GTP-C and

GTP-U.

GTPv2-C is used within the EPC for signalling between S-GW, P-GW, SGSN and SRVCC enhanced MSC server. This allows the EPC to activate a session on a user's behalf (EPS bearer), to deactivate the same session, to adjust QoS parameters, or to update a session for a subscriber changing S-GW or SGSN.

Additionally, GTPv2-C is used to perform PS to CS handover between MME and SRVCC enhanced MSC (see Chapter 10 for more details).

GTPv1-U is used for carrying user data within the EPC, between eNBs and

S-GWs (S1 interface) and between neighbouring eNBs (X2 interface).

UE is connected to an eNB without being aware of GTP.

GTP tunnels are used between two nodes communicating over a GTP based interface, to separate traffic into different communication flows.

132

S1/S3/S4/S5/S8/

S10/S11/S12/Sv/X2

Figure 5-23 GTP protocol stack


5 Core Network

A GTP tunnel is identified in each node with a Tunnel Endpoint Identifier

(TEID), an IP address and a UDP port number. The receiving end side of a

GTP tunnel locally assigns the TEID value the transmitting side has to use.

The TEID values are exchanged between tunnel endpoints using GTP-C,

S1-MME or X2-eNB messages.

X2AP S1AP

MME

GTP-C GTP-C eNB

GTP-U eNB

RNC

S-GW

GTP-U

GTP-U

GTP-U

SGSN

GTP-U

P-GW

RANAP

Figure 5-24 Tunnel control protocols

Tunnel establishment

The generic GTP-C/GTP-U tunnel establishment procedure is shown in

Fig.-5-25.

Node 1

Create Tunnel Request ( )

Create Tunnel Response ( )

Data

Control

Node 2

TEID & IP @ Node 1 for data

TEID & IP @ Node 1 for signalling

TEID & IP @ Node 2 for data

TEID & IP @ Node 2 for signalling

Figure 5-25 Generic tunnel establishment procedure

133



The node that is initiating the tunnel establishment sends to the terminating node the Create Tunnel Request message; the message among many other procedure specific parameters includes:

•

Tunnel Endpoint Identifier (TEID) for User Plane that specifies a TEID for GTP-U, chosen by the originating node. The terminating node includes this TEID in the GTP-U header of all subsequent

GTP-U packets, send in the backward direction.

•

Tunnel Endpoint Identifier (TEID) for Control Plane that specifies a TEID for control plane message, chosen by the originating node. The terminating node includes this TEID in the GTP-C header of all subsequent GTP-C packets, send in the backward direction. Those packets can carry messages used to complete the tunnel establishment, modify the already existing tunnel or to release the existing tunnel,

•

Originating node’s IP address for User Plane,

•

Originating node’s IP address for Control Plane.

The terminating node answers with the Create Tunnel Response message which contains:

•

Tunnel Endpoint Identifier (TEID) for User Plane that specifies a TEID for GTP-U, chosen by the terminating node. The originating node includes this TEID in the GTP-U header of all subsequent

GTP-U packets, send in the forward direction.

•

Tunnel Endpoint Identifier (TEID) for Control Plane that specifies a TEID for control plane messages, chosen by the terminating node.

The originating node includes this TEID in the GTP-C header of all subsequent GTP-C packets, sent in the forward direction.

•

Terminating node’s IP address for User Plane,

•

Terminating node’s IP address for Control Plane.

From that moment the user communication context on one side of the tunnel is associated with the corresponding context on the other side of the tunnel.

This association is kept thanks to allocation of flow specific pairs of IP addresses and TEIDs for both user data and control messages.

134


5 Core Network

Diameter is an AAA (Authentication, Authorisation and Accounting) protocol for applications such as network access or IP mobility. The basic concept is to provide a base protocol that can be extended in order to provide AAA services to new access technologies. Diameter is intended to work in both local and roaming

AAA situations.

Diameter sessions consist of exchange of commands and Attribute Value

Pairs (AVPs) between authorised Diameter Clients and Servers. Some of the command values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter.

The base protocol provides basic mechanisms for reliable transport, message delivery and error handling. It must be used along with a Diameter application. A Diameter application uses the services of base protocol in order to support a specific type of service. The Diameter Base Protocol defines basic and standard behaviour of Diameter nodes as well-defined state machines and also provides an extensible messaging mechanism that allows information exchange among Diameter Nodes. Diameter Applications augment the Base Protocol state machines with application-specific behaviour to provide new AAA capabilities.

There are two kinds of applications: IETF standards track applications and vendor specific applications. The 3GPP Diameter application, relevant to

EPS, are listed in Fig. 5-26.

PCRF ↔ AF

PCRF ↔ PCEF (P-GW)

MME ↔ HSS

MME/SGSN ↔ EIR vPCRF ↔ hPCRF

Figure 5-26 3GPP Diameter applications

The Diameter peers are communicating with each other over transport connection provided by SCTP (SCTP association).

135



S6a/S13/S9/Rx/Gx

Figure 5-27 Diameter protocol stack

The Diameter base protocol defines two types of Diameter agent, namely

Diameter Relay agent and Diameter Proxy agent.

Diameter Relay is a function specialised in message forwarding, i.e.:

•

A Relay agent does not inspect the actual contents of the message.

•

When a Relay agent receives a request, it will route messages to nexthop Diameter peer based on information found in the message e.g. application ID and destination address.

Diameter Proxy includes the functions of Diameter Relay and additionally it can inspects the actual contents of the message to perform admission control, policy control, add special information elements handling.

The use of Proxy and Relay agent is especially important in case of roaming scenarios to support scalability, resilience and maintainability and to reduce the export of network topologies.

IMSI

Update Location Request,

Destination Realm: epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org.

User Name: IMSI

HSS

MME

MME

PCRF

Proxy/

Relay GRX/IPX

Proxy/

Relay

HSS

HSS

MME

PCRF

Figure 5-28 Diameter Proxy/Relay agent

Please, note that without usage of Diameter Proxy/Relay agents it would be necessary to provide a separate Diameter connection (SCTP association) between each MME of the VPLMN and each HSS of every possible HPLMN.

136


5 Core Network

Q uality o f S

The EPS provides IP connectivity between a UE and a PLMN external packet data network. This is referred to as PDN Connectivity Service. The PDN

Connectivity Service supports the transport of one or more Service Data

Flows (SDFs).

For E-UTRAN access to the EPC the PDN connectivity service is provided by an EPS bearer.

An EPS bearer uniquely identifies an SDF aggregate between a UE and a

P-GW.

An EPS bearer is the level of granularity for bearer level QoS control in the

EPC/E-UTRAN. That is, SDFs mapped to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. scheduling policy, queue management policy, rate shaping policy, RLC configuration, etc.). Providing different bearer level QoS to two SDFs thus requires that a separate EPS bearer is established for each SDF. eNB S-GW

EPS Bearer #1 (bearer QoS

1

)

P-GW

EPS Bearer #2 (bearer QoS

2

)

PDN

Service Data Flow (PCC parameters)

Figure 5-29 EPS bearer

One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the default bearer. Any additional EPS bearer that is established to the same PDN is referred to as a dedicated bearer.

137


LTE/EPS Technology eNB S-GW

Dedicated Bearer (additional bearer, GBR or non-GBR)

P-GW

Default Bearer (created as a part of Attach proc., non-GBR)

PDN

Figure 5-30 Default & dedicated bearer

An UpLink/DownLink Traffic Flow Template (UL/DL TFT) is a set of

UL/DL packet filters. Every EPS bearer is associated with an UL TFT in the

UE and a DL TFT in the P-GW (i.e. PCEF).

UE

Filters eNB S-GW

EPS Bearer #1

EPS Bearer #2

P-GW

Filters PDN

Figure 5-31 Traffic Flow Template (TFT)

The initial bearer level QoS parameter values of the default bearer are assigned by the network, based on subscription data (in case of E-UTRAN the

MME sets those initial values based on subscription data retrieved from HSS).

The PCEF may change those values based in interaction with the PCRF or based on local configuration.

The decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer level QoS parameter values are always assigned by the EPC. Therefore, the MME does not modify the bearer level QoS parameter values received on the S11 reference point during establishment or modification of a dedicated bearer.

Instead, the MME only transparently forwards those values to the E-UTRAN. Consequently, ‘QoS negotiation’ between the E-UTRAN and the EPC during dedicated bearer establishment / modification is not supported. The MME may, however, reject the establishment or modification of a dedicated bearer (e.g. in case the bearer level QoS parameter values sent by the PCEF over an S8 roaming interface do not comply with a roaming agreement).

138


5 Core Network

‘Bearer establishment trigger’

PCRF eNB S-GW

Bearer establishment direction

P-GW

AF no QoS negotiation

Figure 5-32 Bearer establishment direction

An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR) value that is associated with the EPS bearer are permanently allocated (e.g. by an admission control function in the eNB) at bearer establishment/modification. Otherwise, an EPS bearer is referred to as a Non-GBR bearer.

A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer is a Non-GBR bearer.

An EPS bearer is realised by the following elements:

•

An UL TFT in the UE maps an SDF to an EPS bearer in the UL direction. Multiple SDFs can be multiplexed onto the same EPS bearer by including multiple UL packet filters in the UL TFT;

•

A DL TFT in the P-GW maps an SDF to an EPS bearer in the DL direction. Multiple SDFs can be multiplexed onto the same EPS bearer by including multiple DL packet filters in the DL TFT;

•

A radio bearer transports the packets of an EPS bearer between a UE and an eNB. There is a one-to-one mapping between an EPS bearer and a radio bearer;

•

An S1 bearer transports the packets of an EPS bearer between an eNB and a S-GW;

•

An S5/S8 bearer transports the packets of an EPS bearer between a

S-GW and a P-GW;

•

A UE stores a mapping between an UL packet filter and a radio bearer to create the mapping between an SDF and a radio bearer in the UL;

•

A P-GW stores a mapping between a DL packet filter and an S5/S8 bearer to create the mapping between an SDF and an S5/S8 bearer in the DL;

139



•

An eNB stores a one-to-one mapping between a radio bearer and an

S1 to create the mapping between a radio bearer and an S1 bearer in both the UL and DL;

•

A S-GW stores a one-to-one mapping between an S1 bearer and an

S5/S8 bearer to create the mapping between an S1 bearer and an S5/S8 bearer in both the UL and DL.

The bearer level (i.e. per bearer or per bearer aggregate) QoS parameters are

QCI, ARP, GBR, MBR, and AMBR described in this section.

Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS parameters:

•

QoS Class Identifier (QCI);

•

Allocation and Retention Priority (ARP).

A QCI is a scalar that is used as a reference to access node-specific parameters that control bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operator owning the access node (e.g. eNB).

The primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or needs to be rejected in case of resource limitations (typically available radio capacity in case of GBR bearers). In addition, the ARP can be used (e.g. by the eNB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at handover).

Once successfully established, a bearer's ARP has no any impact on the bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding treatment should be solely determined by the other bearer level QoS parameters: QCI, GBR, MBR, and AMBR.

Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNB can then drop the ‘video bearer’ without affecting the ’voice bearer’. This would improve service continuity.

140


5 Core Network

Each GBR bearer is additionally associated with the following bearer level

QoS parameters:

•

Guaranteed Bit Rate (GBR);

•

Maximum Bit Rate (MBR).

The GBR denotes the bit rate that can be expected to be provided by a GBR bearer. The MBR limits the bit rate that can be expected to be provided by a

GBR bearer (e.g. excess traffic may get discarded by a rate shaping function).

Each APN is associated with the ‘per APN Aggregate Maximum Bit Rate

(APN-AMBR)’ IP-CAN session level QoS parameter. The APN-AMBR is a subscription parameter stored per APN in the HSS. It limits the aggregate bit rate that can be expected to be provided across all Non-GBR bearers and across all PDN connections of the same APN (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non-GBR bearers could potentially utilise the entire APN-AMBR, e.g. when the other Non-GBR bearers do not carry any traffic. GBR bearers are outside the scope of

APN-AMBR. The P-GW enforces the APN-AMBR in downlink.

Enforcement of APN-AMBR in uplink is done in the UE and additionally in the P-GW.

Each UE is associated with the ‘per UE Aggregate Maximum Bit Rate

(UE-AMBR)’ bearer level QoS parameter. The UE-AMBR is limited by a subscription parameter stored in the HSS. The MME sets the used UE-AMBR to the sum of the APN-AMBR of all active APNs up to the value of the subscribed UE-AMBR. The UE-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR bearers of a UE (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non-GBR bearers could potentially utilise the entire UE-AMBR, e.g. when the other

Non-GBR bearers do not carry any traffic. GBR bearers are outside the scope of UE-AMBR. The E-UTRAN enforces the UE-AMBR in uplink and downlink.

The GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/

APN-AMBR denote bit rates of traffic per group of bearers. Each of those

QoS parameters has an uplink and a downlink component. On S1_MME the values of the GBR, MBR, and AMBR refer to the bit stream excluding the

GTP-U/IP header overhead of the tunnel on S1_U.

One 'EPS subscribed QoS profile' is defined for each APN permitted for the subscriber. It contains the bearer level QoS parameter values for that APN's default bearer (QCI and ARP) and the APN-AMBR.

141



GBR bearer

GBR

MBR

EPS bearer non-GBR bearer

QCI

ARP

UE-AMBR APN-AMBR

Figure 5-33 EPS bearer related QoS parameters

Mapping between Q C

A recommended mapping for QoS Class Identifier to/from UMTS QoS parameters is shown in Fig. 5-34.

-

-

-

-

-

-

-

-

-

-

-

-

-

Figure 5-34 QCI to UMTS QoS parameters mapping

142


6 Policy Control and Charging

Chapter 6

Policy C ontrol and C harging

Introduction.................................................................................................... 145

Policy Control ................................................................................................ 150

Charging......................................................................................................... 150


143



144



First of all this it is necessary to have a definition of the policy control.

According to IETF, the first standard body that has been working on policy control for IP networks, the policy control is the application of rules to

determine resource access and usage.

Policy control is described in 3GPP specifications as being part of the Packet

Core network architecture. Actually, this feature interacts not only with

Packet Core nodes, but also with SIP servers belonging to the IMS, such as the P-CSCF.

Policy control and charging in the past

In early UMTS implementation (including UMTS R5) policy control was user/terminal driven. Depending on the requested service (Web browsing, streaming, Push-to-Talk), the user terminal was requesting a Packet Data

Protocol (PDP) context with QoS attributes being set accordingly to the type of the service. service #1

HSS

GPRS Core

PDP context #1

APN #1

SGSN GGSN

PDP context #2

APN #2

CDR CDR CDR CDR service #2

Figure 6-1 Policy Control and Charging (UMTS R5-)

The requested Access Point Name (APN) and QoS parameters were eventually checked by the SGSN based on user subscription limitation stored in the HSS. Using a set of Charging Data Records (CDRs) defined by the standard and generated by the network elements such as the SGSN and

GGSN, the operator had the possibility of charging the end subscriber either on time, volume or on allocated QoS. However, it was not possible to apply differentiated charging rules for a different service data flows which could possibly be aggregated within a single PDP context, as the end-user has

145


LTE/EPS Technology actually no constrains for opening a new PDP context for each new type of application being used.

As IMS really began to emerge from the standard, and considering the future of IP-based applications (including the upcoming VoIP), the 3GPP community decided to define a new architecture for more flexible policy control and charging mechanisms.

Thanks to R6 evolution, the network has the possibility to identify the different Service Data Flows (SDFs) being aggregated within a single PDP context. This gives the possibility to the network of controlling (meaning allowing or blocking) each of the flows and charging the end-user having a much better accuracy.

HSS service #1

GPRS Core

PDP context #1

SGSN GGSN APN #1

CDR CDR

SDF #1 SDF #2 usage usage

Figure 6-2 Policy Control and Charging (UMTS R6+) service #2

Each of those elementary flows, also known as SDF, is defined as a 5-tuple

(source IP address, destination IP address, source port, destination port and a protocol used above IP). This definition allows identifying each of the information flows from the mass of IP packets sent and received by the terminal, for example:

• a web-browsing session towards server ‘A’,

• another web-browsing session towards server ‘B’,

• a streaming session from server ‘C’,

• a SIP-signalling flow associated to an IMS service.

Fig. 6-3 illustrates the new network elements introduced in the UMTS R6 to allow flow-based policy control and charging. For that purpose, two new network elements have been introduced:

•

Policy Decision Function (PDF),

•

Charging Rules Function (CRF).

146



CRF

Gx

Go

PCEF

GGSN

PDF

Gi

Gq

Rx

AF

P-CSCF

SDF (source IP, destination IP, source port, destination port, PID)

Figure 6-3 Policy Control architecture (UMTS R6)

The PDF is the network entity where the policy decisions are made. As the

IMS session is being setup, SIP signalling containing media requirements are exchanged between the terminal and the P-CSCF. At some time in the session establishment process, the PDF receives those requirements from the P-CSCF and makes decision based on network operator rules, such as:

• allowing or rejecting the media request,

• using new or existing PDP context for an incoming media request,

• checking the allocation of new resources against the maximum authorised.

The GGSN is in charge of enforcing policy decisions received from the PDF over Go interface. The policy rules are either ‘pushed’ by the PDF, e.g. as new media are added to an existing session, or ‘requested’ by the GGSN itself, when the establishment of a new PDP context is requested by the terminal. The policy enforcement process performed by the GGSN takes the form of a ‘gating’ process. Each packet received by the GGSN in the downlink or uplink direction is classified (meaning associated with one of the existing SDF) and checked against filters being defined by the PDF for the corresponding SDF.

The CRFs role is to provide operator defined charging rules applicable to each

SDF. The CRF selects the relevant charging rules based on information provided by the P-CSCF, such as Application Identifier, Type of Stream,

Application Data Rate, etc.

Charging rules are then provided by the CRF to the GGSN in the form of a packet filter similar to the 5-tuple gate definition above. Using the charging rules, the GGSN is able to count packets for each of the SDFs and generates corresponding charging records.

147



The two new CRF and PDF network nodes interact with the GGSN and the

AF using specific interfaces named in the Fig. 6-3. As for many IMS related interfaces, Gx, Go, Gq and Rx interfaces make use of already existing IETF protocols.

Go is based on Common Open Policy Service (COPS) protocol. The COPS protocol proposes generic policy control for packet networks and is based on a simple client/server model. In the OPS terminology, two entities are defined:

•

The Policy Decision Point (PDP), which is the policy server making the decision – in the UMTS case, this role is supported by the PDF.

•

The Policy Enforcement Point (PEP), which is the policy client, responsible for enforcing the policy decisions – in the UMTS case, this role is supported by the GGSN.

The other policy control and charging interfaces (Gq, Gx and Rx) are all based on an extended version of the IETF Diameter protocol, similarly to the

Cx interface already existing in IMS.

The major improvement brought by the R7 in terms of policy control and charging is a definition of a new converged architecture, so as to allow the optimisation of the interactions between these two functions. The R7 evolution involves a new network node PCRF (Policy and Charging Rules

Function) which is actually a concatenation of a PDF and CRF. As a result, evolved version of the R6 interfaces have been defined, as illustrated in

Fig. 6-4.

PCEF

GGSN

Gx

PCRF

Gi

Rx

AF

P-CSCF

SDF (source IP, destination IP, source port, destination port, PID)

Figure 6-4 Policy Control and Charging (UMTS R7)

This model is actually not specific to UMTS or UTRAN access networks, as it was defined for all types of IP access, including 3GPP access types and also

WLAN and fixed IP broadband access. In the generic policy and charging control 3GPP model, the Policy and Charging Enforcement Function (PCEF)

148


6 Policy Control and Charging is the generic name for the functional entity which supports SDF detection, policy enforcement and flow based charging. In the case of the WLAN 3GPP

IP Access, the PCEF is implemented by the Packet Data Gateway (PDG).

Similarly , the Application Function (AF) represents the network element which supports applications that require dynamic policy and/or charging control. In the IMS model the AF is implemented by the P-CSCF.

The new R7 Rx interface combines both the former Rx and Gq. Since both were based earlier on IETF Diameter protocol, the P-CSCF can provide service dynamic information to the PCRF using a single procedure.

The new R7 Gx interface supports Gx and Go capabilities, so that policy decision and charging rules are provided from the PCRF to the GGSN using a single message. As R6 Gx and Go are not based on the same protocols (Gx is based on Diameter whereas Go relies on COPS), the choice was made to use

Gx (Diameter) as a basis and to enhance it with all necessary features to allow service based local policy.

Fig. 6-5 shows additionally two other interfaces: Gy and Gz.

OFCS OCS

Gz Gy

Gx

PCEF

GGSN

PCRF

Gi

Figure 6-5 Gy and Gz interfaces

Rx

AF

P-CSCF

The Gy interface resides between the Online Charging System (OCS) and the

PCEF. It allows online credit control for service data flow based charging.

The functionalities required across the Gy reference point use existing functionalities and mechanisms, based on IETF Diameter Credit-Control

Application (RFC 4006).

The Gz interface resides between the PCEF and the Offline Charging System

(OFCS). It enables transport of service data flow based offline charging information. The Gz interface is based on Ga interface specifications.


149


The model for policy control and charging in EPS networks is aligned with the UMTS R7:

• the new S7 interface introduced in EPC is based on Gx interface,

(described earlier),

• the P-GW plays the role of the PCEF, as an equivalent of the GGSN for the policy and charging control functions.

OFCS OCS

Gz Gy

PCRF

Gx Rx+

PCEF

P-GW SGi

AF

P-CSCF

Figure 6-6 EPS Policy Control and Charging architecture

From the network operator point of view charging is one of the most critical features. Network subscriber charging is not only the major source of revenue, but also an area in which an operator can innovate and differentiate from its competitors by creating cost attractive services and solutions while not jeopardising the whole network profitability.

In legacy 2G or 3G CS based networks, charging was quite an easy task. Any granted user service request involved the allocation of the fixed amount of resource for a given time. Because CS technology means guaranteed bandwidth and delay, the charging rules are generally simply based on the allocated resource size and use time.

When using packet applications and packet transmission, the picture is a bit different. The end-user may be inactive for long periods of time, e.g. during silent phase of a PoC session or during the time needed to read a Web page freshly downloaded, and during those inactivity phases, the resources may be used for another purpose, which is one of the main benefits of the PS networks. Therefore, it may be seen as quite unfair to only charge end-user for connection time or service duration.

150



The standard does not specify the charging schemes, leaving to the operator the choice to charge the end user based on any of the following:

• data volume,

• session or connection time,

• service type (Web, e-mail, MMS, etc.),

• allocated QoS.

For that purpose, the 3GPP standard proposes all the necessary features to allow a flexible charging scheme to be implemented by operators. The charging process is based on the collection of various events and information which are stored in a formatted record called the Charging Data Record

(CDR).

Figure 6-7 EPS charging architecture

Fig. 6-7 presents the network element involved in the charging process and their interaction with 2G, 3G and IMS network nodes. The role of the

Charging Data Function (CDF) is to collect charging information from the different nodes through the Rf interface and built a corresponding CDR. The type of the nodes being linked to the CDF is not limited. It includes IMS nodes (such as the CSCF servers), Application Servers (such as PoC server) and EPC nodes (such as S-GW and P-GW).

The Rf interface is based on the IETF Diameter protocol, also used in many

IMS interfaces. The Rf declination of Diameter makes use of extensions specific to the charging process. The Charging Gateway Function (CGF) is a gateway between the CN nodes and the Billing Domain (BD). Its main task is

CDR collection through the Ga interface, CDR storage, CDR management

(like CDR opening, closing, deleting) and secure transfer to the BD. The default CDR transfer method over the Bx interface proposed by the 3GPP standard is FTP. The Ga interface is based on a simple UDP/IP tunnelling protocol whose only purpose is to transfer the CDRs.

151



For a given session, charging information is issued by different network nodes. This information is used by the CDF or CGF to built a complete CDR, putting together the various pieces from the network elements. The redundant information (such as data traffic volumes or session start and stop timestamp) is used to check the consistency between the views reported by the network elements.

152


7 Traffic Cases

Chapter 7

Traffic Cases

EMM and ECM and RRC states.................................................................... 155

Attach procedure ............................................................................................ 159

Tracking Area Update.................................................................................... 163

UE triggered Service Request ........................................................................ 166

Network Triggered Service Req. ................................................................... 167

S1 release procedure ...................................................................................... 168

Dedicated bearer activation............................................................................ 170

UE req. bearer resource alloc......................................................................... 171

Handover........................................................................................................ 171

Handover from E-UTRAN to 3G .................................................................. 177

Idle state Signalling Reduction ...................................................................... 179


153



154


7 Traffic Cases

EMM and ECM and RRC states

The EPS Mobility Management (EMM) states describe the Mobility

Management states that result from the mobility management procedures e.g.

Attach and Tracking Area Update procedures.

Detach,

Attach reject,

TAU reject, non-3GPP handover, all bearers deactivated

EMM-DEREGISTERED EMM-REGISTERED

Attach accept,

TAU accept

Figure 7-1 EPS Mobility Management (EMM) states

In the EMM-DEREGISTERED state, the EMM context in MME holds no valid location or routeing information for the UE. The UE is not reachable by a MME, as the UE location is not known.

The UE enters the EMM-REGISTERED state by a successful registration procedure which is either an Attach procedure or a Tracking Area Update procedure. In the EMM-REGISTERED state, the UE can receive services that require registration in the EPS.

The UE location is known in the MME to at least an accuracy of the TA list allocated to that UE.

In the EMM-REGISTERED state, the UE shall always have at least one

active PDN connection and setup the EPS security context.

The MME may perform an implicit detach any time after the UE reachable timer expires.

155



The EPS Connection Management (ECM) states describe the signalling connectivity between the UE and the EPC.

UE:

ECM-IDLE

RRC connection released

RRC connection established

ECM-CONNECTED

MME:

S1 connection released

ECM-IDLE ECM-CONNECTED

S1 connection established

Figure 7-2 EPS Connection Management (ECM) states

A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state, a UE performs cell (re)selection and

PLMN selection.

There exists no UE context in E-UTRAN for the UE in the ECM-IDLE state.

There is no S1_MME and no S1_U connection for the UE in the ECM-IDLE state.

In the EMM-REGISTERED and ECM-IDLE state, the UE shall:

• perform a TA update if the current TA is not in the list of TAs that the

UE has received from the network in order to maintain the registration and enable the MME to page the UE,

• perform the periodic TA updating procedure to notify the EPC that the

UE is available,

• answer to paging from the MME by performing a Service Request procedure,

• perform the Service Request procedure in order to establish the radio bearers when uplink user data is to be sent.

156


7 Traffic Cases

The UE and the MME shall enter the ECM-CONNECTED state when the signalling connection is established between the UE and the MME. Initial

NAS messages that initiate a transition from ECM-IDLE to

ECM-CONNECTED state are Attach Request, Tracking Area Update

Request, Service Request or Detach Request.

When the UE is in ECM-IDLE state, the UE and the network may be unsynchronised, i.e. the UE and the network may have different sets of established EPS bearers. When the UE and the MME enter the

ECM-CONNECTED state, the set of EPS Bearers is synchronised between the UE and network.

The UE location is known in the MME with an accuracy of a serving eNB ID.

The mobility of UE is handled by the handover procedure.

The UE performs the TA update procedure when the TAI in the EMM system information is not in the list of TA's that the UE registered with the network.

For a UE in the ECM-CONNECTED state, there exists a signalling connection between the UE and the MME. The signalling connection is made up of two parts: an RRC connection and an S1_MME connection.

The S1 release procedure changes the state at both UE and MME from

ECM-CONNECTED to ECM-IDLE.

After a signalling procedure, the MME may decide to release the signalling connection to the UE, after which the state at both the UE and the MME is changed to ECM-IDLE.

When a UE changes to ECM-CONNECTED state and if a radio bearer cannot be established, the corresponding EPS bearer is deactivated.

RR C states

A UE is in RRC_CONNECTED when an RRC connection has been established. If this is not the case, i.e. no RRC connection is established, the

UE is in RRC_IDLE state. The RRC states can further be characterised as follows:

•

A UE specific DRX may be configured by upper layers.

•

UE controlled mobility;

157



•

The UE: o Monitors a Paging channel to detect incoming calls; o Performs neighbouring cell measurements and cell

(re)selection; o Acquires system information.

•

Transfer of unicast data to/from UE;

•

At lower layers, the UE may be configured with a UE specific DRX/

DTX;

•

Network controlled mobility;

•

The UE: o Monitors control channels associated with the shared data channel to determine if data is scheduled for it; o Provides channel quality and feedback information; o Performs neighbouring cell measurements and measurement reporting; o Acquires system information.

The following figure not only provides an overview of the RRC states in

E-UTRA, but also illustrates the mobility support between E-UTRAN,

UTRAN and GERAN.

GSM_Connected

CELL_DCH Handover

E-UTRA

RRC_CONNECTED

Handover

GPRS Packet transfer mode

CELL_FACH

CELL_PCH

URA_PCH

Reselection

CCO with

NACC

CCO,

Reselection

Connection establishment/release



UTRA_Idle

Reselection Reselection

E-UTRA

RRC_IDLE

CCO, Reselection

Figure 7-3 Radio Resource Control (RRC) states

GSM_Idle/GPRS

Packet_Idle

158


7 Traffic Cases

A UE needs to register with the network to receive services that require registration. This registration is described as Network Attachment. The always-on IP connectivity for UE of the EPS is enabled by establishing a default EPS bearer during Network Attachment. The Attach procedure may trigger one or multiple Dedicated Bearer Establishment procedures to establish dedicated EPS bearer or bearers for that UE.

During the Initial Attach procedure the IMEI may be obtained from the UE.

The MME operator may check the IMEI with an EIR. At least in roaming situations, the MME passes the IMEI to the HSS, and, if a P-GW outside of the VPLMN, MME passes the IMEI also to the P-GW. new MME old MME/SGSN HSS

1. Attach Request

2. Attach Request

3. Identification

4. Authentication/Security

5. Identity Request/Response 5. ME Identity Check

6. Update Location

7. Cancel Loc.

EIR

8. Insert Subscriber Data

9. Update Location Ack.

10. Create Default Bearer Request

S-GW

16. RRC Con.

Reconfiguration

(Attach Accept)

15. Attach Accept

14. Create Default Bearer Rsp.

P-GW PCRF

11. Create Default Bearer Req.

13. Create Default Bearer Rsp.

First Downlink Data

12. PCRF

Interaction

17. RRC Con. Rec.

Complete

(Attach Complete)

18. Attach Cmp.

First Uplink Data

First Downlink Data

19. Update Bearer Request

20. Update Bearer Response

21. Update Location Request

22. Update Location Response

Figure 7-4 Attach procedure

1. The UE initiates the Attach procedure by the transmission of an Attach

Request message containing:

•

(old GUTI or IMSI if no GUTI is available),

• last visited TAI (if available),

•

UE network capabilities (e.g. NAS and AS security algorithms),

•

Protocol Configuration Options (used to transparently transfer some important parameters between the UE and the P-GW, e.g.: IP address allocation method, request for DNS, IP GW, P-CSCF addresses),

159



• attach type (may indicate ‘handover’ when the UE is coming from non-3GPP access, where it has an opened connection session),

• information about valid security parameters,

• selected network (PLMN that is selected for network sharing purposes).

2. The eNB derives the MME from the GUTI and from the indicated selected network. If that MME is not associated with the eNB, the eNB selects a new

MME. The eNB forwards the Attach Request message to the new MME contained in a S1-MME control message (Initial UE message) together with the selected network and an indication of the E-UTRAN area identity, a globally unique E-UTRAN ID of the cell from where it received the message to the new MME.

3. If the UE identifies itself with GUTI and the MME has changed since detach, the new MME sends an Identification Request (containing old

GUTI, complete Attach Request message) to the old MME to request the

IMSI. If the S-TMSI and old TAI identifies an SGSN, the message shall be sent to the old SGSN. The old MME/SGSN responds with Identification

Response (IMSI, Authentication Vectors and NAS security context).

4. If no UE context for the UE exists anywhere in the network and UE is either not using integrity protection or if the check of integrity failed, then authentication and NAS security setup are mandatory. Otherwise it is optional.

5. The IMEI is retrieved from the UE. The procedure is optional in case, when attach type indicates handover. The MME may send the IMEI Check

Request (IMEI, IMSI) to the EIR. The EIR responds with IMEI Check Ack

(Result). Dependent upon the Result, the MME decides whether to continue with this Attach procedure or to reject the UE.

6. If the MME has changed since the last detach, or if there is no valid subscription context for the UE in the MME, or if the IMEI has changed, the

MME sends an Update Location (MME Identity, IMSI, IMEI) to the HSS.

7. The HSS sends Cancel Location (IMSI, cancellation type = update procedure) to the old MME. The old MME acknowledges with Cancel

Location Ack (IMSI) and removes the MM and bearer contexts.

8. The HSS sends Insert Subscriber Data (IMSI, Subscription Data) message to the new MME. The Subscription Data contains the list of all

APNs that the UE is permitted to access, an indication about which of those

APNs is the Default APN, and the ‘EPS subscribed QoS profile’ for each permitted APN. Then the new MME constructs a context for the UE and returns an Insert Subscriber Data Ack. message to the HSS. The Default

APN is used for the remainder of this procedure.

160


7 Traffic Cases

9. The HSS acknowledges the Update Location message by sending an

Update Location Ack. to the new MME.

10. If the PDN subscription context contains no P-GW address the new MME selects a P-GW. The new MME also selects a S-GW and allocates an EPS

Bearer Identity (EBI) for the Default Bearer associated with the UE. Then it sends a Create Default Bearer Request (IMSI, MSISDN, MME Context ID,

P-GW address, APN, RAT type, Default Bearer QoS, PDN Address

Allocation, EPS Bearer Identity (EBI), Protocol Configuration Options

(PCO), IMEI, ECGI, Serving Network) message to the selected S-GW. The

RAT type is provided in this message for the later PCC decision.

11. The S-GW creates a new entry in its EPS Bearer table and sends a Create

Default Bearer Request (IMSI, MSISDN, APN, Serving GW Address for the user plane, S-GW TEID of the user plane, S-GW TEID of the control plane, RAT type, Default Bearer QoS, PDN Address Allocation, EBI, PCO,

ME Identity, ECGI, Serving Network) message to the P-GW indicated by the

P-GW address received in the previous step. After this step, the S-GW buffers any DL packets it may receive from the P-GW until receives the message in step 20 below.

12. If dynamic PCC is deployed, the P-GW interacts with the PCRF to get the default PCC rules for the UE. This may lead to the establishment of a number of dedicated bearers in association with the establishment of the default bearer. The IMSI, UE IP address, ECGI, Serving Network, RAT type, Default

Bearer QoS are provided to the PCRF by the P-GW if received by the previous message. The ECGI is used for location based charging.

13. The P-GW returns a Create Default Bearer Response (P-GW Address for the user plane, P-GW TEID of the user plane, P-GW TEID of the control plane, PDN Address Information, EBI, UL TFT) message to the S-GW. PDN

Address Information (IP address) is included if the P-GW allocated a PDN address Based on PDN Address Allocation received in the Create Default

Bearer Request.

14. The S-GW returns a Create Default Bearer Response (PDN Address

Information, S-GW address for User Plane, S-GW TEID for User Plane,

S-GW Context ID, EBI, P-GW addresses and TEIDs at the P-GW(s) for UL traffic, UL TFT) message to the new MME. PDN Address Information is included if it was provided by the P-GW.

15. The new MME sends an Attach Accept (APN, GUTI, PDN Address

Information, TAI List, EBI, Session Management Configuration) message to the eNB. GUTI is included if the new MME allocates a new GUTI. This message is contained in an S1_MME control message Initial Context Setup

Request. This S1 control message also includes the AS security context information for the UE, the Handover Restriction List, the bearer level QoS

161


LTE/EPS Technology parameters, EBI and the AMBR associated with the PDN Address

Information, and QoS information needed to set up the radio bearer, as well as the TEID at the S-GW used for user plane and the address of the S-GW for user plane. The PDN address information, if assigned by the P-GW, is included in this message. If the UE has UTRAN or GERAN capabilities, the

MME uses the EPS bearer QoS information to derive the corresponding PDP context parameters QoS Negotiated (R99 QoS profile), Radio Priority and

Packet Flow Id and includes them in the Session Management Configuration.

The UL TFT shall be included in the Session Management Configuration.

16. The eNB sends the RRC Connection Reconfiguration message including the EBI to the UE, and the Attach Accept message will be sent along to the UE. The UE stores the QoS Negotiated, Radio Priority, Packet

Flow Id, which it received in the Session Management Configuration, for use when accessing via GERAN or UTRAN. The APN is provided to the UE to notify it of the APN for which the activated default bearer is associated. The

UE uses the UL TFT to determine the mapping of UL packets to the radio bearer.

17. The UE sends the RRC Connection Reconfiguration Complete message to the eNB. This message includes the Attach Complete message. With the

Attach Complete message the UE starts using the NAS security algorithm indicated by the MME.

18. The eNB forwards the Attach Complete message to the new MME in an

S1 control message. This S1 control message includes the TEID of the eNB and the address of the eNB used for DL traffic on the S1_U reference point.

After the Attach Accept message and once the UE has obtained a PDN

Address Information, the UE can then send UL packets towards the eNB which will then be tunnelled to the S-GW and P-GW.

19. The new MME sends an Update Bearer Request (eNB address, eNB

TEID) message to the S-GW.

20. The S-GW acknowledges by sending Update Bearer Response (EBI) message to the new MME. The S-GW can then send its buffered DL packets.

21. After the MME receives Update Bearer Response (EBI) message, if an

EPS bearer was established and the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses, and if the MME selected a P-GW that is different from the P-GW address which was indicated by the

HSS in the PDN subscription context, the MME shall send an Update

Location Request including the APN and P-GW address to the HSS for mobility with non-3GPP accesses.

22. The HSS stores the APN and P-GW address pair and sends an Update

Location Response to the MME.

162


7 Traffic Cases

TAU procedure with MME and S new MME old MME/SGSN new S-GW old S-GW

1. UE changes to a new TA

2. TAU Request

3. TAU Request

4. Context Req.

5. Context Res.

6. Authentication

7. Context Ack.

8. Create Bearer Request

9. Update Bearer Request

10. Update Bearer Response

11. Create Bearer Response

12. Update Location

13. Cancel Location

14. Cancel Location Ack.

15. Insert Subscriber Data

15. Insert Subscriber Data Ack.

16. Update Location Ack.

17. Delete Bearer Request

18. Delete Bearer Response

19. TAU Accept

19. TAU Complete

P-GW HSS

Figure 7-5 TAU procedure with MME and S-GW change

1. The UE detects a change to a new TA by discovering that its current TAI is not in the list of TAIs that the UE is registered with the network.

2. The UE initiates the procedure by sending a TAU Request containing:

• old GUTI,

• last visited TAI- included in order to help the MME produce a good list of TAIs for any subsequent TAU Accept message,

• active flag - requests to activate the radio and S1 bearers for all the active EPS Bearers by the TAU procedure when the UE is in

ECM-IDLE state,

•

EPS bearer status - indicates each EPS bearer that is active in the UE,

•

Selected Network,

•

Security parameters.

3. The eNB derives the MME from the GUTI and from the indicated Selected

Network. If that MME is not associated with that eNB, the eNB selects a new

MME.

163



The eNB forwards the TAU Request message together with an indication of the E-UTRAN Area Identity, a globally unique E-UTRAN ID, of the cell from where it received the message and with the Selected Network to the new

MME.

4. The new MME sends a Context Request (old GUTI, complete TAU

Request message) message to the old MME to retrieve user information. The new MME derives the old MME from the GUTI.

5. The old MME responds with a Context Response message containing:

•

IMSI,

•

MSISDN,

•

Authentication Quintets,

• bearer contexts (e.g. P-GW Address and TEID(s) for UL traffic),

•

S-GW signalling Address and TEID(s).

If the UE is not known in the old MME or if the integrity check for the TAU

Request message fails, the old MME responds with an appropriate error cause. The MSISDN is included if the old MME has it stored for that UE.

6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory.

7. The new MME determines whether to relocate the S-GW or not. The S-GW is relocated when the old S-GW cannot continue to serve the UE. The new

MME may also decide to relocate the S-GW in case a new S-GW is expected to serve the UE longer and/or with a more optimal UE to P-GW path, or in case a new S-GW can be co-located with the P-GW.

The new MME sends a Context Acknowledge (S-GW change indication) message to the old MME. S-GW change indication indicates a new S-GW has been selected. The old MME marks in its context that the information in the

GWs and the HSS are invalid. This ensures that the old MME updates the

GWs and the HSS if the UE initiates a TAU procedure back to the old MME before completing the ongoing TAU procedure.

8. The MME constructs an MM context for the UE. The MME verifies the

EPS bearer status received from the UE with the bearer contexts received from the old MME and releases any network resources related to EPS bearers that are not active in the UE. If the new MME selected a new S-GW it sends a

Create Bearer Request (IMSI, bearer contexts, MME Context ID) message to the selected new S-GW. The P-GW address is indicated in the bearer

Contexts.

9. The new S-GW sends the message Update Bearer Request (S-GW Address,

S-GW TEID) to the P-GW concerned.

164


7 Traffic Cases

10. The P-GW updates its bearer contexts and returns an Update Bearer

Response (MSISDN, P-GW address and TEID(s)) message.

11. The S-GW updates its bearer context. This allows the S-GW to route bearer PDUs to the P-GW when received from eNB.

The S-GW returns a Create Bearer Response (MME Context ID, S-GW address and TEID for user plane, S-GW Context ID) message to the new

MME.

12. The new MME sends an Update Location (MME Id, IMSI) to the HSS.

13. The HSS sends the message Cancel Location (IMSI, Cancellation Type) to the old MME with Cancellation Type set to Update Procedure.

14. The old MME removes the MM context and acknowledges with the message Cancel Location Ack (IMSI).

15. The HSS sends Insert Subscriber Data (IMSI, Subscription Data) to the new MME.

The new MME constructs an MM context for the UE and returns an Insert

Subscriber Data Ack (IMSI) message to the HSS.

16. The HSS acknowledges the Update Location message by sending an

Update Location Ack to the new MME.

17. When the old MME removes the MM context and it receives the S-GW change indication in the Context Acknowledge message, the old MME deletes the EPS bearer resources by sending Delete Bearer Request (Cause, TEID) messages to the S-GW. Cause indicates to the old S-GW that the old S-GW shall not initiate a delete procedure towards the P-GW. If the S-GW has not changed, the old MME does not delete the bearers. If the MME has not changed, step 11 triggers the release of EPS bearer resources when a new

S-GW is allocated.

18. The S-GW acknowledges with Delete Bearer Response (TEID) messages.

19. The new MME validates the UE’s presence in the (new) TA, after it has received valid and updated subscription data. If all checks are successful then the MME sends a TAU Accept (new GUTI, TAI list, EPS bearer status, security parameters) message to the UE. If the ‘active flag’ is set in the TAU

Request message the user plane setup procedure can be activated in conjunction with the TAU Accept message (same message sequence as for

UE triggered Service Request procedure describer later in this chapter). The

UE removes any internal resources related to bearers that are not marked active in the received EPS bearer status.

20. If new GUTI or new security parameters were included in the TAU

Accept, the UE acknowledges the received message by returning a TAU

Complete message to the MME.

165



MME S-GW P-GW PCRF

1. NAS Service Req.

2. NAS Service Req.

3. Authentication

4. S1-AP: Initial

Context Setup Req.

5. Radio Bearer

Establishment

HSS

6. Uplink data

7. S1-AP Initial

Context Setup Cmp.

8. Update Bearer Req.

9. Update Bearer Req.

12. Update Bearer Rsp.

11. Update Bearer Rsp.

10. PCEF Initiated

IP-CAN Session

Modification

Figure 7-6 UE triggered Service Request

1. The UE sends NAS message Service Request (S-TMSI) towards the MME encapsulated in an RRC message (e.g. Initial UE message) to the eNB.

2. The eNB forwards NAS message to MME. NAS message is encapsulated in an S1-AP: Initial UE Message (NAS message, CGI of the serving cell).

3. NAS authentication procedures may be performed.

4. The MME sends S1-AP Initial Context Setup Request (S-GW address,

S1-TEID(s) UL, Bearer QoS(s), Security Context, MME Signalling

Connection Id) message to the eNB. This step activates the radio and S1 bearers for all the active EPS Bearers. The eNB stores the Security Context,

MME Signalling Connection Id, Bearer QoS profile(s) and S1-TEID(s) in the

UE RAN context.

5. The eNB performs the radio bearer establishment procedure. The user plane security is established at this step, which implicitly confirms the Service

Request. When user plane security has been established the EPS bearer state is synchronised between the UE and the network, i.e. the UE should remove the EPS bearers for which no radio bearers are setup.

6. The UL data from the UE can now be forwarded by eNB to the S-GW. The eNB sends the UL data to the S-GW address and TEID provided in the step 4.

7. The eNodeB sends an S1-AP message Initial Context Setup Complete

(eNodeB address, List of accepted EPS bearers, List of rejected EPS bearers,

S1 TEID(s) DL) to the MME.

8. The MME sends an Update Bearer Request message (eNB address, S1

TEID(s) for the accepted EPS bearers, RAT Type) to the S-GW. The S-GW is now able to transmit downlink data towards the UE.

166


7 Traffic Cases

9. If the RAT Type has changed compared to the last reported RAT Type, the

S-GW sends the Update Bearer Request message (RAT Type) to the P-GW.

10. If dynamic PCC is deployed, the P-GW interacts with the PCRF to get the

PCC rule(s) according to the RAT Type. If dynamic PCC is not deployed, the

P-GW may apply local QoS policy.

11. The P-GW sends the Update Bearer Response to the S-GW.

12. The S-GW sends an Update Bearer Response to the MME. eNodeB RNC/BSC MME SGSN

Downlink Data Notification

Downlink Data Notification Ack.



S-GW P-GW

Downlink data

Paging

Paging

Paging

Paging

UE Paging Response/UE triggered Service Request procedure

Downlink data E-UTRAN

Downlink data GERAN or UTRAN non Direct Tunnel

Downlink data UTRAN Direct Tunnel

Figure 7-7 Network Triggered Service Request

When the S-GW receives a DL data packet for a UE known as not user plane connected (i.e. the S-GW context data indicates no DL user plane

TEID), it buffers the DL data packet. and identifies which MME or SGSN is serving that UE.

The S-GW sends a Downlink Data Notification message to the MME and

SGSN nodes for which it has control plane connectivity for the given UE 1 .

The MME and SGSN respond to the S-GW with a Downlink Data

Notification Ack. message.

If the UE is registered in the MME, the MME sends a Paging message

(NAS Paging ID, TAI(s), Paging DRX ID) to each eNB belonging to the

Tracking Area(s) in which the UE is registered.

1 In case the network is not supporting ISR or ISR is not activated for that UE, the S-GW has control plane connectivity for the given UE with only one node i.e. SGSN or MME exclusively.

167



If the UE is registered in the SGSN, the SGSN sends paging messages to

RNC/BSS.

If eNBs receive paging messages from the MME, the UE is paged by the eNBs.

If RNC/BSS nodes receive paging messages from the SGSN the UE is paged by the RNSC/BSS.

Upon reception of paging indication in E-UTRAN access, the UE initiates the UE triggered Service Request procedure.

Upon reception of paging indication in UTRAN or GERAN access, the MS responds in respective access and the SGSN notifies the S-GW.

The MME and/or SGSN supervises the paging procedure with a timer. If the

MME and/or SGSN receives no response from the UE to the Paging Request message, it may repeat the paging. The repetition strategy is operator dependent.

The S-GW transmits DL data towards the UE only via the RAT where paging response was received.

This procedure is used to release the logical S1-AP signalling connection

(over S1-MME) and all S1 bearers (in S1-U) for a UE. The procedure will move the UE from ECM-CONNECTED to ECM-IDLE in both the UE and

MME, and all UE related context information is deleted in the eNB.

The initiation of S1 Release procedure is either:

• eNB-initiated with cause e.g. user inactivity, O&M intervention, unspecified failure, user inactivity, UE generated signalling connection release, repeated RRC signalling integrity check failure, etc.,

•

MME-initiated with cause e.g. authentication failure, detach, etc.

Both eNB-initiated and MME-initiated S1 release procedures are shown in

Fig. 7-8.

168


7 Traffic Cases

RRC Connection Release

S1-AP: S1 UE Context

Release Request

MME S-GW

Update Bearer Request

Update Bearer Response S1-AP: S1 UE Context

Release Command

S1-AP: S1 UE Context

Release Complete

Figure 7-8 S1 release procedure

If the eNB detects a need to release the UE's signalling connection and all radio bearers for the UE, the eNB sends an S1 UE Context Release Request

(cause) message to the MME.

Step is only performed when the eNB-initiated S1 release procedure is considered. Step is not performed and the procedure starts with Step when the MME-initiated S1 release procedure is considered.

The MME sends an Update Bearer Request message to the S-GW that requests the release of all S1-U bearers for the UE. This message is triggered either by an S1 Release Request message from the eNB, or by another MME event.

The S-GW releases all eNB related information (address and TEIDs) for the UE and responds with an Update Bearer Response message to the MME.

Other elements of the UE's S-GW context are not affected. The S-GW retains the S1-U configuration that the S-GW allocated for the UE’s bearers. The

S-GW starts buffering DL packets received for the UE and initiating the

‘Network Triggered Service Request’ procedure, described earlier, if DL packets arrive for the UE.

The MME releases S1 by sending the S1 UE Context Release Command

(cause) message to the eNB.

If the RRC connection is not already released, the eNB sends a RRC

Connection Release message to the UE. Once the message is acknowledged by the UE, the eNB deletes the UE’s context.

The eNB confirms the S1 Release by returning an S1 UE Context Release

Complete message to the MME. With this, the signalling connection between the MME and the eNB for that UE is released.

The MME deletes any eNB related information (address and TEIDs) from the

UE’s MME context, but, retains the rest of the UE's MME context including the S-GW's S1-U configuration information (address and TEIDs). All EPS bearers established for the UE are preserved in the MME and in the S-GW.

169



The dedicated bearer activation procedure is depicted in Fig. 7-9.

RRC Connection

Reconfiguration

RRC Connection

Reconfiguration Cmp.

Bearer Setup

Request

MME

Create Dedicated

Bearer Request

S-GW


Bearer Request

P-GW PCRF

PCRF Initiated

IP-CAN Session

Modification, begin

Bearer Setup

Response


Bearer Response


Bearer Response

PCRF Initiated

IP-CAN Session

Modification, end

Figure 7-9 Dedicated Bearer Activation procedure

If dynamic PCC is deployed, the PCRF sends a PCC decision provision

(QoS policy) message to the P-GW. If dynamic PCC is not deployed, the

P-GW may apply local QoS policy.

The P-GW uses this QoS policy to assign the EPS Bearer QoS. The P-GW sends a Create Dedicated Bearer Request message (IMSI, EPS Bearer QoS,

S5/S8-TEID) to the S-GW.

The S-GW sends the Create Dedicated Bearer Request (IMSI, EPS Bearer

QoS, S1-TEID) message to the MME. If the UE is in ECM-IDLE state the

MME will trigger the Network Triggered Service Request.

The MME then signals the Bearer Setup Request (EPS Bearer QoS,

S1-TEID) message to the eNB.

The eNB maps the EPS Bearer QoS to the Radio Bearer QoS. It then signals a RRC Connection Reconfiguration message to the UE.

The UE then acknowledges the radio bearer activation to the eNB with a

RRC Connection Reconfiguration Complete message.

The eNB acknowledges the bearer activation to the MME with a Bearer

Setup Response (EBI, S1-TEID) message.

The MME acknowledges the bearer activation to the S-GW by sending a

Create Dedicated Bearer Response (EBI, S1-TEID) message.

The S-GW acknowledges the bearer activation to the P-GW by sending a

Create Dedicated Bearer Response (EBI, S5/S8-TEID) message.

If the dedicated bearer activation procedure was triggered by a PCC

Decision Provision message from the PCRF, the P-GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not.

170


7 Traffic Cases

UE req . b earer resource al loc.

The UE requested bearer resource allocation procedure for an E-UTRAN is depicted in Fig. 7-10. The procedure allows the UE to request for an allocation of bearer resources to one new Service Data Flow (SDF) with a specific QoS demand. If accepted by the network, the request invokes the

Dedicated Bearer Activation Procedure. The procedure is used by the UE when the UE already has an IP-CAN session with the PDN.

Request Bearer Resource Allocation

MME S-GW

Request Bearer

Resource Allocation

P-GW PCRF

Request Bearer

Resource Allocation

PCEF Initiated IP-CAN

Session Modification

Dedicated bearer activation procedure

Figure 7-10 UE requested bearer resource activation

This section aims at presenting how EPS networks support mobility cases for

ECM-CONNECTED terminals. As opposed to ECM-IDLE mode,

ECM-CONNECTED terminal mobility, called handover, is completely under control of the network. The decision to move as well as the choice for the target cell and technology (when applicable) is made by the current serving eNB, based on measurements performed by the eNB itself and the terminal. In addition, ECM-CONNECTED mode mobility requires some specific features to be supported and implemented by the network so as to limit interaction on user experience and preserve the ongoing service.

In all the cases, the resources and context in the target nodes (whatever the target technology is) are reserved before the actual handover is performed in order to minimise the interruption time is kept to a minimum.

Due to the broadband nature of the E-UTRAN radio interface, the amount of packets stored in radio equipment before scheduled transmission over the radio may not be negligible. For that reason, some mobility cases make use of packet forwarding mechanism between source and target nodes so as to limit packet loss during the overall handover.

171



Fig. 7-11 shows the general architecture of an intra E-UTRAN handover case.

In this example, the whole procedure benefits from the availability of the X2 interface between the source and target eNB, so that the involvement of the

MME and S-GW in the handover process itself is at a minimum. In addition, the X2 interface allows packet loss limitation thanks to buffered packet forwarding from source to target eNB.

SGi

P-GW

S5

MME S-GW

S1

X2

Figure 7-11 Intra E-UTRAN handover with X2 support (overview)

The only impact on EPC nodes relates to the update of the signalling and user plane connectivity. As the terminal is moving from one node to the other, the new eNB needs to built an S1 connection with the MME which is in charge of the user session, and also needs to built a new tunnel for user data transmission with S-GW. Once the handover is completed, the old resources and connections on the radio and S1 interface (represented using dotted lines) are released. In any case, the handover is completely transparent to the P-GW, which keeps tunnelling user data to and from the same S-GW.

Fig. 7-12 describes in more detail the different steps and signalling messages which are part of the handover procedure.

172


7 Traffic Cases source target

MME S-GW

HO decision

HO Request

Radio Resource allocation

HO Request Ack

(HO cmd)

HO Command data forwarding

HO Confirm

Path Switch Request

Release Resource


Path Switch Request

Ack

Update Bearer Response

Radio Resource release

P-GW

Figure 7-12 Intra E-UTRAN handover with X2 support (message flow)

The handover decision is made by the source eNB, based on measurement reported by the terminal and also possibly made by the eNB itself.

Once the decision is made, the source eNB sends a Handover Request message over the X2 interface to the target eNB, which allocates all needed resources to accept the incoming UE and associated bearers. The target eNB answers with Handover Request Ack. Message which encapsulates the

Handover Command content eventually sent to the terminal by the source eNB. On reception of the Handover Request Ack., the source eNB forwards all buffered DL data packets that have not been acknowledged by the terminal to the target eNB. Those packets will be stored by the target eNB until the terminal is able to receive them.

Once the terminal is synchronised with the target eNB, it sends a Handover

Confirm message, which triggers the transmission of the Path Switch procedure to the MME. Once the Handover Confirm is received, the target eNB can transmit over the radio the buffered packets for the DL. The role of the Path Switch Request message is to inform the MME about the successful completion of an intra E-UTRAN handover performed via the X2 interface and request a path switch of the user plane data towards the new eNB. On reception of this message, the MME is now aware that the terminal has successfully changed eNB and can therefore update the S-GW about the new data path (the Update Bearer Request/Response). The Release Resource is sent by the target eNB over X2 interface, which has the effect of releasing old resources allocated in the source eNB.


173


In some cases, it may happen that the X2 interface is not available between eNBs. This may result from network equipment failure, or simply from the fact that the operator is not willing to deploy X2 connectivity between eNB for cost reasons.

SGi

P-GW

S5

MME S-GW

S1

Figure 7-13 Intra E-UTRAN handover without X2 support (overview)

In such a case, the network architecture picture is the same as the previous case. However, the overall handover process is much more complex, as there is no direct communication between source and target eNB. As a consequence, the MME is no longer transparent to the handover process, as it acts as a signalling relay between the two eNBs. source target

MME S-GW P-GW

HO decision

HO Required

HO Request


HO Request Ack

(HO cmd)

HO Command

HO Command

HO Confirm

HO Notify

UE Context Release Command


UE Context Release Complete

User Plane Update Req.

User Plane Update Rsp.

Figure 7-14 Intra E-UTRAN handover without X2 support (message flow)

174


7 Traffic Cases

Instead of being sent directly to the target eNB, the request for handover is transmitted from the source eNB via the MME, using the Handover Required and Handover Request S1 messages. Similarly, once the resources have been allocated in the target eNB, the answer is sent back to the source eNB using

Handover Request Ack. And Handover Command S1 messages. This answer message contains information related to the target cell radio resource.

Finally, once the handover is completed, the resources in the source eNB are released under the MME control, once the MME receives the Handover

Notify message informing that the handover procedure is successful from the

E-UTRAN perspective. In parallel, the S-GW is updated about the new data path towards the new eNB.

The main difference from the ‘X2 support’ case is that usually no data forwarding is performed between the source and target eNBs 2 . As a consequence, all the data packets being buffered at the source eNB level will be lost. The impact on user perception will depend on the application and corresponding protocol stack being used.

For all non real-time applications (like Web browsing) which rely on secured end-to-end transport layers like TCP, such a handover may induce a delay in end-to-end information transmission, but no actual loss of data due to retransmission mechanism implemented at the TCP level.

However for real-time applications based on unsecured transport layers like

UDP (for example, streaming or voice), the handover will result in a loss of data frames, with a possible impact on user quality of experience.

In this handover case, the target eNB has no connectivity with the current

MME and S-GW. For that reason, the terminal mobility will also imply a relocation of EPC nodes. From the terminal and eNB perspective, this handover is not different from the previous ‘no X2 support’ case. The only real difference relies on the fact that the session needs also to be handed over from one MME to the other. In practice, it is performed by transferring the user communication context from the source MME to the target MME using the S10 interface. In addition, the P-GW needs also to be updated, so as to maintain user plane connectivity.

Depending on the network engineering choice, there might be other simpler case of mobility with EPC node relocation. As S-GW and MME are separate

2 Standard defines optional data forwarding between source and target eNB also in case of S1-based HO.

175


LTE/EPS Technology nodes, it may happen that a user mobility case implies a change of MME with no change of S-GW.

SGi

P-GW

S-GW S11 MME S10

S5

MME S11 S-GW

S1

X2

Figure 7-15 Intra E-UTRAN handover with EPC relocation (overview)

Similarly, the source and target eNBs may be connected to the same MME, but different S-GW. source

HO decision

HO Required

MME S-GW target

MME S-GW

Forward Relocation Request

HO Request


HO Request Ack.

(HO Cmd)

Forward Relocation Response (HO Cmd)

Create Bearer

Request

Create Bearer

Response

HO Command

HO Confirm

HO Notify

Forward Relocation Complete

Forward Relocation Complete Ack.

UE Context

Release Cmd.


UE Context

Release Cmp.

Delete Bearer

Request

Delete Bearer

Response



P-GW

Figure 7-16 Intra E-UTRAN handover with EPC relocation (message flow)

Although looking more complex than the previous example (no X2 support), this handover case uses the same principles. The main difference is in the fact that the source and target MME are different nodes, which requires the transfer of the user context (containing the user IMSI, user subscription information, authentication vectors as well as on-going allocated EPS bearers) between the two MMEs using the Forward Relocation Request/Response

176


7 Traffic Cases messages. In addition, a new user plane bearer is created between the P-GW

(which is the user plane anchor point for the session) and the new S-GW.

Once the handover is complete from the access network perspective, the new

MME informs the old one about the successful outcome using the Forward

Relocation Complete message, so that the old radio resources and bearer path can be released. In addition, the bearer path is updated using the Update

Bearer procedure, so that the P-GW can transmit the DL packet to the relevant new S-GW.

At the end, if the terminal determines that the new cell belongs to a TA it is not registered to, a TA update procedure is performed towards the new MME.

As a consequence, the HSS is updated accordingly.

Handover from E

EPS networks are to support seamless mobility to and from 2G and 3G packet systems. Fig. 7-17 describes an examples of such a mobility case, for a terminal moving from a E-UTRAN access towards a UTRAN target cell.

For simplicity, the target RNC and NBs nodes are represented as one box.

In the case of handover towards a 2G/GPRS system, the picture would actually be quite similar, as the SGSN node exists in both 2G and 3G packet core architecture.

MME

S1

SGi

P-GW

S5

S-GW

S3

S4

SGSN

Iu

RNC+NB

Figure 7-17 Handover from E-UTRAN to 3G (overview)

177



As represented in the figure above, the S-GW acts as a sort of user plane anchor point. The control plane for NAS signalling (for session setup and control) is moved over the S3 interface from the serving MME to the target

SGSN, which is the standard point of terminating this protocol in 2G and 3G packet architecture. Regarding the user plane, a new tunnel is built between the S-GW and the target SGSN over the S4 interface so as to ensure packet transmission continuity.

Since the S-GW still remains in the data path, the P-GW is not directly involved in the procedure, However, it is informed about the change in RAT, mainly for charging purposes.

Once the handover is completed, the old resources and connections on the radio as well as S1 user and signalling interfaces are released. source

MME SGSN RNC+NB

HO decision

HO Required

Forward Relocation

Request

Relocation Req.

HO Command

HO Command


Response


Relocation Rsp.

Handover to UTRAN Complete

UE Context

Release Cmd.


Complete


Complete Ack.


UE Context

Release Cmp.

Relocation Cmp.



S-GW P-GW

Upd. Bearer Req.

Upd. Bearer Rsp.

Figure 7-18 Handover from E-UTRAN to 3G (message flow)

When the handover decision is made, the session context (including session-related EPS bearers and associated QoS attributes) is moved from the source MME to the target SGSN using Forward Relocation procedure, as in the ‘Intra E-UTRAN with EPC nodes relocation’ handover case. This procedure is actually an extension of the existing Forward Relocation procedure which applies in the case of inter-SGSN mobility within 2G and 3G networks.

On this occasion, the MME translates the EPS QoS attributes into their 2G or

3G equivalent, in the form of PDP context attributes.

Once the terminal is synchronised on the target NB and the handover considered as completed from the access network point of view, a Forward

Relocation Complete is sent from the SGSN to the MME. The signal is used as an indication that resources in the old serving E-UTRAN and MME nodes are no longer useful and can be released. Simultaneously, the target SGSN updates the bearer path towards the S-GW using the Update Bearer procedure.

178


7 Traffic Cases

Idle state Signalling Reduction (ISR) aims at reducing the frequency of

Tracking Area Update (TAU) and Routing Area Update (RAU) procedures caused by UEs reselecting between E-UTRAN and GERAN/UTRAN which are operated together. Especially the update signalling between UE and network is reduced. But also network internal signalling is reduced.

UMTS described already RAs containing GERAN and UTRAN cells, which also reduces update signalling between UE and network. The combination of

GERAN and UTRAN into the same RAs implies however common scaling, dimensioning and configuration for GERAN and UTRAN (e.g. same RA coverage, same SGSN service area, no GERAN or UTRAN only access control, same physical node for GERAN and UTRAN). As an advantage it does not require special network interface functionality for the purpose of update signalling reduction.

ISR enables signalling reduction with separate SGSN and MME and also with independent Tracking Ares (TAs) and Routing Areas (RAs). Thereby the interdependency is drastically minimised compared with the

GERAN/UTRAN RAs. This comes however with ISR specific node and interface functionality. SGSN and MME may be implemented together, which reduces some interface functions but results also in some dependencies.

ISR support is mandatory for E-UTRAN UEs that support GERAN and/or

UTRAN and optional for the network. ISR requires special functionality in both the UE and the network (i.e. in the SGSN, MME, S-GW and HSS) to activate ISR for a UE. The network can decide for ISR activation individually for each UE. Gn/Gp SGSNs 3 do not support ISR functionality.

It is inherent functionality of the MM procedures to enable ISR activation only when the UE is able to register via E-UTRAN and via GERAN/UTRAN.

For example, when there is no E-UTRAN coverage there will be also no ISR activation. Once ISR is activated it remains active until one of the criteria for deactivation in the UE occurs, or until SGSN or MME indicate during an update procedure no more the activated ISR, i.e. the ISR status of the UE has to be refreshed with every update.

When ISR is activated this means the UE is registered with both MME and

SGSN. Both the SGSN and the MME have a control connection with the

S-GW. MME and SGSN are both registered at HSS. The UE stores MM parameters from SGSN (e.g. P-TMSI and RA) and from MME (e.g. GUTI

3 Gn/Gp SGSN is an SGSN connected to the MME via GTPv1 based, Gn/Gp like interface. In contrast, regular

SGSN is a SGSN connected to the MME via GTPv2 based, S3 interface, that supports all EPS specific procedures.

179


LTE/EPS Technology and TA(s)) and the UE stores session management (bearer) contexts that are common for E-UTRAN and GERAN/UTRAN accesses. In idle state the UE can reselect between E-UTRAN and GERAN/UTRAN (within the registered

RA and TAs) without any need to perform TAU or RAU procedures with the network. SGSN and MME store each other's address when ISR is activated.

When ISR is activated and DL data arrive, the S-GW initiates paging processes on both SGSN and MME. In response to paging or for UL data transfer the UE performs normal Service Request procedures on the currently camped-on RAT without any preceding update signalling (there are however existing scenarios that may require to perform a RAU procedure prior to the

Service Request when GERAN/UTRAN RAs are used together).

The UE and the network run independent periodic update timers for

GERAN/UTRAN and for E-UTRAN. When the MME or SGSN do not receive periodic updates MME and SGSN may decide independently for implicit detach, which removes session management (bearer) contexts from the CN node performing the implicit detach and it removes also the related control connection from the S-GW. Implicit detach by one CN node (either

SGSN or MME) deactivates ISR in the network. It is deactivated in the UE when the UE cannot perform periodic updates in time. When ISR is activated and a periodic updating timer expires the UE starts a Deactivate ISR timer.

When this timer expires and the UE was not able to perform the required update procedure the UE deactivates ISR.

MM

Context

TA list RA

RNC/BSC SGSN

SGSN & MME registered

S3

HSS eNodeB MME no need to update location due to UTRAN/E-UTRAN reselection

EMM

Context

Figure 7-19 Idle state Signalling Reduction

The UE may have valid MM parameters both from MME and from SGSN.

The Temporary Identity used in Next update (TIN) is a parameter of the UE's

MM context, which identifies the UE identity to be indicated in the next RAU

180


7 Traffic Cases

Request or TAU Request message. The TIN also identifies the status of ISR activation in the UE.

The TIN can take one of the three values, ‘P-TMSI’, ‘GUTI’ or ‘RAT-related

TMSI’. The UE sets the TIN when receiving an Attach Accept, a TAU Accept or RAU Accept message.

P TMSI

Figure 7-20 Setting of TIN

‘ISR Activated’ indicated by the RAU/TAU Accept message but the UE not setting the TIN to "RAT-related TMSI" is a special situation. Here the UE has deactivated ISR due to special situation handling (e.g. modification or activation of additional bearers while being connected to the other RAT). By maintaining the old TIN value the UE remembers to use the RAT TMSI indicated by the TIN when updating with the CN node of the other RAT.

Only if the TIN is set to ‘RAT-related TMSI’ ISR behaviour is enabled for the

UE, i.e. the UE can change between all registered areas and RATs without any update signalling and it listens for paging on the RAT it is camped on. If the TIN is set to "RAT-related TMSI", the UE's P-TMSI and RAI as well as its GUTI and TAI(s) remain registered with the network and valid in the UE.

When ISR is not active the TIN is always set to the temporary ID belonging to the currently used RAT. This guarantees that always the most recent context data are used, which means during inter-RAT changes there is always context transfer from the CN node serving the last used RAT.

The UE identities, old

GUTI IE and additional GUTI IE, indicated in the next TAU Request message, and old P-TMSI IE and additional P-TMSI/RAI IE, indicated in the next RAU Request message depend on the setting of TIN and are specified in table below.

181



P TMSI/RAI

P TMSI/RAI mapped

P TMSI/RAI

P TMSI/RAI

P TMSI/RAI

P TMSI/RAI mapped

P TMSI/RAI

Figure 7-21 Temporary UE ID to be indicated as old GUTI or old P-TMSI

The UE indicates also information elements ‘additional GUTI’ or ‘additional

P-TMSI’ in the Attach Request, TAU or RAU Request. These information elements permit the MME/SGSN to find the already existing UE contexts in the new MME or SGSN, when the ‘old GUTI’ or ‘old P-TMSI’ indicate values that are mapped from other identities.

TA list

RA#2

RAU Request (P-TMSI + additional P-TMSI = mapped GUTI

RNC/BSC

RA#1

RNC/BSC

SGSN

SGSN

GUMMEI part of

GUTI identifies MME

S3 S3 eNodeB MME

Figure 7-22 Additional GUTI/P-TMSI

The information flow in Fig.7-22 shows an example of ISR activation. For explanatory purposes the figure is simplified to show the MM parts only.

The process starts with an ordinary Attach procedure not requiring any special functionality for support of ISR. The Attach however deletes any existing old

182


7 Traffic Cases

ISR state information stored in the UE. With the Attach request message, the

UE sets its TIN to ‘GUTI’. After attach with MME, the UE may perform any interactions via E-UTRAN without changing the ISR state. ISR remains deactivated. One or more bearer contexts are activated on MME, S-GW and

P-GW, which is not shown in the figure.

The first time the UE reselects GERAN or UTRAN it initiates a Routing Area

Update. This represents an occasion to activate ISR. The TIN indicates

‘GUTI’ so the UE indicates a P-TMSI mapped from a GUTI in the RAU

Request. The SGSN gets contexts from MME and both CN nodes keep these contexts because ISR is being activated. The SGSN establishes a control relation with the S-GW, which is active in parallel to the control connection between MME and S-GW (not shown in figure). The RAU Accept indicates

ISR activation to the UE. The UE keeps GUTI and P-TMSI as registered, which the UE memorises by setting the TIN to "RAT-related TMSI". The

MME and the SGSN are registered in parallel with the HSS.

After ISR activation, the UE may reselect between E-UTRAN and

UTRAN/GERAN without any need for updating the network as long as the

UE does not move out of the RA/TA(s) registered with the network.

The network is not required to activate ISR during a RAU or TAU. The network may activate ISR at any RAU or TAU that involves the context transfer between an SGSN and an MME. The RAU procedure for this is shown in Fig. 7-23. ISR activation for a UE, which is already attached to

GERAN/UTRAN, with a TAU procedure from E-UTRAN works in a very similar way.

MME SGSN HSS

Attach Request (old GUTI = real

GUTI or mapped from P-TMSI)

Attach Accept (GUTI)

Attach Accept never indicates ISR activation so UE sets TIN to GUTI

HSS interactions

MME registered

Normal Attach procedure, nothing special for ISR besides deactivation of any potential old ISR states

RAU Request (P-TMSI mapped from GUTI because TIN = GUTI)

Context Request

Context Res (ISR capability)

Context Ack (ISR activated) store SGSN ID

RAU Accept (P-TMSI, ISR)

RAU Accept indicates ISR so UE sets TIN to RAT-related TMSI store MME ID

HSS interactions

SGSN registered

RAU procedure with ISR activation, UE has valid MM contexts for SGSN and

MME, SGSN and MME have valid MM registration from UE, SGSN and MME are registered with HSS

Figure 7-23 ISR activation

183



Fig. 7-24 shows a downlink data transfer to an idle state UE when ISR is activated. The S-GW receives downlink data. Because of activated ISR, the S-GW has control connections with both MME and SGSN and sends therefore downlink data notifications to both nodes. MME and SGSN start their paging procedures, which results in paging of the UE in the registered

RA and TA(s) in parallel.

In the example illustrated in Fig. 7-24 it is assumed that the UE camps on

E-UTRAN. So the UE responds to paging as usual with Service Request. This triggers the MME to setup the user plane connection between eNodeB and

S-GW. The downlink data are transferred to the UE.

When the UE camps on UTRAN/GERAN it performs the paging response as specified for these access systems without any required update or other signalling before. The downlink data are then transferred via

UTRAN/GERAN to the UE.

RNC/BSC MME SGSN





S-GW P-GW

Downlink data

Paging

Paging

Paging

Service Request

Paging

User Plane Setup

Downlink data

User Plane Setup

Figure 7-24 Downlink data transfer (ISR active)

Deactivation of ISR for the UE does not require any specific functionality.

The status of ISR activation is refreshed in every RAU and TAU Accept message. If there is no explicit indication of ISR Activated in these messages then ISR is deactivated and the UE sets its TIN to ‘GUTI’ or ‘P-TMSI’, as specified in Fig. 7-20. This causes always ISR deactivation when a UE performs a RAU with a Gn/Gp SGSN of any standards release as these

SGSNs never indicate ‘ISR Activated’ to the UE.

184


8 Security

Chapter 8

Authentication................................................................................................ 187

EPS key hierarchy.......................................................................................... 194

Ciphering & integrity protection.................................................................... 196

Key handling in handover .............................................................................. 201

Key-change-on-the-fly................................................................................... 206


185



186


8 Security

A uthentication

Two security features related to entity authentication are provided:

•

user authentication: the property that the serving network corroborates the user identity of the user,

•

network authentication: the property that the user corroborates that she/he is connected to a serving network that is authorised by the user's Home Environment (HE) to provide him services; this includes the guarantee that this authorisation is recent.

The entity authentication occurs at each connection set-up between the user and the network. Two mechanisms have been included: an authentication mechanism using an Authentication Vector (AV) delivered by the user's

Home network Environment (HE) to the serving network, and a local authentication mechanism using the integrity key established between the user and serving network during the previous execution of the Authentication and

Key Agreement (AKA) procedure. user authentication network authentication

Figure 8-1 Entity authentication

A R99 or later USIM application is sufficient for accessing E-UTRAN, provided that the separation bit in the AMF is not used for operator specific purposes (e.g. support of multiple authentication algorithms and keys, changing sequence number verification parameters, setting threshold values to restrict the lifetime of cipher and integrity keys) 1 .

Additionally for R8 and later USIM application, bits 1 to 7 are reserved for future standardisation use and only bits 8 to 15 can be used for proprietary purposes.

1 This restriction applies only to separation bit in the AMF. Other bits in the AMF still can be used for operator specific purposes.

187



Access to E-UTRAN with a 2G SIM or a SIM application on a Universal

Integrated Circuit Card (UICC) shall not be granted.

SIM

NO ACCESS

&

separation bit in the AMF is not used for operator specific purposes

USIM

R8

+

&

separation bit in the AMF is not used for operator specific purposes, bits 1 to

7 reserved for future standardisation

Figure 8-2 SIM, USIM and separation bit in the AMF

Authentication and Key Agreement

The mechanism described here achieves mutual authentication by the user and the network showing knowledge of a secret key K which is shared between and available only to the USIM and the AuC in the user's HE. In addition the

USIM and the HE keep track of counters SQN

MS

and SQN

HE

respectively to support network authentication. The sequence number SQN

HE is an individual counter for each user and the sequence number SQN

MS

denotes the highest sequence number the USIM has accepted.

Additionally, EPS AKA procedure produces keying material forming a basis for User Plane (UP), RRC, and NAS ciphering keys as well as RRC and NAS integrity protection keys.

MME HSS

Authentication data request

(IMSI, MCC+MNC, E-UTRAN)

Generate EPS-AVs

Store EPS-AVs

Authentication data response

(EPS-AV(1..n))

Select EPS-AV(i)

Authentication request (RAND(i), AUTN(i))

Verify AUTN(i), compute RES(i)

Authentication response (RES(i))

Compare RES(i) and XRES(i)

Compute CK(i), IK(i) and K

ASME

(i)

Select K

ASME

(i)

Figure 8-3 Authentication and Key Agreement (AKA)

188


8 Security

The Authentication data request includes the IMSI, Serving Network identity (i.e. MCC+MNC) and the Network Type (i.e. E-UTRAN).

Upon receipt of a request from the MME, the HE/HSS sends an ordered array of n EPS-AV(1..n), to the MME.

The EPS-AV are ordered based on sequence number. Each EPS-AV consists of the following components:

Access Stratum Management Entity Key K

ASME,

a random number RAND, an authentication token AUTN and an expected response XRES.

If the Network Type equals E-UTRAN then the ‘separation bit’ in the AMF field of AUTN is set to 1 to indicate to the UE that the authentication vector is only usable for AKA in an EPS context, if the ‘separation bit’ is set to 0, the vector is usable in a non-EPS context only (e.g. GSM, UMTS). For authentication vectors with the ‘separation bit’ set to 1, the secret keys:

Ciphering Key (CK) and Integrity protection Key (IK) generated during AKA shall never leave the HSS.

Each authentication vector is good for one AKA between the MME and the

USIM. Authentication vectors in MME are used on an FIFO basis.

When the MME initiates an EPS AKA, it selects the next EPS-AV from the ordered array and sends the random challenge RAND and an authentication token AUTN to the USIM via ME in Authentication Request message.

At receipt of those parameters, the USIM verifies freshness of the authentication vector, and than checks whether AUTN can be accepted and if so, produces a response RES and computes CK and IK. The CK, IK and

Serving Network’s identity (SN id) are used by Key Derivation Function

(KDF) in ME to compute K

ASME

. SN id binding implicitly authenticates the serving network's identity when the derived keys from K

ASME

are successfully used. Additionally, an ME accessing E-UTRAN checks during authentication that the ‘separation bit’ in the AMF field of AUTN is set to 1 and reject authentication otherwise.

UE responds with Authentication Response message including RES in case of successful AUTN and AMF verification. Otherwise UE sends

Authentication Reject message.

The MME compares the received RES with XRES. If they match the MME considers the EPS AKA to be successfully completed.


189


MME

(Network Type = E-UTRAN)

Authentication data response

UE

(RAND, AUTN, AMF separation bit = 1)

EPS security context

Figure 8-4 Separation bit (EPS security context)

(RAND, AUTN, AMF separation bit = 0) non-EPS security context

SGSN HLR

Authentication data request

Authentication data response

Figure 8-5 Separation bit (non-EPS security context)

If the keys CK, IK resulting from an EPS AKA run were stored in the fields already available on the USIM R99 – R7 for storing keys CK and IK this could lead to overwriting keys resulting from an earlier run of UMTS AKA.

This would lead to problems when EPS security context and UMTS security context were held simultaneously (as is the case when security context is stored e.g. for the purposes of ISR).

CK, IK

USIM

R99 – R7

CK, IK

UMTS AKA SGSN

K

ASME

USIM

R99 – R7

EPS AKA MME

Figure 8-6 EPS and UMTS security context conflict (USIM R99 – R7)

In case of USIM R8 or later, there are separate files to store EPS, UMTS and

GSM/GPRS security contexts separately so such conflict can not happen.

190


8 Security

EF

EPSNSC

EPS NAS Security Context

EF

Keys

Ciphering and Integrity Keys

EF

KeysPS

Ciphering and Integrity Keys for PS domain

EF

Kc

EF

KcGPRS

GPRS Ciphering key KcGPRS

Figure 8-7 Security contexts on USIM R8

Generation of authentication vecto rs in HE/AuC

Fig. 8-8 shows the generation of an UMTS and EPS-AV by the HE/AuC.

Generate SQN

K AMF SQN

Generate RAND

RAND SN id f1

MAC f2

XRES f3

CK f4

IK f5

AK

KDF

K

ASME

AUTN := SQN

⊕

AK || AMF || MAC

UMTS AV := RAND || XRES || CK || IK || AUTN

EPS AV := RAND || XRES || K

ASME

|| AUTN

Figure 8-8 Generation of authentication vectors

The HE/AuC starts with generating a fresh sequence number SQN and an unpredictable challenge RAND. For each user the HE/AuC keeps track of a counter SQN

HE.

191



Subsequently the following values are computed:

• a Message Authentication Code MAC = f1 (SQN || RAND || AMF) where f1 is a message authentication function;

• an eXpected RESponse XRES = f2 (RAND) where f2 is a message authentication function;

• a Cipher Key CK = f3 (RAND) where f3 is a key generating function;

• an Integrity Key IK = f4 (RAND) where f4 is a key generating function;

• an Anonymity Key AK = f5 (RAND) where f5 is a key generating function or f5

≡

0;

• an Access Stratum Management Entity Key K

ASME

= KDF (CK ||

IK || AK || SQN || SN id) where KDF is a Key Derivation Function.

Finally the authentication token AUTN = SQN ⊕ AK || AMF || MAC is constructed.

AK is an anonymity key used to conceal the sequence number as the latter may expose the identity and location of the user. The concealment of the sequence number is to protect against passive attacks only.

K

ASME

Figure 8-9 Authentication parameters

An authentication and key management field AMF is included in the authentication token of each authentication vector. Example uses of AMF includes:

192


8 Security

• support multiple authentication algorithms and keys (This mechanism is useful for disaster recovery purposes. AMF may be used to indicate the algorithm and key used to generate a particular authentication vector.)

• changing sequence number verification parameters (This mechanism is used to change dynamically the limit on the difference between the highest SEQ accepted so far and a received sequence number SEQ).

User authentication function in the USIM

Upon receipt of the Authentication Request message the UE proceeds as shown in Fig. 8-10.

RAND AUTN

SQN

⊕

AK f5

AMF MAC

AK

⊕

SQN

USIM ME

SN id

K f1

XMAC f2

RES f3

CK f4

IK

KDF

K

ASME

Verify MAC = XMAC Verify that SQN is in the correct range

Figure 8-10 User authentication function

Upon receipt of RAND and AUTN the USIM first computes the anonymity key AK = f5 (RAND) and retrieves the sequence number SQN = (SQN ⊕

AK) ⊕ AK.

Next the USIM computes XMAC = f1 (SQN || RAND || AMF) and compares this with MAC which is included in AUTN. If they are different, the user sends Authentication Reject back to the MME with an indication of the cause and the user abandons the procedure. In this case, MME initiates an

Authentication failure report procedure towards the HLR. MME may also decide to initiate a new identification and authentication procedure towards the user.

193



Next the USIM verifies that the received sequence number SQN is in the correct range. If correct, the USIM computes RES = f2 (RAND) and includes this parameter in a Authentication Response back to the MME.

Next the USIM computes the cipher key CK = f3 (RAND) and the integrity key IK = f4 (RAND), which are than made available to the ME.

Finally, the ME computes the K

ASME

= KDF (CK || IK || AK || SQN || SN id).

Upon receipt of the Authentication Response the MME compares RES with the eXpected RESponse XRES from the selected authentication vector. If

XRES equals RES then the authentication of the user has passed. The MME also selects the appropriate K

ASME

from the selected authentication vector. If

XRES and RES are different, MME initiates an Authentication failure report procedure towards the HLR and may also decide to initiate a new identification and authentication procedure towards the user.

The verification of the SQN by the USIM will cause the MS to reject an attempt by the MME to re-use an Authentication Vector to establish a particular security context more than once. In general therefore the MME can use an Authentication Vector only once.

The mechanisms for verifying the freshness of sequence numbers in the

USIM to some extent allows the out-of-order use of sequence numbers. This is to ensure that the authentication failure rate due to synchronisation failures is sufficiently low. This requires the capability of the USIM to store information on past successful authentication events (e.g. sequence numbers).

The mechanism ensures that a sequence number can still be accepted if it is among the last x = 32 sequence numbers generated. The same minimum number x needs to be used across the systems to guarantee that the synchronisation failure rate is sufficiently low under various usage scenarios, in particular user movement between MMEs which do not exchange authentication information.

The EPS key hierarchy includes following keys: K eNB,

K

NASint,

K

NASenc,

K

UPenc,

K

RRCint and

K

RRCenc

(see Fig. 8-11).

K

eNB is a key derived by UE and MME from K

ASME

when the UE goes to

ECM-CONNECTED state or by UE and target eNB during eNB handover.

194


8 Security

USIM / AuC K

CK, IK

UE / HSS

UE / ASME

K

NASenc

K

NASint

UE / MME

K

ASME

UE / eNB

K eNB

K

UPenc

K

RRCint

K

RRCenc

Figure 8-11 EPS key hierarchy

Keys for NAS traffic:

•

K

NASint

is used for the protection of NAS traffic with a particular integrity algorithm This key is derived by UE and MME from K

ASME, as well as an identifier for the integrity algorithm using the Key

Derivation Function (KDF).

•

K

NASenc

is used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by UE and MME from

K

ASME, as well as an identifier for the encryption algorithm using the

KDF.

Keys for UP traffic:

•

K

UPenc is used for the protection of UP traffic with a particular encryption algorithm. This key is derived by UE and eNB from K eNB

, as well as an identifier for the encryption algorithm using the KDF.

Keys for RRC traffic:

•

K

RRCint is used for the protection of RRC traffic with a particular integrity algorithm. K

RRCint

is derived by UE and eNB from K eNB

, as well as an identifier for the integrity algorithm using the KDF.

•

K

RRCenc is used for the protection of RRC traffic with a particular encryption algorithm. K

RRCenc

is derived by UE and eNB from K eNB

as well as an identifier for the encryption algorithm using the KDF.

Intermediate keys:

•

NH is a key derived by UE and MME to provide forward security.

The NH is sent by the MME to the eNB using S1signalling.

•

K eNB

* is a key derived by UE and eNB when performing an horizontal or vertical key derivation using a KDF.

195



Authentication and key setting are triggered by the authentication procedure.

Authentication and key setting may be initiated by the network as often as the network operator wishes. Key setting can occur as soon as the identity of the mobile subscriber (i.e. GUTI or IMSI) is known by the MME. Key K

ASME

is stored in the MME and key K eNB

is derived using the KDF from the key

K

ASME

and transferred to the UE's serving eNB when needed. K

ASME

is stored in the UE and MME and updated with the next authentication procedure.

The RRC and UP keys are derived from the K eNB

using the KDF when needed.

K

NASenc

K

NASint

K

ASME

K eNB

K

UPenc

K

RRCenc

K

RRCint eNB

Authentication

K eNB

K

UPenc

K

RRCenc

K

RRCint

MME

K

NASenc

K

ASME

K

NASint

K eNB

Figure 8-12 E-UTRAN key setting during AKA

User an d signalling data confidentiality

All currently available ciphering algorithms are algorithms with a 128-bit input key. Each EPS Encryption Algorithm (EEA) is assigned a 4-bit identifier. Currently, the following values have been defined for NAS, RRC and UP ciphering:

0000 – EEA0 null ciphering algorithm

0001 – 128-EEA1 SNOW 3G based algorithm (same as UEA2)

0010 – 128-EEA2 AES based algorithm

Figure 8-13 EPS Encryption Algorithms (EEAs)

It is recommended, however it is not mandatory, to use RRC (AS signalling),

NAS signalling and User Plane (UP) data ciphering.

196


8 Security

Ciphering provided to RRC signalling prevents UE tracking based on cell level measurement reports, handover message mapping, or cell level identity chaining.

Implementation of all currently available EEAs is mandatory for UEs and eNBs (for RRC and UP ciphering) and for UEs and MMEs (for NAS signalling ciphering).

RRC and UP confidentiality protection is done at PDCP layer. Confidentiality protection for NAS is provided by the NAS protocol.

UE

IP

PDCP

RLC

MAC

PHY eNode B GW

IP

PDCP

RLC

MAC

PHY

Figure 8-14 User Plane confidentiality (protocols)

IP

UE

NAS

RRC

PDCP

RLC

MAC

PHY eNode B

RRC

PDCP

RLC

MAC

PHY

MME

NAS

Figure 8-15 Control Plane confidentiality (protocols)

The input parameters to the 128-bit EEA algorithms are an 128-bit cipher key

K

RRCenc

, K

UPenc or K

NASenc

as KEY, a 5-bit bearer identity BEARER which value corresponds to the radio bearer identity, the 1-bit direction of transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction dependent 32-bit input COUNT.

In case of RRC and UP ciphering value COUNT corresponds to the 32-bit

PDCP COUNT.

In case of NAS ciphering the COUNT is constructed as follows:

COUNT := 0x00 || NAS OVERFLOW || NAS SQN

197



Where:

• the leftmost 8 bits are padding bits including all zeros.

•

NAS OVERFLOW is a 16-bit value which is incremented each time the NAS SQN is incremented from the maximum value.

•

NAS SQN is the 8-bit sequence number carried within each NAS message.

Sender Receiver

COUNT DIRECTION

BEARER LENGTH

COUNT DIRECTION

BEARER LENGTH

KEY EEA KEY EEA

KEYSTREAM

BLOCK

PLAINTEXT

BLOCK

⊕ CIPHERTEXT

BLOCK

KEYSTREAM

BLOCK

⊕ PLAINTEXT

BLOCK

Figure 8-16 Ciphering of data

Fig. 8-16 illustrates the use of the ciphering algorithm EEA to encrypt plaintext by applying a keystream using a bit per bit binary addition of the plaintext and the keystream. The plaintext may be recovered by generating the same keystream using the same input parameters and applying a bit per bit binary addition with the ciphertext.

Integrity protection, and replay protection, is provided to NAS and RRC signalling.

When authentication of the credentials on the UICC during Emergency

Calling in Limited Service Mode, can not be successfully performed, the integrity and replay protection of the RRC and NAS signaling is omitted. This is accomplished by the network by selecting EIA0 for integrity protection of

NAS and RRC. EIA0 is only used for emergency calls.

User plane packets between the eNB and the UE are not integrity protected.

All currently available integrity protection algorithms are algorithms with a

128-bit input key. Each EPS Integrity Algorithm (EIA) is assigned a 4-bit identifier. Currently, the following values have been defined:

198


8 Security

0000 – EIA0 null integrity protection algorithm

0001 – 128-EIA1 SNOW 3G (same as UIA2)

0010 – 128-EIA2 AES

Figure 8-17 EPS Integrity protection Algorithms (EIAs)

Implementation of all currently available EIAs is mandatory for UEs and eNBs (for RRC signalling integrity protection) and for UEs and MMEs (for

NAS signalling integrity protection).

RRC integrity protection is provided by the PDCP layer between UE and eNB and no layers below PDCP are integrity protected. NAS integrity protection is provided by the NAS protocol.

UE eNode B MME

NAS

RRC

PDCP

RLC

RRC

PDCP

RLC

NAS

MAC MAC

PHY PHY

Figure 8-18 Control Plane integrity protection (protocols)

The input parameters to the 128-bit EIA algorithms are an 128-bit integrity key K

RRCint or K

NASint

as KEY,

, a 5-bit bearer identity BEARER (for NAS constant value 0x00), the 1-bit direction of transmission DIRECTION and a bearer specific, time and direction dependent 32-bit input COUNT.

In case of RRC integrity protection value COUNT corresponds to the 32-bit

PDCP COUNT.

In case of NAS integrity protection the COUNT is constructed as follows:

COUNT := 0x00 || NAS OVERFLOW || NAS SQN

Where:

• the leftmost 8 bits are padding bits including all zeros.

•

NAS OVERFLOW is a 16-bit value which is incremented each time the NAS SQN is incremented from the maximum value.

•

NAS SQN is the 8-bit sequence number carried within each NAS message.

199



KEY

Sender

COUNT DIRECTION

MESSAGE BEARER-ID

Receiver

COUNT DIRECTION

MESSAGE BEARER-ID

EIA KEY EIA

MAC-I XMAC-I

Figure 8-19 Integrity protection of NAS/AS messages

Based on these input parameters the sender computes a 32-bit message authentication code (MAC-I/NAS-MAC) using the integrity algorithm EIA.

The message authentication code is then appended to the message when sent.

The receiver computes the expected message authentication code (XMAC-

I/XNAS-MAC) on the message received in the same way as the sender computed its message authentication code on the message sent and verifies the data integrity of the message by comparing it to the received message authentication code, i.e. MAC-I/NAS-MAC.

The supervision of failed RRC integrity checks is performed both in the ME and the eNB. In case of failed integrity check (i.e. faulty or missing MAC-I), the concerned message is discarded.

The supervision of failed NAS integrity checks is performed both in the ME and the MME. In case of failed integrity check (i.e. faulty or missing

NAS-MAC), the concerned message is discarded except for some NAS messages that in certain situations are sent by the network before security can be activated.

NAS integrity is activated with the help of the NAS Security Mode Command

(SMC) procedure immediately after successful authentication. NAS integrity stays activated until the EPS security context is deleted. While the EPS security context exists, all NAS messages are integrity protected. In particular the NAS service request is always be integrity protected and the NAS attach request message shall be integrity protected if the EPS security context is not deleted while UE is in EMM-DEREGISTERED. The length of the

NAS-MAC is 32 bit. The full NAS-MAC is appended to all integrity protected messages except for the Service Request. Only the 16 least significant bits of the 32 bit NAS-MAC are appended to the Service Request message.

200


8 Security

The general principle of key handling at handovers is depicted in Fig. 8-20.

K

NAS uplink COUNT

(K eNB

)

Initial

NH

PCI,

K * *

K

PCI,

EARFCN- DL

K *

K eNB

PCI,

EARFCN- DL

K eNB

* *

K

PCI,

EARFCN-DL

K *

K

K eNB

PCI,

EARFCN- DL

K eNB

*

K eNB

NCC = 0

NCC = 1

NH K K

K * * K * K * *

Figure 8-20 Handover key chaining

K NCC = 2

Whenever an initial AS security context needs to be established between UE and eNB, MME and the UE derive a K eNB

and a Next Hop (NH) parameter.

The K eNB

and the NH are derived from the K

ASME

. A NH Chaining Counter

(NCC) is associated with each K eNB

and NH parameter. Every K eNB

is associated with the NCC corresponding to the NH value from which it was derived. At initial setup, the K eNB

is derived directly from K

ASME

, and is then considered to be associated with a virtual NH parameter with NCC value equal to zero. At initial setup, the derived NH value is associated with the

NCC value one.

The UE and the eNB use the K eNB

to secure the communication between each other. On handovers, the basis for the K eNB

that will be used between the UE and the target eNB, called K eNB

*, is derived from either the currently active

K eNB

or from the NH parameter.

If K eNB

* is derived from the currently active

K eNB

this is referred to as a horizontal key derivation and if the K eNB

* is derived from the NH parameter the derivation is referred to as a vertical key derivation (see Fig. 8-20).

On handovers with vertical key derivation the NH is further bound to the target Physical Cell Identity (PCI) and its frequency

EARFCN-DL before it is taken into use as the K eNB

in the target eNB. On handovers with horizontal key derivation the currently active K eNB

is further bound to the target PCI and its frequency EARFCN-DL before it is taken into use as the K eNB

in the target eNB.

NH parameters are only computable by the UE and the MME. The MME provides NH parameters to eNBs.

The MME does not send the NH value to eNB at the initial connection setup.

201



Since the MME does not send the NH value to eNB at the initial connection setup, the NH value associated with the NCC value one can not be used in the next X2 handover or the next intra-eNB handover, for the next X2 handover or the next intra-eNB handover the horizontal key derivation will apply.

Initial set-up

no NH horizontal key derivation at first HO

Figure 8-21 No NH value at initial set-up

MME eNB h andover

When the eNB decides to perform an intra-eNB handover it derives K eNB

* using target PCI, its frequency EARFCN-DL, and either NH or the current

K eNB

depending on the following criteria:

• the eNB uses the NH for deriving K eNB

* if an unused {NH, NCC} pair is available in the eNB (vertical key derivation),

• otherwise if no unused {NH, NCC} pair is available in the eNB, the eNB derives K eNB

* from the current K eNB

(horizontal key derivation).

The eNB uses the K eNB

* as the K eNB

after handover. The eNB sends the NCC used for K eNB

* derivation to UE in Handover Command message.

HO CMD (NCC) unused NH, NCC, …

S

13

K eNB

*

202

Figure 8-22 Intra-eNB handover (vertical key derivation)


8 Security

HO CMD (NCC)

K eNB

, NCC, …

S

13

K eNB

*

Figure 8-23 Intra-eNB handover (horizontal key derivation)

Key handling at X2-handovers is depicted in Fig. 8-24.

S

13

K eNB

*

MME

S1

Pa

Pa th S

(N th S witc

S1

H, witc

NC h R

C)

Handover Request (K eNB h R eq

*, NCC) ue st eq

. A ck.

X2

Handover Command (NCC)

Ha ndo ver

Co mp lete

Figure 8-24 X2-handover

As in intra-eNB handovers, for X2 handovers the source eNB performs a vertical key derivation in case it has an unused {NH,NCC} pair. The source eNB first computes K eNB

* from target PCI, its frequency EARFCN-DL, and either from currently active K eNB

in case of horizontal key derivation or from the NH in case of vertical key derivation. The target eNB associates the NCC value received from source eNB with the K eNB

.

203



Next the source eNB forwards the {K eNB

*, NCC} pair to the target eNB.

The target eNB includes the received NCC into the prepared Handover

Command message, which is sent back to the source eNB in a transparent container and forwarded to the UE by source eNB.

The target eNB uses the received K eNB

* directly as K eNB

to be used with the UE. When the target eNB has completed the handover signalling with the

UE, it sends a Path Switch Request to the MME.

Upon reception of the Path Switch request, the MME increases its locally kept NCC value by one and compute a new fresh NH by using the K

ASME

and its locally kept NH value as input.

The MME then sends the newly computed {NH, NCC} pair to the target eNB in the Path Switch Request Acknowledge message. The target eNB stores the received {NH, NCC} pair for further handovers and remove other existing unused stored {NH, NCC} pairs if any.

Because the path switch message is transmitted after the radio link handover, it can only be used to provide keying material for the next handover procedure and target eNB. Thus, for X2-handovers key separation happens only after two hops because the source eNB knows the target eNB keys. The target eNB can immediately initiate an intra-cell handover to take the new NH into use once the new NH has arrived in the Path Switch Request Acknowledge. h andover

Key handling at X2-handovers is depicted in Fig. 8-25.

MME

Forward Relocation Request (NH, NCC, KSI, K

ASME

)

MME

Handover Command (NCC)

NCC, NH, PCI,

EARFCN-DL

S

13

K eNB

*

Figure 8-25 S1-handover

204


8 Security

When an S1-handover is performed, the source eNB does not send any keys to the MME in the Handover Required message.

Upon reception of the Handover Required message the source MME computes a fresh {NH, NCC} pair from its stored data. The source MME stores that fresh pair and send it to the target MME in the Forward Relocation

Request message. The Forward Relocation Request message in addition contains the K

ASME

that is currently used to compute {NH, NCC} pairs and its corresponding eKSI. The target MME stores locally the {NH, NCC} pair received from the source MME.

The target MME then sends the received {NH, NCC} pair to the target eNB within the Handover Request.

Upon receipt of the Handover Request from the target MME, the target eNB computes the K eNB

to be used with the UE by performing the key derivation with the fresh {NH, NCC} pair received in the Handover Request and the target PCI and its frequency EARFCN-DL.

The target eNB includes the NCC value from the received {NH, NCC} pair into the Handover Command to the UE and remove any existing unused stored {NH, NCC} pairs.

The source MME may be the same as the target MME. If so the single MME performs the roles of both the source and target MME, i.e. the MME calculates and stores the fresh {NH, NCC} pair and sends this to the target eNB.

The UE behaviour is the same regardless if the handover is S1, X2 or intraeNB.

If the NCC value the UE received in the HO Command message from target eNB via source eNB is equal to the NCC value associated with the currently active K eNB

, the UE derives the K eNB

* from the currently active K eNB

and the target PCI and its frequency EARFCN-DL.

If the UE received an NCC value that was different from the NCC associated with the currently active K eNB

, the UE first synchronizes the locally kept NH parameter by computing fresh NH parameter iteratively (and increasing the

NCC value until it matches the NCC value received from the source eNB via the HO command message. When the NCC values match, the UE computes the K eNB

* from the synchronized NH parameter and the target PCI and its frequency EARFCN-DL.

The UE uses the K eNB

* as the K eNB

when communicating with the target eNB.

205



Key-change-on-the-fly consists of re-keying or key-refresh.

K eNB ,

K

RRC-enc

, K

RRC-int

, and K

UP-enc key-refresh is initiated by the eNB when a PDCP COUNTs is about to be re-used (PDCP COUNTs are about to wrap around) with the same Radio Bearer identity and with the same K eNB

.

HO Cmd (NCC)

PDCP COUNT

Figure 8-26 Key-refresh

K eNB ,

K

RRC-enc

, K

RRC-int

, K

UP-enc

, K

NAS-enc

and K

NAS-int re-keying is initiated by the MME when an EPS AS security context different from the currently active one is activated.

Re-keying of the entire EPS key hierarchy including K

ASME

is achieved by first re-keying K

ASME

, then K

NAS-enc

and K

NAS-int

, followed by re-keying of the

K eNB

and derived keys. eNB new AKA

HO Cmd

NAS SMC

UE Context Modification

Request (K eNB

)

MME

Figure 8-27 Re-keying

For NAS key change-on-on-the fly, activation of NAS keys is accomplished by a NAS SMC procedure.

AS Key-change-on-the-fly is accomplished using a procedure based on intra-cell handover.

206


9 EPS Management

Chapter 9

Introduction.................................................................................................... 209

Establishment of new eNB............................................................................. 212

Self optimisation ............................................................................................ 214


207



208


9 EPS Management

The E-UTRAN and EPC systems need to be managed. As E-UTRAN and

EPC are evolvements of UMTS, the management also evolves from UMTS.

The complexity of the E-UTRAN/ EPC network places new demands on the

O&M of the network, therefore as well as re-using and evolving existing management solutions, management solutions for E-UTRAN/ EPC also need to encompass some new functionality, e.g.:

EPS new O&M functionality: auto-configuration, auto-optimisation, information model discovery, development of pear-to-pear interfaces.

Figure 9-1 EPS new O&M functionality.

Best practice in O&M has changed dramatically in recent years. This has been driven both by changes in the networks being managed and also by the increase in the number and complexity of services being supported on those networks.

The emphasis has changed from infrastructure management to the management of services supported on that infrastructure.

There is less focus on having all management applications at the Element

Management System (EMS) layer and greater emphasis on interfaces and data availability such that the Network Management System (NMS) and Operation

& Support System (OSS) layer have access to the required data.

The concept of Next Generation Networks (NGNs) decouples the supported services from the underlying access network. It was easier in the days of voice based services to assume that by managing the infrastructure the services were also managed. The multitude and complexity of today's services means that this is no longer the case.

Element Management (EM) is about managing a single domain from a single vendor. It no longer makes sense to do any significant analysis at this level since there is a strong interdependency between domains and vendors to

209


LTE/EPS Technology assure end-to-end QoS. It still makes sense to support some vendor/domain specific applications at this level, but the emphasis is on support of standardised interfaces that make the element management data available to the NMS and OSS.

An increased emphasis on O&M related standards is pivotal in enabling analysis applications at the NMS and OSS level. This makes it possible to do end-to-end analysis in the context of services rather than just RAN specific or

CN specific analysis for a given vendors equipment node.

The E-UTRAN/EPC networks will increase the numbers of NE's to be managed, while at the same time having strong requirements that emphasise the need to reduce network complexity and lower operating costs.

In order to reduce the operating expenditure (OPEX) associated with the management of this larger number of nodes from more than one vendor the concept of the Self-Organising Network (SON) is introduced. Automation of some network planning, configuration and optimisation processes via the use of SON functions can help the network operator to reduce OPEX by reducing manual involvement in such tasks. In 3GPP R8 many of the signalling interfaces between network elements are standardised (open) interfaces.

Significant examples in the context of SON are the X2 interface between eNBs and the S1 interface between eNB and the EPC (e.g. MME, SGW).

MME/S-GW MME/S-GW

S1

E-UTRAN

S1

S1 S1

X2 eNB

X2 X2

SON functionality included eNB

Figure 9-2 Open interfaces (SON context) eNB

210


9 EPS Management

If the solution for a particular SON-related use case is best provided at the network level the associated SON algorithm(s) will reside in one or more network elements. This is an example of a distributed SON architecture.

MME/S-GW

SON algorithm

S1

S1

SON algorithm

E-UTRAN

X2

MME/S-GW

SON algorithm

S1

S1

SON algorithm

X2 X2

SON algorithm

Figure 9-3 SON architecture (distributed)

If the solution is best provided in the existing network management system or in an additional standalone SON function or server, then the SON algorithm(s) will most likely reside either at DM or NM level. This is an example of a centralised SON architecture.

MME/S-GW

S1

S1

Management system SON algorithm

E-UTRAN

MME/S-GW

S1

S1

X2

X2 X2

Figure 9-4 SON architecture (centralised)

211



It may also result that the solution could require SON functionality partly at the network level and partly in the management system. This is an example of hybrid SON architecture.

For 3GPP R8 it has been decided that SON algorithms themselves will not be standardised.

Establishment of new eN B

A typical task for operational staff is the introduction of an eNB. This requires provision of initial configuration to the new cells and neighbouring cell list to both new and old cells in the surrounding area. add new cells modification of neighbour cell list initial configuration including neighbour cell list

Figure 9-5 Introduction of new eNB modification of neighbour cell list

It is very likely that in the future EPS networks the establishment of the new eNB will be performed fully automatically, according to the steps described below.

The first step is obviously the planning of a new site based on coverage and capacity requirements. The process can be supported by measurements to indicate coverage or capacity problems in the network. A first initial set of parameters I

1

is: location, eNB type, antenna type, cell characteristics

(sectors), required maximum capacity, etc..

After the physical installation of the eNB a first initial self test will start with a possible report R

1

in case of failure to the network element manager.

In the next step self configuration starts. The eNB requests its basic setup information: including configuration of IP-address and detection of O&M, authentication of eNB, association of a GW, downloading of eNB software.

212


9 EPS Management

Then as a second part of the self configuration the initial radio configuration

I

2 will be done. The following data might be provided via the network element manager from the planning tool or another self-configuration related instance: cell-id, power settings, antenna tilt, TAI, IP addresses of neighbourhood eNBs, etc..

In case any data are missing all parameters should be also derivable from a default value by an auto optimisation and it should be possible to send back this data to the element manager and the planning tool.

At the end of the procedure it is necessary to inform the neighbour eNBs about the existence of the new eNB and to include the new cells in the corresponding neighbourhood list of the neighbouring eNBs and to set neighbour specific parameters in these cells.

An additional self test like for example a plausibility check of parameter with possible report R

2

to the element manager could be done.

At the end of the installation the eNB is ready for commercial use and a test call can be done successfully.

Planning tool

I

1 planning and ordering

Network element manager

R

1

I

2

R

2 installation self test

1 self configuration self test

2 self optimisation

Establishment of new eNodeB

Figure 9-6 Introduction of the new eNB time

Operational State


213


Optimisation of the neighbourhood list

In operational phase, a further optimisation of neighbour list (including

2G/3G) can be done considering e.g. radio measurements of eNBs and UEs or call events like call drops, handover problems etc.. For this approach RRC connections (calls, signalling procedures) and their accompanying measurements can be used to gather the needed information about neighbours.

Known neighbours can be checked if they are really appropriate concerning real RF conditions, new ones can be included based on information in UEs about detected cells.

cell A cell C cell D cell B

signal strength (A) signal strength (C) signal strength (D) signal strength (B) configuration data signal strength (C) signal strength (A) signal strength (D) signal strength (B) configuration data signal strength (D) signal strength (B) signal strength (C) signal strength (A) configuration data signal strength (B) signal strength (D) signal strength (C) signal strength (A) configuration data

Data processing new neighbour list and new neighbour list and new neighbour list and new neighbour list and related parameters related parameters related parameters related parameters

Figure 9-7 Optimisation of neighbour list and related parameters

Another typical operational task is to optimise the network according to coverage and capacity. Planning tools support this task based on theoretical models but for both problems measurements must be derived in the network.

Call drop rates give a first indication for areas with insufficient coverage, traffic counters identify capacity problems.

Following parameters are identified as possibly beneficial to be optimised

(see Fig. 9-8):

214


9 EPS Management

Parameters to be optimised: subcarriers (subcarriers sets planned for cell borders), antenna tilt, power settings,

Radio Resource Management (RRM) parameters.

Figure 9-8 Coverage and capacity optimisation

For a deeper analysis e.g. the detection of the location of these areas detailed measurements are requested.

The current method for solving these problems and determining the correct configuration relies upon special tools to analyse RRM related measurements, interface tracing and drive tests.

For E-UTRAN the appropriate measurements, significant statistical base of performance measurements, problem specific measurement configuration and the full support of processing this valuable information shall be supported by

3GPP Telecom Management specifications.

Parameter optimisation due to trouble shooting

In a typical workflow performance measurements indicate problems in the network caused by different reasons (see Fig. 9-9): high call drop rate poor Setup Success Rate

HW defects or SW failures user failures poor average throughput many others wrong or not ideal parameterisation

Figure 9-9 Troubleshooting

Analyses of complex problems currently are based on drive test results, accompanied by interface traces. Typically signal strengths, signal quality values of neighbours, special call events like call drop, handover failures etc. are valuable indications both for optimisation and trouble shooting purpose. In special cases even cell and neighbour individual parameterisation must be found to mitigate problems. Obviously network quality and performance could be improved if such individual optimisation could be done by default for every cell. Further typical configuration failures would be found (if not already avoided by intelligent self-configuration function) like missing or lost neighbours, inappropriate hysteresis values, 2G- and 3G-neighbour related parameter and others.

215



Figure 9-10 Troubleshooting today (statistics + drivetest)

Optimisation of multiple parameters in a wider EPS network area will be supported by appropriate O&M functionality. The efficient transport of information about status of network elements, their configuration and a smart design to implement self-organising functionality is announced to be a selfevident feature of an E-UTRAN system.

Dynamic resource shifting and optimisation leads to better resource utilisation and cost effectiveness considering roaming of customer due to their daily activities. For example, during the day traffic is concentrated more in urban areas but at night there is a shift towards the suburban areas. f f

216 f

Figure 9-11 Dynamic resource shifting


f

9 EPS Management

In OFDM the opportunity exists to distribute air interface resources in a dynamic way to optimise on traffic situation or interference situation. Based on statistical measurements of power and interference level for single subchannels the coordination of sub-channels and dedicated power could be done in a dynamic way.

Other parameters beside sub-channels seen as beneficial in this area are principally antenna parameters, power settings and RRM management parameters.

Handover o ptimisation

The future EPS networks should also support automatic optimisation of handover parameters like: handover neighbour list, neighbour specific thresholds, margins and hysteresis. The autonomous intelligent optimisation algorithm should find the optimal configuration based on the following input parameters:

• handover trigger reasons,

•

Key Performance Indicators (KPIs): cell and neighbour specific HO success/failure rate, cell and neighbour specific path loss, received signal strength, interference measurements before HO events,

• planning data like maps, location of cells, theoretical path loss/interference,

• drive test results,

• traces of interfaces.

In the ideal case all measurements are linked with correct location information.

QoS related radio parameters optimi s ation

The EPS network should also support automated optimisation of the QoS related radio parameters. For example, the radio parameters influencing retransmission and discard operation in RLC layer or admission and congestion control parameters influence significantly the performance experience.


217



218


10 Services

Chapter 10

Introduction.................................................................................................... 221

Network architecture...................................................................................... 223

Identification .................................................................................................. 226

Protocols ........................................................................................................ 228

Traffic cases ................................................................................................... 230

Security .......................................................................................................... 241

Presence Service (PS) .................................................................................... 243

Push-to-talk over Cellular (PoC) ................................................................... 245

Immediate Messaging (IM)............................................................................ 246

Session-based Messaging (SM) ..................................................................... 247

SMS over generic IP-CAN ............................................................................ 250

White board communication.......................................................................... 254

Voice Call Continuity (VCC) ........................................................................ 254

Single Radio VCC (SRVCC)......................................................................... 260

219




220


10 Services

IP Multimedia Subsystem (IMS) refers to a network architecture consisting of an IP-based core network connected to multiple access networks to provide a converged services to wireless and wireline subscribers. Initially, IMS standards were defined for 3G UMTS, but the flexibility of the IMS network architecture has made it attractive to connect other access networks as well.

Additional networks, including GSM, CDMA, CATV, WiFi, WiMAX networks, enterprise and residential networks, are being added to this common IMS core.

(bearer services)

HSS

IMS

S-CSCF

P-CSCF

(teleservices)

I-CSCF

Figure 10-1 IMS – possible access networks

Legacy networks address a specific network access as shown below. They can be described as ‘vertically integrated’, i.e. optimised for a particular service category and typically offer a single service or set of closely related services.

The PSTN and PLMN are examples of vertically integrated networks. The operator offers everything from subscriber access to service creation and service delivery across a wholly owned network infrastructure. Each vertically integrated network incorporates its own protocols, nodes and end-user equipment. Telephony and data service domains are still kept more or less separate.

In contrast, the IMS provides switching, control and application processing across the multiple access networks offered by a particular operator. The IMS is often shown as a layered network consisting of a connectivity layer, a call control layer and an applications layer. Networks designed on this layered principle are described as ‘horizontally integrated’.

221



Vertical integration Horizontal integration

Services

MGW

Connectivity

Network

MGW

Access Access Access

Figure 10-2 Vertically and horizontally integrated networks

By layering the design of the network and providing open, standard interfaces, each part of the network can evolve at its own pace independent of changes in other parts of the network.

IMS uses the Session Initiation Protocol (SIP) protocol for multimedia session negotiation and session management. IMS is essentially a mobile SIP network designed to support this functionality, where IMS provides routing, network location, and addressing functionalities.

In contrast to the CS and PS domains, the IMS domain enables any type of media session to be established (e.g. voice, video, text, etc.). It also allows the service creator the ability to combine services from CS and PS domains in the same session, and for sessions to be dynamically modified (e.g. adding a video component to an existing voice session). This capability opens up a number of new and innovative user-to-user and multi-user services such as enhanced voice services, video telephony, chat, push-to-talk (PoC) and multimedia conferencing, all of which are based on the concept of a multimedia session.

IMS provides solution for operators who want to implement real-time IP mobile services without gambling on best effort transmission and the resulting customer dissatisfaction. Real-time mobile IP communication is difficult due to fluctuating bandwidths and delay, which severely affect the transmission of

IP packets through the network. In classical IP networks, IP transport would be what is known as ‘best effort’, meaning that the network will do its best to ensure the required bandwidths, but there is no guarantee. The result is that real-time mobile IP services may function poorly or not at all, depending on the bandwidth availability and network congestion.

222


10 Services

The Quality of Service (QoS) mechanisms were developed in order to overcome these issues and provide some type of guaranteed level of transmission instead of ‘best effort’. QoS ensures that critical elements of IP transmission such as transmission rate, gateway delay and error rates can be measured, improved and guaranteed in advance. Users are able to specify the level of quality they require depending on the type of service and the users’ circumstances.

The IP Multimedia CN subsystem comprises all CN elements for provision of multimedia services. This includes the collection of signalling and bearer related network elements as shown in Fig. 10-3. In the figure, all the functions are considered implemented in different logical nodes. If two logical nodes are implemented in the same physical equipment, the relevant interfaces may become internal to that equipment.

AS

HSS

I-CSCF

MRFC

MRFP

S-CSCF

P-CSCF

BGCF

MGCF

IM-MGW

Figure 10-3 Basic IMS architecture

The CSCF may take on various roles as used in the IP multimedia subsystem.

There are three different types of CSCF:

Proxy-CSCF (P-CSCF) is an entry point for the user to the IMS domain. Its address is discovered by UEs (described later in this chapter). It provides a simple, generic call control functions as well as potentially providing a SIP firewall to ensure security of the IMS domain. Additionally, the P-CSCF

223


LTE/EPS Technology could provide access to services that are not user specific but they are specific to the network, such as emergency calls.

Serving-CSCF (S-CSCF) performs the session control services for the UE. It maintains a session state as needed by the network operator for support of the services. Within an operator's network, different S-CSCFs may have different functionalities. The S-CSCF passes control to Application Servers (ASs) if required. The S-CSCF routes the call to the PSTN if required by invoking the

BGCF, MGCP and MGW.

Interrogating-CSCF (I-CSCF) is the contact point within an operator's network for all connections destined to a user of that network operator, or a roaming user currently located within that network operator's service area.

The I-CSCF also quarries the HSS to determine which S-CSCF the call should be assigned to.

Fig. 10-4 shows the usage of P-CSCF, S-CSCF and I-CSCF during IMS call.

Home A Home B

S-CSCF I-CSCF

HSS

S-CSCF

P-CSCF

P-GW

S-GW eNB media stream

Visited A network Visited B network

Figure 10-4 CSCF types

P-CSCF

P-GW

S-GW eNB

An Application Server (AS) offers value added IMS services and resides either in the user's home network or in a third party location. Examples of such services include: vice mail, prepaid subscription, push-to-talk and chat.

An Application Server may influence and impact the SIP session on behalf of the services supported by the operator's network. An AS may host and execute services.

224


10 Services

The Home Subscriber Server (HSS) is a database containing information about subscribers, services they have subscribed to and IP addresses of

S-CSCF they are currently registered to.

Signalling Gateway F unction (SGW)

The SGW performs the signalling conversion (both ways) at transport level between the SS7 based transport of signalling used in traditional CS networks, and the IP based transport of signalling (i.e. between SIGTRAN SCTP/IP and

SS7 MTP). The SGW does not interpret the application layer (e.g. MAP,

CAP, BICC, ISUP) messages but may have to interpret the underlying SCCP or SCTP layer to ensure proper routing of the signalling.

The Media Gateway Control Function (MGCF) controls the MGW to send or receive calls to/from PSTN and other CS networks. The MGCF uses SIP messages to/from the CSCF or BGCF and uses H.248 messages to/from the

MGW.

The IMS - Media Gateway Function (IMS-MGW) may terminate bearer channels from a circuit switched network and media streams from a packet switched network (e.g., RTP streams in an IP network). The IMS-MGW may support media conversion, bearer control and payload processing (e.g. codec, echo canceller, conference bridge).

The Multimedia Resource Function Controller (MRFC) controls the MRFP to provide media processing required by the AS. The MRFC uses SIP messages to/from the ASs and typically uses H.248 messages to/from the MRFP.

Media Resources Function Processor (MRFP) performs all of the media processing required by the ASs for supporting features such as conferencing, voice mail, recording, voice processing, etc.

225



The Breakout Gateway control function (BGCF) selects the network in which

PSTN breakout is to occur and - within the network where the breakout is to occur - selects the MGCF.

User identi ties

Every IMS user has one or more Private User Identities. The private identity is assigned by the home network operator, and used, for example, for

Registration, Authorisation, Administration, and Accounting purposes. This identity takes the form of a Network Access Identifier (NAI). It is possible for a representation of the IMSI to be contained within the NAI for the private identity.

Every IMS user also has one or more Public User Identities. The Public User

Identity(s) are used by any user for requesting communications to other users.

For example, this might be included on a business card. The Public User

Identity/identities take the form of a SIP URI (e.g. sip: jakub.bluszcz@neofon.tp.pl or sip: 48399571981@neofon.tp.pl).

When using a phone number as the dialled address, the UE can provide this number in the form of a SIP URI or a TEL URI. This phone number can be in the form of E.164 format (prefixed with a '+' sign), or a local format using local dialling plan and prefix. The IMS will interpret the phone number with a leading '+' to be a fully defined international number.

The E.164 NUmber Mapping (ENUM)/DNS translation mechanism can be used by all IMS nodes that require E.164 address to SIP URI resolution.

For example, E.164 number 48607221954 is translated into ENUM domain

4.5.9.1.2.2.7.0.6.8.4.e164.arpa.

It is possible that the ENUM/DNS mechanism uses a different top level domain to that of ‘e164.arpa.’, therefore, the top level domain to be used for

ENUM domain names is a network operator configurable option in all IMS nodes that can perform ENUM/DNS resolution.

ENUM databases may contain Number Portability information.

226


10 Services

With the introduction of standardised presence, messaging, conferencing, and group service capabilities in IMS, there is a need for Public Service Identities

(PSIs). These identities are different from the Public User Identities in the respect that they identify services, which are hosted by ASs. In particular,

PSIs are used to identify groups. For example a chat-type service may use a

PSI (e.g. sip:chatlist_X@example.com) to which the users establish a session to be able to send and receive messages from other session participants. As another example, local service may be identified by a globally routable PSI.

The IMS provides the capability for users to create, manage, and use PSI identities under control of AS. It is possible to create statically and dynamically a PSI.

Each PSI is hosted by an AS, which executes the service specific logic as identified by the PSI.

An IP Multimedia Services Identity Module (ISIM) is an application running on a UICC smart card in a UE in the IMS. It contains parameters for identifying and authenticating the user to the IMS. The ISIM application can co-exist with SIM and USIM on the same UICC making it possible to use the same smartcard in both GSM/UMTS and IMS.

The ISIM contains:

•

Private User Identity,

•

Home Network Domain Name,

•

IMS public user identity,

•

P-CSCF Address,

•

Secret keys used for IMS AKA.


227


Pr otocols

The key protocols used in IMS are presented in Fig. 10-5.

AS

MRFC

MRFP

HSS

I-CSCF

S-CSCF

P-CSCF

BGCF

MGCF

IM-MGW

Figure 10-5 Key protocols used in IMS

Session Initiation Protocol (SIP) is the main signalling protocol used in IMS networks. It was developed by the IETF and was selected by 3GPP as a standard for IMS in R5. The function of SIP is to establish, modify and terminate multimedia sessions – with medias such as voice, video and chat – over IP networks, where the media delivery part is handled separately. In SIP there is just one single protocol, which works end-to-end and supports the establishment and termination of user location, user availability, user capability, session set-up and session management. SIP is also designed to enable additional multimedia sessions and participants to be dynamically added or removed from a session.

Session Description Protocol (SDP) is indeed a data format rather than a protocol. It convey sufficient information to enable participation in a multimedia session.

228


10 Services

SDP includes description of:

• media to use (codec, sampling rate),

• media destination (IP address and port number),

• session name and purpose,

• times the session is active,

• contact information,

• different types of optional information (e.g. authorisation data).

INVITE sip: UserB@there.com SIP/2.0

Via: SIP/2.0/UDP here.com:5060

From: BigGuy <sip:UserA@here.com>

To: LittleGuy <sip:UserB@there.com>

Call-ID: 123456@here.com

CSeq: 1 INVITE

Subject: Hallo!

Contact: BigGuy <sip:UserA@here.com>

Content-Type: application/sdp

Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com

s=Session SDP c=IN IP4 100.101.102.103

t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

SIP/2.0 200 OK

Via: SIP/2.0/UDP here.com:5060

From: BigGuy <sip:UserA@here.com>

To: LittleGuy <sip:UserB@there.com>; tag 65a35

Call-ID: 123456@here.com

CSeq: 1 INVITE

Subject: Hallo!

Contact: LittleGuy <sip:UserB@there.com>

Content-Type: application/sdp

Content-Length: 134 v=0 o=UserA 2890844527 2890844527 IN IP4 there.com

s=Session SDP c=IN IP4 100.111.112.113

t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

Figure 10-6 SIP/SDP message structure

D iameter

Diameter is a development of the older RADIUS protocol used as the policy support and Accounting, Authentication, Authorisation (AAA) protocol for

IMS. Diameter is used by the S-CSCF, I-CSCF and the SIP application servers in the Service Layer, and in their exchanges with the HSS containing the user and subscriber information. Compared with RADIUS, Diameter has improved transport – it uses Transmission Control Protocol (TCP) or Stream

Control Transmission Protocol (SCTP), instead of UDP.

H.248 is a control protocol used between media control functions and media resources. Examples of nodes with media control functions are the Media

Gateway Control Function (MGCF) and Media Resource Function Controller

(MRFC). Typical media resources are the Media Gateway and Media

Resource Function Processor (MRFP).

229



IPv6 is a network-layer IP standard used by devices to exchange data across a packet-switched network. It follows IPv4 as the second version of the Internet

Protocol to be formally adopted for general use. Originally, IMS was specified to use IPv6; however, with 3GPP R6, IMS does provide support for

IPv4 and private address scheme. This means that even though IMS is expected to drive the adoption of IPv6, it is not dependent on IPv6 availability in order to be successfully launched.

HTTP is used by MRFC to fetch documents (scripts and other resources) from an AS.

EPS bearer for SIP signalling

Prior to communication with the IMS, the UE performs an EPS Attach procedure and ensures that a EPS bearer context used for SIP signalling is available. This EPS bearer context remains active throughout the period the

UE is connected to the IMS, i.e. from the initial registration and at least until the deregistration.

The default EPS bearer context is usually used for SIP signalling, however any other dedicated EPS bearer context can be used for SIP signalling as well.

UE is informed by the network whether the default EPS bearer context can be used for SIP signalling (IM CN Subsystem Signaling Flag parameter)

P-CSCF Address Request

IM CN Subsystem Signaling Flag

P-CSCF Address

IM CN Subsystem Signaling Flag

PDN Connectivity Request

Activate Default EPS Bearer Context Request

Activate Default EPS Bearer Context Accept

EPS network

Figure 10-7 Default EPS bearer for SIP signalling

230


10 Services

If the EPS bearer for SIP signalling establishment is initiated by the UE (i.e. it is not a default bearer), the UE indicates to the network in the Bearer

Resource Allocation Request message that the request is for SIP signalling, by setting IM CN Subsystem Signaling Flag. If the request is authorized, the network establishes a bearer with the appropriate QCI (i.e. QCI=5) and the IM

CN Subsystem Signaling Flag is set in the response message.

The UE may also use this EPS bearer context for DNS and DHCP signalling.

EPS bearer for media

In EPS, the UE cannot control whether media streams belonging to different

SIP sessions are established on the same EPS bearer context or not. During establishment of a session, the UE establishes data streams(s) for media related to the session. Such data stream(s) can result in activation of additional

EPS bearer context(s). Either the UE or the network can request for resource allocations for media, but the establishment and modification of the EPS bearer is controlled always by the network.

If the resource allocation is initiated by the UE, the UE starts reserving resources whenever it has sufficient information about the available media streams and codecs.

SDP ( media characteristics )

Bearer Resource Allocation Req. ( QoS )

Activate Ded. EPS Bearer Ctx. Req. ( QoS )

Activate Ded. EPS Bearer Accept

SDP ( ack )

EPS network

Figure 10-8 UE initiated resource allocation

IMS

If the UE is configured not to initiate resource allocation for media, then the

UE refrains from requesting additional EPS bearer context(s) for media until the UE considers that the network did not initiate resource allocation for the media.

If the resource reservation requests are initiated by the EPS IP-CAN, then the bearer establishment is initiated by the network after the P-CSCF has authorised the respective IP flows and provided the QoS requirements and optionally PCC parameters over the Rx interface to the PCRF.

231


LTE/EPS Technology eNB S-GW

EPS

PCRF

QoS and PCC

P-GW

Dedicated Bearer (GBR or non-GBR)

PCEF

IMS

AF

P-CSCF

Figure 10-9 Network initiated resource allocation

If the UE receives an activation request from the network for a EPS bearer context which is associated with the EPS bearer context used for signalling, the UE correlates, based on the information contained in the Traffic Flow

Template (TFT) information element, the media EPS bearer context with a currently ongoing SIP session establishment or SIP session modification.

In order that the user can make and receive calls, the UE has to be registered with an S-CSCF. Once registered, users can make and receive IMS domain calls until they deregister. Before the registration procedure can take place, the UE has to connect to the network and discover an entry point into the IMS domain. The entry point is the P-CSCF.

The P-CSCF discovery can be performed using one of the following mechanisms:

•

As a part of the establishment of connectivity towards the IP-CAN if the IP-CAN provides such means. In case when the IP-CAN is an

E-UTRAN based GPRS, discovery can be part of Default/Dedicated

EPS bearer context activation procedure, see Fig. 10-11 and Fig.

10-12. In case when the IP-CAN is a GERAN/UTRAN based GPRS, discovery can be a part of PDP Context Activation.

•

Alternatively, the P-CSCF discovery may be performed after the IP connectivity has been established by the use of DHCP mechanism or

P-CSCF address or domain name can be preconfigured on ISIM. If the domain name is known, DNS resolution is used to obtain the IP address.

232


10 Services

The application level registration can be initiated after the registration to the access network is performed, and after IP connectivity for the signalling has been gained from the access network. For the purpose of the registration information flows, the user is considered to be always roaming. For user roaming in their home network, the home network performs the role of the visited network elements and the home network elements.

Visited network Home network

HSS

IP-CAN P-CSCF I-CSCF S-CSCF

Figure 10-10 Functional entities for IMS registration

Fig. 10-10 shows the functional entities involved in registration and Fig.

10-11 shows the message sequence required.

Visited Network Home Network

P-CSCF

REGISTER

I-CSCF

REGISTER

HSS

UAR

UAA

REGISTER

SAR

SAA

S-CSCF

Service control

200 OK

200 OK 200 OK

Figure 10-11 IMS registration

The I-CSCF sends the Diameter User-Authentication-Request (UAR) to the HSS (the message contains user identity and P-CSCF network identifier).

The HSS checks whether the user is registered already. The HSS indicates whether the user is allowed to register in that P-CSCF network (identified by the P-CSCF network identifier) according to the user subscription and operator limitations/restrictions.

233



Diameter User-Authentication-Answer (UAA) is sent from the HSS to the

I-CSCF. It contains the S-CSCF name, if it is known by the HSS, or the

S-CSCF capabilities, if it is necessary to select a new S-CSCF. When capabilities are returned the I-CSCF performs the new S-CSCF selection based on the capabilities returned.

The I-CSCF, using the name of the S-CSCF, shall determine the address of the S-CSCF through a name-address resolution mechanism. I-CSCF then sends SIP REGISTER to the selected S-CSCF (message includes: P-CSCF address/name, user identity, P-CSCF network identifier, UE IP address).

The S-CSCF stores the P-CSCF address/name, as supplied by the visited network. This represents the address/name that the home network forwards the subsequent terminating session signalling to the UE.

The S-CSCF sends Diameter Server-Assignment-Request (SAR), (message includes: user identity and S-CSCF name) to the HSS.

The HSS stores the S-CSCF name for that user and returns Diameter

Server-Assignment-Answer (SAA) to the S-CSCF. The information passed from the HSS to the S-CSCF includes one or more names/addresses information which can be used to access the platform(s) used for service control while the user is registered at this S-CSCF. The S-CSCF stores the information for the indicated user. In addition to the names/addresses information, security information may also be sent for use within the S-CSCF.

Based on the filter criteria, the S-CSCF sends register information to the service control platform and perform whatever service control procedures are appropriate.

The S-CSCF returns the SIP 200 OK to the I-CSCF. Than I-CSCF sends

200 OK to the P-CSCF and releases all registration information.

The P-CSCF store the home network contact information and sends SIP

200 OK to the UE. The P-CSCF may subscribe at the PCRF to notifications of the status of the IMS Signalling connectivity.

Once the user is registered with an S-CSCF, voice and multimedia calls may be made to other users. The S-CSCF provides the main point of control of the call and any supplementary or advanced services features for that user. SIP signalling between the UE and the S-CSCF is routed via a P-CSCF, which provides a (secure) entry point to the IMS domain and a point of flexibility for routing SIP messages to home or visited network S-CSCFs.

234


10 Services

Each user will be registered with an S-CSCF, so that a simple voice call between two users will usually required two S-CSCFs to communicate (i.e. one for each user). Additionally, an I-CSCF is required in order to interrogate the HSS to find the S-CSCF on which the called user is registered. Fig. 10-14 shows the main functional entities involved in the control of voice calls between two mobile users. For simplicity, this scenario assumes that both users are connected to, and registered on, their home network (i.e. they are not roaming).

A’s home network B’s home network

HSS

S-CSCF

P-CSCF

I-CSCF S-CSCF

P-CSCF

A B

IP-CAN media

IP-CAN

Figure 10-12 Entities for mobile-to-mobile call

Fig. 10-13 illustrates the SIP signalling flow for a simple mobile-to-mobile call with a resource reservation phase, based on scenario in Fig. 10-12. It assumes that the underlying IP-CAN provides the necessary quality of service for the speech paths (or more generally for media flows selected by the users).

P-CSCF A

⓮ UPDATE

S-CSCF A I-CSCF B HSS S-CSCF B

❶ INVITE

100 TRYING

❷

❸ INVITE

100 TRYING

❹

INVITE

100 TRYING

❺

LIR/LIA

❻

INVITE

100 TRYING

⓫

183 SESS.PROG

183 SESS.PROG

❿

183 SESS.PROG

PRACK

⓬ PRACK

183 SESSION PROG.

PRACK

200 OK

200 OK

UPDATE

200 OK

UPDATE

P-CSCF B

❼

INVITE

❽ INVITE

100 TRYING

100 TRYING

183 SESS.PROG

183 SESS.PROG

❾

PRACK

200 OK

UPDATE

PRACK

200 OK

UPDATE

⓭

⓰

200 OK

180 RINGING

PRACK

200 OK

180 RINGING

PRACK

180 RINGING

200 OK

180 RINGING

PRACK

200 OK

180 RINGING

PRACK

200 OK

180 RINGING

⓯

200 OK

200 OK

200 OK

200 OK

ACK

200 OK

200 OK

200 OK

200 OK

200 OK

PRACK

200 OK

200 OK

⓱

⓲ ACK

ACK

ACK

ACK

⓳ (multi)media exchange

Figure 10-13 Mobile-to-mobile call set-up

235



❶ The UE A sends the SIP INVITE message to its P-CSCF A. It includes: identity of the called party (UE B), SDP information containing requested media parameters and the list of codecs supported by the UE A.

❷ Upon receipt of the SIP INVITE, the P-CSCF A returns an acknowledgement (SIP 100 TRYING message) back to the UE A to inform that the SIP INVITE message has been reliably received by the next hop in the chain.

❸ Next, the P-CSCF A undertakes some internal checks and procedures. For example it checks the requested media parameters against the policy of the visited network operator (e.g. G.711 codec not allowed because of 64 kb/s bandwidth necessity) and adds extra parameters related with charging. If all the checks are passed, the P-CSCF A forwards a slightly modified SIP

INVITE to the S-CSCF A.

❹ Upon receipt of the SIP INVITE the S-CSCF A first of all returns the SIP

100 TRYING message to P-CSCF A. Than, the S-CSCF A identifies the user and retrieves the user profile which was already downloaded during registration procedure. Next the S-CSCF A: evaluates the user profile to find out if and which AS need to be involved, checks SDP parameters against local network policy , e.g. codec format, analyses the called address to find the address of an I-CSCF and sends the SIP INVITE message to the I-CSCF 1 .

The I-CSCF acknowledges the message reception by sending back the SIP

100 TRYING message to S-CSCF A.

❺ The I-CSCF queries the HSS about the called subscriber to get informed, which S-CSCF B is already allocated to that user (during the registration procedure address of the S-CSCF B was stored in the HSS). It sends the

Diameter Location-Information-Request (LIR), which includes the called party identity..

The HSS returns the address of the allocated S-CSCF B to the I-CSCF by means of the Diameter Location-Information-Answer (LIA).

❻ The I-CSCF forwards the SIP INVITE message to the S-CSCF B.

The S-CSCF B sends the SIP 100 TRYING message back to the I-CSCF.

1 In case the called address is a SIP URI (sip: jakub.bluszcz@neofon.tp.pl) or a

SIP URI with mapped telephone number (e.g. sip: 48399571981@neofon.tp.pl), S-CSCF A contacts DNS to find the address of a SIP server (usually an I-CSCF) in the network neofon.tp.pl.

In case of a TEL URI, which may belong to a PSTN user or GSM user, the S-CSCF contacts

ENUM to get a SIP URI. If there is no SIP URI available, the S-CSCF A will contact the Breakout

Gateway Control Function (BGCF).

236


10 Services

❼ Upon receipt of the SIP 100 INVITE message the S-CSCF B evaluates the user profile to check if AS are to be involved at the called side.

The S-CSCF forwards the modified SIP INVITE message to the P-CSCF B.

❽ The reception of the SIP INVITE message will be acknowledged by returning the SIP 100 TRYING message. Then the P-CSCF B carries out a number of functions related to charging, security, control of P-GW, compression of signalling, etc. Finally, the modified SIP INVITE message is forwarded to the UE B.

❾ Upon receipt of the SIP INVITE, the UE B sends the TRYING message and a SIP 183 SESSION PROGRESS message that contains an SDP answer to communicate the media streams and codecs the UE B is able to handle for this session and advice for the UE A to send an updated SDP information when terminal resource reservation on calling side has been completed (the calling and the called party will be alerted only when resource reservation has been completed on both sides).

❿ The SIP 183 SESSION PROGRESS traverses step by step all the nodes back to the UE A (SDP part of the message contains the list of codecs supported by both UE A and UE B).

⓫ Finally, the SIP 183 SESSION PROGRESS message arrives at the UE A.

Upon receipt of the SIP 183 SESSION PROGRESS message (which includes the IP-address of UE B) the UE A is informed: whether or not the UE B accepts a session with the media streams proposed and what codecs are supported at both ends. The UE A now selects a codec from the list supported at both ends for each media stream. Then the UE A starts resource reservation. This is a procedure that is dependent on the underlying IP-CAN.

If the IP-CAN is an EPS network than alternatively, the resource reservation can be initiated by the network.

⓬ Finally, the UE A forwards the SIP PRACK message (including the final

SDP identifying the selected codec) to the UE B. At this time the resource reservation of UE A most probably is not completed yet.

⓭ Upon receipt of the SIP PRACK message the UE B confirms media streams and codecs by means of the OK message. As the selected codes are know now also on the UE B side, the UE B starts the resource reservation.

This is a procedure that is dependent on the underlying IP-CAN. If the

IP-CAN is EPS network than alternatively, the resource reservation can be initiated by the network.

⓮ When the necessary resources have been reserved at the calling side, UE A sends the SIP UPDATE message to UE B.

237



As any other message with SDP-content the reception of the SIP UPDATE message will be acknowledged by the UE B with an SIP 200 OK message

(traversing all the nodes in the chain). At this time the UE B may still be engaged in resource allocation.

⓯ Once resource reservation has been completed at the UE B (as well as at the calling side - these are independent processes which can be completed in any order) the UE B starts alerting the B party and generates the SIP 180

RINGING message back to UE B.

⓰ Upon receipt of the SIP 180 RINGING message the UE A applies a locally stored ring tone to the caller and sends the SIP PRACK message to UE B.

The SIP PRACK message is acknowledged by the UE B by sending the SIP

200 OK message to UE A. At this stage the B party gets ringing and the A party hears ring tone.

⓱ When the B party answers (i.e. accepts the session) the UE B sends an SIP

200 OK message.

⓲ When the SIP 200 OK message has arrived, the UE A stops ring tone and forwards the SIP ACK message to UE B to acknowledge the establishment of a session.

⓳ The session set-up is now completed and both parties can generate their audio and video streams. These media streams are sent end-to-end via the media plane.

Fig. 10-14 shows the main functional entities involved in the control of voice mobile-to-PSTN calls.

IMS

ENUM BGCF

P-CSCF S-CSCF media

MGCF

IM-MGW

SGW

Figure 10-14 Entities for mobile-to-PSTN call setup

PSTN

Fig. 10-15 illustrates the SIP signalling flow for a simple mobile-to-PSTN call with a resource reservation phase, based on scenario in Fig. 10-14.

238


10 Services

P-CSCF S-CSCF BGCF MGCF

❶ INVITE ENUM

INVITE ❷

100 TRYING

INVITE

❸ INVITE

100 TRYING

100 TRYING

100 TRYING

❻

183 SESS.PROG

183 SESS.PROG

PRACK

PRACK

183 SESS.PROG

183 SESS.PROG

❺

PRACK

❹ ADD.Req

ADD.Resp

ADD.Req

ADD.Resp

MOD.Req

200 OK

200 OK

200 OK (PRACK) ❽

MOD.Resp

MGW

❼

❾ UPDATE

UPDATE

200 OK

180 RINGING

200 OK

180 RINGING

UPDATE

200 OK (UPDATE)

180 RINGING

⓬ media: Ring Back Tone

❿ IAM

⓫ ACM

SGW

⓭ ANM

MOD.Req

200 OK

200 OK (INVITE)

⓮

200 OK

ACK

ACK

MOD.Resp

ACK media: Voice

Figure 10-15 Mobile-to-PSTN call setup

❶ UE sends the SIP INVITE message to its P-CSCF. It includes user identity of the called party, which is a TEL-URI (tel: +48323766305).

Upon receipt of the SIP INVITE, by means of sending the SIP 100 TRYING message the P-CSCF returns an acknowledgement back to the UE.

Next, the P-CSCF undertakes some internal checks and procedures, exactly as in the previous case of mobile-to-mobile call. If all the checks are passed, the

P-CSCF forwards the modified SIP INVITE to the S-CSCF.

❷ Upon receipt of the INVITE, the S-CSCF allocated to the UE identifies the user and retrieves the user profile which was already downloaded during registration procedure. Next the S-CSCF analyses the called address, which will be a TEL URI and contacts ENUM to resolve TEL URI into SIP URI. In this case of a call to the PSTN ENUM will not return a SIP URI. It may return a negative response or a TEL URI. Both these possibilities trigger the S-CSCF to send SIP INVITE to contact the Breakout Gateway Control Function

(BGCF), specialized in routing SIP requests based on telephone numbers.

❸ Upon receipt of the SIP INVITE the BGCF returns the SIP 100 TRYING message and analyses the destination address (i.e. the TEL URI). Based on agreements the home network operator may have for call termination in the

PSTN, the BGCF decides whether the session should be handled by a local

MGCF or by a remote MGCF. If the session to be handled locally, the BGCF further decides if it wants to stay in the chain of nodes traversing the further

239


LTE/EPS Technology message flow or not. The BGCF then routes the SIP INVITE message to the

MGCF (in our example to a local MGCF, and announces that it does not wish to remain in the signalling path for the rest of the session.

❹ Upon receipt of the SIP INVITE message the MGCF returns the SIP 100

TRYING message and selects the SGW and IM-MGW to be used for this session to meet the required preconditions (one MGCF can control many

SGW and IM-MGW).

Than MGCF request the selected IM-MGW for a new context by sending

H.248 ADD.request. The UE’s IP address, RTP port number and the list of available codecs is specified in the message.

The IM-MGW reserves resources for the RTP connection. The media connection is marked as one way as the MGCF has not specified the other end of this connection. The IM-MGE responds with H.248 ADD.response that includes identity of the allocated context, common codes that are supported by both UE and IM-MGW, the local IP address and RTP port number.

❺ The MGCF then responds with a SIP 183 SESSION PROGRESS message that contains an SDP answer to communicate the media streams and codecs the MGW is able to handle. The 183 SESSION PROGRESS message sent by the MGCF back to UE includes an SDP body as well as advice for the UE to send an updated SDP and to communicate when terminal resource reservation on calling side is completed (the calling and the called party will be alerted only when resource reservation has been completed on both sides).

❻ Upon receipt of the SIP 183 SESSION PROGRESS message (which includes the description of the IP speech termination at the MGW) the UE is informed: whether or not the MGCF accepts a session with the media streams proposed (for the time being only audio is specified) and what codecs are supported at the MGW connected to the called PSTN network.

❼ In a meantime the MGCF by sending another H.248 ADD.request is requesting the IM-MGW for the TDM termination towards the PSTN network. This termination is requested for the same context that was created during the previous contact with the IM-MGW.

Since the TDM circuit setup request was received for the same context identity as the previous RTP context, the IM-MGW associates the RTP and

TDM ports and responds with the H.248 ADD.response that contains TDM port identity (CIC).

❽ Upon receipt of the SIP PRACK message the MGCF starts resource modification in the IM-MGW. The H.248 MOD.request modifies the

IM-MGW context to update the IM-MGW about the codecs selected for the

RTP session by the UE. Then, after reception H.248 MOD.response, the

240


10 Services

MGCF confirms final codec format by means of the SIP 200 OK message.

The SIP 200 OK message traverses all the nodes in the chain back to UE.

❾ When the necessary resources have been reserved at the calling side (i.e. the Dedicated Bearer Activation procedure has been completed), UE sends the

SIP UPDATE message to MGCF (traversing all the nodes in the chain). As any other message with SDP-content the reception of the SIP UPDATE message will be acknowledged by the MGCF with an SIP 200 OK message.

❿ As the speech path is completed now at the mobile network side, the

MGCF sends the Initial Address Message (IAM), containing the called party phone number and the TDM termination identity (CIC) towards the PSTN exchange.

⓫ When the speech path towards the called party is allocated in the PSTN network the Address Complete Message (ACM) containing the subscriber free indication is sent to the MGCF. The ACM message also indicates that the called party in the PSTN network is being alerted. The MGCF performs the mapping of SS7 signalling and SIP and thus, sends the SIP 180 RINGING message back to UE.

⓬ The ring back tone is fed to the calling subscriber. The IM-MGW converts the tone into RTP packets. The UE converts it back to the ring back tone and feeds it to the calling subscriber.

⓭ When the called party answers the MGCF receives the ISUP Answer

Message (ANM). At this point, the MGCF issues another H.248

MODIFY.request to allow both-way speech paths to be switched through. The

MGCF then sends a SIP 200 OK message back to the UE, with a session description indication that two-way media may be sent and received.

⓮ When the SIP 200 OK has arrived at the UE, it forwards the SIP ACK message to MGCF to acknowledge the establishment of a session. The session set up is now completed and both parties can generate their audio streams.

These media streams are sent end-to-end via the media plane.

In a 3GPP network environment, even when an IMS subscriber has passed the

PS domain authentication, the IMS subscriber's identity must be confirmed by the IMS authentication again before accessing IMS services. Both the PS domain and the IMS authentications are necessary for the IMS subscriber.

241



This is referred to as a two-pass authentication. However, the PS domain authentication is carried out by the Authentication and Key Agreement

(AKA) of the 3GPP, called 3GPP AKA; the IMS authentication is carried out by IMS AKA. Since IMS AKA is based on 3GPP AKA, almost all of the operations are the same.

3GPP AKA

3GPP AKA

GERAN/

UTRAN/

E-UTRAN

IMS

Figure 10-16 3GPP AKA & IMS AKA

The initial SIP messaging (SIP REGISTER and associated response) is carried in the clear text (i.e. not encrypted). The response to the first SIP

REGISTER message contains a challenge for the user and key information for the P-CSCF. The P-CSCF removes the key information before forwarding the response to the user. The user calculates a response to the challenge and uses this calculated information to encrypt all future SIP control messages. The user sends a new register request encrypted, including the challenge response.

The P-CSCF uses the key information to decrypt the message and forward it in the clear toward the S-CSCF. The S-CSCF examines the response to authenticate the user. In the downstream direction, the P-CSCF uses the keys to encrypt the SIP messages before forwarding them to the user.

P-CSCF

REGISTER

I-CSCF

REGISTER

(RAND, AUTN)

401 AUT. REQ.

(RAND, AUTN,

CK, IK)

401 AUT. REQ.

REGISTER

(RES)

REGISTER

(RES)

200 OK

200 OK

HSS S-CSCF

UAR/UAA

REGISTER

(RAND, AUTN,

XRES, CK, IK)

MAR/MAA

401 AUTHORIZATION REQ.

(RAND, AUTN, CK, IK)

UAR/UAA

REGISTER (RES)

SAR/SAA

200 OK

Figure 10-17 IMS authentication

242


10 Services

The Presence Service (PS) provides the ability for the home network to manage presence information of a user’s device, service or service media even whilst roaming. A user’s presence information may be obtained through input from the user, information supplied by network entities or information supplied by elements external to the network. Consumers of presence information, watchers, may be internal or external to the home network.

The user can control the dissemination of her/his presence information to other users and services, and also be able to explicitly identify specifically which other users and services to which she/he provides presence status.

Figure 10-18 Presence Service

The architectural model for providing presence service is depicted in

Fig. 10-19 below.

3GPP AAA

PDG

HSS/HLR

S-CSCF

SGSN

GGSN

GMLC

HSS

P-CSCF

I-CSCF

S-CSCF

SIP

Presence User Agent

Presence list server external watcher

Presence server

Presence External Agent

Figure 10-19 Presence Service architecture

243



The Presence Server receives and manage presence information that is published by the Presence User Agents, Presence Network Agents or External

Agents, and is responsible for composing the presence-related information for a certain presentity from the information it receives from multiple sources into a single presence document.

The Presence Server provides also Subscription Authorization Policy. The

Subscription Authorization Policy determines which watchers are allowed to subscribe to a Presentity’s Presence information. The Subscription

Authorization Policy also determines which tuples of the Presentity’s

Presence information the watcher has access.

The function of the Agent elements is to make presence information available to the Presence Server element in standardized formats across standardized interfaces.

The Presence User Agent (PUA) collects presence information associated with a presentity and sends it to the Presence Server. In reality, a PUA may be located in the user’s terminal or within a network entity.

The Presence Network Agent (PNA) receives presence information from network elements and publishes it to the Presence Server.

The Presence External Agent (PEA) supplies Presence information from external networks and handles the interworking and security issues involved in interfacing to external networks.

The Presence List Server stores grouped lists of watched presentities and enables a Watcher Application to subscribe to the presence of multiple presentities using a single transaction. The Presence List Server is implemented as a SIP Application Server.

244


10 Services alk over Cellular (PoC)

Push-to-Talk over Cellular (PoC) service provides a walkie-talkie like service in the cellular communication infrastructure. In this service, several predefined PoC group members participate in one PoC session. Since the PoC session is half-duplex, only one group member speaks at a time, and the others listen. Therefore, a user must ask for the floor (the permission to speak) by pressing the push-to-talk button before he/she starts to talk.

Figure 10-20 Push-to-talk over Cellular (PoC)

The simplified architectural model for providing PoC service is depicted in

Fig. 10-21.

I-CSCF

HSS

P-CSCF

S-CSCF

SIP

XDMS PS server

PoC server

Figure 10-21 PoC architecture

The IMS network provides routing, security and charging support for the PoC service along with session control based on SIP.

245



The PoC server is implementing the application level network functionality.

It is connecting the PoC sessions together. PoC server also multiplies the speaker’s bit stream to multiple streams for the participants of the PoC session and is taking care of floor control. PoC server is also taking case of the voice transcoding in case of incompatible voice codecs in PoC clients. PoC server is essentially seen as an AS from the IMS perspective.

The XML Document Management Server (XDMS) is used by the PoC users to manage groups and lists (e.g. contact and access lists) that are needed for the PoC service.

A Presence server may provide availability information about PoC users to other PoC users.

Immediate Messaging (IM)

IMS users are also able to exchange Immediate Messages (IMs) containing any type of multimedia content, for example but not limited to: pictures, video clips, sound clips.

The IM delivery process of the IM is illustrated in Fig. 10-22.

A

P-CSCF A S-CSCF A I-CSCF B

MESSAGE

MESSAGE

MESSAGE

HSS

LIR/LIA

MESSAGE

S-CSCF B P-CSCF B

MESSAGE

200 OK

MESSAGE

200 OK

200 OK

200 OK

200 OK

200 OK

B

Figure 10-22 Immediate Messaging (IM)

UE A generates the multimedia content intended to be sent to UE B and sends the MESSAGE request to P-CSCF A that includes the multimedia content in the message body.

P-CSCF A forwards the MESSAGE request to S-CSCF A along the path determined upon UE A's most recent registration procedure.

246


10 Services

Based on operator policy S-CSCF A may reject the MESSAGE request with an appropriate response, e.g. if content length or content type of the

MESSAGE are not acceptable. S-CSCF A invokes whatever service control logic is appropriate for this MESSAGE request. This may include routing the

MESSAGE request to an Application Server, which processes the request further on.

S-CSCF A forwards the MESSAGE request to I-CSCF B.

I-CSCF B performs Location Query procedure with the HSS to acquire the

S-CSCF address of the destination user (S-CSCF B).

I-CSCF B forwards the MESSAGE request to S-CSCF B.

Based on operator policy S-CSCF B may reject the MESSAGE request with an appropriate response, e.g. if content length or content type of the

MESSAGE are not acceptable. S-CSCF B invokes whatever service control logic is appropriate for this MESSAGE request. This may include routing the

MESSAGE request to an Application Server, which processes the request further on. For example, the UE B may have a service activated that blocks the delivery of incoming messages that fulfil criteria set by the user. The AS may then respond to the MESSAGE request with an appropriate error response.

S-CSCF B forwards the MESSAGE request to P-CSCF B along the path determined upon UE B's most recent registration procedure.

P-CSCF B forwards the MESSAGE request to UE#2. After receiving the

MESSAGE UE B renders the multimedia content to the user.

UE B acknowledges the MESSAGE request with a response that indicates that the destination entity has received the MESSAGE request. The response traverses the transaction path back to UE A. based Messaging (SM)

If the message because of its length or high QoS requirements can not be delivered between users as the IM the users can switch to Session-based

Messaging (SM).

SM messages are exchanged between users via a separate traffic bearer. The

SM traffic bearer establishment is very similar to the traffic bearer establishment for mobile-to-mobile IMS call, that was described earlier. This solutions protects the IMS signalling network against any load increase due to transfer of the potentially large SM message.

247



The following procedure shows the establishment of a message session between two terminals.

A

P-CSCF A S-CSCF A I-CSCF B HSS S-CSCF B P-CSCF B

B messaging session establishment (as for IMS call) message exchange connection establishment (TCP/SCTP)

SEND MESSAGE

MESSAGE OK

Figure 10-23 Session-based Messaging (SM)

The first step is establishment of the messaging session, which is very similar to the establishment of the IMS call. The main difference is that SDP parts of the messages, instead of specifying the real time media connection parameters, are specifying the type of IP bearer connection suitable for exchange of message content. For session based messaging the SDP offer in the first INVITE request may indicate the maximum message size UE#1 accepts to receive and the 200 OK (Offer response) to the INVITE request may indicate the maximum message size UE B accepts to receive.

UE A establishes a reliable end-to-end connection with UE B to exchange the message media.

UE A generates the message content and sends it to UE B using the established message connection.

UE B acknowledges the message with a response that indicates that UE B has received the message. The response traverses back to UE A. After receiving the message UE B renders the multimedia content to the user.

Further messages may be exchanged in either direction between UE A and

UE B using the established connection.

Session based messaging between more than two UEs require the establishment of a session based messaging conference.

Within session based messaging conferences including multiple UEs (e.g. multiparty chat conferences) an Multimedia Resource Function Processor

(MRFC) / Multimedia Resource Function Processor (MRFP)or an IMS AS is used to control the media resources.

248


10 Services

When MRFC/MRFP are used, then conferencing principles are used to provide the chat service:

•

MRFP establishes message connections with all involved parties,

•

MRFC/MRFP receives messages from conference participants and to distribute messages to all or some of the participants,

•

In order to enable the UE managing information related to the session based messaging conference the MRFC may be co-located with an

IMS AS.

When an AS is used, then the IMS service control architecture is used to provide the chat service. Both signalling and user plane are then supported by the AS.

The originating session based messaging set up using an intermediate server for a chat service is shown in Fig. 10-26. In this case the intermediate chat server is addressed by the UE A using a Public Service Identity (PSI). It is assumed that UE A is the first UE entering the chat session.

A

P-CSCF A S-CSCF A

INVITE

INVITE

INVITE

MRFC or AS

MRFP

200 OK

200 OK

200 OK

ACK

ACK

ACK message exchange connection establishment

SEND MESSAGE

MESSAGE OK

Figure 10-24 Session based messaging using a chat server

UE A sends the SIP INVITE request addressed to a conferencing or chat

PSI to the P-CSCF. The SDP offer indicates that UE A wants to establish a message session and contains all necessary information to do that. The SDP offer may indicate the maximum message size UE A accepts to receive.

P-CSCF forwards the INVITE request to the S-CSCF.

S-CSCF may invoke service control logic for UE A.

249



S-CSCF forwards the INVITE request to the MRFC/AS.

MRFC/AS acknowledges the INVITE with a 200 OK, which traverses back to UE A. The 200 OK (Offer response) may indicate the maximum message size the host of the PSI accepts to receive.

Based on operator policy P-CSCF may authorize the resources necessary for this session.

UE A acknowledges the establishment of the messaging session with an

ACK towards MRFC/AS.

UE A establishes a reliable end-to-end connection with MRFP/AS to exchange the message media.

UE A sends a message towards MRFP/AS.

MRFP/AS acknowledges the message.

In the meantime, other users send an INVITE request addressed to the same conferencing or chat PSI. The initial SDP indicates that the UEs want to establish a message session and contains all necessary information to do that.

MRFP/AS forwards the message to all recipients, e.g. all participants in the chat room.

Further messages may be exchanged in either direction between the participating UEs using the established connection via the MRFC/MRFP or

AS.

SMS over generic IP access can be used to support applications and services that use SMS when a generic IP access is used.

SC

HSS

SMS-GMSC /

SMS-IWMSC

IP-SM-GW S-CSCF P-CSCF

Figure 10-25 SMS over generic IP-CAN architecture

250


10 Services

The IP-SM-GW has the following functions:

•

IP-SM-GW provides the protocol interworking for delivery of the

Short Message (SM) between the IP-based UE and the SMS-SC. The message is routed to the SMS-SC for delivery to the SMS-based user or the message is received from the SMS-SC of an SMS-based UE for delivery to an IP-based UE.

•

IP-SM-GW determines the domain (CS/PS or IMS) for delivery of a

SM.

•

IP-SM-GW appears to the SMS-GMSC and SMS-IWMSC as an MSC or SGSN and it appears as AS towards the IMS core.

•

IP-SM-GW communicates with the UE using IMS messaging as transport while maintaining the format and functionality of the SMS.

In order to support SMS over generic IP access, the HSS has to be upgraded to support the following functions:

• storing the pre-configured address of the IP-SM-GW on a subscriber basis (if all subscribers are assigned to a single IP-SM-GW address, the IP-SM-GW address does not need to be pre-configured in the

HSS);

• handling an indication that the terminal is registered with an

IP-SM-GW for delivery of SMS;

• responding to the MAP Send Routing Information for Short Message

(SRI for SM) query from IP-SM-GW with the address of the

MSC/SGSN and subscriber’s IMSI;

• forwarding the SRI for SM, from an SMS-GMSC, towards the

IP-SM-GW and forwarding any responses to the originator of the SRI for SM;

• alerting the SCs stored in the message waiting data when the terminal is registered with an IP-SM-GW for delivery of short message;

• reporting notification to the IP-SM-GW of the reachability of a UE at the transport layer after a delivery failure;

• accepting delivery status reports from IP-SM-GWs instead of

SMS-GMSC.

251



After successful IMS registration and based on the retrieved initial Filter

Criteria (iFC), the S-CSCF informs the IP-SM-GW about the registration of the user.

The IP-SM-GW registers its address (IP-SM-GW No) to the HSS, which in turn, stores an indication that the UE is available to be accessed via the IMS.

HSS

REGISTER

S-CSCF

REGISTER

P-CSCF IP-SM-GW

Figure 10-26 SMS over generic IP-CAN registration

UE sends an encapsulated SM to the S-CSCF, which in turn, forwards it to

IP-SM-GW based on stored iFC.

The IP-SM-GW performs service authorization based on the stored subscriber data, and if successful, forwards the SM towards the SMS-SC via the

SMS-IWMSC using standard MAP signalling.

HSS

SC

SMS-GMSC /

SMS-IWMSC


Figure 10-27 MO SMS over generic IP-CAN

252


10 Services

The MT SMS delivery process is illustrated in Fig. 10-28.

SC

SRI for SM

HSS

IP-SMS-GW No

SMS-GMSC /

SMS-IWMSC

SRI for

SM

MSC No

SGSN No

Domain selection:

CS/PS/IMS


Figure 10-28 MT SMS over generic IP-CAN

The SMS-SC forwards the SM to the SMS-GMSC.

The SMS-GMSC interrogates the HSS to retrieve routeing information.

The HSS forwards the request to the IP-SM-GW.

If the IP-SM-GW has no information related to the MSISDN of the destination UE, the IP-SM-GW queries the HSS for routing information.

The HSS returns the addresses of the current MSC and/or SGSN (MSC No /

SGSN No) to the IP-SM-GW for delivery of the SM in CS/PS domain.

The IP-SM-GW returns its own address to the SMS-GMSC that originated the routing information query.

SMS-GMSC delivers the SM to IP-SM-GW, in the same manner that it delivers the SM to an MSC or SGSN.

The IP-SM-GW performs domain selection function to determine the preferred domain for delivering the message according to operator policy and user preferences.

If the preferred domain is IMS, the IP-SM-GW forwards the SM encapsulated in the appropriate SIP method towards the S-CSCF.

The S-CSCF forwards the encapsulated SM to the UE.

253



White board c ommunication

So far, there has not been an easy way to electronically communicate via free format communication. But this drawback is over come with the white board application. The person in this scenario is actually handwriting a message when a friend initiates a video call to her/him. This way of creating a message in a native language including symbols and pictures makes the communication more personal than a regular e-mail whether in Chinese,

Japanese, English, French or any language.

The users can draw on a blank background, or select to share an image as the background for drawing, e.g. a map or a floor plan of a building. Both users can edit the drawing, and both users get to see the complete content. They can individually store the session content at any time. white board session

I-CSCF

HSS

P-CSCF

S-CSCF speech session

Figure 10-29 White board communication

White board communication is usually implemented as a peer-to-peer solution only using the common IMS nodes (i.e. the AS are not necessary).

Voice Call Continuity ( VCC

Voice Call Continuity (VCC) is an IMS application that provides capabilities to transfer voice calls between the CS domain and the IMS.

The solution requires UE capability to simultaneously signal on two different radio access technologies, e.g. PS eUTRAN and CS GERAN/UTRAN.

All domain transfers associated with a VCC sessions are initiated by the VCC

UE and executed and controlled by the VCC application in the home IMS, where all the calls from and to a VCC UE are anchored.

254


10 Services

When the VCC UE determines that domain transfer is desirable and possible, a new call context is established by the VCC UE toward the VCC application in the home IMS. Signalling and bearer resources are allocated in the transferring-in domain and the user’s active session is transferred from the transferring-out domain. Resources in the transferring-out domain are subsequently released.

MGCF

I-CSCF

HSS GMSC

MSC gsmSCF

S-CSCF

VCC app P-CSCF

VCC UE

Figure 10-30 VCC architecture

The CS originating voice calls of a VCC UE are re-routed using CAMEL to the user's home IMS network for anchoring in IMS. The UE establishes the call using standard call origination procedures; CAMEL origination triggers at the VMSC then invoke signalling towards the gsmSCF. As a part of the

CAMEL dialogue, the gsmSCF instructs the VMSC to route the call towards the IMS, where the call is anchored in VCC application.

Fig. 10-31 gives the general overview of the MO call setup for a VCC user initiated call from CS domain.

VCC UE

CS RAN gsmSCF

MSC media

A

MGCF

MGW

VCC app S-CSCF

Figure 10-31 MO CS call from the VCC user

B

VCC UE call origination from IMS domain utilises existing MO. Originating initial Filter Criteria (iFC) in S-CSCF for the VCC user results in routing of the IMS originating sessions to the VCC application, that initiates a call to the remote party on behalf of the user.

255



VCC UE

IP-CAN

P-CSCF S-CSCF media

VCC app

A

B

Figure 10-32 MO IMS call from the VCC user

Voice calls to VCC subscribers coming from the IMS or the CS domain are anchored in the IMS to facilitate domain transfer and may finally be delivered to the UE via the IMS or the CS domain. For the calls to be delivered to CS domain the VCC application, optionally in collaboration with HSS, provides

CS domain Routing Number (CSRN), which is used to reach the VCC UE while roaming in CS domain.

HSS

A

SIP/TEL

URI

VCC app

S-CSCF

CSRN

VCC UE

CS media

Figure 10-33 VCC MT call directed to CS domain

B

A

SIP/TEL

URI

VCC app

S-CSCF media

P-CSCF

IP-CAN

Figure 10-34 VCC MT call directed to IMS

VCC UE

B

Domain transfer procedures enable voice continuity between CS domain and

IMS while maintaining an active voice session when using a VCC UE.

Upon detection of conditions requiring domain transfer, the UE establishes an

Access Leg with the VCC application via the transferred-in domain to request domain transfer to the transferred-in domain. The VCC application executes

256


10 Services the Domain Transfer procedure by replacing the Access Leg currently communicating to the Remote Leg with the Access Leg established via the transferred-in domain. The Access Leg established via the transferred-out domain is subsequently released. When the switch of the Access leg from the transferred-out domain to the transferred-in domain is executed, the Remote

Leg is also updated in order to forward the U-Plane data to the transferred-in domain.

The execution of the Domain Transfer procedure consists of the following basic steps:

The UE establishes an Access Leg via the transferred-in domain after registering with the transferred-in domain as needed.

The VCC application performs the Access Leg Update to switch the

Access Leg communicating with the Remote Leg from transferred-out domain to transferred-in domain. If the remote party is IMS capable, the U-plane path is switched end-to-end (i.e. between UEs). And if the remote party is

CS/PSTN, U-plane path is switched between VCC UE and MGW. It means

MGW becomes the U-plane anchor point, even if both sides are in CS domain. The VCC UE switches the voice traffic from the transferred-out domain to the transferred-in domain as soon as the Access Leg in the transferred-in domain is fully established.

Both the VCC UE and the VCC application release the source Access Leg, which is the Access Leg previously established via the transferred-out domain. vMSC

CS radio

MGCF

MGW

VCC app

S-CSCF

IMS

VCC UE

IP-CAN

IP-CAN switched end-to-end

VCC UE

Figure 10-35 User plane path between VCC UE and IMS UE

257


LTE/EPS Technology vMSC

MGCF#1

MGW#1

VCC app

S-CSCF

IMS

MGCF#2

MGW#2

CS net

CS UE

CS radio IP-CAN switched at MGW

VCC UE

Figure 10-36 User plane path between VCC UE and CS UE/PSTN 2

IMS to CS domain transfer

Fig. 10-37 provides an information flow for Domain Transfer of voice calls made using VCC UE in IMS to CS domain direction. The flow is based on the precondition that the user is active in an IMS voice originating or terminating session at the time of initiation of Domain Transfer to CS.

VCC UE

MSC MGCF I-CSCF S-CSCF VCC app

Setup (VDN)

IAM

INVITE

INVITE

Access

Leg Update

Figure 10-37 Domain transfer – IMS to CS domain

Source

Access Leg

Release

If the user is not attached to the CS domain at the time when the UE determines a need for Domain Transfer to CS, the UE performs a CS Attach.

It subsequently originates a voice call in the CS domain using the VCC

Domain Transfer Number (VDN) to establish an Access Leg via the CS domain and request Domain Transfer of the active IMS session to CS

Domain. A VDN is a public telecommunication number (i.e. it has a structure

2 MGW#1 and MGW#2 may be merged.

258


10 Services of the ISDN telephone number) configured into the UE during initial provisioning.

The MSC routes the call towards the user's home IMS network via an

MGCF in the home network.

The MGCF initiates an INVITE towards the I-CSCF in the home IMS of the originating VCC user.

The I-CSCF routes the INVITE directly or via S-CSCF to the VCC

Application.

The VCC performs the Domain Transfer by updating the Remote Leg with the connection information of the newly established Access Leg using the

Access Leg Update.

The source Access Leg (which is the Access Leg previously established over IMS) is released.

CS to IMS domain transfer

Domain transfer from CS to IMS domain is triggered by the VCC UE that establishes the IMS call towards VCC application by addressing INVITE message to Session Transfer Identifier (SDI). An SDI is a Tel URI (i.e. it has a structure of the SIP address) configured into the UE during initial provisioning.

VCC UE

S-CSCF VCC app

INVITE (VDI)

INVITE (VDI)

Access

Leg Update

Source

Access Leg

Release

Figure 10-38 Domain transfer – CS to IMS domain

When the UE determines a need for domain transfer, the UE initiates registration with IMS. It subsequently initiates an IMS originated session toward the VCC Application using a VCC Domain Transfer URI (VDI) to establish an Access Leg via IMS and request Domain Transfer of the active

CS session to IMS. A VCC Domain Transfer URI (VDI) is a SIP URI configured into the UE during initial provisioning.

259



The IMS session is processed at the S-CSCF and delivered to the VCC

Application.

The VCC Application completes the establishment of the Access Leg via

IMS and performs the Domain Transfer by updating the Remote Leg with connection information of the newly established Access Leg.

The source Access Leg which is the Access leg previously established over

CS is subsequently released.

Single Radio VCC (SR VCC)

Single Radio Voice Call Continuity (SRVCC) is an IMS application that provides capabilities to transfer voice calls between the CS domain and the

IMS, that does not require UE capability to simultaneously signal on two different radio access technologies.

In SRVCC RAT change and domain selection is under network control.

The following figure only shows the necessary components related to

SRVCC.

SRVCC

UE

GERAN/

UTRAN

MSC

SGSN

MSC server

SRVCC enhanced

Sv HSS

MME

IMS

E-UTRAN S-GW/P-GW

SRVCC

UE

Figure 10-39 SRVCC architecture

260


10 Services

MSC s erver enhanced for SRVCC

In addition to the standard MSC server behavior, an MSC server which has been enhanced for SRVCC provides the following functions:

•

Handling the Relocation Preparation procedure requested for the voice component from MME via Sv interface,

•

Invoking the session transfer procedure from IMS to CS,

•

Coordinating the CS Handover and session transfer procedures,

•

Handling the MAP_Update_Location procedure without it being triggered from the UE.

If the MME supports the interworking to 3GPP CS, the MME in addition to the standard MME behaviour provides the following functions:

•

Performing the PS bearer splitting function by separating the voice PS bearer from the non-voice PS bearers.

•

Handling the non-voice PS bearers handover with the target cell,

•

Initiating the SRVCC handover procedure for handover of the voice component to the target cell via the Sv interface. This procedure is only triggered once regardless of the number of voice bearers (i.e.

QCI=1) that are in use by the UE.

•

Coordinating PS handover and SRVCC handover procedures when both procedures are performed.

If the SGSN supports the interworking to 3GPP CS (e.g. from HSPA to

UTRAN/GERAN), the SGSN in addition to the standard SGSN behaviour provides the following functions:

•

Performing the PS bearer splitting function by separating the voice PS bearer from the non-voice PS bearers. VoIP is detected by traffic class=conversational and SSD='speech'.

•

Handling the non-voice PS bearers handover with the target cell.

•

Initiating the SRVCC handover procedure for handover of the voice component to the target cell via the Sv interface.

•

Coordinating PS handover and SRVCC handover procedures when both procedures are performed.

261



3GPP SRVCC UE is needed to perform SRVCC.

The SRVCC UE indicates to the network that the UE is SRVCC capable when being configured for using IMS speech service supported by the home operator and the operator policy on the SRVCC UE does not restrict the session transfer.

Between UE and E-UTRAN, no additional functionality is required for the

E-UTRAN. When E-UTRAN selects a target cell for SRVCC handover, it needs to send an indication to MME that this handover procedure requires

SRVCC. E-UTRAN may be capable of determining the neighbour cell list based on the ‘SRVCC operation possible’ indication and/or presence of established QCI=1 bearers for a specific UE.

When HSPA capable UTRAN selects a target cell for SRVCC handover, it needs to send an indication to SGSN that this handover procedure requires

SRVCC.

UTRAN may be capable of determining the neighbour cell list based on the

‘SRVCC operation possible’ indication and/or presence of established voice bearers (i.e. bearers with Traffic Class = Conversational and Source Statistic

Descriptor = 'speech') for a specific UE.

The SRVCC STN-SR and MSISDN are downloaded to MME from HSS during E-UTRAN attach procedure.

The Session Transfer Number for Single Radio Voice Call Continuity (STN-

SR) is a public telecommunication number (E.164) and is used by the MSC

Server to request session transfer of the media path from the PS domain to CS domain.

262


10 Services

UTRAN Attach procedure for SRVCC

E-UTRAN attach procedure for 3GPP SRVCC UE is performed as ordinary

E-UTRAN attach with the following additions:

•

SRVCC UE includes the SRVCC capability indication as part of the

UE Network Capability in the Attach Request message. MME stores this information for SRVCC operation.

•

SRVCC UE includes the GERAN Classmark (if GERAN access is supported) in the Attach Request message.

•

If the subscriber is allowed to have SRVCC in the VPLMN then HSS includes SRVCC STN-SR and MSISDN in the Insert Subscriber Data message to the MME.

•

MME includes a ‘SRVCC operation possible’ indication in the S1 AP

Initial Context Setup Request, meaning that both UE and MME are

SRVCC-capable.

UTRAN to GERAN

Fig. 10-40 gives the general overview of the User and Control Plane paths towards the SRVCC mobile during domain transfer.

SRVCC

UE

GERAN MSC MGW

IMS

E-UTRAN S/P-GW

SRVCC

UE

Figure 10-40 User Plane path (SRVCC)

Depicted in Fig. 10-41 is a call flow for SRVCC from E-UTRAN to

GERAN. It is assumed that the GERAN network is not supporting Dual

Transfer Mode (DTM), hence the non-voice PS bearers have to be suspended.

It is further assumed that the MSC server enhanced for SRVCC controls the target BSS, so the functions of the MSC server enhanced for SRVCC are

263


LTE/EPS Technology merged with those of the target MSC. In case another MSC controls the target

BSS, the MSC-MSC handover is executed.

E-UTRAN MME

MSCs/

MGW

❶ Mes. Report

❷ HO Required

❸ PS to CS Req

SGSN

❹ HO Request/Ack

GERAN S-GW

❺ Initiation of Session Transfer (STN-SR)

❿ HO from

EUTRAN Cmd

❾ HO Command

❽ PS to CS Rsp

⓫ HO Detection

⓬ Suspend

⓬ Suspend Request/Response

⓮ PS to CS

Com./Ack.

⓬ Suspend

⓬ Update bearer

⓭ HO Complete

⓯ Upd.

Loc.

HSS

IMS

❻ Session Transfer and

Update remote end

❼ Release of IMS access leg

Figure 10-41 SRVCC from E-UTRAN to GERAN (without DTM)

❶ UE sends measurement reports to E-UTRAN.

❷ Based on UE measurement reports the source E-UTRAN decides to trigger an SRVCC handover to GERAN. E-UTRAN sends Handover Required

(target cell identifier, SRVCC handover indication and some other parameters to be transparently sent from E-UTRAN to GERAN) message to the source

MME.

❸ Based on the QCI associated with the voice bearer (QCI=1) and the

SRVCC handover indication, the source MME splits the voice bearer from the non voice bearers and initiates the PS-CS handover procedure for the voice bearer only towards MSC Server. The MME sends a SRVCC PS to CS

Request (STN-SR, MSISDN, MM Context) message to the MSC Server. The

MSC server is selected based on the target cell identifier received in the

Handover Required message. The MME received STN-SR and MSISDN from the HSS as part of the subscription profile downloaded during the

E-UTRAN attach procedure. The MM Context contains security related information. CS security key is derived by the MME from the E-UTRAN/EPS domain key.

❹ MSC server performs resource allocation with the target BSS by exchanging Handover Request/ Acknowledge messages.

264


10 Services

❺ MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP IAM (STN-SR) message towards the IMS. Standard IMS

Service Continuity procedures are applied for execution of the Session

Transfer.

❻ During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point.

❼ Source IMS access leg is released.

❽ MSC Server sends a SRVCC PS to CS Response message (description of resources already allocate din GERAN )to the source MME. Source MME knows that at the end of the PS-CS handover the non-GBR bearers should be preserved.

❾ MME sends a Handover Command message to the E-UTRAN. The message includes information about the voice component only.

❿ E-UTRAN sends a Handover from E-UTRAN Command message to the

UE.

⓫ UE tunes to GERAN and Handover Detection at the GERAN occurs.

⓬ UE starts the Suspend procedure. This triggers the SGSN to send a

Suspend Request message to the MME. The MME returns a Suspend

Response to the SGSN, which contains the MM and PDP contexts of the UE.

The MME also starts the preservation of non-GBR bearers and the deactivation of the voice bearer.

⓭ GERAN sends a Handover Complete message to the MSC.

⓮ MSC Server sends a SRVCC PS to CS Complete Notification message to the source MME, informing it that the UE has arrived on the target side.

Source MME acknowledges the information by sending a SRVCC PS to CS

Complete Acknowledge message to the MSC Server.

⓯ MSC Server may perform a MAP Update Location to the HSS/HLR if needed. This may be needed for MSC Server to receive GSM Supplementary

Service information and routing of mobile terminating calls. This Update

Location is not initiated by the UE

After the CS voice call is terminated and if the UE is still in GERAN, then the

UE resumes PS services by sending a Routeing Area Update Request message to the SGSN.

265




266


11 CSFB and SMSoSGs

Chapter 11

Introduction.................................................................................................... 269

Architecture.................................................................................................... 270

Co-existence with IMS .................................................................................. 271

Attach procedure ............................................................................................ 273

TA/LA update procedure ............................................................................... 275

Mobile Originating call.................................................................................. 277

Mobile Terminating Call................................................................................ 279

SMS................................................................................................................ 282


267



268



The CS FallBack (CSFB) in EPS enables the provisioning of voice and other

CS-domain services (e.g. CS UDI video, LCS, USSD) by reuse of CS infrastructure when the UE is served by E-UTRAN. A CSFB enabled terminal, connected to E-UTRAN may use GERAN or UTRAN to connect to the CS-domain. This function is only available in case E-UTRAN coverage is overlapped by either GERAN coverage or UTRAN coverage.

CS domain service

GERAN

/UTRAN

HO or cell reselection

Paging or Service Request

MSC server

SGs

CS network

E-UTRAN MME

CS-domain service examples:

• voice,

• CS UDI video,

• LCS,

• USSD

Figure 11-1 CS FallBack (CSFB)

This chapter also describes the architecture required for SMS over SGs

(MME–MSC interface). The MO SMS and MT SMS are signalled over SGs and do not cause any CS Fallback to GERAN/UTRAN RATs, and consequently does not require any overlapped GERAN/UTRAN coverage.

MSC server

HSS

SMS-IWMSC/

SMS-GMSC

SMS

SMS-SC

SGs

E-UTRAN MME

Figure 11-2 SMS over SGs

269



The CSFB and SMS over SGs in EPS function is realized by using the SGs interface mechanism between the MSC Server and the MME.

GERAN

UTRAN

MSC

server

Gs

SGSN

S3

Sv SGs

E-UTRAN

MME

Figure 11-3 CS Fallback and SMS over SGs architecture

SGs is an interface between the MME and MSC server. It is used for the

Mobility Management (MM) and paging procedures between EPS and CS domain, and is based on the Gs (VLR-SGSN) interface procedures. The SGs reference point is also used for the delivery of both Mobile Originating and

Mobile Terminating SMS (MO-SMS and MT-SMS).

S3 is an interface between MME and SGSN. It has additional functionality to support CSFB with ISR.

MME

SGsAP

SCTP

IP

L2

L1

MSC server

SGsAP

SCTP

IP

L2

L1

Figure 11-4 SGs protocol stack

270



SGs Application Part (SGsAP) protocol is used to connect an MME to an

MSC Server. SGsAP is based on the BSSAP+ protocol, used earlier on Gs

(SGSN-VLR) interface.

Stream Control Transmission Protocol (SCTP) transfers signalling messages.

For UE originating calls, the UE performs access domain selection. The service domain selection functionality decides whether the call is serviced in the CS domain or the IMS. Service domain selection functionality may take into account for originating calls whether the user is roaming or not, user preferences, service subscription and operator policy. If the UE is configured for Voice over IMS, the service domain selection functionality takes the ‘IMS voice over PS session supported indication’ into account and should only initiate IMS voice calls (with the voice bearer in the PS domain) using the

RAT where the ‘IMS voice over PS session supported indication’ applies and indicates support. The "IMS voice over PS session supported indication" applies to E-UTRAN when received in E-UTRAN, and applies to UTRAN when either received in GERAN or UTRAN.

IMS voice over PS session supported indication

Attach accept / RAU Accept

SGSN

IMS voice over PS session supported indication

Attach accept / TAU Accept

MME

EPS attach result: EPS only / combined EPS/IMSI attach

Additional result: - / CSFB not preferred / SMS only

Figure 11-5 IMS voice over PS session supported indication

271



To allow for appropriate domain selection, the CSFB and IMS capable UE in

E-UTRAN can be provision with the HPLMN operator preferences on how a

CSFB/IMS enabled UE is supposed to handle vice services:

•

CS Voice only: the UE does not attempt to initiate voice sessions over

IMS using a PS bearer. The UE attempts combined EPS/IMSI attach.

•

CS Voice preferred, IMS PS Voice as secondary: the UE tries preferably to use the CS domain to originate and terminate voice calls.

The UE attempts combined EPS/IMSI attach and if combined

EPS/IMSI attach fails for the CS domain or succeeds with an SMS only indication or succeeds with a CSFB Not Preferred indication, the

UE attempts voice over IMS.

•

IMS PS Voice preferred, CS Voice as secondary: the UE tries preferably to use IMS to originate and terminate voice sessions. If the

UE fails to use IMS for voice e.g. due to ‘IMS voice over PS session supported indication’ indicates voice is not supported, then the services are provided using CS domain. The UE can either perform combined EPS/IMSI attach or EPS attach when attaching to

E-UTRAN.

•

IMS PS Voice only: the UE does not attempt combined EPS/IMSI attach (to support voice services) and perform IMS registration indicating support for voice.

A CSFB/IMS enabled UE may behave in either a ‘Voice centric’ or ‘Data centric’ way:

•

UE acting in a ‘Voice centric’ way always tries to ensure that Voice service is possible. A CSFB/IMS enabled UE acting in a ‘Voice centric’ way that cannot obtain IMS voice over PS session service, selects a cell of any RAT that provides access to the CS domain. In this case, when CSFB is not supported in the network, the UE camps only on RATs that provides access to the CS domain (e.g. GERAN and UTRAN) and disable E-UTRAN capability.

Upon receiving combined EPS/IMSI attach accept with ‘SMS only’ indication or with ‘CSFB Not Preferred’ indication, a voice centric UE that fails to use IMS reselects to another RAT.

•

UE acting in a ‘Data centric’ way always tries to ensure it gets PS data connectivity, e.g. the UE stays in the current RAT for PS data connectivity even when voice service is not obtained. A CSFB/IMS enabled UE acting in a ‘Data centric’ way that cannot obtain IMS voice over PS session service in EPS, continues to stay in EPS even when the EPS does not support CSFB.

272



Upon receiving combined EPS/IMSI attach accept with ‘SMS only’ indication, a data centric UE stays in the current RAT.

Upon receiving combined EPS/IMSI attach accept with ‘CSFB Not

Preferred’ indication, a data centric stays in the current RAT and is allowed to use CSFB.

• CS Voice only

• CS Voice preferred, IMS PS Voice as secondary

• IMS PS Voice preferred, CS Voice as secondary

• IMS PS Voice only

• Voice centric

• Data centric

Figure 11-6 UE configuration (domain selection)

If a UE is configured to use SMS over IP services it shall, if registered to

IMS, send SMS over IMS, even if it is EPS/IMSI attached.

The home operator is able to activate/deactivate the UE configuration to use

SMS over IP by means of device management in order to allow alignment with HPLMN support of SMS over IP.

The attach procedure for the CS fallback and SMS over SGs in EPS is realized based on the combined GPRS/IMSI Attach procedure specified earlier for the Gs interface.


273


MME MSC/VLR HSS

Attach Request

Security procedures, registration and bearer establishment as in ordinary attach procedure.

Attach Accept

VLR number derivation

Location Update Req.

SGs association creation

Location Update Accept

Location Update in CS domain

Figure 11-7 Attach procedure

The UE initiates the attach procedure by the transmission of an Attach

Request. message to the MME. The Attach Type parameter indicates that the

UE requests a combined EPS/IMSI attach and informs the network that the

UE is capable and configured to use CS fallback. If the UE needs SMS service but not CSFB, the UE includes an ‘SMS-only’ indication.

Security procedures, registration and default bearer establishment as in ordinary EPS Attach procedure.

The MME allocates a default LAI, which is configured on the MME and may take into account the current TAI and/or E-CGI and whether the IMSI attach is for both CSFB and SMS, or for SMS only. The MME derives a VLR number based on the allocated LAI and IMSI. The MME starts the location update procedure towards the new MSC/VLR upon receipt of the subscriber data from the HSS in step .

The MME sends a Location Update Request (new LAI, IMSI, MME IP address, Location Update Type) message to the VLR.

The VLR creates an association with the MME by storing MME address.

The VLR performs Location Updating procedure in CS domain.

The VLR responds with Location Update Accept (TMSI) to the MME.

The EPS Attach procedure is completed. Attach Accept message includes

LAI and TMSI. The existence of LAI and TMSI indicates successful attach to

CS domain.

If the UE requests combined EPS/IMSI Attach Request without the

‘SMS-only’ indication, and if the network supports only SMS over SGs, the network performs the IMSI attach and the MME indicates in the Attach

Accept message that the IMSI attach is for SMS only.

274



When the network accepts a combined EPS/IMSI attach without limiting to

‘SMS-only’, the network may provide a ‘CSFB Not Preferred’ indication to the UE.

TA/LA u pdate procedure

The combined TA/LA Update procedure for the CSFB and SMS over SGs in

EPS is realized based on the combined RA/LA Update procedure specified in earlier for the Gs interface. new MME old MME MSC/VLR HSS

UE determines to perform TAU.

TAU Request

Security procedures, MME / S-GW reallocation, bearer modification as in ordinary TAU.

Location Update Request

Location Update Accept

Location Update in CS domain

TAU Request

TAU Complete

Figure 11-8 Combined TA/LA update

The UE detects a change to a new TA by discovering that its current TAI is not in the list of TAIs that the UE registered with the network.

The UE initiates the TAU procedure by sending a TAU Request. The

Update Type indicates that this is a combined Tracking Area/Location Area

Update Request or a combined Tracking Area/Location Area Update with

IMSI attach Request. If the UE needs SMS service but not CSFB, the UE include an ‘SMS-only’ indication in the combined TA/LA Update procedure.

Security procedures, possible MME and S-GW reallocation and bearer modification as in ordinary EPS TAU procedure.

If there is an associated VLR in the MM context, the VLR also needs to be updated. If the association has to be established or if the LA changed, the new

MME sends a Location Update Request (new LAI, IMSI, MME IP address,

Location Update Type) message to the VLR. New LAI is determined in the

MME based on the received GUTI from the UE. If this GUTI is mapped from

275


LTE/EPS Technology a P-TMSI/RAI, the LAI is retrieved from the GUTI without any modification by the MME. Otherwise, the MME allocates a default LAI, which is configured on the MME and may take into account the current TAI or E-CGI and whether the IMSI attach is for both CSFB and SMS, or for SMS only.

The MME retrieves the corresponding VLR number from the determined

LAI. If multiple MSC/VLRs serve this LAI an IMSI is used to retrieve the

VLR number for the LAI.. The Location Update Type indicates normal location update.

The VLR performs Location Update procedure in CS domain.

The VLR responds with Location Update Accept (TMSI) to the MME.

The MME sends a TAU Accept (LAI, TMSI) message to the UE. The

TMSI is optional if the VLR has not changed. The presence of the LAI indicate to the UE that it is IMSI attached. If the UE requests combined

TA/LA Update Request without the ‘SMS-only’ indication, and if the network supports SGs for SMS only, the network performs the IMSI attach and the

MME indicates in the TAU Accept message that the IMSI attach is for SMS only.

The UE may send a TAU complete message for the TAU procedure if the

LAI/TMSI has been changed.

When the UE is camped on E-UTRAN, periodic LA updates are not performed, but periodic TA updates are performed. In this case, an SGs association is established and the MSC/VLR disables implicit detach for

EPS-attached UEs and instead rely on the MME to receive periodic TA updates.

276



Mobile O riginating call

The procedure for MT call is illustrated in Fig. 11-9. eNB/BSS/RNS MME MSC SGSN S-GW

Extended Service Request

S1AP Request with CSFB ind.

Optional Measurement Report solicitation

PS HO / CCO optionally with NACC / connection release with redirection to GERAN/UTRAN

CM Service Request

CM Service Reject

LA update or combined LA/RA update if the MSC is changed and no implicit loc. upd.

CS call establishment procedure

RA update (if necessary)

Figure 11-9 MO call

The UE sends an Extended Service Request (CS Fallback Indicator) to

MME. CS Fallback Indicator indicates MME to perform CS Fallback. The UE only transmits this request if it is attached to CS domain (with a combined

EPS/IMSI Attach) and can not initiate an IMS voice session (because e.g. the

UE is not IMS registered or IMS voice services are not supported by the serving IP-CAN, home PLMN or UE).

The MME sends an S1-AP Request message to eNB that includes a CS

Fallback indicator. This message indicates to the eNB that the UE should be moved to UTRAN/GERAN.

The eNB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN cell to which PS handover will be performed.

If the UE and the network support inter-RAT handover from E-UTRAN to

GERAN/UTRAN, the eNB triggers PS handover to a GERAN/UTRAN neighbour cell by sending a Handover Required message to the MME.

277



If the UE and the network support inter-RAT Cell Change Order (CCO) to

GERAN and the target cell is GERAN, the eNB triggers an inter-RAT CCO

(optionally with NACC).

If the UE or the network does not support inter-RAT handover from E-

UTRAN to GERAN/UTRAN nor inter-RAT CCO, the eNB triggers connection release with redirection to GERAN/UTRAN instead of PS HO or

COO.

The UE establishes CS signalling connection in the target RAT and sends

CM Service Request message. The simultaneous support of packet data bearers depends on selected RAT and additional features like e.g. DTM.

In case the MSC serving the 2G/3G target cell is different from the MSC that served the UE while camped on E-UTRAN, the MSC rejects the service request, if implicit location update is not performed. The CM Service Reject triggers the UE to perform a Location Area Update as follows:

•

If the target system operates in Network Mode of Operation (NMO) I the UE performs a combined RA/LA update. In this case, the SGSN establishes a Gs association with the MSC/VLR, which replaces the

SGs association with the MME.

•

If the target system operates in NMO II or III the UE performs a LA update towards the MSC. In this case, the MSC releases the SGs association with the MME.

The UE initiates the CS call establishment procedure.

The UE may trigger the RA update procedure when the sending of uplink packet data is possible.

278



The procedure for MT call is illustrated in Fig. 11-10. eNB/BSS/RNS MME MSC SGSN S-GW

IAM

CS page

Extended Service Request

S1AP Request /

S1AP Initial UE Context Setup

Optional Measurement Report solicitation

PS HO / CCO optionally with NACC / connection release with redirection to GERAN/UTRAN

LA update or combined LA/RA update

Paging Response

Connection Release / Reject

LA update or combined LA/RA update and Roaming Retry for CSFB

CS connection establishment

Figure 11-10 MT call

The MSC receives an incoming voice call.

The MME receives a CS Paging (IMSI, VLR TMSI, Location Information, optional Caller Line Identification)) message from the MSC over a SGs interface. The TMSI (or IMSI) received from the MSC is used by the MME to find the S-TMSI which is used as the paging address on the radio interface.

If the UE is in Idle mode the MME pages the UE in all the TAs, the UE is registered to.

1

In active mode the MME reuses the existing connection to relay the CS Page to the UE.

The eNB forwards the paging message to the UE. The message contains a suitable UE Identity (i.e. S-TMSI or IMSI) and a CN Domain indicator and

Caller Line Identification if available and needed.

1 This procedure takes place before step deployed.

, immediately after MSC receives MAP_PRN from HSS, if pre-paging is

279



The UE establishes an RRC connection or reuses the existing connection to send an Extended Service Request (CS Fallback Indicator, Reject or Accept) to MME.

MME sends S1AP Initial UE Context Setup or S1AP Request message to eNB that includes CSFB indicator. This message indicates to the eNB that the

UE should be moved to UTRAN/GERAN.

The eNB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN cell to which PS handover will be performed.

If the UE and the network support inter-RAT handover from E-UTRAN to

GERAN/UTRAN, the eNB triggers PS handover to a GERAN/UTRAN neighbour cell by sending a Handover Required message to the MME.

If the UE and network support inter-RAT Cell Change Order (CCO) to

GERAN and the target cell is GERAN, the eNB triggers an inter-RAT CCO

(optionally with NACC).

If the UE or the network does not support inter-RAT handover from E-

UTRAN to GERAN/UTRAN nor inter-RAT CCO, the eNB triggers connection release with redirection to GERAN/UTRAN instead of PS HO or

COO.

If the UE obtains LA/RA information of the new UTRAN/GERAN cell

(e.g. based on the system information or redirection info) and the LA/RA of the new cell is different from the one stored in the UE, it performs a Location

Area Update or a Combined RA/LA procedure if the target system operates in

NMO I

The UE establishes CS signalling connection in the target RAT and sends

Paging Response message 2 . The simultaneous support of packet data bearers depends on selected RAT and additional features like e.g. DTM.

If the MSC that receives the Paging Response is different from the MSC that sent the paging request and if the Location Area Update / Combined

RA/LA Update was not performed in step , the MSC rejects the page response by releasing the A/Iu-cs connection. The BSC/RNC in turn releases the signalling connection for CS domain. The signalling connection release triggers the UE to perform a LA update or Combined RA/LA update.

The LA update triggers the Roaming Retry for CS Fallback procedure, described in the next section.

2 MSC should be prepared to receive a paging response after a relatively long time from when the CS Paging was sent. The BSS should be prepared to receive a Paging Response even when the corresponding Paging Request has not been sent by this BSS.

280



In case the MSC serving the 2G/3G cell is the same as the MSC that served the UE while camped on LTE, it shall stop the paging response timer and establish the CS connection.

MT Roaming Retry Call

MT Roaming Retry Call applies to a MT call while the called mobile is simultaneously moving from an old to a new MSC, if the GMSC, the HLR and the old terminating VMSC support the MT Roaming Retry procedure.

In that case, upon receipt of an ISUP IAM message which was preceeded by a

MAP Cancel Location procedure, the old VMSC instructs the GMSC to resume terminating call procedure by sending a MAP Resume Call Handling

(RCH) message. The GMSC then releases the ISUP connection to the old

VMSC, terminate any open CAP dialogue, and retry the terminating call setup towards the new MSC by sending an additional SRI to the HLR. This second

SRI request leads to obtaining a roaming number from the new MSC towards which the call can then be delivered (possibly after new CAMEL interactions).

The similar procedure is used for Roaming Retry for CS fallback. There are only two differences in this procedure compared to the Mobile Terminating

Roaming Retry Call procedure described earlier. The first difference is that the paging message triggers the CS fallback including a location update in the new RAT. This functionality is already supported in the CS fallback flows for terminating calls and no additional functionality is needed. The second difference is that the UE may send a page response message after receiving

Location Update Accept message. The new MSC ignores or rejects the page response message.

MSC

IAM

RC

H

P

R

N

C

A

N

C

LO

C

IAM

GMSC

SRI

SRI

HSS MME CS

FB

LU

P

IAM

MSC

LU

P

Se tu p

Figure 11-11 Roaming Retry for CS fallback

281



The procedures for SMS over SGs apply only if the UE is EPS/IMSI attached and the CS access domain is chosen by the UE and/or the home PLMN for delivering short messages.

SMS support is based on SGs interface between the MME and the MSC

Server and use of NAS signalling between the UE and the MME, i.e. no CS

Fallback is performed for SMS.

The SMS protocol entities are reused from the existing MS/UE and MSC

2G/3G implementations.

MSC

server

HSS

SMS-IWMSC/

SMS-GMSC

SMS

SMS-SC

SGs

E-UTRAN

MME

Figure 11-12 SMS over SGs

282


12 Acronyms & Abbreviations

AGW

AK

AKA

AMBR

AMF

AMPS

AMR

AAS

ACI

ACK

ACM

ADC

ADSL

AES

AF

ANM

ANSI

APN

ARP

ARQ

AS

ASK

AuC

16QAM

2G

3G

3GPP TR

3GPP

64QAM

A/D

AAA

16 Quadrature Amplitude Modulation

2-nd Generation

3-rd Generation

3GPP Technical Report

3rd Generation Partnership Project

64 Quadrature Amplitude Modulation

Analogue-to-Digital

Authentication Authorisation and Accounting

Adaptive Antenna Systems

Adjacent Channel Interference

Acknowledgement

Address Complete Message

Analogue-to-Digital Converter

Asymmetric Digital Subscriber Line

Advanced Encryption Standard

Application Function

Access Gateway

Anonymity Key

Authentication and Key Agreement

Aggregate Maximum Bit Rate

Authentication Management Field

Advanced Mobile Phone System

Adaptive Multi Rate

Answer Message

American National Standards Institute

Access Point Name

Allocation and Retention Priority

Automatic Repeat Request

Application Server

Amplitude Shift keying

Authentication Centre


283


CAP

CATV

CC

CCCH

CCH

CCO

CDMA

CDR

CGF

CIC

CK

CN

COPS

CP

CPC

CQI

CRC

CRF

CS

CSCF

AUTN

AV

AVP

BCCH

BCH

BD

BER

BGCF

BICC

BPSK

BSC

BSS

BSSAP

BW

C/I

CAMEL

AUthentication TokeN

Authentication Vector

Attribute Value Pair

Broadcast Control Channel

Broadcast Channel

Billing Database

Bit Error Rate

Breakout Gateway control function

Bearer Independent Call Control

Binary Phase Shift Keying

Base Station Controller

Base Station System

BSS Application Part

Bandwidth

Carrier to Interface ratio

Customized Applications for Mobile Network Enhanced Logic

Camel Application Part

Cable TeleVision

Chase Combining / Country Code

Common Control Channel

Common Control Channel

Cell Change Order

Code Division Multiple Access

Charging Data Record

Charging Gateway Function

Circuit Identity Code

Ciphering Key

Core Network

Common Open Policy Service

Cyclic Prefix

Continuous Packet Connectivity

Channel Quality Indicator

Cyclic Redundancy Check

Charging Rules Function

Circuit Switching

Call Session Control Function

284



CSFB

CSRN

CTCH

D/A

DAC

D-AMPS

DBS

CS Fallback

CS domain Routing Number

Common Traffic Channel

Digital-to-Analogue

Digital-to-Analogue Converter

Digital-Advanced Mobile Phone Service

Digital Broadcast Systems

DC

DCCH

Direct Current

Dedicated Control Channel

DCH Dedicated Control Channel

DC-HSPA Dual-Carrier HSPA

DECT Digital Enhanced Cordless Telephony

DPCH

DSL

DSP

DTCH

DTF

DTM

DwPTS

DFT

DHCP

Diffserv

DL

Discrete Fourier Transform

Dynamic Host Configuration Protocol

Differentiated Services

Downlink

DL-PSCH Downlink Physical Shared Channel

DL-SCH Downlink Shared Channel

DM

DNS

DPCCH

Domain Management

Domain Name System

Dedicated Physical Control Channel

Dedicated Physical Channel

Digital Subscriber Line

Digital Signal Processing

Dedicated Traffic Channel

Discrete Fourier Transform

Dual Transfer Mode

Downlink Pilot Time Slot

EARFCN E-UTRA Absolute Radio Frequency Channel Number

EDGE Enhanced Data Rates for GSM/Global Evolution

EEA

EF

EPS Encryption Algorithm

Elementary File eGTP

EIA

EIR

EM evolved GPRS Tunnelling Protocol

EPS Integrity Algorithm

Equipment Identity Register

Element Management

285



E-MBMS Enhanced MBMS

EMS eNB

Element Management System

Evolved NodeB

ENUM

EPC ePDG

EPS

E.164 NUmber Mapping

Evolved Packet Core evolved Packet Data Gateway

Evolved Packet System

EPS-AV

ETSI

EPS – Authentication Vector

European Telecommunication Standard Institute

E-UTRAN Evolved UMTS Terrestrial Radio Access Network

EV-DO Evolution – Data Only

FACH Forward Access Channel

FDD

FDMA

FEC

FFT

Frequency Division Duplex

Frequency Division Multiple Access

Forward Error Correction

Fast Fourier Transform

FIFO

FMC

FQDN

FSK

FTP

GBR

GERAN

GGSN

GMLC

GMSK

Gn/Gp

GPRS

First In, First Out

Fixed-Mobile Convergence

Fully Qualified Domain Name

Frequency Shift keying

File Transfer Protocol

Guaranteed Bit Rate

GSM/EDGE Radio Access Network

Gateway GPRS Support Node

Gateway Mobile Location Center

Gaussian Minimum Shift Keying

SGSN-GGSN interface

General Packet Radio Service

GRE

GSM

GSMA

GTP

Generic Routing Encapsulation

Global System for Mobile Communications

GSM Association

GPRS Tunelling Protocol

GTP-C

GTP-U

GTP Control Plane

GTP User Plane

GUMMEI Globally Unique MME Identifier

GUTI Globally Unique Temporary Identity

286



HARQ

HE

HLR

HO hPCRF

HPLMN

HSDPA

Hybrid Automatic-Repeat Request

Home Environment

Home Location Register

Handover home PCRF

Home Public Land Mobile Network

High Speed Downlink Packet Access

HS-DSCH High Speed Downlink Shared Channel

HSPA High Speed Packet Access

HS-PDSCH High Speed Physical Downlink Shared Channel

HSS Home Subscriber Server

HSUPA High Speed Uplink Packet Access

HTTP

IAM

IASA

ICI

Hypertext Transfer Protocol

Initial Address Message

IETF Administrative Support Activity

Inter-Cell Interference

I-CSCF

IDMA

IEEE

IETF iFC

Interrogating CSCF

Interleaved Division Multiple Access

Institute of Electrical and Electronics Engineers

Internet Engineering Task Force initial Filter Criteria

IFFT

IK

IM

IMEI

Inverse Fast Fourier Transform

Integrity protection Key

Immediate Messages

International Mobile Equipment Identity

IM-MGW IMS - Media Gateway Function

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

IMT

INIT

IP

IP-CAN

International Mobile Telecommunications

Initialisation

Internet Protocol

IP Connectivity Access Network

IP-SM-GW IP-Short-Message-Gateway

IR Incremental Redundancy

ISDN

ISI

Integrated Services Digital Network

Inter Symbol Interference

287



ISIM

ISR

ISUP

ITU

IUA

JCP

K

K

ASME

KDF

KPI

L2

LA

IP Multimedia Services Identity Module

Idle state Signalling Reduction

ISDN User Part

International Telecommunication Union

ISDN User Adaptation

Java Community Process authentication Key

LCS

LIA

LIR

LO

LPF

LTE

LUP

M2PA

M2UA

Access Stratum Management Entity Key

Key Derivation Function

Key Performance Indicator

Layer 2

Location Area

Location Services

Location-Information-Answer

Location-Information-Request

Local Oscillator

M3UA

MAC

MAP

MBMS

MBR

MBSFN

MCC

Low Pass Filter

Long Term Evolution

Location Update

MTP2 Pear-to-pear user Adaptation

MTP2 User Adaptation

MTP3 User Adaptation

Media Access Control / Message Authentication Code

Mobile Application Part

Multimedia Broadcast/Multicast Services

Maximum Bit Rate

Multimedia Broadcast over a Single Frequency Network

Mobile Country Code

MCCH

MCH

Multicast Control Channel

Multicast Channel

MEGACO Media Gateway Control Protocol

MGC Media Gateway Controller

MGCF

MGW

MIMO

MIP

Media Gateway Control Function

Media Gateway

Multiple Input Multiple Output

Mobile IP

288



MTCH

MTP

MT-SMS

MTU

MUX

NACC

NAI

NAP

NAS

NCC

NDC

NE

NGN

NH

NM

NMO

NMS

NMT

NRZ

O&M

MISO

MME

MMEC

MMEGI

MMEI

MNC

MO

Multiple Input Single Output

Mobility Management Entity

MME Code

MME Group ID

MME Identifier

Mobile Network Code

Mobile Originated

MO-SMS Mobile Originated SMS

MRF Media Resource Function

MRFC

MRFP

MRFP

Multimedia Resource Function Controller

Media Resources Function Processor

Multimedia Resource Function Processor

MSC

MSIN

MSISDN

MT

Mobile services Switching Centre

Mobile Station Identification Number

Mobile Subscriber Integrated Services Digital Network

Mobile Terminated

Multicast Traffic Channel

Message Transfer Part

Mobile Terminated SMS

Maximum Transfer Unit

Multiplexing/er

Network Assisted Cell Change

Network Access Identifier

Network Attachment Point

Non-access Stratum Signalling

NH Chaining Counter

National Destination Code

Network Element / Network Entity

Next Generation Network

Next Hop

Network Management

Network Mode of Operation

Network Management System

Nordic Mobile Telephone

Non-Return-to-Zero

Operation & Maintenance

289



PEA

PEP

P-GW

PHICH

PHY

PLMN

PMCH

PMIP

PDCCH

PDCP

PDF

PDG

PDN

PDP

PDSCH

OCS

OFCS

OFDM

OFDMA

OMA

OPEX

OPS

OSS

PAPR

Online Charging System

Offline Charging System

Orthogonal Frequency Division Multiplexing

Orthogonal Frequency Division Multiple Access

Open Mobile Alliance

OPerating EXpenditure

Open Policy Service

Operation & Support System

Peak-to-Average Power Ratio

PAR

PBCH

PCC

Peak-to-Average Ratio

Physical Broadcast Channel

Policy and Charging Control

PCCH Paging Control Channel

P-CCPCH Primary Common Control Physical Channel

PCEF

PCFICH

PCH

PCI

PCM

PCRF

P-CSCF

Policy and Charging Enforcement Function

Physical Control Format Indicator Channel

Paging Channel

Physical Cell Identity

Pulse Code Modulation

Policy Control and Charging Rules Function

Proxy CSCF

Physical Downlink Control Channel

Packet Data Convergence Protocol

Policy Decision Function

Packet Data Gateway

Packet Data Network

Packet Data Protocol / Policy Decision Point

Physical Downlink Shared Channel

Presence External Agent

Policy Enforcement Point

Packet Data Network Gateway

Physical Hybrid ARQ Indicator Channel

Physical Layer

Public Land Mobile Network

Physical Multicast Channel

Proxy Mobile IP

290



RACH

RAN

RAND

RAT

RAU

RB

RCH

RES

RFC

RLC

RNC

ROHC

RRC

RRM

RST

RTP

RTSP

RTT

Rx

S1-AP

PSTN

P-TMSI

PUA

PUSCH

QAM

QCI

QoS

QPSK

RA

PNA

PoC

PRACH

PS

PSI

PSK

PSS

Presence Network Agent

Push-to-talk over Cellular

Physical Random Access Channel

Packet Switching / Presence Service

Public Service Identity

Phase Shift keying

Packet Streaming Service

Public Switched Telephone Network

Packet TMSI

Presence User Agent

Physical Uplink Shared Channel

Quadrature Amplitude Modulation

QoS Class Identifier

Quality of Service

Quadrature Phase Shift Keying

Routing Area

Random Access Channel

Radio Access Network

RANDom challenge

Radio Access Technology

Routing Area Update

Resource Block

Resume Call Handling authentication RESponse

Request For Comments

Radio Link Control

Radio Network Controller

Robust Header Compression

Radio Resource Control

Radio Resource Management

Reset

Real-time Transport Protocol

Real Time Streaming Protocol

Round Trip Time

Receiver

S1 Application Part

291



SAA

SAE

SAR

Server-Assignment-Answer

System Architecture Evolution

Server-Assignment-Request

Service Center

Signalling Connection Control Part

SC

SCCP

S-CCPCH Secondary Common Control Physical Channel

SCF Service Control Function

SC-FDMA Single Carrier – Frequency Division Multiple Access

S-CSCF Serving CSCF

SCTP

SDF

SDH

Stream Control Transmission Protocol

Service Data Flows

Synchronous Digital Hierarchy

SDI

SDMA

SDP

SFN

Session Transfer Identifier

Space Division Multiple Access

Session Description Protocol

Single Frequency Network

SG

SGF

SGs

SGsAP

SGSN

Signalling Gateway

Signalling Gateway function

MME-MSC interface

SGs Application Part

Serving GPRS Support Node

S-GW

SI

Serving Gateway

System Information

SIGTRAN Signalling Transport

SIM Subscriber Identity Module

SIMO

SIP

SISO

Single Input Multiple Output

Session Initiation Protocol

Single Input Single Output

SM

SMC

Short Message / Session-based Messaging

Security Mode Command

SMS Short Message Service

SMS-GMSC SMS Gateway MSC

SMS-IWMSC SMS Interworking MSC

SMSoSGs SMS over SGs interface

SMS-SC

SN

SMS Service Center

Serving Network / Subscriber Number

292



TDD

TDM

TDMA

TEID

TF

TFT

TIN

TISPAN

TMSI

TTI

TX

UA

UAA

UAC

UAL

UAR

UAS

UDI

UDP

UE

SNR

SON

SQN

SRI

SRVCC

SS7

STC

STN-SR

SUA

SYN

TA

TAC

TAI

TAU

TCAP

TCP

Serial Number / Signal-to-Noise Ratio

Self-Organising Network

SeQuence Number

Send Routing Information

Single Radio Voice Call Continuity

Signalling System No. 7

Space-Time Coding

Session Transfer Number for SRVCC

SCCP User Adaptation

Synchronisation

Tracking Area

Tracking Area Code / Type Approval Code

Tracking Area Identity

Tracking Area Update

Transactions Capabilities Application Part

Transmission Control Protocol

Time Division Duplex

Time Division Multiplexing

Time Division Multiple Access

Tunnel Endpoint Identifier

Transport Format

Traffic Flow Template

Temporary Identity used in Next update

Telecoms and Internet converged Services and Protocols for Advanced Nets.

Temporary Mobile Subscriber Identity Number

Transmission Time Interval

Transmitter

User Adaptation

User-Authentication-Answer

User Agent Client

User Adaptation Layer

User-Authentication-Request

User Agent Server

Unrestricted Digital Information

User Datagram Protocol

User Equipment

293



VDI

VDN

VLR

VMSC

VoIP vPCRF

VPLMN

WAP

WARC

WF

WiFi

WiMAX

WLAN

WML

WWW

X2-AP

XDMS

XMAC

XML

XRES

UICC Universal Integrated Circuit Card

UL Uplink

UL-PSCH Uplink Physical Shared Channel

UL-SCH

UMA

UMB

UMTS

Uplink Shared Channel

Unlicensed Mobile Access

Ultra Mobile Broadband

Universal Mobile Telecommunication System

UP

UpPTS

URA

URI

USIM

USSD

UTRAN

V5UA

VCC

User Plane

Uplink Pilot Time Slot

UTRAN Registration Area

Uniform Resource Identifier

UMTS Subscriber Identity Module

Unstructured Supplementary Service Data

UMTS Terrestrial Radio Access Network

V5 User Adaptation

Voice Call Continuity

VCC Domain Transfer URI

VCC Domain Transfer Number

Visited Location Register

Visited MSC

Voice over IP visited PCRF

Visited Public Land Mobile Network

Wireless Application Protocol

World Administrative Radio Conference

Weight Factor

Wireless Fidelity

Worldwide Interoperability Microwave Access

Wireless Local Access Network

Wireless Markup Language

World Wide Web

X2 Application Part

XML Document Management Server eXpected Message Authentication Code

Extensible Markup Language eXpected RESponse

294
