ALU UTRAN Parameters Description.pdf

UMTS Terrestrial Radio Access Network (UTRAN) Parameters Description

Student GuideGuide release: 04.03Guide status: StandardDate: March 2007

3FL12812AAAAWBZZA Ed2

Copyright © 2006 Alcatel-Lucent Networks. All rights reserved.

The information contained in this document is the property of Alcatel-Lucent Networks. Except as specifically authorized in writing by Alcatel-Lucent Networks, the holder of this document shall not copy or otherwise reproduce, or modify, in whole or in part, this document or the information contained herein. The holder of this document shall protect the information contained herein from disclosure and dissemination to third parties and use the information solely for the training of authorized individuals.

THE INFORMATION PROVIDED HEREIN IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND. Alcatel-Lucent NETWORKS DISCLAIMS ALL WARRANTIES, EITHER EXPRESSED OR IMPLIED,INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL Alcatel-Lucent NETWORKS BE LIABLE FOR ANY DAMAGES WHATSOEVER, INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, ARISING OUT OF YOUR USE OR RELIANCE ON THIS MATERIAL, EVEN IF Alcatel-Lucent NETWORKS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Information subject to change without notice.Alcatel-Lucent, Alcatel-Lucent Networks, the Globemark device, and the Alcatel-Lucent Networks logo are trademarks of Alcatel-Lucent Networks.

DescriptionThis course provides the participants with theoretical knowledge of UTRAN Parameters. It describes the main UMTS radio procedures (Measurements, Compressed Mode, Mobility in Idle Mode, Call Admission, Packet Data Management, Power Management, Mobility in Connected Mode, Location Services, HSDPA) and their associated parameters.

This course applies to UA04.02.

Intended audienceThis course is mostly intended for technicians and engineers involved in UMTS activities such as RF Engineering, optimization, Network Design, UTRAN Datafill, Trials and VO.

PrerequisitesThis course has the following prerequisites:

• UMTS System Description (2911A)

• UMTS Radio Interface (3038A)

ObjectivesAfter completing this course, you will be able to:

• describe how parameters are organized,

• describe parameters involved in the main UTRAN procedures,

• evaluate parameter change impacts on live network,

• configure parameters to make UTRAN procedures work efficiently,

• tune the parameters that have a significant effect on the UTRAN behavior.

Course introduction

Overview

ReferencesThe following documents provide additional information:

Access Network Parameters — Volume 1 - RAN Model InformationNTP 411-8111-813P1

Access Network Parameters — Volume 2 - ANode ParametersNTP 411-8111-813P2

Access Network Parameters — Volume 3 - CNode ParametersNTP 411-8111-813P3

Access Network Parameters — Volume 4 - INode ParametersNTP 411-8111-813P4

Access Network Parameters — Volume 5 - BTS ParametersNTP 411-8111-813P5

Access Network Parameters — Volume 6 - OAM ParametersNTP 411-8111-813P6

Access Network Parameters — Volume 7 - POC ParametersNTP 411-8111-813P7

Synchronization in UTRAN3GPP TS 25.402

UTRA High Speed Downlink Packet Access (HSDPA); Overall description 3GPP TS 25.308

Physical layer - general description 3GPP TS 25.201

Physical channels and mapping of transport channels onto physical channels 3GPP TS 25.211

Multiplexing and channel coding3GPP TS 25.212

Spreading and modulation3GPP TS 25.213

Physical layer procedures3GPP TS 25.214

Physical layer; Measurements3GPP TS 25.215

Common test environments for User Equipment (UE); Conformance testing 3GPP TS 34.108

Typical examples of Radio Access Bearers (RABs) and Radio Bearers (RBs) supported by Universal Terrestrial Radio Access (UTRA)3GPP TS 25.993

Channel coding and multiplexing examples 3GPP TS 25.944

UTRAN overall description3GPP TS 25.401

Radio Resource Control (RRC) protocol specification 3GPP TS 25.331

Broadcast/Multicast Control (BMC) 3GPP TS 25.324

Packet Data Convergence Protocol (PDCP) specification 3GPP TS 25.323

Radio Link Control (RLC) protocol specification 3GPP TS 25.322

Medium Access Control (MAC) protocol specification 3GPP TS 25.321

Services provided by the physical layer 3GPP TS 25.302

Radio interface protocol architecture 3GPP TS 25.301

Contents

1. Discover Knowledge Services

2. UTRAN Parameters & Objects

3. UTRAN Configuration

4. Measurements

5. Compressed Mode

6. Mobility in Idle Mode

7. Call Admission

8. Packet Data Management

9. Power Management

10. Mobility in Connected Mode

11. HSDPA

12. Location Based Services

13. Glossary

Publication History

Minor correctionsAugust 200604.03

Correction, modification and update (UA04.02)July 200604.02

Creation (UA04.01+HSDPA) based on former UM015 (UMT/TRD/CN/0021 03.03/EN)

August 200504.01

CommentsDateVersion

1-1

3FL12812AAAAWBZZA Ed2March 2007

Discover Knowledge Services

Section 1

1-2

3FL12812AAAAWBZZA Ed2March 20071-2

Course Objectives

After this course, you will be able to

> describe how parameters are organized,

> describe parameters involved in the main UTRAN procedures,

> evaluate parameter change impacts on live network,

> configure parameters to make UTRAN procedures work efficiently,

> tune parameters that have a significant effect on UTRAN behavior.

1-3


Course Contents

1. Discover Knowledge Services2. UTRAN Parameters & Objects3. UTRAN Configuration4. Measurements5. Compressed Mode6. Mobility in Idle Mode7. Call Admission8. Packet Data Management9. Power Management 10.Mobility in Connected Mode11.HSDPA12.Location Services

1-4

Student notes

2-1


UTRAN Parameters & Objects

Section 2

2-2


Objectives

After this section, you will be able to

> Describe UTRAN parameters organization

> Evaluate impact of parameter modifications

> Describe UTRAN Configuration Management process and tools

2-3


Contents

> UTRAN Configuration Overview

> UTRAN Parameters Organization

2-4

Student notes

2-5


UTRAN Configuration Overview

2-6


UTRAN Configuration Process & Tools

ProvisioningActivities

PlanningActivities

Main Server

Configuration Data

OA&MActivities

ND

RF

IP

ATM

WPS for Access

This process describes how to configure UTRAN Network Elements (NEs) during a deployment phase. The main steps are the following:

• Planning Activities

1. Check UTRAN CIQs consistency

2. Provide neighboring XML files for cell planning

3. Provide last WPS templates and ATM Profile

• Provisioning Activities

1. Generate full configuration with WPS

2. Export XML files from WPS

• Operation Administration & Maintenance Activities

1. Load configuration data into their respective NEs

2. Build the database (MIB) of the RNS and make sure all the local information are up-to-date.

3. Perform real-time adjustments to the initial network configuration.

NoteThese steps do not necessarily apply to other contexts, such as introduction of new features, addition of new NEs, network optimization, …

2-7


Customer Input Questionnaire

CIQ

• RRM Parameters• RRM Parameters• RRM Parameters• …

OperatorTeams

• Network Requirements• Deployment Constraints• ...

• Network System Definition• Engineering rules• Addressing rules• ...

EngineeringTeams

(Core, Local)

• IP Parameters

• IP Parameters

• IP Parameters

• ...

• ATM Parameters• ATM Parameters

• ATM Parameters• …

•Net

work D

esig

n

•Net

work D

esig

n

•Net

work D

esig

n

•…

• RF Parameters

• RF Parameters

• …

The Customer Input Questionnaire is a repository where are stored all parameter values and configuration data required for the later datafill of the UTRAN subsystem.

As mentioned in the document header: "The CIQ is used by the Wireless Network Engineering team, Regional Engineering and deployment personnel to better understand the customer requirements”.

Each manager of a Local Engineering team (in relation with the other activity groups) is in charge of filling his own part of the CIQ along with the operator:

• Radio Frequency (RF) staff fills RF parameters. RF team can also provide XML files coming from any cell planning tool, such as iPlanner

• IP engineering staff fills the IP addresses

• ATM engineering staff fills the ATM parameters…

The UTRAN CIQ template highlights for each parameter to which domain it belongs (Design, IP, ATM…).

At WPS level, the UTRAN datafill engineer is in charge of checking the consistency and completeness of the UTRAN CIQs.

2-8


UTRAN CM Solution Overview

Provisioning OA&M

Engineering Tools

XML Files

OpenInterface

BTSC-NodeI-Node

RNC

Main ServerWPS Access

NodeB

Wireless Wireless –– Network Management SystemNetwork Management System

OffOff --lineline OnOn--lineline

XM

L

For the UMTS Access Network, Wireless-Network Management System provides two complementary sets of configuration tools:

• off-line configuration tool to support network engineering

• on-line configuration tool to support network operations

These two toolkits fully inter-work and provide a consistent user environment for engineering and operations staff.

• Off-line Configuration is designed to support efficient bulk configuration of the UTRAN by engineering staff. Users can import, modify and export data, both from the UMTS access network and from 3 rd party engineering tools (such as iPlanner). Off-line Configuration delivers a seamless network-engineering environment from initial network design through to actual network configuration.

• On-line Configuration has been designed to change the configuration of the UTRAN in real-time. Not adapted to bulk configuration, the On-line configuration mainly concerns specific operations, such as extending the network, adding NEs, …

2-9


UTRAN CM XML Files Exchange

Live Network

WPSWPS

Impo

rt/E

xpor

t

S

S

Impo

rt/E

xpor

t

D

D

WPS Import

WPS Export

XML Snapshots

XML WorkordersMain Server

WPSWPS

WNMS Export

WNMS ImportD

S

At any time during the network building steps, the datafiller can export part of his work towards other platforms.

The following CM (Configuration Management) files can be exported:

• Snapshot,

• Workorder.

According to the option selected, the result of the export will be very different:

• Exporting the current state of the network as a snapshot means merging the elementary operations performed by the workorders with the initial snapshot. As it is said by WPS: “the current planning view is the result of the execution of the workorders on the initial snapshot”.

• Exporting the workorder means gathering all the elementary operations performed upon a snapshot into a CM file for further use (other WPS platforms, W-NMS).

2-10

Student notes

2-11


UTRAN Parameters Organization

2-12


UTRAN Objects Mapping

Hardware Equipment

RNCEquipment

Logical Configuration

NodeB

FDDCell/0

FDDCell/1 BTSCell/1

BTSCell/0

PP15K-IN

RNC

BTSEquipment

PP7K-AN

CN IN

AN

The RAN model is split into two parts:

• Hardware Equipment: This part groups all elements (parameters) that defines the equipment (BTS) and the Passport module (Pmod). It is the physical part of that model.

• Software Configuration: This other part groups all elements that defines theNodeB and RNC logical configuration. It is called “logical part” because it defines the software for logical radio sectors and logical RNC nodes.

To perform a link between the Hardware Equipment (physical part) and the Software Configuration (logical part), it is necessary to link several elements from both parts. For example to link the logical sectors to the physical equipment, the user has to attach a BTSCell (physical part) to one FddCell (logical part). This specific operation is called “Mapping”.

2-13


UTRAN Parameter Domain

RAN ModelBased

InterfaceNode

Access Node

NodeB

MIB

PassportBased

W-NMS

Control Node

WiPS

MIB

Two different types of parameters are designed to configure a UMTS Access Network:

• Control Node, NodeB and RAN parameters.

• Interface Node, Access Node and Passport parameters.

Changing parameters value may impact the behavior of the live network.

For RAN parameters the impact triggered by a parameter modification is strongly linked with the parameter classes (see next slide).

For Passport parameters it is not always easy to predict the impact of a parameter modification. Possible consequences are:

• nothing,

• reset of an interface,

• reset of a module,

• reset of a node.

2-14


RAN Parameter Types

Customer

Manufacturer

Static Configuration

ADDRESSING

OPTIMIZATION

DESIGN

OPERATION

SYSTEM

PRODUCT

Accessible viaOAM GUI

Accessible via command line (WICL)

MainServer

There are two main kinds of parameters in the Alcatel-Lucent system, the static and configuration parameters.

The static parameters have the following characteristics:

• They have a fixed value and cannot be modified at the Access OAM.

• They are part of the network element load.

• A new network element needs to be reloaded and built in order to change their values.

• They cannot be modified by the customer.

The configuration parameters have the following characteristics:

• They are contained in the Access OAM database.

• They are subdivided in two main types:

—Customer: can be modified by the customer at the Access OAM (directly or with XML Configuration Management files).

—Manufacturer: they represent system constants defined by the manufacturer and can only be modified via a Wireless Internet Command Line interface (WICL).

2-15


RAN Attribute Activation Classes

activation classes apply toCustomer and Manufacturer parameters

Class 0

Class 3

Class 2

Class 1 MIB

MIB build required(most common case)

lock/unlock required

reset required

on-line modification allowed

The Parameter activation class defines the behavior of the parameter with respect to the ‘’set online’’ operation:

• Class 0:

The parameter can not be directly modified online. The modification can be performed either by a MIB build or by a deletion and re-creation online of the object it belongs to (when allowed).

• Class 1:

Not available.

• Class 2:

The parameter can be modified online but the operation requires to prior lock the object it belongs to or one of its ancestors.

• Class 3:

The parameter can be directly modified online.

Note

Classes do not apply to Passport parameters.

2-16


RAN Object Activation Classes

Not Allowed

Allowed

Allowed With Lock

Allowed With Parent MIB

MIB build required

lock/unlock required

parent modification required

on-line modification allowed

on-line Creation / Deletion behavior

The object activation class defines the object behavior with respect to the ‘’create online’’ and ‘’delete online’’ operations.

• Not Allowed:

The object can not be created/deleted online, a build is required.

• Allowed With Parent:

The object can be created/deleted online but the operation requires the creation/deletion of the parent.

• Allowed With Lock:

The object can be created/deleted online but the operation requires locking the object or one of its ancestors in the containment tree.

• Allowed:

The object can be created/deleted online.

2-17


RRM Subtree

ConfigurationClassX

InstanceN

Instance...

Instance2

Instance1

ConfigurationClassZ

InstanceN

Instance...

Instance3

Instance2

Instance1

ConfigurationClassY

InstanceN

Instance...

Instance...

Instance3

Instance2

Instance1

RNC

RadioAccessService

DedicatedConf

Radio Resource Management is an essential piece of the RNC controlling the radio resources allocated to the users.

The RadioAccessService object is the root of the RRM architecture. It includes a set of parameters that applies to the whole Radio Network Subsystem.

Some of the parameters of the RRM tree are stored in libraries composed of Configuration Classes and Configuration Classes Instances.

There are 7 Main Configuration Classes, some of them containing some children:

• CacConfClass,

• HoConfClass,

• MeasurementConfClass,

• NodeBConfClass,

• PowerConfClass,

• PowerPartClass,

• PowerCtrlConClass.

Each of these Configuration Class can have a maximum of 5 different instances. Each instance corresponds then to a predefined set of parameters (see example next page).

2-18


Configuration Classes Instantiation

NeighbouringRNCcacConfClassId 0

RNC

RadioAccessService

DedicatedConf

MeasurementConfClass PowerCtrlConfClass CacConfClassHoConfClass

NeighbouringRNC

Example

-50.0maxUlInterferenceLevel

384maxUlEstablishmentRbRate

85firstRlOvsfCodeCacThreshold

CacConfClass/ 0

Configuration Classes are involved in NodeB, FDDCell and NeighbouringRNCconfiguration.

In the example above, we can see that each instance of CacConfClass includes a set of predefined parameters.

Each parameter belonging to the CacConfClass object can take a different value under each instance.

For example, the maxUlInterferenceLevel can take values from -112 dBm to -50 dBmaccording to the selected instance.

These parameters will be taken into account when the Iur are datafilled during WPS sessions.

2-19

Student notes

2-20

Student notes

3-1


UTRAN Configuration

Section 3

3-2


Objectives


> Describe OAM Shared Objects and associated parameters

> Describe RNC configurations and associated parameters

> Describe NodeB configurations and associated parameters

> Describe BTS configurations and associated parameters

3-3


Contents

> OAM Objects Configuration

> RNC Configuration

> NodeB Configuration

> BTS Configuration

3-4

Student notes

3-5


OAM Objects Configuration

3-6


OAM Shared Objects

frequencyBand (Operator)

mobileCountryCode (Operator)

mobileNetworkCode (Operator)

type (Operator)

dlFrequencyList (NodeBCommonParam)

testFrequency (NodeBcommonParam)

ulFrequencyList (NodeBCommonParam)

GSMBandIndicator (RNCCommonParam)

OAM shared objects have no existence outside the OAM tools (above slide shows how these objects are displayed in WPS for Access). They are particularly useful to ease and secure the parameters setting of RAN nodes and sub-components.

The frequencyBand indicates the frequency band supported (UMTS1900 or UMTS).

The mobileCountryCode identifies the country in which the PLMN is located. The value of the mobileCountryCode is the same as the three digit MCC contained in the IMSI.

The mobileNetworkCode identifies the PLMN in that country. The mobileNetworkCode takes the same value as the two or three digit MNC contained inthe IMSI.

The type parameter clarifies the access rights assigned to the operator. Without Utran Sharing (nominal case) the standard type is chosen.

The dlFrequencyList and ulFrequencyList record the listing of applicable UARFCNsin the network for Downlink and for Uplink.

The testFrequency gives the UTRA Absolute Radio Frequency Channel Number of the Down Link Frequency used by the BTS to detect its RF cabling.

The GSMBandIndicator identifies which is the GSM band used in the whole network.

3-7


RNC Configuration

3-8


Identification & Capacity

RNC NodeB

rncId (RNC)

RNC

NodeB

rncId (RNC) NodeB

NodeB

NodeB

NodeB

NodeB

cnodeCapacity (RNC)

The different RNC of the network are simply identified by their rncId under the RNC object.

The capacity of the RNC in terms of number of calls, number of supported BTS and cells depends on two major factors:

• The number of TMUs (hardware configuration)

• The software configuration.

The parameter cnodeCapacity determines the Control Node capacity according to the number of TMUs.

This parameter determines the number of active TMUs taking into account the redundancy rule.

The TMU redundancy rule is N+1 if the number of TMUs < 9 and N+2 otherwise.

3-9


NodeB Configuration

3-10


FDDCell Identifiers

BTSEquipment

Operator (OAM)

FDDCell BTSCell

Logical Objects(3GPP)

Physical Objects(Alcatel-Lucent)

RNC

NodeB

cellId (FDDCell)

rncId (RNC)

ucid (FDDCell)

+

=

localCellId (FDDCell)

The standardization of the Iub interface has pushed Alcatel-Lucent to define an object model based on a logical part and a physical part in order to cope with the multi-vendor configurations:

• The logical part of the equipment (NodeB and RNC) is managed by the OMC-R.

• The physical part of the equipment (BTS) is managed by the OMC-B.

The mapping between the two parts is assured by the localCellId parameter, coded on 28 bits, found under the FDDCell and the BTSCell objects. It is advised to have unique localCellId on the whole network for OAM purpose, to prevent problems during neighboring declaration.

In the UTRAN, the different Cells (part of the NodeBs) are identified uniquely by their ucid.

This ucid contains the identifier of the RNC, the rncId, coded on 12 bits, defined under the RNC object and also the cellId, coded on 16 bits, defined under the FDDCell object.

3-11


Channel Numbers

RNC

ulFrequencyNumber (FDDCell)

Operator (OAM)

dlFrequencyNumber (FDDCell)

FDDCell

NodeBCommonParam

9662-99381930-19909262-95381850-19102

10562-108382110-21709612-98881920-19801 and 3

UARFCNDL (MHz)UARFCNUL (MHz)ITU Region

NodeB

The frequency of a carrier if defined:

• in uplink by the ulFrequencyNumber parameter,

• in downlink by the dlFrequencyNumber parameter.

Both parameters corresponds to the UARFCN (UTRA Absolute Radio Frequency Channel Number) where: UARFCN = 5 * Frequency (MHz).

UTRAN is designed to operate with the following Tx-Rx frequency separation:

• ITU Region 1 & 3; duplex shift = 190 MHz

• ITU Region 2; duplex shift = 80 MHz

But it is possible to have a channel separation which is different from this standard values, due to the channel raster.

The channel raster is 200 kHz, which means that the center frequency must be an integer multiple of 200 kHz.

The nominal channel spacing is 5 MHz, but this can be adjusted to optimize performance in a particular deployment scenario.

3-12


Scrambling Codes

NodeB

primaryScramblingCode (FDDCell)

aichScramblingCode (RACH)

sccpchDlScramblingCode (SCCPCH)

Scrambling code

Channelization code 1



User 1 signal

User 2 signal

User 3 signal

UE is surrounded by BTSs (Base Transceiver Station), all of which transmitting on the same W-CDMA frequency.

It must be able to discriminate between the different cells of different base stations and listen to only one set of code channels. Therefore two types of codes are used:

• DL Channelization CodeThe user data are spread synchronously with different channelization codes. The orthogonality properties of OVSF enable the UE to recover each of its bits without being disturbed by other user channels.

• DL Scrambling CodeScrambling is used for cell identification.

Scrambling Code parameters

The Primary Scrambling Code (P-SC) of each cell it set with the primaryScramblingCode parameter of the FDDCell object. The range of the P-SC must be within 0 to 511. On the Iub interface, the system will convert this value (defined as i) using the following formula: P-SC = 16*i.

When Secondary SC are not in use the aichScramblingCode and the sccpchDlScramblingCode must be set to 0. The 0 value will be defining the AICH Scrambling Code = the Primary SC and the S-CCPCH Scrambling Code = the Primary SC.

3-13


Synchronization

F1F1

F1

F2

F2F2

tCell = 0

tCell = 0

tCell = 3

tCell = 3

tCell = 6

tCell = 6

Twin Cells

tCell (FDDCell)NodeB

The synchronization channels (P-SCH) are transmitted in all cells of a same NodeB. The synchronization bursts need to be separated in time between the cells of a same NodeB on a same carrier.

As defined in the 3GPP recommendations (TS 25.402), tCell is used to skew cells in the same NodeB in order to not get colliding SCH bursts (one SCH burst is a 1/10th

of a slot time).

The tCell parameter avoids to have overlapping P-SCHs in different sectors of a same NodeB. It represents the timing delay relative to BFN used for defining start of SCH, CPICH and DL scrambling code in a cell.

The tCell parameters value (from its respective FDDCell) shall respect the following rules:

• The tCell parameter must be different for the cells which have the same frequency.

• The tCell parameter must be identical for a cell and its twin cell in case of a STSR-2 configuration.

3-14


Neighboring Cells Definition

FDDCell

NodeB

FDDCell

UMTSFddNeighbouringCell/rncId.cellIdGSMNeighbouringCell/ci.lac.mcc/mnc

GsmNeighbour/0

GSMCell/ci.lac.mcc.mnc

primaryScramblingCode (UMTSFddNeighbouringCell)

dlFrequencyNumber (UMTSFddNeighbouringCell)

ulFrequencyNumber (UMTSFddNeighbouringCell)

bcchFrequency (GSMCell)

bcc (GSMCell)

ncc (GSMCell)

RNC

ucidcgi

The information and parameters related to the neighboring cells are contained into two subtrees in the Radio Access Network Model:

• UMTSNeighbouringFDDCell for 3G neighbors,

• GSMNeighbouringCell for 2G neighbors when available.

Each 3G neighboring cell is identified by its ucid.

UMTSFddNeighboringCell objects also store information about the UL and DL frequencies together with the Primary Scrambling Code of the related FDDCell.

Each 2G neighboring cell is identified by its Cell Global Identifier. CGI is a structure of 4 elements: Cell Id, Location Area Code, Mobile Country Code and Mobile Network Code.

GSMCell objects definition also requires the setting of the BCCH Frequency (2G), the Network Color Code and the Base Station Color Code. Some of these parameters are used to derive the Base Station Identity Code (BSIC) which is a local color code that allows a MS to distinguish between different neighboring Base Stations using the same BCCH Frequency. BSIC is a 6 bit length code which is structured in the following way: BSIC = NCC (3 bits) + BCC (3 bits).

3-15


SIB11/DCH Neighboring Lists

Measurement ControlRRC

OR

SI broadcastP-CCPCH

UE

sib11AndDchNeighboringFddCellAlgo (FDDCell)

sib11OrDchUsage (UMTSFddNeighboringCell)

NodeB

SIB11+

DCHDCH

SIB11+

DCH

DCH

DCH

DCH

SIB11+

DCH SIB11+

DCH

SIB11+

DCH

DCH

DCH

DCH

SIB11+

DCHDCH

SIB11+

DCH

SIB11+

DCH

SIB11+

DCHDCH

DCH

DCHDCH

DCH

SIB11+

DCH

FDDCell

DCH

SIB11+

DCH

DCH

DCH

SIB11+

DCHDCH

DCH

An algorithm is used to declare and control correctly the list of neighboring cells, thus allowing to make differentiation between the configuration of idle mode/Cell FACH mode neighbors (sent in SIB11) and cell DCH connected mode neighbors.

The SIB11 neighboring list shall be a subset of the DCH neighboring list. The differentiation is set through the use of the sib11OrDchUsage parameter.

The algorithm used to build SIB11 and RRC Measurement Control, for 3G frequency measurements is set by the value of sib11AndDchNeighbouringFddCellAlgo:

• classic (or unset): no distinction between SIB11 and DCH neighboring lists,

• manual: RNC reads sib11OrDchUsage to compute the neighboring lists,

• automatic: RNC automatically chooses intra-frequency neighboring cells broadcasted in SIB11 (not supported in this release).

The maximum number of neighboring cells broadcasted in SIB11 per FDDCell are:

• 16 UMTS intra-frequency neighbors (not including serving cell),

• 16 UMTS inter-frequency neighbors,

• 16 GSM neighbors.

The maximum number of neighboring cells in cell DCH per FDDCell are:

• 48 UMTS Fdd Cell neighboring with a maximum of:

—32 UMTS intra-frequency neighbors (including serving cell),

—32 UMTS inter-frequency neighbors,

• 32 GSM neighbors.

3-16


Configuration Classes Instantiation

FDDCellpowerPartId 0

RNC

RadioAccessService

DedicatedConf

MeasurementConfClass PowerCtrlConfClass PowerPartConfClass CacConfClassHoConfClassPowerConfClass

FDDCell

Example

0minSignallingPowerRatio

0minDataPowerRatio

0minSpeechPowerRatio

85callAdmissionRatio

PowerPartConfClass/0

Configuration classes have several instances where each instance has its own parameter settings. Once all the configuration classes are defined, each FDDcellbelonging to the RNC has pointers defined by the following parameters:

• powerConfId,

• powerPartId,

• powerCtrlConfId,

• hoConfId,

• cacConfId,

• measurementConfId.

These parameters are designed to identify which instance of the configuration classes the cell is using.

In the example above, we can see that each instance of PowerPartConfClassincludes a set of predefined parameters. Each parameter belonging to the PowerPartConfClass object can take a different value under each instance.

For example, the minSpeechPowerRatio can take values from 0% to 80% according to the selected instance.

3-17


Transmit Diversity

txDiversityIndicator (static)

sttdIndicator (NodeB)

UE RakeCombining

FBI / DPCCH(closed loop)

Different fading channels

Log (distance)

Path loss

Slow fading

Fast fadingSig

nal

leve

l (d

B)

Gain in capacity

Gain in coverage

Transmit diversity duplicates the physical transmission path to increase the downlink capacity.

In Closed Loop Transmit Diversity, the power is equally shared between the 2 transmit antennas.

Space Time Transmit Diversity (STTD) All data sent to both antennas, but reordered/conjugated.

Time Switched Transmit Diversity (TSTD) Used for synchronization only (on P-SCH channels). Antenna alternated transmission at TS rate.

Site Selection Transmit Diversity (SSTD) The 3 first schemes require an additional PA per sector whereas no extra HW module is required for the Site Selection mode.

TxDiv (with additional power amplifier) is also a mean for MCPA redundancy like but also brings signal processing gain. In case of MCPA failure, the cell is reconfigured for operation without TxDiv.

3-18

Student notes

3-19


BTS Configuration

3-20


BTSCell Identifiers

localCellId = 1000rdnId = 0

rdnId = 2localCellId = 1002

rdnId = 1localCellId = 1001

localCellGroupId = 0priority = 1

rdnid (BTSCell)

localCellId (BTSCell)

The localCellId parameter is used to uniquely identify the set of radio resources required to support a cell. Alcatel-Lucent recommends that the localCellId remains unique within the UTRAN (range: [0, 268 435 455])

The rdnId identifies the BTS cell within the BTSEquipment

RdnId allocation:

• rdnId = 0 is allocated to the upper north sector

• consecutive rdnId are allocated clockwise.

3-21


Frequencies

localCellgroupId = 1

localCellid = 1011


localCellid = 1012


localCellid = 1013


localCellid = 1003


localCellid = 1002


localCellid = 1001localCellGroupId (BTSCell)

frequencyBand (BTSEquipment)

testFrequency (BTSEquipment)

F1

F1

F1

F2 F2

F2

STSR-2-6-3

Within a BTSEquipment, all BTSCells using the same frequency carrier shall bear the same localCellGroupId. This localCellGroup is therefore a group of local cells of a BTS associated with the same carrier.

The frequencyBand parameter indicates the frequency band supported (UMTS1900 or UMTS).

