UMTS Terrestrial Radio Access
Network (UTRAN)
Parameters Description
Student Guide
Guide release: 04.03
Guide status: Standard
Date: 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.
Course introduction
Overview
Description
This 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 audience
This course is mostly intended for technicians and engineers involved in UMTS activities such
as RF Engineering, optimization, Network Design, UTRAN Datafill, Trials and VO.
Prerequisites
This course has the following prerequisites:
• UMTS System Description (2911A)
• UMTS Radio Interface (3038A)
Objectives
After 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.
References
The following documents provide additional information:
NTP 411-8111-813P1
Access Network Parameters — Volume 1 - RAN Model Information
NTP 411-8111-813P2
Access Network Parameters — Volume 2 - ANode Parameters
NTP 411-8111-813P3
Access Network Parameters — Volume 3 - CNode Parameters
NTP 411-8111-813P4
Access Network Parameters — Volume 4 - INode Parameters
NTP 411-8111-813P5
Access Network Parameters — Volume 5 - BTS Parameters
NTP 411-8111-813P6
Access Network Parameters — Volume 6 - OAM Parameters
NTP 411-8111-813P7
Access Network Parameters — Volume 7 - POC Parameters
3GPP TS 25.201
Physical layer - general description
3GPP TS 25.211
Physical channels and mapping of transport channels onto physical channels
3GPP TS 25.212
Multiplexing and channel coding
3GPP TS 25.213
Spreading and modulation
3GPP TS 25.214
Physical layer procedures
3GPP TS 25.215
Physical layer; Measurements
3GPP TS 25.301
Radio interface protocol architecture
3GPP TS 25.302
Services provided by the physical layer
3GPP TS 25.308
UTRA High Speed Downlink Packet Access (HSDPA); Overall description
3GPP TS 25.321
Medium Access Control (MAC) protocol specification
3GPP TS 25.322
Radio Link Control (RLC) protocol specification
3GPP TS 25.323
Packet Data Convergence Protocol (PDCP) specification
3GPP TS 25.324
Broadcast/Multicast Control (BMC)
3GPP TS 25.331
Radio Resource Control (RRC) protocol specification
3GPP TS 25.401
UTRAN overall description
3GPP TS 25.402
Synchronization in UTRAN
3GPP TS 25.944
Channel coding and multiplexing examples
3GPP TS 25.993
Typical examples of Radio Access Bearers (RABs) and Radio Bearers (RBs)
supported by Universal Terrestrial Radio Access (UTRA)
3GPP TS 34.108
Common test environments for User Equipment (UE); Conformance testing
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
Version
Date
Comments
04.01
August 2005
Creation (UA04.01+HSDPA) based on former
UM015 (UMT/TRD/CN/0021 03.03/EN)
04.02
July 2006
Correction, modification and update (UA04.02)
04.03
August 2006
Minor corrections
Discover Knowledge Services
Section 1
3FL12812AAAAWBZZA Ed2
1-1
March 2007
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-2
3FL12812AAAAWBZZA Ed2
1-2
March 2007
Course 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 Services
1-3
3FL12812AAAAWBZZA Ed2
1-3
March 2007
Student notes
1-4
UTRAN Parameters & Objects
Section 2
3FL12812AAAAWBZZA Ed2
2-1
March 2007
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-2
3FL12812AAAAWBZZA Ed2
2-2
March 2007
Contents
> UTRAN Configuration Overview
> UTRAN Parameters Organization
2-3
3FL12812AAAAWBZZA Ed2
2-3
March 2007
Student notes
2-4
UTRAN Configuration Overview
2-5
3FL12812AAAAWBZZA Ed2
2-5
March 2007
UTRAN Configuration Process & Tools
Planning
Activities
ATM
RF
ND
Provisioning
Activities
IP
WPS for Access
OA&M
Activities
Configuration Data
Main Server
3FL12812AAAAWBZZA Ed2
2-6
March 2007
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.
Note
These steps do not necessarily apply to other contexts, such as introduction of new
features, addition of new NEs, network optimization, …
2-6
Customer Input Questionnaire
•
•
•
•
• Network Requirements
• Deployment Constraints
• ...
Network System Definition
Engineering rules
Addressing rules
...
• A
T
RRM Parameters
• A M Para
TM
met
RRM Parameters
P
• An
e
sig TM arame rs
r
e
RRM Parameters
t
t
P
•
e
e
n
a
rs
s
…
r am
m
et er
…Para eDteerssig gn
P
e
s
m
i
I
s
a k
•
Par or eteDr es
• IP Patwramork k D eters
e
• IP N etw oPr aram eters
. N RtFw
•
.
.
• • • e Param
N F
•• R
…
•• …
•
•
•
•
Operator
Teams
2-7
Engineering
Teams
(Core, Local)
CIQ
3FL12812AAAAWBZZA Ed2
March 2007
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-7
UTRAN CM Solution Overview
Wireless – Network Management System
OffOff-line
OnOn-line
WPS Access
Main Server
XML
XML Files
Engineering Tools
Open
Interface
I-Node
C-Node
RNC
Provisioning
2-8
BTS
NodeB
OA&M
3FL12812AAAAWBZZA Ed2
March 2007
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-8
UTRAN CM XML Files Exchange
WPS
D
Import/Export
Import/Export
S
XML Snapshots
WPS Import
WPS Export
S WNMS Export
D WNMS Import
Main Server
XML Workorders
S
D
Live Network
WPS
3FL12812AAAAWBZZA Ed2
2-9
March 2007
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-9
Student notes
2-10
UTRAN Parameters Organization
2-11
3FL12812AAAAWBZZA Ed2
2-11
March 2007
UTRAN Objects Mapping
FDDCell/0
BTSCell/0
NodeB
BTSEquipment
FDDCell/1
AN
RNC
CN
BTSCell/1
PP7K-AN
IN
PP15K-IN
RNCEquipment
Logical Configuration
2-12
Hardware Equipment
3FL12812AAAAWBZZA Ed2
March 2007
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 the
NodeB 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-12
UTRAN Parameter Domain
MIB
RAN Model
Based
NodeB
Control
Node
WiPS
W-NMS
MIB
Passport
Based
Access
Node
2-13
Interface
Node
3FL12812AAAAWBZZA Ed2
March 2007
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-13
RAN Parameter Types
Accessible via
OAM GUI
ADDRESSING
Static
Configuration
Main
Server
OPTIMIZATION
OPERATION
Customer
DESIGN
Manufacturer
SYSTEM
PRODUCT
Accessible via
command line (WICL)
2-14
3FL12812AAAAWBZZA Ed2
March 2007
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-14
RAN Attribute Activation Classes
Class 0
activation classes apply to
Customer and Manufacturer parameters
Class 1
MIB
MIB build required
(most common case)
Class 2
reset required
Class 3
lock/unlock required
on-line modification allowed
3FL12812AAAAWBZZA Ed2
2-15
March 2007
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-15
RAN Object Activation Classes
Not Allowed
on-line Creation / Deletion behavior
Allowed With Parent
MIB
MIB build required
Allowed With Lock
parent modification required
Allowed
lock/unlock required
on-line modification allowed
3FL12812AAAAWBZZA Ed2
2-16
March 2007
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-16
RRM Subtree
RNC
RadioAccessService
DedicatedConf
ConfigurationClassX
InstanceN
ConfigurationClassY
InstanceN
Instance...
ConfigurationClassZ
InstanceN
Instance...
Instance...
Instance...
Instance3
Instance3
Instance2
Instance2
Instance1
2-17
Instance1
Instance2
Instance1
3FL12812AAAAWBZZA Ed2
March 2007
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-17
Configuration Classes Instantiation
RNC
RadioAccessService
DedicatedConf
MeasurementConfClass
PowerCtrlConfClass
HoConfClass
CacConfClass
NeighbouringRNC
Example
CacConfClass/0
NeighbouringRNC
cacConfClassId
0
firstRlOvsfCodeCacThreshold
85
maxUlEstablishmentRbRate
384
maxUlInterferenceLevel
2-18
3FL12812AAAAWBZZA Ed2
-50.0
March 2007
Configuration Classes are involved in NodeB, FDDCell and NeighbouringRNC
configuration.
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 dBm
according to the selected instance.
These parameters will be taken into account when the Iur are datafilled during WPS
sessions.
2-18
Student notes
2-19
Student notes
2-20
UTRAN Configuration
Section 3
3FL12812AAAAWBZZA Ed2
3-1
March 2007
Objectives
After this section, you will be able to
> 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-2
3FL12812AAAAWBZZA Ed2
3-2
March 2007
Contents
> OAM Objects Configuration
> RNC Configuration
> NodeB Configuration
> BTS Configuration
3-3
3FL12812AAAAWBZZA Ed2
3-3
March 2007
Student notes
3-4
OAM Objects Configuration
3-5
3FL12812AAAAWBZZA Ed2
3-5
March 2007
OAM Shared Objects
frequencyBand (Operator)
mobileCountryCode (Operator)
mobileNetworkCode (Operator)
type (Operator)
dlFrequencyList (NodeBCommonParam)
testFrequency (NodeBcommonParam)
ulFrequencyList (NodeBCommonParam)
GSMBandIndicator (RNCCommonParam)
3-6
3FL12812AAAAWBZZA Ed2
March 2007
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 in
the 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 UARFCNs
in 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-6
RNC Configuration
3-7
3FL12812AAAAWBZZA Ed2
3-7
March 2007
Identification & Capacity
NodeB
RNC
NodeB
NodeB
rncId (RNC)
NodeB
RNC
NodeB
rncId (RNC)
NodeB
cnodeCapacity (RNC)
NodeB
3FL12812AAAAWBZZA Ed2
3-8
March 2007
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-8
NodeB Configuration
3-9
3FL12812AAAAWBZZA Ed2
3-9
March 2007
FDDCell Identifiers
Logical Objects
(3GPP)
Physical Objects
(Alcatel-Lucent)
Operator (OAM)
RNC
BTSEquipment
NodeB
rncId (RNC)
+
cellId (FDDCell)
BTSCell
FDDCell
=
ucid (FDDCell)
localCellId (FDDCell)
3-10
3FL12812AAAAWBZZA Ed2
March 2007
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-10
Channel Numbers
RNC
NodeB
Operator (OAM)
NodeBCommonParam
FDDCell
dlFrequencyNumber (FDDCell)
3-11
ulFrequencyNumber (FDDCell)
ITU Region
UL (MHz)
UARFCN
DL (MHz)
UARFCN
1 and 3
1920-1980
9612-9888
2110-2170
10562-10838
2
1850-1910
9262-9538
1930-1990
9662-9938
3FL12812AAAAWBZZA Ed2
March 2007
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-11
Scrambling Codes
primaryScramblingCode (FDDCell)
aichScramblingCode (RACH)
sccpchDlScramblingCode (SCCPCH)
NodeB
Scrambling code
Channelization code 1
User 1 signal
Channelization code 2
User 2 signal
Channelization code 3
User 3 signal
3-12
3FL12812AAAAWBZZA Ed2
March 2007
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 Code
The 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 Code
Scrambling 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-12
Synchronization
tCell = 0
F1
tCell = 3
F1
tCell = 0
tCell = 3
F2
F2
NodeB
tCell (FDDCell)
F1
tCell = 6
Twin Cells
F2
3-13
tCell = 6
3FL12812AAAAWBZZA Ed2
March 2007
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-13
Neighboring Cells Definition
RNC
GsmNeighbour/0
GSMCell/ci.lac.mcc.mnc
NodeB
FDDCell
FDDCell
cgi
ucid
GSMNeighbouringCell/ci.lac.mcc/mnc
3-14
UMTSFddNeighbouringCell/rncId.cellId
bcchFrequency (GSMCell)
primaryScramblingCode (UMTSFddNeighbouringCell)
bcc (GSMCell)
dlFrequencyNumber (UMTSFddNeighbouringCell)
ncc (GSMCell)
ulFrequencyNumber (UMTSFddNeighbouringCell)
3FL12812AAAAWBZZA Ed2
March 2007
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-14
SIB11/DCH Neighboring Lists
NodeB
SI broadcast
P-CCPCH
OR
DCH
DCH
UE
DCH
Measurement Control
RRC
DCH
SIB11
+
DCH
DCH
DCH
SIB11
+
DCH
sib11AndDchNeighboringFddCellAlgo (FDDCell)
DCH
sib11OrDchUsage (UMTSFddNeighboringCell)
SIB11
+
DCH
SIB11
+
DCH
DCH
SIB11
+
DCH
DCH
SIB11
+
DCH
FDDCell
SIB11
+
DCH
DCH
SIB11
+
DCH
DCH
SIB11
+
DCH
SIB11
+
DCH
DCH
SIB11
+
DCH
DCH
DCH
SIB11
+
DCH
DCH
DCH
DCH
DCH
3FL12812AAAAWBZZA Ed2
3-15
March 2007
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-15
Configuration Classes Instantiation
RNC
RadioAccessService
DedicatedConf
MeasurementConfClass
PowerConfClass
PowerCtrlConfClass
PowerPartConfClass
HoConfClass
CacConfClass
FDDCell
Example
PowerPartConfClass/0
FDDCell
powerPartId
3-16
0
callAdmissionRatio
85
minSpeechPowerRatio
0
minDataPowerRatio
0
minSignallingPowerRatio
0
3FL12812AAAAWBZZA Ed2
March 2007
Configuration classes have several instances where each instance has its own
parameter settings. Once all the configuration classes are defined, each FDDcell
belonging 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 PowerPartConfClass
includes 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-16
Transmit Diversity
Different fading
channels
FBI / DPCCH
(closed loop)
Signal level (dB)
UE Rake
Combining
txDiversityIndicator (static)
Slow fading
sttdIndicator (NodeB)
Path loss
Gain in capacity
Fast fading
Gain in coverage
Log (distance)
3-17
3FL12812AAAAWBZZA Ed2
March 2007
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-17
Student notes
3-18
BTS Configuration
3-19
3FL12812AAAAWBZZA Ed2
3-19
March 2007
BTSCell Identifiers
localCellGroupId = 0
priority = 1
localCellId = 1000
rdnId = 0
rdnid (BTSCell)
localCellId (BTSCell)
rdnId = 2
localCellId = 1002
3-20
rdnId = 1
localCellId = 1001
3FL12812AAAAWBZZA Ed2
March 2007
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-20
Frequencies
F1
localCellgroupId = 0
localCellid = 1001
localCellGroupId (BTSCell)
frequencyBand (BTSEquipment)
F2
testFrequency (BTSEquipment)
localCellgroupId = 1
localCellid = 1011
localCellgroupId = 0
F1
localCellid = 1003
STSR-2-6-3
F2
F1
localCellgroupId = 0
localCellid = 1002
F2
localCellgroupId = 1
localCellgroupId = 1
localCellid = 1013
localCellid = 1012
3-21
3FL12812AAAAWBZZA Ed2
March 2007
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-21
TRM Defense Mechanism
localCellGroupId 0
frequencyGroupId (localCellGroup) 0
localCellGroupId 0
priority (localCellGroup) 1
F1
localCellGroupId 0
F1
localCellGroupId 0
F1
Highest priority
TRM-1
STSR 2-6-3
TRM-2
F2
localCellGroupId 1
localCellGroupId 1
F2
F2
frequencyGroupId (localCellGroup) 0
localCellGroupId 1
priority (localCellGroup) 2
localCellGroupId 1
3-22
3FL12812AAAAWBZZA Ed2
March 2007
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-22
Antenna Access
BTSEquipment
AntennaAccess
BTSCell
localCellGroup
BTS
Masthead
equipment
DDM
RF cables
(2 per sector)
TMA
TMA
TMA
tmaAccessType (AntennaAccess)
antennaConnectionList (BTSCell)
3-23
3FL12812AAAAWBZZA Ed2
March 2007
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-23
Rake Receiver
rakeMode (BTSEquipment)
4 or 8 fingers
RX
Delay τ1
cellSize (BTSCell)
Delay (ττn)
C(t-ττn)
τn
D(t)
TX
C(t)
RX
Delay τ0
Delay (ττ1)
C(t-ττ1)
+
τ1
RX
Spreading &
Scrambling
Delay (ττ0)
C(t-ττ0)
τ0
3-24
3FL12812AAAAWBZZA Ed2
March 2007
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-24
Student notes
3-25
Student notes
3-26
Measurements
Section 4
3FL12812AAAAWBZZA Ed2
4-1
March 2007
Objectives
After this section, you will be able to
> 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-2
3FL12812AAAAWBZZA Ed2
4-2
March 2007
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-3
3FL12812AAAAWBZZA Ed2
4-3
March 2007
Student notes
4-4
UMTS Measurements Principles
4-5
3FL12812AAAAWBZZA Ed2
4-5
March 2007
Reported Measurements
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
Inter System Measurements
• GSM Carrier RSSI
• Path Loss
• BSIC
• Observed time difference to GSM Cell
Traffic Volume Measurements (UL)
Quality Measurements
• Transport Channel BLER
• SIR
RRC Measurements
UE Internal Measurements
• UE Transmitted Power
• UE Position (UEbased GPS)
RNC
NodeB
UE
NBAP Measurements
• DL Transmitted Carrier Power
• UL Received Total Wideband Power
• Acknowledged PRACH Preamble
• SIR
• SIR Error
• DL Transmitted Code Power
• Round Trip Time
BTS In-Band Measurements
• Propagation Delay (RACH)
• BLER (CRCI)
• BER (QE)
4-6
3FL12812AAAAWBZZA Ed2
March 2007
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: intrafrequency, 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-6
Measurements Elaboration
RRC Measurements
REPORTING
UE
ESTIMATING
FILTERING
FN = (1 - a).FN-1 + a.MN
filter coefficient
acquisition time
reporting period
or
event triggered
RNC
NodeB
NBAP Measurements
4-7
3FL12812AAAAWBZZA Ed2
March 2007
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-7
Measurements Activation
isEventTriggeredMeasAllowed
(FDDCell)
isInterFreqMeasActivationAllowed
(RadioAccessService)
isGsmMeasActivationAllowed
(RadioAccessService)
RNC
ueInternalMeasurementQuantity
(UEIntMeas)
ueInternalMeasurementFilterCoeff
(UEIntMeas)
measurementConfId
(FDDCell)
measurementConfClassId
(NeighbouringRNC)
isQualityMeasurementAllowed
(MeasurementConfClass)
4-8
3FL12812AAAAWBZZA Ed2
March 2007
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 interfrequency 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.
Note
UeIntMeas is an optional objects.
4-8
Main Measurements
4-9
3FL12812AAAAWBZZA Ed2
4-9
March 2007
Cells Sets
Cells belonging to the Active Set
isDetectedSetCellsAllowed
(RadioAccessService)
Cell belonging to the Detected Set
Cell belonging to the Monitored Set
4-10
3FL12812AAAAWBZZA Ed2
March 2007
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-10
Power Measurements
Intra/Inter-Frequency
Intra/Inter-Frequency
-25 -15 -10
Ec/No
Pilot
(dB)
Pilot
CPICH_RSCP =
Received Signal
Code Power
measured on
CPICH OVSF
code
CPICH_Ec/No =
Inter-System
GSM CARRIER RSSI =
4-11
0
Power density
of CPICH
Power density
in the band
GSM Signal
Received Power on the
GSM BCCH carrier
3FL12812AAAAWBZZA Ed2
March 2007
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 reselection and for handover preparation, open loop power control and pathloss
calculation.
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-11
Signal to Interference Ratio
SIR_Error= SIR – SIR Target
Serving
RNC
UL outer loop
power control
SIR =
Power Control
SIR Target
DL outer loop
power control
SF
2
x
RSCP
ISCP
SF x
Received Signal Code Power
Interference Signal Code Power
DPCCH
= SIR
DPCCH
R
SI
4-12
3FL12812AAAAWBZZA Ed2
=
nk
Li
Q
ua
y
lit
Es
at
t im
n
io
March 2007
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 Error
SIR 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/2
The 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 be
clearly 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-12
Path Loss
Path Loss = Primary CPICH Tx Power
-
P-CPICH_RSCP
P-CPICH
Path Loss
Path Loss
FDD Cell
4-13
3FL12812AAAAWBZZA Ed2
March 2007
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-13
QE and CRCI
NodeB
RNC
Frame Protocols
IE QE Selector:
Physical
Channel
Transport Channels
block
block
« non-selected »
Quality Estimate:
Physical Channel BER
OR
« selected »
Transport Channel BER
• Soft Handover
• UL outer loop Power Control
CRC
Indicator
qeSelector (Static)
4-14
3FL12812AAAAWBZZA Ed2
March 2007
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-14
NBAP Measurement Procedures
4-15
3FL12812AAAAWBZZA Ed2
4-15
March 2007
NBAP Measurements Initiation
C-RNC
NodeB
Common
Measurement Initiation Request
Dedicated
Measurement
ID
• Cell
• RACH
•…
Measurement
Object
Type
Measurement
type
Measurement
Filter
Coefficient
Report
Characteristics
• On Demand
• Event-Triggered
• Periodic
• Common
• Dedicated
• DL Transmitted Carrier Power
• DL Transmitted Code Power
• SIR
• RTT
• ...
4-16
• RTWP
• ...
3FL12812AAAAWBZZA Ed2
March 2007
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-16
NBAP Measurements Reports
NodeB
C-RNC
commonMeasurementReportingPeriod
(NBAP Measurement)
Common Measurement Reports
r5NbapCommonMeasurementReportingPeriod
(NBAP Measurement)
commonMeasurementFilterCoeff
(NBAP Measurement)
Measurement
ID
Report
Type
Measured Quantity
Common Measurement Termination Request
4-17
3FL12812AAAAWBZZA Ed2
March 2007
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 the
measurement 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-17
Call Trace
NodeB
C-RNC
Common
tcpRequired
(NbapCommonMeasConfigForCallTrace)
tcpReportPeriodicity
(NbapCommonMeasConfigForCallTrace)
Dedicated
rssiRequired
(NbapCommonMeasConfigForCallTrace)
rssiPeridodicity
(NbapCommonMeasConfigForCallTrace)
Measurement Initiation Request
Common
Measurement Reports
Dedicated
sirRequired
(NbapDedicatedMeasConfigForCallTrace)
sirReportPeridodicity
(NbapDedicatedMeasConfigForCallTrace)
transmittedCodePowerRequired
(NbapDedicatedMeasConfigForCallTrace)
transmittedCodePowerPeridodicity
(NbapDedicatedMeasConfigForCallTrace)
roundTripTimeRequired
(NbapDedicatedMeasConfigForCallTrace)
roundTripTimePeriodicity
(NbapDedicatedMeasConfigForCallTrace)
4-18
Common Measurement Termination Request
Dedicated Measurement Termination Request
3FL12812AAAAWBZZA Ed2
March 2007
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-18
Event Triggered Reports
NodeB
C-RNC
iRM Scheduling Downgraded UE
Dedicated Measurement Initiation Request (Bx)
Primary Cell
RL Monitoring
• Event A
• Event B1
• Event B2
NBAP Dedicated Report Event Bx
Dedicated Measurement Termination Request (Bx)
4-19
3FL12812AAAAWBZZA Ed2
March 2007
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-19
Event A
Event A
Report
Transmitted Code Power
Primary Cell
TxCP
Threshold
Event A Timer
Event A Timer
dlIrmSchedDowngradeTxcpTrigger_threshold_delta
(DlUsPowerConf)
dlIrmSchedDowngradeTxcpTrigger_timeToTrigger
(DlUsPowerConf)
4-20
3FL12812AAAAWBZZA Ed2
March 2007
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-20
Event B1 & Event B2
Event B1 Event B2
Report
Report
Transmitted Code Power
Primary Cell
Event B2
Threshold
thresholdTransCodePower (DhighRbB1)
Event B1
Threshold
deltaThresholdTransCodePower (DhighRbB2)
timeToTrigger (DhighRbB1)
deltaTimeToTrigger (DhighRbB2)
Event B1 Timer
Event B2 Timer
Event B2 Timer = Event B1 Timer + deltaTime
4-21
Event B2 Threshold = Event B1 Threshold + deltaTCP
3FL12812AAAAWBZZA Ed2
March 2007
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.
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 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.
Event B2 configuration relies on:
• 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-21
Student notes
4-22
RRC Measurement Procedures
4-23
3FL12812AAAAWBZZA Ed2
4-23
March 2007
RRC Measurements Initiation
SI broadcast
P-CCPCH
UE
OR
NodeB
Measurement Control
RRC
Measurement Measurement Measurement Measurement Measurement
ID
Command
Type
Object
Quantity
• Setup
• Modify
• Release
4-24
Inter-Frequency
Intra-Frequency
Inter-System
Traffic Volume
Quality
UE internal
• FDDCell
• Physical Channel
• RB
•…
Measurement Measurement
Reporting
Reporting
Reporting
Mode
Quantity
Criteria
• Ec/No
• RSCP
• BLER
• Traffic Volume
• ...
3FL12812AAAAWBZZA Ed2
• Periodical
• Event-Triggered
• RLC AM
• RLC UM
March 2007
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: interfrequency, 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-24
Intra-Frequency Reporting
Measurement Report
rrcIntraFreqMeasurementReportingPeriod
(RRC Measurement)
rrcIntraFreqMeasurementFilterCoeff
(RRC Measurement)
Measurement Report
Measurement
ID
Measurement
Results
Measurement
Reporting
Quantity
Active Set cells
+
Best Monitored cells
NodeB
• Cell Synchronization information (SFN-CFN)
• CPICH Ec/No
repMode (static)
maxCellsRepType (static)
• CPICH RSCP
• SFN-SFN observed time difference « type2 »
4-25
3FL12812AAAAWBZZA Ed2
March 2007
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-25
RRC Measurements on RACH
sib11IntraFreqMeasurementNbrOfCellOnRACH (RRCSysInfoMeas)
sib11IntraFreqMeasurementFilterCoeffOnRACH (RRCSysInfoMeas)
SIB 11
Reported Measurements on RACH
RACH
CPICH Ec/No
or
CPICH RSCP
or
Path Loss
Neighboring Cells
measQuantity (static)
4-26
3FL12812AAAAWBZZA Ed2
March 2007
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-26
Fast Measurements at Call Establishment
SI broadcast
P-CCPCH
UE
NodeB
RRC Connection Request
RRC Connection Setup
Measurement Report
Measurement Control
isSib11MeasReportingAllowed (FDDCell)
sib11MeasReportingUsHoConfId (FDDCell)
4-27
3FL12812AAAAWBZZA Ed2
March 2007
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-27
Student notes
4-28
Intra-Frequency Event Triggered
Measurement Reporting
4-29
3FL12812AAAAWBZZA Ed2
4-29
March 2007
Events Description
Event Id
Meas Id
triggering
quantity
triggering cells
semantic & usage
Soft Handover Management
1A
Measid1
CPICH Ec/No any of Monitored Set
A monitored P-CPICH enters reporting range.
RL addition based on relative criteria when AS not full.
1B
Measid1
CPICH Ec/No
An active P-CPICH leaves reporting range.
RL deletion based on relative criteria.
1C
Measid1
CPICH Ec/No any of Monitored Set
A non-active P-CPICH becomes better than an active P-CPICH.
RL addition based on relative criteria when AS full.
1D
Measid1
CPICH Ec/No
Change of best cell.
Primary cell change.
1E
Measid1
CPICH Ec/No any of Monitored Set
A P-CPICH becomes better than an absolute threshold.
RL addition based on absolute criteria when AS not full.
1F
Measid1
CPICH Ec/No
A P-CPICH becomes worse than an absolute threshold.
RL deletion based on absolute criteria.
any of Active Set
any of Active Set
any of Active Set
Hard Handover Management
2D
Measid11 CPICH Ec/No
best Active Set cell
2D
Measid12 CPICH RSCP
best Active Set cell
2F
Measid11 CPICH Ec/No
best Active Set cell
2F
Measid12 CPICH RSCP
best Active Set cell
Estimated quantity of current carrier is worse than threshold.
4-30
Estimated quantity of current carrier is better than threshold.
3FL12812AAAAWBZZA Ed2
March 2007
3GPP specifications define 2 RRC measurements reporting modes; periodical
reporting and event-triggered reporting. For the event triggered reporting mode, RRC
standards 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-30
Event1A
Event1A
CPICH_EC/No
Event1A
Event 1A
amountRep1A
(FullEventRepCritShoMgtEvent1A)
Best Cell
New Cell
entering reporting range
leaving reporting range
maxNbReportedCells1A
(FullEventRepCritShoMgtEvent1A)
timeToTrigger1A
(FullEventRepCritShoMgtEvent1A)
repInterval1A
(FullEventRepCritShoMgtEvent1A)
N