The testFrequency parameter corrsponds to the UARFCN (UTRA Absolute Radio Frequency Channel Number of the Down Link Frequency used by the BTS to detect its RF cabling.

The above drawing shows an example of identifier distribution and frequency carrier plans, identified by localCellId and localCellGroupId parameters.

3-22


TRM Defense Mechanism

localCellGroupId 0

frequencyGroupId (localCellGroup) 0

priority (localCellGroup) 1

localCellGroupId 1

frequencyGroupId (localCellGroup) 0

priority (localCellGroup) 2

F1

STSR 2-6-3

TRM-1

Highest priority

F1

F1

F2

F2

F2

TRM-2

localCellGroupId 1

localCellGroupId 1

localCellGroupId 1

localCellGroupId 0

localCellGroupId 0

localCellGroupId 0

A local cell group is a group of local cells associated with the same carrier. There are as many local cell groups as carriers managed by the BTS.

Each BTSCell is linked to a frequency group (frequencygroupId) thanks to the localCellGroupId. Finally one priority level is given to each frequency group.

In the example above, if TRM1 becomes disabled, the BTS will:

• Impact all the cells: meaning that all the communication will be lost.

• Re-allocate one frequency in TX and RX to TRM2. The frequency is chosen according to the priority of the frequency.

• Re-configure the cells for the re-allocated frequency.

Frequency selection mechanism for this example:

Loss of TRM1 when priority (F1) > priority (F2):

• All BTScells (of both frequencies) are lost and then BTScells for frequency F1 are reconfigured.

Loss of TRM1 when priority (F1) = priority (F2):

• All BTScells (of both frequencies) are lost and then BTScells for frequency F2 are reconfigured.

3-23


Antenna Access

TMA

TMA

TMA

Masthead equipmentBTS

RF cables(2 per sector)

DD

M

tmaAccessType (AntennaAccess)

AntennaAccess localCellGroupBTSCell

BTSEquipment

antennaConnectionList (BTSCell)

The antennaConnectionList parameter gathers the identifiers of all the AntennaAccess objects used within a same BTSCell.

For example:

In OTSR: 1 AntennaAccess,

In STSR with 3 sectors: 3 AntennaAccess.

Tower Mast Amplifier (TMA)

The parameter tmaAccessType can take three different values, noTma, tmaUmtsOnly or tmaMix.

In the case where tmaUmtsOnly is selected, the Access OAM will indicate this information to the TRM and DDM for LNA adjustment.

The impact on the DDM is a LNA gain of:

• 24.5 dB, if noTma is chosen,

• 15.5 dB adjustment gain, if tmaUmtsOnly is selected.

3-24


Rake Receiver

TXD(t)

Delay ττττ0

Delay ττττ1

C(t-ττττ0)

+C(t-ττττ1)

Delay (ττττ1)

RX

C(t-ττττn)

Delay (ττττ0)

Delay (ττττn)RX

RX

C(t)

ττττ0

ττττ1

ττττn

Spreading &

Scrambling

4 or 8 fingers

rakeMode (BTSEquipment)

cellSize (BTSCell)

On the BTS side (uplink), the number of fingers handled by the Rake receiver can be tuned to optimise the radio performance. The number of fingers should be high enough to handle all multipaths (otherwise contributing to the noise) but the more fingers the Rake receiver must track, the more resources are consumed on the CEM.

A good compromise seems to be around 4 fingers as a default value. The parameter rakeMode from the BTSEquipment object defines the number of finger the UL Rake receiver handles. Please, note that this parameter is set for a NodeB and therefore cannot be set differently for each cell controlled by the same NodeB.

The rakeMode parameter depends on the type of CEM card used. CEM alpha supports both 4 fingers and 8 fingers, while iCEM card will support only 8 fingers.

The search window size conditions the maximum time allowed for a message to be transmitted from the NodeB to UE and return. The parameter cellSize is used to give a rough approximation of the search window size for the initial access to the NodeB. The larger the cell, the larger the window shall be to get a chance to receive the mobile transmissions (main path and multipaths at the Rake receiver). The cell size should be estimated according to the cell planning (pilot coverage). If some doubt arises, the larger value should be chosen.

Actually, if the value is too low, the NodeB may not detect the mobile. However, if the value is too high, the mobile will be correctly handled but NodeB’s resources will not be optimised.

3-25

Student notes

3-26

Student notes

4-1


Measurements

Section 4

4-2


Objectives


> Describe measurements principles

> Describe main measurements purpose and use

> Describe NBAP measurement process and parameters

> Describe RRC measurement process and parameters

> Describe In-Band measurement process and parameters

4-3


Contents

> UMTS Measurements Principles

> Main Measurements

> NBAP Measurement Procedures

> RRC Measurement Procedures

> Intra-Frequency Event Triggered Measurement Reporting

> In-Band Measurement Procedures

> Missing Measurements Management

4-4

Student notes

4-5


UMTS Measurements Principles

4-6


Reported Measurements

• Propagation Delay (RACH)• BLER (CRCI)• BER (QE)

• SIR• SIR Error• DL Transmitted Code Power• Round Trip Time

• DL Transmitted Carrier Power• UL Received Total Wideband Power• Acknowledged PRACH Preamble

UE Internal Measurements• UE Transmitted Power• UE Position (UEbased GPS)

Quality Measurements• Transport Channel BLER• SIR

Traffic Volume Measurements (UL)

Inter System Measurements• GSM Carrier RSSI• Path Loss• BSIC• Observed time difference to GSM Cell

Intra & Inter Frequency Measurements• P-CPICH Ec/No• P-CPICH RSCP• Path Loss• SFN-SFN Observed Time Difference• Cell Synchronization Information (SFN-CFN)• UTRA Carrier RSSI

RRC Measurements

NBAP Measurements

BTS In-Band Measurements

RNC

NodeB

UE

The NodeB has to provide two types of measurements: common measurements and dedicated measurements. These measurements are also called NBAP Measurements because they are reported to the RNC using NBAP messages.

Beside the NBAP measurements, the BTS is also providing measurements results that are sent in-band.

The UE has to be capable of performing 7 different measurement types: intra-frequency, inter-frequency, inter-system, traffic volume, quality, UE-internal and UE positioning. These measurements are also called RRC Measurements because they are reported to the RNC using RRC messages.

4-7


Measurements Elaboration

ESTIMATING

acquisition time

FILTERING

filter coefficient

REPORTING

reporting periodor

event triggered RNCNodeB

UE

NBAP Measurements

RRC Measurements

FN = (1 - a).FN-1 + a.MN

Physical Layer provides measurements to the upper layers (Layer 3). For each measurement, a basic measurement period is defined, which corresponds to the shortest averaging period and also the shortest reporting period i.e. the NodeB or UE can not be required to report a measurement to the RNC in a shorter time period.

Before reporting to the RNC, the NodeB or UE Layer 3 performs a filtering operation averaging several measurements and allowing to create measurements reports with a period not necessarily equal to the basic measurement period. The filtering parameter a is defined as a = 1/2(k/2), where k is the parameter received in the Measurement Filter Coefficient IE.

The reporting period for each measurement is configured by the RNC when the UE or the NodeB is requested to perform measurements. The minimum reporting period for each measurement is equal to the basic measurement period for this measurement. In general, the reporting period is a multiple of the basic measurement period.

For UTRAN measurements reported in-band, the reporting period is the period at which frames are sent from the NodeB to the serving RNC.

4-8


Measurements Activation

RNC

isInterFreqMeasActivationAllowed (RadioAccessService)

isGsmMeasActivationAllowed (RadioAccessService)

measurementConfClassId(NeighbouringRNC)

measurementConfId(FDDCell)

ueInternalMeasurementQuantity(UEIntMeas)

ueInternalMeasurementFilterCoeff(UEIntMeas)

isEventTriggeredMeasAllowed(FDDCell)

isQualityMeasurementAllowed (MeasurementConfClass)

Each FDDCell and NeighbouringRNC has necessarily a pointer towards one of the Measurement Configuration Classes stored under the RNC they depend upon.

The parameter isEventTriggeredMeasAllowed controls the activation of Full Event Triggered RRC measurement reports per FDDcell.

The parameter isInterFreqMeasActivationtAllowed controls the activation of inter-frequency RRC measurement reports.

The parameter isGsmMeasActivationtAllowed controls the activation of inter-RAT RRC measurement reports.

The parameter isQualityMeasurementAllowed controls the activation of internal RRC measurement reports.

When set to true, the parameter UeInternalMeasurementQuantity allows to choose which measurement type is selected among the three available types: ueTransmittedPower, utraCarrierRssi, ueRxTxTimeDiff.

NoteUeIntMeas is an optional objects.

4-9


Main Measurements

4-10


Cells Sets

Cells belonging to the Active Set

Cell belonging to the Monitored Set

Cell belonging to the Detected Set

isDetectedSetCellsAllowed(RadioAccessService)

There are 3 different ways to classify the cells that may be involved in handover procedures:

• Cells belonging to the Active Set are the cells involved in the soft handover and that are communicating with the UE.

• Cells belonging to the Monitored Set, that do not belong to the active set, but that are monitored by the UE depending on the neighboring list sent by the UTRAN.

• Cells belonging to the Detected Set, which are detected by the UE, but that are neither in the Active Set nor in the Monitored Set.

Starting UA4.2 the value of the parameter isDetectedSetCellsAllowed indicates if the detected set cells have to be taken into account for RRC Intra-Frequency measurement management for the calls established in Event-Triggered Reporting Mode.

4-11


Power Measurements

Ec/No (dB)

-25 -15 -10 0

Power density of CPICH

Power density in the band

GSM Signal

PilotPilot

Received Power on the GSM BCCH carrier

CPICH_Ec/No =

GSM CARRIER RSSI =

CPICH_RSCP =Received Signal

Code Power measured on CPICH OVSF

code

Intra/Inter-FrequencyIntra/Inter-Frequency

Inter-System

CPICH Ec/No

CPICH Ec/No is the received energy per chip divided by the power density in the band, i.e., it is identical to the RSCP measured on the CPICH divided by the RSSI. The UE has to perform this measurement on the Primary CPICH and the reference point is the antenna connector of the UE. This measurement is used for cell selection and re-selection and for handover preparation.

CPICH RSCP

CPICH RSCP is the Received Signal Code Power on one channelization code measured on the bits of the Primary CPICH. The reference point is the antenna connector at the UE. Although the measurement of this quantity requires that the Primary CPICH is despread, it should be noted that the RSCP is related to a chip energy and not a bit energy. This measurement is used for cell selection and re-selection and for handover preparation, open loop power control and pathlosscalculation.

GSM carrier RSSI

This measurement is the wide-band received measured on a specified GSM BCCH carrier. This measurement is used for GSM handover preparation.

4-12


Signal to Interference Ratio

DPCCH

ServingRNC

SIR =Power ControlSIR Target

SIR_Error = SIRUL outer loop power control

Received Signal Code Power

Interference Signal Code PowerSF x

DPCCH= SIRRSCP

ISCPx

2

SF

DL outer loop power control

– SIR Target

SIR = L

ink Q

uality

Est

imat

ion

SIR (NodeB measurement)The Signal to Interference Ratio (SIR) is measured on a dedicated physical control channel (DPCCH) after radio link combination in the NodeB. In compressed mode, the SIR should not be measured during the transmission gaps.

SIR is defined as SF*(RSCP/ISCP) where SF is the spreading factor, RSCP is the Received Signal Code Power and ISCP is the Interference Signal Code Power.

This measurement is used in Power Control algorithm.

SIR ErrorSIR error is defined as SIR - SIRtarget. SIRtarget is the SIR value for the UL outer loop power control algorithm.

This measurement is used to assess the efficiency of the UL outer loop power control.

SIR (UE measurement)SIR is defined as (RSCP/ISCP)*SF/2The reference point for RSCP and ISCP is the antenna connector, but they can only be measured at the output of the de-spreader as they assess either the received power and the non-orthogonal reference received on a particular code. It should beclearly understood that RSCP is though a wideband measurement i.e. at chip level, the narrow band measurement is RSCP * SF/2.

This measurement is used as a quality estimation for the link (for downlink outer loop power control). It is sent periodically, once every power control cycle and event triggered to the RNC (RRC).

4-13


Path Loss

Path Loss = Primary CPICH Tx Power - P-CPICH_RSCP

P-CPICH

FDD Cell

Path Loss

Path Loss

The path loss is defined as Primary CPICH Tx power – P-CPICH RSCP.

This measurement is used to define the initial PRACH power and for inter frequency handover criteria evaluation.

4-14


QE and CRCI

Transport Channels

block

RNC

CRCIndicator

IE QE Selector:

« selected » Transport Channel BER

« non-selected » Physical Channel BER

OR

Physical

Channel

Quality Estimate:

block

• Soft Handover• UL outer loop Power Control

Frame Protocols

NodeB

qeSelector (Static)

CRC INDICATOR

The CRC indicator is attached to the UL frame for each transport block of each transport channel transferred between the NodeB and the RNC. It shows if the transport block has a correct CRC (0=Correct, 1=Not Correct). This measurement is used for frame selection in case of soft handover.

QUALITY ESTIMATE

The quality estimate is reported in band in the UL data frames from the NodeB to the RNC and it is derived from the Transport channel BER or Physical channel BER. If the IE QE-Selector is equal to:

• « selected » in the DCHs of the DCH FP frame, then the QE is set to the Transport channel BER

• « non-selected » in the DCHs of the DCH FP frame, then the QE is set to the Physical channel BER.

In case of soft handover, the quality estimate is needed in order to select a transport block when all CRC indications are showing bad (or good) frame. The RNC compares the QE value with the qeThreshold (static parameter) in order to choose the best transport block.

Quality Estimate can also be used to enhance the UL Outer Loop Power Control mechanism.

4-15


NBAP Measurement Procedures

4-16


NBAP Measurements Initiation

• DL Transmitted Code Power• SIR• RTT• ...

• On Demand• Event-Triggered• Periodic

MeasurementID

MeasurementObject Type

Measurementtype

MeasurementFilter

Coefficient

ReportCharacteristics

Measurement Initiation Request

• Cell• RACH• …

• Common

• Dedicated

• DL Transmitted Carrier Power

• RTWP

• ...

C-RNC

NodeB Common

Dedicated

Depending on the type of measurement, (common or dedicated), measurement requests are initiated by the controlling RNC by sending a COMMON MEASUREMENT INITIATION REQUEST or DEDICATED MEASUREMENT INITIATION REQUEST to the NodeB.

The common and dedicated measurement messages both contain the following information elements to define the measurements to be performed:

• A measurement id uniquely identifying each measurement.

• A measurement object type to indicate the type of object on which the measurement is to be performed, e.g., cell, RACH, time slot, etc.. It can be common or dedicated according to the message. In the case of a dedicated measurement either a radio link is identified on which the measurement has to be performed or the measurement should be performed on all radio links for the NodeB.

• A measurement type indicates which measurement is to be performed. It is also common (Received total wideband power, transmitted carrier power, Acknowledged PRACH preambles, etc.) or dedicated (SIR, transmitted code power, In-Band (transport channel BER, physical channel BER), etc.).

• A measurement filter coefficient gives the parameter for the layer 3 filtering to be performed before the measurement can be reported.

• The report characteristics give the criteria for reporting the measurement. The reporting is on demand, periodic or event-triggered.

4-17


NBAP Measurements Reports

Common Measurement ReportscommonMeasurementReportingPeriod

(NBAP Measurement)

r5NbapCommonMeasurementReportingPeriod(NBAP Measurement)

commonMeasurementFilterCoeff(NBAP Measurement)

Measurement ID

Report Type Measured Quantity

C-RNCNodeB

Common Measurement Termination Request

The reports are sent in the DEDICATED MEASUREMENT REPORT and COMMON MEASUREMENT REPORT, on criteria defined by the report characteristics given in the measurement request.

For the Common Measurements, the type of measurement report is defined by the parameter commonRepType [on demand, periodic, event-triggered].

The quantity measured is defined by the parameter measQuantity.

The periodicity is given in the Report_Periodicity IE of the measurement request message.

In case of NBAP Common Measurements Reports used for Call Processing (nominal case), the periodicity is given in the Report_Periodicity IE of themeasurement request message and corresponds to the value of the parameter commonMeasurementReportingPeriod if the BTS software release is UA4.0 or lower and r5NbapCommonMeasurementReportingPeriod if the BTS software release is UA4.1 or greater.

For common measurements, only one type of measurement can be requested at a time; so in case of several measurement types, a request should be done for each type.

For dedicated measurements, only one type of measurement can be requested at a time, but the NodeB can be required to perform it on all the radio links or on one given radio link.

The measurements reporting by the NodeB stops upon reception of COMMON MEASUREMENT TERMINATION REQUEST sent by the C-RNC.

4-18


Call Trace

Measurement Reports

sirRequired (NbapDedicatedMeasConfigForCallTrace)

sirReportPeridodicity (NbapDedicatedMeasConfigForCallTrace)

transmittedCodePowerRequired (NbapDedicatedMeasConfigForCallTrace)

transmittedCodePowerPeridodicity (NbapDedicatedMeasConfigForCallTrace)

roundTripTimeRequired (NbapDedicatedMeasConfigForCallTrace)

roundTripTimePeriodicity (NbapDedicatedMeasConfigForCallTrace)

C-RNCNodeB

Measurement Initiation Request

Dedicated Measurement Termination Request

Common

Dedicated

Common

Dedicated

Common Measurement Termination Request

tcpRequired(NbapCommonMeasConfigForCallTrace)

tcpReportPeriodicity(NbapCommonMeasConfigForCallTrace)

rssiRequired (NbapCommonMeasConfigForCallTrace)

rssiPeridodicity (NbapCommonMeasConfigForCallTrace)

In case of Dedicated Measurements, three different types of measurements reports are supported (SIR, DL TRANSMITTED CODE POWER and ROUND-TRIP-TIME). For Call Trace purposes, these three types of reports can be activated separately and can be configured with different periodicities.

The procedure is initiated with a DEDICATED MEASUREMENT INITIATION REQUEST message sent from the RNC to the NodeB. This procedure is used by a RNC to request the initiation of measurements on dedicated resources (all UE Radio links managed by FDDCells belonging to this NodeB.

Upon reception, the NodeB shall initiate the requested measurement according to the parameters given in the request and shall periodically send a DEDICATED MEASUREMENT REPORT.

The procedure is operational as long as the RL is established. The RNC does not send sent a DEDICATED MEASUREMENT TERMINATION REQUEST message. Instead, even though the trace session is deleted, the NBAP dedicated measurement reporting, if initiated, will remain until the radio links associated with the call being traced are deleted or released.

4-19


Event Triggered Reports

C-RNC

NodeB

Dedicated Measurement Initiation Request (Bx)

Dedicated Measurement Termination Request (Bx)

NBAP Dedicated Report Event Bx

RL Monitoring• Event A• Event B1• Event B2

Primary Cell

iRM Scheduling Downgraded UE

NBAP event triggered report mode is only used in the scope of iRM scheduling downgrade/upgrade procedures with the RNC perspective to retrieve the transmitted code power by the NodeB for a particular radio link (user) and to order the radio bearer downsizing/upsizing through iRM scheduling towards the more adapted bit rate to guarantee the service continuity.

For the purpose of iRM Scheduling RNC configures the NodeB with one Event A and two Events B:

• Event A is indicating that the radio conditions become bad enough to attempt a downgrading to the fallback radio bearer in order to maintain a good radio link quality.

• Event B1 is indicating that the radio conditions become good enough to attempt an upgrading towards the original requested RB.

• Event B2 is indicating that the radio conditions become good enough to consider an upsizing towards a relative lower bit rate than the requested RB to maintain a good radio link quality.

4-20


Event A

Transmitted Code Power Event AReport

Primary Cell

TxCPThreshold

Event A Timer

dlIrmSchedDowngradeTxcpTrigger_threshold_delta

(DlUsPowerConf)

dlIrmSchedDowngradeTxcpTrigger_timeToTrigger

(DlUsPowerConf)

Event A Timer

In order to be able to perform IRM Scheduling downgrade, the RNC configures NBAP dedicated measurement by event A report for this UE on the primary cell.

So, each time the primary cell changes, the RNC terminates measurements on the old primary cell and initiates measurements on the new primary cell.

Event A configuration relies on:

• Measurement Threshold: the relative transmitted code power threshold given by the parameter dlIrmSchedDowngradeTxcpTrigger_threshold_data is used to compute the absolute TxCP Threshold together with the parameters pcpichPower(FDDCell) and maxDlTxPower (DlUsPowerConf).

• Measurement Hysteresis: dlIrmSchedDowngradeTxcpTrigger_timeToTrigger.

So, Event A is reported when the transmitted code power is above TxCP absolute threshold during at least the time to trigger.

4-21


Event B1 & Event B2

Event B2 Timer

Transmitted Code Power Event B1Report

Primary Cell

Event B2Threshold

Event B1Threshold

Event B1 Timer

Event B2Report

thresholdTransCodePower (DhighRbB1)

timeToTrigger (DhighRbB1)

deltaThresholdTransCodePower (DhighRbB2)

deltaTimeToTrigger (DhighRbB2)

Event B2 Timer = Event B1 Timer + deltaTime Event B 2 Threshold = Event B1 Threshold + deltaTCP

When a UE is using the RB assigned by IRM Scheduling downgrade, the RNC configures two types of NBAP dedicated measurement by event B report for this UE on the primary cell.


Event B1 configuration relies on:

• Measurement Threshold: absolute transmitted code power threshold given by the parameter thresholdTransCodePower

• Measurement Hysteresis: given by the parameter timeToTrigger

So, Event B1 is reported when the transmitted code power is under thresholdTransCodePower during at least timeToTrigger.


• Measurement Threshold: absolute transmitted code power threshold given by thresholdTransCodePower + deltaThresholdTransCodePower

• Measurement Hysteresis: given by timeToTrigger+ deltaTimeToTrigger

So, event B2 is reported when the transmitted code power is under thresholdTransCodePower + deltaThresholdTransCodePower during at least timeToTrigger+ deltaTimeToTrigger.

4-22

Student notes

4-23


RRC Measurement Procedures

4-24


RRC Measurements Initiation

Measurement ControlRRC

OR

SI broadcastP-CCPCH

NodeBUE

MeasurementID

MeasurementObject

MeasurementType

MeasurementQuantity

• FDDCell• Physical Channel• RB• …

• Ec/No• RSCP• BLER• Traffic Volume• ...

Inter-FrequencyIntra-FrequencyInter-SystemTraffic VolumeQualityUE internal

MeasurementReportingQuantity

MeasurementReporting

Criteria

ReportingMode

MeasurementCommand

• Setup • Modify• Release

• Periodical• Event-Triggered

• RLC AM• RLC UM

In CELL_FACH, CELL_PCH or URA_PCH state, the UE is informed of the measurements to perform via the system information broadcast on the P-CCPCH.

When the UE is in CELL_DCH state, UTRAN starts a measurement in the UE by sending the MEASUREMENT CONTROL message, that includes the following information elements to define measurements to perform:

• measurement id is a reference number to be used when modifying or releasing measurement,

• measurement command indicates the action performed on the measurement (setup a new measurement, modify the characteristics of a measurement, …),

• measurement type indicates one of the different types of measurement: inter-frequency, intra-frequency, …,

• measurement object indicates the object on which the measurement shall be performed,

• measurement quantity indicates the quantity to be measured (RSCP, SIR, ...),

• measurement reporting quantity indicates quantities that the UE should report together with the measurement quantity e.g. the measurement quantity which triggered the report,

• measurement reporting criteria indicates the type of reporting i.e. periodical or event-triggered,

• reporting mode specifies whether the UE shall transmit the measurement report using acknowledged or unacknowledged RLC mode.

4-25


Intra-Frequency Reporting

Active Set cells+

Best Monitored cells

• Cell Synchronization information (SFN-CFN)

• CPICH Ec/No

• CPICH RSCP

• SFN-SFN observed time difference « type2 »

Measurement Report

Measurement Report

rrcIntraFreqMeasurementReportingPeriod (RRC Measurement)

rrcIntraFreqMeasurementFilterCoeff (RRC Measurement)

MeasurementID


NodeB

MeasurementResults

repMode (static)

maxCellsRepType (static)

The MEASUREMENT REPORT message is sent from the UE to the UTRAN and contains the measurement id, the measured results and the measurement event result that triggered the report in case it was event-triggered.

When the rrcIntraFreqMeasurementReportingPeriod time has elapsed, the UE shall send the computed measurement.

Reporting Quantities

The RNC requests the following quantities to be reported by the mobiles:

• “Cell Synchronization information” which provides the difference between SFN of the reported cell and CFN as observed by the UE.

• CPICH Ec/No: the received energy per chip divided by the power density in the band.

• CPICH RSCP: is the received power on one code measured on the Primary CPICH.

Other reporting quantities are also supported by UTRAN and are also requested to the UE for tracing purposes:

• SFN – SFN observed time difference "type 2": the relative timing difference between cell j and cell i measured on the primary CPICH.

4-26


RACH

Neighboring Cells

RRC Measurements on RACH

sib11IntraFreqMeasurementNbrOfCellOnRACH (RRCSysInfoMeas)

sib11IntraFreqMeasurementFilterCoeffOnRACH (RRCSysInfoMeas)

SIB 11Reported Measurements on RACH

CPICH Ec/No

CPICH RSCP

Path Loss

or

or

measQuantity (static)

Measurements reported in RACH message are used by power allocation and RAB assignment algorithms.

The static parameter measQuantity determines the type of reported measurements. Only the value CPICH_Ec/No is supported for static measQuantity parameter.

The parameter sib11IntraFreqMeasurementNbrOfCellOnRACH indicates how many cell measurements shall be reported in the RACH message, including the current cell.

Note

The number of reported cells on RACH is used by the compound neighbor list feature to create the neighboring list for the first Measurement Control Message.

4-27


Fast Measurements at Call Establishment

Measurement Control

SI broadcastP-CCPCH

NodeBUE

RRC Connection Request

RRC Connection Setup

Measurement Report

isSib11MeasReportingAllowed (FDDCell)

sib11MeasReportingUsHoConfId (FDDCell)

This feature allows UTRAN to provide intra-frequency measurements configuration information to UEs which are in Idle Mode or in Cell-FACH. Received within the SIB11, information is used by UEs to activate intra-frequency measurements just after entering the Cell-DCH state, with no need to wait for the first Measurement Control.

If the reporting mode is “Event Triggered”, only Event 1A is configured in the SIB11 and UE sends the first Measurement Report only if the 1A Event has been reached. The rest of the events are configured in the first RRC Measurement Control message. The parameter sib11MeasReportingUsHoConfId is the identifier of the UsHoConf instance to be used to fill the SIB11 IEs relative to the Event 1A.

If the reporting mode is “Periodic”, the UE keeps on sending reports at the defined period until the reception of the first RRC Measurement Control.

The first RRC Measurement Control message sent to the UE is of type SETUP instead of MODIFY in order to ensure no misalignment between UE and the Network.

UE starts sending measurements when its state changes:

• from Idle mode to Cell-DCH (after the RRC Connection Setup),

• from Cell-FACH to Cell-DCH (after the RRC RB Setup).

4-28

Student notes

4-29


Intra-Frequency Event Triggered Measurement Reporting

4-30


Events Description

Measid12

Measid11

Measid12

Measid11

Measid1

Measid1

Measid1

Measid1

Measid1

Measid1

Meas Id

best Active Set cellCPICH RSCP2D

Estimated quantity of current carrier is better tha n threshold.best Active Set cellCPICH Ec/No2F

best Active Set cellCPICH RSCP2F

Estimated quantity of current carrier is worse than threshold.best Active Set cellCPICH Ec/No2D

Hard Handover Management

A P-CPICH becomes worse than an absolute threshold.RL deletion based on absolute criteria.any of Active SetCPICH Ec/No1F

A P-CPICH becomes better than an absolute threshold.RL addition based on absolute criteria when AS not f ull.

any of Monitored SetCPICH Ec/No1E

Change of best cell.Primary cell change.any of Active SetCPICH Ec/No1D

A non-active P-CPICH becomes better than an active P -CPICH.RL addition based on relative criteria when AS full.

any of Monitored SetCPICH Ec/No1C

An active P-CPICH leaves reporting range.RL deletion based on relative criteria.

any of Active SetCPICH Ec/No1B

A monitored P-CPICH enters reporting range.RL addition based on relative criteria when AS not f ull.

any of Monitored SetCPICH Ec/No1A

Soft Handover Management

semantic & usagetriggering cellstriggering quantity

Event Id

Measid12

Measid11

Measid12

Measid11

Measid1

Measid1

Measid1

Measid1

Measid1

Measid1

Meas Id

best Active Set cellCPICH RSCP2D

Estimated quantity of current carrier is better tha n threshold.best Active Set cellCPICH Ec/No2F

best Active Set cellCPICH RSCP2F

Estimated quantity of current carrier is worse than threshold.best Active Set cellCPICH Ec/No2D

Hard Handover Management

A P-CPICH becomes worse than an absolute threshold.RL deletion based on absolute criteria.any of Active SetCPICH Ec/No1F

A P-CPICH becomes better than an absolute threshold.RL addition based on absolute criteria when AS not f ull.

any of Monitored SetCPICH Ec/No1E

Change of best cell.Primary cell change.any of Active SetCPICH Ec/No1D

A non-active P-CPICH becomes better than an active P -CPICH.RL addition based on relative criteria when AS full.

any of Monitored SetCPICH Ec/No1C

An active P-CPICH leaves reporting range.RL deletion based on relative criteria.

any of Active SetCPICH Ec/No1B

A monitored P-CPICH enters reporting range.RL addition based on relative criteria when AS not f ull.

any of Monitored SetCPICH Ec/No1A

Soft Handover Management

semantic & usagetriggering cellstriggering quantity

Event Id

3GPP specifications define 2 RRC measurements reporting modes; periodical reporting and event-triggered reporting. For the event triggered reporting mode, RRCstandards define a set of events for each type of measurement:

• Events 1X are defined for intra-frequency measurements,

• Events 2X are defined for inter-frequency measurements,

• Events 3X are defined for inter-RAT measurements,

• Etc.

Event-triggered reporting is used in Alcatel-Lucent UTRAN for intra-frequency reporting measurements. Inter-frequency and inter-RAT measurements reporting are based on periodical reporting.

The use of event triggered reporting has a direct impact on the following mechanisms:

• primary cell determination,

• active set management,

• alarm measurement criteria,

• inter-frequency blind handover,

• radio link color determination.

4-31


Event 1A

Best Cell

New Cell

CPICH_EC/No

entering reporting range

leaving reporting range

Eve

nt1A

Eve

nt1A

Eve

nt1A

timeToTrigger1A(FullEventRepCritShoMgtEvent1A)

repInterval1A(FullEventRepCritShoMgtEvent1A)

amountRep1A(FullEventRepCritShoMgtEvent1A)

hysteresis (static)wParam (static)

cpichEcNoReportingRange1A (FullEventHOConfShoMgt)

cellIndivOffset (UMTSFddNeighbouringCell)

maxNbReportedCells1A(FullEventRepCritShoMgtEvent1A)

)2/(10)1(1010 111

aaBest

N

iiNewNew HRLogMWMLogWCIOLogM

A

m−⋅⋅−+

⋅⋅≥+⋅ ∑

=

Event 1A is triggered when a new P-CPICH enters the reporting range.Event 1A is used to add a RL based on relative criteria when the Active Set is not full.

The variables in the formula are defined as follows:

• MNew is the measurement result of the cell entering the reporting range.

• CIONew is the individual cell offset for the cell entering the reporting range if an individual cell offset is stored for that cell. Otherwise it is equal to 0.

• Mi is a measurement result of a cell not forbidden to affect reporting range in the active set.

• NA is the number of cells not forbidden to affect reporting range in the current active set.

• MBest is the measurement result of the cell not forbidden to affect reporting range in the active set with the best measurement result, not taking into account any cell individual offset.

• W is a parameter sent from UTRAN to UE.

• R1a is the reporting range constant.

• H1a is the hysteresis parameter for the event 1a.

NoteThe above drawing shows an example assuming that CIO is set to 0 dB.

4-32


Event 1B

Best Cell

Old Cell

CPICH_EC/No



Eve

nt1B

Eve

nt1B

timeToTrigger1B(FullEventRepCritShoMgtEvent1B)

repInterval1B(FullEventRepCritShoMgtEvent1B)

amountRep1B(FullEventRepCritShoMgtEvent1B)

hysteresis (static)wParam (static)

cpichEcNoReportingRange1B (FullEventHOConfShoMgt)


Eve

nt1B

Eve

nt1B

maxNbReportedCells1B(FullEventRepCritShoMgtEvent1B)

)2/(10)1(1010 111

bbBest

N

iiOldOld HRLogMWMLogWCIOLogM

A

±−⋅⋅−+

⋅⋅≤+⋅ ∑

=

Event 1B is triggered when an active P-CPICH leaves the reporting range.Event 1B is used to delete a RL based on relative criteria.


• MOld is the measurement result of the cell leaving the reporting range.

• CIONew is the individual cell offset for the cell entering the reporting range if an individual cell offset is stored for that cell. Otherwise it is equal to 0.

• Mi is a measurement result of a cell not forbidden to affect reporting range in the active set.

• NA is the number of cells not forbidden to affect reporting range in the current active set.

• MBest is the measurement result of the cell not forbidden to affect reporting range in the active set with the best measurement result, not taking into account any cell individual offset.

• W is a parameter sent from UTRAN to UE.

• R1b is the reporting range constant.

• H1b is the hysteresis parameter for the event 1b.

NoteThe above drawing shows an example assuming that CIO is set to 0 dB.

R99/R4 UEs are not able to use periodical measurement reporting after initial report.

4-33


Event 1C

AS Cell

InAS Cell

CPICH_EC/No



Eve

nt1C

Eve

nt1C

timeToTrigger1C(FullEventRepCritShoMgtEvent1C)

repInterval1C(FullEventRepCritShoMgtEvent1C)

amountRep1C(FullEventRepCritShoMgtEvent1C)

hysteresis1C (FullEventRepCritShoMgtEvent1C)


Eve

nt1C

Eve

nt1C

maxNbReportedCells1C(FullEventRepCritShoMgtEvent1C)

New Cell

)2/1010 1cInASInASNewNew HCIOLogMCIOLogM ±+⋅≥+⋅

Event 1C is triggered when a new P-CPICH becomes better than an active P-CPICH.

Event 1C is used to replace a RL based on relative criteria when the Active Set is full.


• MNew is the measurement result of the cell not included in the active set.

• CIONew is the individual cell offset for the cell becoming better than the cell in the active set if an individual cell offset is stored for that cell. Otherwise it is equal to 0.

• MInAS is the measurement result of the cell in the active set with the lowest measurement result.

• CIOInAS is the individual cell offset for the cell in the active set that is becoming worse than the new cell.

• H1c is the hysteresis parameter for the event 1c.

Note

The above drawing shows an example assuming that the maximum AS size is set to 2 and that all the CIOs are set to 0 dB.

4-34


Event 1D

Best Cell

CPICH_EC/No



Eve

nt1D

timeToTrigger1D(FullEventRepCritShoMgtEvent1D)

hysteresis1D (FullEventRepCritShoMgtEvent1D)


maxNbReportedCells1D(FullEventRepCritShoMgtEvent1D)

useCIOfor1D(FullEventRepCritShoMgtEvent1D)

NotBest Cell

)2/1010 1dBestBestNotBestNotBest HCIOLogMCIOLogM ±+⋅≥+⋅

Event 1D is triggered when an active P-CPICH becomes better than the primary cell P-CPICH.

Event 1D is used to change primary cell.


• MNotBest is the measurement result of an active cell not primary.

• CIONotBest is the cell individual offset of an active cell not primary.

• MBest is the measurement result of the primary cell.

• CIOBest is the cell individual offset of the primary cell.

• H1d is the hysteresis parameter for the event 1d.

NoteIn 3GPP R5 the definition of event 1D has been changed.

CIOs are only applied by R5 UEs and only if requested by a configuration flag present in event 1D configuration sent in Measurement Control message.

Event 1D can be triggered by a cell in the Active Set for R5 UEs or by a cell in the Active Set or in the Monitored Set for R99/R4 UEs.

If event 1D is triggered by a monitored cell, the RL is added in the Active Set if not full.

4-35


Event 1E

AS Cell

New Cell

CPICH_EC/No



Eve

nt1E

timeToTrigger1E (FullEventRepCritShoMgtEvent1E)

hysteresis (static)

cpichEcNoThresholdUsedFreq1E (FullEventHOConfShoMgt)


absolute threshold

maxNbReportedCells1E(FullEventRepCritShoMgtEvent1E)

2/10 11 eeNewNew HTCIOLogM ±≥+⋅

Event 1E is triggered when a new P-CPICH becomes better than an absolute threshold.

Event 1E is used to add a RL based on absolute criteria when the Active Set is not full.


• MNew is the measurement result of a cell that becomes better than an absolute threshold.

• CIONew is the individual cell offset for the cell becoming better than the absolute threshold. Otherwise it is equal to 0.

• T1e is an absolute threshold.

• H1e is the hysteresis parameter for the event 1e.

4-36


Event 1F

AS Cell

Old Cell

CPICH_EC/No



Eve

nt1F

timeToTrigger1F (FullEventRepCritShoMgtEvent1F)

hysteresis (static)

cpichEcNoThresholdUsedFreq1F (FullEventHOConfShoMgt)


absolute threshold

maxNbReportedCells1F(FullEventRepCritShoMgtEvent1F)

2/10 11 ffOldOld HTCIOLogM m≤+⋅

Event 1F is triggered when an acttive P-CPICH becomes worse than an absolute threshold.

Event 1F is used to delete a RL based on absolute criteria.


• MOld is the measurement result of a cell that becomes worse than an absolute threshold.

• CIOOld is the individual cell offset for the cell becoming worse than the absolute threshold. Otherwise it is equal to 0.

• T1f is an absolute threshold.

• H1f is the hysteresis parameter for the event 1f.

4-37


timeToTrigger2D (FullEventRepCritHhoMgtEvent2D)maxNbReportedCells2D (FullEventRepCritHhoMgtEvent2D)

timeToTrigger2F (FullEventRepCritHhoMgtEvent2F)maxNbReportedCells2F (FullEventRepCritHhoMgtEvent2F)

Event 2D/2F

Best Cell

CPICH_EC/NoCPICH_RSCP

leaving 2D reporting range

entering 2D reporting range

Eve

nt2D

hysteresis (static)

cpichEcNoThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)cpichRscpThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)cpichEcNoThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)cpichRscpThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)

2D absolute threshold

timerAlarmHoEvent(FullEventHOConfHhoMgt)

2F absolute thresholdleaving 2F reporting range

entering 2F reporting range

Eve

nt2F

Eve

nt2D

Alarm Measurement Criteria

Alarm Measurement Timer

NOT HIT HIT

2/22 ddUsedUsed HTQ m≤ 2/22 ffUsedUsed HTQ ±≤

Event 2D is triggered when the best active P-CPICH becomes worse than an absolute threshold.Event 2F is triggered when the best active P-CPICH becomes better than an absolute threshold.

Events 2D/2F are used to validate/invalidate alarm measurements conditions.


• QUsed is the quality estimate of the used frequency.

• TUsed2d and TUsed2f are the absolute thresholds that apply for the used frequency.

• H2d and H2f are the hysteresis parameters.

The algorithm used to trigger alarm measurements is based on the following principles:

• On reception of an event 2D the RNC starts the timer timerAlarmHoEvent.

• If no event 2F has been received at timer expiry, the alarm condition is validated and the alarm measurements are configured.

• If an event 2F is received while the timer is running, the timer is stopped and the alarm conditions are invalidated.

4-38

Student notes

4-39


In-Band Measurement Procedures

4-40


RACH & DCH FP Measurements

1st Transport Block of 1 st DCH

1st Transport Block of 1 st DCH Pad.

Last Transport Block of 1 st DCH

Last Transport Block of 1 st DCH Pad.

1st Transport Block of last DCH

1st Transport Block of last DCH Pad.

Last Transport Block of last DCH

Last Transport Block of last DCH Pad.

QE

CRCI

Pad.CRCI

Spare extension

Payload Checksum (optional)


Header CRC FTCFN

Spare TFI of 1 st DCH

Spare TFI of last DCH

1st RACH Transport Block

1st RACH Transport Block Pad.

Last RACH Transport Block

Last RACH Transport Block Pad.

CRCI

Pad.CRCI

Spare extension



Header CRC FTCFN

Spare TFIPropagation Delay

The propagation delay is reported in the RACH data frames transferred from theNodeB to the RNC when a successful RACH procedure has happened and the RACH has been sent from the UE to the RNC.

The CRC Indicator is attached to the UL frame for each transport block of each transport channel transferred between the NodeB and the RNC. It shows if the transport block has a correct CRC.

The Quality Estimate is reported in band in the UL data frames from the NodeB to the RNC. This QE corresponds to either the transport channel BER or the physical channel BER when no transport channel BER is available i.e. there is no data transmitted in the UL thus only DPCCH is transmitted.

4-41


Missing Measurements Management

4-42


RRC Missing Measurements

Measurement Report

Measurement Report

RRC Measurements are missing

Measurement Report


Use modified version of old RRC measurement instead

maxAllowedNumber(MissingMeasurement)

Measurement Report


MN = MN-1 - penalty

missedEcNoMeasurementPenalty(MissingMeasurement)

missedRSCPMeasurementPenalty(MissingMeasurement)

RRC measurements set to minimal value

Measurement Report


In the RRC protocol, when measurements are missing in the MEASUREMENT REPORT sent by the UE to the SRNC, a maximum of maxAllowedNumberconsecutive missing measurements are allowed.

If maxAllowedNumber + 1 consecutive measurements are missing, the link is released.

To cope with missing measurements in order to keep on making decision through the algorithms, a missing measurement algorithm is performed at the SRNC.

Then, the decision algorithm is processed with the modified value as if it was a real measurement.

In some cases this can lead to drop the radio link if the corresponding cell is part of the Active Set.

Note

RRC missing measurements management does not apply for event triggered reporting mode.

4-43


CM Measurements Validity

Measurement Report

GSM Measurements are missing

Measurement Report


Measurement Report


Use old GSM measurement instead

Use old GSM measurement instead

old GSM measurement is removed

Measurement Report

inter-Frequency Measurements are missing

Measurement Report

inter-Frequency Measurements are missing

old inter-frequency measurement is removed

Use old inter-frequency measurement instead

gsmRssiMeasValidityPeriod (RRCMeasurement)

interFreqMeasValidityPeriod (InterFreqMeasConf)

gsmRssiMeasValidityPeriod is the maximum number of measurement report without a GSM measurement after which an old GSM measurement is deleted while the current measurement is missing.

interFreqMeasValidityPeriod is the maximum number of measurement report without a inter-frequency measurement after which an old inter-frequency measurement is deleted while current measurement are missing.

4-44

Student notes

5-1


Compressed Mode

Section 5

5-2


Objectives


> Describe Compressed Mode Principles

> Describe CM implementation and configuration

> Describe CM measurement process and associated parameters

> Describe CM impacts on other UTRAN features

5-3


Contents

> Compressed Mode Principles

> Compressed Mode Implementation

> FDD Inter-Frequency Measurements

> GSM Inter-System Measurements

> Measurement with Compressed Mode

> Impacts of Compressed Mode

5-4

Student notes

5-5


Compressed Mode Principles

5-6


Compressed Mode Scope & Methods

Inter-frequency measurementsInter-RAT measurements

Transmission Gap Length = 3, 4, 7, 10, 14 TS

pow

er

time

idle

TGL

frame N-1 frame N+1

pow

er

time

idle

TGL

frame N-1 frame N+2idle

frame boundary

ulCModeMethod (CmodePatternSeqInfo)dlCModeMethod (CmodePatternSeqInfo)

Single-Frame Mode

Double-Frame Mode

Compressed Mode consist in creating regularly spaced short gaps (less than one 10 ms radio frame) of transmission in the uplink or downlink, or possibly both at the same time and/or reception without altering the data to be exchanged on the radio interface.

Three methods are proposed in the standard: Spreading Factor Reduction, Puncturing and Higher Layer Scheduling.

Compressed mode is mandatory in downlink and optional in uplink. It can only be achieved on dedicated channels. The Transmission Gap Length is 3, 4, 5, 7, 10 or 14 slots.

Two methods can be used for time transmission reduction:

• compressed mode by reducing the spreading factor by 2: the SF can be reduced by 2 to permit the transmission of the information bits in the remaining time slots of the compressed frame. In that case, the scrambling code could be different from normal mode;

• compressed mode by higher layer scheduling: higher layers set restrictions in order to know the maximum number of bits that will be delivered to the physical layer during the compressed radio frame. So the data rate provided by the higher layers is lowered and the transmission gap is created.

5-7


• Dual receiver UE?• Mono Receiver UE?• GSM compatible UE?

Needs for Compressed Mode

isCmodeAllowed (RadioAccessService)

UMTS

UMTS

GSM

GSM450Present (RadioAccessService)GSM480Present (RadioAccessService)GSM850Present (RadioAccessService)GSM900PPresent (RadioAccessService)GSM900EPresent (RadioAccessService)GSM1800Present (RadioAccessService)GSM1900Present (RadioAccessService)

UE Capability

The real need for Compressed Mode is provided by the UE itself. Following network request through the UE Capability required indicator in the RRC Connection Setup message, the UE indicates in the UE Radio Access Capability IE (Measurement Capability sub-IE, provided in the RRC Connection Setup Complete message) if Compressed Mode is needed in either UL or DL for the FDD and GSM bands.

Therefore, regarding CM for GSM, in order not to configure compressed mode in every case, a set of flags indicating the frequency bands of the FDD and GSM neighboring cells will be defined and used in the RNC to determine whether or not Compressed Mode is needed.

Each flag indicates that there exists at least a GSM cell of the corresponding frequency band in the access network (i.e. not only being part of the GSM neighboring lists seen by the RNC) to which handovers from a 3G cell are supported by the network. Therefore, if Compressed Mode is needed by the mobile for that frequency band, it will be configured accordingly and possibly activated by the network.

5-8

Student notes

5-9


Compressed Mode Implementation

5-10


Alternate Scrambling Code Method

Compressed Time SlotsSF/2

Normal Time SlotsSF

The Spreading Factor Reduction method consists in creating gaps of transmission / reception and granting twice the bandwidth for compressed frames in order to compensate for the loss of bandwidth in not transmitted frames. This method applies for both uplink and downlink with fixed or flexible position mapping but it requires that the spreading factor be strictly greater than 4.

The SF is reduced by a factor two for as many slots as used for gaps and the transmitted power of these slots is increased. Thus OVSF code need to be changed, the new one is the parent code of the code used for non-compressed radio frames.

In downlink, the scrambling code management is done through the alternate scrambling code method. This method consists in applying to the compressed frames the new channelization code with SF/2 while applying one of the two available alternate scrambling codes (left or right alternative) depending on the original OVSF.

The figure above gives an example of how this method applies.

In uplink, the compressed mode method by spreading factor reduction is identical to the spreading factor reduction used in the downlink but with some exceptions.

For example as in downlink, the OVSF code is changed to be the parent code of the code that would be used for non-compressed radio frame, but the scrambling code is left unchanged. Indeed, multiple UEs are differentiated by their scrambling code rather than the OVSF code so there is no coordination between UEs to account for.

5-11


Compressed Mode Pattern Sequences

sub-pattern 1 sub-pattern 2 sub-pattern 1 sub-pattern 2 sub-pattern 1 sub-pattern 2

#1 #2 #TGPRC#TGCFN

Gap1 Gap2 Gap1 Gap2

tgsn

tgl1 tgl2 tgl1 tgl2

tgd tgd

tgpl1 tgpl2

tgprc (CModePatternSeqInfo)tgcfnOffset (CModePatternSeqInfo)

The compressed mode is controlled by the UTRAN: it is configured by the RNC on a per UE basis in the form of Compressed Mode Transmission Gap Pattern Sequences. A CM pattern sequence may be composed of up to two sub-patterns and is dedicated to one specific measurement purpose.Each pattern is described by the parameters listed below, those parameters being defined at the cell level.

• TGL1 and TGL2: length of transmission gaps 1 and 2 expressed in number of slots. Possible values are 3, 4, 5, 7, 10 and 14. TGL2 is an optional parameter and if a value is not given by the upper layers, then by default TGL2 = TGL1,

• TGSN: the first gap occurs TGSN slots after the beginning of the pattern,

• TGD: the two gaps are separated by a distance of TGD slots,

• TGPL1 and TGPL2: length of pattern 1 and 2 expressed in radio frames,

• TGCFN: CM start expressed in CFN as CFNx + TgcfnOffset) mod[256],

• TGPRC: number of times the Transmission Gap Pattern is repeated within the Transmission Gap Pattern Sequence.

5-12


Pattern Sequence Configuration

A pattern sequence is defined for each type of meas urement

RadioAccessServiceCmodePatternSeqInfo [0]

isPatternAllowed = TrueTgmp = 2 TgcfnOffset = 0Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 8Tgsn = 8

CmodePatternSeqInfo [1]isPatternAllowed = TrueTgmp = 3 TgcfnOffset = 48Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 78Tgsn = 8nIdentifyAbort = 26

CmodePatternSeqInfo [2]

isPatternAllowed = TrueTgmp = 1 TgcfnOffset = 0Tgd = 0Tgl1 = 10Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 50Tgsn = 10

GSM RSSI measurement

BSIC identification

FDD measurements

A certain number of pattern sequences can be defined in UTRAN configuration, each of them being associated to a specific measurement purpose.

The pattern sequence is defined by a set of parameters (transmission GAP and CM patterns parameters), that are grouped into the CModePatternSeqInfo object:

• Instance 0 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose GSM RSSI Measurements,

• Instance 1 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose GSM Initial BSIC Identification,

• Instance 2 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose FDD Inter-Frequency Measurement.

5-13


FDD Inter-Frequency Measurements

5-14


FDD Inter-Frequency CM Pattern

6 Frames (60 ms)

50 Patterns (3000 ms)

10 Time Slots 70 Time Slots

Gap = 10 Time SlotsCFN + 0

For FDD inter-frequency measurement a single pattern of 6 frames repeated 50 times is used leading to a basic compressed mode measurement period of 3 s.

The UE is provided with the FDD neighboring cell list, when receiving the RRC Measurement Control message. Using this list, the UE starts the CPICH_RSCP and CPICH_Ec/No measurements process that can be seen as a sort of endless loop, intending to identify the best neighboring cells.

Measurements results are sent to the RNC with periodical measurement reports.

5-15


GSM Inter-System Measurements

5-16


GSM Measurement Process

Measurement Control (BSIC, BCCH, ARFCN)

Measurement Control (CM Pattern, starting CFN)

Measurement ReportRSSI Measurement

8 strongest cells

BSIC Identification

identified BSICs

BSIC ConfirmationMeasurement Report

PeriodicalMeasurementReports

isNIdentifyAbort (static)

nIdentifyAbort (CmodePatternSeqInfo)

The figure above presents a view of the Compressed Mode process for GSM measurements.

The UE is provided with the GSM neighboring cell list, when receiving the RRC Measurement Control message. Using this list, the UE starts the RSSI measurement process that can be seen as a sort of endless loop, intending to identify the 8 strongest neighboring cells.

If BSIC verification is requested, the UE has to verify the BSIC of the 8 strongest BCCH carriers.

5-17


GSM Measurements CM Pattern

6 Frames (60 ms)

8 Patterns (480 ms)

8 Time Slots 68Time SlotsGap = 14 Time Slots

CFN + 0

CFN + 48

78 Patterns (4680 ms)

RSSI BSIC

In the case of GSM initial BSIC identification, the UE is to take the results of the most recent set of GSM RSSI samples and attempt to identify the BSICs of the 8 strongest cells, proceeding in single strength order.

UTRAN can signal an additional parameter nIdentifyAbort to set an upper limit on the number of patterns the UE should use in attempting to identify the BSIC of a given BCCH carrier. If the timer expires, the BSIC is considered non-verified and the UE moves on to attempt to identify the next BCCH carrier in signal strength order.

As the searching is done serially, the use of this parameter ensures that the UE does not spend all of its time trying to identify the BSIC of one cell.

5-18

Student notes

5-19


Measurement with Compressed Mode

5-20


CM Activation with Periodic Reporting

IFP-CPICH_EcNo(primary) < cpichEcNoThresholdORP-CPICH_RSCP(primary) < cpichRscpThreshold

THENAlarm Measurement Counter is incremented by stepUpIF

Alarm Measurement Counter > counterTHEN

Alarm Measurements are requested from UE ELSE

Alarm Measurement Counter = Max ( 0; Alarm Measurem ent Counter – stepDown )

cpichEcNoThreshold (AlarmMeasActivation)

cpichRscpThreshold (AlarmMeasActivation)

counter (AlarmMeasActivation)

stepUp (AlarmMeasActivation)

stepDown (AlarmMeasActivation)

Max Alarm Measurement Counter = Counter + numberOfStepDownToComeBackToThreshold (static) x Step Down

In case of periodical RRC measurement reporting, at each report reception the following criteria is evaluated for the Primary cell:

• AlarmMeas = (CPICH Ec/No < cpichEcNoThreshold),

• or AlarmMeas = (CPICH RSCP < cpichRscpThreshold).

Then, the following process is applied:

• If AlarmMeas is valid:

—Increment AlarmMeasCounter by StepUp,

—Else Let AlarmMeasCounter = max (0, AlarmMeasCounter – StepDown),

• If AlarmMeasCounter > Counter, then inter-system or inter-frequency measurements are requested from the UE.

5-21


CM Activation with Full Event Triggered

Best Cell




Eve

nt2D




Eve

nt2F

Eve

nt2D



NOT HIT HIT

Tim

e to

Trig

ger

2D

Tim

e to

Trig

ger

2F

Tim

e to

Trig

ger

2D

Alarm Measurements Requested from UE

In case of Full Event Triggered RRC measurement reporting, the events 2D and 2F are used to validate/invalidate alarm measurements conditions.


• QUsed is the quality estimate of the used frequency.

• TUsed2d and TUsed2f are the absolute thresholds that apply for the used frequency.

• H2d and H2f are the hysteresis parameters.

The algorithm used to trigger alarm measurements is based on the following principles:

• On reception of an event 2D the RNC starts the timer timerAlarmHoEvent.

• If no event 2F has been received at timer expiry, the alarm condition is validated and the alarm measurements are configured.

• If an event 2F is received while the timer is running, the timer is stopped and the alarm conditions are invalidated.

5-22


Compressed Mode Strategy

fastAlarmHHOStrategy (UsHoConf) isGsmCModeActivationAllowed (DlUserService)isInterFreqCModeActivationAllowed (DlUserService)

Alarm Measurements Required

HHO Strategy = Inter-System

Inter-System CM enabledAND

Inter-System neighbors configured

Inter-Frequency CM enabledAND

Inter-Frequency neighbors configured

Inter-System CM enabledAND

Inter-System neighbors configured

Inter-Frequency CM enabledAND

Inter-Frequency neighbors configured

Inter-System CM activated

Inter-Frequency CM activated

CM not activated

YES NO

YES

YES

YES

YES

NO

NO NO

NO

Starting UA4.2 there is the possibility to favor either inter-system or inter-frequency measurements in case of Alarm Hard Handover on a per user Service basis using the fastAlarmHHOStrategy parameter.

An example of strategy could be to privilege inter-system hard handover for speech based user services, standalone SRBs and PS services with the smallest bit rates, and to prefer inter-frequency hard handover for all the remaining user services.

As shown in the above diagram, fastAlarmHHOStrategy gives just an indication of what is the preferred mode for CM. The final choice between Inter-System CM and Inter-Frequency CM relies also on the neighboring list and on the global CM activation settings.

5-23


CM Deactivation / Reactivation

cModeDeltaCfn (CModeConfiguration)

CM period

Duration of pattern sequence

gsmCModeReactivationTimer (CModeConfiguration )

If required according to alarm measurements

Measurement criteria is still valid

CFN

CM activation time

Inter-System or inter-Frequency measurements

are required

fddCModeReactivationTimer (CModeConfiguration )

Inter-System

Inter-FreqcModeShoDeltaCfn (CModeConfiguration)

or

isShoCModeActiveAllowed(CModeConfiguration)

if = Yes

If inter-system/frequency measurement criteria is fulfilled, then the following is applied:

• Inter-system/frequency measurements are requested from the UE using a RRC Measurement Control message

• Compressed Mode is possibly activated using the Measurement Controlmessage, based on UE needs, as indicated in the mobile Classmark

• if compressed mode needs to be reactivated, a Compressed Mode Commandmessage is sent to the UE.

cModeDeltaCfn indicates the delay to add to the CFN to determine the activation time of the compressed mode. It allows to synchronize UE and BTS Compressed Mode start.

There is no criterion for CM de-activation (CM scheme with a finite length pattern). Meanwhile, CM needs to be re-activated if the inter-system/frequency measurement criteria are still valid. In order to prevent CM to be active forever, the parameters gsmCModeReactivationTimer and fddCModeReactivationTimer are set to a value which shall be greater than the pattern sequence length.

Interaction between CM and SHO

• isShoCModeActiveAllowed allows to indicate whether the soft handover is enabled while the compressed mode is active

• cModeShoDeltaCfn indicates the delay to add to the CFN in order to determine the reception time of the NBAP RL Setup Request at NodeB level while the compressed mode is active. It is given in connection frame number of 10 ms.

5-24


Measurements Reports

Best Monitored cells

• GSM Carrier RSSI

• Observed time difference to GSMCell

• Verified BSIC

Measurement Report

Measurement Report

rrcIntraFreqMeasurementReportingPeriod (RRC Measurement)

rrcGsmMeasurementFilterCoeff (RRC Measurement)

interFreqFilterCoeff (InterFreqMeasConf)

MeasurementID


NodeB

MeasurementResults

maxCellsRepType (static)• CPICH Ec/No

• CPICH RSCP

Periodic reporting is used for the alarm measurements. All the measured quantities will be reported by the mobile in the same Measurement Report message.

The UE is requested to report up to maxCellsRepType neighbouring cells amongst the monitored set: either FDD inter-frequency or GSM inter-system neighbouring cells.

The monitored set is defined as the set of FDD inter-frequency and GSM neighbours and is provided to the UE through a MEASUREMENT CONTROL message first time the alarm measurement condition is fulfilled and on modification of monitored set.

In order to avoid making handover decision on stale measurement (which would lead to handover failure), a measurement validity criteria is defined using the parameters GsmRssiMeasValidityPeriod and InterFreqMeasValidityPeriod expressed in number of measurement reports. At a given time, more than 1 measurement may be valid.

5-25


Impacts of Compressed Mode

5-26


Impacts on Frame Format

Slot # (Nfirst - 1)

TPC

Data1TFCI Data2 PL

Slot # (Nlast + 1)

PL Data1TPC

TFCI Data2 PL

transmission gap

Slot # (Nfirst - 1)

TPC

Data1TFCI Data2 PL

Slot # (Nlast + 1)

PL Data1TPC

TFCI Data2 PL

transmission gap

TPC

dlFrameType (CmodePatternSeqInfo)

(a) Radio frame structure type A

(b) Radio frame structure type B

• Type A

• Type B

Downlink

In downlink, there are two possible radio frame structures that can be used with compressed mode. These are denoted as Type A and Type B, and are illustrated in the figure above.

• The Type A radio frame structure is designed to maximize the available transmission gap. All DPDCH and DPCCH information is stopped for the period of the transmission gap, except for the pilot field in the last slot of the gap. The inclusion of the pilot at the end of the transmission gap is necessary as the pilot bits at the end of one slot are used for coherent detection in the next slot. Without the inclusion of this field, coherent detection would not be possible in the first slot following the transmission gap.

• The Type B radio frame structure is designed to optimize the power control algorithm by including the TPC field in the first slot of the transmission gap. By giving one more power control command before proceeding to the gap, it is hoped that there will be less drift in the power control loop and the recovery period will be shorter following the compressed mode gap.

5-27


Impacts on Outer Loop Power Control

∆∆∆∆SIR

Transmission Gap1

Compressed frames

Compressedframes

∆∆∆∆ pilot

Transmission Gap2

∆∆∆∆ pilot

SIR target

∆∆∆∆SIR =3dB -> Compressed radio frame

0 -> Other radio frame

∆∆∆∆SIRcompression + ∆∆∆∆SIRcoding

CmodePCDeltaSir1(DlUserService)

CmodePCDeltaSir2(DlUserService)

CmodePCDeltaSirAfter1(DlUserService)

CmodePCDeltaSirAfter2(DlUserService)

Due to the introduction of transmission gaps in the radio frames, Compressed Mode has a significant impact on the different Power Management algorithms. These impacts are not necessary the same for uplink and downlink.

In order to compensate for the changes that apply to the transmission scheme when the transmitted radio frames are compressed, some parameters are used by the Node-B and UE for the outer loop power control.

The UE and the Node-B are signaled offset values ∆SIR for the SIR target used by the inner loop power control. As the compressed mode patterns can have 2 different gap lengths, 2 values of ∆SIR are signaled together, after to be used in the radio frame following the compressed radio frame.

∆SIR can be separated into 2 parts named ∆SIR _compression and ∆SIR _coding.

• ∆SIR _compression aims at compensating for the bit rate increase,

• ∆SIR _coding aims at compensating for the possible degradation due to a change in the rate matching attributes during the compressed mode.

The signaled value CmodePCDeltaSIR1, CmodePCDeltaSIR2, CmodePCDeltaSIRafter1and CmodePCDeltaSIRafter2 correspond to ∆SIR_coding. It should be noted that these values are not to be computed exactly but will result from an estimation of the degradation of the link performance due to compressed mode.

∆SIR_compression takes the following values: 3 dB for the compressed radio frame, 0 for the other radio frames.

The UE and Node-B will then derive the value of ∆SIR which should be applied in each radio frame from the following rule:

• ∆SIR = max (∆SIR1_compression,... ∆SIRn_compression) + ∆SIR_coding

5-28


Impacts on Inner Loop Power Control

Recovery Period Power Control (RPP = 0 or 1)

Transmission Gap

ITP = 0

Transmission Gap

ITP = 1

Initial Transmission Power

Compressed framesCompressedframes

Compressedframes

Compressed frames

Offset δ δ δ δ last

DL

ITP = 0

RPP = 1

UL

ITP = 0 or 1

RPP = 0 or 1

DPCCH

∆∆∆∆ pilot

Compressed mode procedure

CmodePCItp(DlUserService)

CmodePCRtp(DlUserService)

During uplink compressed mode, the UE does not transmit the DPCCH/DPDCH so the NodeB cannot perform any measurement to adapt the UE transmit power to the radio conditions. Similarly when the downlink is compressed, there are missing TPC commands, therefore after a transmission gap there is a need for specific power control procedures in order to help the UE transmit power converge back to an adapted value as fast as possible.

Two procedures have been standardized which are applicable for both uplink and downlink compressed mode.

Initial transmission power (ITP)

It is controlled by the ITP parameter. There are 2 possible modes of operation:

• ITP = 0: power after the transmission gap = power before the transmission gap

• ITP = 1: power after the transmission gap = average power before the transmission gap

Recovery period power control (RPP)

This procedure is controlled by the RPP parameter. It allows changing the power control steps during the recovery period i.e. the period following the resumption of simultaneous uplink and downlink DPCCH transmission. There are two possible modes of operation:

• RPP = 0: the same algorithm and step size are applied as in normal mode.

• RPP = 1: Algorithm 1 is used with a modified step size ∆TPC = min (3 dB, 2DTPC) during RPL slots = min (7 slots, transmission gap length) after the transmission gap.

For the Downlink power control case, the behavior of the NodeB is equivalent to:

• ITP = 0 (no power offset between the power before and after the transmission gap)

• RPP = 1 (simple power control algorithm is used during RPL slots after the transmission gap).

5-29

Student notes

5-30

Student notes

6-1


Mobility in Idle Mode

Section 6

6-2


Objectives


> Describe PLMN selection and associated parameters

> Describe Cell selection and associated parameters

> Describe Cell reselection and associated parameters

> Describe CELL_FACH mobility and associated parameters

6-3


Contents

> Network Selection

> Cell Selection

> Cell Reselection

> Cell Status and Reservation

> Location Registration

> Mobility in CELL_FACH

6-4

Student notes

6-5


Network Selection

6-6


PLMN Selection

MCC MNC MSIN

mobileCountryCode (Operator)mobileNetworkCode (Operator)

mobileCountryCode (RNC)mobileNetworkCode (RNC)

mobileCountryCode (CsCoreNetworkAccess)mobileNetworkCode (CsCoreNetworkAccess)

mobileCountryCode (PsCoreNetworkAccess)mobileNetworkCode (PsCoreNetworkAccess)

mobileCountryCode (FDDCell)mobileNetworkCode (FDDCell)

MIB / P-CCPCH

Preferred PLMN List Forbidden PLMN List

The different UMTS networks are identified uniquely in the world by the PLMN identifier composed of:

• the Mobile Country Code (MCC),

• the Mobile Network Code (MNC).

For one carrier, once the cell search procedure is completed, the UE has found the strongest cell and knows its scrambling code; it is then possible to decode the Primary CCPCH.

The MNC and MCC are part of the system information broadcast on the P-CCPCH (in the Master Information Block or MIB).

The UE then decodes the received PLMN identifiers and determines if the PLMN is permitted or not according to the lists of preferred and forbidden PLMN (stored in the UE). If the PLMN is permitted and chosen, the cell selection parameters are used by the UE to determine on which cell to camp on.

6-7


Cell Selection

6-8


Srxlev > 0��

CPICH_RSCP > qRxLevMin + Pcompensation

P-CPICH

Cell Selection Criteria

S Criteria

AND

qQualMin (CellSelectionInfo)qRxLevMin (CellSelectionInfo)

Squal > 0��

CPICH_Ec/No > qQualMin

FDDCCell

Squal and SRxlev are the two quantities used for cell selection criteria.

If the criteria are fulfilled, the UE moves to the camped normally state where the following tasks will be performed:

• Select and monitor the indicated PICH and PCH.

• Monitor relevant System Information.

• Perform measurements for the cell reselection evaluation procedure.

If the criteria are not fulfilled, the UE will attempt to camp on the strongest cell of any PLMN and enter in the camped on any cell state where it can only obtain limited service (emergency calls). The following tasks will be performed in the camped on any cell state:

• Monitor relevant System Information.

• Perform measurements for the cell reselection evaluation procedure.

• Regularly attempt to find a suitable cell trying all radio access technologies that are supported by the UE. If a suitable cell is found, the cell selection process restarts.

6-9


NodeB

RNC

UE Power Compensation

FDDCell

CellSelectionInfo

RadioAccessService

DedicatedConf

PowerConfClass

qRxLevMin (CellSelectionInfo)sibMaxAllowedTxPowerOnRach (PowerConfClass)

Pcompensation=

max (sibMaxAllowedUlTxPowerOnRach – P_MAX, 0)

Srxlev > 0��

CPICH_RSCP > qRxLevMin + Pcompensation

+21 dBm4

+24 dBm3

+27 dBm2

+33 dBm1

P_MAXUE Class

Pcompensation = max (sibmaxAllowedUlTxPowerOnRach – P_MAX, 0). Pcompensation is a compensation factor to penalize the low power mobiles.

• sibMaxAllowedUlTxPowerOnRach = maximum transmit power level the UE is allowed to use while accessing the cell on RACH.

• P_MAX = maximum output power of the UE according to its power class.

6-10

Student notes

6-11


Cell Reselection

6-12


Idle Mode Neighboring List

sib11AndDchNeighbouringFddCellAlgo (FDDCell)

sib11OrDchUsage (UMTSFddNeighbouringCell)

SIB11 / P-CCPCH

Serving Cell

• 16 intra-frequency FDDCells• 16 inter-frequency FDDCells• 16 GSMCells

SIB11 Neighboring List

• UMTSFddNeighbouringCell List

• GsmNeighbouringCell List

FDDCell Neighboring List

The list of neighboring cells is broadcasted through SYSInfo.

The information and parameters related to the neighboring cells are contained into two subtrees in the Radio Access Network Model:

• UMTSNeighbouringFDDCell for FDD intra and inter-frequency neighbors,

• GSMNeighbouringCell for GSM neighbors.

An algorithm is used to declare and control correctly the list of neighboring cells in order to make differentiation between the configuration of idle mode/cell_FACH mode neighbors (sent in SIB11) and cell_DCH connected mode neighbors. The idle mode/cell_FACH mode neighboring list is a subset of the cell_DCH connected mode neighboring list. The differentiation is set through the sib11OrDchUsage parameter on each umtsFddNeighbouringCell. Note that this parameter is only used when sib11NeighboringFddCellAlgo is set to manual.

6-13


Cell Reselection Triggering Criteria

Squal = CPICH_Ec/No - qQualMin (CellSelectionInfo)

sIntraSearch (CellSelectionInfo)

sInterSearch (CellSelectionInfo)

sSeachRatGsm (CellSelectionInfo)Measurement

on same frequency

Measurement on other

frequencies Measurement on other RAT

If CPICH_Ec/No – qQualMin ≤≤≤≤ Threshold

Then associated measurements are performed

SIB11 / P-CCPCH

Without Hierarchical Cell Structures (HCS) for FDD cells, Squal is compared to thresholds in order to determine the measurement types the UE shall perform.

The following cell reselection algorithms apply:

Intra-frequency measurements: Squal comparison with Sintrasearch

• if Squal > sIntraSearch UE doesn’t need to perform intra-frequency measurements

• if Squal ≤ sIntraSearch UE performs intra-frequency measurements

• if Sintrasearch not sent for serving cell, UE performs intra-frequency measurements

Inter-frequency measurements: Squal comparison with Sintersearch

• if Squal > sInterSearch UE doesn’t need to perform inter-frequency measurements

• if Squal ≤ sInterSearch UE performs inter-frequency measurements

• if Sintrasearch not sent for serving cell, UE performs inter-frequency measurements

Inter RAT measurements: Squal comparison with SsearchRATgsm

• if Squal > sSearchRatGsm UE doesn’t need to perform GSM measurements

• if Squal ≤ sSearchRatGsm UE performs GSM measurements

• if SsearchRATgsm not sent for serving cell, UE performs GSM measurements

6-14


FDDCell

CPICH_Ec/No CPICH_RSCP

Cell Reselection Process

Best cell is a ..?

Best GSMCellis reselected

GSMCell

Best FDDCellafter First Ranking

is reselected

Best FDDCellafter Second Ranking

is reselected

qualMeas = ..?

Eligible CellsFirst Ranking

(CPICH_RSCP & RxLev)

Second Ranking

(CPICH_Ec/No)

qualMeas (Static)

The slide above describes the cell reselection process when the UE is in Idle mode.

UE has to define which cell is the best one, and then reselect it, if the detected best cell is different from the serving cell.

A first ranking is performed based on the signal reception level:

• If a GSM cell is ranked as the best cell in term of Rx level, the GSM cell is reselected.

• If a FDD cell is ranked as the best cell, a second parameter (QualMeas) is taken into account:

—If reselection is based on CPICH_RSCP, the best FDD cell after the first ranking is selected.

—If reselection is based on CPICH_Ec/No, a second ranking is performed (only on FDD Cell) based on the interference level.

• Following this second ranking, the UE shall perform cell reselection on the best ranked FDD cell.

6-15


Cells Eligibility Criteria

UMTSFddNeighbouringCell

Srxlev > 0Squal > 0

> > + PcompensationCPICH_Ec/No qQualMin (UMTSFddNeighbouringCell) qRxLevMin(UMTSFddNeighbouringCell)

CPICH_RSCPANDANDANDAND

GSMCell

Srxlev > 0

> + Pcompens ationqRxLevMin (GSMCell)QRxLeavMeas

Max(MaxAllowedUlTxPower - P_max, 0)(GSMCell)

Max(MaxAllowedUlTxPower - P_max, 0)(UMTSFddNeighbouringCell)

Once the criteria for GSM or UTRAN/FDD neighboring cells tracking and measurements based on CPICH_Ec/No are applied, a criteria S is applied on the measured GSM or FDD neighboring cells to assess their eligibility to cell reselection.

To be eligible, the intra and inter-frequency FDD cells must fulfill criteria very similar to what is used for Cell Selection. But this time these relationships shall be verified on the neighbor cell, this means the measurements are made on this neighbor cell, and the parameters are those defined in the neighboring relationship.

To be eligible, the inter-system GSM cells must fulfill criteria shown in the above slide. Any cell (serving and any GSM or UTRAN/FDD neighboring cell), which fulfills these criteria, will be part of the list of cells for ranking.

6-16


First Ranking

qHyst1 (CellSelectionInfo)

UMTSFddNeighbouringCell

GSMCell

CPICH_RSCP

Rank

123…

Cell ID

Cell BCell ACell C

…

UE List

qOffset1sn (UMTSFddNeighbouringCell)CPICH_RSCPRs = +

R criterion for Serving Cell R criterion for FDD Neighboring Cell

Rn = –

FDDCell

RxLev qOffset1sn (GSMCell)Rn = –

R criterion for GSM Neighboring Cell

All the neighboring cells being eligible (S criteria) are ranked accordingly to the R criteria, as defined below:

• Rs = Qmeas,s + Qhysts; for the serving cell

• Rn = Qmeas,n - Qoffsets,n; for any GSM or UTRAN/FDD neighboring cells

Where Qmeas is the CPICH_RSCP for the FDD case. For GSM cells, RxLev is used instead of CPICH RSCP in the mapping function.

Where Qhysts is the qHyst1 parameter of the CellSelectionInfo object.

Where Qoffset is the qOffset1sn parameter of the GSMcell object.

The cells (serving and neighbors) will be ranked according the R criterion.

6-17


Second Ranking

Rn = –Rs = +CPICH_Ec/No CPICH_Ec/noqHyst2 (CellSelectionInfo) qOffset2sn (UMTSFddNeighbouringCell)

R criterion for Serving Cell R criterion for Neighboring Cell

FDDCell UMTSFddNeighbouringCell

Rank

123…

Cell ID

Cell BCell ACell C

…

UE List

If after a first ranking selection the best ranked cell is a FDD Cell and if the qualMeasstatic parameter is set to CPICH_Ec/No, then a second ranking selection will be performed with the following conditions:

• Only FDD Cell will be implied.

• All the FDD neighboring cells being eligible (S criterion) are ranked accordingly to the R criterion, as defined below:

—Rs = Qmeas,s + Qhysts; for the serving cell

—Rn = Qmeas,n - Qoffsets,n; for any UTRAN/FDD neighboring cells

Where Qmeas is the CPICH Ec/No measurement.

Where Qhysts is the qHyst2 parameter of the CellSelectionInfo object.

Where Qoffset is the qOffset2sn parameter of the UMTSFddNeighbouringCell object.

The FDD cells (serving and neighbors) will be ranked a second time according to the R criterion.

6-18


GSMCell

B

Rank

123…

Cell ID

Cell B (GSM cell)Cell A (FDD cell)Cell C (FDD cell)…

UE List

FDDCell

A

FDDCell

C

FDDCell

D

Rank

123…

Cell ID

Cell A (FDD cell)Cell B (GSM cell)Cell C (FDD cell)…

UE ListRank

123…

Cell ID

Cell D (FDD cell)Cell A (FDD cell)Cell C (FDD cell)…

UE List

After 1st ranking

After 1st ranking

After 2ndranking

If New Cell better ranked than Serving Cell during tReselection (CellSelectionInfo)

Then New Cell is reselected

Cell Reselection Process Summary

If CPCICH_Ec/No

If CPCICH_RSCP

Among the GSM and FDD cells which verify the S criteria, the UE shall perform ranking according to the R criteria. In this first step, the offset Qoffset1sn is used to calculate Rn, the hysteresis Qhyst1s is used to calculate Rs.

Then the following selection process applies:

• if a GSM cell is ranked as the best cell, then the UE shall perform cell reselection to that GSM cell,

• if an FDD cell is ranked as the best cell and the quality measurement for cell selection and reselection is set to CPICH RSCP, the UE shall perform cell reselection to that FDD cell,

• if an FDD cell is ranked as the best cell and the quality measurement for cell selection and reselection is set to CPICH Ec/No, the UE shall perform a second ranking of the FDD cells according to the R criteria. In this second step, the offset Qoffset2s,n is used to calculate Rn, the hysteresis Qhyst2s is used to calculate Rs. Following this second ranking, the UE shall perform cell reselection to the best ranked FDD cell.

In all cases, the UE shall reselect the new cell, only if the cell reselection criteria are fulfilled during a time interval of tReselection.

6-19


Cell Status and Reservation

6-20


Cell Status and Reservation Process

barred notBarred

notReservedallowed notAllowed

only UE withAccess Classes 11 / 15

are accepted

reserved

try to selectanother intra

frequency cell

try to selectanother inter

frequency cell

if no other cell

all UE Access Classesare accepted

notReservedreserved

other UE

barredOrNot (FDDCell) = ..?

intraFreqCellReselectInd (FDDCell) = ..? cellReservedForOperatorUse (FDDCell) = ..?

cellReservationExtension (FDDCell) = ..?

try to reselectsame cell

wait tBarred (FDDCell)

wait Max( tBarred )(barredS1280 )

All UEs are members of one out of ten randomly allocated mobile populations defined as Access Classes 0 to 9. The population number is stored in the SIM. In addition mobiles may be members of one or more out of 5 special categories (Access Classes 11 to 15) also held in the SIM and allocated to specific high priority users as follows (enumeration is not meant as a priority sequence):

• Class 15 - PLMN Staff (VIP),

• Class 14 - Emergency Services,• Class 13 - Public Utilities (e.g. water/gas suppliers),

• Class 12 - Security Services,

• Class 11 - For Operator Use.

An additional control bit known as "Access Class 10" is also signaled over the air interface to the UE. This indicates whether or not network access for Emergency Calls is allowed for UEs with access classes 0 to 9 or without an IMSI.

Cell status and cell reservations are indicated with the Cell Access Restriction Information Element in the System Information Message (SIB3) by means of four Information Elements:

• Cell barred (IE type: "barred" or "not barred").• Cell Reserved for operator use (IE type: "reserved" or "not reserved").

• Cell reserved for future extension (IE type: "reserved" or "not reserved").

• Intra-frequency cell re-selection indicator (IE type: "allowed" or "not allowed").

The last element (Intra-frequency cell re-selection indicator) is conditioned by the value ”barred“ of the first element (Cell barred).

6-21


Location Registration

6-22


LAC/RAC/SAC

LAC 2

RAC 1

RAC 2

SAC 1

SAC 2

LAC 1

RNClocationAreaCode (FDDCell)

routingAreaCode (FDDCell)

serviceAreaCode (FDDCell)

Location Area (LA)

The location area is used by the Core Network CS domain to determine the UE location in idle mode. A location area contains a group of cells. Each cell belongs only to one LA.

The location area is identified in the PLMN by the Location Area Code (LAC), which corresponds to the locationAreaCode parameter of the FDDCell object.

The Location Area Identifier (LAI) = PLMN-id + LAC = MCC + MNC + LAC

Routing Area (RA)

The routing area is used by the PS Core Network to determine the UE location in idle mode. A routing area contains a group of cells. Each cell belongs only to one RA.

The routing area is identified by the Routing Area Code (RAC) within the LA. The RAC corresponds to the routingAreaCode parameter of the FDDCell object.

A Routing Area Identifier (RAI) = LAI + RAC = MCC + MNC + LAC + RAC

Service Area (SA)

The Service Area is used by the Core Network to determine the UE location in connected mode. A service area contains a group of cells. Each cell belongs only to one SA.

The service area is identified by the Service Area Code (SAC) within the LA. The SAC corresponds to the serviceAreaCode parameter of the FDDCell object.

The Service Area Identifier (SAI) = LAI + SAC = MCC + MNC + LAC + SAC.

6-23


Mobility in CELL_FACH

6-24


Cell Reselection on CELL_FACH

RNC

RACH / Cell Update

FACH / Cell Update Confirm (RNTI)

UE RRC Connection Request messagecontains the establishment cause

RRCRRC

RRC

RRC RRC

RRCRACH / UTRAN Mobility Information Confirm

FACH / Routing Area Update Accept

RACH / Routing Area Update RequestGMMGMM

GMMGMM

if UE enters a new Location or Routing Area

UE Core Network

When in CELL_FACH mode, although the mobile is in RRC Connected Mode, the UE mobility is controlled by "cell re-selection rules" as in Idle mode. This paragraph covers the following mobility cases:

• "3G to 3G cell reselection intra-frequency in CELL_FACH mode".

• "3G to 3G cell reselection inter-frequency in CELL_FACH mode".

• "3G to 2G cell reselection in CELL_FACH mode".

When the UE is reselecting a new cell being also controlled by the SRNC (as in the above slide) the UE generates a CELL UPDATE message, so that the SRNC keeps the current cell updated for paging and user data transfer. In case the UE enters a new Location/Routing Area, the Cell Update is followed by a Location/Routing Area Update.

In case of Inter-RNC Cell Update, the new RNC detects that the UE is actually connected to another SRNC. As, in this version, UTRAN does not support common channel over Iur nor 3G to 3G SRNS Relocation, it will reject the cell update using RRC connection release, forcing the UE to go to Idle Mode.

The parameters for Cell reselection in CELL_FACH mode are the same than for idle mode.

6-25

Student notes

6-26

Student notes

7-1


Call Admission

Section 7

7-2


Objectives


> Describe call establishment and associated parameters

> Describe RAB Matching and associated parameters

> Describe IRM RAB to RB Mapping and associated parameters

> Describe CAC and associated parameters

> Describe CELL_FACH admission and associated parameters

7-3


Contents

> Paging

> Access Preambles & Acknowledgment

> RRC Connection Establishment

> RAB Matching Principles

> RAB to RBset Matching

> Target RAB Determination

> Resource Reservation & Admission Control

> CELL_FACH Admission Control

7-4

Student notes

7-5


Paging

7-6


Paging DRX Cycle

Paging for Packet callPaging for Circuit call

DRX

Slot #0 Slot #1 PICH Slot #14

nbOfPagingRepetition (Static)UE

NodeB

FDDCell

psDrxCynLngCoef

csDrxCynLngCoef

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

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

Slot #0 Slot #1 PICH Slot #14

When camping normally on a cell, the UE monitors regularly the paging channel. In order to save some energy, a discontinuous reception mode (DRX) is used.

The DRX cycle is defined as the individual time interval between monitoring Paging Occasion for a specific UE. The UE needs only to monitor one Page Indicator (PI) in one Paging Occasion per DRX cycle.

The DRX cycle length is defined as MAX(2k, PBP), where:

• PBP is the Paging Block Periodicity and has the fixed value of 1 in UMTS-FDD.

• k is an integer and can be specific by Core Network domain.

The value of k is controlled in Alcatel-Lucent’s solution by two parameters, one by Core Network Domain: csDrxCynLngCoef and psDrxCynLngCoef.

Since the UE may be attached to two different domains simultaneously, both DRX cycle length values are calculated and stored in the UE from the values read in the SIB 1 (NAS system information, idle and connected mode timers and counters). Then the UE should keep only the shortest of both values as the DRX cycle length it will use.

UTRAN may repeat the transmission of a PAGING_TYPE_1 message to a UE in several paging occasions to increase probability of proper reception of a page.

The static parameter nbOfPagingRepetition handles the number of automatic paging message repetition over the Iub and Uu.

7-7


Access Preambles & Acknowledgment

7-8


Preambles Transmission

PRACH

prachScramblingCode (RACH)

Preamble

rachsubChannel (RACH)

2

preambleThreshold (RACH) Preambledetection

Interference level

RACH

detection

3

Preamble Part

preambleSignature (RACH)1

Wait for Ack ...

aichTransmissionTiming (RACH)

5

Ack.

4

Message part

6

AS 0 AS 1 AS 2 AS15

UE PRACH use is composed of two parts: the preamble part and the message part. Before transmitting the message part of the preamble, the UE waits for an acknowledgement from the network (on the AICH), confirming that the network hasdetected the UE.

The transmission of the preamble part consists in the repetition of a preamble composed of a 16-chip signature repeated 256 times for a total of 4096 chips.

Basically, the UE is assigned one of the 16 possible preambles signature and transmits it at increasing power until it gets a response from the network. The parameter preambleSignature of the RACH object, defines the set of allowed signatures of the PRACH preamble part.

The parameter preambleThreshold is defined as the threshold (in dB) over the interference level used for preamble detection in the CEM card.

The parameter rachSubChannels defines the set of access slots on which the mobiles are authorized to transmit their access on the PRACH. It defines a sub-set of the total set of uplink access slots.

The aichTransmissionTiming parameter of the RACH object defines the timing relation between PRACH and AICH channels.

The scrambling code of the PRACH preamble part is defined by theprachScramblingCode parameter of the RACH object.

7-9


Acknowledgement Transmission

PreamblePreamble

Preamble PRACH

aichTransmissionTiming (RACH) = 0

Transmission of AICH may only start at the beginnin g of a DL AS

Transmission of UL RACH preambles and RACH message parts may only start at the beginning of an UL AS

PRACH

AICH3 TS

3 AS 3 AS

Downlink

AICH

Uplink

PRACH

aichTransmissionTiming (RACH) = 1

Downlink

AICH

Uplink

PRACH

Preamble

AICH

4 AS 4 AS

5 TS

The aichTransmissionTiming parameter of the RACH object defines the timing relation between PRACH and AICH channels.

For example when aichTransmissionTiming is set to 1:

• the minimum inter-preamble distance tp-p,min = 20480 chips (4 access slots),

• the preamble-to-AI distance tpa = 12800 chips (5 time slots),

• the preamble-to-message distance tp-m = 20480 chips (4 access slots).

7-10


Preambles Retransmission Parameters

PREAMBLE #1

PREAMBLE #2

PREAMBLE #N

NB01min (RachTxParameters)

NB01max (RachTxParameters)

Acc

ess

Cyc

le #

1A

cces

s C

ycle

#2

preambleRetransMax (RACH)

Mmax (RachTxParameters)

PREAMBLE #1

PREAMBLE #N

When a negative answer is received by the UE from the network after a given period, then the UE re-sends a preamble at a higher transmission power, so that the NodeB can detect it better among the other information received. This “ramping up” process is thus characterized by:

• Periodicity of the preamble retransmission: 3GPP (cf. 25.321) has defined two parameters: NB01min and NB01max, setting respectively the lower and the upper bounds of the retransmission periodicity (unit is expressed in 1/10th of ms).

• Maximum number of preambles transmitted: this limitation is defined through preambleRetransMax and Mmax parameters.

—preambleRetransMax gives the maximum number of PRACH time slots allowed within an access cycle,

—Mmax gives the maximum number of access cycles. An access cycle is defined by a number of radio frames on which the PRACH access (and therefore a preamble ramping cycle) is allowed on specific slot numbers.

The ramping process stops when the number of preambles transmitted has reached the maximum allowed number of PRACH retransmissions, either within an access cycle, or when the maximum number of access cycles is reached.

7-11


RRC Connection Establishment

7-12


RRC Connection Setup

RRC Connection Request (Cause)

RNC

RB = ???

DlUserService UlUserService UlRbSetConfDlRbSetConf ServiceInit

RadioAccessService

UserServices

NodeB

When the UE attempt to establish an RRC Connection is accepted, the corresponding Signalling Radio Bearers can be supported on two different RRC states and with two different throughputs:

• CELL_DCH with SRB 3.4k: supported from UA1.

• CELL_FACH: supported from UA3.

• CELL_DCH with SRB 13.6k: supported from UA4.1