10 ⋅ LogM New + CIONew ≥ W ⋅ 10 ⋅ Log  ∑ M i  + (1 − W ) ⋅ 10 ⋅ LogM Best − (R1a m H1a / 2)
 i =1 
A
cpichEcNoReportingRange1A (FullEventHOConfShoMgt)
cellIndivOffset (UMTSFddNeighbouringCell)
4-31
hysteresis (static)
wParam (static)
3FL12812AAAAWBZZA Ed2
March 2007
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.
Note
The above drawing shows an example assuming that CIO is set to 0 dB.
4-31
Event1B
Event1B
Event1B
CPICH_EC/No
Event1B
Event 1B
amountRep1B
(FullEventRepCritShoMgtEvent1B)
Best Cell
leaving reporting range
entering reporting range
Old Cell
timeToTrigger1B
(FullEventRepCritShoMgtEvent1B)
maxNbReportedCells1B
(FullEventRepCritShoMgtEvent1B)
repInterval1B
(FullEventRepCritShoMgtEvent1B)
N

10 ⋅ LogMOld + CIOOld ≤ W ⋅ 10 ⋅ Log  ∑ M i  + (1 − W ) ⋅ 10 ⋅ LogM Best − (R1b ± H1b / 2)
 i =1 
A
cpichEcNoReportingRange1B (FullEventHOConfShoMgt)
cellIndivOffset (UMTSFddNeighbouringCell)
4-32
hysteresis (static)
wParam (static)
3FL12812AAAAWBZZA Ed2
March 2007
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.
The variables in the formula are defined as follows:
• 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.
Note
The 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-32
Event1C
Event1C
Event1C
CPICH_EC/No
Event1C
Event 1C
amountRep1C
(FullEventRepCritShoMgtEvent1C)
AS Cell
New Cell
entering reporting range
maxNbReportedCells1C
InAS Cell (FullEventRepCritShoMgtEvent1C)
leaving reporting range
timeToTrigger1C
(FullEventRepCritShoMgtEvent1C)
repInterval1C
(FullEventRepCritShoMgtEvent1C)
10 ⋅ LogM New + CIONew ≥ 10 ⋅ LogMInAS + CIOInAS ± H1c / 2)
hysteresis1C (FullEventRepCritShoMgtEvent1C)
cellIndivOffset (UMTSFddNeighbouringCell)
4-33
3FL12812AAAAWBZZA Ed2
March 2007
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.
The variables in the formula are defined as follows:
• 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-33
CPICH_EC/No
Event1D
Event 1D
entering reporting range
NotBest Cell
Best Cell
leaving reporting range
maxNbReportedCells1D
(FullEventRepCritShoMgtEvent1D)
useCIOfor1D
(FullEventRepCritShoMgtEvent1D)
timeToTrigger1D
(FullEventRepCritShoMgtEvent1D)
10 ⋅ LogM NotBest + CIONotBest ≥ 10 ⋅ LogM Best + CIOBest ± H1d / 2)
hysteresis1D (FullEventRepCritShoMgtEvent1D)
cellIndivOffset (UMTSFddNeighbouringCell)
4-34
3FL12812AAAAWBZZA Ed2
March 2007
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.
The variables in the formula are defined as follows:
• 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.
Note
In 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-34
Event1E
Event 1E
CPICH_EC/No
AS Cell
New Cell
entering reporting range
absolute threshold
leaving reporting range
maxNbReportedCells1E
(FullEventRepCritShoMgtEvent1E)
timeToTrigger1E (FullEventRepCritShoMgtEvent1E)
10 ⋅ LogM New + CIONew ≥ T1e ± H1e / 2
hysteresis (static)
cpichEcNoThresholdUsedFreq1E (FullEventHOConfShoMgt)
cellIndivOffset (UMTSFddNeighbouringCell)
4-35
3FL12812AAAAWBZZA Ed2
March 2007
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.
The variables in the formula are defined as follows:
• 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-35
Event1F
Event 1F
CPICH_EC/No
AS Cell
leaving reporting range
absolute threshold
entering reporting range
Old Cell
maxNbReportedCells1F
(FullEventRepCritShoMgtEvent1F)
timeToTrigger1F (FullEventRepCritShoMgtEvent1F)
10 ⋅ LogMOld + CIOOld ≤ T1f m H1f / 2
hysteresis (static)
cpichEcNoThresholdUsedFreq1F (FullEventHOConfShoMgt)
cellIndivOffset (UMTSFddNeighbouringCell)
4-36
3FL12812AAAAWBZZA Ed2
March 2007
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.
The variables in the formula are defined as follows:
• 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-36
Event 2D/2F
Alarm Measurement Criteria
NOT HIT
HIT
timerAlarmHoEvent
(FullEventHOConfHhoMgt)
Event2D
Event2F
CPICH_EC/No
CPICH_RSCP
Event2D
Alarm Measurement Timer
entering 2F reporting range
2F absolute threshold
leaving 2F reporting range
leaving 2D reporting range
2D absolute threshold
entering 2D reporting range
Best Cell
QUsed ≤ TUsed 2d m H 2d / 2
QUsed ≤ TUsed 2f ± H 2f / 2
cpichEcNoThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)
cpichRscpThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)
cpichEcNoThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)
cpichRscpThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)
4-37
hysteresis (static)
timeToTrigger2D (FullEventRepCritHhoMgtEvent2D)
maxNbReportedCells2D (FullEventRepCritHhoMgtEvent2D)
timeToTrigger2F (FullEventRepCritHhoMgtEvent2F)
maxNbReportedCells2F (FullEventRepCritHhoMgtEvent2F)
3FL12812AAAAWBZZA Ed2
March 2007
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.
The variables in the formula are defined as follows:
• 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-37
Student notes
4-38
In-Band Measurement Procedures
4-39
3FL12812AAAAWBZZA Ed2
4-39
March 2007
RACH & DCH FP Measurements
Header CRC
FT
CFN
Spare
TFI of 1st DCH
Header CRC
CFN
Spare
FT
Spare
TFI
1st
Propagation Delay
Last Transport Block of 1st DCH
1st
Pad.
CRCI
Pad.
Transport Block of last DCH
1st Transport Block of last DCH
CRCI
Pad.
Last Transport Block of 1st DCH
Pad.
Last RACH Transport Block
Last RACH Transport Block
Transport Block of 1st DCH
1st Transport Block of 1st DCH
1st RACH Transport Block
1st RACH Transport Block
TFI of last DCH
Pad.
Pad.
Last Transport Block of last DCH
Spare extension
Payload Checksum (optional)
Last Transport Block of last DCH
Payload Checksum (optional)
Pad.
QE
CRCI
CRCI
Pad.
Spare extension
Payload Checksum (optional)
Payload Checksum (optional)
4-40
3FL12812AAAAWBZZA Ed2
March 2007
The propagation delay is reported in the RACH data frames transferred from the
NodeB 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-40
Missing Measurements
Management
4-41
3FL12812AAAAWBZZA Ed2
4-41
March 2007
RRC Missing Measurements
Measurement Report
Measurement Report
RRC Measurements are missing
Use modified version of old RRC measurement instead
Measurement Report
MN = MN-1 - penalty
RRC Measurements are missing
missedEcNoMeasurementPenalty
(MissingMeasurement)
missedRSCPMeasurementPenalty
(MissingMeasurement)
Measurement Report
RRC Measurements are missing
maxAllowedNumber
(MissingMeasurement)
Measurement Report
RRC Measurements are missing
RRC measurements set to minimal value
4-42
3FL12812AAAAWBZZA Ed2
March 2007
In the RRC protocol, when measurements are missing in the MEASUREMENT
REPORT sent by the UE to the SRNC, a maximum of maxAllowedNumber
consecutive 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-42
CM Measurements Validity
Measurement Report
GSM Measurements are missing
Use old GSM measurement instead
Measurement Report
GSM Measurements are missing
Use old GSM measurement instead
gsmRssiMeasValidityPeriod (RRCMeasurement)
Measurement Report
GSM Measurements are missing
old GSM measurement is removed
Measurement Report
inter-Frequency Measurements are missing
Use old inter-frequency measurement instead
interFreqMeasValidityPeriod (InterFreqMeasConf)
Measurement Report
inter-Frequency Measurements are missing
old inter-frequency measurement is removed
4-43
3FL12812AAAAWBZZA Ed2
March 2007
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-43
Student notes
4-44
Compressed Mode
Section 5
3FL12812AAAAWBZZA Ed2
5-1
March 2007
Objectives
After this section, you will be able to
> Describe Compressed Mode Principles
> Describe CM implementation and configuration
> Describe CM measurement process and associated
parameters
> Describe CM impacts on other UTRAN features
5-2
3FL12812AAAAWBZZA Ed2
5-2
March 2007
Contents
> Compressed Mode Principles
> Compressed Mode Implementation
> FDD Inter-Frequency Measurements
> GSM Inter-System Measurements
> Measurement with Compressed Mode
> Impacts of Compressed Mode
5-3
3FL12812AAAAWBZZA Ed2
5-3
March 2007
Student notes
5-4
Compressed Mode Principles
5-5
3FL12812AAAAWBZZA Ed2
5-5
March 2007
Compressed Mode Scope & Methods
power
Single-Frame Mode
frame N-1
idle
frame N+1
time
TGL
Double-Frame Mode
power
frame boundary
frame N-1
idle
idle
frame N+2
time
TGL
Inter-frequency measurements
Inter-RAT measurements
Transmission Gap Length = 3, 4, 7, 10, 14 TS
dlCModeMethod (CmodePatternSeqInfo)
5-6
ulCModeMethod (CmodePatternSeqInfo)
3FL12812AAAAWBZZA Ed2
March 2007
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-6
Needs for Compressed Mode
isCmodeAllowed (RadioAccessService)
GSM
UE
it y
abil
Ca p
UMTS
UMTS
GSM450Present (RadioAccessService)
GSM480Present (RadioAccessService)
GSM850Present (RadioAccessService)
GSM900PPresent (RadioAccessService)
GSM900EPresent (RadioAccessService)
GSM1800Present (RadioAccessService)
GSM1900Present (RadioAccessService)
• Dual receiver UE?
• Mono Receiver UE?
• GSM compatible UE?
5-7
3FL12812AAAAWBZZA Ed2
March 2007
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-7
Student notes
5-8
Compressed Mode Implementation
5-9
3FL12812AAAAWBZZA Ed2
5-9
March 2007
Alternate Scrambling Code Method
Compressed Time Slots
SF/2
Normal Time Slots
SF
5-10
3FL12812AAAAWBZZA Ed2
March 2007
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-10
Compressed Mode Pattern Sequences
tgcfnOffset (CModePatternSeqInfo)
tgprc (CModePatternSeqInfo)
#TGCFN
#1
#2
#TGPRC
sub-pattern 1 sub-pattern 2
sub-pattern 1 sub-pattern 2 sub-pattern 1 sub-pattern 2
Gap1
Gap2
Gap1
Gap2
tgl1
tgl2
tgl1
tgl2
tgsn
tgd
tgd
tgpl1
5-11
tgpl2
3FL12812AAAAWBZZA Ed2
March 2007
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-11
Pattern Sequence Configuration
A pattern sequence is defined for each type of measurement
GSM RSSI measurement
CmodePatternSeqInfo [0]
RadioAccessService
isPatternAllowed = True
Tgmp = 2
TgcfnOffset = 0
Tgd = 0
Tgl1 = 14
Tgl2 = 0
CmodePatternSeqInfo [1]
Tgpl1 = 6
isPatternAllowed = True
Tgpl2 = N/A
Tgmp = 3
Tgprc = 8
TgcfnOffset = 48
Tgsn = 8
Tgd = 0
Tgl1 = 14
Tgl2 = 0
Tgpl1 = 6
CmodePatternSeqInfo
Tgpl2 = N/A
isPatternAllowed = True
Tgprc = 78
Tgmp = 1
Tgsn = 8
TgcfnOffset = 0
nIdentifyAbort = 26
Tgd = 0
Tgl1 = 10
Tgl2 = 0
Tgpl1 = 6
Tgpl2 = N/A
Tgprc = 50
Tgsn = 10
BSIC identification
FDD measurements
5-12
[2]
3FL12812AAAAWBZZA Ed2
March 2007
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-12
FDD Inter-Frequency
Measurements
5-13
3FL12812AAAAWBZZA Ed2
5-13
March 2007
FDD Inter-Frequency CM Pattern
50 Patterns (3000 ms)
CFN + 0
Gap = 10 Time Slots
10 Time Slots
70 Time Slots
6 Frames (60 ms)
5-14
3FL12812AAAAWBZZA Ed2
March 2007
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-14
GSM Inter-System Measurements
5-15
3FL12812AAAAWBZZA Ed2
5-15
March 2007
GSM Measurement Process
Measurement Control (BSIC, BCCH, ARFCN)
Measurement Control (CM Pattern, starting CFN)
RSSI Measurement
Measurement Report
8 strongest cells
Periodical
isNIdentifyAbort (static)
Measurement
nIdentifyAbort (CmodePatternSeqInfo)
Reports
BSIC Identification
identified BSICs
BSIC Confirmation
5-16
Measurement Report
3FL12812AAAAWBZZA Ed2
March 2007
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-16
GSM Measurements CM Pattern
8 Patterns (480 ms)
78 Patterns (4680 ms)
RSSI
BSIC
CFN + 48
CFN + 0
8 Time Slots
68Time Slots
Gap = 14 Time Slots
6 Frames (60 ms)
5-17
3FL12812AAAAWBZZA Ed2
March 2007
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-17
Student notes
5-18
Measurement with Compressed
Mode
5-19
3FL12812AAAAWBZZA Ed2
5-19
March 2007
CM Activation with Periodic Reporting
IF
P-CPICH_EcNo(primary) < cpichEcNoThreshold
OR
P-CPICH_RSCP(primary) < cpichRscpThreshold
THEN
Alarm Measurement Counter is incremented by stepUp
IF
Alarm Measurement Counter > counter
THEN
Alarm Measurements are requested from UE
ELSE
Alarm Measurement Counter = Max ( 0; Alarm Measurement Counter – stepDown)
cpichEcNoThreshold (AlarmMeasActivation)
cpichRscpThreshold (AlarmMeasActivation)
counter (AlarmMeasActivation)
stepUp (AlarmMeasActivation)
stepDown (AlarmMeasActivation)
Max Alarm Measurement Counter = Counter + numberOfStepDownToComeBackToThreshold (static) x Step Down
3FL12812AAAAWBZZA Ed2
5-20
March 2007
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-20
CM Activation with Full Event Triggered
Alarm Measurement Criteria
NOT HIT
HIT
Alarm Measurements Requested from UE
Event2D
Event2F
CPICH_EC/No
CPICH_RSCP
Event2D
Alarm Measurement Timer
entering 2F reporting range
2F absolute threshold
leaving 2F reporting range
leaving 2D reporting range
2D absolute threshold
entering 2D reporting range
5-21
Time to Trigger 2D
Time to Trigger 2F
Time to Trigger 2D
Best Cell
3FL12812AAAAWBZZA Ed2
March 2007
In case of Full Event Triggered RRC measurement reporting, the events 2D and 2F
are used to validate/invalidate alarm measurements conditions.
The variables in the formula are defined as follows:
• 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-21
Compressed Mode Strategy
isGsmCModeActivationAllowed (DlUserService)
isInterFreqCModeActivationAllowed (DlUserService)
fastAlarmHHOStrategy (UsHoConf)
Alarm Measurements Required
YES
HHO Strategy = Inter-System
Inter-System CM enabled
YES
AND
Inter-System neighbors configured
NO
YES
NO
Inter-Frequency CM enabled
AND
Inter-Frequency neighbors configured
NO
Inter-System CM activated
Inter-Frequency CM activated
Inter-Frequency CM enabled
AND
Inter-Frequency neighbors configured YES
NO
5-22
Inter-System CM enabled
AND
YES Inter-System neighbors configured
CM not activated
3FL12812AAAAWBZZA Ed2
NO
March 2007
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-22
CM Deactivation / Reactivation
Inter-System or
inter-Frequency
measurements
are required
CM activation time
Measurement criteria
is still valid
CM period
CFN
If required according to
alarm measurements
Duration of pattern sequence
cModeDeltaCfn (CModeConfiguration)
Inter-System
gsmCModeReactivationTimer (CModeConfiguration)
Inter-Freq
fddCModeReactivationTimer (CModeConfiguration)
or
cModeShoDeltaCfn (CModeConfiguration)
if
5-23
isShoCModeActiveAllowed = Yes
(CModeConfiguration)
3FL12812AAAAWBZZA Ed2
March 2007
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 Control
message, based on UE needs, as indicated in the mobile Classmark
• if compressed mode needs to be reactivated, a Compressed Mode Command
message 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-23
Measurements Reports
rrcIntraFreqMeasurementReportingPeriod
(RRC Measurement)
Measurement Report
rrcGsmMeasurementFilterCoeff
(RRC Measurement)
interFreqFilterCoeff
(InterFreqMeasConf)
Measurement Report
Measurement
ID
Measurement
Results
Measurement
Reporting
Quantity
NodeB
Best Monitored cells
• GSM Carrier RSSI
• CPICH Ec/No
• Observed time difference to GSMCell
• CPICH RSCP
maxCellsRepType (static)
• Verified BSIC
5-24
3FL12812AAAAWBZZA Ed2
March 2007
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-24
Impacts of Compressed Mode
5-25
3FL12812AAAAWBZZA Ed2
5-25
March 2007
Impacts on Frame Format
Downlink
• Type A
dlFrameType (CmodePatternSeqInfo)
• Type B
(a) Radio frame structure type A
Slot # (Nfirst - 1)
T TF
Data1 P CI
C
Data2
transmission gap
Slot # (Nlast + 1)
T TF
PL Data1 P CI
C
PL
Data2
PL
(b) Radio frame structure type B
Slot # (Nfirst - 1)
T TF
Data1 P CI
C
5-26
Data2
transmission gap
PL
Slot # (Nlast + 1)
T TF
PL Data1 P CI
C
T
P
C
3FL12812AAAAWBZZA Ed2
Data2
PL
March 2007
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-26
Impacts on Outer Loop Power Control
∆SIR
SIR target
∆SIR = ∆SIRcompression + ∆SIRcoding
3dB -> Compressed radio frame
0 -> Other radio frame
CmodePCDeltaSir1
(DlUserService)
CmodePCDeltaSirAfter1
(DlUserService)
Transmission
Gap1
Compressed
frames
5-27
CmodePCDeltaSir2
(DlUserService)
CmodePCDeltaSirAfter2
(DlUserService)
∆ pilot
∆ pilot
Transmission
Gap2
Compressed
frames
3FL12812AAAAWBZZA Ed2
March 2007
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, CmodePCDeltaSIRafter1
and 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-27
Impacts on Inner Loop Power Control
Initial Transmission Power
UL
ITP = 0
DPCCH
ITP = 0 or 1
RPP = 0 or 1
Compressed frames
Compressed
frames
CmodePCItp
(DlUserService)
∆ pilot
Transmission
Gap
Recovery Period Power Control (RPP = 0 or 1)
ITP = 1
CmodePCRtp
(DlUserService)
DL
Offset δ last
Transmission
Gap
ITP = 0
RPP = 1
5-28
Compressed
frames
Compressed frames
Compressed mode procedure
3FL12812AAAAWBZZA Ed2
March 2007
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-28
Student notes
5-29
Student notes
5-30
Mobility in Idle Mode
Section 6
3FL12812AAAAWBZZA Ed2
6-1
March 2007
Objectives
After this section, you will be able to
> 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-2
3FL12812AAAAWBZZA Ed2
6-2
March 2007
Contents
> Network Selection
> Cell Selection
> Cell Reselection
> Cell Status and Reservation
> Location Registration
> Mobility in CELL_FACH
6-3
3FL12812AAAAWBZZA Ed2
6-3
March 2007
Student notes
6-4
Network Selection
6-5
3FL12812AAAAWBZZA Ed2
6-5
March 2007
PLMN Selection
/ PMIB
CC
PCH
mobileCountryCode (Operator)
mobileNetworkCode (Operator)
mobileCountryCode (RNC)
mobileNetworkCode (RNC)
mobileCountryCode (CsCoreNetworkAccess)
mobileNetworkCode (CsCoreNetworkAccess)
mobileCountryCode (PsCoreNetworkAccess)
mobileNetworkCode (PsCoreNetworkAccess)
MCC
MNC
Preferred PLMN List
6-6
MSIN
mobileCountryCode (FDDCell)
mobileNetworkCode (FDDCell)
Forbidden PLMN List
3FL12812AAAAWBZZA Ed2
March 2007
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-6
Cell Selection
6-7
3FL12812AAAAWBZZA Ed2
6-7
March 2007
Cell Selection Criteria
P-C
H
PIC
C
FDD
Squal > 0
CPICH_Ec/No > qQualMin
AND
Cell
qQualMin (CellSelectionInfo)
qRxLevMin (CellSelectionInfo)
Srxlev > 0
CPICH_RSCP > qRxLevMin + Pcompensation
S Criteria
6-8
3FL12812AAAAWBZZA Ed2
March 2007
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-8
UE Power Compensation
RNC
Srxlev > 0
CPICH_RSCP > qRxLevMin + Pcompensation
Pcompensation
=
max (sibMaxAllowedUlTxPowerOnRach – P_MAX, 0)
6-9
UE Class
P_MAX
1
+33 dBm
2
+27 dBm
3
+24 dBm
4
+21 dBm
RadioAccessService
NodeB
DedicatedConf
FDDCell
PowerConfClass
CellSelectionInfo
qRxLevMin (CellSelectionInfo)
sibMaxAllowedTxPowerOnRach (PowerConfClass)
3FL12812AAAAWBZZA Ed2
March 2007
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-9
Student notes
6-10
Cell Reselection
6-11
3FL12812AAAAWBZZA Ed2
6-11
March 2007
Idle Mode Neighboring List
P11 /
SIB
CCP
CH
C
ving
Ser
ell
FDDCell Neighboring List
• UMTSFddNeighbouringCell List
• GsmNeighbouringCell List
SIB11 Neighboring List
sib11AndDchNeighbouringFddCellAlgo (FDDCell)
• 16 intra-frequency FDDCells
• 16 inter-frequency FDDCells
• 16 GSMCells
6-12
sib11OrDchUsage (UMTSFddNeighbouringCell)
3FL12812AAAAWBZZA Ed2
March 2007
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-12
Cell Reselection Triggering Criteria
SIB11 / P-CCPCH
Squal = CPICH_Ec/No - qQualMin (CellSelectionInfo)
sIntraSearch (CellSelectionInfo)
sInterSearch (CellSelectionInfo)
Measurement
on same
frequency
6-13
Measurement
on other
frequencies
sSeachRatGsm (CellSelectionInfo)
Measurement
on other RAT
≤ Threshold
If
CPICH_Ec/No – qQualMin
Then
associated measurements are performed
3FL12812AAAAWBZZA Ed2
March 2007
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-13
Cell Reselection Process
Eligible Cells
First Ranking
(CPICH_RSCP & RxLev)
FDDCell
CPICH_Ec/No
Best cell is a ..?
CPICH_RSCP
qualMeas = ..?
Best GSMCell
is reselected
Best FDDCell
after First Ranking
is reselected
Second Ranking
(CPICH_Ec/No)
Best FDDCell
after Second Ranking
is reselected
6-14
GSMCell
3FL12812AAAAWBZZA Ed2
qualMeas (Static)
March 2007
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-14
Cells Eligibility Criteria
CPICH_Ec/No > qQualMin (UMTSFddNeighbouringCell)
AND
Squal > 0
CPICH_RSCP > qRxLevMin + Pcompensation
(UMTSFddNeighbouringCell)
Srxlev > 0
UMTSFddNeighbouringCell
Max(MaxAllowedUlTxPower - P_max, 0)
(UMTSFddNeighbouringCell)
GSMCell
Max(MaxAllowedUlTxPower - P_max, 0)
(GSMCell)
Srxlev > 0
QRxLeavMeas > qRxLevMin (GSMCell) + Pcompensation
6-15
3FL12812AAAAWBZZA Ed2
March 2007
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-15
First Ranking
R criterion for Serving Cell
Rs = CPICH_RSCP + qHyst1 (CellSelectionInfo)
FDDCell
R criterion for FDD Neighboring Cell
Rn = CPICH_RSCP – qOffset1sn (UMTSFddNeighbouringCell)
UMTSFddNeighbouringCell
GSMCell
UE List
Rank
Cell ID
1
2
3
…
Cell B
Cell A
Cell C
…
Rn = RxLev – qOffset1sn (GSMCell)
R criterion for GSM Neighboring Cell
6-16
3FL12812AAAAWBZZA Ed2
March 2007
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-16
Second Ranking
R criterion for Serving Cell
R criterion for Neighboring Cell
Rs = CPICH_Ec/No + qHyst2 (CellSelectionInfo)
Rn = CPICH_Ec/no – qOffset2sn (UMTSFddNeighbouringCell)
UMTSFddNeighbouringCell
FDDCell
UE List
Rank
Cell ID
1
2
3
…
Cell B
Cell A
Cell C
…
3FL12812AAAAWBZZA Ed2
6-17
March 2007
If after a first ranking selection the best ranked cell is a FDD Cell and if the qualMeas
static 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-17
Cell Reselection Process Summary
FDDCell
D
FDDCell
If CPCICH_Ec/No
C
1
2
3
…
6-18
GSMCell
B
FDDCell
UE List
Rank Cell ID
If CPCICH_RSCP
After 2nd
ranking
Cell D (FDD cell)
Cell A (FDD cell)
Cell C (FDD cell)
…
UE List
UE List
A
Rank Cell ID
1
2
3
After 1st …
ranking
Cell A (FDD cell)
Cell B (GSM cell)
Cell C (FDD cell)
…
Rank Cell ID
1
2
3
…
After 1st
ranking
Cell B (GSM cell)
Cell A (FDD cell)
Cell C (FDD cell)
…
If
New Cell better ranked than Serving Cell during tReselection (CellSelectionInfo)
Then
New Cell is reselected
3FL12812AAAAWBZZA Ed2
March 2007
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-18
Cell Status and Reservation
6-19
3FL12812AAAAWBZZA Ed2
6-19
March 2007
Cell Status and Reservation Process
barredOrNot (FDDCell) = ..?
barred
notBarred
intraFreqCellReselectInd (FDDCell) = ..?
allowed
try to select
another intra
frequency cell
notAllowed
try to select
another inter
frequency cell
cellReservedForOperatorUse (FDDCell) = ..?
other UE
reserved
only UE with
Access Classes 11 / 15
are accepted
if no other cell
cellReservationExtension (FDDCell) = ..?
wait tBarred (FDDCell)
try to reselect
same cell
6-20
notReserved
reserved
wait Max(tBarred)
(barredS1280)
3FL12812AAAAWBZZA Ed2
notReserved
all UE Access Classes
are accepted
March 2007
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-20
Location Registration
6-21
3FL12812AAAAWBZZA Ed2
6-21
March 2007
LAC/RAC/SAC
RNC
locationAreaCode (FDDCell)
routingAreaCode (FDDCell)
serviceAreaCode (FDDCell)
RAC 2
LAC 1
LAC 2
RAC 1
SAC 2
SAC 1
6-22
3FL12812AAAAWBZZA Ed2
March 2007
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-22
Mobility in CELL_FACH
6-23
3FL12812AAAAWBZZA Ed2
6-23
March 2007
Cell Reselection on CELL_FACH
UE
RRC
RRC
RRC
RACH / Cell Update
RNC
Core Network
RRC
UE RRC Connection Request message
contains the establishment cause
RRC
FACH / Cell Update Confirm (RNTI)
RACH / UTRAN Mobility Information Confirm
RRC
if UE enters a new Location or Routing Area
GMM
GMM
6-24
GMM
RACH / Routing Area Update Request
GMM
FACH / Routing Area Update Accept
3FL12812AAAAWBZZA Ed2
March 2007
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-24
Student notes
6-25
Student notes
6-26
Call Admission
Section 7
3FL12812AAAAWBZZA Ed2
7-1
March 2007
Objectives
After this section, you will be able to
> 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-2
3FL12812AAAAWBZZA Ed2
7-2
March 2007
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-3
3FL12812AAAAWBZZA Ed2
7-3
March 2007
Student notes
7-4
Paging
7-5
3FL12812AAAAWBZZA Ed2
7-5
March 2007
Paging DRX Cycle
Slot #0
Slot #1
Slot #0
Slot #1
Slot #0
Slot #1
Slot #0
Slot #1
Slot #0
Slot #1
Slot #0
Slot #1
Pa
Pa
g
NodeB
ing
gi
n
fo r
gf
or
PICH
PICH
Pa
c
Ci
r cu
it c
Slot #14
Slot #14
Slot #14
Slot #14
Slot #14
Slot #14
ke
DRX
tc
FDDCell
all
csDrxCynLngCoef
a ll
psDrxCynLngCoef
nbOfPagingRepetition (Static)
7-6
UE
3FL12812AAAAWBZZA Ed2
March 2007
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-6
Access Preambles & Acknowledgment
7-7
3FL12812AAAAWBZZA Ed2
7-7
March 2007
Preambles Transmission
detection
RACH
Interference
level
preambleThreshold (RACH)
3
Preamble
detection
rachsubChannel (RACH)
2
AS 0 AS 1 AS 2
AS15
Ack.
prachScramblingCode (RACH)
PRACH
1
4
preambleSignature (RACH)
Preamble Part
Wait for Ack ...
6
Message part
5
Preamble
7-8
aichTransmissionTiming (RACH)
3FL12812AAAAWBZZA Ed2
March 2007
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 has
detected 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 the
prachScramblingCode parameter of the RACH object.
7-8
Acknowledgement Transmission
aichTransmissionTiming (RACH) = 0
3 TS
AICH
Downlink
AICH
Preamble
PRACH
Preamble
Uplink
PRACH
3 AS
3 AS
Transmission of AICH may only start at the beginning of a DL AS
Transmission of UL RACH preambles and RACH message parts may only start at the beginning of an UL AS
aichTransmissionTiming (RACH) = 1
5 TS
AICH
Downlink
AICH
Preamble
PRACH
Preamble
Uplink
PRACH
4 AS
4 AS
7-9
3FL12812AAAAWBZZA Ed2
March 2007
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-9
Preambles Retransmission Parameters
preambleRetransMax (RACH)
PREAMBLE #2
Access Cycle #1
PREAMBLE #1
PREAMBLE #N
Mmax (RachTxParameters)
PREAMBLE #1
NB01max (RachTxParameters)
PREAMBLE #N
7-10
3FL12812AAAAWBZZA Ed2
Access Cycle #2
NB01min (RachTxParameters)
March 2007
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-10
RRC Connection Establishment
7-11
3FL12812AAAAWBZZA Ed2
7-11
March 2007
RRC Connection Setup
NodeB
RR
n
C Co
R
tion
nec
se)
Ca u
est (
u
q
e
RNC
RB = ???
RadioAccessService
DlRbSetConf
DlUserService
ServiceInit
UlUserService
UlRbSetConf
UserServices
7-12
3FL12812AAAAWBZZA Ed2
March 2007
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-12
UL Interference CAC on RACH
Eb/No
required
Call is accepted
Call is rejected
Interference level
Yes
No
UL RTWP
Received
Power
RTWP < Maximum UL Interference Level
RNC
CH
P-RA
NBAP Common measurement report
(RTWP)
cacConfId (FDDCell)
maxUlInterferenceLevel (CacConfClass)
7-13
3FL12812AAAAWBZZA Ed2
March 2007
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-13
RRC Speech Redirection
RNC
RRC Connection Request
UL Interference CAC Rejection
RNC Overload
SRB CAC Rejection
IF
RRC Establishment Cause = MO Conversational
OR
RRC Establishment Cause = Emergency
AND
isDlCemLoadCalculationEnabled = TRUE
AND
2G neighbor configured
THEN
include Redirection IE in RRC Connection Rejection message
RRC Connection Rejected (cause)
Redirection IE (Inter-RAT info = GSM)
isDlCemLoadCalculationEnabled (RadioAccessService)
7-14
3FL12812AAAAWBZZA Ed2
March 2007
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-14
RRC Connection Rejection
RNC
RRC Connection Request
RTWP > Maximum UL Interference Level
RRC Connection Rejected (cause)
RNC Overload
waitTimeOnRrcConnectionRejection (ServiceInit)
timeReject (RadioAccessService)
waitTime3Gto2GRedirectFailure (FDDCell)
RRC Connection Request
Redirection Failure
7-15
3FL12812AAAAWBZZA Ed2
March 2007
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-15
FACH Power Adjustment
Maximum FACHpower
P-CPICH
all other
FACH
messages
first RRC
Connection
Setup
second
RRC
Connection
Setup
third RRC
Connection
Setup
Feature Parameters (CallAccessPerformanceConf)
absoluteMaxFachPower
Feature Activation
isFachPowerAdjustmentEnabled (CallAccessPerformanceConf)
initialFachPowerAdjustment
fachTransmitPowerLevelStep
isFachPowerAdjustmentActivated (FDDCell)
fachPowerAdjustmentCpichEcNoThreshold
fachPowerAdjustmentCpichRscpThreshold
7-16
3FL12812AAAAWBZZA Ed2
March 2007
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-16
RRC Connection Setup Repetition
UE
RNC-IN
RNC-CN
RRC Connection Request (TM) (CPICH Ec/No)
RRC Connection Setup (UM) RRC Connection Setup
t351 / n351 Based Repetition
t351 (CallAccessPerformanceConf)
t351
n351 (CallAccessPerformanceConf)
RRC Connection Setup (UM) RRC Connection Setup
t351
RRC Connection Setup (UM) RRC Connection Setup
Quick Repeat
isQuickPepeatActivated (FDDCell)
isQuickPepeatAllowed (CallAccessPerformanceConf)
numberOfQuickRepeat (CallAccessPerformanceConf)
RRC Connection Setup (UM) RRC Connection Setup
deltaCpichEcNoUsedQuickRepeat (CallAccessPerformanceConf)
deltaCpichRscpUsedQuickRepeat (CallAccessPerformanceConf)
RRC Connection Setup Complete (AM)
7-17
3FL12812AAAAWBZZA Ed2
March 2007
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 PCPICH 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-17
Student notes
7-18
RAB Matching Principles
7-19
3FL12812AAAAWBZZA Ed2
7-19
March 2007
RAB Request vs. UserServices Config.
ice R
Serv
est
equ
RNC
Core Network
Service Request
RAB Assignment Request
RB = ???
RadioAccessService
DlRbSetConf
DlUserService
ServiceInit
UlUserService
UlRbSetConf
UserServices
7-20
3FL12812AAAAWBZZA Ed2
March 2007
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-20
RAB Matching Main Steps
UE Capability
Requested RAB
Establishment Cause
Candidate RBSet Selection
RAB to RBset Matching
UE Capability Check
TrCH Type Selection
IRM Selection (DL)
RB Adaptation Initialization (UL)
RBSet List Construction
UserServices Matching
RBset to UserServices Matching
UE Capability Check
Reference UserServices
7-21
Target UserServices
3FL12812AAAAWBZZA Ed2
March 2007
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-21
Student notes
7-22
RAB to RBset Matching
7-23
3FL12812AAAAWBZZA Ed2
7-23
March 2007
Candidate RBset Selection
Core Network
RNC
RAB Assignment Request
• Maximum Bit Rate
• Guaranteed Bit Rate
• UMTS Traffic Class
• A/R Priority Level
• ...
RadioAccessService
DlRbSetConf
UlRbSetConf
enabledForRABMatching (DlRbSetConf)
enabledForRABMatching (UlRbSetConf)
Candidate RBset Selection
DL Candidate RBset
UL Candidate RBset
DL Reference RB
7-24
UL Reference RB
3FL12812AAAAWBZZA Ed2
March 2007
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-24
Candidate RBset Selection Algorithm
Candidate RBset Selection
RAB Assignment Request
• Maximum Bit Rate
• Guaranteed Bit Rate
• UMTS Traffic Class
• A/R Priority Level
• ...
Traffic Class
Bit Rate (RbSetConf)
=
=
Conversational Maximum Bit Rate (RAB Assignment Request)
DL Candidate RbSet
Traffic Class
Bit Rate (RbSetConf)
≥
=
Streaming
Guaranteed Bit Rate (RAB Assignment Request)
UL Candidate RbSet
Traffic Class
Bit Rate (RbSetConf)
≤
=
Interactive/Background Maximum Bit Rate (RAB Assignment Request)
Example
• CS MaxBitRate = 12.2k
• PS MaxBitRate = 384k
• CS Speech + PS I/B
• A/R Priority Level = 2
• ...
7-25
Candidate RBset Selection
UE Capability Check
DL Candidate RbSet
UL Candidate RbSet
• PS 64k (Ref.)
• PS 32k
• CS 12.2k (Ref.)
• PS 384k (Ref)
• PS 128k
• PS 64k
• PS 32k
• CS 12.2k (Ref.)
3FL12812AAAAWBZZA Ed2
March 2007
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 and
one list for DL) that are further filtered according to UE capability.
7-25
Student notes
7-26
Target RAB Determination
7-27
3FL12812AAAAWBZZA Ed2
7-27
March 2007
UL RB Rate Adaptation Initialization
Requested RAB
Reference UL bit rate
Reference DL bit rate
RAB to RBset Matching (UL/DL)
DL iRM
UL bit rate limitation
If Reference UL bit rate > Max UL bit rate
Then Initial UL bit rate = Max UL bit rate
Else Initial UL bit rate = Reference UL bit rate
Initial UL bit rate
iRM DL bit rate
RBset to UserServices Matching (UL/DL)
Target RAB (DL/UL)
isUlRbRateAdaptationAllowed
(RadioAccessService)
Resource Reservation
&
Admission Control
maxUlEstablishmentRate
(CacConfClass)
RB Rate Adaptation (UL/DL)
32
7-28
64
128
384
3FL12812AAAAWBZZA Ed2
March 2007
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-28
DL IRM RB Selection Algorithm
Code Load
3 Power Load
Iub Load
Cell Color
2 RL Quality
Radio
Link C
4 A/R Priority Level
olor
Gold
Bronze
DL Candidate RbSet
1
Silver
DL Candidate RbSet
(Ref.)
(Ref.)
(Target)
5 IRM Tables
7-29
3FL12812AAAAWBZZA Ed2
March 2007
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-29
IRM on Radio Link Condition
No
isIrmOnRlConditionAllowed
(RadioAccessService)
?
Good RL
Condition
Yes
If
- CPICH_Ec/No < irmDlPowerThreshold (IrmOnRlConditionParameters)
dlRbSetConfId
(IrmOnRlConditionParameters)
And
CPICH_RSCP > irmDlcoverageThreshold (IrmOnRlConditionParameters)
Then
Else
Good RL
Condition
Bad RL
Condition
cacConfId (FDDCell)
7-30
cacConfId (FDDCell)
3FL12812AAAAWBZZA Ed2
March 2007
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-30
IRM on Cell Color
isIrmOnCellColourAllowed
(RadioAccessService)
No
?
Radio Color = Green
Yes
cacConfId (FDDCell)
Code Load
Thresholds
Code Color
cacConfId (FDDCell)
Power Load
Thresholds
Power Color
Radio Color
nodeBConfClassId (NodeB)
Iub Load
Thresholds
Cell Color
IRM Tables
Iub Color
Yes
isDlIubTransportLoadColourCalculationEnabled
(RadioAccessService)
7-31
?
No
Iub Color = Green
3FL12812AAAAWBZZA Ed2
March 2007
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 iRM
table (in case of soft HandOver).
7-31
Cell Color Calculation
Code Load
yellow2redCLCthreshold
red2yellowCLCthreshold
70 %
(IrmOnCellColourParameters)
(IrmOnCellColourParameters)
60 %
50 %
green2yellowCLCthreshold
yellow2greenCLCthreshold
40 % (IrmOnCellColourParameters)
(IrmOnCellColourParameters)
Worst
Power Load
yellow2redPLCthreshold
red2yellowPLCthreshold
70 %
(IrmOnCellColourParameters)
(IrmOnCellColourParameters)
60 %
50 %
green2yellowPLCthreshold
yellow2greenPLCthreshold
40 % (IrmOnCellColourParameters)
(IrmOnCellColourParameters)
Radio Color
Worst
Cell Color
Iub Load
yellow2redDlTLCthreshold
red2yellowDlTLCthreshold
90 %
(IrmIubTransportLoadParameters)
(IrmIubTransportLoadParameters)
80 %
70 %
green2yellowDlTLCthreshold
yellow2greenDlTLCthreshold
60 % (IrmIubTransportLoadParameters)
(IrmIubTransportLoadParameters)
7-32
3FL12812AAAAWBZZA Ed2
Iub Color
March 2007
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).
1
NumberOfFreeCodesPerSpreadingFactor
CodeLoad =
∑
NumberOfSpreadingFactors AllSF
SpreadingFactor
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”.
7-32
Cell Color / Active Set Color Calculation
Cell 1
Worst
+
+
+
Worst
Code Color
Iub Color
Worst
Green
=
=
=
Yellow
Red
Power Color
Green
Cell Color
Yellow
Worst
Red
Cell N
Green
Active Set Color
Yellow
Red
Cell Color
7-33
3FL12812AAAAWBZZA Ed2
March 2007
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-33
DL Target RB Determination
RadioAccessService
DL Ref RB
DlRbSetConf
384
256
RlCondition
128
CellColors
64
OLS
gold
silver
bronze
gold
silver
bronze
gold
silver
bronze
gold
silver
bronze
Radio Link = Good
Radio Link = Bad
Cell color Cell color Cell color Cell color Cell color Cell color
Green
Yellow
Red
Green
Yellow
Red
384
384
128
128
128
64
384
384
128
128
64
32
384
128
64
64
32
8
256
256
128
128
128
64
256
256
64
128
64
32
256
128
32
64
32
8
128
128
64
64
64
64
128
128
64
64
64
32
128
64
32
64
32
8
64
64
64
64
64
32
64
64
32
64
32
32
64
32
8
32
32
8
ARPriorityLevel
priorityLevel
(ARPriorityLevel)
7-34
irmDlRbSetId
(ARPriorityLevel)
3FL12812AAAAWBZZA Ed2
March 2007
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-34
IRM Tables (example)
DlRbSetConf/PSDTCH384K
RlCondition/rlGood
ARPriorityLevel/1
priorityLevel=1
irmDlRbSetConfId=PSDTCH384K
ARPriorityLevel/0
priorityLevel=2
irmDlRbSetConfId=PSDTCH384K
ARPriorityLevel/2
priorityLevel = 3
irmDlRbSetConfId=PSDTCH384K
ARPriorityLevel/1
priorityLevel=1
irmDlRbSetConfId=PSDTCH384K
ARPriorityLevel/0
priorityLevel=2
irmDlRbSetConfId=PSDTCH128K
ARPriorityLevel/2
priorityLevel = 3
irmDlRbSetConfId=PSDTCH64K
ARPriorityLevel/1
priorityLevel=1
irmDlRbSetConfId=PSDTCH32K
ARPriorityLevel/0
priorityLevel=2
irmDlRbSetConfId=SRBinCellFACH
ARPriorityLevel/2
priorityLevel = 3
irmDlRbSetConfId=SRBinCellFACH
ARPriorityLevel/1
priorityLevel=1
irmDlRbSetConfId=PSDTCH128K
ARPriorityLevel/0
priorityLevel=2
irmDlRbSetConfId=PSDTCH128K
ARPriorityLevel/2
priorityLevel = 3
irmDlRbSetConfId=PSDTCH128K
ARPriorityLevel/1
priorityLevel=1
irmDlRbSetConfId=PSDTCH64K
ARPriorityLevel/0
priorityLevel=2
irmDlRbSetConfId=PSDTCH32K
ARPriorityLevel/2
priorityLevel = 3
irmDlRbSetConfId=SRBinCellFACH
ARPriorityLevel/1
priorityLevel=1
irmDlRbSetConfId=PSDTCH32K
ARPriorityLevel/0
priorityLevel=2
irmDlRbSetConfId=SRBinCellFACH
ARPriorityLevel/2
priorityLevel = 3
irmDlRbSetConfId=SRBinCellFACH
CellColor/cellColorGreen
CellColor/cellColorYellow
CellColor/cellColorRed
RlCondition/rlBad
CellColor/cellColorGreen
CellColor/cellColorYellow
CellColor/cellColorRed
7-35
3FL12812AAAAWBZZA Ed2
March 2007
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-35
Student notes
7-36
Resource Reservation & Admission
Control
7-37
3FL12812AAAAWBZZA Ed2
7-37
March 2007
UL Radio Load Control
ulCapacityThreshold
Call is accepted
New RL
UL Cost
Call is rejected
Yes
No
PS 128 UEK
UL Cost < UL Capacity Threshold
UL Cost
PS 384 UEI
(FDDCell)
Established RLs
UL Cost
RNC
isShoCacOnNodebLoadAtRncAllowed (RadioAccessService)
PS 128 UEJ
maxCellRadius (FDDCell)
ulCost (static)
PS 128 UEK
7-38
3FL12812AAAAWBZZA Ed2
March 2007
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-38
Transport Resource Reservation
iuCsTransportQosId (DL/ULRbSetConf)
Iu-CS Bearer
Radio Bearer
Iub Bearer
iubIurTransportQosId (DL/ULRbSetConf)
Iur Bearer
Iu-PS Bearer
dscp (DscpPerOlympicService)
priorityLevel (DscpPerOlympicService)
Radio Bearer
7-39
Iub Bearer
3FL12812AAAAWBZZA Ed2
March 2007
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-39
AAL2 Call Admission Control
aal2If
QoS0
ACR(QoS0) x qoS0BWReservation (aal2If)
SHARED
QoS1
ACR(QoS1) x qoS1BWReservation (aal2If)
qos
CacMethod (aal2If)
aal2If
384 kbps
RB MBR
isAal2BearerRenegotiationAllowed (RadioAccessService)
384 kbps
AAL2 CAC EBR
AAL2 CAC EBR
RB MBR
false
ACR(aal2If)
8 kbps
EBR(384 kbps)
384 kbps
384 kbps
8 kbps
EBR(384 kbps)
EBR(8 kbps)
3FL12812AAAAWBZZA Ed2
7-40
true
EBR(384 kbps)
March 2007
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-40
DL Reserved Power Computation
Pmax = pcpichPower + maxDlTxPower
algo1
Pres = Pmax - algo1DeltaTargetPower
algo2
Pres = Pini + algo2DeltaTargetPower
Pini = pcpichPower + initialDlEcnoTarget – CPICH_Ec/No
Algorithm Selection
dlAlgoSelector (PowerConfClass)
powerConfId (FDDCell)
pcpichPower (FDDCell)
maxDlTxPower (DlUsPowerConf)
FDDCell
algo1DeltaTargetPower (DlUsPowerConf)
algo2DeltaTargetPower (DlUsPowerConf)
initialDlEcnoTarget (DlUsPowerConf)
7-41
3FL12812AAAAWBZZA Ed2
March 2007
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 dlAlgoSelector
parameter 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-41
DL Power Admission Criteria
maxTxPower (FDDCell)
callAdmissionRatio (PowerPartConfClass)
2nd
Traffic Power
(SHO reserved)
Pres
Pdata
1st
P traffic
P traffic admission
Traffic
Power
minSpeechPowerRatio (PowerPartConfClass)
Pres
minSignallingPowerRatio (PowerPartConfClass)
Pused
Overhead
Power
(Common
Channels)
Call
Rejected
minDataPowerRatio (PowerPartConfClass)
1st Admission Criterion
Pres + Pused ≤ Ptraffic_admission
No
Yes
Pres is
allocated
Yes
No
2nd Admission Criterion (Data example)
Pres + Pdata ≤ Ptraffic_admission (1- minSpeechPowerRatio – minSignallingPowerRatio )
7-42
3FL12812AAAAWBZZA Ed2
March 2007
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-42
DL Power Self Tuning
isBtsPowerSelfTuningActivated (PowerConfClass)
New allocated
power
Allocated Power
powerMargin
(PowerConfClass)
Measured Power
overEstimate
(PowerConfClass)
Measured Power
Allocated Power
Case 1
Power consumption
underestimated at the RNC
7-43
New allocated
power
Case 2
Power consumption
overestimated at the RNC
3FL12812AAAAWBZZA Ed2
March 2007
Tuning of RNC power pool occupancy
The parameter isBtsPowerSelfTuningActivated indicates if the power pool selftuning 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-43
OVSF Codes Reservation & Admission
OVSF Code Channel Source
C256,0
P-CPICH
C256,1
P-CCPCH 3GPP
AlcatelAICH
Lucent
AlcatelPICH
Lucent
AlcatelS-CCPCH
Lucent
C256,2
C256,3
C64,1
3GPP
Channelization Code (SIB 5)
Channelization Code (SIB 5)
Spreading Factor (SIB 5)
Code Number (SIB 5)
SF4
SF8
SF16
SF32
SF64
OVSF Codes Allocation
Common
Channels
SF128
SF256
7-44
3FL12812AAAAWBZZA Ed2
March 2007
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-44
CN-involved Directed Retry for Speech
Service Request
RNC
Core Network
Service Request
RAB Assignment Request
IF
Speech Call
AND
is3Gto2GVoiceCallRedirectOnRabEstabFailAllowed = TRUE
AND
Blind 2G neighbor configured (and HO allowed/possible)
AND
UE in Cell_DCH
THEN
Directed Retry triggered
is3Gto2GVoiceCallRedirectOnRabEstabFailAllowed
RAB Assignment Response
(failure cause = Directed Retry)
(RadioAccessService)
callsEligibleFor3Gto2GVoiceCallRedirectOnRabEstabFail
(RadioAccessService)
7-45
3FL12812AAAAWBZZA Ed2
Relocation Required
(CGI)
March 2007
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-45
Student notes
7-46
CELL_FACH Admission Control
7-47
3FL12812AAAAWBZZA Ed2
7-47
March 2007
CELL_FACH Admission Control
CELL_FACH Admission Events
IDLE
RRC Connection Request
CELL_DCH
SRB ONLY
CELL_FACH
CELL_FACH
Admission Control
Cell Update
MaxNumberOfUsersPerMacC
(CacOnFachParam)
trbEstThreshold
(CacOnFachParam)
AO Upsize
CELL_DCH
SRB + RB
CELL_FACH
Cell Update
Bucket Occupancy
RAB Assignment
AO Downsize
7-48
3FL12812AAAAWBZZA Ed2
March 2007
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-48
Student notes
7-49
Student notes
7-50
Packet Data Management
Section 8
3FL12812AAAAWBZZA Ed2
8-1
March 2007
Objectives
After this section, you will be able to
> Describe packet data management principles
> Describe Always On and associated parameters
> Describe iRM Scheduling and associated parameters
> Describe iRM Preemption and associated parameters
8-2
3FL12812AAAAWBZZA Ed2
8-2
March 2007
Contents
> Packet Data Management Overview
> Always On
> RB Rate Adaptation
> iRM Scheduling
> iRM Preemption
8-3
3FL12812AAAAWBZZA Ed2
8-3
March 2007
Student notes
8-4
Packet Data Management
Overview
8-5
3FL12812AAAAWBZZA Ed2
8-5
March 2007
Packet Data Management Mechanisms
UM
9
R9
S
T
Dedicated Channel
Dedicated Channel
Dedicated Channel
8-6
Service Class
Domain
Always On
RB Rate
Adaptation
iRM Scheduling
iRM Preemption
Conversational
CS
Streaming
CS
Streaming
PS
Interactive
PS
Background
PS
3FL12812AAAAWBZZA Ed2
March 2007
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 by
providing 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-6
Always On
8-7
3FL12812AAAAWBZZA Ed2
8-7
March 2007
Always On Principles
User Traffic
Volume
T1
T1
T1
T2
Throughput Threshold
Time
T1
T1
T2
AO timers
UE State
Radio Bearer
8-8
CELL_DCH
CELL_DCH
or
CELL_FACH
NOMINAL RB
AO Downsized RB
PMMPMM-idle
No Radio
3FL12812AAAAWBZZA Ed2
March 2007
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-8
Always On Algorithms
low traffic
UL AND DL
Traffic volume
monitoring
low traffic
UL AND DL
AO Downsize
CELL_DCH
DCH RB
AO Downsize
CELL_FACH
OR
Traffic Volume
Monitoring
FACH RB
RLC/MAC Buffer
Occupancy Monitoring
no traffic
UL AND DL
traffic resuming
UL OR DL
AO Release
AO Upsize
isAlwaysOnAllowed (AlwaysOnConf)
preferredTransportTypeForAlwaysOn (AlwaysOnConf)
8-9
3FL12812AAAAWBZZA Ed2
March 2007
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-9
Always On on DCH Parameters
Ul & DL Traffic Volume
step1AverageWindow (AoOnDchParam)
step2AverageWindow (AoOnDchParam)
step1ThroughputThreshold (AoOnDchParam)
step2ThroughputThreshold (AoOnDchParam)
T1
T2
timerT1 (AlwaysOnTimer)
NOMINAL RB
timerT2 (AlwaysOnTimer)
AO Downsized RB
alwaysOnUlRbSetDchId (AlwaysOnConf)
alwaysOnDlRbSetDchId (AlwaysOnConf)
8-10
priorityLevel (AlwaysOnTimer)
No Radio
step1TimerBetween2Reports (AoOnDchParam)
3FL12812AAAAWBZZA Ed2
March 2007
The downsize condition is based on DL and UL traffic volume monitoring on nonsliding 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 nonsliding 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-10
Always On on FACH Parameters
Ul & DL Traffic Volume
step1AverageWindow (AoOnFachParam)
step2AverageWindow (AoOnFachParam)
step1DlUlThroughputThreshold (AoOnFachParam)
step2ThroughputThreshold (AoOnFachParam)
T1
timerT1 (AlwaysOnTimer)
NOMINAL RB
T2
timerT2 (AlwaysOnTimer)
AO Downsized RB
priorityLevel (AlwaysOnTimer)
No Radio
alwaysOnUlRbSetFachId (AlwaysOnConf)
alwaysOnDlRbSetFachId (AlwaysOnConf)
8-11
3FL12812AAAAWBZZA Ed2
step1TimerBetween2Reports (AoOnFachParam)
March 2007
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-11
AO on FACH UL Upsize Parameters
Reporting
event4a
UE RLC/MAC Buffer Occupancy
Report
Reporting
event4a
repThreshold (AoOnFachParam)
timeToTrigger (AoOnFachParam)
FACH
8-12
Upsize
pendTimeAfterTrig (AoOnFachParam)
DCH
3FL12812AAAAWBZZA Ed2
March 2007
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-12
AO on FACH DL Upsize Parameters
RLC/MAC Buffer Occupancy per UE
Upsize
Required
step1DlRlcBoThreshold (AoOnFachParam)
Upsize step1TimerBetween2Reports (AoOnFachParam)
FACH
8-13
3FL12812AAAAWBZZA Ed2
DCH
March 2007
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-13
Always On for Multi-Service CS+PS RAB
Traffic Resuming
PS I/B
CELL_DCH
PS AO
CELL_DCH
or
CELL_FACH
Downsizing / Upsizing
No Traffic
PMMPMM-idle
Add CS
Release CS
CS+PS I/B
CELL_DCH
CS+PS AO
CELL_DCH
Downsizing / Upsizing
No Traffic
CS+PMMCS+PMM-idle
Traffic Resuming
8-14
3FL12812AAAAWBZZA Ed2
March 2007
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-14
User Services Parameters
RNC
DlUserService
UlUserService
DlRbSetConf
UlRbSetConf
AlwaysOnConf
preferredTransportTypeForAlwaysOn
alwaysOnUlRbSetDchId
alwaysOnDlRbSetDchId
isAlwaysOnAllowed
isAlwaysOnAllowed
alwaysOnUlRbSetFachId
alwaysOnDlRbSetFachId
true false disabled degraded2AlwaysOnOnly releaseOnly AlwaysOnTimer
timerT2ForStreamingRab
timerT2ForMultiRab
8-15
3FL12812AAAAWBZZA Ed2
March 2007
The Radio Bearers used for the downsized state are provided in the AlwaysOnConf
object, 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-15
Student notes
8-16
RB Rate Adaptation
8-17
3FL12812AAAAWBZZA Ed2
8-17
March 2007
RB Rate Adaptation Principles
isUlRbRateAdaptationAllowed
(RadioAccessService)
isDlRbRateAdaptationAllowed
(RadioAccessService)
Requested RAB
Reference UL bit rate
Reference DL bit rate
RAB to RBset Matching (UL/DL)
rbRateAdaptationPinPongTimer
(RadioAccessService)
DL iRM
UL bit rate limitation
maxUlEstablishmentRate
(CacConfClass)
Initial UL bit rate
iRM DL bit rate
RBset to UserServices Matching (UL/DL)
Target RB (DL/UL)
CAC
Current RB (DL/UL)
RB Rate Adaptation (UL/DL)
Traffic Monitoring (UL/DL)
RB Resizing (UL/DL)
Estimated
Throughput
(DL/UL)
Adapted RB
(DL/UL)
32
8-18
64
128
3FL12812AAAAWBZZA Ed2
384
March 2007
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
• Upsizing
Uplink: RNC targets the bit rate immediately above the current bit rate (step-bystep 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-18
Traffic Monitoring Principles
Throughput Estimates
T0
T1
T2
T3
T4
time
raUnitPeriodTime
(DlRbRaTrafficMonitoring)
raNbOfSample
(DlRbRaTrafficMonitoring)
Rate[0]=0
Rate[1]=0
Rate[2]=0
Rate[0]=0
Rate[1]=0
Rate[2]=N0/T
R=
Rate[0]=0
Rate[1]=N0/T
Rate[2]=N1/T
1 K −1
∑ Rate [k ]
K k =0
Rate[0]=N0/T
Rate[1]=N1/T
Rate[2]=N2/T
S2 =
Rate[0]=N1/T
Rate[1]=N2/T
Rate[2]=N3/T
raUnitPeriodTime
(UlRbRaTrafficMonitoring)
raNbOfSample
(UlRbRaTrafficMonitoring)
1 K −1
∑ (Rate[k ] − R )2
K − 1 k =0
Confidence Level
throughput Estimate
RLC-SDU
throughput
Confidence Interval = 2β
β
Reliable Throughput Estimate
8-19
S
tδ ,K ≤ β
R K
raMaxConfidenceInt
(DlRbRaTrafficMonitoring)
raModifiedStudentCoef
(DlRbRaTrafficMonitoring)
raMaxConfidenceInt
(UlRbRaTrafficMonitoring)
raModifiedStudentCoef
(UlRbRaTrafficMonitoring)
3FL12812AAAAWBZZA Ed2
March 2007
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-19
DL Downsizing
DL384
DL256
DL128
RLC-SDU Average Throughput
DL64
DL32
isDlRbRateAdaptationAllowedForThisDlUserService
(DlUserService)
DL384
isDlRbRateAdaptationAllowedForThisDlRbSetConf
(DlRbSetConf)
isThisRbRateAdaptationDlRbSetTargetAllowed
(DlRbSetConf)
no downsize
dlRbRateAdaptationDownsizeThreshold
(DlRbSetConf)
DL256
TDOWN384
MIN (Adapted RB, IRM RB)
downsize to DL256
DL128
TDOWN256
DL64
DL32
downsize to DL128
downsize to DL64
downsize to DL32
TDOWN128
DL iRM
Allocated RB
Reference RB
TDOWN64
time
8-20
3FL12812AAAAWBZZA Ed2
March 2007
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-20
UL Downsizing
UL384
UL128
UL64
UL32
RLC-SDU Average Throughput
UL384
isUlRbRateAdaptationAllowedForThisUlUserService
(UlUserService)
isUlRbRateAdaptationAllowedForThisUlRbSetConf
(UlRbSetConf)
no downsize
isThisRbRateAdaptationUlRbSetTargetAllowed
(UlRbSetConf)
ulRbRateAdaptationDownsizeThreshold
(UlRbSetConf)
UL128
TDOWN384
UL64
UL32
downsize to UL128
downsize to UL64
downsize to UL32
TDOWN128
TDOWN64
time
8-21
3FL12812AAAAWBZZA Ed2
March 2007
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-21
DL Multi-Stage Upsizing
DL384
DL256
DL128
QUP384
isDlRbRateAdaptationAllowedForThisDlRbSetConf
(DlRbSetConf)
QUP256
isThisRbRateAdaptationDlRbSetTargetAllowed
(DlRbSetConf)
QUP128
QUP64
DL256
upsize of DL256
DL32
isDlRbRateAdaptationAllowedForThisDlUserService
(DlUserService)
RLC-SDU Average Throughput
DL384
no upsize
DL64
dlRbRateAdaptationUpsizeThreshold
(DlRbSetConf)
RLCRLC-SDU
buffer
raSduQueueThreshold
(DlRbSetConf)
Current RB
MAX [ MIN (Adapted RB, IRM RB), Current RB ]
DL128
DL64
DL32
upsize of DL128
Allocated RB
upsize of DL64
upsize of DL32
TUP64
TUP32
time
8-22
DL iRM
TUP128
Reference RB
3FL12812AAAAWBZZA Ed2
March 2007
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-22
UL Step by Step Upsizing
UL384
UL128
UL64
UL32
UL8
RLC-SDU Average Throughput
UL384
isUlRbRateAdaptationAllowedForThisUlUserService
(UlUserService)
isUlRbRateAdaptationAllowedForThisUlRbSetConf
(UlRbSetConf)
no upsize
isThisRbRateAdaptationUlRbSetTargetAllowed
(UlRbSetConf)
ulRbRateAdaptationUpsizeThreshold
(UlRbSetConf)
UL128
upsize of UL128
UL64
upsize of UL64
UL32
upsize of UL32
TUP128
TUP64
TUP32
time
8-23
3FL12812AAAAWBZZA Ed2
March 2007
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-23
Student notes
8-24
iRM Scheduling
8-25
3FL12812AAAAWBZZA Ed2
8-25
March 2007
iRM Scheduling Principles
Downgrade
Nominal RB
isRlcMacBasedIrmSchedulingAllowed (RadioAccessService)
isIrmSchedulingAllowed (DlUserService)
Intermediate RB
flipFlopUpDowngradeTimer (RadioAccessService)
Fallback RB
Upgrade
NodeB
isIrmSchedDowngradeTxcpAllowed
(RadioAccessService)
DL 384 kbit/s
DL 128 kbit/s
DL 64 kbit/s
8-26
3FL12812AAAAWBZZA Ed2
March 2007
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 iRM
Scheduling Downgrade. The two triggers are mutually exclusive: iRM Scheduling
Downgrade is based on one unique trigger.
8-26
iRM Scheduling Downgrade – BLER
based
radioQualityMeasurementQuantity (irmSchedulingConf)
irmTimerBetween2reports (IrmSchedulingConf)
DL PS384
rlcMacObservable(t)
rlcMacObservableThreshold
timeToTrigger (IrmSchedulingConf)
DL PS64
Use of Fallback TFCS
fallbackThroughput (IrmSchedulingconf)
Reconfiguration to Fallback RB
targetDlRbSetForIrmScheduling (IrmSchedulingconf)
8-27
3FL12812AAAAWBZZA Ed2
March 2007
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.
Note
iRM 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 iRM
scheduling 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-27
Event A for iRM Scheduling Downgrade
isIrmSchedDowngradeTxcpAllowed (DlUsPowerConf)
Event A
Report
Transmitted Code Power
Primary Cell
TxCP
Threshold
Event A Timer
Event A Timer
pcpichPower (FDDCell) + maxDlTxPower (DlUsPowerConf) - dlIrmSchedDowngradeTxcpTrigger_threshold_delta (DlUsPowerConf)
dlIrmSchedDowngradeTxcpTrigger_threshold_delta (DlUsPowerConf)
dlIrmSchedDowngradeTxcpTrigger_timeToTrigger (DlUsPowerConf)
8-28
3FL12812AAAAWBZZA Ed2
March 2007
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-28
iRM Scheduling Downgrade – TxCP
based
irmSchedDowngradeTxcpMaxBitRate (RadioAccessService)
Event A
RNC
DL PS384
Use of Fallback TFCS
DlRbSetConf
PS 384
PS 256
RBset to User Services Matching
PS 128
PS 64
PS 32
PS 8
DL PS64
Reconfiguration to Downgraded RB
8-29
3FL12812AAAAWBZZA Ed2
March 2007
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-29
Event Bx for iRM Scheduling Upgrade
Upgrade
64
384
128
Transmitted Code Power
Event B1
Report
Event B2
Report
Primary Cell
thresholdTransCodePower (DhighRbB1)
Event B2
Threshold
128
Event B1
Threshold
384
timeToTrigger (DhighRbB1)
deltaThresholdTransCodePower (DhighRbB2)
deltaTimeToTrigger (DhighRbB2)
Event B1 Timer
Event B2 Timer
8-30
3FL12812AAAAWBZZA Ed2
March 2007
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.
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 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 falls below
thresholdTransCodePower during at least timeToTrigger.
Event B2 configuration relies on:
• 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-30
iRM Scheduling Upgrade
Cell color
RL Condition
iRM tables
Requested RB
iRM RB
OLS
Min
Event Bx
Event Bx
Processing
Granted RB
Power RB
highBitRate (DhighRbB1)
thresholdTransCodePower (DhighRbB1)
timeToTrigger (DhighRbB1)
isIrmSchedulingUpgradeAllowed (RadioAccessService)
isIrmSchedulingUpgradeAllowedFromThisUS (DlUserService)
isIrmSchedulingUpgradeAllowedToThisUS (DlUserService)
intermediateRate (MediumRbB2)
deltaThresholdTransCodePower (MediumRbB2)
deltaTimeToTrigger (MediumRbB2)
8-31
3FL12812AAAAWBZZA Ed2
March 2007
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-31
iRM Scheduling RAB Configuration
RNC
384
DlUserService/7
isIrmSchedulingAllowed = true
isTransCodePowerIrmSchedulingDowngradeAllowedFromThisUserService = true
DlRbSetConf/7
DlRbSetConf/3
isIrmSchedulingUpgradeAllowedFromThisUS = true
Downgrade
64
IrmSchedulingUpgrade
IrmSchedulingConf
targetDlRbSetForIrmScheduling = 3
Upgrade
128
384
MediumRbB2
intermediateRate = 128
isIrmSchedulingUpgradeAllowedToThisUS = true
8-32
DHighRbB1
highBitRate = 384
isIrmSchedulingUpgradeAllowedToThisUS = true
3FL12812AAAAWBZZA Ed2
March 2007
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 iRM
scheduling downgrade Power (TxCP).
8-32
iRM Preemption
8-33
3FL12812AAAAWBZZA Ed2
8-33
March 2007
iRM Preemption Algorithm
Code Load
2 Power Load
Iub Load
Cell Color
3 A/R Priority Level
isIrmPreemptionAllowed (RadioAccessService)
Gold
Silver
isIrmPreemptionAllowedForGoldUsers (IrmPreemption)
Bronze
isIrmPreemptionAllowedForSilverUsers(IrmPreemption)
isIrmPreemptionAllowedForBronzeUsers(IrmPreemption)
1
Current DL RB
Downgraded DL RB
4 IRM Tables
8-34
3FL12812AAAAWBZZA Ed2
March 2007
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, iRM
scheduling 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-34
iRM Preemption RB Configuration
RadioAccessService
DL Ref RB
OLS
DlRbSetConf
384
RlCondition
BAD
256
128
CellColors
RED
64
gold
silver
bronze
gold
silver
bronze
gold
silver
bronze
gold
silver
bronze
Radio Link = Good
Radio Link = Bad
Cell color Cell color Cell color Cell color Cell color Cell color
Green
Yellow
Red
Green
Yellow
Red
384
384
128
128
128
64
384
384
128
128
64
32
384
128
64
64
32
8
256
256
128
128
128
64
256
256
64
128
64
32
256
128
32
64
32
8
128
128
64
64
64
64
128
128
64
64
64
32
128
64
32
64
32
8
64
64
64
64
64
32
64
64
32
64
32
32
64
32
8
32
32
8
ARPriorityLevel
iRM Preemption Downgrade Target DL Radio Bearers
8-35
3FL12812AAAAWBZZA Ed2
March 2007
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-35
Cell Color / Active Set Color Calculation
normal2congestedPLCThreshold
(IrmPreemptionCacParams)
congested2normalPLCThreshold
(IrmPreemptionCacParams)
normal2congestedCLCThreshold
(IrmPreemptionCacParams)
congested2normalCLCThreshold
(IrmPreemptionCacParams)
normal2CongestedDlTLCThreshold
(IrmPreemptionIubTransportLoadParameters)
congested2NormalDlTLCThreshold
(IrmPreemptionIubTransportLoadParameters)
Worst
Code Color
Iub Color
Worst
Black
White
Power Color
Cell Color
Worst
Cell 1
Cell N
Black
Black
+
Worst
White
=
White
Active Set Color
Cell Color
8-36
3FL12812AAAAWBZZA Ed2
March 2007
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-36
iRM Preemption Behavior
Preemption Start
UE 1
UE 2
UE N
Black
White
time
AS Color
PS I/B Connection
Color Check
Checking Timer
irmPreemptionColorCheckingTimer (IrmPreemption)
8-37
3FL12812AAAAWBZZA Ed2
March 2007
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-37
Interaction with iRM RAB to RB
Mapping
iRM Color
Radio Color
Green
Yellow
Worst
Preemption Color
Black
Radio Color
Red
White
Cell Color
Cell Color
Iub Color
8-38
Worst
Iub Color
3FL12812AAAAWBZZA Ed2
March 2007
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-38
Student notes
8-39
Student notes
8-40
Power Management
Section 9
3FL12812AAAAWBZZA Ed2
9-1
March 2007
Objectives
After this section, you will be able to
> 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-2
3FL12812AAAAWBZZA Ed2
9-2
March 2007
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-3
3FL12812AAAAWBZZA Ed2
9-3
March 2007
Student notes
9-4
Power Management Static Settings
9-5
3FL12812AAAAWBZZA Ed2
9-5
March 2007
Cell Downlink Power Settings
maximumPowerAmplification (BtsCell)
MaxTxPower (FDDCell)
F2
PaRatio (BtsCell)
F1
PaRatio (BtsCell)
Cell Setup
MaxTxPower (FDDCell) = MIN ( MaxTxPower (FDDCell) , MaxDlPowerCapability)
MaxDlPowerCapability = maximumPowerAmplification (BtsCell) x PaRatio (BtsCell) - Global Losses
3FL12812AAAAWBZZA Ed2
9-6
March 2007
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-6
Cables Losses without TMA
tmaAccessType (AntennaAccess)
externalAttenuationMainDl (AntennaAccess)
externalAttenuationDivDl (AntennaAccess)
externalAttenuationXXXDl = 0
BTS
MCPA
Tx Splitter
DDM
Reference point
Global Losses = Internal Losses
externalAttenuationXXXDl ≠ 0
BTS
MCPA
Tx Splitter
DDM
Reference point
Global Losses = Internal Losses + externalAttenuationXXXDl
3FL12812AAAAWBZZA Ed2
9-7
March 2007
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-7
Cables Losses with TMA
tmaAccessType (AntennaAccess)
externalAttenuationMainDl (AntennaAccess)
externalAttenuationDivDl (AntennaAccess)
externalAttenuationXXXDl = 0
BTS
MCPA
Tx Splitter
TMA
DDM
Reference point
Global Losses = Internal Losses + Feeder Losses + TMA Insertion Losses + Jumper Losses
externalAttenuationXXXDl ≠ 0
BTS
MCPA
Tx Splitter
TMA
DDM
Reference point
Global Losses = Internal Losses + externalAttenuationXXXDl + TMA Insertion Losses + Jumper Losses
9-8
3FL12812AAAAWBZZA Ed2
March 2007
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-8
Common Channel Power Settings
NodeB
Traffic Power
(SHO
reserved)
Traffic
Power
Channel
parameter
Object
PCPICH
pcpichPower
FDDCell
P-SCH
pschPowerRelativeToPcpich
FDDCell
S-SCH
sschPowerRelativeToPcpich
FDDCell
P-CCPCH
bchPowerRelativeToPcpich
FDDCell
S-CCPCH
sccpchPowerRelativeToPcpich
SCCPCH
AICH
aichPowerRelativeToPcpich
RACH
PICH
pichPowerRelativeToPcpich
PCH
Overhead
Power
(Common
Channels)
9-9
3FL12812AAAAWBZZA Ed2
March 2007
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-9
Dedicated Channels Power Settings
RadioAccessService
o
TxP
dUl
e
w
Allo
m ax
wer
sPo
(UlU
f)
Con
wer
FACH
DedicatedConf
maxTxPower (FDDCell)
powerConfId (FDDCell)
PowerConfClass
minDlTxPower (DlUsPowerConf)
max UE Tx Power (UE Power Class)
maxDlTxPower (DlUsPowerConf)
DlUsPowerConf
UlUsPowerConf
Max UL Tx Power = MIN( maxAllowedUlTxPower (UlUsPowerConf) , Max UE Tx Power)
9-10
3FL12812AAAAWBZZA Ed2
March 2007
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 reestablished, 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-10
PRACH Power Control
9-11
3FL12812AAAAWBZZA Ed2
9-11
March 2007
PRACH Open Loop
AICH
NACK
NACK
NACK
ACK
SIB 5
sibMaxAllowedUlTxPowerOnRach (PowerConfClass)
PRACH
Data part
SIB 5
powerOffsetPpm (static)
PRACH
Control part
SIB 5
betaC (static)
betaD (static)
SIB 5
powerOffsetPO (RACH)
Pini
Preamble part
Message part
SIB 5
SIB 5
Pini = pcpichPower (FDDCell) + RTWP + constantValue (RACH) - P-CPICH_RSCP
SIB 7
9-12
3FL12812AAAAWBZZA Ed2
March 2007
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-12
UL DPCCH Open Loop Power
Control
9-13
3FL12812AAAAWBZZA Ed2
9-13
March 2007
UL Dedicated Channels Synchronization
INIT
nInSyncInd (FDDCell)
Sync OK
nInSyncInd (FDDCell)
Sync KO
nInSyncInd (FDDCell)
nOutSyncInd (FDDCell)
tRlFailure (FDDCell)
RL Failure
SIRAV > -3dB => InSyncInd
RL Restore
SIRAV < -3dB => OutSyncInd
nOutSyncInd (FDDCell)
tRlFailure (FDDCell)
nInSyncInd (FDDCell)
3FL12812AAAAWBZZA Ed2
9-14
March 2007
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 nOutSynchInd
consecutive 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 nInSynchInd
successive 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-14
DPCCH Open Loop Power Control
Pinitial (UL DPCCH) = dpcchPowerOffset (UlInnerLoopConf) – P-CPICH_RSCP
UL DPCCH Power Increase = ulTpcStepSize (UlInnerLoopConf)
DL DPCC
H Tx Pow
er Comm
ands
UL Synchronization Failed
T TF
PL Data1 P
Data2 PL
CI
C
0
1
0
1
0
1
TS 0 TS 1 TS …
First pattern
0
1
0
1
1
0
1
0
TS 9 TS 10
Last pattern
dlTpcPattern01Count (FDDCell)
9-15
3FL12812AAAAWBZZA Ed2
March 2007
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-15
UL Power Control Preamble
betaC (SignalledGainFactor)
betaD (SignalledGainFactor)
Inner Loop Power Control
DPCCH DPCCH DPCCH
Inner Loop Power Control
Empty
DPDCH
DPDCH
DPDCH
DPDCH
DPCCH DPCCH
DPCCH
DPCCH
DPCCH
pcPreamble (UlInnerLoopConf)
RNC
9-16
srbDelay (UlInnerLoopConf)
RRC Signaling
3FL12812AAAAWBZZA Ed2
March 2007
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-16
UL DPCCH / DPDCH Power Ratio
RNC
ulUserService
SignalledGainFactor
CSDTCH12_2Kx4SRBDCCH3_4K
2PSDTCH64Kx4SRBDCCH3_4K
CSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K Signaled Mode
CSDTCH64Kx4SRBDCCH3_4K
PSDTCH64Kx4SRBDCCH3_4K
TFC 0
PSDTCH384Kx4SRBDCCH3_4K
StandaloneSRBDCCH3_4K
...
betaC
betaDbetaC
betaDbetaC
refTfcId
refTfcId
betaD betaC
refTfcIdbetaD
refTfcId
RNC
ulUserService
CSDTCH12_2Kx4SRBDCCH3_4K
2PSDTCH64Kx4SRBDCCH3_4K
Computed Mode
CSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K
CSDTCH64Kx4SRBDCCH3_4K
TFC 1
PSDTCH64Kx4SRBDCCH3_4K
PSDTCH384Kx4SRBDCCH3_4K
StandaloneSRBDCCH3_4K
TFCS #2
...
9-17
ComputedGainFactor
refTfcId
betaC (SignalledGainFactor)
betaC (ComputedGainFactor)
betaD (SignalledGainFactor)
betaD (ComputedGainFactor)
refTfcId (SignalledGainFactor)
refTfcId (ComputedGainFactor)
refTfcId
3FL12812AAAAWBZZA Ed2
March 2007
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 (SignalledGainFactor
object) is used.
Once the reference TFCs are declared, some other TFCs of the TFCS (under the
same UlUserService instance) can be provisioned as computedGainFactors
instances (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 betaD
values:
• 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-17
UL Rate Matching Attributes
UlRbSetConf
S-RNC
SRBDCCH3_4K
CSDTCH12_2K
CSDTCH64K
PSDTCH64K
PSDTCH128K
PSDTCH384K
2PSDTCH64K
...
DynamicParameterPerDCH
ulRateMatchingAttribute
UlRbSetConf
D-RNC
SRBDCCH3_4K
CSDTCH12_2K
CSDTCH64K
PSDTCH64K
PSDTCH128K
PSDTCH384K
2PSDTCH64K
...
DynamicParameterPerDCH
iurMinRateMatchingAttribute
iurMaxRateMatchingAttribute
ulRateMatchingAttribute (DynamicParameterPerDCH)
iurMinRateMatchingAttribute (DynamicParameterPerDCH)
iurMaxRateMatchingAttribute (DynamicParameterPerDCH)
9-18
3FL12812AAAAWBZZA Ed2
March 2007
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-18
UL Outer Loop Power Control
9-19
3FL12812AAAAWBZZA Ed2
9-19
March 2007
SIR Target Management
RNC
initialUlSirTarget (UlUsPowerConf)
(NBAP)
CRCI
CRCI
ulUserService
CSDTCH12_2Kx4SRBDCCH3_4K
2PSDTCH64Kx4SRBDCCH3_4K
CSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K
referenceUlRbSetConfId
CSDTCH64Kx4SRBDCCH3_4K
(ReferenceUlRbSetList)
PSDTCH64Kx4SRBDCCH3_4K
PSDTCH384Kx4SRBDCCH3_4K
StandaloneSRBDCCH3_4K
...
Partial
OLPC
ulBlerTarget
(DynamicParameterPerDch)
Partial
OLPC
ulBlerTarget
(DynamicParameterPerDch)
OLPC
Master
New SIR Target
9-20
SRBDCCH3_4K
CSDTCH12_2K
CSDTCH64K
PSDTCH64K
PSDTCH128K
PSDTCH384K
2PSDTCH64K
...
UlRbSetConf
SIR Target
Update
3FL12812AAAAWBZZA Ed2
March 2007
The initial SIR target is sent by the RNC to the NodeB through initialUlSirTarget
parameter. 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-20
Partial SIR Target Update
If CRCI bad
If CRCI good
SIR Target
SIR Target
ulUpSirStep
ulUpSirStep
1
-1
ulBlerTarget
SIR Target
minSirTarget (UlUsPowerConf)
transmitTimeInterval (static)
maxSirTarget (UlUsPowerConf)
TTI
isUlOuterPCActivated (UlOuterLoopPowerCtrl)
ulUpSirStep (DynamicParameterPerDch)
ulBlerTarget (DynamicParameterPerDch)
Update Period = Max [TTI of ReferenceUlRbSetList] x ulUpdatePeriod (UlOuterLoopPowerCtrl)
Triggered Update if SIR Variation ≥ updateThreshold (DynamicParameterPerDch)
9-21
3FL12812AAAAWBZZA Ed2
March 2007
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 TrCHs
depends 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-21
Student notes
9-22
UL Inner Loop Power Control
9-23
3FL12812AAAAWBZZA Ed2
9-23
March 2007
UL Inner Loop Power Control
Rake
Pilot
SIRestimate
DPCCH
TPC
0 or 1
TPC
> or <
SIRTarget
• Down Command:
if SIRestimate > SIRtarget then TPC = 0
• Up Command:
if SIRestimate < SIRtarget then TPC = 1
9-24
3FL12812AAAAWBZZA Ed2
March 2007
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-24
UL Power Control Algorithms
Softer handover
identical TPC commands
for the radio link set
SIR target 2
In case of soft HO
(i.e. TPC1 ≠ TPC2)
UE combines TPCs
according to the selected
algorithm
TPC2
TPC2
NodeB 2
2 RLs
RNC
powerCtrlAlgo (UlInnerLoopConf)
TPC1
SIR target 1
algo1
algo2
One TPC_cmd
9-25
Soft handover
possibly different TPC commands
3FL12812AAAAWBZZA Ed2
NodeB 1
1 RL
March 2007
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-25
UL Inner Loop Algorithm 1
Algo 1: PC rate = 1500 Hz (T=666 µs)
• no soft HO: UE derives a TPC_cmd
from the TPC command received for
each slot
powerCtrlAlgo = algo1
• soft HO: UE has to combine TPCs
from different radio link sets and
deduces a single TPC_cmd
Soft HandOver
• TPC_cmd = -1, +1
DL DPCCH TCP field
Algo1 output
1
1
0
0
+1
+1
-1
-1
x
UE Tx output power
Algorithm allows the UE to derive
a single TPC_cmd per slot
DL DPCCH TCP1 field
1
1
1
0
DL DPCCH TCP2 field
1
1
0
0
DL DPCCH TCP3 field
1
0
0
0
+1
+1
-1
-1
Algo1 output
x
ulTpcStepSize
ulTpcStepSize
UE Tx output power
ulTpcStepSize (UlInnerLoopConf)
9-26
3FL12812AAAAWBZZA Ed2
March 2007
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-26
UL Inner Loop Algorithm 2 (no SHO
case)
Algo 2: PC rate = 300 Hz (T=3,333 ms)
• no soft HO: UE derives a TPC_cmd
from the TPC command received on a
5 slot-cycle basis
Algorithm allows the UE
to derive a single TPC_cmd
every 5 slots
powerCtrlAlgo = algo2
• soft HO: UE has to combine TPCs
from different radio link sets
No Macrodiversity
• TPC_cmd = -1, 0, +1
5 radio slots
DL DPCCH TCP field
Algo2 output
1
1
1
1
1
0
0
0
0
0
+1
1
1
-1
0
0
0
0
x ulTpcStepSize
UE Tx output power
ulTpcStepSize (UlInnerLoopConf)
9-27
3FL12812AAAAWBZZA Ed2
March 2007
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-27
UL Inner Loop Algorithm 2 (SHO case)
DL DPCCH TCP1 field
1
1
1
1
1
1
1
1
1
0
+1
DL DPCCH TCP2 field
1
1
1
0
1
1
1
1
1
0
1
1
1
1
1
0
0
0
0
+1
0
0
DL DPCCH TCPN field
1
1
0
1
0
1
-1
0
0
0
0
0
+1
0
0
0
0
0
0
-1
-1
Sum of TPC
N
> 0.5
< - 0.5
Algo2 output
+1
Otherwise
-1
x
0
ulTpcStepSize
UE Tx ouput power
3FL12812AAAAWBZZA Ed2
9-28
March 2007
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-28
DL Traffic Channels Power
9-29
3FL12812AAAAWBZZA Ed2
9-29
March 2007
Initial DL Traffic Channel Power
First Radio Link
MaxDlTxPower (DlUsPowerConf)
Pinitial = pcpichPower (FDDCell) + initialDlEcNoTarget (DlUsPowerConf) - P-CPICH_Ec/No
MinDlTxPower (DlUsPowerConf)
SHO Leg Addition
isShoLegInitialAlgoEnabled (RadioAccessService)
Pinitial = pcpichPower (FDDCell) + initialDlEcNoTarget (DlUsPowerConf) - P-CPICH_Ec/No Equivalent
cell = N
Σ
P-CPICH_Ec/No Equivalent =
P-CPICH_Ec/No (cell)
cell =1
9-30
3FL12812AAAAWBZZA Ed2
March 2007
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:
CPICH _ Ec / N 0
equiv
N
(dB ) = 10 ∗ log ∑10
 i =1
9-30
CPICH
Ec / N 0( celli )
10



DL DPCCH / DPDCH Power Offsets
po3ForPilotBits (DlUserService)
po2ForTpcBits (DlUserService)
po1ForTfciBits (DlUserService)
DL DPDCH Radio Frame
PO2
Pinitial
PO3
Pilot
9-31
PO1
Data1
TPC
TFCI
3FL12812AAAAWBZZA Ed2
March 2007
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-31
Student notes
9-32
DL Outer Loop Power Control
9-33
3FL12812AAAAWBZZA Ed2
9-33
March 2007
DL Outer Loop Power Control
RNC
dlUserService
CSDTCH12_2Kx4SRBDCCH3_4K
2PSDTCH64Kx4SRBDCCH3_4K
CSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K
CSDTCH64Kx4SRBDCCH3_4K
PSDTCH64Kx4SRBDCCH3_4K
PSDTCH384Kx4SRBDCCH3_4K
StandaloneSRBDCCH3_4K
...
Initial Quality target
RB Setup
Quality
Measurements
TPC
SRB
TRB
TX
isDlReferenceTransportChannelAllowed
dlBlerQuality
inner loop
power control
DL Outer Loop Control IE
Outer Loop
Power Control
9-34
isDlReferenceTransportChannelAllowed
dlBlerQuality
BLERtarget increase not allowed
or
BLERtarget increase allowed
3FL12812AAAAWBZZA Ed2
SRBDCCH3_4K
CSDTCH12_2K
CSDTCH64K
PSDTCH64K
PSDTCH128K
PSDTCH384K
2PSDTCH64K
...
DlRbSetConf
March 2007
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 reestablishment 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-34
DL Inner Loop Power Control
9-35
3FL12812AAAAWBZZA Ed2
9-35
March 2007
DL Inner Loop Algorithm
TFCI
PL
BLER target
TPC = 0 / 1
TPC
UL D
PC C
H
NodeB
TPC
TPC =1=> TPC_cmd = +1
TPC_cmd
BLER est
UE Algo
New
BT
appl S outpu
ied t
t
o DP power
DCH
TPC =0 => TPC_cmd = -1
DL power
change
DL Power Change = ∆PTPC + ∆PBalancing
SHO
TPC_cmd x dlTpcStepSize (DlInnerLoopConf)
9-36
3FL12812AAAAWBZZA Ed2
ΣPBAL
March 2007
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 the
TPC_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-36
Power Balancing
dlReferencePower
(DlUserService)
Power per Leg
P1
P2
P1
PREF
P2
time
RL Addition
isPowerBalancingAllowed (RadioAccessService)
powerBalancingRequired (DlUserService)
adjustmentPeriod (PowerBalancingAdjustmentParameters)
Radio Frame
ΣPBAL = (1 - R) x (PREF + PP-CPICH – PINIT)
∆PBalancing
adjustmentRatio (PowerBalancingAdjustmentParameters)
maxAdjustmentStep (PowerBalancingAdjustmentParameters)
3FL12812AAAAWBZZA Ed2
9-37
March 2007
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-37
Rate Reduction Algorithm
1500 TPC commands / s
1
0
1
0
0
PL
1
TFCI
TPC
DPC_Mode = 0 (single Tpc)
UL D
PC C H
500 TPC commands / s
1
1
1
0
0
0
DPC_Mode = 1 (tpcTripletInSoft)
dpcMode (DlInnerLoopConf)
RRC signaling (from RNC)
9-38
3FL12812AAAAWBZZA Ed2
March 2007
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-38
Student notes
9-39
Student notes
9-40
Mobility in Connected Mode
Section 10
3FL12812AAAAWBZZA Ed2
10-1
March 2007
Objectives
After this section, you will be able to
> 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-2
3FL12812AAAAWBZZA Ed2
10-2
March 2007
Contents
> Mobility Requirements
> Active Set Management
> Primary Cell Determination
> Alarm Hard Handovers
> Intra-NodeB Blind Hard Handover
> IMSI-Based Handovers
10-3
3FL12812AAAAWBZZA Ed2
10-3
March 2007
Student notes
10-4
Mobility Requirements
10-5
3FL12812AAAAWBZZA Ed2
10-5
March 2007
Soft Handover Types
Core Network
RNC
RNC
NodeB
NodeB
FDDcell
FDDcell
FDDcell
Inter-RNC SHO
10-6
NodeB
FDDcell
FDDcell
Intra-RNC SHO
FDDcell
Intra-NodeB SHO
(Softer)
3FL12812AAAAWBZZA Ed2
March 2007
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 SRNC. 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-6
Hard Handover Types
Core Network
RNC
RNC
NodeB
NodeB
NodeB
FDDcell
FDDcell
FDDcell
3G to 2G HHO
GSMcell
FDDcell
Inter-RNC HHO
FDDcell
Intra-RNC HHO
FDDcell
Intra-NodeB
Blind HHO
2G to 3G HHO
10-7
3FL12812AAAAWBZZA Ed2
March 2007
Hard Handover gathers a set of handover procedures where all the old radio linksare
abandoned 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-7
Periodic vs. Full Event Triggered
Reporting
RNC
RRC Measurement Control
(Intra-frequency, Periodical Reporting)
FALSE
isEventTriggeredMeasAllowed
(FDDCell)
RRC Measurement Control
(Ec/No, 1A, 1B, 1C, 1D, 1E, 1F)
RNC
RRC Measurement Control
(Ec/No, 2D, 2F)
RRC Measurement Control
(RSCP, 2D, 2F)
10-8
3FL12812AAAAWBZZA Ed2
TRUE
March 2007
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-8
Periodical Reports Processing
RRC Measurement Report
RNC
RRC Measurement Report
Active Set cells
+
best Monitored Set cells
- 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 evaluation (Primary Cell)
• Intra-NodeB Blind Hard Handover
- 3 - Active Set update
- 4 - Primary Cell election
10-9
3FL12812AAAAWBZZA Ed2
March 2007
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-9
Compound Neighbor List
NA2
NA2
NA2
NA3
NA3
A3
NA2
NA3
NA3
A2
NA1
NA3
NA2
NA3
NA1
NA2
NA1
NA3
A1
NA2
NA2
NA3
A3
NA2
NA3
NA1
NA3
NA1
Monitored Set
Primary Cell
A2
NA1
NA3
NA1
NA2
NA1
A1
NA2
NA2
NA3
NA1
NA1
Monitored Set
isCompoundingCellListActivated (RadioAccessService)
isCompoundingCellListActivated (FDDCell)
isCompoundingCellListActivated (NeighbouringRNC)
10-10
3FL12812AAAAWBZZA Ed2
March 2007
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-10
Compound Neighbor List Management
SHO Neighboring List
Primary Cell Change
OR
Active Set Modification
OR
SHO to non-SHO Transition
OR
Dedicated Connection Initiation
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
+
...
non-SHO Neighboring List
Primary Cell static neighboring for DCH mode
+
first best monitored cell and its static neighboring for DCH mode
+
second best monitored cell and its static neighboring for DCH mode
+
...
maxCompoundingListSize (RadioAccessService)
maxNbMonitoredCellForNonShoCompoundList (RadioAccessService)
sib11OrDchUsage (UMTSFddNeighboringCell)
10-11
3FL12812AAAAWBZZA Ed2
March 2007
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-11
Student notes
10-12
Active Set Management
10-13
3FL12812AAAAWBZZA Ed2
10-13
March 2007
Absolute and Relative Criteria for SHO
P-CPICH Ec/No
Add Delta
Add Absolute Criterion
Drop Delta
Add
Absolute
Threshold
Drop
Relative
Criterion
Be
No Action
st
C
Drop Absolute Criterion
10-14
3FL12812AAAAWBZZA Ed2
ell
Add
Relative
Criterion
Drop
Absolute
Threshold
March 2007
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-14
Drop Criteria (Periodical Mode)
IF
Ec/No(i) + Cell Individual Offset(i) ≤ Ec/No(best) – Drop Delta
AND
Ec/No(i) + Cell Individual Offset(i) ≤ Add Absolute Threshold (if Add Absolute Criterion enabled)
OR
Ec/No(i) + Cell Individual Offset(i) ≤ Drop Absolute Threshold (if Drop Absolute Criterion enabled)
THEN
Drop Cell(i) from Active Set
ELSE
Keep Cell(i) in Active Set
Keep Cell in Active Set
neighbouringCellOffset (UMTSFddNeighbouringCell)
legDroppingDelta (SoftHoConf)
shoLinkAdditionAbsoluteThresholdEnable (SoftHoConf)
shoLinkAdditionCpichEcNoThreshold (ShoLinkAdditionParams)
shoLinkDeletionAbsoluteThresholdEnable (SoftHoConf)
shoLinkDeletionCpichEcNoThreshold (ShoLinkAdditionParams)
Drop Cell from Active Set
10-15
3FL12812AAAAWBZZA Ed2
March 2007
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-15
Add Criteria (Periodical Mode)
IF
Ec/No(i) + Cell Individual Offset(i) ≥ Ec/No(best) - Add Delta
OR
Ec/No(i) + Cell Individual Offset(i) ≥ Add Absolute Threshold (if Add Absolute Criterion enabled)
THEN
Add Cell(i) in Active Set
ELSE
Keep Cell(i) in Monitored Set
Add Cell in Active Set
neighbouringCellOffset (UMTSFddNeighbouringCell)
legAdditionDelta (SoftHoConf)
shoLinkAdditionAbsoluteThresholdEnable (SoftHoConf)
shoLinkAdditionCpichEcNoThreshold (ShoLinkAdditionParams)
maxActiveSetSize (SoftHoConf)
Keep Cell in Monitored Set
10-16
3FL12812AAAAWBZZA Ed2
March 2007
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-16
AS Management (Event Triggered Mode)
P-CPICH Ec/No
Add Delta
EVENT 1E
Drop Delta
Add
Absolute
Threshold
Be
No Action
EVENT 1B
ell
EVENT 1C
Drop
Absolute
Threshold
EVENT 1F
10-17
EVENT 1A
st
C
3FL12812AAAAWBZZA Ed2
March 2007
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-17
Student notes
10-18
Primary Cell Determination
10-19
3FL12812AAAAWBZZA Ed2
10-19
March 2007
Primary Cell Election: Periodical Mode
Candidate Cells Selection
IF
Cell(i) was in previous Active Set
AND
Cell(i) is in new Active Set
AND
Ec/No(i) – Drop Primary Delta ≥ Ec/No(Primary Cell)
New Active Set
Cell 1
Cell 2
Cell 3
Cell 4
Candidate Cells
Cell 1
Cell 3
THEN
Cell(i) is candidate for Primary Cell Election
ELSE
Keep Cell(i) in Active Set
rrcIntraFreqMeasurementDropPrimaryDelta (RRCMeasurement)
Primary Cell Election
IF
Candidate Cells
Ec/No(i) is the highest of all candidate cells
Cell 1
THEN
Cell 3
ELSE
y
ar
im ll
r
P Ce
Cell(i) is the new Primary Cell
Keep Cell(i) in Active Set
10-20
3FL12812AAAAWBZZA Ed2
Cell 3
March 2007
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-20
CPICH_EC/No
Event1D
Primary Cell Change: Event 1D
entering reporting range
NotBest Cell
Best Cell
leaving reporting range
maxNbReportedCells1D
(FullEventRepCritShoMgtEvent1D)
useCIOfor1D
(FullEventRepCritShoMgtEvent1D)
timeToTrigger1D
(FullEventRepCritShoMgtEvent1D)
10 ⋅ LogMNotBest + CIONotBest ≥ 10 ⋅ LogMBest + CIOBest ± H1d / 2)
hysteresis1D (FullEventRepCritShoMgtEvent1D)
cellIndivOffset (UMTSFddNeighbouringCell)
10-21
3FL12812AAAAWBZZA Ed2
March 2007
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-21
Student notes
10-22
Alarm Hard Handovers
10-23
3FL12812AAAAWBZZA Ed2
10-23
March 2007
Two-Step Alarm HHO (Periodical Mode)
isAlarmHhoAllowed (RadioAccessService)
IF
P-CPICH_EcNo(primary) < cpichEcNoThreshold
OR
P-CPICH_RSCP(primary) < cpichRscpThreshold
THEN
Alarm Handover Counter is incremented by stepUp
IF
Alarm Handover Counter > counter
THEN
• Alarm Handover is requested
• Target Cell for HHO is chosen
ELSE
Alarm Handover Counter = Max ( 0; Alarm Handover Counter – stepDown)
cpichEcNoThreshold (AlarmHardHoConf)
cpichRscpThreshold (AlarmHardHoConf)
counter (AlarmHardHoConf)
stepUp (AlarmHardHoConf)
stepDown (AlarmHardHoConf)
10-24
3FL12812AAAAWBZZA Ed2
March 2007
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 per
DlUserService. 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-24
Fast Alarm HHO (Periodical Mode)
Two Step Algorithm
Primary Cell
Radio Quality
CM Criteria
Alarm Measurements
fastAlarmHoEnabled (RadioAccessService)
HHO Criteria
cpichEcNoThreshold (FastAlarmHardHoConf)
Alarm HHO
cpichRscpThreshold (FastAlarmHardHoConf)
counter (FastAlarmHardHoConf)
Fast Alarm Algorithm
Primary Cell
Radio Quality
CM Criteria
stepUp (FastAlarmHardHoConf)
stepDown (FastAlarmHardHoConf)
Alarm Measurements
blindHhoTimerForFdd (FastAlarmHardHoConf)
blindHhoTimerForGsm (FastAlarmHardHoConf)
Timer
Alarm HHO
Blind HHO
Valid Target Found
10-25
3FL12812AAAAWBZZA Ed2
March 2007
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-25
Alarm HHO Decision: Events 2D & 2F
Alarm Measurement Criteria
NOT HIT
HIT
Event2D
Event2F
CPICH_EC/No
CPICH_RSCP
Event2D
Alarm Measurement Timer
timerAlarmHoEvent
(FullEventHOConfHhoMgt)
entering 2F reporting range
2F absolute threshold
leaving 2F reporting range
leaving 2D reporting range
2D absolute threshold
entering 2D reporting range
Best Cell
QUsed ≤ TUsed2d m H2d / 2
cpichEcNoThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)
cpichRscpThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)
cpichEcNoThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)
cpichRscpThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)
10-26
QUsed ≤ TUsed2f ± H2f / 2
hysteresis (static)
timeToTrigger2D (FullEventRepCritHhoMgtEvent2D)
maxNbReportedCells2D (FullEventRepCritHhoMgtEvent2D)
timeToTrigger2F (FullEventRepCritHhoMgtEvent2F)
maxNbReportedCells2F (FullEventRepCritHhoMgtEvent2F)
3FL12812AAAAWBZZA Ed2
March 2007
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-26
Target Cell Choice
GSMCell C
FDDCell C
FDDCell B
GSMCell B
GSMCell A
FDDCell A
Measurement reports
Measurement reports
Fi
lte
r
GSM Carrier RSSI (Cell i)
>
minimumGsmRssiValueForHO
(RadioAccessService )
CPICH_Ec/No (Cell j)
>
in
g
minimumCpichEcNoValueForHO
(DlUserService)
AND
>
CPICH_RSCP (Cell j)
minimumCpichRscpValueForHO
(DlUserService)
Eligible GSM Cell list
Eq
ua
li
Equalized Measurement
=
Reported Measurement – gsmCellIndivOffset
(GsmNeighbouringCell)
Eligible FDD Cell list
za
tio
n
Equalized Measurement
=
Reported Measurement – neighbouringCellOffset
(UMTSFddNeighbouringCell)
3FL12812AAAAWBZZA Ed2
10-27
March 2007
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-27
3G to 2G Hard Handover
Target Cell Identification
IF
Equalized RSS(i) is the highest of all reported eligible cells
THEN
• Cell(i) is the Target Cell
• Perform 3G to 2G Hard Handover towards Cell(i)
ELSE
IF
No valid measurement report
OR
No eligible cell in measurement report
THEN
Perform GSM Blind Hard Handover (if available)
ELSE
No Handover
Activation
Blind Handover
isAlarmHhoAllowed (RadioAccessService)
isBlindHoRescueAllowed (RadioAccessService)
activationHoGsmAllowed (RadioAccessService)
blindHoGsmNeighbouringTargetCgi (FDDCell)
activationHoGsmPsAllowed (RadioAccessService)
10-28
3FL12812AAAAWBZZA Ed2
March 2007
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-28
3G-3G Hard Handover
Target Cell Identification
IF
Equalized Ec/No(i) is the highest of all reported eligible cells
THEN
• Cell(i) is the Target Cell
• Perform 3G to 3G Hard Handover towards Cell(i)
ELSE
IF
No valid measurement report
OR
No eligible cell in measurement report
THEN
Perform GSM Blind Hard Handover (if available)
ELSE
No Handover
Activation
isAlarmHhoAllowed (RadioAccessService)
Inter-RNC Handover
is3Gto3GWithoutIurAllowedforCS (RadioAccessService)
Intra-RNC Handover
is3Gto3GWithoutIurAllowedforPS (RadioAccessService)
isInterFreqIntraRncHhoWithCModeAllowed (RadioAccessService)
10-29
3FL12812AAAAWBZZA Ed2
March 2007
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-29
Student notes
10-30
Intra-NodeB Blind Hard Handover
10-31
3FL12812AAAAWBZZA Ed2
10-31
March 2007
Twin Cells Definition
RNC
F1
F2
NodeB
RadioAccesService
F1
F1
F2
FDDCell
F2
F1
FrequencyScope
F2
F1
F1
F2
InterFreqHhoFDDCell
F2
twinCellId (InterFreqHhoFDDCell)
F2
F1
F2
F1
isInterFreqHHoAllowed (RadioAccessService)
scope (FrequencyScope)
10-32
3FL12812AAAAWBZZA Ed2
March 2007
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-32
Mobility to Capacity Hard Handover
IF
P-CPICH_EcNo(primary) – P-CPICH_EcNo(second best) ≥ mob2CapDeltaEcNoBorder
AND
P-CPICH Power – P-CPICH_RSCP(primary) ≤ mob2CapPathLossBorder
THEN
Counter is incremented
IF
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)
F1
F1
F2
F2
F1
F2
10-33
3FL12812AAAAWBZZA Ed2
March 2007
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.
-1UE 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.
-2UE 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-33
Capacity to Mobility Hard Handover
IF
P-CPICH_EcNo(primary) – P-CPICH_EcNo(second best) ≤ cap2MobDeltaEcNoBorder
OR
P-CPICH Power – P-CPICH_RSCP(primary) ≥ cap2MobPathLossBorder
THEN
Perform Inter-Frequency towards Twin Cell
ELSE
• Perform Active Set Evaluation
• Perform Primary Cell Election
cap2MobDeltaEcNoBorder (AlarmHardHoConf)
cap2MobPathLossBorder (InterFreqHhoRnc)
F1
F1
F2
F2
F1
F2
10-34
3FL12812AAAAWBZZA Ed2
March 2007
The handover from F2 to F1 is a critical handover and requires ideally interfrequency measurements (and may required compressed mode) for the selection of
target cell.
If Intra-RNC Inter-Frequency Hard Handover is not enabled, only RRC intrafrequency (on F2) measurements are used.
Any of the two following conditions following then triggers such a handover.
-1UE 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).
-2UE 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-34
IMSI-Based Handovers
10-35
3FL12812AAAAWBZZA Ed2
10-35
March 2007
National Roaming Subtree
Shared
Areas
NationalRoaming
PLMN 3G A
Competitive
Area
ImsiPlmnAccessRight
PLMN 3G A
AllowedPlmnId
AllowedPlmnId
PLMN
3G A
PLMN
3G B
AllowedPlmnId
AllowedPlmnId
PLMN
3G As
PLMN
3G Bs
AllowedPlmnId
AllowedPlmnId
PLMN
2G A
PLMN
2G B
AllowedPlmnId
AllowedPlmnId
PLMN 3G Bs
PLMN 3G As
3G A
3G As
3G Bs
ImsiPlmnAccessRight
PLMN 3G B
3G B
2G B
isImsiHoApplicable (NationalRoaming)
imsiHoMobileNetworkCode (NationalRoaming)
imsiHoMobileCountryCode (NationalRoaming)
2G A
mobileNetworkCode (ImsiPlmnAccessRight)
mobileCountryCode (ImsiPlmnAccessRight)
Operator A subscribers
Operator B subscribers
10-36
mobileNetworkCode (AllowedPlmnId)
mobileCountryCode (AllowedPlmnId)
3FL12812AAAAWBZZA Ed2
March 2007
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-36
Student notes
10-37
Student notes
10-38
HSDPA
Section 11
3FL12812AAAAWBZZA Ed2
11-1
March 2007
Objectives
After this section, you will be able to
> Describe HSDPA principles
> Describe HSDPA resource allocation parameters
> Describe HSDPA specific features and associated
parameters
11-2
3FL12812AAAAWBZZA Ed2
11-2
March 2007
Contents
> HSDPA Principles
> HSDPA Resources
> HSDPA Operation
11-3
3FL12812AAAAWBZZA Ed2
11-3
March 2007
Student notes
11-4
HSDPA Principles
11-5
3FL12812AAAAWBZZA Ed2
11-5
March 2007
HSDPA Distributed Architecture
HS-PDSCH
HS-SCCH
Data Transfer (PS I/B)
Downlink Transfer Information
(UEid, OVSF,...)
Introduction of MAC-hs
RNC
Iub
HS-DPCCH
DPCH
Feedback Information
(CQI, ACK/NACK)
Upper Layer Signaling
New Transport channel
HS-DSCH
New Frame Protocols
HS-DSCH
RLC
MAC-d
RLC
MAC-d
MAC-hs
PHY
Uu
UE
11-6
MAC-hs
HS-DSCH
FP
Flow control
PHY
L2
L1
Iub
NodeB
3FL12812AAAAWBZZA Ed2
HS-DSCH
FP
L2
L1
RNC
March 2007
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-6
HSDPA Key Features
RNC
Capacity Request
Control FP
Capacity Allocation
Control FP
Data FP
Flow Control
Dynamically fills the Queues of each UE
Queue IDs
Scheduler
Fills the TTIs with one or more users based on their priority and
feedback information
HARQ Processes
Retransmissions handling, TFRC selection, AMC…
Feedback Reception
11-7
Radio Transmission
3FL12812AAAAWBZZA Ed2
March 2007
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-7
New IN & RadioAccessService MOCs
0..*
RNC
existing MOC
new MOC
1..1
1..1
EM
RadioAccessService
1..5
HsdpaCellClass
1..1
HsDschFlowInformation
1..1
HsdpaRncConf
1..1
HsdpaUserService
1..1
SourceConformanceInformation
11-8
1..1
RncIn
0..3
SpiConfiguration
3FL12812AAAAWBZZA Ed2
1..1
Fc
March 2007
RadioAccessService new MOCs and parameters.
HsdpaCellClass: maximunNumberOfUsers, minimumPowerForHsdpa
numberOfHsPdschCodes, 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-8
New NodeB & BTSEquipment MOCs
0..*
0..3000
RNC
BTSEquipment
0..200
NodeB
1..12
1..1
RadioAccessService
1..6
0..1
1..5
FDDCell
BTSCell
HsdpaCellClass
HsdpaConf
hsdpaCellClassId
1..1
HsdpaResource
existing MOC
new MOC
11-9
3FL12812AAAAWBZZA Ed2
FDDCell new MOC and parameters.
HsdpaResource: hsdpaCellClassId, hsdpaCellClassRef.
BTSEquipment new MOC and parameters.
HsdpaConf: dchPowerMargin, harqNbMaxRetransmissions, harqType,
hsdpaResourceId, hsdschInterval, hsscchPcOffset, maxRateGrowth.
11-9
March 2007
Student notes
11-10
HSDPA Resources
11-11
3FL12812AAAAWBZZA Ed2
11-11
March 2007
Base Station Configuration
UL
HS-DPCCH
DL
HS-PDSCH
HS-SCCH
MAC-hs
• HARQ
• Scheduler
• Link Adaptation (AMC)
BTS
iCEM128
iCEM128
iCEM64
iCEM64
CEMα
α
H-BBU
H-BBU
iTRM
DDM
BTSEquipment
MCPA
DDM
BTSCell
MCPA
DDM
HsdpaConf
H-BBU
D-BBU
H-BBU
iCCM
iTRM
D-BBU
D-BBU
D-BBU
iTRM
DIGITAL SHELF
UL
Associated/R4 DPDCH
Associated/R4 DPCCH
DL
Associated/R4 DPCH
cmCHs
11-12
MCPA
RF BLOCK
hsdpaResourceId (HsdpaConf)
H-BBU
HSDPA dedicated
D-BBU
DCH/cmCH dedicated
3FL12812AAAAWBZZA Ed2
March 2007
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-Lucent
UMTS 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 btsCell
parameter hsdpaResourceActivation is set to TRUE. When used, this parameter
associates a logical HSDPA resource identifier for this cell.
11-12
OVSF Codes Tree Reservation
SF4
HSDPA + R99
SF8
SF16
SF32
...
HS-PDSCH
SF64
...
SF128
...
...
HS-SCCH
SF256
cmCH
RNC
RadioAccessService
numberOfHsPdschCodes (HsdpaCellClass)
numberOfHsScchCodes (HsdpaCellClass)
HsdpaCellClass
11-13
3FL12812AAAAWBZZA Ed2
March 2007
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-13
Power Reservation
BTSEquipment
MCPA
Power
BTSCell
RNC
HsdpaConf
RadioAccessService
SHO
DPCH
dchPowerMargin
(HsdpaConf)
HsdpaCellClass
HS-PDSCH
HS-SCCH
cmCHs
11-14
minimumPowerForHsdpa
(HsdpaCellClass)
3FL12812AAAAWBZZA Ed2
March 2007
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-14
HSDPA RABs
1
RB & SRB Combination
CS/PS
I/B UL:8 DL:[max bit rate for UE categories 12 and 6] PS RAB
PS
UL:3.4 DL 3.4 SRBs for DCCH
2
I/B UL:32 DL:[max bit rate for UE categories 12 and 6] PS RAB
PS
UL:3.4 DL 3.4 SRBs for DCCH
3
I/B UL:64 DL:[max bit rate for UE categories 12 and 6] PS RAB
PS
UL:3.4 DL 3.4 SRBs for DCCH
4
I/B UL:128 DL:[max bit rate for UE categories 12 and 6] PS RAB
PS
UL:3.4 DL 3.4 SRBs for DCCH
5
I/B UL:384 DL:[max bit rate for UE categories 12 and 6] PS RAB
PS
UL:3.4 DL 3.4 SRBs for DCCH
11-15
3FL12812AAAAWBZZA Ed2
March 2007
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-15
Student notes
11-16
HSDPA Operation
11-17
3FL12812AAAAWBZZA Ed2
11-17
March 2007
Activation Flags
RNC Subtree
NodeB Subtree
RNC
BTSEquipment
NodeB
RadioAccessService
BTSCell
FDDCell
HsdpaConf
isHsdpaAllowed (RadioAccessService)
hsdpaResourceActivation (BTSCell)
hsdpaActivation (FDDCell)
11-18
3FL12812AAAAWBZZA Ed2
March 2007
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-18
Traffic Segmentation
RNC
RRC Connection Request
(AS release indicator = R4 or absent)
HSDPA cell
HSDPA cell
RRC Connection Setup
(Redirection to F2)
RRC Connection Setup
(Redirection to F1)
R4 cell
R4 cell
RRC Connection Request
(AS release indicator = R5)
isRedirectionForTrafficSegmentation (InterFreqHhoFddCell)
isRedirectionBasedOnEstablishmentCause (InterFreqHhoFddCell)
11-19
3FL12812AAAAWBZZA Ed2
March 2007
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-19
Call Admission
RNC
RAB Request
Traffic Class = I/B?
NO
YES
hsdpaMaxNumberUser (BTSEquipment )
hsdpaMaxUserPerNodeB (BTSEquipment )
Multi-Service?
YES
NO
RNC
HSDPA UE?
NO
RadioAccessService
YES
HsdpaCellClass
Primary Cell = HSDPA Cell?
NO
YES
maximunNumberOfUsers (HsdpaCellClass )
HSDPA RAB
11-20
R99 RAB
3FL12812AAAAWBZZA Ed2
March 2007
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-20
HARQ Type
Chase Combining
DATA
DATA
NACK
DATA
DATA
NACK
DATA
NACK
NACK
ACK
BTSEquipment
harqType (HsdpaConf)
BTSCell
harqNbMaxRetransmission (HsdpaConf)
Incremental Redundancy Combining
DATA
DATA1
NACK
11-21
HsdpaConf
DATA2
NACK
DATA3
NACK
3FL12812AAAAWBZZA Ed2
DATA4
NACK
ACK
March 2007
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-21
MAC-hs Settings
to MAC-d or MAC-c/sh
MAC-d flows
MAC-hs
Flow Control
Scheduler
Priority Queue
Distribution
Priority
Queue
RNC
Priority Queue
Distribution
Priority
Queue
Priority
Queue
RadioAccessService
Priority
Queue
HsdpaCellClass
HARQ
TFRC Selection
discardTimer (HsdpaUserService)
macHsWindowSize (HsdpaUserService)
timerT1 (HsdpaUserService)
Associated
Downlink Signaling
11-22
HS-DSCH
Associated
Uplink Signaling
3FL12812AAAAWBZZA Ed2
March 2007
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 PDUs
in 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-22
HS-DPCCH Timing
tcell
BFN
SFN
P-CPICH
2 ms
RNC
HS-SCCH#1
RadioAccessService
HS-SCCH#2
2 slots
HsdpaUserService
cqiRepetitionFactor (HsdpaUserService)
ackNackRepetitionFactor (HsdpaUserService)
HS-PDSCH
cqiFeedbackCycle (HsdpaUserService)
HS-DPCCH
ACK
CQI
ACK
CQI
7,5 slots
11-23
3FL12812AAAAWBZZA Ed2
March 2007
The UE monitors all the HS-SCCHs from the set it has been allocated. It despreads
and 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-23
HS-SCCH Power
P-CP
I
CQI
CH
HS-S
CC H
Power Offset
1–7
0 dB
8–9
-3 dB
10 – 12
-5 dB
13 – 30
-8 dB
BTSEquipment
BTSCell
distance
HsdpaConf
HS-SCCH to P-CPICH
Power Offset
hsscchPcOffset (HsdpaConf)
11-24
3FL12812AAAAWBZZA Ed2
March 2007
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-24
HS-DPCCH Power
DPDCH
DPCCH
HS-DPCCH
OVSFd
βd
x
x
OVSFc
βc
x
OVSFhs
x
βhs
x
x
Σ
I
RNC
Modulation
Σ
RadioAccessService
Q
HsdpaUserService
ackPowerOffset (HsdpaUserService)
βhs NACK
cqiPowerOffset (HsdpaUserService)
βhs CQI
βhs ACK
nackPowerOffset (HsdpaUserService)
NACK
βc
CQI
DPCCH
11-25
ACK
3FL12812AAAAWBZZA Ed2
March 2007
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-25
Always On
UL and DL Inactivity
(T2 expiry)
UL and DL Low Usage
(T1 expiry)
CELL_DCH
UL or DL
(DCH/HS(DCH/HS-DSCH)
High Traffic
CELL_FACH
(RACH/FACH)
PMMPMM-idle
UL or DL Traffic
timerT1forHsdpa (AlwaysOnTimer)
timerT2forHsdpa (AlwaysOnTimer)
11-26
3FL12812AAAAWBZZA Ed2
March 2007
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-26
SPI Configuration
RNC
QId0 QId1
QIdN
QId0 QId1
QIdN
RadioAccessService
Second
Stage
HsdpaRncConf
PQ0
PQ15
SpiConfiguration
First
Stage
SpiConfiguration
SpiConfiguration
NodeB Scheduler
UMTS TRAFFIC CLASS
OLS
Background Interactive Streaming
11-27
gold
15
15
15
silver
7
7
7
bronze
0
0
0
3FL12812AAAAWBZZA Ed2
priorityLevel (SpiConfiguration)
backgroundSpi (SpiConfiguration)
interactiveSpi (SpiConfiguration)
streamingSpi (SpiConfiguration)
March 2007
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-27
Iub Bandwidth Limitation
HS-DSCH Flow Control Protocol
HSDPA UE
DL Traffic
RNC
HSDPA UE
Iub link (N E1s)
NodeB
HSDPA UE
EM
iubFlowControlActivation (Fc)
qosBackPressureThreshold (Fc)
RncIn
qosDiscardThreshold (Fc)
Fc
11-28
3FL12812AAAAWBZZA Ed2
March 2007
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-28
Student notes
11-29
Student notes
11-30
Location Based Services
Section 12
3FL12812AAAAWBZZA Ed2
12-1
March 2007
Objectives
After this section, you will be able to
> 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-2
3FL12812AAAAWBZZA Ed2
12-2
March 2007
Contents
> LBS Principles
> Alcatel-Lucent Implementation
> Location Method Selection
> Cell Id Based Location Method
> UE Based AGPS Location Method
12-3
3FL12812AAAAWBZZA Ed2
12-3
March 2007
Student notes
12-4
LBS Principles
12-5
3FL12812AAAAWBZZA Ed2
12-5
March 2007
Location Based Services
Personal
Personal Lifestyles
Lifestyles
Safety
Safety
•• Emergency
Emergency Dispatch
Dispatch (E911)
(E911)
•• Information
Information services
services
•• Child
Child tracking
tracking
•• Traffic
Traffic Information
Information
•• Auto
Auto theft
theft tracking
tracking
•• Direction
Direction Finding
Finding
•• Roadside
Roadside assistance
assistance
•• Entertainment
Entertainment
Copyright © 1996 Northern Telecom
6
Nov 199
from 16 1996
to 15 Dec
Business
Business
Service
Service Providers
Providers
bs
Ed Hob Savart
.
660 N.W ury
Tilb
97330
r
Numbe
ss line
Busine
3
55 378
calls
on Telecom
Copyright © 1996
iptiNorthern
subscr
$23.45
$10.00
$3.00
line
Private
2
55 723
•• Fleet
Fleet Management
Management
•• Location-based
Location-based Billing
Billing
•• Vehicle
Vehicle dispatch
dispatch
•• Location
Location targeted
targeted advertisement
advertisement
•• Rental
Rental car
car tracking
tracking
•• Customer
Customer Service
Service
•• Trucking
Trucking companies
companies
12-6
CC opyright
© 1996 Northern Telecom
op y rig h t ©
1996
N o rth er n
T ele co m
$11.52
Tot al
$33.45
$14.52
$47.97
•• Network
Network performance
performance
3FL12812AAAAWBZZA Ed2
March 2007
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 enabling
technology 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-6
3GPP UE Location Methods
Cell Coverage
OTDOA
d3
d2
Neighbor
Cell # 1
Serving
Cell
∆d2
Neighbor
Cell # 2
∆d3
Assisted GPS
Assis
ta
nc e D
ata
Serving Cell
12-7
3FL12812AAAAWBZZA Ed2
March 2007
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-7
Student notes
12-8
Alcatel-Lucent Implementation
12-9
3FL12812AAAAWBZZA Ed2
12-9
March 2007
Network Architecture for Cell-Id
HLR
/AuC
Uu
(RRC)
3G MSC-VLR
Iub
(NBAP)
Iu
(RANAP)
Lg
(MAP)
12-10
External
LCS Client
Le
(LCAP)
GMLC
SMLC
UE
Lh
(MAP)
VLR
RNC
3FL12812AAAAWBZZA Ed2
March 2007
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-Lucent
implements 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-10
Network Architecture for A-GPS
EGRN
HLR
/AuC
MLC
SAS
Uu
(RRC)
Iu PC
(PCAP)
Iub
(NBAP)
3G MSC-VLR
Iu
(RANAP)
Lg
(MAP)
12-11
External
LCS Client
Le
(LCAP)
GMLC
SMLC
UE
Lh
(MAP)
VLR
RNC
3FL12812AAAAWBZZA Ed2
March 2007
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-11
Student notes
12-12
Location Method Selection
12-13
3FL12812AAAAWBZZA Ed2
12-13
March 2007
Operators Settings
IF
ueBasedAgpsActivationAllowed = FALSE
OR
ueBasedAgpsParamsEnabled = FALSE
A-GPS Global Activation
THEN
Exclude UE Based AGPS method from candidate list
IF
Primary Cell within S-RNS coverage
THEN
IF
isUeBasedAgpsActivationAllowed = FALSE
THEN
A-GPS Local Activation
Exclude UE Based AGPS method from candidate list
ELSE
IF
isUeBasedAgpsAllowed = FALSE
THEN
Exclude UE Based AGPS method from candidate list
ueBasedAgpsActivationAllowed (LocationServices)
ueBasedAgpsParamsEnabled (EmergencyLocationServices)
isUeBasedAgpsActivationAllowed (FDDCell)
isUeBasedAgpsAllowed (NeighbouringRNC)
12-14
3FL12812AAAAWBZZA Ed2
March 2007
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-14
UE and UTRAN Capabilities
IF
SAS Operational State = UNAVAILABLE
THEN
Exclude UE Based AGPS method from candidate list
Network Capabilities
ELSE
IF
UE RRC Connected Mode = CELL_FACH
THEN
Exclude UE Based AGPS method from candidate list
IF
UE Assisted GPS Support = Network Based
OR
UE Assisted GPS Support = None
UE Capabilities
THEN
Exclude UE Based AGPS method from candidate list
IF
Emergency Service Fallback Method
UE Based AGPS method failed
THEN
Use the results of CellId method
emergencyLocationServiceActivationAllowed (EmergencyLocationServices)
12-15
3FL12812AAAAWBZZA Ed2
March 2007
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-15
Student notes
12-16
Cell Id Based Location Method
12-17
3FL12812AAAAWBZZA Ed2
12-17
March 2007
Cell Id Based Location Technologies
Requested Report Area = Service Area
SAI 2
SAI 4
SAI 3
SAI 1
SAI 5
Requested Report Area = Geographical Area
Point With Uncertainty
12-18
Point With Uncertainty
3FL12812AAAAWBZZA Ed2
Polygon
March 2007
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-18
Geographical Provisioned Information
RNC
NodeB
LocationServices
antennaAngleOfOpening (FDDCell)
FDDCell
azimuthAntennaAngle (FDDCell)
cellIdPositioningMethodAccuracy (FDDCell)
serviceAreaCode (FDDCell)
minCellRadius (FDDCell)
CellIdLocationTechnology
cellAccuracyCode (CellIdLocationTechnology)
APP
GAICoord
lattitude (APP)
lattitude (GAICoord)
latitudeSign (APP)
latitudeSign (GAICoord)
longitude (APP)
longitude (GAICoord)
12-19
3FL12812AAAAWBZZA Ed2
March 2007
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-19
UE Position Estimation Elements
IF
Requested Report Area = Geographical Area
THEN
IF
FDDCell controlled by Alcatel-Lucent RNC
THEN
IF
FDDCell controlled by S-RNC
THEN
Report results of UE position computation
ELSE
IF
GAICoord = One Point
THEN
Report Point With Uncertainty =
cellAccuracyCode
ELSE
Report Polygon Shape
ELSE
Report Iur communicated information
ELSE
Report serviceAreaCode
12-20
3FL12812AAAAWBZZA Ed2
March 2007
When UE position computation is performed (FDDCell controlled by Alcatel-Lucent
S-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-20
UTRAN Provisioning Rules
IF
less than 3 valid points defined in GAICoord
THEN
IF
antennaAngleOfOpening = 360
OR
antennaAngleOfOpening = 0
OR
azimuthAntennaAngle = <unset>
OR
minCellRadius = <unset>
THEN
GAICoord provisioned with point = APP
IF
minCellRadius = <unset>
THEN
cellIdPositioningMethodAccuracy provisioned with cellAccuracyCode
ELSE
cellIdPositioningMethodAccuracy provisioned with converted value of minCellRadius
ELSE
GAICoord provisioned with point = f(APP, antennaAngleOfOpening, azimuthAntennaAngle, minCellRadius)
cellIdPositioningMethodAccuracy provisioned with converted value of minCellRadius/2
12-21
3FL12812AAAAWBZZA Ed2
March 2007
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-21
Student notes
12-22
UE Based AGPS Location Method
12-23
3FL12812AAAAWBZZA Ed2
12-23
March 2007
GPS UE Location Technologies
Autonomous GPS
UE
Loc
atio
n
UE-Assisted AGPS
UE-Based AGPS
UE
AGP
S
12-24
GPS
Loc
atio
n
AGP
S
Da t
a
Dat
a
Da t
a
3FL12812AAAAWBZZA Ed2
March 2007
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-24
UE-Based A-GPS Principles
SAS
SRNC
RANAP LOCATION REPORTING CONTROL
RRC MEASUREMENT CONTROL (setup, request one report, UE allowed
to Request additional assistance data, Reference UE Position)
RRC MEASUREMENT REPORT (UE positioning)
raw position estimate (Cell Id)
PCAP Information Exchange
Initiation Request
GPS assistance
data computation
PCAP Information Exchange
Initiation Response
RRC MEASUREMENT CONTROL (setup, no report, Delay tolerant GPS assistance data set #1)
…
RRC MEASUREMENT CONTROL (modify, request one report, Additional
assistance data request not allowed, Delay Sensitive assistance data set)
• A-GPS measurements
• UE position computation
RRC MEASUREMENT REPORT (UE location information)
RANAP LOCATION REPORT
12-25
3FL12812AAAAWBZZA Ed2
March 2007
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-25
UE-Based A-GPS Main Parameters
RNC
LocationServices
emergencyLocationServiceActivationAllowed (LocationServices)
AGPSUeBasedLocationTechnology
ueBasedAgpsActivationAllowed (LocationServices)
maxNbGpsSatellites (AGPSUeBasedLocationTechnology)
tDelayBetweenGpsAssistanceDataSegments (AGPSUeBasedLocationTechnology)
tmaxDurationSensitiveDataAcquisition (AGPSUeBasedLocationTechnology)
tmaxDurationSensitiveDataTransfer (AGPSUeBasedLocationTechnology)
horizontalAccuracyRequestedtoUe (AGPSUeBasedLocationTechnology)
12-26
3FL12812AAAAWBZZA Ed2
March 2007
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-26
Student notes
12-27
Student notes
12-28
Glossary
Section 13
3FL12812AAAAWBZZA Ed2
13-1
March 2007
16-QAM
16-state Quadrature Amplitude Modulation
1xEV-DO
1x EVolution Data Only
1xEV-DV
1x EVolution Data and Voice
1xRTT
1 times 1.25MHz Radio Transmission Technology
3GPP
3rd Generation Partnership Project
3xEV-DV
3x Evolution Data and Voice
AAL2
ATM Adaptation Layer type 2
AAL5
ATM Adaptation Layer type 5
ACK
ACKnowledgment
AICH
Acquisition Indicator CHannel
AM
Acknowledged Mode
AMC
Adaptive Modulation and Coding
AMD
Acknowledged Mode Data
AMR
Adaptive Multi-Rate
ARQ
Automatic Repeat Query
AS
Access Stratum
ASC
Access Service Class
ATM
Asynchronous Transfer Mode
BCCH
Broadcast Control CHannel
BCH
Broadcast CHannel
BER
Bit Error Rate
BFN
NodeB Frame Number
BLER
BLock Error Rate
BMC
Broadcast Multicast Control
BPSK
Binary Phase Shift Keying
BTS
Base Transceiver Station
CAC
Call Admission Control
CC
Chase Combining
CCCH
Common Control CHannel
CCP
Communication Control Port
CCPCH
Common Control Physical CHannel
CCTrCH
Coded Composite Transport CHannel
CDMA
Code Division Multiple Access
13-2
CEM
Channel Element Module
CFN
Connection Frame Number
CID
Channel IDentifier
CK
Ciphering Key
CM
Compressed Mode
CmCH-PI
Common transport CHannel Priority Indicator (SPI)
CP
NodeB Control Port
CP
Control Plane
CPCH
Common Packet CHannel
CPICH
Common PIlot CHannel
CQI
Channel Quality Indicator
CRC
Cyclic Redundancy Check
C-RNC
Controlling-Radio Network Controller
C-RNTI
Cell-Radio Network Temporary Identity
CS
Circuit Switch
CTCH
Common Traffic CHannel
DCCH
Dedicated Control CHannel
DCH
Dedicated CHannel
DL
Downlink
DPCCH
Dedicated Physical Control CHannel
DPCH
Dedicated Physical CHannel
DPDCH
Dedicated Physical Data CHannel
D-RNC
Drift-Radio Network Controller
DS
Delay Sensitive
DS-CDMA
Direct Sequence-Code Division Multiple Access
DSCH
Downlink Shared CHannel
DTCH
Dedicated Traffic CHannel
DTX
Discontinuous Transmission
E1
Standard European PCM link (2.048 Mbps)
EDGE
Enhanced Data for Global Evolution
EGPRS
EDGE GPRS
FACH
Forward Access CHannel
FBI
FeedBack Information
13-3
FDD
Frequency Division Duplex
FDMA
Frequency Division Multiple Access
FIFO
First In First Out
FP
Frame Protocol
GMM
Global Mobility Management
GPRS
General Packet Radio Service
GSM
Global System for Mobile communications
GTP
GPRS Tunneling Protocol
H-ARQ
Hybrid ARQ
HFN
Hyper Frame Number
HO
HandOver
H-RNTI
HS-DSCH Radio Network Temporary Identifier
HSDPA
High Speed Downlink Packet Access
HS-DPCCH
High Speed Dedicated Physical Control CHannel
HS-DSCH
High Speed Downlink Shared CHannel
HS-PDSCH
High Speed Physical Downlink Shared CHannel
HS-SCCH
High Speed Shared Control CHannel
IE
Information Element
IK
Integrity Key
IMA
Inverse Multiplexing ATM
IMEI
International Mobile Equipment Identity
IMSI
International Mobile Subscriber Identity
IMT-2000
International Mobile Telecommunication for year 2000
IP
Internet Protocol
IR
Incremental Redundancy
Iu
Interconnection point between RNC and 3G Core
Network
Iub
Interface between NodeB and RNC
Iur
Interface between two RNCs
Kbps
Kilobit per second
kHz
kiloHertz
KPI
Key Performance Indicator
Ksps
Kilo symbol per second
L1
Layer 1 (Physical Layer)
13-4
L2
Layer 2 (Data Link Layer)
L3
Layer 3 (Network Layer)
LA
Location Area
LAC
Location Area Code
LAI
Location Area Identity
LAN
Local Area Network
LSB
Least Significant Bit
MAC
Medium Access Control
Mbps
Megabit per second
MCC
Mobile Country Code
MCPA
Multi Carrier Power Amplifier
Mcps
Megachip per second
MHz
MegaHertz
MIR
Mix Incremental Redundancy
MM
Mobility Management
MNC
Mobile Network Code
MOC
Managed Object Class
MOI
Managed Object Instance
MOS
Mean Opinion Score
MSB
Most Significant Bit
NACK
Negative ACKnowledgement
NAS
Non Access Stratum
NBAP
NodeB Application Part
NDI
New Data Indicator
NDS
Non-Delay Sensitive
NodeB
Logical node responsible for radio Tx/Rx to/from UE
NRZ
Non Return to Zero
OAM
Operation Administration and Maintenance
OVSF
Orthogonal Variable Spreading Factor
PA
Power Amplifier
PCCH
Paging Control CHannel
P-CCPCH
Primary-Common Control Physical CHannel
PCH
Paging CHannel
13-5
PCM
Pulse Code Modulation
PCPCH
Physical Common Control CHannel
PDP
Packet Data Protocol
PDU
Protocol Data Unit
PDU
Protocol Data Unit
PI
Paging Indicator
PI
Priority Indicator
PICH
Paging Indicator CHannel
PIR
Partial Incremental Redundancy
PLMN
Public Land Mobile Network
PMM
Packet Mobility Management
PN
Pseudo Noise
PQ
Priority Queue
PRACH
Physical Random Access CHannel
PS
Packet Switch
P-SCH
Primary-Synchronization CHannel
PSK
Phase Shift Keying
QId
Queue Identity
QoS
Quality of Service
QPSK
Quadrature Phase Shift Keying
R4
Release 4
R5
Release 5
RA
Routing Area
RAB
Radio Access Bearer
RAC
Routing Area Code
RACH
Random Access CHannel
RAN
Radio Access Network
RANAP
Radio Access Network Application Part
RB
Radio Bearer
RF
Radio Frequency
RL
Radio Link
RLC
Radio Link Control
RM
Rate Matching
13-6
RNC
Radio Network Controller
RNS
Radio network subsystem
RNSAP
Radio Network Subsystem Application Part
RNTI
Radio Network Temporary Identity
RRC
Radio Resource Control
RRM
Radio Resource Management
RTT
Radio Transmission Technology
RV
Redundancy Version
RX
Receiver / Reception
SA
Service Area
SAP
Service Access Point
SAW
Stop And Wait
S-CCPCH
Secondary-Common Control Physical CHannel
SCH
Synchronization CHannel
SCR
Sustainable Cell Rate
SDU
Service Data Unit
SF
Spreading Factor
SFN
System Frame Number
SHO
Soft HandOver
SIM
Subscriber Identity Module
SIR
Signal to Interference Ratio
SM
Session Management
SNR
Signal to Noise Ratio
SPI
Scheduling Priority Indicator (CmCH-PI)
SRLR
Synchronous Radio Link Reconfiguration
S-RNC
Serving-Radio Network Controller
S-SCH
Secondary-Synchronization CHannel
STTD
Space Time Transmit Diversity
TAF
That's All Folks!
TB
Transport Block
TBS
Transport Block Size
TCP
Transmission Control Protocol
TDD
Time Division Duplex
13-7
TDM
Time Division Multiplexing
TDMA
Time Division Multiple Access
TF
Transport Format
TFC
Transport Format Combination
TFCI
Transport Format Combination Indicator
TFI
Transport Format Indicator
TFO
Tandem Free Operation
TFRC
Transport Format and Resource Combination
TFRI
Transport Format and Resource Indicator
TFS
Transport Format Set
TPC
Transmit Power Control
TrCH
Transport CHannel
TrFO
Transcoder Free Operation
TS
Time Slot
TTI
Transmission Time Interval
TX
Transmitter / Transmission
UARFCN
UMTS Absolute Radio Frequency Channel Number
UDP
User Datagram Protocol
UE
User Equipment
UM
Unacknowledged Mode
UMTS
Universal Mobile Telecommunication System
UP
User Plane
URA
UTRAN Registration Area
U-RNTI
UTRAN-Radio Network Temporary Identity
UTRAN
Universal Terrestrial Radio Access Network
Uu
the radio interface between UTRAN and UE
VCC
Virtual Channel Connection
VoIP
Voice over IP
W-CDMA
Wideband-CDMA
13-8
Student notes
13-9
Student notes
13-10