The parameters which allow to choose the RRC state to support the Signalling Radio Bearers are UlUserviceID for the UL direction, DlUserserviceID for the DL direction

The selection of the state to accommodate the RRC connection is distinguished by RRC establishment Cause (UserServices instance).

7-13


UL Interference CAC on RACH

Interference level

Eb/No required

Received Power

UL RTWP

RNC

NBAP Common measurement report

(RTWP)

P-RACH

RTWP < Maximum UL Interference Level

Yes No

Call is accepted Call is rejected

cacConfId (FDDCell)

maxUlInterferenceLevel (CacConfClass)

The overall interference level received in a cell is measured with the UL RTWP measurement (Received Total Wideband Power measured at NodeB and forwarded to RNC).

On RACH reception, before the allocation of the standalone signaling radio bearer, and during the resource reservation phase, the RNC compares the measured RTWP with a fixed value, the maxULInterferenceLevel parameter.

• If the RTWP is below this threshold, the criterion is met.

• If the RTWP is over the threshold the call is rejected.

The RTWP is measured by the NodeB and sent towards the RNC by sending a “NBAP common measurement report”.

7-14


RRC Speech Redirection


RRC Connection Rejected (cause)

Redirection IE (Inter-RAT info = GSM)isDlCemLoadCalculationEnabled (RadioAccessService)

RNC

UL Interference CAC Rejection RNC Overload SRB CAC Rejection

IFRRC Establishment Cause = MO ConversationalORRRC Establishment Cause = Emergency

ANDisDlCemLoadCalculationEnabled = TRUE

AND2G neighbor configured

THENinclude Redirection IE in RRC Connection Rejection message

Upon reception of the RRC Connection Request message, the RNC executes the usual RRC Connection Admission Controls.

If failure occurs for SRB assignment, the RNC verifies that:

• RRC Establishment cause is MO Conversational or Emergency,

• isDlCemLoadCalculationEnabled is set to true (feature enabled),

• a 2G neighboring cell (blind or other) is provisioned for the current cell.

If all the above conditions are respected, the RRC Connection Reject message then contains the Redirection IE with Inter-RAT info set to “GSM”. Note that the RNC is unaware of the UE capabilities at RRC Connection Request time. Therefore, the RNC attempts an RRC Redirection independently of whether the UE supports GSM or the Redirection IE. If the UE supports GSM and the Redirection IE, it will perform inter-system cell reselection and will re-originate the speech call on the 2G network.

All types of MO Conversational calls are redirected to 2G upon admission failure independently of the service type or domain. This includes non-speech calls such as Video Telephony. This is a consequence of the fact that the RRC establishment cause is not able to uniquely identify a CS speech at this early stage of the call progression.

Redirection is not triggered if the UE already has an established RRC connection prior to invoking the MO call request (for example when a PS call is already established).

7-15


RRC Connection Rejection


RRC Connection Rejected (cause)


RTWP > Maximum UL Interference Level

RNC Overload

waitTimeOnRrcConnectionRejection (ServiceInit)

timeReject (RadioAccessService)

RNC

waitTime3Gto2GRedirectFailure (FDDCell)

Redirection Failure

In case RRC connection or 2G redirection fails, the UE will re-attempt a call in 3G, and this up to N300 times. However, the UE is required to wait (at least) a predetermined time before the subsequent attempt on the 3G network. This wait time is sent by the RNC to the UE in the Wait Time IE in the RRC Connection Reject message.

Subsequent call attempts may or may not be redirected to the 2G network, depending on whether the initial cause for RRC Redirection still persists on the 3G UTRAN.

The Wait Time parameter will be set to the value associated with one of the following parameters:

• timeReject. If the admission failure which causes the redirection is “RNC overload”.

• waitTimeOnRrcConnectionRejection. If the admission failure which causes the redirection is not “RNC overload”.

• waitTime3Gto2GRedirectFailure. In the case of a “3G-2G Emergency Redirection”.

7-16


FACH Power Adjustment

isFachPowerAdjustmentEnabled (CallAccessPerformanceCon f)

isFachPowerAdjustmentActivated (FDDCell)

Feature Activation absoluteMaxFachPower

initialFachPowerAdjustment

fachTransmitPowerLevelStep

fachPowerAdjustmentCpichEcNoThreshold

fachPowerAdjustmentCpichRscpThreshold

Feature Parameters (CallAccessPerformanceConf)

second RRC

Connection Setup

third RRC Connection

Setupfirst RRC Connection

SetupP-CPICH all other FACH

messages

Maximum FACHpower

Starting UA4.1, it is proposed to adjust the FACH power while sending the RRC Connection Setup message based on the CPICH Ec/No measurement received from the RRC Connection Request message. The preferred power setting change is only applied to the FACH frames which carry RRC Connection Setup message. For other messages, RNC should set the power setting level to the nominal value.

Once the FACH power adjustment is required for the first RRC Connection Setup, at every next subsequent repetitions (i.e. T351 expiration), the FACH power is further stepped up.

The feature is activated both at the RNC (isFachPowerAdjustmentEnabled) and FddCell level (isFachPowerAdjustmentActivated).

If the quality measurements of either Ec/No (by default) or RSCP is below the threshold, the FACH power adjustment will be performed.

7-17


RRC Connection Setup RepetitionUE RNC-IN RNC-CN

RRC Connection Request (TM) (CPICH Ec/No)

RRC Connection SetupRRC Connection Setup (UM)

RRC Connection Setup Complete (AM)

RRC Connection Setup (UM) RRC Connection Setup



t351

t351

t351 / n351 Based Repetition

t351 (CallAccessPerformanceConf)

n351 (CallAccessPerformanceConf)

Quick Repeat

isQuickPepeatActivated (FDDCell)

isQuickPepeatAllowed (CallAccessPerformanceConf)

numberOfQuickRepeat (CallAccessPerformanceConf)

deltaCpichEcNoUsedQuickRepeat (CallAccessPerformanceC onf)

deltaCpichRscpUsedQuickRepeat (CallAccessPerformance Conf)

The RRC Connection Setup message is sent over CCCH/FACH in RLC UM mode. Without its retransmission, the message could be lost over the air due to the bad RF conditions. The objective of this feature is to provide the RRC Connection Setup message retransmission functionality if RRC Connection Setup Complete message from the UE has not been received within the duration of T351 timer.

The retransmission of RRC Connection Setup message based on a quicker timer T351 than T300 reduces the call setup duration. By reducing the need of the UE to submit another RRC Connection Request message as a result of the expiry of timer T300, this feature has a positive impact to the RACH capacity.

Thi feature provides quick repetition functionality of the RRC Connection Setup message without waiting for the acknowledgement from the UE (RRC Connection Setup Complete message).

The quick repetition of the RRC Connection Setup is activated based on the P-CPICH Ec/No measurement received from the RRC Connection Request message reported by the UE. If quality measurements are below a certain threshold, the likelihood of high BLER on the FACH channel is increased, thus reducing the probability of RRC Connection Setup being successfully received by the UE, since it is sent on RLC UM. In order to increase the probability of successful RRC Connection Setup transmission, the message is quick-repeated, that is to say, without waiting for an acknowledgement.

7-18

Student notes

7-19


RAB Matching Principles

7-20


RAB Request vs. UserServices Config.

Service Request

RNC Core NetworkService Request

RAB Assignment RequestRB = ???

DlUserService UlUserService UlRbSetConfDlRbSetConf ServiceInit

RadioAccessService

UserServices

Several Access Stratum configurations are supported.

They are split between downlink and uplink and may be dissymmetric.

At the RNC, each access stratum configuration is identified by an access stratum configuration Identifier or UserServiceId. This identifier characterizes a set of radio bearers that are linked through a common radio configuration, including therefore a signaling radio bearer (SRB) and a set of traffic Radio Bearers (RBs).

The objective of the RAB matching algorithm is to translate the RAB parameters specified in the RAB ASSIGNMENT REQUEST received from the Core Network into a pre-defined RAB supported in the RNC.

The requested RAB is matched to the closest RAB provisioned in RNC, using the RAB matching algorithm.

7-21


RAB Matching Main StepsUE Capability Establishment CauseRequested RAB

Candidate RBSet Selection

UE Capability Check

TrCH Type Selection

IRM Selection (DL)

RBSet List Construction

UserServices Matching

UE Capability Check

Target UserServices

RAB to RBset Matching

RBset to UserServices Matching

Reference UserServices

RB Adaptation Initialization (UL)

RAB Matching is done at call establishment. For soft handover, only resource reservation and Call Access Control are performed.

The above diagram describes the main steps of the RAB Matching algorithm used starting UA4.1.

Step 1: RAB to RBset Matching

• UL & DL RBs are selected according to the RAB Request and stored in a RB set,

• this RB list is filtered according to UE capabilities.

Step 2: Transport Channel Type Selection

• DCH or FACH is selected according to the establishment cause.

Step 3: iRM RAB to RB Mapping (DL only)

• a DL Target RB is elected among all the selected RBs of the RBset.

Step 4: RBset to User Services Matching

• Target User Services are extracted and explicitly defined from the RBsets,

• Reference User Services are extracted and explicitly defined from the RBsets.

7-22

Student notes

7-23


RAB to RBset Matching

7-24


UL Candidate RBsetDL Candidate RBset

Candidate RBset SelectionCore Network

RAB Assignment Request

• Maximum Bit Rate• Guaranteed Bit Rate• UMTS Traffic Class• A/R Priority Level• ...

enabledForRABMatching (DlRbSetConf)

enabledForRABMatching (UlRbSetConf)

RNC

UlRbSetConfDlRbSetConf

RadioAccessService

Candidate RBset Selection

DL Reference RB UL Reference RB

The Purpose of this algorithm is to get as output a radio bearer table containing all the acceptable Radio Bearers (DL Candidate RBset and UL Candidate RBset) among which one is marked as the Reference RB in Ul & DL. These RBsets also include the RBs to be used for Always On and iRM Scheduling (when applicable).

From all Radio Bearers defined in the RNC, the RNC selects the Radio Bearers (DlRbSetConf and UlRbSetConf) having the following properties:

• It is eligible to RbSet Matching (enabledForRabMatching),

• The Traffic Class corresponds to the requested Traffic Class,

• The Bit Rate is compliant with the RBset selection criteria (see next slide).

For PS Calls, the rule is to sort all eligible radio bearers in decreasing bit rate order, and to select the reference radio bearer as being the first element in the top of the list.

Other radio bearers are kept as fallback radio bearers.

7-25


Candidate RBset Selection Algorithm


• Maximum Bit Rate• Guaranteed Bit Rate• UMTS Traffic Class• A/R Priority Level• ...

Traffic Class=

Conversational

Bit Rate (RbSetConf)=

Maximum Bit Rate (RAB Assignment Request)

Traffic Class=

Streaming

Bit Rate (RbSetConf)≥

Guaranteed Bit Rate (RAB Assignment Request)

Traffic Class=

Interactive/Background

Bit Rate (RbSetConf)≤

Maximum Bit Rate (RAB Assignment Request)

Candidate RBset Selection

UL Candidate RbSet

DL Candidate RbSet

Example

• CS MaxBitRate = 12.2k• PS MaxBitRate = 384k• CS Speech + PS I/B• A/R Priority Level = 2• ...

Candidate RBset SelectionDL Candidate RbSet

• PS 384k (Ref)• PS 128k• PS 64k• PS 32k• CS 12.2k (Ref.)

UL Candidate RbSet

• PS 64k (Ref.)• PS 32k• CS 12.2k (Ref.)

UE Capability Check

From all Radio Bearers defined in the RNC, the RNC selected the Radio Bearers (DlRbSetConf and UlRbSetConf) having the following properties:

• It is eligible to RbSet Matching (Parameter EnabledForRabMatching)

• The Traffic Class corresponds to the requested Traffic Class and:

—If Traffic Class = Conversational and Source = Speech (Speech case)

– Bit Rate (RbSetConf) = MaxBitRate (rabParam)

– Bit Rate (RbSetConf) ≥ Guaranteed Bit Rate (rabParam)

—If Traffic Class = Streaming

– Bit Rate (RbSetConf) ≥ Guaranteed Bit Rate (rabParam)

—If Traffic Class = Interactive or Background

– Bit Rate (RbSetConf) ≤ MaxBitRate (rabParam)

The Candidate RBset Selection produces two Radio Bearers lists (one list for UL andone list for DL) that are further filtered according to UE capability.

7-26

Student notes

7-27


Target RAB Determination

7-28


UL RB Rate Adaptation InitializationRequested RAB

RAB to RBset Matching (UL/DL)

DL iRM

RBset to UserServices Matching (UL/DL)

Resource Reservation&

Admission Control

UL bit rate limitation

Reference UL bit rate

Initial UL bit rate

Target RAB (DL/UL)

Reference DL bit rate

iRM DL bit rate

If Reference UL bit rate > Max UL bit rateThen Initial UL bit rate = Max UL bit rateElse Initial UL bit rate = Reference UL bit rate

128128 38438464643232

RB Rate Adaptation (UL/DL)

isUlRbRateAdaptationAllowed(RadioAccessService)

maxUlEstablishmentRate(CacConfClass)

RB adaptation based on traffic is a feature introducing PS I/B RB bit rate downsizing/upsizing based on user estimated average throughput.

DL and UL rate adaptation are performed independently.

In UL, user is initially admitted at a configurable low bit rate. As there is no iRM CAC in UL, it could lead to a quick congestion of UL radio resources. Consequently the allocated UL PS RB is limited at the RAB Establishment even if the user is requesting more. Once the RAB established, it may be possible to upsize the RB to UL PS 384 kbps if needed thanks to RB Adaptation.

The parameter maxUlEstablishmentRbRate specifies the maximum UL rate, which may be allocated at service establishment time (RANAP RAB Assignment Request) or after relocation (RANAP Relocation Request). This parameter is significant when isUlRbRateAdaptationAllowed of RadioAccessService object is set to True.

In DL, user is initially admitted at a bit rate determined by RAB Matching and iRM.

7-29


DL IRM RB Selection Algorithm

Cell Color

Code LoadPower LoadIub Load

3

Radio Link Color

2 RL Quality

A/R Priority Level4

1

DL Candidate RbSet

(Ref.)

DL Candidate RbSet

(Ref.)

(Target)

BronzeBronze

GoldGoldSilverSilver

IRM Tables5

This step is applied only in downlink.

The iRM tables use is based on the evaluation of:

• Radio Link Color of the primary cell: based on CPICH Ec/No and CPICH RSCP reported in the RRC Measurements that indicates the radio conditions. The two colors Green and Red represent respectively good radio conditions and bad radio conditions.

• Cell Color: worst color of the cells in the active set that indicates the load of a given cell. Color computation is based on the downlink OVSF code tree occupancy, the downlink power used versus the available power and the Iub load. The three colors (green, yellow and red) are distinguished, green color meaning that the cell is not loaded, and red color indicating a loaded cell.

Once computed, the target downlink radio bearer is flagged as Target Radio Bearer.

7-30


IRM on Radio Link Condition

Bad RL Condition

Good RL Condition

Then

isIrmOnRlConditionAllowed(RadioAccessService)

Yes

Else

irmDlPowerThreshold (IrmOnRlConditionParameters)- CPICH_Ec/No <

If

irmDlcoverageThreshold (IrmOnRlConditionParameters)CPICH_RSCP >

And

No?

dlRbSetConfId(IrmOnRlConditionParameters)

cacConfId (FDDCell) cacConfId (FDDCell)

Good RL Condition

RB selection based on UE radio condition provides the link color based on radio link conditions evaluated through RRC measurements.

During transition from cell FACH state to Cell DCH state, CPICH RSCP is not reported by the UE, therefore:

• the coverage criterion (IrmDlCoverageThreshold) is ignored,

• the Radio link color evaluation is then based only on CPICH Ec/No measurements as reported on the last RACH message.

Link color calculation is based on the following algorithm:

• if (-CPICH Ec/N0 primary < IRMDlPowerThreshold) and (CPICH RSCP > IRMDlCoverageThreshold),

• then link color = green,

• else link color = red.

The Link Color, output of this algorithm is used as an input for the RAB to RB mapping (iRM table).

7-31


IRM on Cell Color

Code Color Power Color

Radio Color

Code LoadThresholds

Power LoadThresholds

IRM Tables

Yes

No? Radio Color = GreenisIrmOnCellColourAllowed

(RadioAccessService)

cacConfId (FDDCell) cacConfId (FDDCell)

isDlIubTransportLoadColourCalculationEnabled(RadioAccessService)

Iub LoadThresholds

nodeBConfClassId (NodeB)

Iub Color

?

Cell Color

Yes

NoIub Color = Green

To manage RAB allocation based on cell color, the cell color is derived from a load calculation based on OVSF tree and DL power occupancy. Hence it provides means for a better management of cell resources.

At each allocation/release/reconfiguration of resources, the RNC 1000 calculates:

• code color calculation based on OVSF code tree occupancy load

• power color calculation based on DL cell power usage

• cell color calculation based on code and / or power color.

This cell color is then used to derive the active set color which is an input to iRMtable (in case of soft HandOver).

7-32


Cell Color Calculation

Worst

green2yellowCLCthreshold(IrmOnCellColourParameters)

yellow2redCLCthreshold(IrmOnCellColourParameters)

yellow2greenCLCthreshold(IrmOnCellColourParameters)

red2yellowCLCthreshold(IrmOnCellColourParameters)

70 %

60 %

50 %

40 %

green2yellowPLCthreshold(IrmOnCellColourParameters)

yellow2redPLCthreshold(IrmOnCellColourParameters)

yellow2greenPLCthreshold(IrmOnCellColourParameters)

red2yellowPLCthreshold(IrmOnCellColourParameters)

70 %

60 %

50 %

40 %

green2yellowDlTLCthreshold(IrmIubTransportLoadParameters)

yellow2redDlTLCthreshold(IrmIubTransportLoadParameters)

yellow2greenDlTLCthreshold(IrmIubTransportLoadParameters)

red2yellowDlTLCthreshold(IrmIubTransportLoadParameters)

90 %

80 %

70 %

60 %

Power Load

Code Load

Iub Load

Worst Cell Color

Radio Color

Iub Color

The code load color is based on the weighted number of free codes (neither used, nor reserved, nor blocked i.e. son or parent of used or reserved).

In DL the number of Spreading Factors is 7 (OVSF tree goes from SF=4 to SF=256).The Code Load Color is then derived based on this Code Load and the current color.

The power load is considered as a secondary criterion for cell color, in cases where the cell power is expected to be in shortage (i.e.. multiple cells sharing the same Power Amplifier). The power load color is calculated as follows:

• power usage ratio = DL power used / DL power available

Where DL power used being the output of “BTS power self tuning” and DL power available is the total power available for traffic in the cell, also called traffic_power.

The Power Load Color is then derived based on this Power Load and the current color.

The determination of Iub load for iRM is done for the DL direction, thanks to real time observation of traffic at ATM layer.

The traffic measured is averaged over a window of 10s.

The Iub load can take also into account the parameters qosBWReservation which are used since UA4.1, to reserve bandwidth per QoS in the AAL2 CAC mechanism when “CAC method” is set to “per QoS”.

∑=AllSF actorSpreadingF

actorSpreadingFeeCodesPerNumberOfFrtorsreadingFacNumberOfSp

CodeLoad1

7-33


Cell Color / Active Set Color Calculation

Code Color

Power Color

Worst

Cell 1

Cell N

Worst

Active Set Color

Red

Green Yellow

+ =+ =+ =

Worst

Cell Color

Red

Green Yellow

Cell Color

Red

Green Yellow

Worst

Iub Color

Cell load color calculation

This block allows to take into account code, power and Iub occupancy in the calculation of cell color.

The cell load color is calculated as follows:

• cell load color = Worst (radio load color, iub load color)

• radio load color = Worst (code load color, power load color)

Active set cell load color calculation

When the call is in soft handover, the color taken into account is the active set color defined as the worst color between the colors of the cells present in the active set. The active set load color is calculated as follows:

• active set color = Worst (cell(i) color, i Є [1..N])

where cell(i) is the cell of the active set and N is the active set size.

7-34


DL Target RB Determination

DlRbSetConf

RadioAccessService

RlCondition

CellColors

ARPriorityLevel

Cell color Green

Cell color Yellow

Cell color Red

Cell color Green

Cell color Yellow

Cell color Red

gold 384 384 128 128 128 64silver 384 384 128 128 64 32

bronze 384 128 64 64 32 8gold 256 256 128 128 128 64silver 256 256 64 128 64 32



bronze 64 32 8 32 32 8

Radio Link = Bad

384

DL Ref RB OLS

256

64

128

Radio Link = Good

priorityLevel(ARPriorityLevel)

irmDlRbSetId(ARPriorityLevel)

The RAB to RB mapping function consists in defining the target RB Set that will replace the Reference RB.

For each triplet {DlRbSetConf, RLCondition, CellColors}, the following parameters are defined and determine the behavior of the iRM Table:

• IrmDlRbSefID: indicates the identity of the DL RB to substitute to the matched RB. This is the output of the algorithm.

• PriorityLevel: indicates the Olympic Level Services priority of the request.

7-35


IRM Tables (example)DlRbSetConf/PSDTCH384K

CellColor/cellColorYellow

ARPriorityLevel/0

priorityLevel=2

irmDlRbSetConfId=PSDTCH384K

ARPriorityLevel/1

priorityLevel=1


ARPriorityLevel/2

priorityLevel = 3


RlCondition/rlGood

ARPriorityLevel/0

priorityLevel=2


ARPriorityLevel/1

priorityLevel=1


ARPriorityLevel/2

priorityLevel = 3


ARPriorityLevel/0

priorityLevel=2

irmDlRbSetConfId=SRBinCellFACH

ARPriorityLevel/1

priorityLevel=1


ARPriorityLevel/2

priorityLevel = 3


ARPriorityLevel/0

priorityLevel=2


ARPriorityLevel/1

priorityLevel=1


ARPriorityLevel/2

priorityLevel = 3


ARPriorityLevel/0

priorityLevel=2


ARPriorityLevel/1

priorityLevel=1


ARPriorityLevel/2

priorityLevel = 3


ARPriorityLevel/0

priorityLevel=2


ARPriorityLevel/1

priorityLevel=1


ARPriorityLevel/2

priorityLevel = 3


CellColor/cellColorRed

CellColor/cellColorGreen

RlCondition/rlBad

CellColor/cellColorYellow

CellColor/cellColorRed

CellColor/cellColorGreen

The slide above shows an example of an iRM table configuration sample.

Note

Starting UA4.2 all the RBs of the Radio Access Service subtree are directly identified with their instance label (and no longer with an integer). There is also a similar evolution for the identification of the RlCondition and CellColor instances.

7-36

Student notes

7-37


Resource Reservation & Admission Control

7-38


UL Radio Load Control

isShoCacOnNodebLoadAtRncAllowed (RadioAccessService)

maxCellRadius (FDDCell)

ulCost (static)

ulCapacityThreshold

Established RLsUL Cost

New RLUL Cost

RNC

UL Cost < UL Capacity Threshold

Yes No

Call is accepted Call is rejected

PS 384 UEI

PS 128 UEJ

PS 128 UEK

PS 128 UEK

UL Cost

(FDDCell)

Uplink radio admission control for high data rate calls has been introduced together with the UL PS384 RAB in order to enable an uplink call admission control mechanism and thus avoid UL congestion.

Lab tests show that in ideal radio conditions three PS I/B 384 generate a noise rise higher than 3 dB (corresponding to 50% of UL Load). Beyond 75% load the system is no longer stable and it could lead to significant neighboring cells interference, cell coverage reduction and mobiles call drop.

As UL interference measurement has an accuracy of 3 dB which is not suitable to detect an UL radio overload, the solution is to define a cost per UL RAB and a total UL capacity threshold.

At each allocation, release or reconfiguration of an UL resource, the UL load is incremented, decremented or adjusted in function of the source and target UL RAB cost.

This UL capacity pool is compared to a configurable threshold: if below this target, the call is accepted, otherwise it is refused.

7-39


Transport Resource Reservation

Radio Bearer

Radio Bearer

Iub Bearer

Iub Bearer

Iur

Bea

rer

Iu-CS Bearer

Iu-PS Bearer

iubIurTransportQosId (DL/ULRbSetConf)

iuCsTransportQosId (DL/ULRbSetConf)

dscp (DscpPerOlympicService)

priorityLevel (DscpPerOlympicService)

Transport resources reservation consists in selecting the QoS identifier corresponding to the requested radio bearer. The QoS identifier is configured at the Access OAM according to the traffic class of the radio bearer.

Based on the QoS identifier required for the radio bearer requested, the RNC will request and reserve a CID (Channel IDentifier) i.e. a transport channel on the Iub, Iur, Iu-CS.

Transport channel on Iu-PS are reserved according to the DSCP. The DSCP (DiffServ Code Point) is deduced from the traffic class and the allocation/retention level (OLS for the interactive and background RABs). The RNC is mapping each DiffServ class on one ATM quality of service over the Iu-PS (namely CBR, VBR-rt, VBR-nrt, UBR).

7-40


AAL2 Call Admission Control

384 kbps

8 kbps

384 kbps

EBR(384 kbps) EBR(384 kbps) EBR(384 kbps)EBR(8 kbps)A

AL2

CA

C E

BR

AA

L2 C

AC

EB

RR

B M

BR

truefalse

384 kbps

8 kbps

384 kbpsRB

MB

R

aal2IfQoS0

QoS1

SHARED

ACR(QoS1) x qoS1BWReservation (aal2If)

CacMethod (aal2If)

ACR(QoS0) x qoS0BWReservation (aal2If)

isAal2BearerRenegotiationAllowed (RadioAccessService)

qos aal2If

ACR(aal2If)

AAL2 CAC ensures that the admission of new calls does not cause traffic to exceed the provisioned ATM bandwidth in either UL or DL. AAL2 CAC can be done per aal2If or per QoS according to the CacMethod chosen.

Each RB has a cost called Equivalent Bit Rate that represents the bandwidth to be reserved. Available bandwidth (called Available Cell Rate) is estimated by the RNC based on the ATM Traffic Descriptors (PCR, SCR).

ACR(QoS) = Sum(ECR GCAC) on all AAL2 VCCs for the given QoS

• for CBR: ECR GCAC = PCR

• for VBR: ECR GCAC = 2 x PCR x SCR / (PCR + SCR)

ACR(aal2If) =Sum(ACR(QoS)) on all QoS in use on the aal2If

The new connection is accepted when:

If CACMethod=aal2If:

• EBR(new connection on aal2If) + EBR(current connections on aal2If) ≤ ACR(aal2If)

If CACMethod=QoS (example of new DS connection):

�If EBR(current NDS) < qos1BwReservation x ACR(NDS)

EBR(new DS) + EBR(current DS) < ACR(DS) + (1-qos1BwReservation)ACR(NDS)

Else:

EBR(new DS) + EBR(current DS) + EBR(current NDS) < ACR(DS) + ACR(NDS)

Starting UA4.1, EBR reservation will be adjusted when a RB is downgraded or upgraded because of RRM decision (AAL2 CAC not only played at CID request).

7-41


Algorithm Selection

Pres = Pmax - algo1DeltaTargetPower

Pres = Pini + algo2DeltaTargetPower

Pini = pcpichPower + initialDlEcnoTarget – CPICH_Ec/No

dlAlgoSelector (PowerConfClass)

FDDCell

powerConfId (FDDCell)

DL Reserved Power Computation

algo1

algo2

pcpichPower (FDDCell)

maxDlTxPower (DlUsPowerConf)

algo1DeltaTargetPower (DlUsPowerConf)

algo2DeltaTargetPower (DlUsPowerConf)

initialDlEcnoTarget (DlUsPowerConf)

Pmax = pcpichPower + maxDlTxPower

After the RAB Matching and RAB Mapping algorithms are processed, the RNC estimates the necessary power to initially support the call.

This power estimation (Pres) corresponds to the power that will be reserved by the RNC if the admission criterion is passed.

Pres is calculated differently depending on which algorithm is used to perform the downlink power allocation.

• algorithm 1: Pres = pcpichPower + maxDlTxPower - algo1DeltaTargetPower

• algorithm 2: Pres = Pini + algo2DeltaTargetPower

Where:

Pini = pcpichPower + initialDlEcnoTarget – CPICH_EC/NO

The choice between these two algorithms is done through the dlAlgoSelectorparameter of the PowerConfClass object:

• with the dlAlgoSelector, the operator can decide which algorithm will be used in the different power control configuration classes,

• each FDD cell points to a specific PowerConfClass, identified by powerConfId.

7-42


DL Power Admission Criteria

P traffic

P traffic admission

callAdmissionRatio (PowerPartConfClass)maxTxPower (FDDCell)

Call Rejected

No

No

Pres is allocated

Yes

Pres

Pused

1st

minDataPowerRatio (PowerPartConfClass)

minSignallingPowerRatio (PowerPartConfClass)

minSpeechPowerRatio (PowerPartConfClass)

Pres

Pdata

2nd

2nd Admission Criterion (Data example)

Pres + Pdata ≤≤≤≤ Ptraffic_admission (1- minSpeechPowerRatio – minSignallingPowerRatio )

Yes

Pres + Pused ≤≤≤≤Ptraffic_admission

1st Admission Criterion

Traffic Power(SHO reserved)

Traffic Power

Overhead Power

(CommonChannels)

Once the downlink power Pres is assessed for the call, some admission criteria are checked by the RNC.

1st Admission Criterion

The first admission is the following:

• primary link admission (call establishment): Pres + Pused ≤ Ptraffic admission

• soft handover link addition: Pres + Pused ≤ Ptraffic

Note : Pused is the sum of the Pres of all calls being actually supported.

If this first criterion is fulfilled, the second one is checked; otherwise, the call is rejected.

2nd Admission Criterion

The second admission criterion depends on the bearer type (speech, data or signaling). This criterion is the following:

• speech: Pres + PspeechUsed ≤ Ptraffic_admission x (1 - minSignallingPowerRatio -

minDataPowerRatio)

• data: Pres + PdataUsed ≤ Ptraffic_admission x (1 - minSignallingPowerRatio -

minSpeechPowerRatio)

• signaling: Pres + PsignalingUsed ≤ Ptraffic_admission x (1 - minSpeechPowerRatio -

minDataPowerRatio)

Finally if the second admission criterion is satisfied the power Pres is reserved by the RNC. Otherwise, the call is rejected.

7-43


DL Power Self Tuning

isBtsPowerSelfTuningActivated (PowerConfClass)

Case 1Power consumption

underestimated at the RNC

Case 2Power consumption

overestimated at the RNC

Allocated Power

Measured Power

New allocatedpower

powerMargin(PowerConfClass)

Allocated Power

Measured PowerNew allocated

power

overEstimate(PowerConfClass)

Tuning of RNC power pool occupancy

The parameter isBtsPowerSelfTuningActivated indicates if the power pool self-tuning must be performed or not.

If self-tuning is allowed 2 cases must be considered:

• Power consumption underestimated at the RNC: In this case it is proposed to update the allocated power (power consumed as seen by the RNC) based on the measured power (as measured by the NodeB) plus a powerMargin.

• Power consumption overestimated at the RNC: The power consumption is confirmed as overestimated if the difference between the measured and allocated is above an overEstimate threshold. In that case, the new allocated power (power consumed as seen by the RNC) is made equal to the measured power (as reported by the NodeB).

7-44


OVSF Codes Reservation & Admission

Alcatel-Lucent

S-CCPCHC64,1

Alcatel-Lucent

PICHC256,3

Alcatel-Lucent

AICHC256,2

3GPPP-CCPCHC256,1

3GPPP-CPICHC256,0

SourceChannelOVSF Code

SF4

SF8

SF16

SF32

SF64

SF128

SF256

CommonChannels

OVSF Codes Allocation

Spreading Factor (SIB 5)

Code Number (SIB 5)

Channelization Code (SIB 5)

Channelization Code (SIB 5)

The channelization codes are OVSF (Orthogonal Variable Spreading Factor) codes that preserves the orthogonality between different physical channels. The OVSF codes can be defined using a code tree.

In the code tree the channelization codes are uniquely described as CSF,k, where SF is the Spreading Factor of the code and k the code number, 0 <= k <= SF-1.

The codes generated within the same layer constitute a set of orthogonal codes. Furthermore, any two codes of different layers are orthogonal except when one of the two codes is a father code of the other. For example C4,3 is not orthogonal with C1,0 and C2,1, but is orthogonal with C2,0.

Scrambling enables neighboring cells to use the same channelization codes. This allows the system to use a maximum of 512 OVSF in each cell. Notice that the use of an OVSF forbid the use of the other codes of its branch. This considerably reduces the number of available codes especially for fast rate service. This may lead to OVSF shortage. For such a case, secondary scrambling codes are allocated to cells and enable to re-use the same OVSF in the same cell.

The admission is performed depending on the availability of the code required by the service that has been granted to the UE after negotiation and RAB to RB mapping. If the required code is available, the call is admitted and the code is allocated.

The RNC is searching for a code by going from top to down. The first available code at the spreading factor requested is allocated to the user.

7-45


CN-involved Directed Retry for Speech

RNC Core NetworkService Request


is3Gto2GVoiceCallRedirectOnRabEstabFailAllowed

(RadioAccessService)

callsEligibleFor3Gto2GVoiceCallRedirectOnRabEstabFail(RadioAccessService)

IFSpeech Call

ANDis3Gto2GVoiceCallRedirectOnRabEstabFailAllowed = TRUE

ANDBlind 2G neighbor configured (and HO allowed/possib le)

ANDUE in Cell_DCH

THENDirected Retry triggered

RAB Assignment Response(failure cause = Directed Retry)

Relocation Required(CGI)

Service Request

During the normal processing of the RAB Assignment Request, RNC attempts to transition the SRB to a SRB+TRB performing the usual RAB admission controls. If failure occurs RNC checks the following (Directed Retry enabling criteria):

• call is a Speech call,

• parameter is3Gto2GVoiceCallRedirectOnRabEstabFailAllowed is set to TRUE,

• UE is 2G capable,

• RNC is configured to allow HO to 2G,

• a blind target 2G cell is provisioned,

• current RRC connection state is Cell_DCH.

If criteria are met, RNC responds to CN with a failure indication in the RAB Assignment Response, with a cause value of “Directed Retry”. RNC also sends CN a RANAP Relocation Required message, including the identity of the 2G target cell, and the cause “Directed Retry”. The usual 3G-2G Blind Hard Handover procedures follows.

Directed Retry may be triggered while a PS session is in progress depending on the UE state and on callsEligibleFor3Gto2GVoiceCallRedirectOnRabEstabFail value:

• 3GTo2GRedirectCsOnly; no Directed Retry with a PS session in progress,

• 3GTo2GRedirectCsPlusAnyPs; Directed Retry is triggered independently of PS,

• 3GTo2GRedirectCsPlusPsAlwaysOnDownsized; Directed Retry only triggered for PS sessions in the Always On downsized state (in cell_DCH).

7-46

Student notes

7-47


CELL_FACH Admission Control

7-48


CELL_FACH Admission Control

IDLE

CELL_DCH CELL_FACHSRB + RB

CELL_DCH CELL_FACHSRB ONLY


Cell Update

Cell Update

AO Downsize

AO Upsize

RAB Assignment

CELL_FACH Admission Events

Buc

ket O

ccup

ancy

CELL_FACHAdmission Control

MaxNumberOfUsersPerMacC(CacOnFachParam)

trbEstThreshold(CacOnFachParam)

Each cell can only accept a limited number of simultaneous UE in the CELL_FACH state:

• Each mobile being on CELL_FACH is allocated a token.

• Each time a CELL_FACH admission is tried in a given cell, the current number of used token is compared to a specific threshold. If below the threshold, the admission is successful and a token is allocated.

There are 2 thresholds used according to the reason for CELL_FACH admission. In the Alcatel-Lucent implementation, they are defined as:

• MaxNumberofUsersPerMacC (signaling dealing with Cell_FACH state as RRC Connection Request, Cell Update – with at least one SRB allocated-)

• trbEstThreshold (transition from Cell_DCH state to Cell_FACH due to Always-On feature).

These parameters are set at the OAM in order to give a higher precedence to a new incoming call (RRC connection request) rather than to a mobile already in call and aiming to transition from Cell_DCH to Cell_FACH.

7-49

Student notes

7-50

Student notes

8-1


Packet Data Management

Section 8

8-2


Objectives


> Describe packet data management principles

> Describe Always On and associated parameters

> Describe iRM Scheduling and associated parameters

> Describe iRM Preemption and associated parameters

8-3


Contents

> Packet Data Management Overview

> Always On

> RB Rate Adaptation

> iRM Scheduling

> iRM Preemption

8-4

Student notes

8-5


Packet Data Management Overview

8-6


Packet Data Management Mechanisms

Dedicated Channel

Dedicated Channel

Dedicated Channel

UMTS R99

��

��

��

��

��

RB Rate Adaptation

��PSBackground

��PSInteractive

��PSStreaming

��CSStreaming

��CSConversational

iRM PreemptioniRM SchedulingAlways OnDomainService Class

Packet Data Management is a set of reactive mechanisms performed during the call in order to satisfy three objectives:

• Increase capacity of the system by taking advantage of user traffic burstiness: Always On mechanism adapts the resources allocated to users according to their activity (two steps mechanism depending on whether there is low traffic or no traffic at all).

• Increase capacity of the system by taking advantage of user traffic burstiness: RB Rate Adaptation saves more capacity by matching dynamically the RB bit rate as close as possible to the real user traffic. It allows to adapt the bandwidth for services requiring more than the Always-On downsized RB but less than the current RB.

• Improve retainability of the calls: iRM Scheduling adapts the resources to the radio conditions fluctuation. iRM Scheduling downgrading secures the call by reducing the amount of downlink power required in degraded radio conditions, whereas iRM Scheduling upgrading enhances subscriber experienced quality byproviding a higher throughput when radio conditions improve.

• Increase capacity at the expense of call retainability: iRM Preemption allows to reduce the bit rate of low priority users or even to pre-empt them in order to increase the admission success rate of CS calls or high priority users in congested situation. It is performed when all other preventive congestion mechanisms are not sufficient to free resources quickly enough to maintain sufficient accessibility to the network.

These Packet Data Management features operate only on UMTS PS I/B RABs since no Guaranteed Bit Rate is defined for such traffic classes.

8-7


Always On

8-8


Always On Principles

Throughput Threshold

User Traffic Volume

Time

T1

AO timers

T1 T2

T1 T1 T1 T2

CELL_DCHCELL_DCHCELL_DCH

orCELL_FACH

PMMPMM--idleidle

NOMINAL RBNOMINAL RB AO Downsized RB

UE State

Radio Bearer No Radio

Dedicated radio resources are not optimal to support packet services with sporadic traffic. In order to find the best trade-off between efficient resource usage and subscriber comfort, the Always On concept developed is composed of two steps.

After a first period of inactivity, the bearer is reconfigured to a predefined downsized bearer configuration, which consumes less radio resources.

If traffic activity is detected, the bearer is upgraded back to its initial configuration (or to a degraded one if network congestion is meanwhile detected). If no traffic activity is detected during a second period of time, then the radio bearer is released.

There are two ways to implement Always On:

• AO on CELL_DCH, the downsized radio bearer uses dedicated resource,

• AO on CELL_FACH, the downsized radio bearer uses common resource.

8-9


Always On Algorithms

low trafficUL AND DL

AO DownsizeCELL_DCH

AO DownsizeCELL_FACH

AO UpsizeAO Release

traffic resumingUL OR DL

no trafficUL AND DL

RLC/MAC Buffer Occupancy Monitoring

Traffic Volume Monitoring

Traffic volume monitoring

DCH RB FACH RBOR

isAlwaysOnAllowed (AlwaysOnConf)

preferredTransportTypeForAlwaysOn (AlwaysOnConf)

low trafficUL AND DL

The downsized radio bearer uses a dedicated resource: CELL_DCH or CELL_FACH to support the downsized radio bearer configuration on common channels.

This allows a more efficient use of radio resources through statistical multiplexing of data on common resources.

When downsize criteria is met, the Always-On downsized RB (on DCH or FACH) is determined at the OAM, thanks to the following parameters:

• DL downsized RB: alwaysOnDlRbSetId (AlwaysOnConf object).

• UL downsized RB: alwaysOnUlRbSetId (AlwaysOnConf object).

8-10


Always On on DCH Parameters

step2ThroughputThreshold (AoOnDchParam)

timerT2 (AlwaysOnTimer)

T2

step2AverageWindow (AoOnDchParam)

T1

step1ThroughputThreshold (AoOnDchParam)


step1AverageWindow (AoOnDchParam)

alwaysOnUlRbSetDchId (AlwaysOnConf)

alwaysOnDlRbSetDchId (AlwaysOnConf)

Ul & DL Traffic Volume

NOMINAL RBNOMINAL RB AO Downsized RB No Radio

step1TimerBetween2Reports (AoOnDchParam)

priorityLevel (AlwaysOnTimer)

The downsize condition is based on DL and UL traffic volume monitoring on non-sliding time windows. The downsize criterion is met if:

• (TBsize x NbTB) / Step1AverageWindow < Step1ThresholdThroughput

during at least TimerT1.

With:

• NbTB: Number of Transport Blocks transferred during the time window,

• TBsize: size of a L1 Transport Block (in bits).

AO Downsize is performed when UL and DL criteria are met.

The upsize condition is also based on DL and UL traffic volume monitoring on non-sliding time windows. The upsize criterion is met if:

• (TBsize x NbTB) / Step1AverageWindow > Step1ThresholdThroughput.

AO Upsize is performed when UL or DL criteria are met.

The release decision is based on DL and UL traffic volume monitoring on non-sliding time windows. The release criterion is met if:

• (TBsize x NbTB) / Step2AverageWindow < Step2ThresholdThroughput

• at least during TimerT2 seconds.

AO Transition to Idle Mode is performed when UL and DL criteria are met.

8-11


Always On on FACH Parameters

step2ThroughputThreshold (AoOnFachParam)


T2

step2AverageWindow (AoOnFachParam)

T1

step1DlUlThroughputThreshold (AoOnFachParam)


step1AverageWindow (AoOnFachParam)

alwaysOnUlRbSetFachId (AlwaysOnConf)

alwaysOnDlRbSetFachId (AlwaysOnConf)

Ul & DL Traffic Volume

NOMINAL RBNOMINAL RB AO Downsized RB No Radio

step1TimerBetween2Reports (AoOnFachParam)

priorityLevel (AlwaysOnTimer)

The decision process for CELL_FACH transition follows the same principles as for DCH rate adaptation, the main difference relates to the fact that the downsized channel is allocated on FACH.

The Downsize and Release conditions are the same as for AO on DCH except that the throughput threshold name used in step1 (Downgrade phase) has a different name: Step1UlDlThroughputThreshold.

As the upsize conditions are applied as the mobile is using common UL and DL resources (RACH/FACH) these conditions cannot be based on observed user traffic. The principle is that these conditions will be based on RLC buffer occupancy, reflecting the state of congestion of the transport channel (see following two slides).

8-12


AO on FACH UL Upsize Parameters

Reporting event4a

DCH

Upsize

repThreshold (AoOnFachParam)

UE RLC/MAC Buffer OccupancyReporting

event4a

timeToTrigger (AoOnFachParam)

FACH

pendTimeAfterTrig (AoOnFachParam)

Report

The UL upsize condition relies on event triggered UE traffic volume measurement on RACH Transport Channel, based on event 4A.

As the sum of Buffer Occupancies of RBs multiplexed onto the RACH exceeds a certain threshold (RepThreshold), the mobile performs an event triggered reporting.

On reception of this event, the SRNC considers the UL upsize condition as fulfilled.

The pendTimeAfterTrig timer is started in the UE when a measurement report has been triggered by a given event. The UE is then forbidden to send new measurement reports triggered by the same event during this time period. Instead the UE waits until the timer has expired.

The timeToTrigger timer is started in the UE when the Transport Channel Traffic Volume triggers the event. If the TCTV crosses the threshold before the timer expires, the timer is stopped. If the timer expires then a report is triggered.

8-13


AO on FACH DL Upsize Parameters

step1DlRlcBoThreshold (AoOnFachParam)

Upsize

UpsizeRequired

RLC/MAC Buffer Occupancy per UE

DCHFACH

step1TimerBetween2Reports (AoOnFachParam)

The DL upsize condition relies on the same kind of mechanism. As the sum of Buffer Occupancies of RBs multiplexed onto the FACH exceeds a certain threshold for a given UE, the SRNC considered the DL upsize condition as fulfilled.

The parameter Step1TimerBetween2Reports is used to avoid sending unnecessary “upsize required” event reports during the execution of the upsize procedure. This parameter sets the minimum time between the emissions of two events "upsize required" by the RNC-IN.

8-14


Always On for Multi-Service CS+PS RAB

PS I/BPS I/BCELL_DCHCELL_DCH PMMPMM--idleidle

CS+PS I/BCS+PS I/BCELL_DCHCELL_DCH CS+PMMCS+PMM--idleidle

Traffic Resuming

Downsizing / Upsizing

Downsizing / Upsizing

No Traffic

Traffic Resuming

No Traffic

PS AOCELL_DCH

orCELL_FACH

CS+PS AOCELL_DCH

Add CS

Release CS

If a CS and a PS RAB are active simultaneously, PS RAB rate adaptation process is performed to the (CS + downsized PS) configuration.

Since the mobile cannot be in CELL_FACH state for PS and in CELL_DCH for CS at the same time, the only possible multi-service (CS + downsized PS) configuration is CS + PS AO RAB on Cell_DCH.

Thus, if a CS call is setup during an on-going PS service in Always On downsized (DCH8/8 or Cell_FACH), the resulting multiservice configuration will CS + PS 8/8.

On the other hand, if a CS call is release while an on-going PS service is in AO downsized, there is a direct transition to the single PS AO downsized state (on CELL_FACH or CELL_DCH).

In case of CS+PS configuration, if the transition to idle mode criteria is fulfilled, the PS part of the call is disconnected, so that the UE is in:

• PMM-Idle state for its PS part

• MM-Connected for its CS part.

8-15


timerT2ForStreamingRab

timerT2ForMultiRab

preferredTransportTypeForAlwaysOn

alwaysOnUlRbSetDchId

alwaysOnDlRbSetDchId

alwaysOnUlRbSetFachId

alwaysOnDlRbSetFachId

User Services Parameters RNC

DlRbSetConf UlRbSetConfDlUserService UlUserService AlwaysOnConf

AlwaysOnTimer

isAlwaysOnAllowed isAlwaysOnAllowed

disabled ��

degraded2AlwaysOnOnly ��

releaseOnly ��

true ��false ��

The Radio Bearers used for the downsized state are provided in the AlwaysOnConfobject, including the type of downsize (Cell_DCH or Cell_FACH).

The list of user services that are eligible to Always On is given through the parameter isAlwaysOnAllowed in DlUserService and UlUserService objects.

The parameter isAlwaysOnAllowed in DlRbSetConf and UlRbSetConf objects determines the behavior of each Radio Bearer when the always on downsize is triggered. It can take the following values:

• degraded2AlwaysOnOnly means that the downsize is allowed and the target radio bearers are determined by the parameters of the AlwaysOnConf object.

• ReleaseOnly means that there is no intermediate downsize for this Radio Bearer. The Radio Bearer is released when the release conditions are met.

• Disabled means that the Always On feature is disabled for this Radio Bearer.

8-16

Student notes

8-17


RB Rate Adaptation

8-18


RB Rate Adaptation PrinciplesRequested RAB

RAB to RBset Matching (UL/DL)

DL iRM

RBset to UserServices Matching (UL/DL)

CAC

UL bit rate limitation

Reference UL bit rate

Initial UL bit rate

Target RB (DL/UL)

Reference DL bit rate

iRM DL bit rate

128128 38438464643232

RB Resizing (UL/DL)

isUlRbRateAdaptationAllowed(RadioAccessService)

isDlRbRateAdaptationAllowed(RadioAccessService)

rbRateAdaptationPinPongTimer(RadioAccessService)

maxUlEstablishmentRate(CacConfClass)

Current RB (DL/UL)

Traffic Monitoring (UL/DL)

EstimatedThroughput

(DL/UL)Adapted RB

(DL/UL)

RB Rate Adaptation (UL/DL)

RB Rate Adaptation is applicable to UL and DL Interactive and Background PS, it introduces RB rate downsizing/upsizing based on user estimated average throughput.

RNC monitors DL and UL traffics and determines if the current RB bit rate needs to be downsized or upsized to accurately match the actual traffic.

• Downsizing

RNC targets the bit rate as close as possible to the estimated throughput

• UpsizingUplink: RNC targets the bit rate immediately above the current bit rate (step-by-step upsize).

Downlink: RNC targets any rate (multi-stages upsize), based on user throughput and RLC buffer occupancy. The targeted RB bit rate should never exceed the Reference RB bit rate.

DL and UL rate adaptation are performed independently.

In UL, the parameter maxUlEstablishmentRbRate specifies the maximum UL rate at call admission. This parameter is significant when isUlRbRateAdaptationAllowed of RadioAccessService object is set to True.

In DL, user is initially admitted at a bit rate determined by RAB Matching and iRM.

8-19


Traffic Monitoring Principles

ββββδδδδ ≤≤≤≤KtKR

S,

[[[[ ]]]]∑∑∑∑−−−−

========

1

0

1 K

k

kRateK

R [[[[ ]]]](((( ))))∑∑∑∑−−−−

====−−−−

−−−−====

1

0

22

11 K

k

RkRateK

S

time

Rate[0]=0Rate[1]=0Rate[2]=0

T0

Rate[0]=0Rate[1]=0Rate[2]=N 0/T

T1

Rate[0]=0Rate[1]=N 0/TRate[2]=N 1/T

T2

Rate[0]=N 0/TRate[1]=N 1/TRate[2]=N 2/T

T3

Rate[0]=N 1/TRate[1]=N 2/TRate[2]=N 3/T

T4

Throughput Estimates

raUnitPeriodTime(DlRbRaTrafficMonitoring)

raNbOfSample(DlRbRaTrafficMonitoring)

raUnitPeriodTime(UlRbRaTrafficMonitoring)

raNbOfSample(UlRbRaTrafficMonitoring)

raMaxConfidenceInt(DlRbRaTrafficMonitoring)

raModifiedStudentCoef(DlRbRaTrafficMonitoring)

raMaxConfidenceInt(UlRbRaTrafficMonitoring)

raModifiedStudentCoef(UlRbRaTrafficMonitoring)

��Reliable Throughput Estimate

Confidence Level

RLC-SDUthroughput

Confidence Interval = 2 ββββ

throughput Estimate

The traffic monitoring function consists in calculating the average throughput over a time window and to estimate the confidence level of the observed throughput.

The algorithm used is the same in DL and in UL. The average throughput is estimated at RLC level excluding retransmissions and acknowledgements.

The algorithm first computes periodically the user throughput over a period of time T (raUnitPeriodOfTime) as Rate =N/T where N is the number of RLC-SDU bits transmitted for the first time during T.

Traffic estimates are then based on a sliding window of size K (raNumberOfSample).

The estimation of the average throughput R and of the throughput variance S is derived over the last K samples Rate[k], where each value R[k] corresponding to a throughput value calculated during a period of time T (see above slide formulas corresponding to an example with K = 3).

The estimated throughput is supposed to follow a Student-t distribution with K degrees of freedom. The throughput estimate is considered as reliable if the probability for the real throughput to be out of the interval of confidence is smaller than a determined threshold (see above slide formulas).

When the throughput estimate is considered as reliable, RB rate adaptation resizing process is triggered, otherwise no action is taken.

8-20


DL Downsizing

no downsizeno downsize

downsize to DL32downsize to DL32



DL384

DL128

DL64

DL32

time

TDOWN256

TDOWN128

TDOWN64

isDlRbRateAdaptationAllowedForThisDlUserService(DlUserService)

isDlRbRateAdaptationAllowedForThisDlRbSetConf(DlRbSetConf)

isThisRbRateAdaptationDlRbSetTargetAllowed(DlRbSetConf)

dlRbRateAdaptationDownsizeThreshold(DlRbSetConf)

DL384DL384 DL256DL256 DL128DL128 DL64DL64 DL32DL32

DL iRM

Reference RB

MIN (Adapted RB, IRM RB)

Allocated RB

TDOWN384


DL256

RLC-SDU Average Throughput

The RB Rate Adaptation process can downsize a RB from the current RB rate down to any smaller RB (all transitions towards smaller RB are possible except to PS 8k, which is not eligible as target).

Based on Traffic Monitoring, the RNC takes the decision to downsize when the following criteria, periodically checked, are verified:

• the observed average throughput is lower than some defined thresholds,

• the confidence level of the estimated average throughput is good enough to consider the observation as reliable.

The RB adaptation process can downsize a RB from the current RB rate down to any RB with lower bit rate but the allocated RB is always constrained by the iRM table selection.

8-21


UL Downsizing

UL384UL384 UL128UL128 UL64UL64 UL32UL32

no downsizeno downsize

downsize to UL32downsize to UL32



UL384

UL128

UL64

UL32


time

TDOWN384

TDOWN128

TDOWN64

isUlRbRateAdaptationAllowedForThisUlUserService(UlUserService)

isUlRbRateAdaptationAllowedForThisUlRbSetConf(UlRbSetConf)

isThisRbRateAdaptationUlRbSetTargetAllowed(UlRbSetConf)

ulRbRateAdaptationDownsizeThreshold(UlRbSetConf)

The RB adaptation process can downsize a Radio Bearer from the current RB rate down to any smaller rate (all transitions towards smaller RB are possible except to PS 8 kbps).

Based on Traffic Monitoring, the RNC takes the decision to downsize when the following criteria, periodically checked, are verified:

• the observed average throughput is lower than some defined thresholds,

• the confidence level of the estimated average throughput is good enough to regard the observation as reliable.

Same criteria and mechanisms as for DL RB Rate Adaptation downsizing apply.

8-22


DL Multi-Stage Upsizing

no upsizeno upsize

upsize of DL32upsize of DL32



time

TUP128

TUP64

TUP32

DL384

DL128

DL64

DL32

DL256upsize of DL256upsize of DL256

DL384DL384 DL256DL256 DL128DL128 DL64DL64 DL32DL32

DL iRM

Reference RB

Allocated RB

isDlRbRateAdaptationAllowedForThisDlUserService(DlUserService)

isDlRbRateAdaptationAllowedForThisDlRbSetConf(DlRbSetConf)

isThisRbRateAdaptationDlRbSetTargetAllowed(DlRbSetConf)

dlRbRateAdaptationUpsizeThreshold(DlRbSetConf)

raSduQueueThreshold(DlRbSetConf)

Current RB

MAX [ MIN (Adapted RB, IRM RB), Current RB ]


RLCRLC--SDUSDUbufferbuffer

QUP128

QUP384

QUP256

QUP64

Multi-stages Upsize avoids successive reconfigurations intermediate bit rates in order to reach directly the most suitable RB rate.

The RB adaptation process can upsize a RB from the current RB rate up to any RB with higher bit rate but the allocated RB is always lower or equal to the Reference RB and is constrained by the iRM table selection.

Based on Traffic Monitoring, the RNC takes the decision to upsize according to the following criteria periodically checked:

• the observed average throughput is higher than some thresholds,

• the confidence level of the estimated average throughput is good enough to consider the observation as reliable,

• RLC-SDU buffer occupancy is higher than some thresholds.

The RNC selects the target RB according to the DL RLC-SDU buffer occupancy. It compares the current value of the RLC buffer occupancy to some thresholds in order to find the highest RB for which the following condition is met:

RLC-SDU Buffer Occupancy ≥ raSduQueueThreshold,

If no RB higher than the current RB meets this condition, the upsize is not performed, it means that there is few data awaiting for transmission.

8-23


UL Step by Step Upsizing

UL384UL384 UL128UL128 UL64UL64 UL32UL32 UL8UL8

isUlRbRateAdaptationAllowedForThisUlUserService(UlUserService)

isUlRbRateAdaptationAllowedForThisUlRbSetConf(UlRbSetConf)

isThisRbRateAdaptationUlRbSetTargetAllowed(UlRbSetConf)

ulRbRateAdaptationUpsizeThreshold(UlRbSetConf)

no upsizeno upsize

upsize of UL32upsize of UL32



UL384

UL128

UL64

UL32

time

TUP128

TUP64

TUP32


A step-by-step upsize scheme applies for the UL RB Rate Adaptation.

It means that the only possible transitions are from the current RB to a target RB which is the very next RB in terms of bit rate. In this case, the RNC selects the bit rate immediately above the current one since the Traffic Monitoring can only indicate that current bit rate is not big enough.

There is no forecast on the future traffic based on the UE RLC buffer occupancy (and consequently multi-stage upsize is not possible).

Based on Traffic Monitoring, the RNC takes the decision to upsize when following criteria, periodically checked, are verified:

• The observed average throughput is lower than some defined thresholds,

• The confidence level of the estimated average throughput is good enough to consider the observation as reliable.

The allocated UL bit rate can never exceed the Reference RB bit rate.

8-24

Student notes

8-25


iRM Scheduling

8-26


iRM Scheduling Principles

Nominal RBNominal RB

Fallback RBFallback RB

NodeB

DL 384 kbit/s

DL 128 kbit/s

DL 64 kbit/s

Intermediate RB

Downgrade

Upgrade

isRlcMacBasedIrmSchedulingAllowed (RadioAccessService)

isIrmSchedulingAllowed (DlUserService)

flipFlopUpDowngradeTimer (RadioAccessService)

isIrmSchedDowngradeTxcpAllowed(RadioAccessService)

The iRM Scheduling mechanism is based on two sequential procedures triggered to adapt user throughput when he goes alternatively through good and bad radio conditions:

• iRM Scheduling Downgrade reduces bit rate when radio conditions are getting bad,

• iRM Scheduling Upgrade increases bit rate when radio conditions are getting better.

There are two possible triggers for IRM Scheduling Downgrade:

• iRM Scheduling Downgrade based on radio condition: trigger is based on an observable quantity representative of the BLER at the RLC level,

• iRM Scheduling Downgrade based on Transmit Code Power: trigger is based on a measurement done by the NodeB. The dedicated measurement is performed on the primary cell and concerns the Downlink Transmitted Code Power.

iRM Scheduling Downgrade can only be applied in DL on PS RB mapped onto DCH (it does not apply to PS RB mapped on HSDSCH).

The trigger based on TxCP dedicated measurement can only be applied if the primary cell is handled by the serving RNC (the trigger based on TxCP is not supported over Iur). When dedicated measurement can not be configured, the trigger based on RLC layer has to be configured to keep the PS RB eligible to iRMScheduling Downgrade. The two triggers are mutually exclusive: iRM Scheduling Downgrade is based on one unique trigger.

8-27


Use of Fallback TFCS

iRM Scheduling Downgrade – BLER based

DL PS384

timeToTrigger (IrmSchedulingConf)

fallbackThroughput (IrmSchedulingconf)

rlcMacObservableThreshold

DL PS64

rlcMacObservable(t)

radioQualityMeasurementQuantity (irmSchedulingConf)

irmTimerBetween2reports (IrmSchedulingConf)

Reconfiguration to Fallback RB

targetDlRbSetForIrmScheduling (IrmSchedulingconf)

Bearer downgrade may be triggered during the call by observing the BLER on the RLC/MAC. A bloc retransmission rate denoted rlcObservable is estimated. At each retransmission, the rlcObservable is evaluated and compared to the rlcObservableThreshold, which is derived from BLER threshold configuration parameters. When it exceeds a threshold, bad radio conditions are detected. If theses radio conditions remain bad during a significant period, bearer fallback is triggered.On detection of bad conditions, the RNC takes two parallel actions:

• It reduces the Transport Format Combination Set so that it limits the bit rate on user data, decreasing the power needed in the next TTIs. This should allow the call to survive during the execution phase of Radio Bearer reconfiguration.

• It starts a Synchronous Radio Link Reconfiguration (SRLR) towards a target configuration still offering the same signaling capacity but lower user bit rate and handled by a physical channel with a higher spreading factor.

NoteiRM Scheduling downgrade is applicable to PS I/B high bit rate calls that are also managed by Always On. It is necessary to manage the interworking between iRMscheduling and AO, since they both may trigger a downgrade but for different reasons.

Thus as soon as TFCS is reduced AO monitoring is stopped. After completion of the reconfiguration, a Traffic Radio Bearer with its nominal TFCS is used and hence Always On usual downsize monitoring resumes.

8-28


Event A for iRM Scheduling Downgrade

Transmitted Code Power Event AReport

Primary Cell

TxCPThreshold

Event A Timer

dlIrmSchedDowngradeTxcpTrigger_threshold_delta (DlUsPowerConf)

dlIrmSchedDowngradeTxcpTrigger_timeToTrigger (DlUsPowerConf)

Event A Timer

pcpichPower (FDDCell) + maxDlTxPower (DlUsPowerConf) - dlIrmSchedDowngradeTxcpTrigger_threshold_delta (DlUsPowerConf)

isIrmSchedDowngradeTxcpAllowed (DlUsPowerConf)

For iRM Scheduling Downgrade based on TxCP, the detection of degradation in radio conditions relies on the monitoring of the DL Transmitted Code Power (TxCP). The TxCP trigger is based on NBAP Dedicated Measurement (type Event A) performed by the NodeB handling the primary cell.

When the transmitted code power (TxCP) rises above a threshold (TxCP threshold) during the hysteresis time (timeToTrigger), a Dedicated Measurement Report is sent by the NodeB to the RNC (Event A).

Event A configuration relies on:

• Measurement Threshold: the relative transmitted code power threshold given by the parameter dlIrmSchedDowngradeTxcpTrigger_threshold_data is used to compute the absolute TxCP Threshold together with the parameters pcpichPower(FDDCell) and maxDlTxPower (DlUsPowerConf).

• Measurement Hysteresis: dlIrmSchedDowngradeTxcpTrigger_timeToTrigger.

8-29


iRM Scheduling Downgrade – TxCPbased

Reconfiguration to Downgraded RB

Use of Fallback TFCS

DL PS384

DL PS64

Event A

irmSchedDowngradeTxcpMaxBitRate (RadioAccessService)

RNC

RBset to User Services Matching

PS 8

PS 32

PS 64

PS 128

PS 256

PS 384

DlRbSetConf

On detection of bad radio conditions (reception of event A report sent by the NodeB), the RNC takes two parallel actions:

• reduction of the Transport Format Combination Set to limit the bitrate of the PS RB,

• start of a SRLR (Synchronous Radio Link Reconfiguration) towards a RB target offering the same signaling capacity but lower bit rate for PS traffic.

The determination of the target RB for downgrade relies on usual RBset to User Services Matching except that for iRM Scheduling Downgrade based on TxCP this step runs on a list of DlRbSetConf reduced to the DlRbSetConf for which the bit rate is lower than the value of irmSchedDowngradeTxcpMaxBitRate.

The IRM tables are not read during the iRM Scheduling Downgrade.

8-30


Event Bx for iRM Scheduling Upgrade

Event B2 Timer

Transmitted Code Power Event B1Report

Primary Cell

Event B1 Timer

Event B2Report



deltaThresholdTransCodePower (DhighRbB2)

deltaTimeToTrigger (DhighRbB2)

128

384

64 384 128Upgrade

Event B2Threshold

Event B1Threshold

When a UE is using the RB assigned by IRM Scheduling downgrade, the RNC configures two types of NBAP dedicated measurement by event B report for this UE on the primary cell.



• Measurement Threshold: absolute transmitted code power threshold given by the parameter thresholdTransCodePower,

• Measurement Hysteresis: given by the parameter timeToTrigger.

So, Event B1 is reported when the transmitted code power falls below thresholdTransCodePower during at least timeToTrigger.


• Measurement Threshold: absolute transmitted code power threshold given by thresholdTransCodePower + deltaThresholdTransCodePower,

• Measurement Hysteresis: given by timeToTrigger+ deltaTimeToTrigger.

So, event B2 is reported when the transmitted code power falls below thresholdTransCodePower + deltaThresholdTransCodePower during at least timeToTrigger+ deltaTimeToTrigger.

8-31


iRM Scheduling Upgrade

isIrmSchedulingUpgradeAllowed (RadioAccessService)

isIrmSchedulingUpgradeAllowedFromThisUS (DlUserService)

isIrmSchedulingUpgradeAllowedToThisUS (DlUserService)

highBitRate (DhighRbB1)



intermediateRate (MediumRbB2)

deltaThresholdTransCodePower (MediumRbB2)

deltaTimeToTrigger (MediumRbB2)

Granted RB

Event BxProcessingEvent Bx

Cell colorRL Condition

Min

iRM tables

iRM RB

Power RB

Requested RB

OLS

Any user becomes eligible to iRM Scheduling upgrade as soon as it experiences an iRM Scheduling downgrade. It means that after the RB reconfiguration bringing to the downgrade, the RNC configures and activates the NBAP dedicated measurement report on the primary cell, so as to track the transmitted code power (see section 4).

On reception of the NBAP Dedicated Measurement Report, the SRNC executes the RAB matching function taking into account that the Power RB (H or I), corresponding to the event reported (B1 or B2), will be the highest rate able to be allocated to this mobile.

On reception of the NBAP Dedicated Measurement report, the RNC proceeds to the Synchronous Radio Link Reconfiguration (SRLR) if the Granted RB is different from the current one. Is so the anti ping-pong timer flipFlopUpDowngradeTimer is started.

This timer should allow slow ping-pong phenomena between upgrading and downgrading if observed. At its expiry, a NBAP dedicated measurement can be initiated if in the meantime an iRM scheduling downgrade has been performed for the mobile.

8-32


isIrmSchedulingUpgradeAllowedFromThisUS = true

intermediateRate = 128

isIrmSchedulingUpgradeAllowedToThisUS = true

highBitRate = 384

isIrmSchedulingUpgradeAllowedToThisUS = true

targetDlRbSetForIrmScheduling = 3

iRM Scheduling RAB Configuration

IrmSchedulingUpgrade

MediumRbB2 DHighRbB1128 384

RNC

DlRbSetConf/7

IrmSchedulingConf

DlRbSetConf/3

64

Downgrade

Upgrade

isIrmSchedulingAllowed = true

isTransCodePowerIrmSchedulingDowngradeAllowedFromThisUserService = true

DlUserService/7384

isIrmSchedulingAllowed: This parameter indicates if the iRM Scheduling is allowed for the given DlUserService.

targetDlRbSetForIrmScheduling: The synchronized radio link reconfiguration that may be triggered by iRM Scheduling leads to replace the current downlink radio bearer by this downlink radio bearer.

isIrmSchedulingUpgradeAllowedFromThisUS indicates whether iRM Scheduling upgrade is permitted from this DlUserService to a higher grade of DlUserService.

IrmSchedulingUpgradeAllowedFromThisUS could be set to True only for DLUserServices that correspond to the targetDlRbsetForIrmScheduling.

isIrmSchedulingUpgradeAllowedToThisUS indicates whether iRM Scheduling upgrade is permitted from a lower grade of DlUserService to this DlUserService.

highBitRate corresponds to the maximum high bit rate for upgrading.

intermediateRate corresponds to the intermediate rate for the medium RB rate of event B2 dedicated measurement.

isTransCodePowerIrmSchedulingDowngradeAllowedFromThisDlUserService indicates if the Access Stratum Service configuration can be eligible for iRMscheduling downgrade Power (TxCP).

8-33


iRM Preemption

8-34


iRM Preemption Algorithm

Cell Color

2

A/R Priority Level

1 Current DL RB Downgraded DL RB

3

SilverSilver

IRM Tables4

BronzeBronze

GoldGoldisIrmPreemptionAllowed (RadioAccessService)

isIrmPreemptionAllowedForGoldUsers (IrmPreemption)

isIrmPreemptionAllowedForSilverUsers(IrmPreemption)

isIrmPreemptionAllowedForBronzeUsers(IrmPreemption)

Code LoadPower LoadIub Load

The purpose of the iRM Preemption is to keep some resources available when the cell becomes loaded. iRM Preemption is a reactive process performed when all other preventive congestion solutions are not sufficient to free OVSF codes and power resources quickly to maintain sufficient accessibility to the network.

The preemption procedure is applicable to specific users having PS Interactive/Background connection in CELL_DCH according to their OLS level.

However, no specific feature is dedicated to the radio bearer upsizing for the preempted users. But they may retrieve the initial requested radio bearer after any reconfiguration (CS release, CS establishment when a PS connection on-going, iRMscheduling upgrade, AO upsizing…) except the AO downsize and iRM scheduling downgrade procedures.

Thus, iRM Preemption completes the existing congestion prevention iRM RAB to RB Mapping feature by implementing a reactive congestion management at the cell level.

8-35


iRM Preemption RB Configuration

DlRbSetConf

RadioAccessService

RlCondition

CellColors

ARPriorityLevel

BAD

RED

Cell color Green

Cell color Yellow

Cell color Red

Cell color Green

Cell color Yellow

Cell color Red

gold 384 384 128 128 128 64silver 384 384 128 128 64 32




bronze 64 32 8 32 32 8

Radio Link = Bad

384

DL Ref RB OLS

256

64

128

Radio Link = Good

iRM Preemption Downgrade Target DL Radio Bearers

The target Radio Bearers for iRM Preemption are defined using the iRM Tables. They

correspond to the Radio Bearers UE would have received if UE were admitted as the Radio

Link Condition was Bad and the Cell Color was Red.

Therefore users eligible to iRM preemption are users whose current DL Bit Rate is higher

than the one defined in the iRM Tables for bad radio conditions and loaded cells.

As iRM tables are constructed making use of A/R Priority, iRM Preemption offers the

possibility to preempt users according to their OLS level.

8-36


Cell Color / Active Set Color Calculation

Code Color

Power Color

WorstWorst

Cell 1

Cell N

WorstWorst

Active Set Color

Cell Color

Cell Color

WorstWorst

Iub Color

+

=

WorstWorst

Black

White

Black

White

Black

White

normal2congestedPLCThreshold(IrmPreemptionCacParams)

congested2normalPLCThreshold(IrmPreemptionCacParams)

normal2congestedCLCThreshold(IrmPreemptionCacParams)

congested2normalCLCThreshold(IrmPreemptionCacParams)

normal2CongestedDlTLCThreshold(IrmPreemptionIubTransportLoadParameters)

congested2NormalDlTLCThreshold(IrmPreemptionIubTransportLoadParameters)

The transition from normal to congested state is computed when one of the following thresholds is overpassed:

• normal2CongestedCLCThreshold (for codes),

• normal2CongestedPLCThreshol (for power),

• normal2CongestedDlTLCThreshold (for Iub).

In order to avoid any ping pong effect between the congested and normal states, due to strong variations in the radio resources allocation, the hysteresis cycle relies on additional thresholds characterizing the congested to normal transition through the parameters:

• congested2NormalCLCThreshold (for codes),

• congested2NormalPLCThreshold (for power),

• normal2CongestedDlTLCThreshold (for Iub).

In case of soft handover, the active set color is derived from the color of each cell.

8-37


iRM Preemption Behavior

irmPreemptionColorCheckingTimer (IrmPreemption)

PS I/B Connection

UE 1

UE 2

UE N

time

Preemption Start

Color Check Checking Timer

AS Color

Black

White

As soon as a downlink PS I/B radio bearer is allocated to a UE the iRM preemption timer assigned to each eligible mobile is armed. At each UE timer expiration, the cell preemption color is checked, and if the cell is congested, the eligible user is preempted if the following condition based on the bit rate comparison is fulfilled:

If

• current DL RB bit rate > bit rate of the target RB given by the iRM table with Radio

• Link Condition = bad and Cell Color = Red, relating to the user OLS,

Then

• preemption is processed and the downgrade is performed.

8-38


Interaction with iRM RAB to RB Mapping

Radio Color

Iub Color

Cell Color

WorstWorst

Black

White

Preemption Color

Radio Color

Iub Color

Cell Color

Worst

iRM Color

Red

Green Yellow

The iRM Preemption cell color determination algorithm is similar to the one already implemented for the iRM RAB to RB Mapping feature based on the cell color evaluation. However, it implies some specific thresholds relating to the calculation of the code load, power load and Iub load. Consequently it has an independent mechanism from the one used for iRM CAC.

The addition of the new colors (Black and White) is made for preemption purpose only.

It has no effect on iRM RAB to RB Mapping process applied at call admission or on RB reconfiguration.

8-39

Student notes

8-40

Student notes

9-1


Power Management

Section 9

9-2


Objectives


> Describe power management static configuration

> Describe PRACH Power Control and associated parameters

> Describe UL Power Control and associated parameters

> Describe DL Power Control and associated parameters

9-3


Contents

> Power Management Static Settings

> PRACH Power Control

> UL DPCCH Open Loop Power Control

> UL Outer Loop Power Control

> UL Inner Loop Power Control

> DL Traffic Channels Power

> DL Outer Loop Power Control

> DL Inner Loop Power Control

9-4

Student notes

9-5


Power Management Static Settings

9-6


Cell Downlink Power Settings

F1

F2

maximumPowerAmplification (BtsCell)

PaRatio (BtsCell)

Cell Setup

MaxTxPower (FDDCell) = MIN ( , MaxDlPowerCapability)MaxTxPower (FDDCell)

MaxTxPower (FDDCell)

PaRatio (BtsCell)

maximumPowerAmplification (BtsCell)MaxDlPowerCapability = PaRatio (BtsCell)x - Global Losses

At the cell setup, the RNC calculates the max Tx Power which is the maximum power that will be used to configure the cell:

• Max Tx Power (FDDCell) = min (Max Tx Power Required, Max DL Power capability)

At the NodeB level, the power is owned by Power Amplifiers which can be shared by multiple cells.

In Alcatel-Lucent configurations, cells on the same sector but on different carriers may share or not the same Power Amplifier. This capability should allow to optimize the use of the PA. The sharing of power between different cells associated to the same PA is static. A configuration parameter at the OMC-B (called PA_Ratio) allows to share a PA power between 2 cells. From RNC perspective, the sharing is transparent.

Example:

Local Cells 1 and 2 respectively on F1 and F2 frequencies sharing PA1 (power P1)

PA_Ratio (Local Cell 1) = 50% , PA_Ratio (Local Cell 2) = 50%

The NodeB will then derive the Max DL Power Capability available for these LocalCell1 and 2 and provides it to the RNC through NodeB resource notification message.

Max DL Power Capability (Local Cell) = (PA_Ratio (Local Cell) x PA Power) - Global Losses.

9-7


Cables Losses without TMA

externalAttenuationXXXDl = 0

MCPA Tx Splitter DDM

BTS

Reference point

Global Losses = Internal Losses

externalAttenuationXXXDl ≠≠≠≠ 0


BTS

Reference point

Global Losses = Internal Losses + externalAttenuationXXXDl

externalAttenuationMainDl (AntennaAccess)

externalAttenuationDivDl (AntennaAccess)


Computation of losses is not the same depending on:

• parameters externalAttenuationMainDl and externalAttenuationDivDl of the AntennaAccess object,

• TMA configuration.

Cable Losses without TMA.

If externalAttenuationXXXDl = 0, the transmission power reference point is defined at the antenna connector of the BTS. In this case the Global Losses refer only to internal cabling losses (typical value = 0.8 dB) and DDM insertion losses (typical value = 0.5 dB).

For OTSR configurations additional losses must be taken into account:

• Tx Splitter insertion losses (typical value = 0.3 dB)

• Additional cabling between Tx Splitter and DDM (typical value = 0.3 dB).

If externalAttenuationXXXDl ≠ 0, the transmission power reference point is defined at the antenna connector after the RF feeder (antenna side).

In this case, the reference point is the point so that losses between the BTS feeder connector (out put of the cabinet) and this point are equal to the datafilled value of externalAttenuationXXXDl.

9-8


externalAttenuationXXXDl ≠≠≠≠ 0


BTS

Reference point

Global Losses = Internal Losses + externalAttenuationXXXDl + TMA Insertion Losses + Jumper Losses

TMA

Cables Losses with TMAexternalAttenuationMainDl (AntennaAccess)

externalAttenuationDivDl (AntennaAccess)


externalAttenuationXXXDl = 0


BTS

Reference point

Global Losses = Internal Losses + Feeder Losses + TMA Insertion Losses + Jumper Losses

TMA

When a TMA is specified (tmaAccessType = tmaUmtsOnly or tmaMix), the transmission power reference point moves to the antenna port of the TMA. Additional losses are taken into account:

• TMA insertion losses are equal to 0.3 dB in the transmission path,

• jumper losses are set to 2*0.6 dB (0.6 dB for each jumper).

If externalAttenuationXXXDl is set to 0, the feeder losses are equal to 2 dB. Otherwise the feeder losses are equal to the datafilled value of externalAttenuationXXXDl .

9-9


Common Channel Power Settings

Traffic Power (SHO

reserved)

Traffic Power

Overhead Power

(Common Channels)

PCHpichPowerRelativeToPcpichPICH

RACHaichPowerRelativeToPcpichAICH

SCCPCHsccpchPowerRelativeToPcpichS-CCPCH

FDDCellbchPowerRelativeToPcpichP-CCPCH

FDDCellsschPowerRelativeToPcpichS-SCH

FDDCellpschPowerRelativeToPcpichP-SCH

FDDCellpcpichPowerPCPICH

ObjectparameterChannel

NodeB

In the overhead, the Pilot power, i.e. the P-CPICH power is defined by the pcpichPower parameter of the FDDCell object as an absolute value in dBm, referenced at the BTS antenna connector.

All the other common channel powers are given relatively to the P-CPICH level.

Because the check in the BTS (CCM) at call setup, this relationship must be true for maxTxPower and PcpichPower: PcpichPower > MaxTxPower - 15 dB.

A sensor at the output of the MCPA allows to measure the effective output power of the amplifier. The range of sensibility of this sensor is [25 dBm..46.5 dBm]. So as to be sure to detect power, it is recommended that the Pcpich Power (at PA Output) is higher than the minimum sensibility of this sensor).

PcpichPower > 25 dBm-total_losses_between_PA_output_and_reference_point

P-CPICH power is recommended to be set at:

• 35 dBm in case of one channel,

• the half (32 dBm) if two carriers are supported by the same PA.

9-10


Dedicated Channels Power Settings

DedicatedConf

RadioAccessService

PowerConfClass

DlUsPowerConf UlUsPowerConf

maxTxPower (FDDCell)

powerConfId (FDDCell)

minDlTxPower (DlUsPowerConf)

maxDlTxPower (DlUsPowerConf)max UE Tx Power (UE Power Class)

FACHmaxAllowedUlTxPower (UlUsPowerConf)

, Max UE Tx Power )Max UL Tx Power = MIN( maxAllowedUlTxPower (UlUsPowerConf)

Part of the Dedicated Channels power management relies on static settings.

This is for example the case in downlink for the maximum power per carrier and the upper and lower bounds of the traffic channel. It is important to note that these two last parameters are not necessarily the same for all UEs communicating in the cell as different values are used depending on the radio bearer.

Static settings are also used to define the maximum allowed transmission power in UL per User Service. It represents the total maximum output transmission power allowed for the UE and depends on the type of service required. The information will be transmitted on the FACH, mapped on the S-CCPCH, to the UE in the RADIO BEARER SETUP message of the RRC protocol.

Consequently, whenever a radio bearer is set up or reconfigured, when a transport or a physical channel is reconfigured, when a RRC connection is setup or re-established, when the active set is updated or when a handover is performed from GSM to UTRAN, a new value may be decided by the RNC (Control Node) for the parameter maxAllowedUlTxPower and this parameter shall be re-transmitted to the UE.

9-11


PRACH Power Control

9-12


PRACH Open Loop

NACK NACK NACK ACK

Message part

PRACHControl part

PRACHData part

Pini

Pini = + RTWP + - P-CPICH_RSCP

powerOffsetPO (RACH)

powerOffsetPpm (static)

sibMaxAllowedUlTxPowerOnRach (PowerConfClass)

Preamble part

betaC (static)

betaD (static)

pcpichPower (FDDCell) constantValue (RACH)

AICH

SIB 5

SIB 5

SIB 5 SIB 5

SIB 5

SIB 5

SIB 7

The PRACH consists of:

• a preamble part which is sent by the UE and repeated until an Acquisition Indicator (ack or nack) is received over AICH or the preamble retransmission counter reaches its max value (parameter provided by the network). The first preamble is transmitted with a power of “Preamble initial power”. Each consecutive preamble is transmitted with a power equal to the previous one plus a ‘power ramping step”. “Preamble initial power “is calculated by the UE based on parameters sent on SIB5 and SIB7 and on CPICH RSCP measured by the UE. “power ramping step” is a UTRAN parameter sent to the UE over SIB5,

• a message part which is sent after an acknowledged Acquisition indicator. This message part is composed of control and data part. The power of control part is equal to the power of the last preamble sent plus Pp-m which is a UTRAN parameter sent over SIB5. The power of data part is derived from the power of control part through (βc,βd) parameters per TFC also sent by the UTRAN over SIB5. βd/βc defines the relative power between control part and data part.

Notes• RTWP: corrective term evaluating the average interference level on UL. In

Alcatel-Lucent implementation, this is not a parameter; it corresponds to the UL RTWP measured by the NodeB. It is broadcast in SIB 7.

• constantValue: corrective term aiming to compensate for shadowing effects. It is broadcast in SIB 5.

9-13


UL DPCCH Open Loop Power Control

9-14


UL Dedicated Channels Synchronization

SIRAV < -3dB => OutSyncInd

SIRAV > -3dB => InSyncInd

nInSyncInd (FDDCell)nOutSyncInd (FDDCell) tRlFailure (FDDCell)

RL RestoreRL Failure

Sync OK Sync KO

INIT

nInSyncInd (FDDCell)



nOutSyncInd (FDDCell)

tRlFailure (FDDCell)

The uplink radio link sets are monitored by the NodeB, to trigger radio link failure/restore procedures. Once the radio link sets have been established, they will be in the in-sync or out-of-sync states.

When the radio link set is in the in-sync state, after receiving nOutSynchIndconsecutive out-of-sync indications, the NodeB shall:

• start timer tRlFailure;

• upon receiving nInSynchInd successive "in sync" indications from Layer1:

—Stop and reset timer tRlFailure;

• if tRlFailure expires:

—NodeB shall trigger the RL Failure procedure and indicates which radio link set is out-of-sync. When the RL Failure procedure is triggered, the state of the radio link set change to the out-of-sync state.

When the radio link set is in the out-of-sync state, after receiving nInSynchIndsuccessive in-sync indications NodeB shall trigger the RL Restore procedure and indicate which radio link set has re-established synchronization. When the RL Restore procedure is triggered, the state of the radio link set change to the in-sync state.

9-15


UL DPCCH Power Increase =

DPCCH Open Loop Power Control

Pinitial (UL DPCCH) = – P-CPICH_RSCP

First pattern

TS 0 TS 1 TS …

dlTpcPattern01Count (FDDCell)

ulTpcStepSize (UlInnerLoopConf)

0 1 0 1 0 1 0 1 0 1

Last pattern

1 0 1 0

TS 9 TS 10

Data1PLTPC

TFCI Data2 PL

DL DPCCH Tx Power Commands

dpcchPowerOffset (UlInnerLoopConf)

UL Synchronization Failed

When establishing the first DPCCH the initial power used by the UE to start the UL DPCCH transmission is:

• DPCCH_Initial_power = dpcchPowerOffset – CPICH RSCP

Where dpcchPowerOffset is a UTRAN parameter sent in the RRC message (RADIO BEARER SETUP/RECONF).

For the first Radio Link set established towards the UE (NBAP parameter “First RLS Indicator” in RADIO_LINK_SETUP message) and while the uplink synchronization is not yet achieved, a specific behavior is described allowing to delay the UL inner loop power control.

The pattern (represented twice) is continuously repeated until the UL synchronization is established. During this pattern the UE will not increase its power.

Then, UE increase its Tx power by ulTpcStepSize only if synchronization does not succeed). However it shall be restarted at the beginning of each frame where CFN mod[4] = 0.

9-16


UL Power Control Preamble

DPCCH DPCCHDPCCH DPCCH DPCCH DPCCH DPCCH

DPDCH DPDCH DPDCH

Inner Loop Power Control

pcPreamble (UlInnerLoopConf) srbDelay (UlInnerLoopConf)

betaC (SignalledGainFactor)

betaD (SignalledGainFactor)

DPCCH

EmptyDPDCH

RNCRRC Signaling

Inner Loop Power Control

Dedicated channels may use a power control preamble at the start of the transmission, in order to ensure that the inner loop power control has converged when the transmission of the data bits starts. It consists in a given number of DPCCH frames (provided through pcPreamble parameter) transmitted prior to the data transmission on DPDCH. The RNC transmits the pcPreamble parameter (number of DPCCH preamble frames) in the “Uplink DPCH power control info” IE using RRC signaling.In addition to the pcPreamble delay, the mobile should not send any data on signaling radio bearers RB0 to RB4 during the number of frames indicated in the “SRB delay” IE, sent through RRC signaling in the “Uplink DPCH power control info” IE. The SRB delay value is defined by the srbDelay parameter value.Inner loop power control is thus applied on DPCCH only, in a first time, starting from the initial DPCCH transmission power determined through the open loop power control process. Then, once pcPreamble DPCCH frames have been transmitted and srbDelay frames passed, data start to be transmitted on DPDCH at an initial transmission power deduced from the current DPCCH transmission power and DPDCH / DPCCH power difference (using betaD and betaC gain factors).Basically, the necessity to delay the power control on dedicated channels might depend on the service’s characteristics. Indeed, if the data transmission is delayed by one radio frame (in the case data are to be transmitted just after dedicated channel assignment), then it requires some data to be buffered both at Node-B and UE. Consequently, it increases the transmission delay for these data, which does not match real time service constraints for example. For the same reason, Alcatel-Lucent has decided to implement a power control preamble process on dedicated channels for all procedures except handover to UTRAN (Power control preambles are absent in handover to UTRAN command).

9-17


CSDTCH12_2Kx4SRBDCCH3_4K2PSDTCH64Kx4SRBDCCH3_4KCSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K

PSDTCH64Kx4SRBDCCH3_4KPSDTCH384Kx4SRBDCCH3_4KStandaloneSRBDCCH3_4K...



UL DPCCH / DPDCH Power Ratio

refTfcId

betaC

betaDrefTfcId

betaC

betaDrefTfcId

betaC

betaDTFC 0

ulUserServiceRNCSignalledGainFactor

ComputedGainFactor

RNC

refTfcId

refTfcId

betaC

betaD

TFC 1

TFCS #2

Signaled Mode

Computed Mode

refTfcId

betaC (SignalledGainFactor)

betaD (SignalledGainFactor)

refTfcId (SignalledGainFactor)

betaC (ComputedGainFactor)

betaD (ComputedGainFactor)

refTfcId (ComputedGainFactor)

CSDTCH64Kx4SRBDCCH3_4K

ulUserService


For a given Access Stratum configuration, corresponding to one precise UlUserService object instance, some TFCs have their betaC and betaD values defined through betaC and betaD parameters respectively, whereas some other TFCs use reference TFCs to deduce their own betaC and betaD values.

In order to give a reference identity to a TFC, to declare it as a possible reference TFC for other TFCs, an optional parameter named refTfcId (SignalledGainFactorobject) is used.

Once the reference TFCs are declared, some other TFCs of the TFCS (under the same UlUserService instance) can be provisioned as computedGainFactorsinstances (mode “computed” chosen at the OAM in the RNC MIB).

For each of them, there is a pointer on a reference TFC in order to indicate from which betaC and betaD values the TFC shall compute its own betaC and betaDvalues:

• This pointer to a reference TFC corresponds to refTfcId parameter in the computedGainFactor object.

• This parameter corresponds to the identity of a reference TFC set through refTfcId parameter in SignalledGainFactor object.

9-18


SRBDCCH3_4KCSDTCH12_2K

PSDTCH64KPSDTCH128KPSDTCH384K2PSDTCH64K...

UL Rate Matching AttributesUlRbSetConf

SRBDCCH3_4KCSDTCH12_2K


S-RNC DynamicParameterPerDCH

D-RNC

ulRateMatchingAttribute

ulRateMatchingAttribute (DynamicParameterPerDCH)

iurMinRateMatchingAttribute (DynamicParameterPerDCH)

iurMaxRateMatchingAttribute (DynamicParameterPerDCH)

DynamicParameterPerDCH

iurMinRateMatchingAttributeiurMaxRateMatchingAttribute

CSDTCH64K

UlRbSetConf

CSDTCH64K

Rate matching is done to adapt the bit rate so that after transport channel multiplexing bit rate is adapted to the capability of the underlying physical channel.

Rate matching consists in repeating or puncturing bits in the radio frame. Each Transport Channel is assigned a rate matching attribute by higher layers. This attribute is used to calculate the number of bits to be repeated or punctured.

Rate matching attribute (part of the transport format) is used to control the relative rate matching between different transport channels multiplexed together onto the same physical resource. By adjusting this attribute the quality of different services can be fine tuned to reach an equal or near-equal symbol power level requirement.

In UL rate matching may vary on a frame-to-frame basis to fill up the physical channel. Uplink rate matching attribute is strongly related to DPDCH/DPCCH power difference and therefore to the appropriate behavior of UL power control and resulting UL Quality of Service.

Note

A check is done by Drift-RNC when receiving a RNSAP Radio Link Setup message regarding the value of uplink rate matching attribute, so that the value belongs to a specific range, given by the two attributes iurMinRateMatchingAttribute and iurMaxRateMatchingAttribute.

9-19


UL Outer Loop Power Control

9-20


CSDTCH12_2K




SIR Target Management

initialUlSirTarget (UlUsPowerConf)

ulBlerTarget(DynamicParameterPerDch)

New SIR Target

(NBAP)

CRCI

RNC

PartialOLPC

ulUserService


UlRbSetConf

CSDTCH64K

SRBDCCH3_4K

ulBlerTarget(DynamicParameterPerDch)

CRCI

PartialOLPC

OLPCMaster

SIR TargetUpdate

referenceUlRbSetConfId(ReferenceUlRbSetList)

The initial SIR target is sent by the RNC to the NodeB through initialUlSirTargetparameter. This parameter is instantiated per RAB. Consequently, once the RNC has matched a RB onto the RAB requested by the Core Network, it points onto the initial SIR target value corresponding to this RB in the initialUlSirTarget parameter. This value is transmitted to the NodeB using NBAP signaling at each RADIO LINK SETUP or reconfiguration.

For each UlUserService, the list of radio bearers (UlRbSetConf) used in the multiple reference OLPC is given through the referenceUlRbSetConfId parameter.

The outer loop power control algorithm takes into account all transport channels. For each transport channel a separate outer loop machine is run. Each outer loop machine updates its partial SIR target according to its transport channel quality target (UlBlerTarget) as soon as it receives at least one transport block CRC. The partial SIR target is then sent to the outer loop power control master.

The OLPC master determines the new SIR target as:

• the maximum partial SIR target if at least one OLPC machine increases its partial SIR target,

• the minimum partial SIR target if all OLPC machines reduce their partial SIR target.

Whenever the new SIR target is different from the old one, it is sent to the NodeB.

9-21


Partial SIR Target Update

maxSirTarget (UlUsPowerConf)

minSirTarget (UlUsPowerConf)

SIR Target

TTI

transmitTimeInterval (static)

isUlOuterPCActivated (UlOuterLoopPowerCtrl)

If CRCI bad

SIR Target

If CRCI good

SIR Target

ulUpSirStep

ulUpdatePeriod (UlOuterLoopPowerCtrl)Update Period = Max [TTI of ReferenceUlRbSetList] x

ulUpSirStep (DynamicParameterPerDch)ulBlerTarget (DynamicParameterPerDch)

ulUpSirStep

1ulBlerTarget

- 1

updateThreshold (DynamicParameterPerDch)Triggered Update if SIR Variation ≥

The RNC computes actualized partial SIR targets every TTI. The TTI value in millisecond is given by the transmitTimeInterval static parameter relative to the TrCHs used as references for the outer loop power control. The reference TrCHsdepends on the service type.

Each outer loop machine updates its partial SIR target according to its transport channel quality target (UlBlerTarget) as soon as it receives at least one transport block CRC. An update from each OLPC machine to the OLPC master is sent every update period or if the SIR target variation exceeds an upper limit (updateThreshold).

The update period is defined by ulUpdatePeriod, and is provided in a number of TTIs.

Whenever the new SIR target is different from the old one, it is sent to the NodeB.

When updating the SIR target at the NodeB, the RNC sends on the user plane a specific control frame, called Outer Loop Power Control, to the NodeB. Consequently, for a given DPCCH, the period between two uplink SIR target updates cannot be shorter than the shortest TTI of the DL associated transport channels.

9-22

Student notes

9-23


UL Inner Loop Power Control

9-24


UL Inner Loop Power Control

Rake

SIRestimate

SIRTarget

> or <TPC0 or 1

Pilot

TPC

DPCCH

• Down Command : if SIR estimate > SIRtarget then TPC = 0

• Up Command :if SIR estimate < SIRtarget then TPC = 1

Uplink inner loop power control algorithm is located in the NodeB physical layer. It is a fast procedure (up to 1500 Hz power change rate) used to derive power control commands (to be applied by the UE) from the SIR target (set by the RNC) and UL measurements.

The NodeB estimates the instantaneous SIR on the pilot bits received on the UL DPCCH and compares it to the SIR target signaled by the RNC. In case the instantaneous SIR is lower (respectively higher) than the target SIR, an up (respectively down) command is sent to the UE in the downlink DPCCH TPC field of each DPCCH radio time slot:

• up command: TPC = 1

• down command: TPC = 0.

In every slot, there is either an up or a down power control command: this process does not provide a good stability of the transmission power.

TPC commands are computed in each NodeB independently from the others, so if the UE is in Soft Handover with several NodeBs, the TPC commands received from the different NodeBs may be conflicting. In the case of a softer handover, the unique involved NodeB sends the same TPC command on all the radio links of the same radio link set.

9-25


UL Power Control Algorithms

Soft handoverpossibly different TPC commands

Softer handover

identical TPC commands

for the radio link set

NodeB 2 2 RLs

NodeB 1 1 RL

SIR target 1

SIR target 2TPC2

TPC1

In case of soft HO(i.e. TPC1 ≠≠≠≠ TPC2)

UE combines TPCsaccording to the selected

algorithm

algo1 algo2

One TPC_cmd

powerCtrlAlgo (UlInnerLoopConf)

TPC2 RNC

In case of soft handover (where TPC commands come from different NodeBs), the UE has to combine different TPCs in order to derive one single internal TPC_cmd(internal power control command applied to adjust the UL transmission power).

There are 2 standardized algorithms (named: algorithm 1 and algorithm 2 in the 3GPP Specifications) for the UE to process TPC commands.

The choice between these two algorithms is under the control of the RNC 1000, and is managed through powerCtrlAlgo parameter (manufacturer parameter).

It is UE specific in the sense that a specific message is sent to each UE in order to indicate which algorithm to use, but Alcatel-Lucent sets the same value for all cells managed by an RNC.

9-26


UL Inner Loop Algorithm 1

Algorithm allows the UE to derive a single TPC_cmd per slot

1DL DPCCH TCP field 1 0 0

Algo1 output +1 +1 -1 -1

x ulTpcStepSize

1DL DPCCH TCP3 field 0 0 0

Algo1 output +1 +1 -1 -1

x ulTpcStepSize



UE Tx output power UE Tx output power


Algo 1: PC rate = 1500 Hz (T=666 µs)

• no soft HO: UE derives a TPC_cmdfrom the TPC command received for each slot

• soft HO: UE has to combine TPCsfrom different radio link sets and deduces a single TPC_cmd

• TPC_cmd = -1, +1

Soft HandOver

powerCtrlAlgo = algo1

This algorithm is well adapted for average speed UEs in urban or suburban environment. The principle of algorithm 1 is that the UE adjusts its DPCCH transmission power every slot (frequency = 1500 Hz), according to TPC_cmd (internal power control command applied to adjust the UE transmission power) derived from the TPC commands received from all NodeBs involved in the communication.

We can distinguish three cases of TPC_cmd generation:• No macrodiversity: the UE receives a single TPC command in each slot (on the single

radio link established for the communication), from which it derives a TPC_cmd as follows:

— if TPC command = 0, then TPC_cmd = -1— if TPC command = 1, then TPC_cmd = 1

• Softer handover: in this case, the UE is aware (from TPC combination index parameter transmitted through RRC protocol) that it will receive identical TPC commands in the downlink. The UE is then able to combine these commands into a single TPC command, for example (UE implementation is proprietary) using maximum ratio combining with all TPC commands received in order to optimize the TPC command decoding.

• Soft handover: in this case, the TPC commands may be different. This case may even involve a softer handover (from which a single TPC is derived, using for example MRC). The UE has first to use soft decision in order to decode the different TPC commands transmitted. Then, it has to combine them in order to deduce a single TPC_cmd value

Then, after deriving a unique TPC_cmd, the UE implements a power change based on the ulTpcStepSize parameter of the UlInnerLoopConf object.

9-27


UL Inner Loop Algorithm 2 (no SHO case)

1DL DPCCH TCP field 1 1 1

Algo2 output +1

UE Tx output power

1 0 0 0 0 0 1 1 0 0 0

-1 0

x ulTpcStepSize

5 radio slots

No Macrodiversity

Algo 2: PC rate = 300 Hz (T=3,333 ms)

• no soft HO: UE derives a TPC_cmdfrom the TPC command received on a 5 slot-cycle basis

• soft HO: UE has to combine TPCsfrom different radio link sets

• TPC_cmd = -1, 0, +1

Algorithm allows the UE to derive a single TPC_cmd

every 5 slots

powerCtrlAlgo = algo2


This algorithm is adapted to high or low speed environment (typically: dense urban or rural). With this algorithm, the UE concatenates N TPC commands received on consecutive radio slots to derive a TPC_cmd to be applied after the Nth slot. N can be different according to the handover situation, but it does always divide 15 (the combining window of the TPC commands does not extend outside the frame boundary). Allowing a decision every N = 5 radio slots instead of every slot, algorithm 2 is a way of emulating step sizes smaller than 1 dB (typically: 0.2 dB or 0.4 dB, corresponding to the step sizes of 1 and 2 dB respectively, but applied every 5 TS).

Note: In the TPC combination algorithm 2, the TPC_cmd is either 1, –1 or 0.

Algorithm 2 works in the following way:

• No macrodiversity: the UE concatenates commands received from 5 consecutive TS to derive a TPC_cmd value:

—For the first 4 slots of a set, TPC_cmd = 0

—For the fifth slot of a set, the UE uses hard decisions on each of the 5 received TPC commands as follows:

– if all 5 hard decisions within a set are 1, then TPC_cmd = 1

– if all 5 hard decisions within a set are 0, then TPC_cmd = -1

– otherwise, TPC_cmd = 0

• Softer handover: similarly to what happens for algorithm 1, for each slot, the UE soft-combines the TPC commands known to be the same (received from the same NodeB).

9-28


UL Inner Loop Algorithm 2 (SHO case)

1DL DPCCH TCPN field 1 1 1

Algo2 output

+1

UE Tx ouput power

1 0 0 0 0 0 0 0 0 0 0

-1 -1


+1

1 1 1 1 1 0 1 1 1 1 1

0 +1

1 1 1 0

0

1 0 0 0 0 0 1 0 1 0 1

-1 0

DL DPCCH TCP2 field

Sum of TPCN

> 0.5 < - 0.5 Otherwise

+ 1 - 1 0

x ulTpcStepSize

Soft handover: the derivation of the TPC_cmd from the TPC commands of the different radio links is done in the following way:

• First, the UE determines 1 temporary TPC command called TPC_tempi for each of the N sets of 5 TPC commands. It is done as follow:

—If all 5 hard decisions with in a set = 1, TPC_tempi = 1.

—If all 5 hard decisions with in a set = 0, TPC_tempi = -1.

—Otherwise, TPC_tempi = 0

• Then the UE derives the combined TPC_cmd for the 5th slot as a function of all the N TPC_tempi:

—TPC_cmd = 1 if (Sum of TPC_tempi)/N > 0.5

—TPC_cmd = -1 if (Sum of TPC_tempi)/N < -0.5

—Otherwise TPC_cmd = 0

• Finally, after deriving a unique TPC_cmd, the UE implements a power change:

—Uplink Power Change = TPC_cmd x ulTpcStepSize.

9-29


DL Traffic Channels Power

9-30


First Radio Link

SHO Leg Addition

Initial DL Traffic Channel Power

MinDlTxPower (DlUsPowerConf)

MaxDlTxPower (DlUsPowerConf)

Pinitial = + - P-CPICH_Ec/NopcpichPower (FDDCell) initialDlEcNoTarget (DlUsPowerConf)

Pinitial = + - P-CPICH_Ec/No EquivalentpcpichPower (FDDCell) initialDlEcNoTarget (DlUsPowerConf)

cell = N

P-CPICH_Ec/No Equivalent = P-CPICH_Ec/No (cell )

cell =1ΣΣΣΣ

isShoLegInitialAlgoEnabled (RadioAccessService)

When a traffic (dedicated) channel is setup, it is done at a certain downlink power called Pini defined by the following equation:

• Pini = pcpichPower + initialDlEcnoTarget – CPICH_Ec/No

Where pcpichPower is the downlink P-CPICH power, initialDlEcnoTarget depends on the service allocated to the UE (access stratum configuration) and CPICH_EC/N0 is the EC/N0 of the Pilot received by the UE.

The Pini is used in the Call Admission Control downlink power reservation algorithm.

The downlink transmission power is limited by an upper and lower limit for each radio link. This limitation is set through the maxDlTxPower and minDlTxPower parameters (DlUsPowerConf object). Both parameters provide actually a value for each access stratum configuration, so they correspond to a set of values rather than to a single value. The value (in dB) of these parameters is provided with respect to P-CPICH power defined by the pcpichPower parameter.

For SHO leg Addition, the initial power is calculated once for all the new links to be added. Pini does not only depend on the CPICH Ec/No of the selected cell to be added but of all the CPICH Ec/No of the cells of the old active set.

An equivalent CPICH Ec/N0 is calculated:

∗= ∑=

N

i

celliNEcCPICH

equivdBNEcCPICH

1

10)(0/

100/_ log10)(

9-31


DL DPCCH / DPDCH Power Offsets

Data1Pilot TPC TFCI

PinitialPO3 PO1

PO2

po3ForPilotBits (DlUserService)

DL DPDCH Radio Frame

po2ForTpcBits (DlUserService)

po1ForTfciBits (DlUserService)

The RNC can also configure in the NodeB static downlink physical channel parameters. In downlink it is possible to give power offsets to the pilot, TPC and TFCI fields of the DPCCH relatively to the DPDCH.

They are given at radio link setup in the Power Offset information IE:

• PO1: TFCI bits,

• PO2: TPC bits,

• PO3: pilot bits.

In Alcatel-Lucent implementation the power offsets used to determine the transmission power of the TFCI, TPC and PILOT bits are defined by the po1ForTfciBits, po2ForTpcBits and po3ForPilotBits parameters respectively.

These parameters of the DlUserService object are transmitted in the Power_Offset_Information IE of the RADIO LINK SETUP, ADDITION or RECONFIGURATION (NBAP signaling). They are identical for all TFC in the TFCS.

9-32

Student notes

9-33


DL Outer Loop Power Control

9-34


DL Outer Loop Power Control

Initial Quality target

DL Outer Loop Control IE

Outer LoopPower Control

SR

B

TR

B

TPC

TX

RB Setup

BLER target increase not allowedor

BLER target increase allowed

inner looppower control

QualityMeasurements

RNC

isDlReferenceTransportChannelAllowed

dlBlerQuality

CSDTCH12_2K


DlRbSetConf

CSDTCH64K

SRBDCCH3_4KisDlReferenceTransportChannelAllowed

dlBlerQuality



dlUserService


The DL outer loop power control algorithm is mobile-manufacturer specific, and DL power control outer loop is not necessarily based on SIR (like UL outer loop is). The only information signaled to the UE by the RNC is a quality target for each radio bearer, expressed as a BLER. This quality target is sent to the UE through RRC signaling (DL Outer Loop Control procedure) for each transport channel of the connection. This quality target information is mandatory for handover to UTRAN, radio bearer setup and transport channel reconfiguration messages. It is optional for radio bearer reconfiguration and release, RRC connection setup and re-establishment messages.

The DL outer loop power control algorithm is located in the UE but the RNC may further use the downlink Outer Loop control procedure to control the DL outer loop algorithm in the UE. To prevent the UE from increasing its DL BLER target value above its current value (the initial one, transmitted by the RNC via RRC signaling), the RNC sets the “Downlink Outer Loop Control” IE to “increase not allowed”. This allows reducing the impact of the UE proprietary outer loop algorithm on the system.

isDlReferenceTransportChannelAllowed indicates that the first Transport Channel of the RbSetConf is allowed to be used as an Outer Loop Power Control Reference Transport Channel.

dlBlerQuality is used if isDlReferenceTransportChannelAllowed is TRUE. dlBlerQuality is the BLER quality target which must be met during Outer Loop Power Control. It is the Log10 of the BLER.

9-35


DL Inner Loop Power Control

9-36


TPC_cmd x

DL Inner Loop Algorithm

NodeBTPC = 0 / 1 UL DPCCH

PL TPCTFCI

TPC

TPC_cmd

DL power change

New BTS output powerapplied to DPDCH

DL Power Change =

TPC =1=> TPC_cmd = +1

TPC =0 => TPC_cmd = -1

∆∆∆∆PTPC + ∆∆∆∆PBalancing

ΣΣΣΣPBAL

UE Algo

SHO

BLER est

dlTpcStepSize (DlInnerLoopConf)

BLER target

The DL inner loop power control algorithm is a fast procedure (1500 Hz) used to optimize DL transmission power by sending power control commands to the NodeB in the TPC field of UL DPCCH time slots.

At each TPC (Transmit Power Command = 0 or 1) field decoded (on UL DPCCH), the BTS estimates the TPC_cmd (TPC command = -1 or 1) based on TPC and Limited_Power_Increase values, and implements a DL power change as shown in the above slide.

As the Limited_Power_Increase functionality is not implemented, TPC_cmd values are directly deduced from TPC values as following:

• TPC = 0 => TPC_cmd = -1

• TPC = 1 => TPC_cmd = 1

So TPC_cmd has never the value 0 (either decrease or increase command for the transmission power), like with combination algorithm 2 for UL power control.

The downlink power adjustment (incrementation or decrementation according to the power control command) step size is tuned through the dlTpcStepSize parameter. This parameter is transmitted by the RNC to the NodeBs using theTPC_DL_Step_Size IE contained in the RADIO LINK SETUP REQUEST message (NBAP). It cannot be reconfigured during the connection. 3GPP TS allowed values are: 0.5 dB, 1 dB (mandatory), 1.5 dB and 2 dB. Alcatel-Lucent implementation proposes only the two mandatory values: 0.5 dB and 1 dB.

9-37


Power Balancing

P1 P2

Power per Leg

RL Additiontime

P1

P2

isPowerBalancingAllowed (RadioAccessService)

powerBalancingRequired (DlUserService)

dlReferencePower(DlUserService)

maxAdjustmentStep (PowerBalancingAdjustmentParameters)

adjustmentPeriod (PowerBalancingAdjustmentParameters)

adjustmentRatio (PowerBalancingAdjustmentParameters)

Radio Frame

ΣΣΣΣPBAL = (1 - R) x (PREF + PP-CPICH – PINIT)

PREF

∆∆∆∆PBalancing

The objective of downlink power balancing function is to equalize powers on the different radio links, eliminating power drifting effects.

This function is triggered by the SRNC which provides balancing parameters to the NodeBs and executed by the NodeBs.

The power balancing function brings a corrective factor Pbal which is added to the power as calculated by the DL inner loop power control .

This Pbal is such that:

. ΣPbal = (1 – R).(Pref + Ppcpich – Pini)

where:

. ΣPbal is the sum of these corrective factors over an adjustment period corresponding to a number of frames,

• Pbal = 0 or -0.5 or 0.5 dB (in first implementation),

• R is the adjustment ratio,

• Pref is the value of the DL Reference Power,

• Ppcpich is the power used on the primary CPICH,

• Pinit is the power of the last slot of the previous adjustment period.

Instead of specifying which maximum correction should be applied on one slot, a period is specified, as a number of time slots, where the accumulated power adjustment should not be greater than 1 dB

The above slide shows an example with ΣPbal = - 4 dB, adjustment period = 2 Radio Frames, max adjustment step = 5 Time Slots.

9-38


Rate Reduction Algorithm

UL DPCCH

dpcMode (DlInnerLoopConf)

1 0 1 0 0 1

1500 TPC commands / s

DPC_Mode = 0 (single Tpc)

500 TPC commands / s

1 1 1 0 0 0

DPC_Mode = 1 (tpcTripletInSoft)

RRC signaling (from RNC)

PL TPCTFCI

The RNC has the possibility to activate a rate reduction algorithm. If rate reduction algorithm is applied, then the UE issues one new command every 3 slots and repeats it over 3 slots, so the DL inner loop TPC commands frequency is divided by 3 (1500 Hz down to 500 Hz).

This algorithm is controlled by the dpcMode parameter (DlInnerLoopConf object), which is signaled to the UE in the Downlink DPCH Power Control Information IE using RRC signaling:

• If dpcMode = singleTpc (0 on ASN1 interface), then the UE sends a specific TPC command in each DPCCH time slot (starts in the first available slot).

• If dpcMode = tpcTripletInSoft (1 on ASN1 interface), then the UE repeats the same TPC command over 3 successive DPCCH time slots.

On reception of TPC field in the UL DPCCH, the NodeB processes the command depending on the DPC_MODE and calculates PTPC(k):

• DPC_MODE = 0 => at each slot:

—PTPC(k) = TPCDLStepSize if TPC = up

—PTPC(k) = -TPCDLStepSize if TPC = down

• DPC_MODE = 1 => each 3 slots:

—PTPC(k) = TPCDLStepSize if 3 last TPCs are up

—PTPC(k) = -TPCDLStepSize if 3 last TPCs are down.

9-39

Student notes

9-40

Student notes

10-1


Mobility in Connected Mode

Section 10

10-2


Objectives


> Describe Handover types and purpose

> Describe Soft Handovers and associated parameters

> Describe Intra-NodeB Blind Handover and associated parameters

> Describe Alarm Handovers and associated parameters

> Describe IMSI-Based Handovers and associated parameters

10-3


Contents

> Mobility Requirements

> Active Set Management

> Primary Cell Determination

> Alarm Hard Handovers

> Intra-NodeB Blind Hard Handover

> IMSI-Based Handovers

10-4

Student notes

10-5


Mobility Requirements

10-6


Soft Handover Types

FDDcell FDDcell FDDcell

Inter-RNC SHO

Core Network

NodeB NodeB

RNC RNC

FDDcell FDDcell FDDcell

NodeB

Intra-RNC SHOIntra-NodeB SHO

(Softer)

Soft Handover (SHO) applies only to dedicated physical channels and refers to the case where more than one cell has a link established with a the UE. In this mode the UE is connected to a set of cells known as the Active Set where it benefits from macro diversity.

Softer Handover is a special case of SHO where the cells communicating with the UE belong to the same NodeB, thus it can only be performed intra-RNC. The particularity of the softer handover comes from the fact that the radio links coming from different cells of the NodeB are combined together at the NodeB level before being sent back to the RNC.

In the Intra-RNC SHO case, the cells involved in the soft handover procedure belong to different NodeBs that are connected to the same Serving RNC ( i.e. the RNC in charge of the RRC connection with the mobile). Radio Link recombination is performed at the S-RNC level.

In the Inter-RNC SHO case, the cells of the active set are not all controlled by the S-RNC. This is where the notion of Drift and Serving RNC comes into play:

• S-RNC is in charge of the RRC connection with the mobile.

• D-RNC controls the NodeB that does not belong to the S-RNC and for which a radio link needs to be established with the mobile.

• An Iur link between S-RNC and D-RNC is required to perform inter-RNC SHO.

• From S-RNC and UTRAN transport perspective D-RNC acts as a router.

• From UE and Core Network perspective the presence of D-RNC is transparent, i.e. soft handover occurs as usual.

10-7


Hard Handover Types

FDDcell

3G to 2G HHO

Core Network

NodeB NodeB

RNC RNC

FDDcell

NodeB

Intra-RNC HHO Intra-NodeBBlind HHO

FDDcell FDDcellFDDcell

FDDcell

GSMcell

2G to 3G HHO

Inter-RNC HHO

Hard Handover gathers a set of handover procedures where all the old radio linksareabandoned before the new radio links are established (break before make).

Hard handovers are needed as soon as the UE needs to leave its serving UMTS carrier. It could be:

• When the Iur interface is not present and the UE is moving from one RNC to another.

• When moving to another UMTS carrier (inter / intra-RNC or inter / intra-PLMN): this case is defined as the inter-frequency HHO.

• When moving to another technology (GSM, GPRS): this case is defined as the inter-RAT HHO.

10-8


Periodic vs. Full Event Triggered Reporting

isEventTriggeredMeasAllowed(FDDCell)

RRC Measurement Control(Intra-frequency, Periodical Reporting)RNC

FALSE

RNC

RRC Measurement Control(Ec/No, 1A, 1B, 1C, 1D, 1E, 1F)

RRC Measurement Control(Ec/No, 2D, 2F)

RRC Measurement Control(RSCP, 2D, 2F)

TRUE

Starting UA4.2, the mobility of a given UE is managed either in Periodical Mode or Full Event Triggered Mode.

The choice between these two modes is done by RNC when the UE establishes a communication in CELL_DCH state and is kept unchanged as long as the UE remains in CELL_DCH state. There is no switch between Periodical Mode and Full Event Mode in CELL_DCH state, even when the Primary Radio Link is changed.

In the event-triggered reporting mode, the type of the triggered event becomes the main indication to compute the Mobility decisions. The semantic of the received event indicates which decision has to be taken. In this mode, the RNC provides to the UE, in the RRC Measurement Control, the means to compute the criteria to manage the Mobility. The RNC has to perform the related action indicated by the received event.

The parameter isEventTriggeredMeasAllowed controls the activation of the Full Event Triggered feature on a per cell basis. The reporting mode for the call is the one configured on the cell where the call is established, and is not changed during the call duration (on CELL_DCH).

10-9


Periodical Reports Processing

Active Set cells+

best Monitored Set cells

RRC Measurement Report

RRC Measurement ReportRNC

- 1 - Alarm Hard Handover criteria evaluation (Primary Cell)• Inter-Frequency Hard Handover (3G to 3G)• Inter-System Hard Handover (3g to 2G)

- 2 - Inter-Frequency Blind Hard Handover criteria ev aluation (Primary Cell)• Intra-NodeB Blind Hard Handover

- 3 - Active Set update

- 4 - Primary Cell election

The above slide indicates in which order the various procedures are performed in the RNC when receiving a RRC Measurement Report message from the mobile.

In this release, Alarm Hard Handover refers to the following mobility cases:

• 3G to 2G handover for CS

• 3G to 2G handover for PS

• 3G to 2G handover for CS+PS

• 3G to 3G inter-frequency inter-RNC handover

• 3G to 3G inter-frequency intra-RNC handover.

10-10


Compound Neighbor List

A1NA2

NA1

A3NA2

A2NA1NA3

NA1NA2

NA1

NA2NA3

NA1NA3

NA3

NA2NA3

NA2

NA3

A1NA2

NA1

A3NA2

A2NA1NA3

NA1NA2

NA1

NA2NA3

NA1NA3

NA3

NA2NA3

NA2

NA3

isCompoundingCellListActivated (RadioAccessService)

isCompoundingCellListActivated (FDDCell)

isCompoundingCellListActivated (NeighbouringRNC)

Primary Cell Monitored SetMonitored Set

Prior to UA04.1, the monitored set was determined as the neighbors of the primary cell. UA04.1 introduces the possibility to select the monitored set based on the compounding neighbors list.

Bad neighboring management contributes to call drop ratios, indeed when a cell is not declared as the neighbor of the primary cell, the former cell will not be monitored and the call may drop. A way to reduce call drop by avoiding the operator to fine tune the neighboring list, which is time consuming, is to perform compounding neighbor list.

Compounding neighbor list is the concatenation of the static neighborhood of each cell composing the Active Set. This will ensure that the cell that is not declared as the neighbor of the primary cell, will nevertheless be present in the Monitored set, as there is high chances that it is declared as a neighbor of another cell of the Active Set.

10-11


Compound Neighbor List Management

maxCompoundingListSize (RadioAccessService)

maxNbMonitoredCellForNonShoCompoundList (RadioAccessService)

sib11OrDchUsage (UMTSFddNeighboringCell)

Entire Active Set Cells+

Primary Cell static neighboring for DCH mode+

AS first best leg static neighboring for DCH mode+

AS second best leg static neighboring for DCH mode+...

SHO Neighboring List

Primary Cell static neighboring for DCH mode+

first best monitored cell and its static neighborin g for DCH mode+

second best monitored cell and its static neighbori ng for DCH mode+...

non-SHO Neighboring List

Primary Cell ChangeOR

Active Set Modification OR

SHO to non-SHO TransitionOR

Dedicated Connection Initiation

Basing the monitored set on the compound neighbor list rather than on the primary cell neighbors increases the number of cells in the monitored set, thus it is important to have way to limit the size of the neighbor list, and ensure that the monitored set comprises the best cells.

To achieve this, the algorithm consists in scanning the cells from the active set in decreasing order of CPICH Ec/N0 and adding their neighbors to the monitored set, until the number of cells in the list reaches the maximum size allowed.

A cell is not added in the compounding list if it is already included in this list, so as not to have several instance of the same cell in the list.

If maxNbOfMonitoredCellForNonShoCompoundList is set to zero, the compound list is only composed of the primary cell and its neighborhood.

10-12

Student notes

10-13


Active Set Management

10-14


Absolute and Relative Criteria for SHO

Drop Delta

Add Delta

DropRelativeCriterion

AddRelativeCriterion

Best Cell

AddAbsoluteThreshold

Add Absolute Criterion

DropAbsoluteThresholdDrop Absolute Criterion

P-CPICH Ec/No

No Action

The active set update algorithm applies to all soft handover cases. Its purpose is to ensure that the strongest cells in the UE environment will be part of its active set.

The algorithm is based on relative comparison between the best cell and each cell CPICH EC/N0 of the reported set.

Since UA04.1, the Active Set Update algorithm offers the possibility to use absolute thresholds for link addition and link deletion criteria providing additional tools for the purposes of reducing call drop rates and improving the capacity of the network from radio power, code and RNC and NodeB processing cost perspective.

Note that absolute thresholds are optional and can be deactivated through parameters. Once activated, the criteria for RL Addition/RL Deletion would be a logical OR between the relative and absolute criteria.

Cell Individual Offsets are also supported since UA04.1. CIO is added to the measurements received from the mobile before SHO conditions are evaluated, i.e. Ec/No(i) + CellIndividualOffset(i) is compared to the add or drop threshold (relative or absolute).

Note

Cell individual offset is taken into account by the RNC only if at least one of the flag enabling absolute thresholds (add or drop) is set to true.

10-15


Drop Criteria (Periodical Mode)

IFEc/No(i) + Cell Individual Offset(i) ≤ Ec/No(best) – Drop DeltaANDEc/No(i) + Cell Individual Offset(i) ≤ Add Absolute Threshold (if Add Absolute Criterion enabled)

OREc/No(i) + Cell Individual Offset(i) ≤ Drop Absolute Threshold (if Drop Absolute Criterion enabled)

THENDrop Cell(i) from Active Set

ELSEKeep Cell(i) in Active Set

Keep Cell in Active Set

Drop Cell from Active Set

neighbouringCellOffset (UMTSFddNeighbouringCell)

legDroppingDelta (SoftHoConf)

shoLinkAdditionAbsoluteThresholdEnable (SoftHoConf)

shoLinkAdditionCpichEcNoThreshold (ShoLinkAdditionParams)

shoLinkDeletionAbsoluteThresholdEnable (SoftHoConf)

shoLinkDeletionCpichEcNoThreshold (ShoLinkAdditionParams)

RNC first identifies which is the best cell, i.e. the cell with the highest CPICH EC/N0 of the reported set (active set +monitored set).

Then for the cells belonging to the active set, RNC applies the drop criteria:

• Cells not matching drop criteria are kept in the active set until the maximum number of cells in the active set is reached.

• Cells matching one of drop conditions are removed from the active set.

The drop criteria depend on the activation of the absolute add or drop thresholds.

If none of the cells of the current active set are eligible, the RNC keeps at least the best cell even if it does not meet the criteria to be eligible.

The RNC identifies then the remaining cells (non-eligible cells) as cells to be removed from the active set. This information will be transmitted in the active set update message.

When both relative and absolute criteria are used for SHO Algorithm, it may happen that the relative and absolute criteria trigger a contradictory decision for the same cell.

In order to avoid such a case, it is necessary to add a supplementary check in order not to delete a radio link which satisfies the link relative deletion threshold but is above the link absolute addition threshold.

10-16


Add Criteria (Periodical Mode)

IFEc/No(i) + Cell Individual Offset(i) ≥ Ec/No(best) - Add Delta

OREc/No(i) + Cell Individual Offset(i) ≥ Add Absolute Threshold (if Add Absolute Criterion enabled)

THENAdd Cell(i) in Active Set

ELSEKeep Cell(i) in Monitored Set

neighbouringCellOffset (UMTSFddNeighbouringCell)

legAdditionDelta (SoftHoConf)

shoLinkAdditionAbsoluteThresholdEnable (SoftHoConf)

shoLinkAdditionCpichEcNoThreshold (ShoLinkAdditionParams)

maxActiveSetSize (SoftHoConf)

Add Cell in Active Set

Keep Cell in Monitored Set

RNC first identifies which is the best cell, i.e. the cell with the highest CPICH EC/N0 of the reported set (active set +monitored set).

Then for the cells belonging to the monitored set, RNC applies the add criteria:

• Cells matching one of add delta & add absolute criteria are added in the active set until the maximum Active Set size is reached.

• Cells not matching any add criteria are ignored.

The addition criteria depends on the activation of the absolute add or drop thresholds.

When both relative and absolute criteria are used for SHO Algorithm, it may happen that the relative and absolute criteria trigger a contradictory decision for the same cell.

In order to avoid such a case, it is necessary to add a supplementary check in order not to add a radio link which satisfies the link relative addition threshold but is below the link absolute deletion threshold.

10-17


AS Management (Event Triggered Mode)

Drop Delta

Add Delta

Best Cell

AddAbsoluteThreshold

DropAbsoluteThreshold

P-CPICH Ec/No

No Action

EVENT 1A

EVENT 1E

EVENT 1B

EVENT 1F

EVENT 1C

RL Addition and Deletion are only performed under the following conditions:

• there is always at least one cell in the Active Set. In case of all AS cells to delete, the best cell based on measured EcNo is kept.

• the maximum AS size limits the number of RL Addition. In case of several cells to add, the best cell of the Measurement Report is chosen.

If either 1A or 1E event is received the corresponding radio link is added to the active set (if the Active Set is not full). If the Active Set is full, it is critical to put the strongest cells in the active set (among the ones being reported by 1A). For that purpose, event 1C is needed.

If 1C event is received, the RNC will replace the cell in the Active Set indicated in the measurement report with the cell triggering this event.

If either 1B or 1F event is received the corresponding radio link is removed from the active set. If the Primary cell needs to be removed due to event 1B then the RNC takes into account the measured results in this event to determine a new Primary cell.

If Detected Set cells are reported the RNC will trace this. For example, the reception of an event 1A or 1E for a detected cell will generate a trace and the cell which trigs the event will not be added in the active set.

10-18

Student notes

10-19


Primary Cell Determination

10-20


Primary Cell Election: Periodical Mode

IFCell(i) was in previous Active SetANDCell(i) is in new Active SetANDEc/No(i) – Drop Primary Delta ≥ Ec/No(Primary Cell)

THENCell(i) is candidate for Primary Cell Election


IFEc/No(i) is the highest of all candidate cells

THENCell(i) is the new Primary Cell


rrcIntraFreqMeasurementDropPrimaryDelta (RRCMeasurement)

Candidate Cells Selection

Primary Cell Election

New Active Set

Cell 1Cell 2Cell 3Cell 4

Candidate Cells

Cell 1

Cell 3

Candidate Cells

Cell 1

Cell 3

Cell 3

Primary

Cell

The primary cell selection algorithm applies to all soft handover cases. The primary cell is used for monitored set determination but also as a pointer to mobility parameters. The primary cell selection algorithm is performed each time a MEASUREMENT REPORT is received by the S-RNC.

To be selected as candidate cell, the following conditions must be true:

• Cell was present in the previous active set

• Cell is eligible to be in the new active set (Reference: soft handover algorithm)

• Cell has the strongest CPICH_Ec/N0 of the MEASUREMENT_REPORT.

The previous primary cell is compared with the candidate cell for primary minus a threshold defined rrcIntraFreqMeasurementDropPrimaryRlDelta. The CPICH EC/N0 values used are the ones contained in the RRC MEASUREMENT_REPORT.

The Monitored Set should be updated each time the primary cell of active set changes. This is performed via the RRC_MEASUREMENT_CONTROL message (with the measurement command set to modify) sent to the UE with the cells to add and remove from the previous monitored set to form the new one.

The monitored set update usually follows the ACTIVE_SET_UPDATE message, but it may also happens without any ACTIVE_SET_UPDATE, when the active set content does not change, but, inside the active set, a cell becomes strong enough to replace the primary cell.

10-21


Primary Cell Change: Event 1D

Best Cell

CPICH_EC/No



Eve

nt1D

timeToTrigger1D(FullEventRepCritShoMgtEvent1D)

hysteresis1D (FullEventRepCritShoMgtEvent1D)


maxNbReportedCells1D(FullEventRepCritShoMgtEvent1D)

useCIOfor1D(FullEventRepCritShoMgtEvent1D)

NotBest Cell

)2/1010 1dBestBestNotBestNotBest HCIOLogMCIOLogM ±+⋅≥+⋅

The primary cell determination is based on event 1D reception. Based on the reception of this event, the RNC stores the new primary, and applies the current process used in case of change of primary cell.

Since the events 1A, 1C are also configured it is assumed that the new primary cell is already in the Active Set when an 1D event is triggered. This will be typically ensured if the time to trigger of 1D is greater or equal than the time to trigger of events 1A or 1C. It should be noted that a monitored set cell that needs to be included in the active set will trigger first an 1A event if its CPICH Ec/No is lower than the best cell in the Active set but entering in its reporting range or 1C event if the Active Set is full and this cell is better than the worse in the Active Set.

An event 1D will typically be triggered by a cell better than the best in the active set. Therefore due to the triggering conditions definition of these events and if the time to trigger of 1D is greater or equal than 1A and 1C typically the 1D will be triggered by a cell in the active set.

If the event 1D is triggered by a monitored cell, the RL will be added in the Active Set if not full.

If the Active Set is full and the event 1D is triggered by a monitored set cell then the new best cell will be added in the active set replacing the worst active set cell.

A new primary cell will be defined if the current primary cell is removed due to reception of RL deletion events.

10-22

Student notes

10-23


Alarm Hard Handovers

10-24


Two-Step Alarm HHO (Periodical Mode)

IFP-CPICH_EcNo(primary) < cpichEcNoThresholdORP-CPICH_RSCP(primary) < cpichRscpThreshold

THENAlarm Handover Counter is incremented by stepUpIF

Alarm Handover Counter > counterTHEN

• Alarm Handover is requested• Target Cell for HHO is chosen

ELSEAlarm Handover Counter = Max ( 0; Alarm Handover Co unter – stepDown )

cpichEcNoThreshold (AlarmHardHoConf)

cpichRscpThreshold (AlarmHardHoConf)

counter (AlarmHardHoConf)

stepUp (AlarmHardHoConf)

stepDown (AlarmHardHoConf)

isAlarmHhoAllowed (RadioAccessService)

The implementation of Alarm Hard Handover fills the following characteristics:

• Alarm Hard Handover is a rescue type of mobility and the HO decision is only triggered on DL radio alarm criteria.

• The decision algorithm is based on intra-frequency measurements reported by the UE in RRC Measurement Reports, and the target cell choice decision is based on either:

—Blind mode, where the target cell choice does not depend on measurement from candidate cells. This is done when no valid measurement is available.

—Alarm measurements from the mobile not mandating compressed mode (e.g. dual-receiver mobiles).

—Alarm measurements from the mobile using compressed mode.

At each reception of RRC MEASUREMENT REPORT (which is periodic), the Alarm Hard Handover criteria (see above slide) based on intra-frequency measurements on the primary cell are evaluated.

AlarmHardHoConf is an object allowing to define the HHO decision parameters perDlUserService. Parameters name are the same as for Compressed Mode Activation(AlarmMeasActivation object); but they are configurable per DlUserService for AlarmHardHoConf, while there is only one value for all services in AlarmMeasActivation object.

10-25


Fast Alarm HHO (Periodical Mode)

Fast Alarm AlgorithmPrimary Cell

Radio Quality

CM Criteria Alarm Measurements

Blind HHO

Timer

Valid Target Found

Alarm HHO

Primary CellRadio Quality

CM Criteria

HHO Criteria

Alarm Measurements

Alarm HHO

Two Step Algorithm

cpichEcNoThreshold (FastAlarmHardHoConf)

cpichRscpThreshold (FastAlarmHardHoConf)

counter (FastAlarmHardHoConf)

stepUp (FastAlarmHardHoConf)

stepDown (FastAlarmHardHoConf)

fastAlarmHoEnabled (RadioAccessService)

blindHhoTimerForFdd (FastAlarmHardHoConf)

blindHhoTimerForGsm (FastAlarmHardHoConf)

Starting in UA04.1 the Fast Alarm Handover feature offers the possibility to combine both measurements and alarm handover criteria.

The Alarm measurements are activated once a criterion is fulfilled, possibly following Compressed Mode activation. As soon as the first valid measurement is received from the mobile, the Alarm handover is performed.

Each time a Measurement Report is received with inter-system or inter-frequency measurements, the Alarm Measurement Criteria is checked again. If still verified, a Hard Handover is triggered towards the chosen target cell.

If no suitable Alarm measurement is reported by the mobile within a certain period of time, a blind handover, if activated, towards the blind GSM cell provisioned for the primary cell is triggered by the RNC.

This algorithm allows better reactivity from UTRAN, as only one radio criteria is used for both alarm measurement and handover triggering. It also has a positive impact on network capacity as it limits the time during which Compressed Mode is active.

The trigger criteria is based on the same principle than alarm criteria, using CPICH Ec/N0 and RSCP thresholds associated with a counter mechanism.

The Fast Alarm handover algorithm is not compatible with the 2 steps handovers mechanism (compressed mode activation, followed by handover decision).

10-26


Alarm HHO Decision: Events 2D & 2F

timeToTrigger2D (FullEventRepCritHhoMgtEvent2D)

maxNbReportedCells2D (FullEventRepCritHhoMgtEvent2D)

timeToTrigger2F (FullEventRepCritHhoMgtEvent2F)

maxNbReportedCells2F (FullEventRepCritHhoMgtEvent2F)

Best Cell




Eve

nt2D

hysteresis (static)

cpichEcNoThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)

cpichRscpThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)

cpichEcNoThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)

cpichRscpThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)


2/22 ddUsedUsed HTQ m≤ 2/22 ffUsedUsed HTQ ±≤

timerAlarmHoEvent(FullEventHOConfHhoMgt)



Eve

nt2F

Eve

nt2D



NOT HIT HIT

The RNC uses the following algorithm:

• The timer timerAlarmHOEvent to confirm alarm handover criteria is started once a 2D event is received for any of the measurement quantity (RSCP or Ec/No).

• If another subsequent 2D event with another measurement quantity is received, the timer shall continue and the RNC stores that both quantities fulfils their triggering condition.

• The timer timerAlarmHOEvent is stopped if a 2F event corresponding to the triggering 2D is received. In case both quantities (RSCP and Ec/N0) have fulfils their triggering condition, the timer is stopped if both 2F corresponding events are received (Ec/N0 and RSCP).

• A change of primary (event 1D) received while the timer is running has no effect on the algorithm, except the case when the new primary has different thresholds than the previous primary cell in which case the 2D/2F events are modified with the new thresholds.

Once the timer timerAlarmHOEvent elapses, the RNC activates Alarm measurement based on periodical reporting, depending on neighboring cell configuration.

• After the timer expiration and alarm measurement is setup, if the alarm criteria becomes invalid (i.e. reception of one 2F event) before the alarm measurement results are received, the alarm handover procedure is cancelled and the alarm measurement results will be ignored when received. If the alarm criteria are again met a new.

10-27


Target Cell Choice

minimumGsmRssiValueForHO (RadioAccessService )

Eligible GSM Cell list

GSMCell A

GSM Carrier RSSI (Cell i)

GSMCell B

GSMCell C

>

Measurement reports

FDDCell A

FDDCell B

FDDCell C

minimumCpichEcNoValueForHO (DlUserService)

minimumCpichRscpValueForHO (DlUserService)

CPICH_Ec/No (Cell j)

CPICH_RSCP (Cell j)

AND

Eligible FDD Cell list

Measurement reports

>

>

Filtering

Equalized Measurement=

Reported Measurement – gsmCellIndivOffset

EqualizationEqualized Measurement

=Reported Measurement – neighbouringCellOffset

(UMTSFddNeighbouringCell)(GsmNeighbouringCell)

Measurement filtering

• The following criteria are evaluated on the measurements reported by the UE (i.e. not equalized measurements):

—for inter-frequency reported cells:

– CPICH Ec/No > minimumCpichEcNoValueForHO

and

– CPICH RSCP > minimumCpichRscpValueForHO

—for inter-system reported cells:

– GSM Carrier RSSI > minimumGsmRssiValueForHO

Target cell identification

• For inter-frequency reported cells, the target cell is chosen among the eligible cells as the cell having the highest CPICH Ec/No after equalization.

• For inter-system reported cells, the target is chosen among the eligible cells as the cell having the highest measured GSM Carrier RSSI after equalization.

10-28


3G to 2G Hard Handover

IFEqualized RSS(i) is the highest of all reported eligib le cells

THEN• Cell(i) is the Target Cell• Perform 3G to 2G Hard Handover towards Cell(i)

ELSE IF

No valid measurement reportORNo eligible cell in measurement report

THENPerform GSM Blind Hard Handover (if available)

ELSENo Handover

Target Cell Identification

ActivationisAlarmHhoAllowed (RadioAccessService)

activationHoGsmAllowed (RadioAccessService)

activationHoGsmPsAllowed (RadioAccessService)

Blind HandoverisBlindHoRescueAllowed (RadioAccessService)

blindHoGsmNeighbouringTargetCgi (FDDCell)

The target cell is chosen amongst the eligible cells as the cell having the highest measured GSM Carrier RSSI after equalization.

The target cell choice decision is based on either:

• Blind mode: this is used when no inter-system valid measurement is available;

• Inter-system measurements performed by the UE, with or without Compressed Mode on 2G neighbors and reported by the UE in the RRC Measurement Reports.

The target GSM cell to use in case of blind handover is indicated by the parameter blindHoGsmNeighbourTargetCgi.

10-29


3G-3G Hard Handover

IFEqualized Ec/No(i) is the highest of all reported eli gible cells

THEN• Cell(i) is the Target Cell• Perform 3G to 3G Hard Handover towards Cell(i)

ELSE IF

No valid measurement reportORNo eligible cell in measurement report

THENPerform GSM Blind Hard Handover (if available)

ELSENo Handover

Target Cell Identification

ActivationisAlarmHhoAllowed (RadioAccessService)

Intra-RNC HandoverisInterFreqIntraRncHhoWithCModeAllowed (RadioAccessService)

is3Gto3GWithoutIurAllowedforCS (RadioAccessService)

is3Gto3GWithoutIurAllowedforPS (RadioAccessService)

Inter-RNC Handover

As for inter-system handover, the decision algorithm is based on intra-frequency measurements performed by the UE on the primary cell and reported in the RRC Measurement Reports.

The target cell is chosen amongst the eligible cells as the cell having the highest measured CPICH Ec/No after equalization.

The target cell choice decision is based on either:

• Blind mode: this is used when no inter-system valid measurement is available;

• Inter-frequency measurements performed by the UE, with or without Compressed Mode on 3G neighbors and reported by the UE in the RRC Measurement Reports.

The target GSM cell to use in case of blind handover is indicated by the parameter blindHoGsmNeighbourTargetCgi.

10-30

Student notes

10-31


Intra-NodeB Blind Hard Handover

10-32


Twin Cells Definition

F1F2

F1F2

F1F2

F1F2

F1F2

F1F2

F1F2

isInterFreqHHoAllowed (RadioAccessService)

scope (FrequencyScope)

F1

F2twinCellId (InterFreqHhoFDDCell)

RNC

NodeB

FDDCell

InterFreqHhoFDDCell

RadioAccesService

FrequencyScope

Inter-frequency handover between twin cells can be used on multi-carrier networks considering two layers: a mobility layer (F1) and a capacity layer (F2).

The inter-frequency handover is performed between two cells on the same sector, which are called twin cells, as shown in the figure above.

There is no inter-frequency measurements for this type of Inter-Frequency Hard Handover (blind handover).

There cannot be any call establishment on capacity layer (ie. F2 layer) even for emergency calls => SIBs on frequency F2 are not be broadcast on F1 layer and F2 cells is barred.

Inter-frequency handover can not be triggered during call establishment (ie. between RRC Connection Request and RAB Assignment Complete).

Inter-frequency intra-NodeB blind handover algorithm is based on intra-frequency measurements. The handover criteria make use of periodic CPICH Ec/No and RSCP measurements from the current primary and second best cell to hand the mobile over the capacity/mobility layer.

The current algorithm to trigger handovers between the capacity and mobility layers cannot be used anymore when the event-reporting mode is configured. It can still be configured but only with periodical reporting.

10-33


Mobility to Capacity Hard Handover

IFP-CPICH_EcNo(primary) – P-CPICH_EcNo(second best) ≥ mob2CapDeltaEcNoBorderANDP-CPICH Power – P-CPICH_RSCP(primary) ≤ mob2CapPathLossBorder

THENCounter is incrementedIF

Counter = 5 (static)THEN

• Perform Inter-Frequency towards Twin Cell• Reset Counter

ELSE• Reset Counter• Perform Active Set Evaluation• Perform Primary Cell Election

mob2CapDeltaEcNoBorder (AlarmHardHoConf) mob2CapPathLossBorder (InterFreqHhoRnc)

F1F2

F1F2

F1F2

The inter-frequency handover trigger is based on RRC measurements reported by the UE (only RRC intra-frequency measurements are needed).

Let us assume that the UE is connected to one or several cells on mobility carrier i.e. F1 carrier, C(F1) being the primary cell of the active set.

The UE will leave the mobility carrier (F1) to the capacity carrier (F2) (i.e. the Twin cell) if the two following conditions are fulfilled.

-1-

UE sees a dominant pilot which is equivalent toCPICH EC/N0(primary cell) – second best CPICH EC/N0 >= mob2CapDeltaEcNoBorder

As far as F2 is less interfered than F1, this condition insureq that UE can survive on F2 cell without soft handover.

-2-

UE experiences good radio conditions on C(F1) which is equivalent to path loss (primary cell) <= Mob2CapPathLossBorder

In the absence of inter-frequency measurements on F2, this condition insureq that the UE is in the coverage area of C(F2) and hence C(F2) is a good target cell. The mob2CapPathLossBorder parameter can be set based on the difference between pilot powers on C(F1) and C(F2).

10-34


Capacity to Mobility Hard Handover

IFP-CPICH_EcNo(primary) – P-CPICH_EcNo(second best) ≤ cap2MobDeltaEcNoBorderORP-CPICH Power – P-CPICH_RSCP(primary) ≥ cap2MobPathLossBorder

THENPerform Inter-Frequency towards Twin Cell

ELSE• Perform Active Set Evaluation• Perform Primary Cell Election

cap2MobDeltaEcNoBorder (AlarmHardHoConf) cap2MobPathLossBorder (InterFreqHhoRnc)

F1F2

F1F2

F1F2

The handover from F2 to F1 is a critical handover and requires ideally inter-frequency measurements (and may required compressed mode) for the selection of target cell.

If Intra-RNC Inter-Frequency Hard Handover is not enabled, only RRC intra-frequency (on F2) measurements are used.

Any of the two following conditions following then triggers such a handover.

-1-

UE is no more in the center of the cell: when path loss becomes high, this means that the UE is going to the border of the cell. In that case, it must be sent on F1 carrier i.e. the mobility carrier (Twin cell).

-2-

UE may not be able anymore to survive without SHO: when (P-CPICH EC/N0 (unique active cell) – second best P-CPICH EC/N0) is lower than Cap2MobDeltaEcNoBorder.

10-35


IMSI-Based Handovers

10-36


AllowedPlmnIdPLMN 3G As

AllowedPlmnIdPLMN 3G Bs

AllowedPlmnIdPLMN 2G A

National Roaming Subtree

Operator A subscribersOperator B subscribers

2G A

2G B

3G Bs 3G As

3G A

3G B

CompetitiveArea

SharedAreas

AllowedPlmnIdPLMN 3G As

NationalRoamingPLMN 3G A

ImsiPlmnAccessRightPLMN 3G A

AllowedPlmnIdPLMN 3G A

ImsiPlmnAccessRightPLMN 3G B

AllowedPlmnIdPLMN 2G B

AllowedPlmnIdPLMN 3G Bs

AllowedPlmnIdPLMN 3G B

isImsiHoApplicable (NationalRoaming)

imsiHoMobileNetworkCode (NationalRoaming)

imsiHoMobileCountryCode (NationalRoaming)

mobileNetworkCode (ImsiPlmnAccessRight)

mobileCountryCode (ImsiPlmnAccessRight)

mobileNetworkCode (AllowedPlmnId)

mobileCountryCode (AllowedPlmnId)

In the new regulatory and commercial situation for UMTS, it may be necessary for a UE to treat different PLMN codes (MCC+MNC) as equivalent (National Roaming). This addresses in particular the concerns of:

• Pan-European operators: Networks of the same operator in different countries should all be treated as a single HPLMN

• MVNOs (Mobile Virtual Network Operator) or Joint Ventures (like existing operators who want to share a 3G network)

• An operator that has different PLMN codes in 3G and 2G (to allow inter-PLMN cell reselection, and in particular GPRS to UMTS mobility).

Based on subscriber IMSI the allowed PLMNs can be chosen (i.e. IMSI based handover) as follows:

• At the call setup the SRNC receives the user IMSI and retrieves the MCC and MNC part called IMSI-PLMN Id.

• This is then used at SRNC to derive the allowed PLMNs and cell neighboring list based on the PLMN access right table.

10-37

Student notes

10-38

Student notes

11-1


HSDPA

Section 11

11-2


Objectives


> Describe HSDPA principles

> Describe HSDPA resource allocation parameters

> Describe HSDPA specific features and associated parameters

11-3


Contents

> HSDPA Principles

> HSDPA Resources

> HSDPA Operation

11-4

Student notes

11-5


HSDPA Principles

11-6


HSDPA Distributed Architecture

Uu Iub

MAC-dRLC

HS-DSCH FPMAC-hs

HS-DSCH FP

RLC

L2 L2

Flow control

PHY PHY L1 L1

New Transport channelHS-DSCH

RNCNodeBUE

HS-SCCHDownlink Transfer Information(UEid, OVSF,...)

HS-PDSCHData Transfer (PS I/B)

HS-DPCCH Feedback Information (CQI, ACK/NACK)

DPCHUpper Layer Signaling

RNC

New Frame ProtocolsHS-DSCH

Introduction of MAC-hs

Iub

MAC-d

MAC-hs

HSDPA is an increment on UTRAN procedures, and it is fully compatible with R4 layer 1 and layer 2. It is based on the introduction of a new MAC entity (MAC-hs) in the NodeB, that is in charge of scheduling / repeating the data on a new physical channel (HS-DSCH) shared between all users.

This has a minor impact on network architecture, there is no impact on RLC protocol and HSDPA is compatible with all transport options (AAL2 and IP).

On NodeB side, MAC-hs layer provides the following functionalities:

• Fast repetition layer handled by HARQ processes.

• Adaptive Modulation and Coding.

• New transport channel High Speed Downlink Shared Channel (HS-DSCH)

• Flow control procedure to manage NodeB buffering.

Some new L1 new functionalities are introduced compared to R4:

• 3 new physical channels: HS-PDSCH to send DL data, HS-SCCH to send DL control information relative to HS-PDSCH, and HS-DPCCH to receive UL control information.

• New channel coding chain for HS-DSCH transport channel and HS-SCCH physical channel.

11-7


HSDPA Key Features

SchedulerFills the TTIs with one or more users based on their priority and

feedback information

HARQ ProcessesRetransmissions handling, TFRC selection, AMC…

Queue IDs

Radio TransmissionFeedback Reception

Capacity RequestControl FP

Capacity AllocationControl FP Data FP

Flow ControlDynamically fills the Queues of each UE

RNC

The main architectural shift with respect to R4 is the introduction of an ARQ scheme for error recovery at the physical layer (which exists independently of the ARQ scheme at the RLC layer). This fast retransmission scheme is of paramount importance for TCP as generally TCP has not performed well in a wireless environment.

This architectural evolution gives a new importance to the role of the NodeB in the UTRAN. It then necessarily goes together with the introduction of some new functions managed by the NodeB among which:

• Flow Control: new control frames are exchanged in the user plane between NodeB and RNC to manage the data frames sent by the RNC.

• Scheduler: it determines for each TTI which users are going to be served and how many data bits they are going to receive.

• Hybrid Automatic Repeat Query: retransmissions management.

• Adaptive Modulation and Coding: new channel coding stages and radio modulations schemes are introduced to provide data throughput flexibility.

• Feedback demodulation and decoding in UL.

11-8


RNC

New IN & RadioAccessService MOCs

RadioAccessService

1..1

HsdpaCellClass HsdpaRncConf HsdpaUserService

1..11..11..5

existing MOC

new MOC

HsDschFlowInformation SourceConformanceInformation SpiConfiguration

1..11..1 0..3

0..*

EM

RncIn1..1

Fc1..1

1..1

RadioAccessService new MOCs and parameters.

HsdpaCellClass: maximunNumberOfUsers, minimumPowerForHsdpanumberOfHsPdschCodes, numberOfHsScchCodes.

HsdpaRncConf: isRLCReconfigurationForChannelTypeSwitching, suspendTimeOffset, deltaCfnForHsdpaChannelTypeSwitching, deltaCfnForHsdpaMobility, deltaCfnForHsdpaRLCReconfiguration, maxIubHsDschFrameSize, nbOfSpiConfiguration.

HsdpaUserService: ackNackRepetitionFactor, ackPowerOffset, cqiFeedbackCycleK, cqiPowerOffset, cqiRepetitionFactor, discardTimer, hsScchPowerOffset, macHsWindowSize, measurementPowerOffset, nackPowerOffset, timerT1.

HsDschFlowInformation: maxNumberOfRetryRequest, minTimeBetweenRequest.

SourceConformanceInformation: maximumBucketSize, sourceConformanceStatus, maximumTokenGenerationRate.

SpiConfiguration: backgroundSpi, interactiveSpi, priorityLevel,streamingSpi.

IN new MOC and parameters.

Fc: cellColor, iubFlowControlActivation, qosBackPressureThreshold, qosDiscardThreshold

11-9


RNC

New NodeB & BTSEquipment MOCs

HsdpaResource

NodeB

FDDCell

0..200

1..1

1..6

BTSEquipment

HsdpaConf

BTSCell

0..1

1..12

existing MOC

new MOC

0..* 0..3000

RadioAccessService1..1

HsdpaCellClass1..5

hsdpaCellClassId

FDDCell new MOC and parameters.

HsdpaResource: hsdpaCellClassId, hsdpaCellClassRef.

BTSEquipment new MOC and parameters.

HsdpaConf: dchPowerMargin, harqNbMaxRetransmissions, harqType, hsdpaResourceId, hsdschInterval, hsscchPcOffset, maxRateGrowth.

11-10

Student notes

11-11


HSDPA Resources

11-12


Base Station Configuration

hsdpaResourceId (HsdpaConf)

BTSCell

BTSEquipment

HsdpaConf

iCCM iTRM

iTRM

iTRM

MCPA DDM

MCPA DDM

MCPA DDM

iCEM128H-BBU

H-BBU

H-BBU

D-BBU

H-BBU

D-BBU

D-BBU

D-BBU

iCEM128

iCEM64

iCEM64

CEMαααα

ULHS-DPCCHDLHS-PDSCHHS-SCCH

MAC-hs• HARQ• Scheduler• Link Adaptation (AMC)

ULAssociated/R4 DPDCHAssociated/R4 DPCCH

DLAssociated/R4 DPCHcmCHs

DIGITAL SHELF RF BLOCK

BTS

H-BBU

D-BBU

HSDPA dedicated

DCH/cmCH dedicated

The HSDPA support on UMTS BTS requires Alcatel-Lucent second generation of CEM i.e. iCEM64 or iCEM128. Alcatel-Lucent CEM Alpha is not HSDPA hardware ready.

Nevertheless, HSDPA support on Alcatel-Lucent UMTS BTS is possible assuming already installed CEM Alpha modules. CEM Alpha and iCEM modules can coexist within the NodeB digital shelf while providing HSDPA service with Alcatel-LucentUMTS BTS.

Base Band processing is performed by BBUs of CEM and iCEM. One restriction of current BBUs is that one BBU cannot process both Dedicated and HSDPA services. In order for the BTS to be able to manage both dedicated and HSDPA services, the BTS has to specialize BBUs as:

• D-BBU: BBU managing dedicated services,

• H-BBU: BBU managing HSDPA services.

The partition between H-BBU and D-BBU is done by the BTS at BTS startup reading the value of the hsdpaResourceId parameter for a BTS Cell when the btsCellparameter hsdpaResourceActivation is set to TRUE. When used, this parameter associates a logical HSDPA resource identifier for this cell.

11-13


OVSF Codes Tree Reservation

SF4

SF8

SF16

SF32

SF64

SF128

SF256

cmCH

. . .

HS-PDSCH

HS-SCCH

. . .

. . .

. . .

HSDPA + R99HSDPA + R99

numberOfHsPdschCodes (HsdpaCellClass)

numberOfHsScchCodes (HsdpaCellClass)

RadioAccessService

RNC

HsdpaCellClass

The configuration of the OVSF code tree can provide up to 15 SF16 codes allocated to HS-PDSCH and up to 4 SF128 codes for HS-SCCH.

All the R4 common channels (CPICH, P-CCPCH, S-CCPCH) are allocated in the top of the tree and take the equivalent of a SF32 code. All remaining OVSF codes can be used for non-HSDPA services (speech, multi-RABs...).

In Alcatel-Lucent implementation, the HS-PDSCH SF16 codes are allocated and reserved by the RNC at the bottom of the tree. Immediately above, the HS-SCCH SF128 codes are allocated. These codes are allocated at cell setup and cannot be used or preempted for other services.

All the remaining codes are therefore contiguous and left for further DCH allocations. This includes associated DCH as well as any other calls mapped on DCH (e.g. speech calls, streaming, etc.).

Note that the maximum configuration (15 HS-PDSCH codes and 4 HS-SCCH codes) leaves no room in the OVSF tree for DCH (due to common channels occupancy) so it is not even possible to allocate associated SRB for HSDPA calls.

11-14


Power Reservation

minimumPowerForHsdpa(HsdpaCellClass)

RadioAccessService

RNC

HsdpaCellClassdchPowerMargin

(HsdpaConf)

BTSCell

BTSEquipment

HsdpaConf

cmCHs

HS-PDSCHHS-SCCH

DPCH

SHO

MCPAPower

Power partitioning is defined at cell setup.

The minimum power for HSDPA is set by the operator and may be 0 dB (if there is no HSDPA traffic the minimum HSDPA power recommended value is 0 dB in order not to impact the DCH traffic).

The maximum usable power for HSDPA corresponds to the difference between the maximum power reserved for Traffic (maximum power – power reserved for SHO) and the power reserved for Common Channels.

11-15


HSDPA RABs

PSI/B UL:384 DL:[max bit rate for UE categories 12 and 6] PS RAB

UL:3.4 DL 3.4 SRBs for DCCH

5



4



3



2



1

CS/PSRB & SRB Combination

Five new RABs are introduced in UA4.2 in order to support HSDPA operation, all of them

being exclusively dedicated to PS I/B services. While the DL PS RB maximum throughput

depends on UE category and radio conditions, the allowed UL RB maximum throughputs are

8, 32, 64, 128 and 384 kbps. The UL and DL SRBs are the already known 3.4 kbps RBs.

11-16

Student notes

11-17


HSDPA Operation

11-18


Activation Flags

hsdpaActivation (FDDCell)

RadioAccessService

RNC

NodeB

FDDCell

isHsdpaAllowed (RadioAccessService)

RNC SubtreeRNC Subtree

BTSCell

BTSEquipment

HsdpaConf

hsdpaResourceActivation (BTSCell)

NodeB SubtreeNodeB Subtree

HSDPA activation main switch is located at RNC level, under the Radio Access Service subtree. If the value of isHsdpaAllowed is set to TRUE, then all the new MOIs required for HSDPA operation should be defined in the RNC configuration.

Activation consists in:

• at BTS level, set hsdpaResourceActivation to TRUE.

• at RNC level, set isHsdpaAllowed to TRUE and then hsdpaActivation to TRUE.

Note that HSDPA needs to be activated at BTS level first, and that prior to the activation on a BTS, a new VCC shall be created on the corresponding Iub link to carry HSDPA traffic.

Deactivation can be performed at two levels:

• deactivation at RNC level: setting isHsdpaAllowed to FALSE deactivates HSDPA and leaves the HSDPA dedicated resources preserved,

• deactivation at cell level: setting hsdpaActivation and hsdpaResourceActivation to FALSE completely deactivates HSDPA.

11-19


Traffic Segmentation

R4 cell R4 cell

RRC Connection Setup(Redirection to F1)

HSDPA cell

RRC Connection Setup(Redirection to F2)

RRC Connection Request(AS release indicator = R4 or absent)

RRC Connection Request(AS release indicator = R5)

isRedirectionForTrafficSegmentation (InterFreqHhoFddCell)

isRedirectionBasedOnEstablishmentCause (InterFreqHhoFddCell)

RNC

HSDPA cell

Traffic Segmentation feature allows to deal with a multi-layer scenario where HSDPA is available in only one of the layers.

Mobiles are redirected to the right layer at RRC connection establishment in order that mobiles that are eligible to HSDPA are directed towards the HSDPA layer and that the other ones are directed towards the non-HSDPA layer. The redirection is based on the twin-cell configuration. The call flow is not modified compared to a normal call setup, the redirection only consists in indicating a target frequency in the RRC Connection Setup message (frequency info IE).

Mobiles in idle mode will select a layer according to radio conditions criteria. The cell selection/reselection algorithm is not governed by HSDPA availability so it is not possible to guarantee that an HSDPA mobile will select the HSDPA layer (and vice versa a non-HSDPA mobile will select the non-HSDPA layer).

Segmentation is done by the RNC when a mobile tries to establish a RRC connection. It is based on the Access Stratum Release Indicator IE present in RRC Connection Request, knowing that R4 mobiles do not support HSDPA. If a R4 mobile sends its connection request in the HSDPA layer, it is redirected to the non-HSPDA layer in the RRC Connection Setup message. If a R5 (or later release) mobile sends its connection request in the non-HSDPA layer, it is redirected to the HSDPA layer.

11-20


Call Admission

HSDPA RAB

Traffic Class = I/B?

Multi-Service?

R99 RAB

YES

NO

YES

RAB Request

NO

YES

NO

RNCRNC

HSDPA UE?

Primary Cell = HSDPA Cell?

YES

NO

maximunNumberOfUsers (HsdpaCellClass )

RadioAccessService

RNC

HsdpaCellClass

hsdpaMaxNumberUser (BTSEquipment )

hsdpaMaxUserPerNodeB (BTSEquipment )

Any PS RAB request with Interactive or Background traffic class is matched to the HSDPA Radio Bearer configuration if the mobile is HSDPA capable and the primary cell of the active set supports HSDPA. If it is not the case, the request is mapped on DCH as usual (iRM CAC is performed).

In this implementation, the admission process in the RNC for HSDPA admits any I/B RAB request on HSDPA until the maximum number of simultaneous users allowed on HSDPA is reached (maximumNumberOfUsers). In this version there is no other admission criteria.

The BTS will limit the number of simultaneous HS-DSCH radio-links because of limited processing capacity. If the limit is reached, the radio-link setup/reconfiguration is rejected. This leads to a RAB reject by the RNC.

hsdpaMaxNumberUser represents the maximum number of HSDPA user (logical channel) allowed per hsdpaResource (H-BBU) 0 meaning maximum user allowed by software and hardware Default value = 0 (no limit except software and hardware limit).

11-21


HARQ Type

NACK NACK NACK NACK ACK

DATA DATA DATA DATA DATA

Chase CombiningChase Combining

NACK NACK NACK NACK ACK

DATA DATA1 DATA2 DATA3 DATA4

Incremental Redundancy CombiningIncremental Redundancy Combining

BTSCell

BTSEquipment

HsdpaConf

harqType (HsdpaConf)

harqNbMaxRetransmission (HsdpaConf)

With HARQ the UE does not discard the energy from failed transmissions. The UE stores and later combines it with the retransmissions in order to increase the probability of successful decoding. This is a form of soft combining.

HSDPA supports both Chase Combining (CC) and Incremental Redundancy (IR).

Chase Combining is the basic combining scheme. It consists in the NodeB simply retransmitting the exact same set of coded symbols of the original packet.

With Incremental Redundancy, different redundancy information can be sent during re-transmissions, thus incrementally increasing the coding gain. This can result in fewer retransmissions than for Chase Combining and is particularly useful when the initial transmission uses high coding rates (e.g. 3/4). However, it results in higher memory requirements for the UE.

The Chase Combining option corresponds to the first redundancy version applied for all retransmissions.

The Partial Incremental Redundancy indicates that for all redundancy versions the systematic bits must be transmitted (only RV parameters with s = 1 are taken into account).

The Full Incremental Redundancy corresponds to sequences where both systematic and non-systematic bits can be punctured.

11-22


MAC-hs Settings

discardTimer (HsdpaUserService)

macHsWindowSize (HsdpaUserService)

timerT1 (HsdpaUserService)

RadioAccessService

RNC

HsdpaCellClass

Scheduler

TFRC Selection

Priority QueueDistribution

Priority QueueDistribution

PriorityQueue

PriorityQueue

PriorityQueue

Flow Control

MAC-d flows

AssociatedUplink Signaling

HS-DSCHAssociated Downlink Signaling

MAC-hs

to MAC-d or MAC-c/sh

HARQ

PriorityQueue

HARQ performs fast retransmissions between UE at BTS for each MAC-HS PDU which is NACked by UE. The max delay between two subsequent retransmissions is 12 ms (6 TTIs). Due to the short delay and soft combing of these HARQ retransmissions they are more efficient than RLC retransmissions.

Therefore enough HARQ retransmissions should be allowed to recover most of the radio errors. Apart from the maximum number of retransmissions and HARQ type (see previous slide), the process of each MAC-HS PDU is controlled by the following parameters:

• timerT1 = 100 ms (default value); this is a stall avoidance timer running at BTS; if this timer expires and the corresponding MAC-HS PDU has not been ACKed by UE then BTS stops retransmitting this PDU. This timer is linked to harqNbMaxRetransmissions by the following formula:

timerT1 ≥ harqNbMaxRetransmissions * 12 ms

• discardTimer = 500 ms (default 3000); if this timer expires and the corresponding MAC-HS PDU has not been ACKed by UE then this PDU will be discarded. The RLC layer will retransmit it so no packet loss occurs. The discardTimer > TimerT1 to allow HARQ recovery before discarding it. Typically RLC layer will retransmit a MAC-d PDU after timer poll prohibit = 300 ms expires. To avoid duplicated PDUsin BTS buffer it is recommended to keep discardTimer >= 500 ms.

• macHsWindowSize = 32 MAC-HS PDUs (default value); This parameter defines the receiver and transmitter MAC-hs PDU window size.

11-23


CQIACK

HS-DPCCH Timing

HS-SCCH#2

CQIACK

7,5 slots

HS-SCCH#1

HS-PDSCH

2 ms

HS-DPCCH

P-CPICH

2 slots

SFNBFN tcell

cqiRepetitionFactor (HsdpaUserService)

ackNackRepetitionFactor (HsdpaUserService)

cqiFeedbackCycle (HsdpaUserService)

RadioAccessService

RNC

HsdpaUserService

The UE monitors all the HS-SCCHs from the set it has been allocated. It despreadsand decodes the first slot of the corresponding HS-SCCHs.

If the UE detects data intended to it by recognizing its UEId on the first slot, it decodes the rest of the subframe to get all the relevant information needed to receive HS-DSCH (transport block size, HARQ process number, redundancy version, New Data Indicator).

In parallel the UE may start to despread the HS-PDSCH codes it has been allocated (the first slot of HS-SCCH contains the channelization code set and the modulation scheme information).

After HS-PDSCH decoding, the UE send the ACK/NACK and CQI. It possibly repeats this indications over consecutive HS-DPCCH subframes.

11-24


HS-SCCH Power

P-CPICH

HS-SCCH

-8 dB13 – 30

-5 dB10 – 12

-3 dB8 – 9

0 dB1 – 7

Power OffsetCQI

distance

HS-SCCH to P-CPICHPower Offset

hsscchPcOffset (HsdpaConf)

BTSCell

BTSEquipment

HsdpaConf

There is no true power control mechanism on HS-SCCH and a CQI-based power control procedure is implemented instead.

A direct relation between the quality of DL radio conditions and the amount of power to be allocated to the HS-SCCH is used. The worst the DL radio conditions, the smallest the CQI and the greatest the power to be allocated to the HS-SCCH. The principle then consist in associating a power offset (relative to P-CPICH power) to the HS-SCCH depending on the reported CQI value. The power allocated for HS-SCCH is derived from the CQI reported by the mobile in order to adapt the transmission power to radio conditions.

This is configured in a table that gives a power offset relative to P-CPICH for each CQI value (cqiPowerOffset parameter).

11-25


HS-DPCCH Power

x

OVSFc ββββc

DPCCH x

x

OVSFhs ββββhs

HS-DPCCH x

x

OVSFd ββββd

DPDCH x ΣΣΣΣ

Q

I

Modulation

ΣΣΣΣ

NACK

DPCCH

ββββc

ββββhs CQI

ββββhs ACK

ββββhs NACK

CQIACK

ackPowerOffset (HsdpaUserService)

cqiPowerOffset (HsdpaUserService)

nackPowerOffset (HsdpaUserService)

RadioAccessService

RNC

HsdpaUserService

Radio conditions information and acknowledgement are reported by the UE to the NodeB through the HS-DPCCH channel. This channel allows the NodeB to adapt the downlink data rate and to manage retransmission process. The HS-DPCCH is divided in two parts. The first one is the Channel Quality Indicator (CQI) which is a value between 1 and 30 characterizing the radio conditions (1 = bad radio conditions and 30 = good radio conditions). The second one is the acknowledgement information: if data are well received by the UE, the UE sends to the NodeB an Ack, otherwise a Nack.

The HS-DPCCH BLER should be low enough to ensure correct HS-DSCH transmission; a correct demodulation of CQI ensures suitable transport block transmission. A correct ACK/NACK demodulation ensures a good H-ARQ efficiency.

The power allocated to the HS-DPCCH is derived from the power of the associated DPCCH taking into account three specific power offsets. These power offsets should not be set too high in order not to impact the uplink coverage and capacity.

Offset values are sent to the UE via RRC signaling. These signaled values correspond to predefined (3GPP standards) quantized amplitude ratios βhs/βc.

11-26


Always On

CELL_DCHCELL_DCH(DCH/HS(DCH/HS--DSCHDSCH))

CELL_FACHCELL_FACH(RACH/FACH)(RACH/FACH)

PMMPMM--idleidle

UL and DL Low Usage(T1 expiry)

UL or DL Traffic

UL or DL

High Traffic

UL and DL Inactivity(T2 expiry)

timerT1forHsdpa (AlwaysOnTimer)

timerT2forHsdpa (AlwaysOnTimer)

Always-On step 1 (downgrade) is supported but only towards Cell_FACH, using an asynchronous RB Reconfiguration. Once the reconfiguration has been performed, all RLs are deleted. If there is a CAC failure on FACH then the call is released.

Always-On upgrade is supported, coming from Cell_FACH. The RL is allocated first on the BTS. The RB is then reconfigured to HSDPA (if the cell supports HSDPA, else it is reconfigured to DCH) using an asynchronous RB Reconfiguration If there is a CAC failure on HSDPA then the call is released.

When an HSDPA mobile in Always-On downgraded state on DCH moves to an HSDPA cell (on a primary cell change), then the RB is reconfigured to HSDPA. If HSDPA CAC fails then the RAB is released.

When an HSDPA mobile in CS+PS Always-On downgraded releases the CS RAB, then the PS RB is reconfigured to HSDPA (if the cell is HSDPA) if the Always-On target is DCH. If the Always-On target is Cell_FACH, then the RB is reconfigured to Cell_FACH.

11-27


SPI Configuration

priorityLevel (SpiConfiguration)

backgroundSpi (SpiConfiguration)

interactiveSpi (SpiConfiguration)

streamingSpi (SpiConfiguration)

RadioAccessService

RNC

HsdpaRncConf

SpiConfiguration

SpiConfiguration

SpiConfiguration

PQ0 PQ15

QId0 QId1 QIdN QId0 QId1 QIdN

SecondStage

FirstStage

NodeB Scheduler

Background Interactive Streaming

gold 15 15 15

silver 7 7 7

bronze 0 0 0

OLSUMTS TRAFFIC CLASS

The aim of the scheduler is to dynamically share available DL bandwidth among users, in order to optimize the overall throughput, and fulfill network and UE criteria. In order to separately manage the two aspects, the scheduler is divided into two stages:

• the first stage deals with priorities (CmCH-PI) assigned by higher layers on the different queues for choosing queues which will be served in the coming transmission interval,

• the second stage takes care of radio conditions and UE capabilities to determined what users belonging to the selected queue will get access to radio resources in the coming transmission interval.

Before entering the scheduler, the Mac-d PDUs for each queue of each user are classified according to their corresponding priority (CmCH-PI). Every TTI, the scheduler is launched in order to efficiently assign the available resources (number of codes and remaining power) to the different users.

The selection of a priority queue is based on a cost function that takes into account credits assigned to each priority queue and the number of Mac-d PDUs already transmitted in the last TTI for these queues.

The aim is to provide some throughput per queue according to its priority (SPI): the higher the priority (the higher the SPI), the higher the allocated bandwidth.

11-28


Iub Bandwidth Limitation

NodeB

HSDPA UE

HSDPA UE

HSDPA UEIub link (N E1s)RNC

DL Traffic

HS-DSCH Flow Control Protocol

RncIn

EM

Fc

iubFlowControlActivation (Fc)

qosBackPressureThreshold (Fc)

qosDiscardThreshold (Fc)

As HS-DSCH Flow Control mechanism may generate large traffic volume than that what can be carried over Iub links, a continuous monitoring of DS, NDS and HSDPA traffic in DL at FP level is done by the PMC PC.

The Iub Bandwidth Limitation feature works with thresholds which represent the peak of traffic allowed on Iub.

There are 2 Discard thresholds: Th1 for DS+NDS and Th2 for DS+NDS+HSDPA.

When DS+NDS reaches Th1, NDS FPs are deleted. When DS+NDS+HSDPA reaches Th2, HSDPA FPs are deleted.

There are also 2 Back Pressure thresholds: Xoff1 for NDS and Xoff2 for HSDPA (eg. Xoffi=95% Thi).

When DS+NDS reaches Xoff1, PMC PC ask PMC RAB to stop transmission of NDS FPs during Txoff1. When DS+NDS+HSDPA reaches Xoff2, PMC PC ask PMC RAB to stop transmission of HSDPA FPs during Txoff2.

DS traffic is not regulated by the Iub bandwidth limitation feature (DS regulation is done by AAL2 CAC).

The regulation is done for AAL2 traffic only. The Iub bandwidth (noted « Th0 ») for AAL2 traffic is given to the RNC through the PCR&SCR parameters defined for the AAL2 VCCs in the RNC. Th0=sum(ECR_GCAC). For typically 5% of AAL5 traffic in DL, then SCR&PCR must to be set so that Th0/10ms=95%*Iub_bandwidth (for 1E1 (4528cells/s), Th0=43cells).

11-29

Student notes

11-30

Student notes

12-1


Location Based Services

Section 12

12-2


Objectives


> Describe Location Based Services principles

> Describe LBS method selection and associated parameters

> Describe Cell Id based LBS and associated parameters

> Describe AGPS based LBS and associated parameters

12-3


Contents

> LBS Principles

> Alcatel-Lucent Implementation

> Location Method Selection

> Cell Id Based Location Method

> UE Based AGPS Location Method

12-4

Student notes

12-5


LBS Principles

12-6


Location Based Services

Business

• Fleet Management

• Vehicle dispatch

• Rental car tracking

• Trucking companies

Business

• Fleet Management

• Vehicle dispatch

• Rental car tracking

• Trucking companiesCopyright © 1996 Northern TelecomC opyrigh t ©

1996

N orthern

T ele com

Service Providers

• Location-based Billing

• Location targeted advertisement

• Customer Service

• Network performance

Service Providers

• Location-based Billing

• Location targeted advertisement

• Customer Service

• Network performance

Copyright © 1996 Northern Telecom

Ed Hobbs

660 N.W. Savart

97330 Tilbury

from 16 Nov 1996

to 15 Dec 1996

Numbersubscription calls

Total

Business line

55 3783

Private line

55 7232

$10.00

$3.00

$33.45$23.45

$47.97$11.52 $14.52

Personal Lifestyles

• Information services

• Traffic Information

• Direction Finding

• Entertainment

Personal Lifestyles

• Information services

• Traffic Information

• Direction Finding

• Entertainment

Copyright © 1996 Northern Telecom

Safety

• Emergency Dispatch (E911)

• Child tracking

• Auto theft tracking

• Roadside assistance

Safety

• Emergency Dispatch (E911)

• Child tracking

• Auto theft tracking

• Roadside assistance

Location Based Services (LBS) are mobile services and applications that make use of the subscriber’s geographical location. Position information about users (person or device) with UMTS adds a new dimension to this service category.These could include mapping or localized shopping and entertainment services.

LoCation Services (LCS) may be considered as a network provided enablingtechnology consisting of standardized service capabilities which enables the provision of location applications. This application may be service provider specific.

Location technology not only enables specific location-based services, but also enhances other services offerings, such as customized infotainment, and will be a major driver for the creation of new applications.

LCS is available to four categories of LCS clients:

• Value added Services LCS clients - supports value added services including mobile subscribers.

• PLMN Operator LCS clients - enhances or supports certain O&M related tasks, supplementary services, IN related services, bearer services and teleservices.

• Emergency Services LCS clients - enhances support for emergency calls from subscribers.

• Lawful Intercept LCS clients - supports various legally required or sanctioned services.

LCS is applicable to any target UE whether or not the UE supports LCS, but with restrictions on choice of positioning method or notification of a location request to the UE user when LCS or individual positioning methods, respectively, are not supported by the UE.

12-7


3GPP UE Location Methods

Serving Cell

Assistance Data

Assisted GPS

d2d2d2

∆∆∆∆∆∆∆∆d2d2 ∆∆∆∆∆∆∆∆d3d3

OTDOACell Coverage

d3d3d3

Serving Cell

NeighborCell # 2

NeighborCell # 1

Various technologies are available to provide Location Services. The positioning feature may use one or more location method to determine the location of UE.

The standard positioning methods are:

• Coverage based methods (Cell-Id based methods)

• Observed Time Difference of Arrival methods

• Assisted GPS methods.

Locating the UE involves two main steps:

• Signal measurements

• Location estimate computation based on the measurements.

The signal measurements may be made by the UE, the NodeB or the Location Measurement Unit (LMU). The basic signals measured are typically the UTRAN radio transmission timings, but some optional methods may make use of other transmission signals such as general radio navigation signals.

The location estimate computation may be made in the UE or by a calculation function located in the UTRAN.

12-8

Student notes

12-9


Alcatel-Lucent Implementation

12-10


Network Architecture for Cell-Id

Uu(RRC)

RNC

Iu(RANAP)

UE

Iub(NBAP)

HLR/AuC

GMLC

3G MSC-VLRExternal

LCS Client

VLR

SMLC

Lh(MAP)

Le(LCAP)

Lg(MAP)

To support location services LCS, additional elements need to be implemented in the network architecture.

LCS is logically implemented within the UMTS network through the addition of one network node: the Gateway Mobile Location Centre (GMLC). Alcatel-Lucentimplements this logical node on the Mobile Location Center platform.

The RNC is the master of the overall process of UE positioning: positioning request handling, UE positioning technology selection, radio resources management, control of the measurement procedures, position calculation function in case of e.g. Cell-ID based positioning.

The Serving Mobile Location Center (SMLC) function is integrated within the RNC.

The serving RNC will always perform the calculation of UE position, in case Cell-ID positioning technology is selected.

12-11


Network Architecture for A-GPS

EGRN

Uu(RRC)

RNC

Iu(RANAP)

UE

Iub(NBAP)

HLR/AuC

GMLC

3G MSC-VLRExternal

LCS Client

VLR

SMLC

Iu PC(PCAP)

MLCSAS

Lh(MAP)

Le(LCAP)

Lg(MAP)

The radio access network remains 3GPP R99 based, except for the Iu-PC interface, which is 3GPP R5 based.

The impacted Radio Access elements are the SAS, the RNC and the OAM platform:

• From the RNC perspective, the SAS acts as a GPS assistance data server (the SAS interfaces to an External GPS Reference -Network EGRN-);

• The RNC shall support some additional coordination functions, new radio interface procedures, Iupc interface procedures and connectivity. Additional RNC processing capability is needed in order to support additional load due to UE positioning activities (e.g. UE positioning message handling);

• The Alcatel-Lucent Mobile Location Center (MLC) shall support the 3GPP SAS functions: GPS assistance data collection and storage, Iupc interface;

• Configuration Management: additional parameters;

• Performance Management: additional counters and traces.

In order to obtain the assistance data, the UTRAN network needs to rely on a continuously operating GPS Reference Network (GRN), which has clear sky visibility of the same GPS constellation as the assisted UEs.

12-12

Student notes

12-13


Location Method Selection

12-14


Operators SettingsIF

ueBasedAgpsActivationAllowed = FALSEORueBasedAgpsParamsEnabled = FALSE

THENExclude UE Based AGPS method from candidate list

ueBasedAgpsActivationAllowed (LocationServices)

ueBasedAgpsParamsEnabled (EmergencyLocationServices)

isUeBasedAgpsActivationAllowed (FDDCell)

isUeBasedAgpsAllowed (NeighbouringRNC)

A-GPS Global Activation

A-GPS Local Activation

IFPrimary Cell within S-RNS coverage

THENIF

isUeBasedAgpsActivationAllowed = FALSETHEN

Exclude UE Based AGPS method from candidate listELSE

IFisUeBasedAgpsAllowed = FALSE


The objectives are to select the UE location method, able to satisfy to the requested horizontal accuracy while taking into account the following constraints: UE capabilities, Network capabilities and operators configured preferences.

In this release, the list of possible UE positioning technologies is initialized as follows:

• Cell Id,

• UE Based AGPS.

This list is successively refined after application of the criteria described above.

It is ensured that the list is never empty after application of all criteria, i.e. at least the Cell Id is available (fall back method).

12-15


UE and UTRAN Capabilities

IFSAS Operational State = UNAVAILABLE


ELSEIF

UE RRC Connected Mode = CELL_FACHTHEN

Exclude UE Based AGPS method from candidate list

Network Capabilities

UE Capabilities

IFUE Assisted GPS Support = Network BasedORUE Assisted GPS Support = None


IFUE Based AGPS method failed

THENUse the results of CellId method

Emergency Service Fallback Method

emergencyLocationServiceActivationAllowed (EmergencyLocationServices)

To get AGPS UE location report, it is needed that the UE is in CELL_DCH RRC State when the RANAP Location Reporting Control (LCR) message arrives to the RNC.

If UE is in idle mode, it will be paged by Core Network, and according to the RRC Connection establishment cause, the UE will be connected in CELL_DCH or CELL_FACH state. If UE is in CELL_FACH State, then only CellId will be reported.

Fallback method selection applies only to Emergency Location Services and refers to the case where one selected method failed (i.e. in this release, only in case UE based A-GPS failed).

12-16

Student notes

12-17


Cell Id Based Location Method

12-18


Cell Id Based Location Technologies

Requested Report Area = Geographical Area

SAI 1

SAI 2

SAI 3

SAI 4

SAI 5

Requested Report Area = Service Area

Point With Uncertainty Point With Uncertainty Polygon

In the cell ID based (i.e. cell coverage) method, the position of an UE is estimated with the knowledge of its serving NodeB and cell. This information may be obtained when the UE is either in CELL_FACH or CELL_DCH state; in all other cases, the Cell-ID information is obtained by paging the UE.

The position estimates can be expressed as the Service Area Identity (SAI) related to the serving cell (in case the result is reported to PS CN domain: PS domain SAI; else CS domain SAI) or as the geographical coordinates of a position related to the serving cell.

When geographical coordinates are used as the position information, the estimated position of the UE can be a fixed geographical position within the serving cell (e.g. geographical position of the serving NodeB) or a geographical position computed by combining information on the cell specific fixed geographical position with other available information (e.g. additional cell provisioned information).

Geographical information can also take the form of a polygonal area defined with the help of provisioned geographical points.

12-19


Geographical Provisioned Information

LocationServices

RNC

CellIdLocationTechnology

NodeB

FDDCell

cellAccuracyCode (CellIdLocationTechnology)

APP GAICoord

lattitude (APP)

latitudeSign (APP)

longitude (APP)

lattitude (GAICoord)

latitudeSign (GAICoord)

longitude (GAICoord)

antennaAngleOfOpening (FDDCell)

azimuthAntennaAngle (FDDCell)

cellIdPositioningMethodAccuracy (FDDCell)

minCellRadius (FDDCell)serviceAreaCode (FDDCell)

The UE position is estimated on following provisioned information basis (if requested report area is Geographical Area).

Per cell provisioned data:

• UTRAN transmitter position (Access Point Position)

• Antenna azimuth

• Antenna angle of opening

• Mean cell radius

• Accuracy code (cellIdPositioningMethodAccuracy)

• Polygonal shape (optional).

Per RNC provisioned precision data:

• Accuracy code (cellAccuracyCode).

12-20


UE Position Estimation Elements

IFRequested Report Area = Geographical Area

THENIF

FDDCell controlled by Alcatel-Lucent RNCTHEN

IFFDDCell controlled by S-RNC

THENReport results of UE position computation

ELSEIF

GAICoord = One PointTHEN

Report Point With Uncertainty = cellAccuracyCode

ELSEReport Polygon Shape

ELSEReport Iur communicated information

ELSEReport serviceAreaCode

When UE position computation is performed (FDDCell controlled by Alcatel-LucentS-RNC) using antenna angle of opening allows to discriminate between omni and sectorial configurations:

• If Omni, UE position estimate is returned as Point With Uncertainty where point is given as the Antenna Position and uncertainty (k) is based on Mean Cell Radius (r) and converted according to 3GPP formula r = 10*(1.1k −1).

• If sectorial, UE position estimate is returned as Point With Uncertainty where point is given as the estimated cell geographical barycenter (computed according to provisioned parameters (antenna position, mean cell radius, antenna azimuth and antenna angle of opening) and uncertainty (k) is based on the radius: r = Mean Cell Radius / 2 and converted according to 3GPP formula: r =10*(1.1k −1).

12-21


UTRAN Provisioning Rules

IFless than 3 valid points defined in GAICoord

THENIF

antennaAngleOfOpening = 360ORantennaAngleOfOpening = 0ORazimuthAntennaAngle = <unset>ORminCellRadius = <unset>

THENGAICoord provisioned with point = APPIF

minCellRadius = <unset>THEN

cellIdPositioningMethodAccuracy provisioned with cellAccuracyCodeELSE

cellIdPositioningMethodAccuracy provisioned with converted value of minCellRadiusELSE

GAICoord provisioned with point = f(APP, antennaAngleOfOpening, azimuthAntennaAngle, minCellRadius)cellIdPositioningMethodAccuracy provisioned with converted value of minCellRadius/2

When Computed, the point is defined as the geometric barycenter of the cell.

Within a local 2D Cartesian referential, the coordinates of the point are defined as:

x = α * R * cos(Ө) and y = α * R * sin(Ө)

• (x, y) denotes the local 2D Cartesian coordinates on the tangential plane from the surface of the earth,

• Ө denotes the antenna orientation of the sector supporting the serving cell,

• R denotes the mean radius of the serving cell (minCellRadius parameter),

• α is a coefficient, which depends on the sector configuration, i.e. from angle of opening β (antennaAngleOfOpening parameter).

Using antennaAngleOfOpening allows to discriminate between Omni and Sectorial configurations:

• Omni (provisioned antennaAngleOfOpening value is 0°or 360°) the UE position estimate will be returned as Point With Uncertainty shape where the point is given as the ‘Antenna Position’ and uncertainty (k) is based on ‘Mean cell radius’ (r) and converted according to 3GPP formula (where r = 10x(1.1k-1)).

• Sectored: the UE position estimate will be returned as Point With Uncertainty shape where the point is given as the estimated cell geographical barycenter(computed according to provisioned ‘antenna position’, ‘Mean cell radius’, ‘Antenna Azimuth’ and ‘Angle of Opening’) and uncertainty (k) is based on the Mean Cell Radius (r) = mincellradius/2 and converted according to 3GPP formula (where r = 10x(1.1k-1)).

12-22

Student notes

12-23


UE Based AGPS Location Method

12-24


GPS UE Location Technologies

UE Location

Autonomous GPS

UE Location

UE-Based AGPS

AGPS Data

GPS Data

UE-Assisted AGPS

AGPS Data

While providing good accuracy in most cases, GPS suffers from a number of issues:

• GPS receiver needs near Line Of Sight to 4 satellites.

• It takes a long time to get a first fix.

• It is very battery consuming, as it continuously monitors the satellites.

It is possible to use Assistance Data provided by the cellular network in order to:

• Reduce the UE GPS start-up and acquisition times.

• Increase the UE GPS sensitivity (assistance data are obtained via UTRAN so UE can operate in low SNR situations).

• Allow the UE to consume less handset power than with stand-alone GPS.

There are two types of Assisted GPS methods which differ according to where the actual position calculation is carried out:

• UE-based: the computation of the position fix is done in the UE.

• UE-assisted: the computation of the position fix is done in the network.

For the UE-based method, a full GPS receiver functionality in the UE is required, allowing stand-alone location fixes.

For the UE-assisted method, the UE may employ a reduced complexity GPS receiver functionality:

• this receiver carries out the pseudo-range (code phase) measurements,

• these are signaled, using higher layer signaling, to the specific network element that estimates UE location and carries out the remaining GPS operations.

12-25


UE-Based A-GPS Principles

RANAP LOCATION REPORT

RANAP LOCATION REPORTING CONTROL

RRC MEASUREMENT CONTROL (setup, no report, Delay tolerant GPS assistance data set #1)

PCAP Information Exchange Initiation Request

PCAP Information Exchange Initiation Response

• A-GPS measurements

• UE position computation RRC MEASUREMENT REPORT (UE location information)

RRC MEASUREMENT CONTROL (modify, request one report, Additional assistance data request not allowed, Delay Sensitive assistance data set)

…

RRC MEASUREMENT CONTROL (setup, request one report, UE allowed to Request additional assistance data, Reference UE Position)

RRC MEASUREMENT REPORT (UE positioning)

SRNCSAS

raw position estimate (Cell Id)

GPS assistancedata computation

The Cell-Id method is invoked in order to obtain the UE raw position. The UE position is provided as Polygon or Point With Uncertainty circle shape.

In UE-Based method, UE is instructed to report its own position. The UE is allowed to request additional assistance data, if it has not perform enough GPS measurements.

In most cases, RNC receives UE report indicating that additional assistance data are needed. RNC computes the GPS assistance data delivery roadmap (identification of the GPS assistance data acquisition / delivery steps to be performed).

At reception of the UE report including a valid result, the RNC checks whether the AGPS result is more accurate than the Cell-Id result.

RNC reports to the Core Network the Cell-Id result if more accurate than A-GPS returned UE position otherwise the RNC uses the A-GPS method result.

12-26


UE-Based A-GPS Main Parameters

LocationServices

RNC

AGPSUeBasedLocationTechnology

emergencyLocationServiceActivationAllowed (LocationServices)

ueBasedAgpsActivationAllowed (LocationServices)

maxNbGpsSatellites (AGPSUeBasedLocationTechnology)

tDelayBetweenGpsAssistanceDataSegments (AGPSUeBasedLocationTechnology)

tmaxDurationSensitiveDataAcquisition (AGPSUeBasedLocationTechnology)

tmaxDurationSensitiveDataTransfer (AGPSUeBasedLocationTechnology)

horizontalAccuracyRequestedtoUe (AGPSUeBasedLocationTechnology)

MaxNbGpsSatellites defines the number of GPS Satellites for which GPS assistance data are delivered to UE.

tDelayBetweenGpsAssistanceDataSegments is the minimum delay between successive emission by RNC of a RRC MEASUREMENT CONTROL message including GPS assistance data.

tmaxDurationSensitiveDataAcquisition Is the maximum time for acquiring the delay sensitive GPS Assistance data from SAS.

tmaxDurationSensitiveDataTransfer Is the maximum time for transferring the delay sensitive GPS Assistance data from SAS.

horizontalAccuracyRequestedToUE defines the Horizontal Accuracy, which will be requested to UE for its location fix. It is expressed as Uncertainty Code k. So the uncertainty in meter is derived from formula r = 10*(1.1k-1) in meters.

12-27

Student notes

12-28

Student notes

13-1


Glossary

Section 13

13-2

Code Division Multiple AccessCDMA

Coded Composite Transport CHannelCCTrCH

Common Control Physical CHannelCCPCH

Communication Control PortCCP

Common Control CHannelCCCH

Chase CombiningCC

Call Admission ControlCAC

Base Transceiver StationBTS

Binary Phase Shift KeyingBPSK

Broadcast Multicast ControlBMC

BLock Error RateBLER

NodeB Frame NumberBFN

Bit Error RateBER

Broadcast CHannelBCH

Broadcast Control CHannelBCCH

Asynchronous Transfer ModeATM

Access Service ClassASC

Access StratumAS

Automatic Repeat QueryARQ

Adaptive Multi-RateAMR

Acknowledged Mode DataAMD

Adaptive Modulation and CodingAMC

Acknowledged ModeAM

Acquisition Indicator CHannelAICH

ACKnowledgmentACK

ATM Adaptation Layer type 5AAL5

ATM Adaptation Layer type 2AAL2

3x Evolution Data and Voice3xEV-DV

3rd Generation Partnership Project3GPP

1 times 1.25MHz Radio Transmission Technology1xRTT

1x EVolution Data and Voice1xEV-DV

1x EVolution Data Only1xEV-DO

16-state Quadrature Amplitude Modulation16-QAM

13-3

FeedBack InformationFBI

Forward Access CHannelFACH

EDGE GPRSEGPRS

Enhanced Data for Global EvolutionEDGE

Standard European PCM link (2.048 Mbps)E1

Discontinuous TransmissionDTX

Dedicated Traffic CHannelDTCH

Downlink Shared CHannelDSCH

Direct Sequence-Code Division Multiple AccessDS-CDMA

Delay SensitiveDS

Drift-Radio Network ControllerD-RNC

Dedicated Physical Data CHannelDPDCH

Dedicated Physical CHannelDPCH

Dedicated Physical Control CHannelDPCCH

DownlinkDL

Dedicated CHannelDCH

Dedicated Control CHannelDCCH

Common Traffic CHannelCTCH

Circuit SwitchCS

Cell-Radio Network Temporary IdentityC-RNTI

Controlling-Radio Network ControllerC-RNC

Cyclic Redundancy CheckCRC

Channel Quality IndicatorCQI

Common PIlot CHannelCPICH

Common Packet CHannelCPCH

Control PlaneCP

NodeB Control PortCP

Common transport CHannel Priority Indicator (SPI)CmCH-PI

Compressed ModeCM

Ciphering KeyCK

Channel IDentifierCID

Connection Frame NumberCFN

Channel Element ModuleCEM

13-4

Layer 1 (Physical Layer)L1

Kilo symbol per secondKsps

Key Performance IndicatorKPI

kiloHertzkHz

Kilobit per second Kbps

Interface between two RNCsIur

Interface between NodeB and RNCIub

Interconnection point between RNC and 3G Core Network

Iu

Incremental RedundancyIR

Internet ProtocolIP

International Mobile Telecommunication for year 2000IMT-2000

International Mobile Subscriber IdentityIMSI

International Mobile Equipment IdentityIMEI

Inverse Multiplexing ATMIMA

Integrity KeyIK

Information ElementIE

High Speed Shared Control CHannelHS-SCCH

High Speed Physical Downlink Shared CHannelHS-PDSCH

High Speed Downlink Shared CHannelHS-DSCH

High Speed Dedicated Physical Control CHannelHS-DPCCH

High Speed Downlink Packet AccessHSDPA

HS-DSCH Radio Network Temporary IdentifierH-RNTI

HandOverHO

Hyper Frame NumberHFN

Hybrid ARQH-ARQ

GPRS Tunneling ProtocolGTP

Global System for Mobile communicationsGSM

General Packet Radio ServiceGPRS

Global Mobility ManagementGMM

Frame ProtocolFP

First In First OutFIFO

Frequency Division Multiple AccessFDMA

Frequency Division DuplexFDD

13-5

Paging CHannelPCH

Primary-Common Control Physical CHannelP-CCPCH

Paging Control CHannelPCCH

Power AmplifierPA

Orthogonal Variable Spreading FactorOVSF

Operation Administration and MaintenanceOAM

Non Return to ZeroNRZ

Logical node responsible for radio Tx/Rx to/from UENodeB

Non-Delay SensitiveNDS

New Data IndicatorNDI

NodeB Application PartNBAP

Non Access StratumNAS

Negative ACKnowledgementNACK

Most Significant BitMSB

Mean Opinion ScoreMOS

Managed Object InstanceMOI

Managed Object ClassMOC

Mobile Network CodeMNC

Mobility ManagementMM

Mix Incremental RedundancyMIR

MegaHertzMHz

Megachip per secondMcps

Multi Carrier Power AmplifierMCPA

Mobile Country CodeMCC

Megabit per secondMbps

Medium Access ControlMAC

Least Significant BitLSB

Local Area NetworkLAN

Location Area IdentityLAI

Location Area CodeLAC

Location AreaLA

Layer 3 (Network Layer)L3

Layer 2 (Data Link Layer)L2

13-6

Rate MatchingRM

Radio Link ControlRLC

Radio LinkRL

Radio FrequencyRF

Radio BearerRB

Radio Access Network Application PartRANAP

Radio Access NetworkRAN

Random Access CHannelRACH

Routing Area CodeRAC

Radio Access BearerRAB

Routing AreaRA

Release 5R5

Release 4R4

Quadrature Phase Shift KeyingQPSK

Quality of ServiceQoS

Queue IdentityQId

Phase Shift KeyingPSK

Primary-Synchronization CHannelP-SCH

Packet SwitchPS

Physical Random Access CHannelPRACH

Priority QueuePQ

Pseudo NoisePN

Packet Mobility ManagementPMM

Public Land Mobile NetworkPLMN

Partial Incremental RedundancyPIR

Paging Indicator CHannelPICH

Priority IndicatorPI

Paging IndicatorPI

Protocol Data UnitPDU

Protocol Data UnitPDU

Packet Data ProtocolPDP

Physical Common Control CHannelPCPCH

Pulse Code ModulationPCM

13-7

Time Division DuplexTDD

Transmission Control ProtocolTCP

Transport Block SizeTBS

Transport BlockTB

That's All Folks! TAF

Space Time Transmit DiversitySTTD

Secondary-Synchronization CHannelS-SCH

Serving-Radio Network ControllerS-RNC

Synchronous Radio Link ReconfigurationSRLR

Scheduling Priority Indicator (CmCH-PI)SPI

Signal to Noise RatioSNR

Session ManagementSM

Signal to Interference RatioSIR

Subscriber Identity ModuleSIM

Soft HandOverSHO

System Frame NumberSFN

Spreading FactorSF

Service Data UnitSDU

Sustainable Cell RateSCR

Synchronization CHannelSCH

Secondary-Common Control Physical CHannelS-CCPCH

Stop And WaitSAW

Service Access PointSAP

Service AreaSA

Receiver / ReceptionRX

Redundancy VersionRV

Radio Transmission TechnologyRTT

Radio Resource ManagementRRM

Radio Resource ControlRRC

Radio Network Temporary IdentityRNTI

Radio Network Subsystem Application PartRNSAP

Radio network subsystemRNS

Radio Network ControllerRNC

13-8

Wideband-CDMAW-CDMA

Voice over IPVoIP

Virtual Channel ConnectionVCC

the radio interface between UTRAN and UEUu

Universal Terrestrial Radio Access NetworkUTRAN

UTRAN-Radio Network Temporary IdentityU-RNTI

UTRAN Registration AreaURA

User PlaneUP

Universal Mobile Telecommunication SystemUMTS

Unacknowledged ModeUM

User EquipmentUE

User Datagram ProtocolUDP

UMTS Absolute Radio Frequency Channel NumberUARFCN

Transmitter / TransmissionTX

Transmission Time IntervalTTI

Time SlotTS

Transcoder Free OperationTrFO

Transport CHannelTrCH

Transmit Power ControlTPC

Transport Format SetTFS

Transport Format and Resource IndicatorTFRI

Transport Format and Resource CombinationTFRC

Tandem Free OperationTFO

Transport Format IndicatorTFI

Transport Format Combination IndicatorTFCI

Transport Format CombinationTFC

Transport FormatTF

Time Division Multiple AccessTDMA

Time Division MultiplexingTDM

13-9

Student notes

13-10

Student notes

Documents

ALU UTRAN Parameters Description.pdf