01 - RN33211EN40GLA1 - RU40 Release Hands-On Workshop PDF

RN3321-40A
RU40 Release Hands-on Workshop

(Practical)
For public use IPR applies

1 Nokia Siemens Networks RN33211EN40GLA1
Nokia Siemens Networks Academy
Legal notice
Intellectual Property Rights

All copyrights and intellectual property rights for Nokia Siemens Networks training
documentation, product documentation and slide presentation material, all of which are forthwith
known as Nokia Siemens Networks training material, are the exclusive property of Nokia
Siemens Networks. Nokia Siemens Networks owns the rights to copying, modification,
translation, adaptation or derivatives including any improvements or developments. Nokia
Siemens Networks has the sole right to copy, distribute, amend, modify, develop, license,
sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individuals
can use the Nokia Siemens Networks training material for their own personal self-development
only, those same individuals cannot subsequently pass on that same Intellectual Property to
others without the prior written agreement of Nokia Siemens Networks. The Nokia Siemens
Networks training material cannot be used outside of an agreed Nokia Siemens Networks
training session for development of groups without the prior written agreement of Nokia
Siemens Networks.

Objectives
After completing this training the participant shall be able to:
- Describe, Activate and test selected RU40 features

RU40 Voice and Data Features
RAN2135 Layering in RRC connection release ***
RAN2124 HSPA 128 Users per cell
RAN1645 - HSUPA 16QAM
RAN971 HSUPA DL Physical channel power control ***
RAN1913 High speed Cell_FACH (UL) ***
RAN2451 Fast Dormany profiling ***
RAN1910 Flexible RLC in UL
RAN1908 UE_DRX in Cell_FACH ***
RAN2302 Dynamic HSUPA BLEr ***
RAN2494 Fast Cell_PCH Switching ***
RAN2509 Application Aware RAN ***
RAN2179 Dual Band HSDPA 42Mbps
RAN 1907 - Dual Cell HSDPA with MiMo 84Mbps
RAN2435 - SRVCC from LTE and CSFB with HO
RAN2717 - Smart LTE Layering

RU40 O&M, Performance Management and
Servicebility Features
RAN1877 End-user experienced DL Throughput

RAN2526 - 1 Hour RNC Release Software Upgrade
RAN2539 - OMS RNC Connectivity Increase
RAN2446 - Emergency Symptom Data Collection for IPA-RNC
RAN1805 Event Triggered Symptom Data Collection for IPA-RNC

RU40 Transmission and Transport Feature
RAN2296 Transport sub-Module "FTIF" Eth+E1/Ta/JT1 for

FSM3 outdoor

RU40 BTS and Site Solution Features
RAN2117 RNC2600 Co-Sitting with Multicontroller RNC

RAN2240 mcRNC Flexible Dimensioning up to 50Gbps HW Release 2
RAN2262 Flexi Multiradio System Modules, FSMF and FBBA extension module
RAN2317 240W Multiradio remote RF
RAN2429 Flexi 3-sector RF Module 2100 80W FXDB (RU30 EP2 on top)
RAN2157 Flexi Lite BTS 2100 ***
RRH FHDB 60W+60W
RAN2489 - Carrier Bandwidth 3.8MHz
RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices
RAN2591 Selective BTS Resource Re-Balancing in mcRNC

RU40 Voice and Data Features

RAN2135
Layering in RRC Connection Release

RAN2135 - Layering in RRC Connection Release
Brief description
Allows the operator to define the preferred idle mode layer in RRC
connection release, in order to push the UE to this layer.
RNC triggers layering in order to direct a UE to other WCDMA layer.

This is done during RRC Connection Release
Layering is supported from common and dedicated channels

(trasitions from Cell_DCH, Cell_FACH, Cell/URA_PCH)
Layering decision takes into account UE band capability

Used service does not affect the layering decision

RAN2135 - Layering in RRC Connection Release,
cont.
Summary:
Feature RAN2135: Layering in RRC Connection Release allows the operator to define the preferred idle mode
layer in RRC connection release, in order to push the UE to this layer.
Benefits:
End-user benefits
The end user benefits from an enhanced application experience because of the distributed RRC connection
setup load.
Operator benefits
Without this feature the UE easily camps on a layer with better coverage, such as lower frequency band, for
example, 900 MHz. This could cause an excessive number of RRC connection setup requests on the layer.
The feature RAN2135: Layering in RRC Connection Release can push the UE in idle mode to a preferred
layer, for example, 2100 MHz, so that the RRC connection setup request that happens after is performed on
the preferred layer.)
The operator is able to control the UEs idle mode camping routines idle mode UEs are distributed
across different WCDMA carriers.
If data or voice connections are needed, requests are sent on different layers - this helps to avoid high
load states in particular cells
End-user experience can also be improved due to better resource utilization (PLMN level)
Only supported inside WCDMA
Impacts on system performance and capacity
RRC connection setup load can be distributed to desired frequencies .

Benefits
UEs easily camp on due to better coverage
The operator is able to control the UEs idle mode camping routines
Idle mode UEs are distributed across different WCDMA carriers.
For data or voice connections, requests are sent on different layers -
this helps to avoid high load states in particular cells
End-user experience can also be improved
Only supported inside WCDMA
*If the UE is in state CELL_PCH or URA_PCH, the RNC must first page
it to state CELL_FACH before releasing the RRC connection.

Target UARFCN is given to

the UE within this RRC
message
UE goes to Idle Mode and

camps on this WCDMA layer
If layer change is triggered, the new frequency info is included to

RRC Connection release message
Rel6 and later UEs can read this frequency information
It is expected that UE goes to one of the frequency given to it
in Redirection info IE after receiving RRC Connection Release
and stays there in idle mode if the coverage is good enough.
Define other cell reselection parameters so that ping-pong is
avoided.

cont.
Functional description
The RAN2135: Layering in RRC Connection Release feature introduces the connected-mode
mechanism that pushes the UE to perform idle-mode camping on a particular carrier. Idle-mode
camping is controlled with the cell reselection parameters. During the RRC connection release
procedure, the RNC triggers the RAN2135: Layering in RRC Connection Release feature if the
UE needs to be directed to another layer after the RRC connection is released for this UE.
The preferred layer (frequency) is defined by the operator with the cell-level parameter in order
to push the UE to this preferred idle mode layer. The preferred layer could be another band, or
another carrier within the same band.
The RNC sends the information on the preferred frequency to the UE in the Redirection info
Information Element (IE) included in the RRC CONNECTION RELEASE message. This IE
includes the UARFCN downlink (Nd) IE that points out the frequency with which the UE
attempts to camp. After receiving this message, the UE goes to the frequency given to it and
stays on this frequency in idle mode if the coverage is good enough. The possible RRC
connection setup request that happens after is performed on the same layer. This process is
illustrated in Figure 17 Layering in RRC connection release. If the coverage is not good enough,
the UE changes the layer.
Before sending the RRC CONNECTION RELEASE message, the RRC entity in the RNC
checks if the conditions for moving the UE to another layer are satisfied. The UE can be on the
dedicated or common channel. Both channels are supported by the feature. The UE is directed
to another FDD UMTS frequency layer if the following conditions are met:

There are no means of redirecting UEs to a specific frequency layer during RRC
connection releasing
UEs go to Idle Mode, camps on a frequency layer with better coverage which has
served terminated voice or data call and follow standard cell reselection
procedures.
No UARFCN Target Info is given to UE when releasing RRC connection
RAN2135
Not activated

It is possible to distribute Idle Mode UEs across different frequency layers using
Frequency Info IE included in RRC Connection Release message
All frequency layers are loaded evenly with Idle Mode UEs - this avoids
excessive number of RRC Connection Setup requests on particular layer
UE is ordered to camp on a specific frequency layer (UARFCN)
RAN2135
Activated

New Parameters:
Parameter Object Range Default Description
Disabled (0), Defines whether the layering in RRC Connection Release is enabled
LayeringRRCRelEnabled WCEL Disabled (0)
Enabled (1) in the cell.
This parameter structure defines the possible target frequencies for
Structure
LayeringRRCConnRelTargFreq WCEL layering in RRC connection release. Up to 8 different frequencies can
parameter
be defined.
This parameter defines the target frequency for layering in RRC
connection release. The frequencies are given in UTRA Absolute
Radio Frequency Channel Number (UARFCN) format, which defines
0...16383,
TargetFrequency WCEL 0 the downlink channel number and the downlink carrier frequency.
step 1
Default value 0 means that UE is not directed to other frequency in
RRC Connection Release due to Layering in RRC connection
Release.
New Counter:
Counter ID Name
M1006C269 RRC Connection Release WCDMA Redirection
License:
Long-term ON/OFF


cont.
A restart of the RNC and the BTS is not required after the activation of this feature.
This procedure does not cause downtime and the feature can be activated at any
time of the day.
Make sure you have access to the following applications:
OMS Element Manager
Application Launcher
Man-machine interface (MMI)
The feature code for this feature is 3898.
To set the feature state to ON, use the following command:

for IPA-RNC:
ZW7M:FEA=3898:ON;
for mcRNC:
set license feature-mgmt id 0000003898 feature-admin-state on
In Flexi Direct RNC there is no need to configure the license
RAN2124
HSPA 128 Users per cell

RAN2124 - HSPA 128 Users per cell
With this feature 128 simultaneous HSPA serving users (HSDPA and HSUPA) per
cell are supported.
Maximum number of HSPA end users in

the CELL_DCH* state is increased up to UTRAN Connected Mode
128
CELL_PCH URA_PCH
Instant access to data services for more
HSPA users per cell is provided
Quality of experience (QoE) for more
HSPA end users is increased CELL_DCH CELL_FACH
Number of users in other states

remain unchanged
Non-serving HSUPA users per cell limit is Idle mode
removed and just serving HSUPA users
are taken into account, however the BTS
is limiting this amount RRC states and state transitions

RAN2124 - HSPA 128 Users per cell, cont.
Max no. of active users in HS CELL_FACH per cell 12

Max no. of active users in HS CELL_FACH per BTS 192
Max no. of inactive users in HS CELL_FACH per cell 600
Max no. of users in HS CELL_FACH per cell 1024
inactive
CELL_DCH (transmission of bigger messages, dedicated channel resources);
CELL_DCH is the only RRC state which allows UE to establish soft and softer handover
connections. Both dedicated channels and HSUPA support soft and softer handover. The use
of soft handover helps to improve air-interface performance towards the cell edge
If the paging message was for a CS service then the UE will be moved into CELL_DCH. The
UE may also be moved to CELL_DCH for PS services, depending upon the quantity of data to
transfer.
CELL_FACH (the UE monitors a forward access channel (FACH));
CELL_PCH (the UE listens to the PCH transport channel);
URA_PCH (the location of the UE is known on the UTRAN registration area (URA) level)
NRT users are wanted to be kept as long as possible in CELL_DCH state even if they have no
data to be transferred
64 UEs
(19 HSUPA) 64 UEs
RU10: The maximum number (19 HSUPA)
of users per cell is 64 for
HSDPA and 19 for HSUPA. 64 UEs
The limit of E-RGCH/E-HICH (19 HSUPA) Serving and
non-serving
RAN2124
codes is equal to 1
Not activated
HSUPA users
72 UEs are taken for
RU20: The maximum number 72 UEs the limit
of HSPA users per cell is 72
(both HSUPA and HSDPA). 72 UEs
The limit of E-RGCH/E-HICH
codes is increased to 4
The maximum number of 128 UEs

RAN 2124
HSPA users per cell is 128 128 UEs Serving HSUPA

Activated
(both HSUPA and HSDPA). users only are

The limit of E-RGCH/E-HICH 128 UEs
taken for the
codes is removed and
limit
depends on the BTS

Number of HSPA users will in general increased numbers of

control channels.
RAN1686 has introduced the requirements for the dynamical
handling of increased numbers of HS-SCCH and E-RGCH/E-
HICH. As well as for flexible allocation of DL code space.
RAN2124 feature requires extending of the implemented
mechanisms for higher user counts.

E-DCH BTS of the active set
Without feature HSPA 128 Users per Cell the
(non-serving BTS) UE is taken for the limit in the cell A and B
E-DCH/ HS-DSCH
(serving BTS)
DCH BTS of the active set

(non-serving BTS)
UE
B
C With this feature the UE is taken

for the users limit in the cell B only

This feature increases the number of serving HSPA (HSDPA and HSUPA) users per
cell in CELL_DCH state to 128. It mainly deals with the BaseBand capacity
enhancements brought with the new HW and SW. The BTS provides resources and
handles the increased number of users, while the RNC takes care of enhanced
admission and overload control.
Maximum number of E-HICH/E-RGCH codes is increased accordingly. Note that
completely inactive users are released by the RNC even before the limit of users is
reached when the noise rise is high for a given period.
The RAN1686: HSPA 72 Users per Cell feature has introduced the requirements for
the dynamic handling of increased numbers of HS-SCCH and E-RGCH / E-HICH, as
well as for flexible allocation of DL code space. This feature requires extending of the
implemented mechanisms for higher user counts.
For the UL, only serving users are counted and checked, but the number of non-
serving E-DCH users is limited, according to the maximum amount of E-HICH/E-
RGCH codes. The maximum number of HS-DSCH MAC-d flows is 1024 per one cell.

RAN1686: HSPA 72 Users per Cell
RAN1644 - Continuous Packet Connectivity Recommended
RAN1201 - Fractional DPCH features to achieve
- Note: It is required for the CS Voice over HSPA feature maximum number
RAN971 - HSUPA Downlink Physical Channel Power Control of HSPA users
RAN1308 - HSUPA Interference Cancellation Receiver
- Beneficial for the feature Optional
RAN1913 - High Speed CELL_FACH Enhancements
- Note: CS Voice over HSPA is not possible in the CELL_FACH state
RAN2124
HSPA 128 Users
per Cell
RAN1308
RAN971
RAN1201 RAN1913
RAN1644 RAN1686

Interdependencies between features

This feature requires the following features up and running:
RAN971: HSUPA Downlink Physical Channel Power Control
RAN1201: Fractional DPCH (recommended for air interface capacity reasons)
RAN1644: Continuous Packet Connectivity (recommended for air interface capacity reasons)
RAN1686: HSPA 72 Users per Cell
Optional Enhancements
RAN1308 - HSUPA Interference Cancellation Receiver
RAN1913 - High Speed CELL_FACH
This feature impacts interfaces as follows:
Uu:
higher number of HSPA UEs/Cell - load and interference issues, higher ranges of UE
identifiers like E-RNTI and H-RNTI
This feature impacts system performance and capacity as follows:
Number of HSPA users per cell is increased from 72 to 128.

Hardware requirements:
RAN2382 Flexi BTS Multimode System Module FSMC, or
RAN1016 Flexi BTS Multimode System Module FSMD, or
RAN1848 Flexi BTS Multimode System Module FSME, or
RAN2262 Flexi BTS Multiradio System Module FSMF, or
RAN2157 Flexi Lite BTS 2100
RAN2124 RAN2157
HSPA 128 Users Flexi Lite BTS
per Cell 2100
RAN2382 RAN1016 RAN1848 RAN2262

Flexi BTS Flexi BTS Flexi BTS Flexi BTS
Multimode System Multimode System Multimode System Multiradio System
Module FSMC Module FSMD Module FSME Module FSMF

Network Design Impact of HSPA 128 Users per Cell
HSPA 128 Users

per Cell
Carrier capacity Downlink spreading

usage code tree occupation
More capacity is Better BTS

remaining for the spreading code
DCH transmission tree usage

Network design impact:

Air Interface aspects:
- Possible Higher number of HSPA active UEs per cell from
72 to 128
- Significant gains in downlink spreading code tree
occupation
- More available E-HICH/E-RGCH codes reservations
Baseband aspects:
- HSPA schedulers admit up to 128 users per cell

New Parameters:
Managed
Abbreviated name Full name
object
HSPA128UsersPerCell HSPA 128 Users Per Cell WCEL
ULLoadStateTTT UL loaded state time to trigger RNPS
ULLoadStateHSUOffset UL loaded state for HSPA users offset WCEL
ULLoadStateHSUBRLimit UL loaded state for HSPA users bit rate limit WCEL
Modified Parameters:
Managed
Abbreviated name Full name object
MaxNumberHSDSCHMACdFlows Maximum number of HS-DSCH MAC-d flows WCEL
MaxNumberHSDPAUsers Maximum number of HSDPA users WCEL
MaxNumbHSDSCHMACdFS Max number HSDSCH MACd flows per MAChs/ehs scheduler WCEL
MaxNumbHSDPAUsersS Max number HSDPA users per MAChs/ehs scheduler WCEL
MaxNumberEDCHCell Maximum number of E-DCHs in the cell WCEL
MaxNumberEDCHLCG Maximum number of E-DCHs in the local cell group WBTS
NumberEDCHReservedSHOBranchAdditions Number of E-DCHs reserved for SHO branch additions WCEL
RsrvdSignaturesOffset Reserved E-RGCH and E-HICH signatures per cell WCEL
HSPDSCHMarginSF128 HS-PDSCH code upgrade margin for SF128 codes WCEL
HSDPA48UsersEnabled HSDPA 48 users enabled RNFC
HSDPA64UsersEnabled HSDPA 64 users enabled WCEL
HSPA72UsersPerCell HSPA 72 Users per Cell WCEL
HSUPAXUsersEnabled HSUPA x users enabled WBTS
InacUsersOverloadFact Inactive users overload preventive factor RNHSPA
RncOptions RNC Options RNC

If this feature is not enabled, the RNC allows only 16, 48, 64 or 72 HSDPA users per cell and
only 3, 12, 60 users per BTS or LCG or 72 HSUPA users per cell
HSPA128UsersPerCell:
This parameter determines whether the HSPA 128 Users per Cell feature is enabled in the cell
or not. If this feature is enabled, a maximum of 128 users with HS-DSCH in downlink and 128
users with E-DCH in uplink can be admitted per cell; Disabled (0), Enabled (1); Default = 0.
ULLoadStateTTT:
This parameter defines time to trigger value to activate and deactivate UL loaded state (UL
loaded state for HSPA users) and HSPA load state; Range 0..10 s, step 0.5 s; default= 2 s.
ULLoadStateHSUOffset:
This parameter defines an offset related to the maximum received target power. The sum of
this offset and target power is used to trigger the UL loaded state for the purposes of HSPA
users checking; Range -3..3 dB, step 0.1 dB; Default = -0.5 dB.
ULLoadStateHSUBRLimit:
This parameter defines user based bit rate limit for NRT services mapped to E-DCH that must
be exceeded so that UL loaded state for HSPA users is not triggered. If bit rate per user is
under this limit, then UL loaded state for HSPA users is triggered if load of UL is high enough;
Range 0..128 kbps, step 1 kbps; Default = 8 kbps

ULLoadStateHSUOffset
PrxTotal
PrxNoise + Offset
PrxMaxTargetBTS
time
ULLoadStateTTT start ULLoadState activated ULLoadState released

ULLoadState not activated

UL load state for HSPA users is triggered by high UL load

When a cell in UL load state for HSPA users, then the following
preventive actions take place:
New users with extended inactivity timer running are not allowed
The cell is set to UL loaded state if level of PrxTotal is higher than the
following sum of parameters for at least time defined by
ULLoadStateTTT:
PrxNoise + PrxMaxTargetBTS + ULLoadStateHSUOffset
If the condition is not fulfilled for at least time indicated by the

management parameter ULLoadStateTTT then the UL loaded state is
canceled
New management ULLoadStateHSUBRLimit parameter defines user
based bit rate limit for NRT services mapped to E-DCH that must be
exceeded so that UL loaded state for HSPA users is not triggered

Before the HSPA 128 Users per Cell feature there were no counters to analyze the
activity of over 72 HSPA users per cell, therefore the following new counters are
introduced with the HSPA 128 Users per Cell feature:
M1000C384 - DURA_HSUPA_USERS_73_TO_80
M1000C387 - DURA_HSUPA_USERS_113_OR_MORE
M1000C388 - MAX_HSUPA_USERS_IN_SERV_CELL
M1000C389 - SUM_HSUPA_USERS_IN_SERV_CELL
M1000C390 - DURA_HSDPA_USERS_73_TO_80
M1000C393 - DURA_HSUPA_USERS_113_OR_MORE
M5000C415 - HSDPA_USERS_ONE_TTI
M5000C416 - HSDPA_USERS_TWO_TTI
M5000C417 - HSDPA_USERS_THREE_TTI
M5000C418 - HSDPA_USERS_FOUR_TTI

M1000C384 - DURA_HSUPA_USERS_73_TO_80:
The counter indicates the amount of time that 73 to 80 active HSUPA users are simultaneously allocated
during the measurement period. Sampling interval is equal to 1s
M1000C387 - DURA_HSUPA_USERS_113_OR_MORE:
The counter indicates the amount of time that 113 or more active HSUPA users are simultaneously
allocated during the measurement period. Sampling interval is equal to 1s
M1000C388 - MAX_HSUPA_USERS_IN_SERV_CELL:
The maximum number of simultaneous HSUPA users in serving E-DCH cell. The number of HSUPA users
is sampled with defined time interval. Sampling interval is equal to 1s
M1000C389 - SUM_HSUPA_USERS_IN_SERV_CELL:
The sum of sampled values for measuring the number of simultaneous HSUPA users in serving E-DCH
cell. The counter, provides the average number of HSUPA users (E-DCH allocations) in the serving E-DCH
cell. Sampling interval is equal to 1s
The counter indicates the amount of time that 73 to 80 active HSDPA users are simultaneously allocated
Example: Number of Active Serving HSUPA Users

during the measurement period. Sampling interval is equal to 1s.
M1000C393 - DURA_HSDPA_USERS_113_OR_MORE
The counter indicates the amount of time that 113 or more active HSDPA users are simultaneously
allocated during the measurement period. Sampling interval is equal to 1s
M5000C415 - HSDPA_USERS_ONE_TTI
The number of one per TTI scheduled HSDPA users in WCELL
Incremented for every TTI for which there is data in the HSDPA user buffers and the data (MAC-hs PDU) is
scheduled to be send to one user
M5000C416 - HSDPA_USERS_TWO_TTI
The number of two simultaneously scheduled HSDPA users per TTI in WCELL
scheduled to be send to two users
M5000C417 - HSDPA_USERS_THREE_TTI
scheduled to be send to three users.
M5000C418 - HSDPA_USERS_FOUR_TTI
scheduled to be send to four users.
Licensing:
RNC level License Key: HSPA 128 Users per Cell

Long-term capacity license
Number of BTS
Controlled on the cell level
HSPA 128 Users per Cell use together with RAN1644 CPC is controlled by the License Key:
CPC for 128 Users LK
RAN2124 HSPA 128 Users per Cell is ASW feature and it is controlled by the RNC level LK HSPA 128 Users per Cell with the
following requirements:
License control attribute: Long-term capacity license
License capacity info: Number of BTS
The use of the feature is controlled on the cell level
The use of RAN2124 HSPA 128 Users per Cell together with RAN1644 CPC feature is controlled by the CPC for 128 Users LK

Activation Aspects:
State of the HSPA 128 Users per Cell license is On

HSPA128UsersPerCell parameter must be set to Enabled
HSPA72UsersPerCell parameter must be set to Enabled
HSDPAenabled and HSUPAEnabled parameters must be set to Enabled
If the CPC is enabled then the CPC for 128 HSPA Users LK must be On
Parameters related with number of supported HSPA users per cell, BTS or LCG
should be adjusted
To achieve the maximum number of HSPA users:

F-DPCH and CPC are recommended in RNC
HSUPA Downlink Physical Channel Power Control in BTS

The following conditions have to be fulfilled to apply RAN2124 in a cell:

State of the HSPA 128 Users per Cell license is On
The HSPA128UsersPerCell activation parameter is set to value Enabled
The HSPA 72 Users per Cell feature is enabled in the cell using HSPA72UsersPerCell
HSDPA and HSUPA features are enabled using HSDPAenabled and HSUPAEnabled
If the CPC is enabled then the CPC for 128 HSPA Users LK must be On
To increase the number of supported HSPA users per cell, BTS or LCG the range of related
management parameters should be increased if necessary it might include:
WCEL MaxNumberEDCHCell
WBTS MaxNumberEDCHLCG
WCEL MaxNumberHSDSCHMACdFlows
WCEL MaxNumberHSDPAUsers
WCEL MaxNumbHSDPAUsersS
WCEL MaxNumbHSDSCHMACdFS
These parameters by default do not provide any restrictions
To achieve maximum number of HSPA users F-DPCH and CPC are recommended in RNC
and HSUPA Downlink Physical Channel Power Control in BTS


Restart of the RNC and the WBTS is not required after activation of this feature.
This procedure requires cell locking.
Make sure you have access to the following applications:
OMS Element Manager
Application Launcher
for IPA-RNC
ZW7M:FEA=1796:ON;
for mcRNC
set license feature-mgmt code 0000001796 feature-admin-state on
RAN 2124: HSPA 128 Users per Cell feature needs the following features to be activated before it can be
enabled:
HSDPA
HSUPA
RAN1686: HSPA 72 Users per cell
To achieve the maximum number of HSPA users it is recommended to have the following features activated:
in RNC:
RAN1201: Fractional DPCH
RAN1644: Continuous Packet Connectivity (to use RAN1644 simultaneously with RAN2124, CPC for
128 HSPA Users license key must be set to ON)
in BTS:
RAN971: HSUPA Downlink Physical Channel Power Control
Release Information
WCDMA Release RU40
Flexi Direct Flexi Direct Rel5
RNC Release RN7.0
mcRNC Release mcRNC3.0
BTS (Flexi) WBTS8.0
NetAct OSS5.4 CD set 3
HW Requirements RAN2382, or
RAN1016, or
RAN1848, or
RAN2262, or
RAN2157
UE Release 3GPP Rel-5
Common O&M Platform Feature No
BSW/ASW ASW
RAS SW Component RAN
License Control Long-term ON/OFF
License Control in Network Element RNC LK

RAN1645
HSUPA 16QAM

Enables 11.5Mbps peak UL data rate by sending four bits per symbol
instead of two
HSUPA 16QAM = 11Mbps

0110 1111 1001 1001 0101
Q Q
1011 1001 0001 0011
10 00
1010 1000 0000 0010
I 1110 1100 0100 0110
I
11 01
1111 1101 0101 0111
QPSK 2 bits/symbol 16 QAM 4 bits/symbol

RAN1645 - HSUPA 16QAM, cont.
GPP Rel-7 introduces 16QAM modulation for HSUPA in addition

to QPSK modulation
16QAM modulation is supported by HSUPA terminal category 7
HSUPA peak data rate is increased from 5.8Mbps to 11.5 Mbps
HSUPA 16QAM is an optional feature for UEs
16QAM capability is signaled to the RNC by the UE in the RRC
connection setup message
Throughput can be limited by radio channel conditions,
interference level, allowed noise rise, and both receiver and
transmitter imperfections
QPSK symbols carry two bits of information while 16QAM symbols carry
four bits of information allowing a higher peak rate at the cost of a
reduction of the Euclidian distance between adjacent symbols
A good SNR (signal-to-noise ratio) is required to achieve the same BER
(bit error rate)
This feature requires the following features:

RAN981: HSUPA 5.8 Mbps
RAN1016: Flexi BTS Multimode System Module - FSMD
RAN1848: Flexi BTS Multimode System Module - FSME
RAN1226: HSPA Peak Rate Upgrade for RNC196 and RNC450
RAN1470: HSUPA 2ms TTI
RAN1702: Frequency Domain Equalizer
RAN2261: Flexible User Plane Capacity in RNC196 and RNC450
RAN1645
HSUPA 16QAM
RAN1226
RNC196/450 RAN981 RAN1470 RAN1702 RAN1016/1848
HSPA Peak HSUPA HSUPA 2ms Frequency Multimode SM
Rate Upgrade 5.8Mbps TTI Domain FSMD/FSME
Equalizer

Counters:
Counter ID Counter name Measurement
M5000C359 SUM OF ACTIVE 16QAM UL USERS M5000 HSPA in WBTS
M5000C360 SUM OF CORRECTLY RECEIVED MAC-E PDUs WITH 16QAM UL M5000 HSPA in WBTS
M5000C361 SUM OF INCORRECTLY RECEIVED MAC-E PDUs WITH 16QAM UL M5000 HSPA in WBTS

Max. data rate (Mbps)

Highest
Code configuration
E-DCH category 3GPP Release order
for Max. data rate
modulation 10 ms E-DCH TTI 2 ms E-DCH TTI
Category 1 1 x SF4 0.7 Not supported
Category 2 2 x SF4 1.4 1.4

Rel 6 QPSK
Category 4 2 x SF2 2.0 2.9
Category 6 2 x SF2 + 2 x SF4 2.0 5.8
Category 7 Rel 7 2 x SF2 + 2 x SF4 16QAM 2.0 11.5

Summary
HSUPA 16QAM enables 11.5 Mbps peak UL data rate by sending four bits per symbol instead
of two. Together with RAN1905 DC-HSUPA a peak rate of 23 Mbps can be obtained.
Benefits for the Customer
16QAM offers higher UL peak rates and better UL capacity.
Functional Description
3GPP Rel-7 introduces 16QAM modulation for HSUPA. HSUPA terminal category 7 supports
16QAM. 16QAM modulates 4 bits per symbol and increases the HSUPA peak data rate to 11.5
Mbps. Category 1-6 maximum is 5.8 Mbps.
16QAM is an optional feature for the UE, and the 16QAM capability is signaled to RNC in the
RRC connection setup. The maximum theoretical throughput of cat7 terminal is 11.5 Mbps.
Practical throughput achievable with this feature is limited by radio channel, interference,
allowed noise rise and both receiver and transmitter imperfections.
Interdependencies between Features
RAN981: HSUPA 5.8 Mbps and RAN1702: Frequency Domain Equalizer are required for this
feature.
RAN1910: Flexible RLC in UL is needed for achieving the 11.5 Mbps peak UL data rate.
HW Requirements
This feature requires RAN1016/RAN1848: Flexi BTS Multimode System Module .
For RNC196 and RNC450, RAN2261 Flexible User Plane Capacity in RNC196 and RNC450 is
required
Eb Es Ec
SF = 2
Cch,2,1 ed,
1
4 symbols E-DPDCH 1
4PAM modulation
mapper
+ SF=4
Cch,4,1 ed,

4 symbols 4PAM modulation
3
I
E-DPDCH 2
mapper
Cch,256,1 e
c
E-DPCCH
BPSK modulation 16
mapper
I+jQ
symbols
S
SF=2 = 16QAM
Cch,2,1 ed,
2
4 symbols E-DPDCH 3
4PAM modulation
mapper
+ SF=4
Cch,4,1 ed,
4 symbols

4 Q
4PAM modulation
E-DPDCH 4 mapper
Cch,256,0 c j
E-DPCCH BPSK modulation

mapper

Release Information
RAS Release - RU40
RNC Release - RN7.0
IPA Platform - A14
OMS for WCDMA - OMS2.0 (RU40)
OMS for I-HSPA - IHO 5.0 (RU40 / I-HSPA 5)
mcRNC Release - mcRNC3.0
Flexi Direct Release - ADA5.0
BTS Release (Flexi) - WBTS8.0
BTS release (Flexi Lite) - WBTS8.0
BTS Release (Flexi 10) - FSMr3 WBTS8.0
BTS HW Release - Flexi Rel2 Flexi Rel3.0
NetAct - OSS5.4 CD set 3
SGSN - SG7.0 MSC
UE Release - 3GPP Rel-7

Activating HSUPA 16QAM:

Licence Feature Code 1497
HSUPA needs to be enabled and working
This feature can be activated by selecting the HSUPA16QAMAllowed parameter
from the drop down menu and then selecting Apply

1. Open the OMS Element Manager.
2. Go to Tree View.
Expand the topology tree of the RNC.
3. Configure the following WCEL parameters.
1. Select Edit parameters from the WCEL object.

2. Under the Admission Control tab, set the HSUPA16QAMAllowed
parameter to Enabled.
3. Under the Packet Scheduler tab, set the MaxTotalUplinkSymbolRate parameter to 5760
kbit/s (2*SF2+2*SF4).
4. Save the changes.

1. Click the Validate button.
2. Click the Apply button

RAN971
HSUPA Downlink Physical Channel Power Control

RAN971 (BSW)
Adjusts HSUPA downlink control channels transmit power : E-
AGCH, E-RGCH) and E-HICH according to the required power
level at the UE. If F-DPCH is configured, it also adapts the transmit
power of the F-DPCHfor each UE.
DL Power Tx Power F-DPCH

CQI Control
Tx Power E-HICH
DL TPC Inner
Tx Power E-RGCH
Loop &
L1 HSPA ACK & NACK Outer
Tx Power E-AGCH
Loop
Power offsets from

RNC databuild

RAN971 (BSW), cont.
This feature dynamically adjusts HSUPA downlink control channels:
E-DCH Absolute Grant Channel (E-AGCH)
E-DCH Relative Grant Channel (E-RGCH)
E-DCH Hybrid ARQ Indicator Channel (E-HICH) transmit powers according to the
required power level at the UE
Fractional Dedicated Physical Channel (F-DPCH)
If F-DPCH is configured, it adapts the transmit power for each UE
The E-DCH serving BTS adjusts the downlink control channel transmit powers
Inner loop algorithm, based on HS-DPCCH feedback information i.e. CQI for
F-DPCH and DL TPC will be used in case of non F-DPCH
Outer loop algorithm, based on Hybrid Automatic Repeat Request (ARQ)
acknowledgements (ACK/NACK), for adjusting the L1 BLER target.
Note that this outer loop algorithm is not related to or does not replace the
RNC based OLPC algorithm for the adjustment of the UL SIR target values

RAN971 (BSW)
RAN 826 Basic HSUPA
RAN 968 HSUPA BTS Packet Scheduler
RAN 973 HSUPA Basic RRM
RAN1016/1848 Multimode SM FSMD/FSME
RAN971
HSUPA Downlink Physical
Channel Power Control
RAN973 RAN826 RAN968 RAN1016/1848

HSUPA Basic HSUPA BTS Multimode SM
Basic RRM HSUPA Packet FSMD/FSME
Scheduler

RAN971 (BSW)
Release Information
RAS Release - RU40
BTS HW Release - Flexi Rel2

RAN1913
High Speed Cell_FACH

RAN1913 - High Speed Cell_FACH
HSPA is used in Cell_FACH state to transport smaller data volumes

More users can be supported in Cell_FACH
Smooth data transmission is provided for users not requiring large data
volumes
Seamless transitions from Cell_FACH to Cell_DCH and from Cell_DCH
to Cell_FACH

RAN1637 HS-Cell_FACH DL
RAN1913 HS-Cell_FACH
Activated
common channels also on HSPA
Common channels
Common channels
Dedicated channels
Low data volume High data volume

Cell_PCH to
Transmission on HSPA Transmission on HSPA
Cell_FACH
in Cell_FACH in Cell_DCH
HS-Cell_FACH Logical channel to transport and physical channel

mapping for 2 X CCPCH
Downlink (RNC UE Uplink (UE RNC
Logical BCCH CCCH DCCH DTCH PCCH CCCH DCCH DTCH
Channel
Transport BCH FACH-c FACH-u HS-DSCH PCH RACH E-DCH

Channel
Physical S-CCPCH HS-PDSCH S-CCPCH PRACH E-DPDCH

P-CCPCH
Channel
Rel.7
Rel.8

RAN1913 - High Speed Cell_FACH, cont.
RAN1637 HS-Cell_FACH DL
The FACH scheduling in the downlink is performed in the RNC MAC layer and mapped to the SCCPCH at
the BTS
The FACH carries the following logical channels for the UEs in the Cell_FACH state:
Broadcast Control Channel (BCCH), which includes the RRC: System Information Change Indications
Dedicated Control Channel (DCCH) for UEs having the RRC connection established
Dedicated Traffic Channel (DTCH), which allows data transmission for the RRC connected UEs
Common Control Channel (CCCH), which is used by UEs for establishing the RRC connection and
when UEs access a new cell/URA area due to cell/URA reselection.
The PRACH in the uplink comprises a preamble part and a message part
The AICH is the downlink physical channel that is used to acknowledge the preambles transmitted by the
UEs in the PRACH state
The preamble acknowledgements are transmitted when the signature included in the preamble can be
correctly detected
If no AICH is detected
the UE increases the preamble power
The preamble is retransmitted in the next available access slot with increased transmission power

HS-Cell_FACH in RU40
introduces support of HSUPA in CELL_FACH state and idle mode
This is introduced in 3GPP Release 8 in order to
Increase the available uplink peak date rate for UEs in CELL_FACH state
Reduce the state transition delay from CELL_FACH state to CELL_DCH state
Reduce the latency of user and control plane in the IDLE mode, CELL_FACH, CELL_PCH and
URA_PCH state
The Enhanced UL access procedure is similar to the 3GPP Rel-3 RACH procedure
preamble transmission with power ramping
BUTwith fast E-DCH resource allocation
The PRACH preamble part is still used for power ramping but an ACK on AICH not only acknowledges
reception but also assigns a common E-DCH resource to the UE
Once a common E-DCH resource is allocated, UE starts transmitting user data in the UL using the
E-DPDCH
This data transmission still has the possibility of collision due to users competing for UL
RESOURCES until further potential collision is resolved by the BTS via a UE specific E-RNTI on
AGCH
After this, UE transmits exclusively on this allocated common E-DCH resource until this resource is
released by either the BTS or by the UE
After the common E-DCH resource is released, any further UL transmissions require the above
described access procedure to be performed again
This E-DCH Enhanced Random access procedure is only required at the start of each UL
transmission
Each common E-DCH resource consists of parameters used by the UE to transmits and receive data in
High Speed CELL_FACH operation e.g.
F-DPCH code and time-offset
E-RGCH/E-HICH code and signature
E-AGCH code
HS-DPCCH parameters (power offsets, CQI)
Up to 32 common E-DCH resources can be configured in the cell and are broadcast by system SIB
5/5bis
Common E-DCH resource allocation are under direct control of the BTS
A Common E-DCH is configured in the cell by the RNC but it is not involved in the assignment of these
resources to UEs
The UE can determine a particular E-DCH resource configuration to use from the index indicated by the
AICH/E-AICH in response to its preamble transmission

HS-Cell_FACH in RU40
introduces support of HSUPA in CELL_FACH state and idle mode
This is introduced in 3GPP Release 8 in order to
Increase the available uplink peak date rate for UEs in CELL_FACH state
Reduce the state transition delay from CELL_FACH state to CELL_DCH state
Reduce the latency of user and control plane in the IDLE mode, CELL_FACH, CELL_PCH and
URA_PCH state
The Enhanced UL access procedure is similar to the 3GPP Rel-3 RACH procedure
preamble transmission with power ramping
BUTwith fast E-DCH resource allocation
The PRACH preamble part is still used for power ramping but an ACK on AICH not only acknowledges
reception but also assigns a common E-DCH resource to the UE
Once a common E-DCH resource is allocated, UE starts transmitting user data in the UL using the E-
DPDCH
This data transmission still has the possibility of collision due to users competing for UL
RESOURCES until further potential collision is resolved by the BTS via a UE specific E-RNTI on
AGCH
After this, UE transmits exclusively on this allocated common E-DCH resource until this resource is
released by either the BTS or by the UE
After the common E-DCH resource is released, any further UL transmissions require the above
described access procedure to be performed again
This E-DCH Enhanced Random access procedure is only required at the start of each UL
transmission
Each common E-DCH resource consists of parameters used by the UE to transmits and receive data in
High Speed CELL_FACH operation e.g.
F-DPCH code and time-offset
E-RGCH/E-HICH code and signature
E-AGCH code
HS-DPCCH parameters (power offsets, CQI)
Up to 32 common E-DCH resources can be configured in the cell and are broadcast by system SIB
5/5bis
Common E-DCH resource allocation are under direct control of the BTS
A Common E-DCH is configured in the cell by the RNC but it is not involved in the assignment of these
resources to UEs
The UE can determine a particular E-DCH resource configuration to use from the index indicated by the
AICH/E-AICH in response to its preamble transmission

Uplink
PRACH Preamble Part is used for Power ramping phase before transmission
on common E-DCH
E-DPDCH is used for Uplink user data
E-DPCCH is used for Control signaling for E-DPDCH (RSN, E-TFCI and
Happy Bit)
HS-DPCCH (if configured) is used for HS-DSCH control signaling CQI, HARQ
ACK/NACK
DPCCH is used for Power Control Commands
Downlink
AICH is used for access grant and allocation of E-DCH resources
E-HICH is used for HARQ ACK/NACK (E-DCH)
E-AGCH is used for collision resolution, scheduling and release of common E-
DCH resources
E-RGCH (if configured) is used for scheduling
F-DPCH is used for Power Control Commands

RAN1913 - High Speed Cell_FACH)
E-DCH procedure (RAN1913)

3
AICH response
1
{
DL
AICH
4
2
UL
PRACH
E-DPDCH
E-DPCCH AICH responds
RACH type random access
with preambles and power Common E-DCH resource assigned
ramping BTS start transmitting on F-DPCH
and synchronizes
UE starts transmitting on DPCCH
and synchronizes

Collision probability is high
E-DCH procedure (RAN1913)

First E-AGCH transmission with the UEs E-RNTI
3 is used for collision detection/resolving
AICH response It marks the end of the collision detection phase
1 5 It is also used as the absolute grant
{
DL AICH E-AGCH
5
4
2
UL
PRACH E-DPDCH E-DPDCH
E-DPDCH E-DPCCH E-DPCCH
E-DPCCH
Common E-DCH resources
exclusively used by this UE

1. UE receives system information:

UL interference level
AS & signature setting
Thresholds
sub-channels
Access Class (AC) to Access Service Class (ASC) mapping
Initial gain factor (or initial bit-rate)
Outer Loop Power Control (OLPC), select access slot and signature
2. Rel. 99 RACH type random access with preambles and power ramping
3. Channel access and resource assignment
4. BTS start transmitting on F-DPCH and synchronizes
5. UE starts transmitting on DPCCH and synchronizes

Overall timing relations for E-DCH

Transmission in Cell_FACH and Idle state
from a UE perspective when using HS-
Cell_FACH

1. UE receives system information:
UL interference level
AS & signature setting
Thresholds
sub-channels
Access Class (AC) to Access Service Class (ASC) mapping
Initial gain factor (or initial bit-rate)
Outer Loop Power Control (OLPC), select access slot and signature
2. Rel. 99 RACH type random access with preambles and power ramping
3. Channel access and resource assignment
4. BTS start transmitting on F-DPCH and synchronizes
5. UE starts transmitting on DPCCH and synchronizes
6. E-DPCCH and E-DPDCH transmission. During the collision resolution phase, the UEs E-RNTI is
included in all MAC-i PDUs
7. E-HICH for HARQ functionality
8. First E-AGCH transmission with the UEs E-RNTI is used for collision detection/resolving.It marks the end
of the collision detection phase. It is also used as absolute grant
9. HS-DPCCH to support DL HS-DSCH transmission
10. Stop the transmission:
UE runs out of data
BTS stops transmission
Transition to CELL_DCH
In idle mode or if no E-RNTI identifier is allocated to the UE only Common

Control Channel (CCCH) data transmission is possible
Once the E-RNTI has been allocated collision resolution can be carried out
and dedicated data transmission and control signaling is granted on E-
DCH
When the UL resources have been assigned, inner loop power control is
started and the UE is able to send ACK/NACK and CQI for the HSDSCH
If High Speed Cell_FACH is not used in the uplink for Rel7 or older UEs
then Rel99 RACH is used
There is no dedicated uplink feedback signaling channel and HSDPA HARQ
cannot be used
The MAC layer can be configured to execute fixed downlink retransmissions.
High Speed Cell_FACH allows fast service for a large number of users at
the same time
For bursty data like SMSs and push-email the response times allow a
Cell_FACH state data transfer without frequent switching to Cell_DCH
state
With High Speed Cell_FACH uplink, the collision probability remains very
low when the Rel99 PRACH has already reached a probability of 1
BTS baseband resources are efficiently shared between High Speed
Cell_FACH state UEs since resources are not reserved for a UE during
inactivity
This improves resource utilization at the RNC since the Cell_DCH setup is
not needed for a short data burst.
Considering the increasing amounts of keep-alive messaging from
smartphones High Speed Cell_FACH has major benefits for BTS and
RNC resource utilization
The control of state transitions takes into account the UE device type.


RAN1637: High Speed Cell_FACH DL
RAN1910: Flexible RLC Uplink
RAN1638: Flexible RLC Downlink
RAN1016/RAN1848: Flexi BTS Multimode System Module
RAN1913
HS-Cell_FACH
RAN1226
RNC196/450 RAN1910 RAN1638 RAN1016/1848
HSPA Peak Flexible RLC Flexible RLC Multimode SM
Rate Upgrade Uplink Downlink FSMD/FSME

Release Information
RAS Release - RU40
RNC Release - RN7.0
IPA Platform - A14
mcRNC Release - mcRNC3.0 RNC
BTS HW Release - Flexi Rel2/Flexi Rel3.0

Activating HS-Cell_FACH:
Set the feature license ON
For IPA-RNC:
ZW7M:FEA=1795:ON;
For mcRNC:
HSDPA/HSUPA should already be enabled and working
Cell requires locking
Set the following parameters
WCEL - PowerSaveHSPAType parameter is set to 0 (NoHSPA05ReConf) or 2 (HSPA5)

WCEL HSFACHEnabled is set to Enabled
WCEL HSRACHEnabled parameter is set to Enabled

RNFC - FRLCEnabled parameter is set to Enabled

RNFC - FlexULRLCEnabled parameter is set to Enabled

RAN2451
Fast Dormancy Profiling

RAN2451 - Fast Dormancy Profiling
Significant Control plane load reduction in the RNC by identifying smart phones
causing extra signalling load

RAN2451 - Fast Dormancy Profiling, cont.
Legacy smartphones causing unnecessary signalling load are identified and moved Cell_PCH/URA_PCH
state
Shorter inactivity timers are used to avoid signalling connection release
Higher traffic volume measurement thresholds for the use of common channels is configured to avoid state
transition to Cell_DCH for keep-alive messages
PS call setup from idle state to Cell_DCH state requires almost ten times more signaling when compared to
Cell_PCH use and sending smaller packets in Cell_FACH state
Control plane load of Iub, Iu and core network is reduced
Users will benefit in terms of longer battery life
Identification is based on the signalling connection release triggered by the UE.
When the UE sends the Signalling Conection Release Indication (SCRI) to the RNC without any cause then
this UE is treated as Legacy Fast Dormancy (LFD) phone and is moved to Cell_PCH/URA_PCH state
If the UE creates new RRC connection while the IMSI is still stored (old double reservation functionality) the
UE is classified as a "legacy fast dormancy phone
To prevent these UEs from sending the SCRI again and going to idle mode the RNC uses shorter
inactivity/idle timers so that the RNC reacts faster than the UE
When this idle timer expires, RNC moves the UE to Cell_PCH/URA_PCH state before they initiate the
connection release
The RNC can control the UE state
UE battery consumption is kept low
Uisng Cell_PCH state only requires about one third of the RAN signalling when compared to the signalling
amount required to perform RRC connection setup again after it is released
Frequent RRC connection releases and setups causes additional uneccessary load to the core network.
PCH state has to be supported in the RNC before Fast Dormancy Profiling can be used
Release Information
RAS Release - RU40

RNC Release - RN7.0

Activating Fast Dormancy Profiling:

Licence feature Code - 3384
Check and activate the licence
IPA-RNC:
ZW7I:FEA,LIM:FEA=3384,FSTATE=ON;
ZW7M:FEA=3384:ON;
mcRNC and I-HSPA Adapter:
Expand the RNFC object
Select Edit parameters from the RNFC object
Set the LFDProfEnabled parameter to Enabled

RAN1910
Flexible RLC in UL

RAN1910 - Flexible RLC in UL
Fixed RLC PDU in UL (3GPP Rel-7) is a

bottleneck: 3GPP Rel-7
HSUPA RLC peak rate is limited due to
number of concatenated overheads PDCP IP packet 1500 bytes
RLC PDU size is fixed and independent from
the current radio conditions
RLC packet size equals
RLC to 40 or 80 bytes
Flexible RLC PDU in UL (3GPP Rel-8)
omits that bottleneck:
RLC PDUs can be as large as IP packet
RLC PDU size reflects radio conditions 3GPP Rel-8
HSUPA RLC peak rate is increased
PDCP IP packet 1500 bytes
Average network throughput is increased
New functional entities of MAC-i and MAC-is RLC packet size flexible
are added to MAC layer to handle new RLC between 2 1505 bytes
variable RLC PDUs
Less RLC processing since the number of
packets to be processed is reduced

RAN1910 - Flexible RLC in UL, cont.
Benefits
End-user benefits
Feature RAN1910: Flexible RLC in UL enables higher bit rates for single end users.
Operator benefits
This feature benefits the operator as follows:
increases overall data throughput in the network
reduces the Layer 2 overhead and padding in combination with the optimum transport block
size for different radio conditions
The flexible RLC PDU size reduces processing needs both in the UE and the RNC. The feature
is part of 3GPP Rel-8, optional for the UE. It is applied for the UE supporting flexible RLC in the
UL, recognized in the RAN by the UE capability.
Feature RAN1910: Flexible RLC in UL is characterized by the following:
The size of the uplink RLC PDUs can be significantly larger with the feature activated and
it is determined autonomously by the RLC layer within the limits given by upper layers.
There is no need to use padding to reach a certain predefined PDU size.
The feature is applicable for:
radio bearers (RBs) using acknowledged mode (AM) RLC or unacknowledged mode (UM)
RLC and mapped on the enhanced dedicated transport channel (E-DCH) using MAC-i or
MAC-is in CDSP-DH card
signaling radio bearers (SRBs) using AM or UM RLC and mapped on the E-DCH transport
channel using MAC-i or MAC-is in CDSP-DH card
RAN1910 RAN1910
Not activated Activated
TCP/IP TCP/IP
TCP/IP Payload TCP/IP Payload
header header
MTU: 1500 bytes MTU: 1500 bytes
RLC SDU RLC SDU
MAC-es/e RLC MAC-is/i RLC

headers PDUs Paddings headers PDU Padding
19 MAC-es/e 19 fixed RLC PDUs One MAC-is/i One RLC PDU is

headers required (656 bits each) required header required required per 1500
+ optional padding per 1500 bytes IP packet + optional padding bytes IP packet
Control data = 3.72% of whole transport block Control data = 0.27% of whole transport block
When the transmission error occurs one small RLC PDU It corresponds to 93% drop of control data for typical IP
needs to be retransmitted packet size of 1500 bytes
When the transmission errors occur one big RLC PDU
needs to be retransmitted
Flexible RLC is used in the uplink for the E-DCH. RLC operation is simplified; the IP packet received from the
upper layer in the service data unit (SDU) can be passed to the MAC layer typically in one or two RLC PDUs.
Segmentation is used when the IP packet size exceeds the maximum RLC PDU payload size, which in the
3GPP specifications is 1503 bytes.
In order to support flexible RLC PDU sizes in the WCDMA UL, new MAC entities are necessary for the RNC,
BTS, and UE:
MAC-i is introduced in the BTS and the UE
MAC-is is introduced in the RNC and the UE
The MAC layer supports handling of SDUs with different sizes, and their segmentation when needed.
MAC-i (together with the E-DCH scheduler) handles E-DCH specific functions in the BTS, such as:
E-DCH scheduling
E-DCH control
de-multiplexing of MAC-i PDUs
reading UE ID
hybrid automatic repeat request (HARQ)
MAC-is handles E-DCH specific functions (not covered in the MAC-i entity in the BTS) such as:
disassembly of MAC-is PDUs
reordering queue distribution and reordering of received MAC-is PDUs
macro diversity selection
re-assembly of segmented MAC-d or MAC-c PDUs
cyclic redundancy check (CRC) error detection
Software requirements: Hardware requirements:
Flexible RLC (DL) (RAN1638) Flexi BTS Multimode System Module FSMC
Basic HSUPA (RAN826) (RAN2382), or
Flexi BTS Multimode System Module FSMD
(RAN1016), or
Flexi BTS Multimode System Module FSME
(RAN1848)
RAN2382
Flexi BTS
Multimode System
RAN1638 Module FSMC
Flexible RLC (DL)
or
RAN1016
RAN1910 Flexi BTS
Flexible RLC in UL Multimode System
Module FSMD
or
RAN826
Basic HSUPA
RAN1848
Flexi BTS
Multimode System
Module FSME

Flexible RLC in Uplink
Overview (simplified)
UE selects the E-TFC and TBS according to current grant on TTI basis
RLC operations (segmentation and concatenation) on RLC SDUs are
performed to fit maximum RLC PDU size
New MAC-is/i are introduced in order to handle flexible instead of fixed
size RLC PDUs
MAC-i is introduced in the UE and BTS
MAC-is is introduced in the UE and RNC
UE BTS RNC
RLC RLC
MAC-d MAC-d
MAC-is/i MAC-i MAC-is
For public use IPR applies Uu Iub

MAC-is/-i structure in the BTS and in the RNC for DCCH/DTCH
transmission
RNCs MAC-is handles E-DCH specific functionality:
Disassembly of MAC-is PDUs
RNC Reordering queue distribution
Reordering of received MAC-is PDUs
RLC Macro diversity selection
Reassembly of segmented MAC-d/c PDUs
MAC-d CRC error detection (needs RAN1913)
MAC-is
Iub
BTSs MAC-i together with the E-DCH scheduler handles
HSUPA specific functions:
E-DCH scheduling
BTS
E-DCH control
MAC-i
De-multiplexing of MAC-i PDUs
Uu Reading UEs id
HARQ associated procedures
New E-DCH UE Categories
3GPP Rel. 9 TS 25.306 specification define new E-DCH categories (the feature
was itself was specified earlier, in 3GPP Rel. 8) which support MAC-i/is and
therefore support FRLC in UL
Those categories include:
E-DCH Category 8 and 9
In the table below some details concerning new categories are presented:
Max. number Maximum Dual Cell Min. Max. number of Max. L1

E-DCH Support of
of E-DCH modulation E-DCH spreading bits of an E-DCH throughput*
Cat. E-DCH TTI
codes per TB order operation factor TB within TTI [Mbit/s]
8 4 QPSK supported SF2 11484 2ms** only 5.742

9 4 16QAM*** supported SF2 22996 2ms** only 11.498
The information concerning the support of the MAC-i/is is indicated in the new UE
information element named Support of MAC-i/is
The absence of IE indicates that UE does not support MAC-i/is operation
*- No DC E-DCH operation is assumed
**- Requires HSUPA 2ms TTI (RAN1470)
*** - Requires HSUPA 16QAM (RAN1645)
New Parameters:
Managed
object
FlexULRLCEnabled Flexible UL RLC Enabled RNFC
Modified Parameters:
Managed
HSUPAUserLimit16QAM HSUPA user limit for 16QAM usage WCEL
AMRLCRelatTxWindowRate8 AM RLC relative Tx window size defining data rate 8 RNRLC
AMRLCRelatTXWindowRate8Size AM RLC relative Tx window size assigned to data rate 8 RNRLC

New Parameters:
FlexULRLCEnabled:
This parameter enables/disables use of feature Flexible UL RLC. If the parameter is enabled (1), then
feature Flexible UL RLC is used in the RNC. If the parameter is disabled (0), then feature Flexible UL RLC
is not used in the RNC. Range: 0 (Disabled), 1 (Enabled); Default= 0.
Modified parameters:
HSUPAUserLimit16QAM:
This parameter defines the limit for the amount of active HSUPA users in a cell in the process of
determining the usage of HSUPA 16QAM with both fixed and flexible UL RLC.
For flexible UL RLC: If the amount of active HSUPA users in a cell is lower than or equal to the threshold,
defined by this parameter, the HSUPA 16QAM usage is allowed with flexible UL RLC PDU size.
For fixed UL RLC: If the amount of active HSUPA users in a cell is lower than or equal to the threshold
defined by this parameter, the fixed UL RLC PDU size must be 656 bits. Otherwise an UL RLC PDU size of
336 bits can be used. The HSUPA 16QAM usage is allowed if the UL RLC PDU size is 656 bits.
Range:1..10, step 1. Default:2 (Default value of 2 enables UE-UE call in cell with 16QAM)
AMRLCRelatTxWindowRate8:
This parameter defines the eighth transport channel user data rate for the definition of the relative
transmission window size of the AM RLC. Range: 8..85000 kbps, step 8 kbps. Default=85000 kbps.
The final size of the transmission window is defined for UL transport channel data rate by sharing out the
RLC buffer of the UE between the transport channels in the ratio of their relative window sizes
AMRLCRelatTXWindowRate8Size:
This parameter assigns the relative transmission window size of the AM RLC to the eighth transport
channel user data rate. The window size is defined as the number of AM PDUs. This parameter also
defines the relative transmission window size for all of the non-zero transport channel user data rates which
are higher than data rate number 8. Range:8..85000, step 8. Default=31000
Following counters were introduced to verify feature usage performance

M1001C706 - UE SUPPORT FOR FLEXIBLE RLC UPLINK
M1006C233 - RADIO BEARER CONFIGURED FOR FLEXIBLE RLC UL
Following counters were modified to verify feature usage performance
M5000C1xx - MAC-E PDU RETRANSMISSIONS from 0 to 12 COUNTER
M5000C142 - MAC-E PDU HARQ FAILURE COUNTER
M5000C144 - MAC-E PDU RETRANSMISSIONS UNKNOWN COUNTER
M5000C15x - HSUPA MINIMUM or MAXIMUM MAC-D THROUGHPUT
M5000C153 - HSUPA AVERAGE MAC-D THROUGHPUT
M5000C32x - HSUPA MACE PDUS WITH 2MS or 10MS TTI
M5000C36x - SUM OF (IN)CORRECTLY RECEIVED MAC-E PDUs WITH 16QAM UL
M5002C2 - E-DCH DATA VOLUME FOR SERVING CELL UL
M5002Cx - E-DCH DATA VOLUME FOR NON-SERVING CELL IN (NON-)SERVING E-DCH
RLS UL
M5002Cxx - TOTAL HSUPA DATA FOR SPI from 0 to 15
M5002C38 - UE HSUPA THROUGHPUT CLASS from 00 to 11
M5003Cx (E-)xCH DATA VOLUME TO IUB-INTERFACE
M5003C19 - MAC-E PDU LOST

New WCEL, RNC Counters:
M1001C706 - UE SUPPORT FOR FLEXIBLE RLC UPLINK

The number of RRC connections established by UEs supporting Flexible-RLC in the uplink direction.
Updated: When an RRC connection is successfully established with RRC: RRC CONNECTION SETUP
COMPLETE message or incoming relocation/HHO/ISHO by a UE that supports Flexible-RLC in the uplink
direction.
M1006C233 - RADIO BEARER CONFIGURED FOR FLEXIBLE RLC UL
The number of successful radio bearer setups and reconfigurations to use Flexible-RLC in uplink direction.
M1006C202 can be updated in parallel with this counter because it indicates the Flexible-RLC usage in the
downlink direction.
When the UE replies with RRC: RADIO BEARER SETUP COMPLETE or RRC: RADIO BEARER
RECONFIGURATION COMPLETE indicating a successful configuration of Flexible-RLC in uplink direction
that was not in use before the reconfiguration.
M5000C1xx - MAC-E PDU RETRANSMISSIONS from 0 to 12 COUNTER (xx = 28 -> 40)
Number of MAC-e PDUs that are received correctly with the number retransmissions indicated in the counter
name in E-DCH Serving Cell. These counters are also applicable for MAC-i.
When a MAC-e PDU is received correctly with the number of retransmissions indicated in the counter name.
These counters are also applicable for MAC-i. Particular counters are updated only for serving cell.
M5000C142 - MAC-E PDU HARQ FAILURE COUNTER
Number of MAC-e PDUs that are not received correctly despite retransmission in E-DCH Serving Cell. This
counter is also applicable for MAC-i.
that was not in use before the reconfiguration

New KPIs
Average HSUPA Session Throughput, Cell Level:

Number of SDU bytes transmitted in uplink using RLC AM
Avg HSUPA SessionThp Cell =
Measurement period duration
Summarization Formula:
sum(8 * UL RLC AM SDU PAYLOAD OF PS TRAFFIC FOR WCEL)
sum(MEASUREMENT TIME PERIOD FOR UL RLC AM FOR WCEL)
Average number of active users with HSUPA 16QAM:
SUM (SUM OF ACTIVE 16QAM UL USERS)

Avg no act usr HSUPA16QAM =
CELL SPECIFIC USERS DENOMINATOR

Avg HSUPA SessionThp Cell:

Average HSUPA Session Throughput, Cell Level
Average HSUPA Session throughput. This KPI is based on the number of SDU bytes transmitted in uplink
using RLC Acknowledge Mode and on the actual transmission time.
Avg no act usr HSUPA16QAM:
Average number of HSUPA users using QAM16 modulation
Average number of active HSUPA users using 16QAM modulation is given with cell specific granularity.
Operator can also see summary levels such as: Network, City, Area, RNC, Cluster of cells, and Cell
MEASUREMENT(S): HSPA in WBTS
M5000C359 - EDCH_16QAM_UE_ACT_SUM :
The sum of sampled number of active 16QAM UL users (user configured with 16QAM and 16QAM is
currently in use). Applicable only for a serving cell.
The counter is updated periodically and the updated value is a snapshot of the current situation. The
16QAM modulation usage is checked from last Narq HARQ processes. Narq equals to the total number of
HARQ processes.
SAMPLING INTERVAL: 100ms
M5000C327 - DENOM_CPC_USERS
CELL SPECIFIC USERS DENOMINATOR
The counter is updated by value 1 when the number of users is sampled periodically.

New KPI
Utilization of the HSUPA 16QAM mode:

100 * SUM (SUM OF CORRECTLY RECEIVED MAC - E PDUs WITH 16QAM UL)
Util HSUPA 16QAM mode =
SUM (MAC - E PDU RETRANSMISSIONS 0 COUNTER +
MAC - E PDU RETRANSMISSIONS 1 COUNTER +
MAC - E PDU RETRANSMISSIONS UNKNOWN COUNTER)

New RNC, WCEL Counters: (Measurement HSPA in WBTS
Util HSUPA 16QAM mode:
Utilization of the HSUPA 16QAM mode comparing to all received MAC-E PDUs.
M5000C360 - MACE_PDU_RX_COR_16QAM:
SUM OF CORRECTLY RECEIVED MAC-E PDUs WITH 16QAM UL
The number of correctly received MAC-e / MAC-i PDUs sent by 16QAM modulation in uplink. Applicable only for a
serving cell.
The counter is updated whenever a MAC-e / MAC-i PDU is correctly received (CRC ok) and the PDU was sent
using 16QAM modulation
M5000C128 - MACE_PDU_RETR_00_COUNTER:
MAC-E PDU RETRANSMISSIONS 0 COUNTER
umber of MAC-e PDUs that are received correctly without retransmissions in E-DCH Serving Cell. This counter is
also applicable for MAC-i.
When a MAC-e PDU is received correctly with the number of retransmissions indicated in the counter name. This
counter is also applicable for MAC-i. Counter updated only for serving cell.
M5000C129 - MACE_PDU_RETR_XX_COUNTER:
MAC-E PDU RETRANSMISSIONS XX COUNTER (with XX = 01 to 12)
Number of MAC-e PDUs that are received correctly with XX retransmissions in E-DCH Serving Cell.This counter is
When a MAC-e PDU is received correctly with the number of retransmissions indicated in the counter name. This
counter is also applicable for MAC-i. Counter updated only for serving cell.
M5000C144 - MACE_PDU_RETR_UNKNOWN_COUNTER:
Number of MAC-e PDUs that are received correctly but the number of retransmissions is unknown. This counter is
When a MAC-e PDU is correctly received but the number of retransmissions is not known. This counter is also
applicable for MAC-i. Counter updated only for serving cell.
New KPIs
Nbr of Radio Bearers using UL Flexible RLC:
Nbr of RBs UL Flex RLC = SUM (RB_CONFIG_FLEXIBLE_RLC_UL )
UEs with Flexible UL RLC capability ratio:

SUM (UE_SUPP_FLEX_RLC_UL)
UEs Flex UL RLC cap ratio =
SUM(RRC_CO NN_ACC_COMP + RRC_RELOC_ACC_COMP)
HSUPA throughput utilization per BTS

(EDCH_DATA_SCELL_UL +

100 * sum( EDCH_DATA_NSC_S_EDCH_UL + * 8)
EDCH_DATA_NSC_NS_EDCH_UL)

(PERIOD_DURATION * 60)
HSUPA thr util per BTS =
(Licensed peak rate throughput)

New KPIs:
Nbr of RBs UL Flex RLC:
Number of Radio Bearers which were configured to use Flexible UL RLC
MEASUREMENT(S): RRC signalling
M1006C233 - RB_CONFIG_FLEXIBLE_RLC_UL:
RADIO BEARER CONFIGURED FOR FLEXIBLE RLC UL
The number of successful radio bearer setups and reconfigurations to use Flexible-RLC in uplink direction.
that was not in use before the reconfiguration.
MEASUREMENT(S): RRC signalling
UEs Flex UL RLC cap ratio:
This KPIs give the percetange of UEs capable of using Flexible-RLC in the uplink direction related to all Ues.
Ue capability are determined based on RRC: RRC CONNECTION SETUP COMPLETE message or incoming
relocation/HHO/ISHO
M1001C706 - UE_SUPP_FLEX_RLC_UL:
UE SUPPORT FOR FLEXIBLE RLC UPLINK
The number of RRC connections established by UEs supporting Flexible-RLC in the uplink direction.
When an RRC connection is successfully established with RRC: RRC CONNECTION SETUP COMPLETE
message or incoming relocation/HHO/ISHO by a UE that supports Flexible-RLC in the uplink direction.
MEASUREMENT: ServiceLevel

M5002C2 - EDCH_DATA_SCELL_UL:
E-DCH DATA VOLUME FOR SERVING CELL UL
Amount of MAC-e PDU data transferred in the E-DCH serving cell in the uplink direction during the measurement
interval. The MAC-e header includes to the MAC-e PDU data calculation.
This counter is also used for MAC-i PDU data amount calculation.The MAC-i header includes to the MAC-i PDU
data calculation.
The counter is updated when the connection is released or the measurement interval ends.
MEASUREMENT: Cell_Throughput_WBTS
UNIT: kbyte
M5002C3 - EDCH_DATA_NSC_S_EDCH_UL:
E-DCH DATA VOLUME FOR NON-SERVING CELL IN SERVING E-DCH RLS UL
Amount of MAC-e PDU data transferred in the E-DCH non-serving cell in the serving radiolink set in the uplink
direction during the measurement interval. The MAC-e header includes to the MAC-e PDU data calculation.
data calculation.
UNIT: kbyte
M5002C4 - EDCH_DATA_NSC_NS_EDCH_UL:
E-DCH DATA VOLUME FOR NON-SERVING CELL IN NON-SERVING E-DCH RLS UL
Amount of MAC-e PDU data transferred in the E-DCH non-serving cell in the non-serving radiolink set in the uplink
direction during the measurement interval. The MAC-e header includes to the MAC-e PDU data calculation.
data calculation.
UNIT: kbyte
Release Information:
WCDMA Release RU40
Flexi Direct Flexi Direct RU40
RNC Release RN7.0
BTS (Flexi) WBTS8.0
HW Requirements Flexi Rel2
UE Release 3GPP Rel-8

RAN1908
UE DRX in Cell_FACH

RAN1908 - UE DRX in Cell_FACH
Discontinuous reception of HS-DSCH in HS-SCCH frames

Cell_FACH state allows to:
Periodically turn off the receiver
Read HS-SCCH frames at regular
fixed interval (when RX is on)
It enables to transfer periodically short

packets i.e. keep-alive messages Rx On Rx On
Rx Off
DRX reception allows to decrease UE

battery consumption comparing to legacy
Cell_FACH (without DRX)
Battery
savings
The latency for downlink traffic is increased
by the DRX process

RAN1908 - UE DRX in Cell_FACH, cont.
Brief Description:
Feature enables a discontinuous reception (UE DRX) for High Speed Cell_FACH
state according to 3GPP Rel8 UEs onwards
UE doesnt need to decode all the downlink HS-SCCH frames in Cell_FACH state
DRX operation in Cell_FACH state is interrupted when data transmission is started
Feature is dedicated especially for smartphone users
Benefits:
End-user benefits
Discontinuous reception in High Speed Cell_FACH state results in reduced UE
battery consumption.
Operator benefits
Lower battery consumption enables longer Cell_FACH state times, resulting in
faster
response times.
Without UE DRX in Cell_FACH With UE DRX in Cell_FACH feature

feature there is a certian power loss in there is more rational power utilization
cell_fach state due to RX always at UE in cell_fach state. Less power is
switched on even if no data are being lost when transmission is not present
transmitted. due to RX switched off.
HS-SCCH frames HS-SCCH frames
No data No data
transmission transmission
Data Data Data Data
RX continous switched on RX on RX off RX on
Unnecessary power loss No power loss

Feature Requirements:
RAN1913 High Speed Cell_FACH
RAN2261 Flexible User Plane Capacity is needed for RNC196 and RNC450 (all capacity steps)
RAN1016/RAN1848 Flexi BTS Multimode System Module
UEs: 3GPP Rel8
RAN1913 RAN1908* RAN1016

High Speed UE DRX in
RAN1848
Cell_FACH Flexi BTS
Cell_FACH Multimode SM
RAN2261
Flexible User Plane
Only for RNC196
Capacity
and RNC450
*RAN1908 UE DRX in Cell_FACH with RAN1913 High Speed Cell_FACH is based on Cell_FACH state.
In RAN1644 CPC similar functionality of UE DRX exists but it is based on Cell_DCH state

DRX Process
Rx burst is described
After inactivity time new by HS-DSCH Rx burst
DRX cycle starts FACH parameter
RX off RX off RX off RX off
DRX Rx burst DRX Rx burst DRX Rx burst

cycle length cycle length cycle length
DRX cycle E-DCH/HS-DSCH Inactivity DRX cycle DRX cycle

sum resource allocated time sum sum
Inactivity time is sort of a buffer protecting Rx burst

DRX cycle is described by from cancellation
HS-DSCH DRX cycle FACH parameter (due to too fast jump from RX to DRX state)
DRX process includes:

RX burst length the duration in frames during which UE reads HS-SCCH transmission
DRX cycle sum includes RX burst length and DRX cycle
DRX cycle is the time during which UE will not read HS-SCCH frame

New Parameters:
Managed
object
HSFACHDRXEnabled UE DRX with High Speed Cell FACH Enabled WCEL
T321 High Speed Cell FACH DRX operation timer WCEL
DRXCycleHSFACH Discontinuous Reception Cycle HS-FACH WCEL

RXBurstHSFACH HS-FACH Reception Burst WCEL
DRXInterruptHSDSCHData DRX Interruption by HS-DSCH data WCEL
DRXInactiveTimerHSFACH Inactivity Supervision Timer of HSFACH for DRX User WCEL
NO DATA TRANSMISSION
T321 is restarted at the
end of HS-SCCH DRX operation
subframe T321 DRX cycle
UE change to
CELL_PCH
Or
E-DCH/HS-DSCH
RX burst URA_PCH
resource allocated
Enabled/Disabled
New Parameters:
HSFACHDRXEnabled:
UE DRX with High Speed Cell FACH Enabled
The parameter enables / disables the use of HSFACH in DL in the cell, that is the use of HSDPA in the cell
for the UE on CELL_FACH state.
Range: Disabled (0), Enabled (1); Default value = Disabled (0)
T321:
High Speed Cell FACH DRX operation timer
This parameter indicates the time the UE waits until initiating DRX operation in High Speed CELL_FACH.
UE enters HS-DSCH DRX cycle after the expiry of this timer
Range: 100 ms (0), 200 ms (1), 400 ms (2), 800 ms (3); Default value = 100 ms (0)
DRXCycleHSFACH:
Discontinuous Reception Cycle HS-FACH.
This parameter indicates the length of the DRX Cycle during DRX operation in High Speed CELL_FACH.
Range: 4 frames (0), 8 frames (1), 16 frames (2), 32 frames (3); Default value = 16 frames (2)
RXBurstHSFACH:
HS-FACH Reception Burst
This parameter indicates the period within the DRX Cycle that the UE continuously receives HS-DSCH.
Range 1 frames (0), 2 frames (1), 4 frames (2), 8 frames (3), 16 frames (4); Default value 1 frames (0)

New Counters:
Managed
SUM_OPER_TIME_HSFACH_RX SUM OF TIME UE IN HSFACH RX HSDPA_WBTS
SUM_OPER_TIME_HSFACH_DRX SUM OF TIME UE IN HSFACH DRX HSDPA_WBTS

DRXInterruptHSDSCHData:
DRX Interruption by HS-DSCH data
This parameter indicates whether DRX operation in High Speed CELL_FACH can be interrupted by HS-
DSCH data or not.
Range: Disabled (0), Enabled (1); Default value = Disabled (0)
DRXInactiveTimerHSFACH:
Inactivity Supervision Timer of HS-FACH for DRX User
This timer is used on MAC -c to detect the idle periods on data transmission (NRT HSPA RBs and SRBs)
for the Rel8 and newer UEs on CELL_FACH using HS-FACH with DRX Mode.
Based on this timer the MAC -c shall give No_Data indication to RRC, which further can change the state of
the UE from Cell_FACH state to the Cell_PCH state (or URA_PCH state).
Range: 1... 120 s; Default value 2 s
New Counters:
SUM_OPER_TIME_HSFACH_RX:
SUM OF TIME UE IN HSFACH RX
Duration of UE in HSFACH RX (Reception) state
This counter is updated when the UE state is changing to the DRX state.
MEASUREMENT: HSDPA_WBTS
SUM_OPER_TIME_HSFACH_DRX
SUM OF TIME UE IN HSFACH DRX
Duration of UE in HSFACH DRX (Discontinuous Reception) state
This counter is updated when the UE state is changing to the RX state.
MEASUREMENT: HSDPA_WBTS
WCDMA Release RU40

I-HSPA System I-HSPA Rel5
RNC Release RN7.0
BTS (Flexi) WBTS 8.0
HW Requirements Flexi Rel2 or 3
UE Release 3GPP Rel8
Licence Control in NE RNC LK

RAN2302
Dynamic HSUPA BLER

RAN2302 - Dynamic HSUPA BLER
Without the feature, HSUPA BLER target in Outer Loop Power Control (OLPC) in RNC is constant
regardless to the radio transmission conditions, nature of the traffic (Continuous, Bursty , Peak data rates)
and E-DCH TTI length (2ms, 10 ms)
Flexi BTS RNC

UE
Peak throughput
UE
Constant transmission (full buffer traffic),

UE
10% BLER target in OLPC
potentially lots of retransmission due to cell Bursty traffic
edge, causing increased UL Interference level

Dynamic HSUPA BLER is enabled with Parameter HSUPADynBLEREnabled (RNFC)

In Setup and reconfiguration phase, OLPC controller shall receive a set of HSUPA
BLER target values and max rate for each RBs. Earlier only one target value was
send to OLPC.
Connections with Apply Low BLER Target to allow a further increase in

high throughput throughput
Connections with Apply moderate BLER Target to help improve latency

bursty activity i.e. Reduced requirements for re-transmission
Other Connections Apply Higher BLER Target to optimise cell capacity and
coverage

RAN2302 - Dynamic HSUPA BLER, cont.
Optimized BLER target for different user scenarios and radio

conditions:
Close to BTS: optimizing BLER to get peak data rates
Cell edge continuous data transmission: optimizing radio
coverage and cell capacity
Bursty traffic: optimizing latency
HSUPA BLER target in outer loop power control in RNC is

dynamically adjusted to optimize the operating point for the
above different conditions.
BLER target is automatically adjusted to achieve best HSUPA

peak data rates and optimize HSUPA cell throughput &
coverage.
RAN2302
Not activated
BLER target is fixed to 10% on first transmission (1st Tx) and on every ReTx
regardless to:
UE scenario: UE - BTS distance (cell edge / close to the BTS / peak data rates)
Nature of traffic: Bursty / continuous data transmission
E-DCH TTI length: 2ms / 10ms
HSUPA Non-Real Time traffic
10%BLER target on 1st Tx

HSUPA Capacity gain*: ~ 20%

RAN2302 HSUPA Coverage gain*: ~ 2dB
Activated
*Preliminary gain figures from simulations, not
commercially bounding
OLPC in RNC enhanced, BLER target for HSUPA NRT traffic varies depending on UE scenarios:
Close to BTS (peak data rates): minimized BLER to maximize UE peak data rates for bursty or continuous
data flow
Bursty data transmission not close to peak data rates: optimizing latency
Continuous data transmission not close to peak data rates: optimizing radio coverage and cell capacity
HSUPA Non-Real Time traffic
2msTTI:
10% BLER on 1% BLER on
2 nd ReTx * 1 st ReTx *
10%BLER on
1st ReTx*
10ms TTI:
20% BLER on
1 st ReTx *
*Example values. BLER target and the target number of

Retransmissions for Block Error detection are configurable
Parameters
Full name Parameter Object
HSUPA Dynamic BLER Enabled HSUPADynBLEREnabled RNFC
Peak rate threshold for bursty data of Dyn HSUPA BLER DynHSUPABLERMaxRateThrB RNAC
Peak rate thr for cont data of Dyn HSUPA BLER 2 ms TTI DynHSUPABLERMaxRateThrC2 RNAC
Peak rate thr for cont data of Dyn HSUPA BLER 10 ms TTI DynHSUPABLERMaxRateThrC10 RNAC
Bursty Data throughput threshold per TTI DynHSUPABLERThrBurstyTP RNAC
Bursty Period for Dyn HSUPA BLER DynHSUPABurstyPeriod RNAC
Window size for FP Frames Measurement DynHSUPABLERFrameWinSiz RNAC
Layer1 Peak Data Rate BLER target for E-DCH L1PeakRateBLERTrgtEDCH RNAC
Layer1 Bursty Data BLER target for E-DCH L1BurstDataBLERtrgtEDCH RNAC
Layer1 Continuous BLER target for E-DCH TTI 2 ms L1ContBLERTrgtEDCH2 RNAC
Layer1 Continuous BLER target for E-DCH TTI 10 ms L1ContBLERTrgtEDCH10 RNAC
Retransmissions in Dyn HSUPA BLER for Peak data DynHSUPABLERPeakRateRx RNAC
Retransmissions in Dyn HSUPA BLER for Bursty Data DynHSUPABLERBurstDataRx RNAC
Retransmissions in Dyn HSUPA BLER for Cont Data 2 ms TTI DynHSUPABLERContDataRx2 RNAC
Retransmissions in Dyn HSUPA BLER for Cont Data 10msTTI DynHSUPABLERContDataRx10 RNAC

Parameters, cont.
HSUPADynBLEREnabled:
Range: Disabled (0), Enabled (1) ; Default = Disabled (0) ;
This parameter Enables/Disables the Dynamic adjustment of HSUPA BLER
DynHSUPABLERMaxRateThrB:
Range: 10..100, step 1; Default = 75 (75%) ;
Defines peak rate threshold in relation to UE max data rate. Parameter is used by the dynamic HSUPA
BLER algorithm. Outer loop power control of the RNC applies the parameter when UE is currently using
bursty data. If current throughput exceeds value of the parameter then OLPC is configured to use the peak
data rate configuration.
DynHSUPABLERMaxRateThrC2 :
Defines peak rate threshold in relation to UE max data rate when E-DCH TTI = 2 ms. Parameter is used by
the dynamic HSUPA BLER algorithm. Outer loop power control of the RNC applies the parameter when UE
is currently using continuous data.
DynHSUPABLERMaxRateThrC10:
Defines peak rate threshold in relation to UE max data rate when E-DCH TTI = 10 ms. Parameter is used
by the dynamic HSUPA BLER algorithm. Outer loop power control of the RNC applies the parameter when
UE is currently using continuous data.
DynHSUPABLERThrBurstyTP:
Range: 10..100 frame, step 10 frame; Default = 10 frame ;
Defines the throughput threshold in number of FP frames per TTI (10ms). It is used by the outer loop power
control of the RNC to check the bursty data rate condition for Dynamic HSUPA BLER. In case of 2ms TTI,
this same parameter is used with multiple of 5.
Parameters, cont.
DynHSUPABurstyPeriod:
Range: 0..5 s, step 0.1 s; Default = 2 s ;
Defines min period which the BLER state must be bursty before outer loop power control state can be
changed from the bursty BLER state to continuous BLER state, or from peak or continuous BLER state to
bursty BLER state. It is allowed to change BLER state from bursty or continuous BLER state to the peak
BLER state without waiting for the expiration of the timer set by the parameter DynHSUPABurstyPeriod.
Change from peak BLER state to bursty or continuous BLER state is performed if throughput falls below
DynHSUPABLERMaxRateThrB or DynHSUPABLERMaxRateThrC10/ DynHSUPABLERMaxRateThrC2,
correspondingly and condition has been valid time defined with the parameter DynHSUPABurstyPeriod.
DynHSUPABLERFrameWinSiz:
Range: 0.1..5 s, step 0.1 s; Default = 1,5 s ;
This parameter defines the size of the sliding averaging window for FP frames measurement of the E-DCH
FP. The measurement measures the number of FP frames transmitted by the E-DCH FP during the sliding
measurement window. The value 0 of the parameter means that the E-DCH FP frames measurement is not
performed.
L1PeakRateBLERTrgtEDCH:
Range: -2..0, step 0.1; Default = -1.3 (5% BLER) ;
Defines L1 BLER target for the E-DCH MAC-d flow of PS NRT service. It is used by the OLPC of the RNC
for peak data rate Value of the parameter equals to the log10 of the BLER value10^-1.3 = 0.05 i.e. BLER
target is 5% (default setting).
L1BurstDataBLERtrgtEDCH:
Range: -2..0, step 0.1; Default = -1 (10% BLER) ;
Defines L1 BLER target for the E-DCH MAC-d flow of PS NRT service. It is used by the OLPC of the RNC
for bursty data. Value of the parameter equals to the log10 of the BLER value. 10^-1 = 0.1 i.e. BLER target
is 10%
Parameters, cont.
L1ContBLERTrgtEDCH2:
Range: -2..0, step 0.1 ; Default = -1 (10% BLER) ;
Defines L1 BLER target for the E-DCH MAC-d flow of PS NRT service when TTI = 2 ms. It is used by the
OLPC of the RNC for continuous transmission that provides better throughput and coverage. Value of the
parameter equals to the log10 of the BLER value.10^-1 = 0.1 i.e. BLER target is 10%. High BLER values
increase latency due to HARQ retransmissions in L1. When E-DCH TTI = 2 ms is used latency increase is
however small because HARQ period is 16 ms
L1ContBLERTrgtEDCH10:
Range: -2..0, step 0.1; Default = -0.7 (20%BLER) ;
Defines L1 BLER target for the E-DCH MAC-d flow of PS NRT service when TTI = 10 ms. It is used by the
OLPC of the RNC for continuous transmission that provides better throughput and coverage. Value of the
parameter equals to the log10 of the BLER value. 10^-0.7 = 0.199 i.e. BLER target is 20%. High BLER
values increase latency due to HARQ retransmissions in L1, especially this is valid when E-DCH TTI = 10
ms is used.
DynHSUPABLERPeakRateRx:
Range: 1..3, step 1; Default = 1;
Defines the L1 HARQ retransmissions threshold for the OLPC entities dedicated to the E-DCH MAC-d flows
of the PS NRT RABs. Its value is used by the OLPC of the RNC for the detection of the block error when
the L1 BLER target is defined with the management parameter "Layer1 Peak Data Rate BLER target for E-
DCH". Block error occurs if the number of the retransmissions equals to or is bigger than the value of the
parameter or an E-HARQ failure has been observed. OLPC adjusts the UL DPCCH SIR target after block
errors occurs.

Parameters, cont.
DynHSUPABLERBurstDataRx:
Defines the L1 HARQ retransmissions threshold for the OLPC entities dedicated to the E-DCH MAC-d flows
of the PS NRT RABs. Its value is used by the OLPC of the RNC for the detection of the block error when
the L1 BLER target is defined with the management parameter "Layer1 Bursty Data BLER target for E-
DCH".
DynHSUPABLERContDataRx2:
Defines the L1 HARQ retransmissions threshold for the OLPC entities dedicated to the E-DCH 2 ms TTI
MAC-d flows of the PS NRT RABs. Its value is used by the OLPC of the RNC for the detection of the block
error when the L1 BLER target is defined with the management parameter "Layer1 Continuous BLER target
for E-DCH".
DynHSUPABLERContDataRx10:
Defines the L1 HARQ retransmissions threshold for the OLPC entities dedicated to the E-DCH 10 ms TTI
MAC-d flows of the PS NRT RABs. Its value is used by the OLPC of the RNC for the detection of the block
error when the L1 BLER target is defined with the management parameter "Layer1 Continuous BLER target
for E-DCH".

Triggers
Yes No UE has Continues 10ms TTI data
EDCH Data Rate > Peak Rate threshold*
A transmission (not close to peak rates)
BLER target to be used is
L1ContBLERTrgtEDCH10 after
UE close to Peak rate (Bursty
DynHSUPABLERContDataRx10
data or Continuous data). retransmissions
L1PeakRateBLERTrgtEDCH
after
DynHSUPABLERPeakRateRx
No
retransmissions Number of frames per TTI < Bursty Data
throughput threshold per TTI (10ms or 2ms)**
B
Yes
2ms 10ms
E-DCH TTI
UE has Bursty data
transmission (not close to
peak rates)
UE has Continues 2ms TTI data
transmission (not close to peak rates)
L1BurstDataBLERTrgtEDCH
after BLER target to be used is
DynHSUPABLERBurstRateRx L1ContBLERTrgtEDCH2 after
retransmissions DynHSUPABLERContDataRx2
retransmissions

Triggers, cont.
A
Peak Rate threshold - depending on the current UE transmission constraints:
Bursty data tramsmission, or
Continuous 10ms TTI transmission, or
Continuous 2ms TTI transmission
one of the following data rate thresholds is used by the Dynamic HSUPA BLER algorithm to
decide whether UE is close to Peak data rates,
Peak rate threshold for Bursty data rates (DynHSUPABLERMaxRateThrB), or
Peak rate threshold for Continuous 10ms TTI transmission
(DynHSUPABLERMaxRateThrC10), or
Peak rate threshold for Continuous 2ms TTI transmission (DynHSUPABLERMaxRateThrC2)
B
Bursty Data throughput threshold per TTI (10ms or 2ms) it is the threshold parameter
(DynHSUPABLERThrBurstyTP) referred in Frame Protocol (FP) frames per TTI (10ms),
used by the Dynamic HSUPA BLER algorithm to decide whether UE is having bursty data
rates or continuous data rates

Triggers
Dynamic HSUPA BLER algorithm is started after the Averaging Sliding Window for Frame Measurement is full. Prior to that
Dynamic HSUPA BLER algorithm is not used and BLER target for OLPC is given with L1BurstDataBLERTrgtEDCH*
parameter after DynHSUPABLERBurstRateRx retransmissions
Size of Window for Frame Measurement is configurable via parameter DynHSUPABLERFrameWinSiz. Within Measurement
Window, the Frame Protocol (FP) frames are counted and the measured average number of FP frames per TTI is compared
to threshold parameter (DynHSUPABLERThrBurstyTP) to decide whether transmission is bursty
Continuous data transmission: average number of Bursty data transmission: average number of FP
FP frames per TTI from Window for Frame frames per TTI from Window for Frame
Measurement is higher than threshold parameter Measurement is higher than threshold parameter
DynHSUPABLERThrBurstyTP DynHSUPABLERThrBurstyTP
Single FP frame
Sliding Window for Frame Measurement Sliding Window for Frame Measurement
* L1BurstDataBLERTrgtEDCH (Layer1 Bursty Data BLER target for E-DCH) is a BLER target used when Dynamic HSUPA BLER
algorithm is in Bursty state (not close to Peak Rates)

Activation
Restart of the RNC and the BTS is not required after activation of this feature
This procedure does not cause downtime and the feature can be activated at any time
1. Configure the following RNFC parameter
Set the HSUPADynBLEREnabled to Enabled.
2. If necessary, configure the following RNAC parameters
a) Layer1 Peak Data Rate BLER target for E-DCH by setting the L1PeakRateBLERTrgtEDCH
b) Layer1 Bursty Data BLER target for E-DCH by setting the L1BurstDataBLERTrgtEDCH
c) Layer1 Continuous Data BLER target for E-DCH TTI=2 ms by setting the L1ContBLERTrgtEDCH2
parameter
d) Layer1 Continuous Data BLER target for E-DCH TTI 10 ms by setting the L1ContBLERTrgtEDCH10
e) L1 HARQ retransmissions threshold for the outer loop power control entities dedicated to the E-DCH
MAC-d flows of the PS NRT RABs by setting the DynHSUPABLERPeakRateRx
f) L1 HARQ retransmissions threshold for the outer loop power control entities dedicated to the E-DCH
MAC-d flows of the PS NRT RABs by setting the DynHSUPABLERBurstDataRx
g) L1 HARQ retransmissions threshold for the outer loop power control entities dedicated to the E-DCH 2
ms TTI MAC-d flows of the PS NRT RABs by setting the DynHSUPABLERContDataRx2

Activation
h) L1 HARQ retransmissions threshold for the outer loop power control entities dedicated
to the E-DCH 10 ms TTI MAC-d flows of the PS NRT RABs by setting the
DynHSUPABLERContDataRx10
i) peak rate threshold for bursty data of Dynamic HSUPA BLER by setting the
DynHSUPABLERMaxRateThrB
j) peak rate threshold in relation to UE max data rate when E-DCH TTI=10 ms by setting
the DynHSUPABLERMaxRateThrC10 parameter
k) peak rate threshold in relation to UE max data rate when E-DCH TTI=2 ms by setting the
DynHSUPABLERMaxRateThrC2
l) minimum period which the BLER state must be bursty before outer loop power control
state can be changed from the bursty BLER state to continuous BLER state, or from
peak or continuous BLER state to bursty BLER state by setting the
DynHSUPABurstyPeriod
m) size of the sliding averaging window for FP frames measurement of the E-DCH FP by
setting the DynHSUPABLERFrameWinSiz
n) Time to trigger Dyn HSUPA BLER Algorithm by setting the
DynHSUPABLERAlgTrgTime

WCDMA Release RU40

RNC Release RN7.0
BTS (Flexi) WBTS 8.0
HW Requirements Flexi Rel2 or 3
UE Release 3GPP Rel8

RAN2494
Fast Cell_PCH Switching

RAN2494 - Fast Cell_PCH Switching
Faster Cell_DCH state transitions - 350ms target
This feature reduces the state

transition times from cell_PCH and
Cell-DCH Signaling load is
Cell_FACH states lightened due to shorter
In transition to Cell_DCH only the Optimized / compressed signaling messages
new configuration parameters are UE message support*
delivered, otherwise previous Faster setup times

configuration information is used Cell-FACH Parallel signaling
Enhanced parallel process activation processing reduces the
reduces state transition time Optimized / compressed
UE message support * state transition time
RRC signaling is started in parallel
with reservation of RNC L2 Improved end user
Cell-PCH experience
resources
* UE message optimization can be applied mainly when

newly allocated configuration is the same as previous

RAN2494 - Fast Cell_PCH Switching, cont.
Benefits
End-user benefits
This feature benefits the end user by decreasing state transition
time to Cell_DCH state and thus improving the end-user
experience, for example, in case of web browsing.
Operator benefits
Network signaling load is lightened due to shorter signaling
messages. With keep-alive messages faster setup time means
lower number of UEs with signaling ongoing per RNC at a time

RNC
RNC resources optimization
RAN2494
RAN2494 Activated RNC resources are
Not activated utilized more efficient
BTS
BTS UE
UE
Some IEs can be skipped
All IEs are sent RRC messages can be smaller
Messages can be send faster

Functional overview
There are several enhancements that allow to decrease state transition time:
When state transition to Cell_DCH is triggered, RNC checks previous configuration used by
the UE and sends only new configuration parameters. With this approach some information
elements (IEs) may be avoided in the RRC signaling (for example RB-Mapping-Info, RLC-
Info or UL/DL Add Reconfigure Transport Channel Info List). It results in smaller message
size and subsequently shorter overall state transition time.
RNC internal signaling is improved and optimally implemented. RRC signaling is started in
parallel with reservation of RNC L2 resources, which reduces state transition time.
Optimization of UE message is applied mainly in cases where newly allocated configuration
is the same as previous configuration already stored at the UE.
Fast Cell_PCH Switching can be restricts to groups of users
None UEs support RAN2494
Only UEs Rel-5 and newer supports RAN2494
Rel99 / HSDPA Cat. 1 and higher
Only UEs Rel-6 and newer support RAN2494
HSUPA Cat 1 and higher / HSDPA Cat. 1 and higher
All UEs support RAN2494
Cell_DCH to Cell_FACH
Cell_PCH to Cell_FACH
Cell_PCH to Cell_FACH
Following IE can be skipped
RB-mapping-Info UE NodeB RNC
UL/DL Transport Channel to Delete List RRC: PagingType1
RRC: CellUpdate
Messages affected
RRC: CellUpdateConfirm
RRC Radio Bearer Reconfiguration Request RRC: UtranMobilityInformationConfirm
RRC Cell Update Confirm
Cell_DCH to Cell_FACH
Cell_DCH UE NodeB RNC
RRC: RadioBearerReconfiguration
Cell_FACH
RRC: RadioBearerReconfigurationComplete
NBAP: RadioLinkDeletionRequest
Cell_PCH
NBAP: RadioLinkDeletionResponse
IDLE_Mode

Cell_PCH to Cell_DCH Cell_PCH to Cell_DCH

Cell_FACH to Cell_DCH UE NodeB RNC
RRC Connection Re-establishment RRC: PagingType1
RRC: CellUpdate
Following IE can be skipped RRC: CellUpdateConfirm

RB-mapping-Info NBAP: RadioLinkSetupRequestFDD
RLC-Info NBAP: RadioLinkSetupResponseFDD
UL/DL Transport Channel Add Reconfigure List RRC: RadioBearerReconfigurationComplete
Messages affected RRC: MeasurementControl
NBAP: RadioLinkRestoreIndication
RRC Radio Bearer Reconfiguration Request
RRC Cell Update Confirm
Cell_FACH to Cell_DCH
UE NodeB RNC
Cell_DCH RRC: MeasurementReport
NBAP: RadioLinkSetupRequestFDD
Cell_FACH
NBAP: RadioLinkSetupResponseFDD
Cell_PCH RRC: RadioBearerReconfiguration

RRC: RadioBearerReconfigurationComplete
IDLE_Mode RRC: MeasurementControl
NBAP: RadioLinkRestoreIndication

RLC parameters for new radio link RLC parameters for new radio link
are identical as previous one are not identical as previous one
RLC configuration does not need to change

RLC configuration is done in legacy way
or
Existing RLC configuration is used during radio link setup
and then in Cell_DCH RLC parameters are reconfigured
Cell_DCH
RLCConfOptionFPS parameter defines which option is

Cell_FACH
used
Cell_PCH RLC parameters
reconfigured
in Cell_DCH
IDLE_Mode
Cell_DCH
Cell_FACH
Cell_PCH
IDLE_Mode

No Fast Cell_PCH Switching Fast Cell_PCH Switching
UE RNC UE RNC
Cell_PCH Cell_PCH
RRC: Cell Update RRC: Cell Update
RNC processing RNC processing
RRC Cell Update Confirm sent

RRC Cell Update Confirm RRC: Cell Update Confirm +
ready to send
RNC resources reservation
Waiting for RNC

resources reservation Cell_FACH/Cell_DCH RNC resources reservation
RRC: Cell Update Confirm
Cell_FACH/Cell_DCH

Measurements and counters

There are no new measurements and counters related to this feature,
existing counters related to this feature:
M1006C174 STATE TRANSITION TIME PCH TO DCH RRC signalling (RNC)
M1006C175 DENOMINATOR FOR STATE TRANSITION TIME PCH TO DCH RRC signalling (RNC)
New parameters:
Abbreviated name Full name Managed object
RLCConfOptionFPS RLC Conf option switch for Fast Cell_PCH Switching RNRLC
FastPCHSwitchEnabled Enabling Fast Cell_PCH Switching Service feature RNFC
DCHtoPCHEnabled Enabling direct Cell_DCH to PCH state transition RNFC
MACLogicalChPriority MAC logical channel priority definition RNC
MACLogChPriSRB1 MAC logical channel priority for SRB1 RNC
AMRLCSRB3n4PeriodMax AM RLC status period max for SRB3 and SRB4 RNRLC
AMRLCSRB3n4RespTime AM RLC round trip time for SRB3 and SRB4 RNRLC

Key performance indicators:

There are no key performance indicators related to this feature.
Existing counters related to this feature:
M1006C174:
Sum of state transition times from Cell-PCH or URA-PCH state to Cell-DCH state, defined as the time between:
RRC: Cell Update (cause: UL Data Transmission or Paging response) - RRC: Radio Bearer Reconfiguration
Complete.
When the RNC receives RRC: Radio Bearer Reconfiguration Complete.
M1006C175:
Denominator for M1006C174 used for average calculation (average state transition time). Updated by value 1,
then the measured time is updated to counter M1006C174.
New parameters:
RLCConfOptionFPS:
Range: Legacy way (0), Optimized RLC reconfiguration (1); Default: Optimized RLC reconfiguration (1)
RNC defines RLC parameters for new radio link based on the used service of the UE during RRC state transition
from CELL_PCH to CELL_DCH. If the RLC parameters defined for the new radio link are identical with the previous
RLC configuration, then RLC configuration does not need to change in UE or RNC RLC entity when Fast Cell_PCH
Switching functionality is applied. If Fast Cell_PCH Switching functionality is applied and the RLC parameters
defined for the new radio link are not identical with the previous RLC configuration, then there are two options.
The first option is that RLC parameter configuration is done in the legacy way. The second option is that the
existing RLC configuration is used during radio link setup and then RLC parameters are reconfigured when UE is in
cell_dch state. This parameter is used to select the option. RLCConfOptionFPS parameter is used to select the
option .
FastPCHSwitchEnabled:
Range and step: 0 (Disabled),
1 (Functionality is enabled only for rel-5 and newer),
15 (Functionality is enabled for all UEs)
Default value: 0
This parameter enables/disables the RAN2494 (Fast Cell_PCH Switching) feature. Fast Cell PCH
Switching feature attempts to make faster transition from Cell/URA_PCH / Cell_FACH to Cell_DCH.
DCHtoPCHEnabled:
Range and step: 0 (Disabled), 1 (Enabled); Default value: 1.
This parameter defines whether direct transition from Cell_DCH to Cell_PCH is allowed or not.
MACLogicalChPriority:
This parameter defines MAC logical channel priority for Signalling Radio Bearers SRB1, SRB2 and SRB3.
The MAC logical channel priority for SRB1, SRB2 and SRB3 can be defined based on domain and Traffic
Class (TC) . These priorities are values in the range of 1 - 3. (1 is the highest and 3 is the lowest priority).
For example, see the following prioritization orders:
Priority Default Config#1
1 SRBs (1-3) SRB 1
2 - SRB 2
3 - SRB 3
MACLogChPriSRB1:
Range and step: 1..3, step 1; Default value: 1:
This parameter defines MAC logical channel priority for Signalling Radio Bearer1 (SRB1).
MACLogChPriSRB2:
This parameter defines MAC logical channel priority for SRB2
MACLogChPriSRB3:
This parameter defines MAC logical channel priority for SRB3
AMRLCSRB3n4PeriodMax :
Range and step: 1..600 %, step 1 %; Default value: 112 %.
This parameter defines the maximum status reporting period of the AM RLC in relation to the RLC round
trip time for SRB3 and SRB4 for all kinds of variations of transport channel used or SRB bitrate .
AMRLCSRB3n4RespTime:
Range and step: 0..1500 ms, step 10 ms; Default value: 100 ms;
The parameter defines the AMRLC Round Trip Time (RTT) for the data transfer for SRB3 and SRB4 for all
kinds of variations of transport channel used or SRB bitrate. It is used to estimate the average response
time from the moment when the AM RLC entity sends an AMD PDU to its peer entity with the poll bit set to
the receiving moment of the corresponding status PDU. The RTT depends on the L1/L2 processing delay of
the UE and the RNC, type of the reverse transport channel - DCH, HS-DSCH or E-DCH, processing delay
of the BTS, the Uu interface delay, and the Iub transfer delay. The parameter is used to define the AM RLC
status reporting and polling period lengths .
WCDMA Release RU40

RNC Release RN7.0
OMS RNO 2.0 (for IPA-RNC and mcRNC)
IHO 5.0 (for Flexi Direct)

RAN2509
Application Aware RAN (AAR)

RAN2509 - Application Aware RAN
Dynamic service or application prioritization for HSPA scheduling leading

to an enhanced user application experience
DPI marks the inner IP

packet DSCP value
according to the
Traffic type and/or operators chosen
activity triggers a policies
change of SPI
SPI RNC
NodeB MAC-d
weight
flows
8 DPI
HSPDA 7 Inspection and inner
scheduler PDCP IP packet Marking
GTP-U
0 SPI-mod RLC GTPU
IP/UDP
MAC Same Bearer Same Bearer
in FP IP IP
FP FP
Change
scheduling
weights The target SPI
associated with value is sent with
the mac-d flow the HSPA
scheduler interval

RAN2509 - Application Aware RAN, cont.
Application differentiation provides an operator the quality of service tools

necessary to provide an enhanced user experience
The 3GPP bearer-based QoS differentiation model is typically not widely
supported by current terminals that connect using a single PDP context
carrying all applications within one bearer i.e. not multi-rab
Subscriber level QoS does not separate different applications within a
single bearer although each application has different requirements when
utilizing a bearer
AAR optimizes the scheduler behavior according to policies defined by the
customer for every class of traffic
Using AAR an operator could allocate a bronze users web session a
higher priority than a gold users FTP download
A slower FTP download would not impact the user experience as much as
a slow web session
The action depends on the traffic carried by the RAB at the specific time
and the action is not permanent but transient
HSPA
DCH NRT
RT
HSPA
Strea
ming Operator
policy
Optimal capacity
sharing

RAN2509 - Application Aware RAN, cont.
Decreasing the priority of peer-to-peer traffic to a lower class is particularly useful
as the decreased traffic share frees up cell capacity for other traffic during peak
hour.
Using the same system capacity an operator can now provide end users a better
application experience
Capacity is shared between users in an optimal manner
Core-network-based Deep Packet Inspection (DPI) provides application detection
by marking the inner (user) IP packet with Differential Service Code Point (DSCP)
values
The SPI of the radio bearer is promoted/demoted at PDCP level according to the
DPI marking
The priority information is transferred from the RNC to the BTS scheduler via the
user plane by using the Common Channel Priority Indication (CCPI) in the frame
protocol (FP)
The dynamic SPI priority change in the BTS comprises the following new functions:
dynamic change of HSDPA scheduling priority for each MAC-d priority queue
dynamic change of HSUPA scheduling priority together with DL priority
reflecting dynamically changed priority by modifying radio interface credit
allocations for both congested or non-congested radio interfaces

RAN763 Basic HSDPA with QPSK and 5 Codes
FC085_001011 DSCP Marking for Services (Flexi NG)
Optional features:
RAN1231 HSPA over Iur (required if this feature needs to be supported over Iur)
RAN1110 HSDPA Congestion Control
RAN 1262 QoS Aware HSPA Scheduling
RAN2509
Application Aware Ran
RAN763
FC085_001011 DSCP
Basic HSDPA with QPSK
Marking for Services
and 5 codes
RAN1231 RAN1110 RAN1262

HSPA over IUR HSDPA Congestion QoS Aware HSDPA
Control Scheduling

Pictorial representation of the PDCP Protocol

EF Expedited forwarding Strict priority e.g. CS Voice, Video and CS

Streaming Normally DSCP 46
AF - Assured Forwarding Each class is assigned a drop precedence
Assured Forwarding (AF) Behavior Group
Class 1 (lowest) Class 2 Class 3 Class 4 (highest)
Low Drop AF11 (DSCP 10) AF21 (DSCP 18) AF31 (DSCP 26) AF41 (DSCP 34)
Med Drop AF12 (DSCP 12) AF22 (DSCP 20) AF32 (DSCP 28) AF42 (DSCP 36)
High Drop AF13 (DSCP 14) AF23 (DSCP 22) AF33 (DSCP 30) AF43 (DSCP 38)
BE - Best Effort - DSCP 0

IPV4 Header Structure
Differentiated Services Code Point (DSCP)

Originally defined as the Type of Service field, this field is now defined by RFC 2474
for Differentiated services (DiffServ).
New technologies are emerging that require real-time data streaming and therefore
make use of the DSCP field.
An example is Voice over IP (VoIP), which is used for interactive data voice exchange

Byte -1 Contents
Bits Meaning DS Field Value IP
DSCP
Precede
Bits 8-10 IP Precedence: Name Binary Decimal nce
111 Network Control
EF 101 110 46 5
110 Internetwork Control
101 Critic/ECP
AF11 001 010 10 1
100 Flash Override
AF12 001 100 12 1
011 Flash
AF13 001 110 14 1
010 Immediate
001 Priority
AF21 010 010 18 2
000 Routine
AF22 010 100 20 2
1 = Low Delay; 0 = Normal
Bit 11 Delay AF23 010 110 22 2
1 = High Throughput; 0 =
Bit 12 Normal Throughput AF31 011 010 26 3
1 = High Reliability; 0 = AF32 011 100 28 3
Bit 13 Normal Reliability AF33 011 110 30 3
1 = Minimise monetary cost
Bit 14 (RFC 1349)
AF41 100 010 34 4
Bit 15 Must be 0
AF42 100 100 36 4
AF43 100 110 38 4

Release Information
RAS Release - RU40

RNC Release - RN7.0

Licence Feature Code = 3422

Parameters:
Object = RNHSPA:
InitialSPINRT
Defines the initial SPI to be used for a PS NRT HSPA or HSDPA RAB
The InitialSPINRT parameter is used when QoS Aware Scheduling is not used and
Application Aware RAN is enabled
AARConfig Table Item List
AppGrpId
Identifies the application group that the parameters will be applied to
All applications in the group receive the same treatment
Up to six application groups can be defined
DSCPCode
Defines the DSCP value assigned within the specific application group
Up to five DSCP values can be assigned within each application group ID

AARConfig Table Item List continued

Precedence
Defines the precedence assigned to the specific application group
Used to decide what SPI should be prioritized when packets belonging to multiple
application groups are detected by the RNC
Up to six precedence values are possible
Precedence = 1 has highest priority and Precedence = 6 has lowest priority
TargetSPIforSPI0 to TargetSPIfor SPI11
Defines the value of the target SPI chosen for a specific application group having an
initial SPI value in the range 0 to 11
Based on this value a new SPI is assigned to a specific application group after
promotion or demotion.
It the Target SPI is the same as the initial SPI then there will be no change to the
SPI
Object = WCEL
AppAwareRANEnabled
Defines whether AAR is used in the cell or not

AppAwareRANCapability
This parameter is set by the system and indicates the AAR capability of the cell
It is not modifiable
Object = IUR
AppAwareRANEnabled
Defines whether AAR is enabled in the DRNC or not
This value is checked when the serving HSDPA/HSPA cell is under a drift RNC
When enabled it is assumed that all BTSs under the drift RNC support AAR
(RAN2509)
Object = RNC
DSCPStatisticsGroupA
Defines what IU-PS GTP user data is mapped to counter M1022C227-IUPS DSCP
CLASS A
The values of DSCP that the operator chooses to monitor in a cell are set
DSCPStatisticsGroupB
CLASS B
DSCPStatisticsGroupC
CLASS C
DSCPStatisticsGroupTCPack
Defines what IU-PS GTP user data is mapped to counter M1022C225-DL TCP
ACKS
The values of DSCP that the operator chooses to use for DL TCP ACKS for specific
UL data

Activating Application Aware RAN:

Ensure that HSPA/HSDPA is correctly enabled
Set WCEL parameter - AppAwareRANEnabled to Enabled

Activating Application Aware RAN:

If QoS Aware Scheduling will be used with AAR ensure set the WCEL parameter
HSPAQoSEnable parameter to QoS prioritization is used for HS NRT channels

If QoS will not be used with AAR set the value of RNHSPA parameter
InitialSPINRT to the desired value 5 or 6
Configure the RNHSPA object Application Aware RAN Configuration

Table according to the CN values
If AAR will be used over the IUR set the IUR parameter
AppAwareRANEnabled to Enabled

RAN2179
Dual Band HSDPA 42Mbps

RAN2179 - Dual Band HSDPA 42Mbps
Dual Band HSDPA 42Mbps allows data scheduling in the downlink

on two different frequency bands
DC-HSDPA DL transmission options DB-HSDPA DL transmission options

2 x 5 MHz 2 x 5 MHz 2 x 5 MHz
f1 f2 f1 f2 f1 f2
U2100 U900
U2100 U900
SC-HSDPA DL transmission options
5 MHz 5 MHz
f1 f1
U2100 U900

RAN2179 - Dual Band HSDPA 42Mbps, cont.
Dual Band HSDPA schedules data for capable UE on two different frequency
bands in the downlink
The maximum peak rate is 42 Mbps when 64QAM is enabled and 15 codes are
available on both frequencies
MIMO is not supported simultaneously with Dual Band HSDPA
The BTS uses proportional fair scheduling
Sector coverage and capacity is optimized by favoring the low-frequency band
for cell-edge UEs and the high-frequency band for UEs closer to the BTS
allowing Dual Band HSDPA to combine the gain of normal Dual Cell HSDPA
scheduling as well as the benefits of a low frequency band for cell border
users
The carrier selection is based both on UE distance and current load of both uplink
carriers
By using the RAN2172: Multi-Band Load Balancing feature for carrier selection it is
possible to define what layer Dual Band HSDPA or Dual Cell HSDPA the UE is
directed to if it capable of supporting both features


Allowed RAB Combinations:

DB-HSDPA supports the same RAB combinations as DC-HSDPA
1 to 3 NRT Interactive or Background RABs mapped to HSPA
DB-HSDPA is not allocated to a standalone SRB
Simultaneous RT PS RABs or CS RABs are not allowed
establishment triggers the release of DB-HSDPA
NRT RAB can be mapped to:
DL HS-DSCH and UL E-DCH
SRB can be mapped to:
DL HS-DSCH and UL E-DCH, or
DL DCH and UL E-DCH, or
DL DCH and UL DCH

Full DL throughput of 42Mbps is achieved with the allocation of all 15

SF16 codes and using 64QAM
Allowed frequency band combinations:

Dual Band Dual Cell Uplink Band Downlink Band
Configuration
1 2100 OR 900 2100 AND 900
2 1700 OR 1900 1700 AND 1900
3 2100 OR 850 2100 AND 850


RAN1906 Dual Cell - HSDPA (and all features required by RAN1906 DC-HSDPA)
RAN1016/RAN1848 - Flexi BTS Multimode System Module (FSMC/FSMD/FSME)
BTS RF Modules - Have to be Release 2 or newer
RAN1226 - HSPA Peak Rate Upgrade for RNC196 and RNC450
RAN1643 - HSDPA 64 QAM in order to achieve at maximum data rate of 42 Mbps
instead of 21 Mbps
RAN2179
Dual Band HSDPA
42Mbps
RAN1226 BTS RF module RAN1643

RAN1016/1848 HSPA Peak Rate must be Release 2
Flexi BTS Multimode HSDPA 64 QAM
Upgrade for RNC196 or newer
System Module and RNC450
FSMC/FSMD/FSME

Release Information
RAS Release - RU40
RNC Release - RN7.0
SGSN SG7.0

Activating Dual Band HSDPA 42Mbps:
Licence Feature Code 2118
Install a relevant RF module to the WBTS, load the software and configure the cells
etc
for IPA-RNC:
ZW7M:FEA=2118:ON;
for mcRNC and I-HSPA Adapter:
Set the DBandHSDPAEnabled parameter to Enabled
Repeat the steps for all the required cells.

RAN 1907
Dual Cell HSDPA with MiMo 84Mbps

RAN1907 - Dual Cell HSDPA with MiMo 84Mbps
Combines DC-HSDPA, MIMO and 64QAM to achieve 84 Mbps peak

rate in the DL


RAN1907 - Dual Cell HSDPA with MiMo 84Mbps,
cont.
DC-HSDPA and MIMO are used simultaneously
64QAM modulation can be used when radio conditions allow
UE reports 4 CQI/2 PCI values and 4 ACK/NACK indicators
Two values are reported on each carrier due to MIMO, and both carriers have
independent reporting to allow joint Dual Cell scheduling to be performed
MIMO scheduling on each carrier is independent
MIMO can be on dual stream mode on one carrier and on single stream mode on
other carrier
MIMO with 64QAM and Dual Cell are both specified in 3GPP Rel8, and
combining the two for 84 Mbps is allowed in Rel9
Dual Cell operation is restricted to adjacent carriers only in Rel9
No RT services are supported on DC-HSDPA
NRT RABs including nominal bit rate case can be mapped on DC HSDPA with
MIMO bearer
Due to very high throughput in DL, a minimum of 3 Mbps will be needed in UL


RAN1907 - Dual Cell HSDPA with MiMo 84Mbps,
cont.
HSDPA and MiMo can be used with 16QAM modulation for both HSDPA
and MiMo Maximum throughput = 56Mbps
DC HSDPA throughput without 64QAM modulation is 14Mbps +
14Mbps = 28Mbps
MiMo 2x2 DL throughput using Dual steam is 14Mbps + 14Mbps =
28Mbps
If HSPA 64QAM and MiMo 64QAM are used then the total throughput
can be 84Mbps
The WBTS configuration needs to be changed to support DC-HSDPA
with MiMo
The MiMo configuration needs to be added to the antenna configuration
When the WBTScells are reconfigured a maximum one cell pair
supporting DC-HSDPA with MiMo can be configured plus another 2 cells
2 Cells will use ant1 and ant3 for DC-HSDPA + MiMo and this will use
all the power and antenna ports for ant1 and ant3
2 Cells will use ant5 and this will then use all the ports/power available
for ant5


RAN1016: Flexi BTS Multimode System Module - FSMD
RAN1848: Flexi BTS Multimode System Module - FSME
RAN1642: MIMO 28 Mbps
RAN1643: HSDPA 64QAM
RAN1906: DC-HSDPA 42 Mbps
RAN1201: Fractional DPCH
RAN1907
DC HSDPA with
MIMO 84Mbps
RAN2261
RNC196/450 RAN1906 RAN1642 RAN1643 RAN1016/1848
RAN1912
Flexible User DC HSDPA MIMO HSDPA 64 Multimode SM
MIMO 42Mbps
Plane capacity 42Mbps 28Mbps QAM FSMD/FSME

Signalling:
The UE signals its combined DC-HSDPA with MIMO capability by inserting the Dualcell
MIMO support IE into the RRC Connection Request message
For a DC-HSDPA with MIMO capable cell, the NBAP Audit Response/Radio Resource
Indication message provides the capability of the BTS concerning the support of DC-
HSDPA in the Bitmap Cell Capability Container IE (one or each potential serving HS-
DSCH cell)
Cell-Capability-Container: '01000000 00000000 00000000 00000000 00000000 00000000 00000 000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000'B
Information Element Impacted Message or Information Element Info
The value 1 of a bit indicates that the corresponding

functionality is supported in a cell and value 0 indicates
NBAP: AUDIT RESPONSE
Cell Capability Container that the corresponding functionality is not supported in a
NBAP: RESOURCE STATUS INDICATION
cell. The second bitinforms about Multi Cell and MIMO
Capability.
This IE is used for initial addition of Secondary Serving HS-

DSCH information to a Node B Communication Context
HS-DSCH FDD Secondary Serving Information NBAP: RADIO LINK RECONFIGURATION PREPARE
and defines the cell specific parameters for the secondary
serving HS-DSCH Radio Link
This IE provides information for Secondary Serving HS-

HS-DSCH FDD Secondary Serving Information DSCH that have been established or modified. It also
NBAP: RADIO LINK RECONFIGURATION READY
Response provides additional HS-DSCH information determined
within the Node B.

Manangement Data:
M5000C424 SUM OF ACTIVE DC HSDPA MIMO USERS WITH TWO CARRIERS M5000 HSPA in
WBTS
M5000C425 SUM OF ACTIVE DC HSDPA MIMO USERS WITH ONE CARRIER M5000 HSPA in
WBTS
M5000C426 SUM OF CAPABLE DC HSDPA MIMO USERS M5000 HSPA in
WBTS
M5000C427 TTI SCHEDULED DC HSDPA MIMO USER FOR PRIMARY CARRIER WITH ONE CARRIER DUAL M5000 HSPA in
STREAM WBTS
M5000C428 TTI SCHEDULED DC HSDPA MIMO USER FOR PRIMARY CARRIER WITH ONE CARRIER SINGLE M5000 HSPA in
STREAM WBTS
M5000C429 TTI SCHEDULED DC HSDPA MIMO USER FOR SECONDARY CARRIER WITH ONE CARRIER M5000 HSPA in
DUAL STREAM WBTS
M5000C430 TTI SCHEDULED DC HSDPA MIMO USER FOR SECONDARY CARRIER WITH ONE CARRIER M5000 HSPA in
SINGLE STREAM WBTS
M5000C431 TTI SCHEDULED DC HSDPA MIMO USER WITH BOTH CARRIER DUAL STREAM M5000 HSPA in
WBTS
M5000C432 TTI SCHEDULED DC HSDPA MIMO USER WITH BOTH CARRIER DUAL AND SINGLE STREAM M5000 HSPA in
WBTS
M5000C433 TTI SCHEDULED DC HSDPA MIMO USER WITH BOTH CARRIER SINGLE AND DUAL STREAM M5000 HSPA in
WBTS
M5000C434 TTI SCHEDULED DC HSDPA MIMO USER WITH BOTH CARRIER SINGLE STREAM M5000 HSPA in
WBTS


M1001C709 ACCESS STRATUM RELEASE INDICATOR M1001 - Service Level
RELEASE 9 (RNC)
M1001C707) UE SUPPORT FOR HSDSCH CLASS 25 M1001 - Service Level
OR 26 (RNC
M1001C708 UE SUPPORT FOR HSDSCH CLASS 27 M1001 - Service Level
OR 28 (RNC)
M1022C223 CHANNEL SWITCH FROM DC-HSDPA TO M1022 - Packet Call
SC-HSDPA SUCCESSFUL (RNC)
M1022C224 CHANNEL SWITCH FROM SC-HSDPA TO M1022 - Packet Call
DC-HSDPA SUCCESSFUL (RNC)
Licencing:
Combination of 3 licenses:
RAN1906 - DC-HSDPA
RAN1642 - MIMO
RAN1643 - HSDPA 64QAM
RAN1201 Fractional DPCH

Release Information
RAS Release - RU40
RNC Release - RN7.0
IPA Platform - A14
SGSN - SG8.0
UE Release - 3GPP Rel-9 Category 25 28

Activating DC-HSDPA with MIMO 84Mbps:
RAN1907: DC-HSDPA with MIMO 84 Mbps feature needs the following features to be
activated before it can be enabled:
HSDPA (HSDPAenabled WCEL parameter)

HSUPA (HSUPAenabled WCEL parameter)
RAN828: HSDPA Serving Cell Change (HSDPAMobility RNC parameter)
RAN829: HSDPA Soft/softer Handover for Associated DPCH (HSDPAMobility RNC parameter)
RAN1201: Fractional DPCH (FDPCHEnabled WCEL parameter)
RAN1258: HSDPA 14 Mbps per User (HSDPA14MbpsPerUser WBTS parameter)
RAN1638: Flexible RLC (FRLCEnabled RNC parameter)
RAN852: HSDPA 15 Codes (HSPDSCHCodeSet WCEL parameter), additionally required by
RAN1906: Dual-Cell HSDPA 42 Mbps
RAN1470: HSUPA 2 ms TTI (HSUPA2MSTTIEnabled WCEL parameter), additionally required by
RAN1642: MIMO 28 Mbps (MIMOEnabled parameter)
RAN1906: Dual-Cell HSDPA 42 Mbps (DCellHSDPAEnabled WCEL parameter)

This feature can be activated by searching for the DCellHSDPAEnabled parameter, selecting
DC-HSDPA and MIMO w/o 64QAM enabled or DC-HSDPA and MIMO with 64QAM enabled
from the drop down menu and then selecting Apply

RAN2435
SRVCC from LTE and CSFB with HO

Single Radio Voice Call Continuity (SRVCC)

functionality enables continuity of voice
service (VoIP) to the CS domain when
changing from an LTE cell to a WCDMA cell.
UE moving from LTE coverage into WCDMA cell coverage area
WCDMA
coverage
LTE coverage

RAN2435 - SRVCC from LTE and CSFB with HO,
cont.
Introduction to the feature
Single radio voice call continuity (SRVCC) from LTE function allows for voice over IP (VoIP) call handover
from the LTE to the WCDMA as a normal CS voice call. Also CS Fallback from LTE function is supported.
This is handled by the UTRAN as an incoming inter-system relocation request from LTE to WCDMA in
the CS domain
CS fallback (CSFB) is initiated in the LTE layer when the UE is in connected mode with a PS connection
allocated and a CS call needs to be established but VoIP is not supported in LTE.
This is handled as a PS ISHO from LTE
CS voice is set up in the WCDMA layer after inter-system
CS fallback allows LTE deployment as a data-only network
Multi-RAB handovers (CS + PS RABs) from LTE to WCDMA are also supported, and all non-voice services
are handed over to the PS domain
Both SRVCC and CSFB are based on relocation procedures
The RNC requires that the UE history information is included in the RANAP RELOCATION REQUEST
message and that it indicates LTE as the originating system
The UE UTRAN capabilities must be included in the RANAP: RELOCATION REQUEST message or the
relocation attempt from the LTE is rejected
The Specification mode IE is set to Complete specification in the RRC HANDOVER TO UTRAN command
in case of inter-system handover (ISHO) from LTE
Complete specification means that complete RB/RL configuration information is sent to the UE instead of
preconfigured default configuration
During the SRVCC the multi-RAB combinations and transport channels combinations are the same as
currently supported in the RNC during ISHO.
RAN2067 - LTE Interworking (supports Idle Mode, Cell_PCH and URA_PCH mobility between WCDMA and LTE)
RAN2176 - LTE PS Handover (supports incoming PS HOs from LTE to 3G).
RAN1016/1848 - Flexi System Module Release 2 or 3 (FSMC, FSMD, FSME, FSMF)
LTE872 - SR Voice Call Continuity (seamless voice call handover from LTE to WCDMA)
LTE736 - CSFB to 3G via PSHO (HO of ongoing packet call when voice service is requested in E-UTRAN which does
not support VoLTE)
LTE56 - Inter-RAT Handover
Beneficial features:
RAN2717 Smart LTE Layering (moves active UEs to the LTE layer using RRC Connection Release with Redirection
command to LTE)
RAN2264 Smart LTE Handover (RU50) - allows handing over of UEs back to the LTE network after finishing a voice
call in WCDMA
RAN2717 (RU40)
RAN2435 RAN2264 (RU50)
Smart LTE Layering SRVCC from LTE and Smart LTE Handover
CSFB with HO
RAN2067 RAN2176 LTE872 LTE736 LTE56

RAN2382/1016/1848/2262 LTE LTE PS SR Voice Call CSFB to 3G Inter-RAT
Flexi BTS Multimode System Interworking Handover Continuity via PSHO Handover
Module
FSMC/FSMD/FSME/FSMF

New counters:
M1009C286 LTE CS HHO IN PREP FAIL DUE TO RNL L3 Relocation signalling (RNC)
M1009C288 LTE CS HHO IN PREP REQ L3 Relocation signalling (RNC)
M1009C289 LTE CS HHO IN PREP SUCC L3 Relocation signalling (RNC)
M1009C290 LTE CS HHO IN PREP FAIL DUE TO TRANS L3 Relocation signalling (RNC)
M1009C291 LTE CS HHO IN PREP FAIL DUE TO NAS L3 Relocation signalling (RNC)
M1009C292 LTE CS HHO IN PREP FAIL DUE TO PROT L3 Relocation signalling (RNC)
M1009C293 LTE CS HHO IN PREP FAIL DUE TO MISC L3 Relocation signalling (RNC)
M1009C294 LTE CS HHO IN PREP FAIL DUE TO NON STAN L3 Relocation signalling (RNC)
M1009C295 LTE CS HHO IN DETECT L3 Relocation signalling (RNC)
M1009C296 LTE CS HHO IN COMPLETE L3 Relocation signalling (RNC)
M1009C297 LTE CS FALLBACK IN PREP REQ L3 Relocation signalling (RNC)
M1009C298 LTE CS FALLBACK IN PREP SUCC L3 Relocation signalling (RNC)
M1009C299 LTE CS FALLBACK IN PREP FAIL DUE TO RNL L3 Relocation signalling (RNC)
M1009C300 LTE CS FALLBACK IN PREP FAIL DUE TO TRANS L3 Relocation signalling (RNC)
M1009C301 LTE CS FALLBACK IN PREP FAIL DUE TO NAS L3 Relocation signalling (RNC)
M1009C302 LTE CS FALLBACK IN PREP FAIL DUE TO PROT L3 Relocation signalling (RNC)
M1009C303 LTE CS FALLBACK IN PREP FAIL DUE TO MISC L3 Relocation signalling (RNC)
M1009C304 LTE CS FALLBACK IN PREP FAIL DUE TO NON STAN L3 Relocation signalling (RNC)
M1009C305 LTE CS FALLBACK IN DETECT L3 Relocation signalling (RNC)
M1009C306 LTE CS FALLBACK IN COMPLETE L3 Relocation signalling (RNC)
M1009C307 LTE CS FALLBACK HIGH PRIO IN PREP REQ L3 Relocation signalling (RNC)
M1009C308 LTE CS FALLBACK HIGH PRIO IN PREP FAIL L3 Relocation signalling (RNC)

Release Information
RAS Release - RU40
RNC Release - RN7.0

Activating SRVCC from LTE and CSFB with HO:
Software requirements:
Network element Main release
MSS
-DX Md 16.1 EP1 (DX) /
-ATCA Ma 16.1 (ATCA)
HLR
-NT-HLR NT 5.0 EP1 (NT-HLR) / NT 6.0 (with IP-SM-GW support) /
-DX-HLR M16.1 (DX-HLR) / M16.1 (with IP-SM-GW support)
IMS IMS 8.2 EP2 (Sun) /
-CFX-5000 (Sun) IMS 9.2 (ATCA)
-CMS-8200 (ATCA) [IMS mandatory forSRVCC, not for CSFB]
SGSN
-DX SG8.0 DX CD3.1 (DX) /
-ATCA
Flexi ISN FI40 CD2 supports HSPA+ data rate up to 42 Mbit/s DL and up to 11 Mbit/s UL
GGSN
Flexi ISN FI50 needed for HSPA+ data rate up to 84 Mbit/s DL and up to 23 Mbit/s UL
MGW
-IPA U5.0 EP2 (IPA) /
-ATCA Ui5.0 EP1 (ATCA)
eNB RL40
PCRF
-PCS-5000 PCS6.3
MME NS2.2 N2 3.10-0 (SRVCC trialing capability only, P7 in March)
S/P GW FlexiNG NG2.1.1.2 Released
LTE RL40

SRVCC and CSFB features are complex End-to-end functionalities that require support from both Target and Source
RANs (LTE and WCDMA). Support from the Core Network is essential as well.
For SRVCC:
Mobile Switching Center (MSC) needs to be upgraded to support SRVCC: Sv interface with MME and
functionalities to receive the HO-requests from the MME,
MME upgrade to Flexi NS 3.0 providing SRVCC (Rel. 9)
NetAct OSS5.4 CD2 supporting SRVCC features.
For CS Fallback:
Evolved Packet Core (EPC) must support CS inter-working for mobility management and paging
SGs interface between MME and MSC is needed
Interworking between SGSN and MME and PDN-GW via S3/S4 interfaces (or via pre-Rel.8 Gn interface).
UTRAN Iu-ps SGSN Gn GGSN
Uu
Gb Iu-cs
UE Um GERAN A MSC
S
Gn Sv
LTE-Uu 3 SGs S
Gn
E-UTRAN S1-MME MME
4
PDN-GW
S1-U S11
S5/S8
S-GW


Do not forget feature parameters on the LTE network also need to be enabled
Licence Feature Code cRNC/mcRNC 1756
Check cRNC
ZW7I:FEA,LIM:FEA=XXXX,FSTATE=ON;
Check mcRNC
[root@CFPU-0(RNC-8) /root]
# fsclish -c "show license feature all" | grep 000000XXXX (licence code must
be
10 digits)
Configure a HOPL
Configure an ADJL towards the target eNB object
Before you start
Restart of the RNC or the BTS is not required after activation of this feature.
Feature RAN2435: SRVCC from LTE and CSFB with HO does not have an own licence, but the ISHO from
LTE licence of the RAN2176: LTE PS Handover feature is required. This is a long-term capacity license.
Capacity license refers to the number of cells. For information on managing licenses,
Set Parameter WCEL IncomingLTEISHO to Enabled
Set Parameter RNFC SRVCCEnabled to Enabled

Set Parameter RNFC - CSFBEnabled to Enabled

Extra Info:
SDF- Service Data Flow- An aggregate set of packet flows that matches a set of filters.
QCI QoS Class Identifier A parameter that is typically associated to packet
forwarding/scheduling etc treatments.
MME Mobility Management Entity
QCI values can be from 1 to 9. Since QCI is an 8 bit field it can have 255 values. Values 10 to
255 are operator specific. A bearer is always associated with a QCI. A UE can have a max of 11
bearers but QCI are from 1 to 9. Which means the QCI can be repeated for the bearers.
Each bearer is also associated with TFT. Yes, even the default bearer can be assigned a TFT
after the recent spec changes. TFT can have multiple packet filters resulting in multiple SDFs.
Now the confusion is with this statement - Each Service Data Flow (SDF) is associated with
one and only one QoS Class Identifier (QCI).
Since two dedicated bearers can have same QCI the above statement leads to confusion.
Reading the statement again makes sense. A bearer is associated with QCI and set of packet
filters that will lead to multiple SDFs. This means multiple SDFs can be treated with same type
of service but one SDF cannot be given multiple treatments. This also means that you cannot
assign same packet filter to two dedicated bearers. Hence the above statement!

RAN2717
Smart LTE Layering

Active UEs are redirected from WCDMA to LTE
UE moving from WCDMA cell coverage area into LTE cell coverage area

RAN2717 - Smart LTE Layering, cont.
The RAN2717: Smart LTE Layering feature introduces support for the redirection of active LTE-capable UE
from WCDMA to LTE. In the early LTE-supporting UE, redirection is well-supported and thus preferred.
LTE cell reselection for the UE in idle mode, Cell_PCH state, or URA_PCH state in the WCDMA layer has
been enabled by the RAN2067: LTE Interworking feature.
Smart LTE Layering introduces support for the redirection of LTE-capable UEs that are in Cell_DCH state
from WCDMA to LTE
A RRC CONNECTION RELEASE message with the redirection to LTE command is used to move the
active UE to the LTE layer
With this feature RRC Connection Release with Redirection command to LTE can be used for moving
active UEs to LTE
These use cases allow LTE measurements after RRC connection release
Cell_DCH to Cell_FACH, Cell_PCH or URA_PCH selection
Typically UEs select the LTE layer using the absolute priorities provided in the system information.
These priorities are used for cell selection only in idle mode i.e. Cell_PCH or URA_PCH states. As an
example use case, laptop dongle frequently changing state between Cell_FACH and Cell_DCH can be
efficiently commanded to the LTE layer using redirection
LTE layer selection is faster when triggered with using the redirection procedure as compared to using
the system information provided mechanism. It also forces the UE to check the availability of the LTE
layer, and confirm that LTE can be used. Frequently transmitting dongles can also be moved to the
LTE layer

The following triggers cause redirection of a UE in Cell_DCH state to the LTE layer:
RRC state change away from Cell_DCH
The network moves the UE away from Cell_DCH because of user inactivity or call
release
Redirection to LTE is not triggered, if the state change is caused by a RAB release for
an emergency call
Channel-type switch from HSDPA to DCH for a UE using only PS
services
The network moves the UE with only PS services from HSDPA to DCH because of, for
example, lack of cell resources or fading WCDMA coverage
CS call release
Possibility for redirection to LTE is checked when CS RAB is released and the UE would
stay in CELL_DCH state (the UE has at least one active PS RAB after CS RAB release)
The redirection to LTE is not triggered, if the released RAB is used for an emergency
call

RAN2067 LTE Interworking
RAN2717
Smart LTE
Layering
RAN 2067
LTE Interworking

New Counters:
M1006C262 RRC CONN RELEASE LTE REDIR DUE TO INACTIVITY M1006 RRC signalling (RNC)
M1006C263 RRC CONN RELEASE LTE REDIR DUE TO CH TYPE SWITCH M1006 RRC signalling (RNC)
M1006C264 LTE REDIRECTIONS PREVENTED BY TIMER M1006 RRC signalling (RNC)
M1006C291 RRC CONN RELEASE LTE REDIR DUE TO CS CALL RELEASE M1006 RRC signalling (RNC)
New parameters:
Full name Abbreviated name Managed object
Smart LTE Layering Enabled SmartLTELayeringEnabled WCEL
Smart LTE Layering RSCP threshold SmartLTELayeringRSCP WCEL
Smart LTE Layering NRT user amount threshold SmartLTELayeringUA WCEL
Smart LTE Layering Target System Selection SmartLTELayeringTSysSel WCEL
Smart LTE Layering service control SmartLTELayeringServ RNMOBI
Timer for Smart LTE Layering Prevention SmartLTELayeringPrevT RNMOBI

Release Information
RAS Release - RU40

RNC Release - RN7.0

Activating Smart LTE Layering :

Do not forget to also enable the feature parameters on the LTE network
Licence Feature Code 3903 (license name: Redirection to LTE)
Create an ADJL towards the target LTE eNB cell
Set the WCEL parameter - SmartLTELayeringEnabled to the desired value:
1. RRC state change away from CELL_DCH state triggers the LTE layering.
2. RRC state change away from CELL_DCH state, or channel-type switch from HSPA or
from HSDPA (E-DCH/HS-DSCH --> DCH/DCH or DCH/HS-DSCH --DCH/DCH) to DCH
triggers the LTE layering.
3. RRC state change away from CELL_DCH, or CS call release triggers the LTE
layering.<for values 2, 3 it means that only one condition must be fullfilled to trigger the
LTE layering
4. Any trigger mentioned above triggers the LTE layering

Set the WCEL parameter - SmartLTELayeringRSCP. This is used to define CPICH
RSCP threshold that must be exceeded before smart LTE layering can be done
Set the WCEL parameter - SmartLTELayeringUA. This is used to define NRT

(interactive, background) user amount threshold at cell level that must be exceeded
before smart LTE layering can be done

Set the WCEL parameter - SmartLTELayeringTSysSel. This indicates if
the redirection is allowed to FDD LTE, TDD LTE or to both

Set the RNMOBI parameter - SmartLTELayeringServ. This is used to define what
services are allowed to be moved to LTE by the RAN2717: Smart LTE Layering
feature

Set the RNMOBI parameter - SmartLTELayeringPrevT. This is used to define a
minimum time that the UE must be in WCDMA system before redirection to LTE can
be done by the RAN2717: Smart LTE Layering feature




RAN1877
End-user experienced DL Throughput

Brief Introduction
Better view of the end-user experienced DL throughput, achieved for each separate SPI
(Scheduling Priority Indicator) class and scheduler buffer throughput.
4 new counters groups introduced at WBTS level
New KPIs/Reports for experienced end-user and the scheduler buffer DL throughput are
provided by NetAct Report through Cell Throughput (actually volume per SPI) with WBTS
(M5002) counters re-usage.
Benefits
Allow to analyze most attractive for mobile operator end-user KPIs and monitor subscribers
throughput, such as QoS related monitoring, thereby:
OPEX saving via simplified NW monitoring and optimization, thanks to more detailed
network throughput OSS statistics instead of more complicated field tests.
Impact on memory capacity due to new PM counters for OMS and NetAct has been seen
as uncritical.

RAN1877 End-user experienced DL Throughput,
cont.
This feature introduces new counters for end-user statistics for each SPI (scheduling priority indicator) class
for HSDPA traffic.
The counters introduced by this feature are based on sampling and summing up every 100 seconds for each
SPI class:
number of active HSDPA users
number of samples for number of active HSDPA users
number of allocated HSDPA users
number of samples for number of allocated HSDPA users
Every counter group consists of 17 counters:
16 counters for each SPI class
one counter for total values
For the detailed counter list, see Measurements and counters.
Along with the RAN1877: End-used Experienced DL Throughput feature, new KPIs are proposed by Nokia
Siemens Networks:
reporting the average number of active HSDPA users, per each SPI class
reporting the average number of allocated HSDPA users, per each SPI class
reporting the average end-user experience throughput of active HSDPA users, per each SPI class
reporting the average end-user experience throughput of allocated HSDPA users, per each SPI class
The new KPIs are based on the introduced counters as well as on M5002C5 -
M5002C20 (TOTAL ACKNOWLEDGED DATA IN MAC-HS PDUS FOR SPI 0...15) existing counters.

RAN1877 RAN1877
Not activated Activated
There is no possibility to measure there is a possibility to watch

throughput in the cell throughput on a cell level from
experienced by the end user users side
existing counters M5002C5 proper denominators to convert

M5002C20 provide only data the data volumes into
volume during the measurement throughput values are provided
period for each SPI class
the end user throughput can be
measured separately for each
SPI class
Two different sets denominators are provided for two purposes:

1) to get real end user experienced throughput, counting also over TTIs where user is not scheduled
but has data in the NodeB buffer
2) to get average thoughput counting only over TTIs where the user has been scheduled.
UE5 UE5
RAN1877 RAN1877
Not activated UE4 Activated UE4
UE3 UE3
UE2 UE2
UE1 UE1

Recommendation:
Using together with RAN1262 QoS Aware HSPA Scheduling. The reason of that is that counters for Cell
Throughput measurements in WBTS are working under that feature. Thereby, activation of this feature will
allow to generate End-User Experienced Throughput KPI Reports.
. Interdependencies:
RAN1877 does not require any other features for activation.
RAN1877 RAN1262
End-user experiended QoS Aware HSPA
DL Throughput Scheduling

Two groups of counters

Counters for "number of users"
updated on every 100ms of Counters for "number of samples" for
successfully transferred data, per SPI active and allocated HSDPA users
class
NUMBER OF NUMBER OF
NUMBER OF NUMBER OF SAMPLES FOR SAMPLES FOR
ACTIVE HSDPA ALLOCATED NUMBER OF NUMBER OF
USERS HSDPA USERS ACTIVE HSDPA ALLOCATED
USERS HSDPA USERS
17 counter for each category (16 per SPI + 1 for total value)
The allocated user is a user receiving or waiting for data whether or not it is
scheduled for him.
The active user means a user who has data in the BTS buffer and the data is
sent to the user.

Existing set of counters (RAN1262 QoS Aware HSPA Scheduling)
TOTAL ACKNOWLEDGED DATA IN TOTAL ACKNOWLEDGED DATA IN

MAC-HS PDUS FOR SPI 0 [M5002C5] MAC-HS PDUS FOR SPI 15 [M5002C20]
New set of KPIs (per SPI per Cell)
Reporting the average number of active HSDPA users
Reporting the average number of allocated HSDPA users
Reporting the average end-user experience throughput of active HSDPA users
Reporting the average end-user experience throughput of allocated HSDPA users

New counters:
M5002C58-M5002C73, M5002C74 ACTIVE HSDPA USERS IN SPI 0-15/ALL ACTIVE HSDPA USERS Cell Throughput in WBTS
SAMPLES FOR ACTIVE HSDPA USERS IN SPI 0-15/ SAMPLES FOR

M5002C75-M5002C90, M5002C91 Cell Throughput in WBTS
ALL ACTIVE HSDPA USERS
ALLOCATED HSDPA USERS IN SPI 0-15/ALL ALLOCATED HSDPA
USERS
SAMPLES FOR ALLOCATED HSDPA USERS IN SPI 0-15/ SAMPLES
FOR ALL ALLOCATED HSDPA USERS

cont.
New counters:
M5002C58-M5002C73, M5002C74
17 counters (ACTIVE_HSDPA_SPI_0 to 15 and ACTIVE_HSDPA_ALL)
Number of active HSDPA users per SPI class 0-15/The sum of all active HSDPA users.
The number of active HSDPA users in SPI class 0-15 or for all SPI classes is sampled each 100 ms and
the value is cumulated to this counter.
The active user means a user who has data in the BTS buffer and the data is sent to the user.
Number of active HSDPA users is sampled each 100ms and value is cumulated to the counter.
M5002C75-M5002C90, M5002C91
17 counters (SAMPLE_ACTIVE_HSDPA_SPI_0 to 15 and SAMPLE_ACTIVE_HSDPA_ALL)
The number of samples for monitoring average number of active HSDPA users in SPI class 0-15/ The
number of samples for monitoring average number of all active HSDPA users.
The counter is incremented by one on each 100ms if at least one HSDPA user is active.
The active user means a user who has data in the BTS buffer and the data is sent to the user.
M5002C92-M5002C107, M5002C108
17 counters (ALLOC_HSDPA_SPI_0 to 15 and ALLOC_HSDPA_ALL)
Number of allocated HSDPA users per SPI class 0-15/The sum of all allocated HSDPA users.
The number of allocated HSDPA users in SPI class 0-15 or for all SPI classes is sampled each 100 ms and
the value is cumulated to this counter.
The allocated user is a user receiving or waiting for data whether or not it is scheduled for him.
M5002C109-M5002C124, M5002C125
17 counters (SAMPLE_ALLOC_HSDPA_SPI_0 to 15 and SAMPLE_ALLOC_HSDPA_ALL)
The number of samples for monitoring average number of allocated HSDPA users in SPI class 0-15/ The
number of samples for monitoring average number of all allocated HSDPA users.
The counter is incremented by one on each 100ms if at least one HSDPA user is active.
The allocated user is a user receiving or waiting for data whether or not it is scheduled for him.
New KPIs
Average number of active HSDPA users per SPI class 0:

sum([ACTIVE HSDPA USERS IN SPI 0])
Avg n of active HSDPA users per SPI class 0 =
sum([SAMPLES FOR ACTIVE HSDPA USERS IN SPI 0])
SUM (ACTIVE_HSDPA_SPI_0)
Avg act HSDPA SPI cl 0 =
sum(SAMPLE_ACTIVE_HSDPA_SPI_0)
Average number of active HSDPA users per SPI class 1:

Avg n of active HSDPA users per SPI class 1 =
sum([SAMPLES FOR ACTIVE HSDPA USERS IN SPI 1])
Average number of active HSDPA users:

ssum([ALL ACTIVE HSDPA USERS])
Avg n of active HSDPA users =
sum([SAMPLES FOR ALL ACTIVE HSDPA USERS])

cont.
New KPIs:
Avg act HSDPA SPI cl 0:
Average number of active HSDPA users per SPI class 0
MEASUREMENT(S): Cell Throughput in WBTS
Avg act HSDPA SPI cl X:( with X= 1 to 15 for all SPI

classes)
Average number of active HSDPA users per SPI class 1
Avg act HSDPA users:

Average number of active HSDPA users
New KPIs
AVERAGE NUMBER OF ALLOCATED HSDPA USERS PER SPI CLASS 0:
sum(ALLOC_HSDPA_SPI_0)
Avg N OF allocated HSDPA users per SPI 0 =
sum(SAMPLE_ALLOC_HSDPA_SPI_0)
Average end-user experience throughput of active HSDPA users per SPI class 0
sum([TOTAL ACKNOWLEDGED DATA IN MAC - HS PDUS FOR SPI 0] * 8 *10)

Avg thr act HSDPA SPI 0 =
sum(HS_DATA_ACK_SPI_0 * 8 *10)
Avg thr act HSDPA SPI 0 =
sum(ACTIVE_HSDPA_SPI_0)

cont.
New KPIs:
Avg n of allocated HSDPA users per SPI class X: (with X = 0 to 15 for
the SPI classes 0 to 15)
Average number of allocated HSDPA users. Allocated means that user is
receiving data or user is waiting for data regardless of the data being
scheduled for the user.
Avg thr act HSDPA SPI 0:

Average end-user experience throughput of active HSDPA users per SPI
class 0
Avg thr act HSDPA SPI X: (with X = 1 to 15 for the SPI classes 1 to 15)
Average end-user experience throughput of active HSDPA users per SPI
class X
New KPIs
Average end-user experience throughput of allocated HSDPA users per SPI class 0
sum([TOTAL ACKNOWLEDGED DATA IN MAC - HS PDUS FOR SPI 0] * 8 *10)

Avg thr alloc DL SPI 0 =
sum([ALLOCATED HSDPA USERS IN SPI 0])
sum(HS_DATA_ACK_SPI_0 * 8 *10)
Avg thr alloc DL SPI 0 =
sum(ALLOC_HSDPA_SPI_0)
Average end-user experience throughput of allocated HSDPA users
sum([ORIGINAL HSDPA DATA] * 8 *10)

Avg thr alloc HSDPA usrs =
sum([ALL ALLOCATED HSDPA USERS])

cont.
New KPIs:
Avg thr alloc DL SPI 0:
Average end-user experience throughput of allocated HSDPA users per SPI class 0
Avg thr alloc DL SPI X: (with X = 1 to 15 for the SPI classes 1 to 15)
Average end-user experience throughput of allocated HSDPA users per SPI class X
HS_DATA_ACK_SPI_0: (kbyte)
Number of octets of acknowledged MAC-hs PDUs for SPI 0.
When a MAC-d PDU is positively acknowledged for this SPI class.
HS_DATA_ACK_SPI_X: (kbyte) (with X = 1 to 15 for the SPI classes 1 to 15)
Number of octets of acknowledged MAC-hs PDUs for SPI X.
When a MAC-d PDU is positively acknowledged for this SPI class.
ALLOC_HSDPA_SPI_X: (with X = 0 to 15 for the SPI classes 0 to 15)
The sum of allocated HSDPA users in SPI X class. The allocated user is a user receiving or
waiting for data whether or not it is scheduled for him.
The number of allocated HSDPA users in SPI class X is sampled each 100ms and the value
is cumulated to this counter. SAMPLING INTERVAL: 100ms
Avg thr alloc HSDPA usrs: (kbit/s)
Average end-user experience throughput of allocated HSDPA users

Activation
Restart of the RNC or the BTS is not required after the activation of this feature.
This procedure does not cause downtime and it can be activated at any time of the
day.
Licensing
This feature belongs to application software (ASW) and is under license key
management.
The counters are optional and controlled by RNC license.
License key installed on RNC. OMS reads the RNC license and based on that
hides or shows the counters in the OMS EM GUI.

cont.
HSDPA_ORIG_DATA: (kbyte)
Total amount of HSDPA original data (first transmissions) sent
on MAC-hs/ehs PDUs. This counter includes legacy single
carrier, Multi-Carrier and MIMO HSDPA data
The counter is updated when the MAC-hs/ehs PDU is sent to
the air (first transmission of the PDU only).
ALLOC_HSDPA_ALL:
The sum of all allocated HSDPA users. The allocated user is a
user receiving or waiting for data whether or not it is
scheduled for him
The number of all allocated HSDPA users is sampled each
100ms and the value is cumulated to this counter
These are MEASUREMENT(S): Cell Throughput in WBTS
WCDMA Release RU40

I-HSPA System I-HSPA Rel.5
BTS (Flexi) WTBS8.0
NetAct NetAct8
HW Requirements None
License Control Long-term ON/OFF
Licence Control in NE RNC LK
RAN1877 End-user experienced DL Throughput feature does not require any

specific RNC or mcRNC HW and SW

RAN2526
1 Hour RNC Release Software Upgrade

IPA RNC Release upgrade time is reduced
1 Hour Release Software Upgrade Time
Preparation
Upgrade
Aftermath
cRNC

The SW upgrade procedure is based on the Preparation, Upgrade, and Aftermath concept
The SW upgrade procedure consists of 3 phases:
SW Upgrade
Aftermath
Preparation Upgrade Aftermath

Not traffic and service affecting Traffic and service affecting Not traffic and service affecting
Manual pre checks e.g. disk space, Macro pre checks Manual post checks e.g. star
locked files, stop command calendar Data conversion and unit preloading tcommand calendar jobs, start
jobs etc. measurements etc.
Boot SW upgrade
Making a fallback of the running KPI monitoring
package New SW activation including reboot
New feature activation
Downloading the software Remove temp files
Preparing the new software Change state of package from NW
to BU
Checking licences and installing
licences
Creating the new package


Release Information
RAS Release - RU40

RNC Release - RN7.0
IPA Platform - A14
RNC Flexi Platform FP-6 Cougar
Activating 1 Hour RNC Release Software Upgrade :

This is BSW (Basic Software) and requires no activation

RAN2539
OMS RNC Connectivity Increase

Simultaneously connected RNCs is increased from 10 to 20
HP Proliant DL360 Gen.8

RAN2539 - OMS RNC Connectivity Increase, cont.
The number of RNCs that can be connected to a standalone OMS is increased

for 10 to 20
The OMS capacity is not increased
Topology browser 30
NE Parameter Editor 30
Radio Network Measurement Management 10
Radio Network Measurement Presentation GUI 20
NE threshold management 20
Radio Network online-monitoring 20
Fault Management 30
Active sessions 30
Secure MMI-window 30
Parameter tool 30
Putty 30
Log viewer 30
SW version viewer 30
BTS Connection Resources UI 30
New GOMS hardware HP Proliant DL360 Gen.8 is required
RAN2701 included in a later release will increase the number of users

Release Information
RAS Release - RU40

Activating OMS RNC Connectivity Increase :

This is BSW (Basic Software) and requires no activation


Operator is able to initiate emergency symptom data collection from an IPA

RNC using an MML command or triggered from OMS
IPA RNC
RAN1805
(RU40) RAN1873
OMS (RU30) NetAct
Flexi WBTS RAN2446 RAN2229 Alarm
(RU40) RU40 enrichment
OSS1071
RAN2199 Planned
Planned
mcRNC
Planned
RAN2601
Symptom data
Manual trigger

Troubleshooting logs (symptom data) collection from the IPA-RNC can be

performed using one command
The user Nemuadmin can trigger log collection from the OMS by default from
the command line interface
If the log collection needs to be triggered by the root user from the command
line interface then the root user needs to be added to _nokNELogManager
group in the OMS
Emergency profile collection is supported and used when fast operator
action is required to restore the service e.g. RNC reset
Currently symptom data information is obtained with command-line-based
tools such as the TN38 log collection macro
This is tedious and time consuming and is usually omitted during
troubleshooting
When triggered by MML or from OMS the IPA RNC will perform the
emergency symptom data collection automatically

The troubleshooting report package consists of compressed file and

includes:
All relevant RNC system and process logs
RNC HW & SW configuration
Active alarms and relevant parts of alarm history
The symptoms are collected into a file that can then be added to the
trouble ticket to help problem solving
There is an alarm to indicate the receipt of troubleshooting data.
System collection and upload failure is indicated by a defined alarm
When the log collection is triggered the logs are also forwarded to the
OMS
The log file is stored on the RNC hard disk at eclipse/var/symptom with a
file name SYMP<sequential_number>.ZIP e.g. SYMP0001.ZIPand
automatically forwarded to the OMS

The logs are stored in the OMS at /var/opt/OMSftproot/NE/

TroubleshootingData/. with a file name TSUPL_RNC_<RNC_ID>.<date-
time>.zip e.g.TSUPL_RNC_00009.20110810103000.zip
The EMERG profile configuration file RNCEMERG.XML can be found at
SHADOWS/RUNNING/LFILES


OMS requires feature RAN1873
RAN2446
Emergency Symptom Data Collection for IPA-RNC
(BSW)
RAN 1873
OMS
Troubleshooting
Data Collection
(BSW)

Release Information
RAS Release - RU40

RNC Release - RN7.0
IPA Platform A14
mcRNC Release planned for a later release
Flexi Direct Release - planned for a later release

Activating Emergency Symptom Data Collection for IPA-RNC :

Create the SOKERI user account and attach it to the PROFILE profile
ZIAH:SOKERI:PROFILE:;
Trigger the log collection using the Service Terminal LCKMAN Log
Collection Extension:
ZDDS:<active_OMU>, <omu_index>;
LP:<number>,LCK; e.g. LP:1,LCK;
1
S:E (trigger log collection)
PF (check the progress)
T:<value> sets the time for automatic transfer to the GOMS. Value = 0
disables automatic file transfer
The logs are stored in the RNC at eclipse/var/symptom with a name like
SYMP0001.ZIP

The log collection can also be triggered from the OMS.

To do this you will first need to add root user to the _nokNELogManage
user group
fsgpasswd a root _nokNELogManage
Now the log collection can be triggered from the GOMS CLI using the
command:
zcollectNELogs n <ne_id> -p RNCEMERG (Ne-id is the NE-ID from
RUOSTEQX)
zcollectNELogs n <ne_id> -f -p RNCEMERG (provides feedback on
CLI screen)
The logs are stored in the GOMS at
/var/opt/OMSftproot/NE/TroubleshootingData/. with a file name
TSUPL_RNC_<RNC_ID>.<date-time>.zip
e.g.TSUPL_RNC_00009.20110810103000.zip

Event Triggered Symptom Data Collection is active by default but will only start to
work when the SOKERI user has been configured in the RNC
In this case the data collection is triggered by certain events
The feature and its main parameters are controlled by PRFILE class2
parameters 1814,1819 and 1818
The following events triggers are configured by default
1001 UNIT RESTARTED
1014 PROCESSOR LOAD RATE ALARM LIMIT EXCEEDED
1078 PROCESS EXCEPTION
1143 AMOUNT OF FREE MEMORY REDUCED
1144 FREE BUFFER HEADERS EXHAUSTING
1147 MESSAGE QUEUE OVERFLOW
1239 DSP SUPERVISION FAILURE
1269 AAL5 FRAME CORRUPTED
1598 UNIT FOUND FAULTY BY ALARM SYSTEM
2693 ACTIVE UNIT FAULTY

Alarm 0186 - New Log File Generated is raised Files stored in RNC at
/ASWDIR/TRSLOG/
Files are stored in GOMS at /var/opt/OMSftproot/NE/TroubleshootingData
The Event Triggered Log Collection profile configuration file RNCSTAND.XML can
be found at SHADOWS/RUNNING/LFILES

Activating Event Triggered Symptom Data Collection for IPA-RNC :
Create the SOKERI user account and attach it to the PROFILE profile
ZIAH:SOKERI:PROFILE:;
Enable/Disable the feature with PRFILE parameter 1814
ZWOI:2,1814 0001 = Enabled / 0000 = Disabled
ZWOC:2,1814,1; - enables Event Triggered Symptom Data Collection
To prevent alarm 0186 from being raised use the PRFILE value 0002
ZWOC:2,1814,2;
Check and increase the the folder space (ASWDIR/TRSLOG/) using commands
ZWOI:2,1819;
ZWOC:2,1819,<size (H)>
Check and configure the automatic transfer of the zip files to OMS using the
command
ZWOI:2,1818; - Enabled = 0001 / 0000 = Disabled
ZWOC:2,1818,1;


RAN2296 Transport sub-Module "FTIF" Eth+E1/Ta/JT1 for

Flexi Multiradio SM

RAN2296
Transport sub-Module "FTIF" Eth+E1/Ta/JT1 for Flexi

Multiradio SM

RAN2296 FTIF Eth + E1/T1/JT1 for Flexi Multiradio SM
FTIF enhances the connectivity and transport mode options of Flexi Multiradio 10
BTS.
2 x Combo Ports, each operating as: 4 x "RJ48C-style" ports,

-100/1000Base-T
-or each provides 2 x E1/T1/JT1
-- optical SFP
FTIF can only be used with FSMF, FSMG and FSML system
modules

RAN2296 FTIF Eth + E1/T1/JT1 for Flexi Multiradio
SM, cont.
Summary
FTIF Transport Sub-Module supports
- Up to 8x E1/T1/JT1 interfaces and
- 2x Combo Ports (2x optical via separate SFP, 2x electrical).
Up to two ports can be used at the same time. Benefits for the Customer FTIF enhances the connectivity
and transport mode options of Flexi Multiradio 10 BTS
Connectivity
- Up to 8x E1/T1/JT1 interfaces to interconnect with TDM based transport networks or
equipmenet on site
- Up to 2 additional Ethernet ports via optical/electrical combo ports for chaining or
collocation
- True zero footprint support for FlexiPacket Radio via Power + Ethernet feature on both
electrical Ethernet ports
Transport modes
- ATM Iub, Dual Iub and IP Iub over ML-PPP
- Media conversion for chained or collocated BTS (CESoPSN, ML-PPP)
Optional Outdoor Transport Sub-Module FTIF extends capabilities of Outdoor Flexi Multiradio
10 System Module FSMF by:
2 x Combo Ports supporting following combinations:
2 x 100/1000Base-T or
2 x optional optical SFP or
1 x 100/1000Base-T and 1 x optional optical SFP
Flexi Multiradio System Module with FTIF supports QoS aware Ethernet Switching across up to 3
interfaces
Forpublic
8use
x E1/T1/JT1
IPR applies (twisted pair) on 4 x RJ48C-style ports; coaxial connectivity can be provided via baluns
System Module
FTIF enhances the connectivity and transport mode options of Flexi
Multiradio 10 BTS
Connectivity:
8x E1/T1/JT1 interfaces to interconnect with TDM based transport networks
or equipment on site
2 additional Ethernet ports via optical/electrical combo ports for chaining or
collocation
True zero footprint support for FlexiPacket Radio via Power + Ethernet
feature on both electrical Ethernet ports
Transport modes:
ATM Iub, Dual Iub and IP Iub over ML-PPP
Media conversion for chained or collocated BTS (CESoPSN, ML-PPP)

System Module, cont.
FTIF is required
- for ATM Iub, Dual Iub and IP Iub over ML-PPP
- if collocation (CESoPSN, ML-PPP) or synchronization shall include TDM
- if more/other Ethernet interfaces are required than available on Multiradio System Module
- if Synchronization Hub function based on Synchronous Ethernet input or output shall be used
Flexi Multiradio System Module integrated Transport and FTIF build a single logical Transport node
Each "RJ48C-Style" port offers 2 E1/T1/JT1 interfaces which are both accessible via one Flexi
Outdoor cable FTCY. Also the existing cables FTCB, FTCV, FTCX can be used but with the
consequence that just 1 PDH interface per RJ48C port is accessible (interfaces 1,2,3 and 4).
Current Implementation
FTIF is an optional enhancement to Flexi Multiradio 10 System Module's integrated transport
functionality. Interdependencies between Features
Depends on feature "RAN2262 Flexi Multimode System Modules, FSMF and FSMG " Operational
Aspects
HW Requirements
FTIF can only be installed to Flexi Multimode System Modules FSMF and FSMG. BTS Transport HW
Flexi Multiradio System Module with FTIF
Supplementary Internal Information
Note that the PDH interface numbering is 1/5; 2/6; 3/7; 4/8.
CESoPSN = Circuit Emulated Services over Packet Switched Networks e.g. Pseudo Wire
System Module
BSW/ASW HW
RAS RELEASE RU40
BTS RELEASE WN 8.0
BTS HARDWARE FLEXI REL.3
NETACT RELEASE OSS5.4 CD Set 3
RNC RELEASE N/A
mcRNC RELEASE N/A
SGSN RELEASE N/A
IHSPA RELEASE N/A
LICENCING N/A


RAN2117 RNC2600 Co-Siting with Multicontroller RNC

RAN2240 mcRNC Flexible Dimensioning up to 50Gbps HW Release 2
RAN2262 Flexi Multiradio Sstem Modules, FSMF and FBBA extension module
RAN2317 240W Multireadio remote RF
RAN2157 Flexi Lite BTS 2100 ***
RRH FHDB 60W+60W
RAN2111 - Flexi WCDMA Software Download Capability for Antenna Line Devices

RAN2117
RNC2600 Co-Siting with Multicontroller RNC

RAN2117 - RNC2600 Co-siting with mcRNC
Capacity of the installed RNC2600 increases

Enables peak rates higher than 84 Mbps for the RNC2600
Provides improved end-user experience due to higher HSPA peak
rate support from the network

RAN2117 - RNC2600 Co-siting with mcRNC, cont.
The idea of the feature is that cRNC can assign certain UEs to be processed by mcRNC.
The assignment is only when cRNC is the SRNC for the UE and static, i.e. UEs are not
switched between RNCs in connected state. Assignment lasts until UE goes to idle state or
is relocated from cRNC.There is no co-siting when cRNC is the drift RNC.
This feature is only supported using Rel2 mcRNC HW

RNC2600 supports co-siting using all valid step configurations
This feature is currently only for use in networks where all the interfaces except the Iu-PS are
ATM/IP based
Full ATM RNC2600s are not supported
Cositing in RU40 is "inter-RNC UE processing within an RNC cluster
The RNC2600 is connected to the mcRNC through a proprietary interface called the RNC-cl
interface and creates an RNC cluster
mcRNC S1 hardware configuration is used
RNCs are geographically co-located and installed in the RNC site and inter connected by IP
interfaces
RNC co-siting is transparent to the core network elements.
Co-siting is not applied when the RNC2600 is the drift RNC
RNC2600 controls the BTSs common channel signaling and core network signalling

RNC2600
mcRNC
BTS Control
Core signalling EU processing
EU processing

Only the RNC2600 has an RNS and is therefore the controlling RNC and controls
the cells
The cRNC is visible to the CN, neighbouring RNCs and the underlying node-
Bs as the CP physical termination end point
The mcRNC is visible only as an UP IP end point
This is possible by usage of site routers on the Iu side and the Iub side of the
RNCs to which both the cRNC and mcRNC connect.
During the RRC connection setup phase, the RNC2600 assigns UEs to itself or to
the mcRNC
The assignment only happens when the RNC2600 is the SRNC for the UE
The UEs are not switched between RNCs
Assignments last until the UE goes to idle state or the UE is relocated from
RNC2600
If a certain UE connected through ATM is being processed in mcRNC, all UP
traffic goes via RNC-cl interface


UE-specific signaling and user plane resources are always allocated from
the same HW platform
UEs capable of HSPA peak rates higher than 84 Mbps are allocated to the
mcRNC
The load is shared between RNC2600 and mcRNC
The mcRNC has its own IP interfaces towards Iub, Iu-cs, Iur, and Iu-ps
If ATM is used in Iub, Iu-cs, or Iur then the RNC2600 acts as the ATM
gateway between the ATM based Iub, Iu-cs, or Iur interface and the
mcRNC IP interfaces
The Iu-ps interface is always IP based when the RNC co-sitting feature is
used
The operability of both RNCs in the cluster is kept independent for
simplicity and to make it possible to use the existing O&M methods and
tools in the respective RNCs
Both RNCs connect to the same OMS using independent BTSOM
interfaces
CCH UP (DMCU) No CSPUs - all cell-

NodeB-specific UP related CP and UP
functionalities functions are
Common channels handled in cRNC
handling
TOP CP (mainly in
ICSU)
cell-specific CP
functionalities cRNC OMS mcRNC
UE CP (in USCP)
UE-specific CP
ICSU RSMU DMCU functionalities
Top CP CCH UP
UE CP (in ICSU)
UE CP UE UP
UE-specific CP CFPU
functionalities BTSOM USPU UE UP (in USUP)
OMU
OMU UE CP UE-specific CP
functionalities
UE UP
Transport Network ATM/IP IFs NP2GE 0 EIPU
RNC-cl
1
EIPU Transport Network
UE UP (DMCU)
UE-specific UP
functionalities

There is a BTSOM interface used between the RNCs

At system level the OMS hides most of the cosite details from NetAct
NetAct is aware of the of co-sited RNC topology
OMS provides the means to configure and activate/deactivate RNC co-siting
OMS does some processing, separation, and filtering of PM data from the independent RNCs to hide the
co-site details
The RNC-cl interface and the BTSOM interface between the RNC2600 and the mcRNC has no visibility to
the RAN
The RNC-cl interface is visible to the OMS
The OMS can be used to configure the RNC-cl interface.
cRNC has to act as ATM gateway to mcRNC when ATM transport is being used.
EIPUs are connected directly to NPGEs without any external devices

Four NP2GE cards configured in protected (NPGEP) should be used at the cRNC side
Eight 1GE ports (4 per each BCN) should be used at the mcRNC side
The theoretical maximum capacity is 3.2 Gbps (due to NPGE backplane capacity)
RAN2440 IP Fast Rerouting is required
In case of failure a BFD triggered switchover for NPGEP from WO to SP occurs
VLANs are used also to provide a logical traffic separation through the RNC-cl interface
No encryption method is taken into consideration for the new interface in RU40
When RAN1874: Automatic OMS resiliency is used

If the serving (primary) OMS fails or if the connection between network
elements (RNC/BTS) and the serving OMS fails, the network elements under
the serving OMS automatically connect to the secondary OMS
For RNC2600 co-siting with mcRNC both RNCs will attempt to move under the
same OMS
When RAN1913: HS Cell FACH is used

HSPA is used in Cell FACH state and therefore more users can be supported
in Cell FACH state and smooth data transmission is provided for users not
requiring large data volumes
For UEs cosited on the mcRNC side that are in HS Cell FACH state, the user
data path uses L2-L2 transparent communication between the mac-d entities
in the mcRNC and mac-c entities in the RNC2600

RAS Release - RU40

RNC Release - RN7.0
IPA Platform - A14

RAN2240
mcRNC HW Release 2 Support2

RAN2240: mcRNC Rel2 HW Support
Improving the capacity and

connectivity by
Introducing a new processor
version add-in card
8x8 G memory per module
Approx 2 times more capacity
expected
Supprting up to 8 module
configuration
10GE network interface supported

the mcRNC is able to support higher capacity due to processor evolution

and software optimization

RAN2240: mcRNC Rel2 HW Support, cont.
BMPP2-B Octeon2 Unit

BMPP2-B BCN Multi-Processor Card gen. 2 is a general purpose
processing unit to be used in the BCN platform
The processor type is the Octeon II (CN6880) made by Cavium
The OCTEON II is a 64 bit processor providing 48GHz of computing
power on a single chip across 32-cores
It performs various data plane and control plane processing tasks in a
number of applications
BMPP2-B Add-in Card supports and utilizes the interfaces that the BCN
motherboard infrastructure provides
2x XAUI, 2x PCI Express, UART, USB
Supports up to 4 x 8Gbyte DDR3 DIMM memories.
In addition to a processor block the Add-in Card has an MMC (Module
Management Controller) for HW management tasks and a power supply
block for generating a variety of supply voltages required on board

2 x AMC bay
Reset
Network interfaces / Network interfaces
Inter-module interfaces 2 x 10 GE (SFP+) Indicator LEDs
USB 2.0 (Type B, target) 7 x 1 GE/10 GE (SFP+) 10 x 1 GE (SFP) Synchronization interface
1 x 1 GE (SFP) 2 x in/out (RJ45)
SAS cross-connect
NE management interface Alarm input interface
LMP serial port
2 x 1GE (SFP) 8 x voltage input (RJ45)
(RS-232)
Module management interface eSW/FW update interface

1 x 10/100M/1GE (RJ45) 2 x USB 2.0 (Type A, host)

RAN2240: mcRNC Rel2 HW Support, cont.
The BCN-B module front panel contains the following interfaces:

7 x 10 GigE (SFP+) interfaces for external cabling and inter-module cabling
2 x 10 GigE (SFP+) and ten 1 GigE (SFP) interfaces for external cabling
2 x additional 1 GigE (SFP) interfaces provide access to add-in card slots 1 and 8
for network element management purposes (SSH connection)
1 x 1 GigE (1000Base-T) interface for local hardware management and
debugging purposes (MGMT port)
2 x USB 2.0 interfaces for software downloading (typically during commissioning)
A direct RS232 interface to the local management processor (LMP) for debugging
purposes
A USB 2.0 slave port for software debugging purposes
A SAS connector for hard disk cross-connecting between two BCN modules
2 x RJ 45 connectors for eight external voltage-sensitive alarm inputs with 1 mA
pull-up load
2 x external synchronization interfaces (E1, T1, JT1, 1.544 MHz, 2.048 MHz)

Due to the fast evolution of processor chips it is now possible to greatly

enhance the operation of the mcRNC by introducing a new HW release
to the market
This new hardware is known as mcRNC Release 2 hardware.
A new hardware platform is introduced BCN-B
New processor units are introduced BCMPP-B also known as Octeon2
Processor units
These units are greatly improved from the first Octeon+ units
Cavium Octeon+ CN5650 Cavium Octeon+ CN6680

64 bit 64 bit
VS
12 cores 32 cores
800MHz 48GHz
4 x 2MB DDR DIMS 4 x 8MB DDR DIMS

A special 1 GE interface, the trace port, is used for providing a connection to an
external traffic tracing server
The trace port is used for port mirroring and allows the mirroring of any port connected
to the HiGig virtual backplane to the trace port
7 x 10Gb SFP+ Ports 2 x 10 Gb 10 x 1Gb SFP Ports for

for interbox connectivity. SFP+ Ports external connections to
1 x 1Gb SFP Port for for external NEs
tracing/port mirroring connections
to NEs
External Connectivity:
Maximum connectivity is 20Gbps
1 GE and 10GE can be used
simultaneously S3-B2
10 x 1 GE + 1 x 10GE Module #3 Module #4
2 x 10GE S1-B2 Module #1 Module #2
Supported transmission types are:

Copper Backbone Network NetAct
Single mode optic fiber DCN OMS
Multimode optic fiber

Release2 HW in RU40 supports S1 and S3 configurations

mcRNC capacity targets with BCN-A1 HW in RU40 (mcRNC HW Rel1)
Configuration ID S1-A1 S5-A1

NE level performance
Number of subscribers per RNC coverage area 340000 1380000
AMR Busy Hour Call Attempts 340000 1380000
PS BHCA (HSPA) 428000 1712000
NAS Busy hour call attempts on top of maximum call capacity 1265650 5137050
AMR Erlangs 8500 34500
AMR Erlangs (including soft handover) 11900 48300
NE level capacity
Iub max total UP throughput (CS+PS, FP, UL+DL)/ Mbps 1290 5190
Iub max total HSDPA UP throughput (CS+PS, FP, DL) 910 3660
Iub max total HSDPA UP throughput (CS+PS, FP, UL) 380 1530
Connectivity
Max number of cells 1410 3110
Max number of BTS sites 470 1037
Max number of RRC connected UE's 195000 780000

mcRNC capacity targets with BCN-B2 HW in RU40 ( mcRNC HW Rel2)

Configuration ID S1-B2 S3-B2
NE level performance
Number of subscribers per RNC coverage area 760000 2140000
AMR Busy Hour Call Attempts 760000 2140000
PS BHCA (HSPA) 555000 1573000
NAS Busy hour call attempts on top of maximum call capacity 2829100 7966150
AMR Erlangs 19000 53500
AMR Erlangs (including soft handover) 26600 74900
NE level capacity
Iub max total UP throughput (CS+PS, FP, UL+DL)/ Mbps 2640 7520
Iub max total HSDPA UP throughput (CS+PS, FP, DL) 1850 5260
Iub max total HSDPA UP throughput (CS+PS, FP, UL) 790 2260
Connectivity
Max number of cells 2600 6600
Max number of BTS sites 520 1320
Max number of RRC connected UE's 352000 1000000

RAS Release - RU40

RNC FlexiPlatform - FP6-Cougar

RAN2262
Flexi Multiradio System Modules

RAN2262 Flexi Multiradio System Modules
Rel3 Flexi Multiradio System modules for Flexi WBTSs
FTxx, optional transport sub-module

FPFC, optional stand alone PDU
FPFD, optional PDU in 3U casing
FSMF / FSMG comes with casing and

fan sub-assembly
FBBA/FBBB, optional
3U Casing with Flexi Rel3
modules

RAN2262 Flexi Multiradio System Modules, cont.
Summary
New Flexi Multiradio System Module (FSM) platform is introduced. It has a variable capacity and can be also
used as a capacity expansion for the existing System Modules. New architecture enables flexible and on
demand capacity upgrade path for Flexi site solution. New System Module platform consists of two base
module variants (FSMF and FSMG) and two optional capacity extension sub-modules (FBBA and FBBB).
Furthermore, the new 3U casing can also accommodate optional Power Distribution Sub-module as well as
optional Transport Sub-module. New System Module supports WCDMA and LTE. HW is ready to support also
GSM/EDGE.
Benefits for the Customer
Secure BTS investments with flexible migration from one radio access technology to
another
Flexible capacity upgrade based on pay as you grow concept
Enables higher site capacities and new configurations
New Flexi System Module is well optimized for data services
Functional Description
New Flexi Multiradio System module consists of 3U high casing, which can accommodate a base module,
optional capacity extension sub-modules (up to 2), an optional power distribution sub-module and an optional
transport sub-module. All modules are IP65 class outdoor capable.
There are two System Module (base) capacity variants, FSMF and FSMG:
FSMF:
Optimized for 2+2+2 WCDMA and LTE 1+1+1 support. Performance equals or exceeds FSMD capacity and
features in terms of channel elements (CE) and HSPA throughput (Mbit/s) as well as LTE bandwidth (20MHz)
and throughput.
FSMG:
Optimized for 1+1+1 WCDMA support. Performance equals to half of FSMD capacity in terms of channel
elements (CE) and HSPA throughput (Mbit/s). Adequate LTE support and performance can be gained with an
extension sub-module, FBBA or FBBB.
New Flexi Multiradio System Module (FSM) platform is introduced

It has a variable capacity
can be used as a capacity expansion for the existing System Modules
New architecture enables flexible and on demand capacity upgrade path
for Flexi site solutions
New System Module platform consists of two base module variants
FSMF and FSMG
Two optional capacity extension sub-modules
FBBA and FBBB
New 3U casing can also accommodate
Optional Power Distribution Sub-module
Optional Transport Sub-module
New System Module supports WCDMA and LTE
HW is also ready to support GSM/EDGE

New System Module consists of integrated ethernet transport, clock and control functions,
baseband processing, casing and fans. It can be used as a stand alone System Module or it
can be extended with optional items.
There are four optical links for RF Modules in the base System Module configuration, FSMF or
FSMG alone.
Inside the casing, new System Module can be extended with up to two capacity extension sub-
modules, FBBA/FBBB. Capacity is increased by adding capability to support more users and
performance by increasing the total throughput of the base station.
New System Module can be used as a extension to existing System Modules (Rel1 and Rel2).
Capacity Extension sub-module FBBA & FBBB (Optional)
FBBA:
High capacity extension sub-module to add control and baseband processing and one optical
connection for high capacity sites. FBBA has a equal performance as FSMF in terms of capacity
and throughput.
FBBB:
Moderate capacity extension sub-module to add cost efficient control and baseband
processing capacity and one optical connection for high capacity sites. FBBB has a equal
performance as FSMG in terms of capacity and throughput. It is used e.g. to upgrade FSMG to
support 2+2+2 WCDMA BTS. In LTE case FBBB with FSMF can be used for high capacity LTE
BTS.
Transport interface sub-modules, several variants (Optional). Support for transport modules,
which can be fit in to 3U System Module casing
FSMF
Optimized for 2+2+2 WCDMA and LTE 1+1+1 support
Performance equals or exceeds FSMD capacity and features in terms of
channel elements (CE)
HSPA throughput (Mbit/s)
LTE bandwidth (20MHz) and throughput
FSMG
Optimized for 1+1+1 WCDMA support
Performance equals to half of FSMD capacity in terms of
channel elements (CE)
HSPA throughput (Mbit/s)
Adequate LTE support and performance can be gained with an extension
sub-module, FBBA or FBBB

Current Implementation
The current FSM-r2 variants will be replaced by r3. FSM-r3 support will be in
RU40 and RL30 and deliveries. Interdependencies between Features
The current FSM-r2 outdoor variants will be replaced by this HW feature.
FSM-r3 will inherit r2 outdoor functionalities and features. Indoor variant for
FSM-r3 will be proposed also.
Operational Aspects
R3 will inherit R2 outdoor operability, functionality and features. Possible
new characteristics enable by the new, advanced HW will be proposed
separately. HW Requirements
FSM-r3 will have new, improved HW architecture and it will consist of new
HW items. R3 will also inherit r2 outdoor operability, functionality and
features in terms of environmental and usability requirements. Possible new
characteristics enable by the new, advanced HW will be proposed
separately


New System Module consists of

integrated ethernet transport, clock and control functions
baseband processing
casing and fans
It can be used as a stand alone System Module or it can be extended with
optional items
There are four optical links for RF Modules in the base System Module
configuration FSMF or FSMG
Inside the casing, new System Module can be extended with up to two
capacity extension sub-modules, FBBA/FBBB
Capacity is increased by adding capability of supporting more users
Performance is increased by increasing the total throughput of the
base station
New System Module can be used as a extension to existing Rel1 and
Rel2 System Modules

Optional capacity extension sub-module FBBA & FBBB

FBBA
High capacity extension sub-module to add:
Control and baseband processing
One optical connection for high capacity sites
FBBA has equal performance toFSMF in terms of capacity and throughput
FBBB
Moderate capacity extension sub-module to add:
Cost efficient control and baseband processing capacity
One optical connection for high capacity sites
FBBB has equal performance toFSMG in terms of capacity and throughput
It is used e.g. to upgrade FSMG to support 2+2+2 WCDMA BTS
In LTE cases the FBBB with FSMF can be used as a high capacity LTE BTS
Several optional variants of Transport sub modules that can fit into the 3U
System Module casing

Alarms
There are no alarms related to this feature.
There are no measurements and counters related to this feature.
Key performance indicators
There are no key performance indicators related to this feature.
New parameters
Abbreviated name Full name Managed object

numberOfR99ChannelElements Number of R99 channel elements BTSSCW
hspaConfigurationList List of HSPA configurations LCELGW

BSW/ASW NOT DEFINED

RAS RELEASE RU40
RNC RELEASE RN7.0
BTS Flexi 10 FSM Rel 3 WN 8.0
BTS HARDWARE FLEXI REL.3
mcRNC RELEASE mcRNC3.0

RAN2317
240W Multiradio remote RF

RAN2317 240 W Multiradio Remote RF
Brief description:
This feature enables usage of up to 180 W output power per sector with one Flexi
RF module
Enables possibility to build high capacity and coverage sector for GSM and
WCDMA/LTE
Motivation and benefits:

180 W output power within one Flexi RF module
Flexible configuration and free power allocation to different radio technologies
GSM capacity in the network can be maintained or expanded as needed and
gradually sifted to WCDMA and LTE technologies
Attractive for MORAN operators

RAN2317 240 W Multiradio Remote RF, cont.

The RAN2317: 240 W Multiradio Remote RF feature is a superior future-proof BTS site
solution for all existing and new mobile operators. With this feature it is possible to have
up to 180 W output power per sector configurations with only one physical Flexi Multiradio
BTS RF Module. With this feature it is possible to build high capacity and coverage
sector for GSM and WCDMA/LTE by allocating the power flexibly from one power amplifier
(MCPA) to different radio technologies.
Operator benefits
The RAN2317: 240 W Multiradio Remote RF feature offers excellent evolution path and
expansion possibilities for operators with high GSM traffic. The GSM capacity in the
network can be maintained or expanded as needed and gradually shifted to WCDMA
and LTE technologies.
Full 3GPP RF band support in TX and RX makes this feature superior in terms of
capacity and coverage and makes it also attractive for MORAN operators. Up to 20 MHz
sub-band is available for WCDMA/LTE with 160 W output power allocation and simultaneously
20MHz sub-band can be used for GSM with 80 W output power allocation.
Performance can be further improved by separate optimal Antenna Tilt for GSM,
WCDMA, and LTE

Supported RF Modules:
- FXFA Flexi RF Module 1900 Triple
- FXCA Flexi RF Module 850 Triple
- FXDA Flexi RF Module 900 Triple
- FXEA Flexi RF Module 1800 Triple
Operates in following concurrent modes:
- GSM + WCDMA
- GSM + LTE
Configuration examples:
- WCDMA/LTE 1+1+1 MIMO with 120 W per carrier and GSM 1+1+1 with 60W per carrier.

RAN2317 240 W Multiradio Remote RF, cont.
Functional overview
240 W Multiradio Remote RF feature supports flexible configurations and
free power
allocation to different radio technologies. The following BTS site
configuration examples are possible:
WCDMA/LTE 1+1+1 MIMO with 80+80 W and GSM 1+1+1 with 80W per
TRX with 3 RF Modules
With four antenna feeders per sector one 4-port antenna or two X-pol
antennas can be used. The number of needed antenna lines can be
minimized by using the Flexi Multiradio Combiners (MRC). Also 4 way RX
diversity configurations and up to 2+2+2 WCDMA configurations are
supported with or without MIMO.
This feature requires:

RAN1770/BSS21403: RF Sharing WCDMA GSM RAN2317
or
RAN2126: RF Sharing WCDMA - LTE
Alarms RAN1770
There are no alarms related to this feature.
There are no measurements or counters related to this
feature.
Key performance indicators
There are no key performance indicators related to this
feature.
Parameters
There are no parameters related to this feature.

Release Information
WCDMA Release RU40
BTS (Flexi) WN8.0
HW Requirements Flexi SM Rel2
BSW/ASW BSW

RAN2429
Flexi 3-sector RF Module 2100 80W FRGT

RAN2429 - Flexi 3-sector RF Module 2100 80W FRGT
Flexi Multiradio RF Module 2100MHz (FRGT) is able to support up to three sectors
with maximum 3 x 80 W output power at the BTS antenna connectors
Bandwidth TX 60MHz RX
60MHz
80W
BAND
2100 Support up to:
6 carriers for WCDMA
2x20 MHz carrier for
LTE
The following three-sector

WCDMA BTS configurations
are supported:
Up to 1+1+1
3-sector RF module for 2100 MHz frequency band: Up to 2+2+2
UL: 1920 - 1980 MHz Up to 3+3+3
DL: 2110 - 2170 MHz Up to 4+4+4
Usage: WCDMA, LTE in dedicated or concurrent Up to 5+5+5
mode Up to 6+6+6

RAN2429 - Flexi 3-sector RF Module 2100 80W
FRGT, cont.
Feature ID: RAN2429
This is a new feature which describes Flexi Multiradio RF Module (FRGT) for 2100 MHz. WCDMA and LTE
operations are SW defined.
Benefits for the operator:
3-sector Flexi Multiradio RF Module introduces industry leading RF integration level and smallest power
consumption combined with flexible WCDMA-LTE site evolution.
Functional description:
Flexi Multiradio RF Module HW supports WCDMA and LTE in dedicated or concurrent mode. Flexi Multiradio
RF Module provides 3 x 80W output power at the antenna connector. Maximum capacity of one Flexi
Multiradio RF Module for WCDMA 2100 MHz is up to 6 carriers and up to 2 x 20 MHZ LTE carrier.
Both Tx and RX chains support 60MHz instantaneous band.
Power consumption is optimised by 3-way Doherty PAs.
In 2100MHz band one Flexi Multiradio RF Module supports the following WCDMA configurations:
Up to 1+1+1, - Up to 2+2+2,
Up to 3+3+3, - Up to 4+4+4,
Up to 5+5+5, - Up to 6+6+6,
Existing power levels are available.
Other functionalities:
Integrated class II OVP protection level in DC connector
RET connector
6Gbit OBSAI
With this feature the WCDMA dedicated operation is activated.
HW Requirements:
RAN1016/ RAN1848 Flexi BTS Multimode System Module (FSMC, FSMD, FSME).
Technical details of FRGT

Full name: Flexi Multiradio RF Module 2100 80W
RF Module variant: FRGT
Product code: 472810A
Hardware release: 2.3
Supported technologies: WCDMA, LTE
Supported bands: 2100 (3GPP band I)
Tx bandwidth: 40 MHz
EAC External Alarm Connector
RET Remote Electrical Tilt
Rx bandwidth: 60 MHz
Output power at antenna connectors: 3x80W
Number of pipes: 3
Available power levels: 8, 15, 20, 30, 40, 60, 80* W
Number of optical interfaces: 3 * - from RU40
Optical link throughput: up to 6 Gbit/s

Release Information
WCDMA Release RU30 EP2
BTS (Flexi) WN7.0 2.0

RAN2573
Flexi 3-sector RF Module 900 80W FXDB

RAN2573 - Flexi 3-sector RF Module 900 80W FXDB
Flexi Multiradio RF Module 900MHz (FXDB) is able to support up to three sectors
with maximum 3 x 80 W output power at the BTS antenna connectors
.
Bandwidth TX 35MHz RX
80W 35MHz
BAND
900
Support up to:
4 carriers for WCDMA
6 TRXs for GSM/EDGE
20 MHz carrier for LTE
The following three-sector

WCDMA BTS configurations
are supported:
Up to 1+1+1
3-sector RF module for 900 MHz frequency band: Up to 2+2+2
UL: 880 - 915 MHz Up to 3+3+3
DL: 925 - 960 MHz Up to 4+4+4
Usage: WCDMA, GSM/EDGE, LTE in dedicated or
concurrent mode

FXDB, cont.
Feature ID: RAN2573
This is a new feature which describes Flexi Multiradio RF Module (FXDB) for 900 MHz. FXDB is
able to support one, two or three sectors with maximum 3 x 80 W output power at the BTS
antenna connectors. It has wide 35MHz transmitter and receiver bandwidth.
It can be used in a one sector configuration with maximum 80 W + 80 W 2TX MIMO. The
environmental protection class is IP65.
Benefits for the operator:

FXDB provides the following benefits:
the most cost, size, and weight optimized three-sector BTS site, easier installation,less visual
impact
industry-leading RF integration level
SW configurable radio: the same RF Module for LTE, HSPA+ and WCDMA and GSM/EDGE
the widest ambient temperature range: -35... +55 C
the smallest power consumption and OPEX
3 sector RF Module in one outdoor IP65 protected box
less wind load
can be used as feederless site as well with one DC and one or two optical cables
TX diversity and MIMO 2TX can be build using two 3-sector RF Modules
Technical details of FXDB

. Full name: Flexi Multiradio RF Module 900 80W
RF Module variant: FXDB
Product code: 472573A
Hardware release: 2.3
Supported technologies: GSM, WCDMA, LTE
Supported bands: 900 (3GPP band VIII)
Tx bandwidth: 35 MHz
Rx bandwidth: 35 MHz
Output power at antenna connectors: 3x80W
Number of pipes: 3
Available power levels: 8, 15, 20, 30, 40, 60, 80* W
Number of optical interfaces: 3 * - from RU40
Optical link throughput: up to 6 Gbit/s

FXDB, cont.
RF redundancy option comes as additional advantage
in feederless installations one 3-sector RF Module is more cost effective than three Remote
Radio Heads (RRHs)
typically only one third of DC and optical cabling required compared to the Remote Radio
Heads
can be used as powerfull one sector RRH : 40 + 40 W 2TX MIMO with HW prepared for 4RX.
Functional description:
Flexi 3-sector RF Module 900 80 W (FXDB) supports 3GPP band 8. TX and RX bandwidths
equal 35 MHz for efficient GSM, WCDMA and LTE Multiradio configurations.
FXDB provides:
configurations up to 4+4+4
8, 20, 40, 60 or 80 W mode per sector cotrolled by SW licenses
1 sector configuration with maximum 80 + 80 W 2TX/2RX MIMO
HW prepared for 1 sector max 80 + 80 W 2TX/4RX MIMO in feederless site (optical and
DC cable up to 200 m)
HW Requirements:
RAN1016/ RAN1848 Flexi BTS Multimode System Module (FSMC, FSMD, FSME).
. Release Information
WCDMA Release RU30 EP2

BTS (Flexi) WN7.0 2.0

RAN2573 (FXDB) and RAN2429 (FRGT)
RAN2429, RAN2573 require Flexi System Module hardware release 2 or 3:

. RAN2382 Flexi Multimode System Module FSMC
RAN1016 Flexi Multimode System Module FSMD
RAN1848 Flexi Multimode System Module FSME
RAN2262 Flexi Multiradio System Module FSMF
RAN2429 RAN2573
Flexi 3-sector RF Flexi 3-sector RF
module 2100 80W module 900 80W
FRGT FXDB
or or or or
RAN1016 RAN1848 RAN2262 RAN2382

Flexi System Flexi System Flexi Multiradio System Flexi System
Module FSMD Module FSME Modules (FSMF) Module FSMC

Example of 4+4+4 (1Tx/2Rx) configuration
RAN2429
RAN2573 Sector 3 Sector 2 Sector 1
f1: Rx f1: Rx f1: Rx
Not utilized
f2: Rx f2: Rx f2: Rx
f3: Rx Sector 3 f3: Rx Sector 2 f3: Rx Sector 1
f4: Rx f1: Tx&Rx f4: Rx f1: Tx&Rx f4: Rx f1: Tx&Rx
f2: Tx&Rx f2: Tx&Rx f2: Tx&Rx
2 optical links required to carry 12 cells 4+4+4(@15W)
Older RF Modules (HW 2.0, 2.1, 2.2)
60W output power pipes allow to allocate 4+4+4 configuration with up to 15W
power per carrier
3Gbit optical interface allows to transmit in single optical link up to 16Tx/16Rx
Narrower Tx and Rx bandwidths limit carriers allocation

Example of 4+4+4 (1Tx/2Rx) configuration
RAN2429
RAN2573 Sector 3 Sector 2 Sector 1
RAN2741 f1: Rx f1: Rx f1: Rx
RAN2742 f2: Rx f2: Rx f2: Rx
Utilized f3: Rx Sector 3 f3: Rx Sector 2 f3: Rx Sector 1
f4: Rx f1: Tx&Rx f4: Rx f1: Tx&Rx f4: Rx f1: Tx&Rx
RU40 perspective
1 optical links sufficient to carry 12 cells 4+4+4(@20W)
New RF Modules (HW 2.3)
80W output power pipes allow to allocate 4+4+4 configuration with up to 20W power
per carrier
6Gbit optical interface allows to transmit in single optical link up to 32Tx/32Rx
(available with FSMF)
Wider Tx and Rx bandwidths allow to better carriers allocation
RAN2157
Flexi Lite BTS 2100

RAN2157 - Flexi Lite BTS 2100
Flexi Lite BTS is extremely compact BTS that consists of HW rel.3 BB unit (responsible for
signal processing) + RF unit + integrated antenna (optional) + Ethernet ports
Supports WCDMA technology
The Flexi Lite BTS supports WCDMA/HSPA+ technology.
Due to a small size Flexi Lite BTS it is even more easier to install BTS in dense urban/urban
environment (Flexi Lite BTS offers extremely flexible deployments e.g. walls, lamp posts,
billboards or other street furniture)

RAN2157 - Flexi Lite BTS 2100, cont.

Flexi Lite BTS is a small all-in-one base station optimized for outdoor micro-cell
environment.
The product design, hardware and software is based on the award-winning Flexi
Multiradio BTS platform.
End-user benefits
This feature does not affect the end-user experience.
Operator benefits
This feature benefits operator as follows:
The product can be used in pico and microcellular applications and also as a
coverage fill-in solution. The main use case is in capacity limited networks where
the operator needs to start using smaller cells to be able to deliver the required
system capacity.
Output power is high enough to support indoor coverage building from outdoor
sites.
It is also high enough to drive distributed antenna system for indoor coverage. It
also supports 2TX MIMO.
Supports WCDMA/HSPA services.
RF details
The product supports UMTS band I * (other bands supports available in the future,
based on customer need)
Up to 2 sectors (2 sectors without Rx diversity) and 2 WCDMA carriers per sector are
supported
Flexi Lite BTS supports 2 way Rx diversity (1 or 2 omni carrier configuration case)
10 W + 10 W output power for micro (250 mW + 250 mW output power for pico layer)**
MIMO support (up to 2 MIMO cells)
Indoor/
Receiver sensitivity -121 dBm (tuneable up to -107dBm) Outdoor
Active cooling for highest reliability performance
HSPA peak rates the same as with Flexi Multiradio BTS
up to 84Mbps peak rate with DC-HSPA + MIMO + 64QAM
maximum 140 HSPA users
** Output power can be set
180 CE for Rel99 only * Band I:
between 250mW and 10W
UL: 1920 1980 MHz;

DL: 2110 2170 MHz

Flexi Lite BTS is integrated, small in size, lightweight base station which can be installed
on walls or poles (IP65). The output power level is adjustable from 250mW + 250mW for
pico cells up to 10W+10W for micro cells.
Flexi Lite BTS offers flexible deployments options at walls, lamp posts, utility poles, billboards or
other street furniture. Typical micro-cell outdoor antenna deployments are below roof-top in
heights of about 5 to 15 meters above the ground level.
Typical indoor deployments include exhibition halls, shopping malls, large office spaces,
airports etc. Antenna height in indoor installations is typically from 2 to 5 meters above
ground level. In indoors Flexi Lite BTS is to be mounted either on the wall or the ceiling
or connected to an external distributed antenna system.
Flexi Lite BTS consists of the following elements:
core base station module
optional integrated antenna
optional visual cover
optional pole and wall installation kits
Flexi Lite BTS can be mounted on a wall or on a pole with the supplied hardware. Silent active
cooling enables minimum installation clearance, so Flexi Lite BTS can be installed in locations
that are not much larger than BTS itself (~10l), for example in utility rooms, inside cabinets (any
position possible). All cabling is accessible without dismounting the unit.
Exemplary configurations
BTS dimensions:
2-Omni, (1TX/2RX) in both cells
Size: 380 x 325 x 86 mm (h x w x d), 10L Antenna
filter
TX f1 10W
Outdoor: -35 to +55 C, IP65
TX / RX
Power consumption <200W (100% load)*
RX
f2
Weight: 11 kg Antenna
filter
TX f2 10W
Any position installation possible
TX / RX
Inside cabinet installation possible
RX
f1
1-Omni / 10W (1TX/2RX)

2-Omni / 10W (1TX/2RX)

Air interface configuration

Flexi Lite BTS has two transceivers: two 10W transmitters and two -121dBm
(3G wide area sensitivity) receivers. Flexi Lite BTS operates at:
UL: 1920 1980 MHz
DL: 2110 2170 MHz
Capacity
WCDMA/HSPA capacity:
HSPA peak rates the same as with Flexi Multiradio BTS
up to 84Mbps peak rate with DC-HSPA + MIMO + 64QAM
Baseband capacity:
maximum 140 HSPA users
180 CE for Rel99 only
Transport
Flexi Lite BTS uses IP as a standard transport protocol. Ethernet, both
wireline and fiber, is the standard interface in the Flexi Lite BTS.
Exemplary configurations
2+2, (1TX/1RX) in both sectors (2TX / 2RX), 10W + 10W MIMO

Antenna f1 5W Antenna
filter
filter
TX f1 10W
TX
TX / RX TX / RX
f2 5W
RX RX
Antenna Antenna
filter f1 5W filter f1 10W
TX TX
TX / RX TX / RX
f2 5W
RX RX
1+1 / 10W (1TX/1RX) 1-Omni / 10W + 10W MIMO

2+2 / 5W (1TX/1RX) (2TX/2RX) in above figure
2-Omni / 5W + 5W MIMO
(2TX/2RX)

Connectors Power options:
EAC = External Alarms and Control Nominal voltage 100- 240VAC, 50/60Hz
LMP = Local Management Port Permits 88 276 VAC, 45 66Hz
SYNC_IN = Synchronization Input Tolerates 276 300 VAC maximum 3 minutes
SFP = Optical Ethernet Survives 20ms loss of AC power supply
TX/RX = Transmitter output/Receiver input

Tx/Rx1
AC power supply input
Power (AC) Tx/Rx2
EAC
GND HDMI
GE Sync In Status LMP
SFP
RJ45 HDMI LED RJ45

Local management (LMP)
Ethernet RJ45 (same as with the Flexi Multiradio BTS)
All three speeds; FE (100 Mbit/s), GE (1000 Mbit/s) and 10 Base-T
Common management tool with Flexi Multiradio BTS
External alarms and controls (EAC)
6 external alarms
2 control outputs
HDMI connector
Status LEDs
Theres 2 LEDs indicating the status of the BTS
RF Power status LED
BTS status LED
System Module rel.3 might be commissioned to one out of the three configurations:
Rel99 only (up to 4 cells)
Support of UMTS Rel.99 services, no support for HSPA
Small HSPA configuration (up to 4 cells)
Providing HSPA processing up to 4 HSPA cells (one HSDPA and HSUPA scheduler)
Only one Local Cell Group (LCG) per Flexi Lite BTS is allowed
Note that LCG commissioning is optional.
By default Small HSPA configuration is assumed
Flexi Lite BTS capacity
Table assumes 10km cell

Number of cells Rel99 Only Small HSPA range / 2way Rx Div / 1
LCG
2,5 Su 1,875 Su
1-4 cells
(240 Rel.99 CE) (180Rel.99 CE)
One subunit provides 96 Rel.99 CE
R99 bearers have the same Rel.99 CE consumptions as in RU30/RU40 with System Module rel.2/rel.3

Flexi Lite BTS capacity Interference Cancelation
1 PIC pool
Small HSPA
activated
Table assumes 10km cell
Flexi Lite BTS
range
traffic capacity
0,875 Su
after PIC pool
activation
1 PIC pool can be activated with Flexi Lite BTS

Flexi Lite BTS Small HSPA configuration
One HSDPA scheduler supports: One HSUPA scheduler supports:
up to 4 HSPA cells up to 4 HSPA cells

Up to 240 active users Up to 160 active users
Up to 168 Mbps
However baseband capacity restricts max amount of HSPA users possible with Flexi Lite BTS
Table assumes Small HSPA

Flexi Lite BTS Flexi Lite BTS configuration,10km cell range.
Number of cells
(no PIC) (1 PIC activated) Max amount of HSDPA and
HSUPA users presented in the
table cannot be met at the same
Flexi Lite BTS traffic capacity 1,875 Su 0,875 Su
time.
Subunits available for HSUPA scheduler 1,75 Su* 0,75 Su*

* - Total BTS capacity cannot be
Max amount HSDPA users (UL:R99
180** 84** allocated for HSUPA scheduler (0,125
bearer, DL:HSDPA bearer) subunit must remain for DCH users)
Max amount of HSUPA users ** - PS 16kbps assumed in UL
120*** 72***
(UL:HSUPA bearer, DL:HSDPA bearer)
*** - 10ms TTI FDPCH users assumed

Flexi Lite BTS Small HSPA configuration
HSUPA allocation is done dynamically in steps so called HSUPA resource steps (0,125 subunit)
In case if Rel99 CE licensed baseband resources are overlapping HSUPA licensed baseband
resources overlapped resources can be dynamically exchanged between R99 and HSUPA users
R
9
9
HSUPA or HSUPA or HSDPA
u
R99 users R99 users s scheduler
e
r
s
To allocate the next HSUPA resource step, an

Max baseband capacity available for HSUPA HSDPA scheduler additional free capacity of six Rel99 CE is
(1,75 subunit)
0,625 subunit needed. The required 6 Rel99 CE free on top of
the HSUPA resource step is to avoid a ping-
pong effect in reserving and freeing HSUPA
Max baseband capacity available for R99 resource steps. This is needed so that the
(1,875 subunit) HSUPA resource step is not requested back
immediately after its allocation.
R Therefore HSUPA scheduler can allocate whole

9 available BTS capacity except one HSUPA
9 resource step (0,125 subunit) which must remain
HSUPA or available for R99 traffic.
u
R99 users s
e
r
s
WCDMA Release RU40

I-HSPA System No supported
RNC Release RN7.0
BTS (Flexi Lite) WL7.0.2.0
NetAct OSS 5.4 CD Set3 PP2
HW Requirements Flexi Lite BTS

Flexi RRH 2TX 60W+60W

Flexi Multiradio RRH 2TX 60W+60W
The Flexi Multiradio Radio Remote Radio Head (FHxx) or RRH, consists of
two independent branches,
capable of transmitting and receiving signals of multiple radio technologies concurrently
It is intended for outdoor mounting and
optimized for feederless applications
Up to 6 GSM carriers with 400 KHz minimum carrier separation
2x60 W TX capability (Note that FHxA variants have 2x40 W TX capability)
EGPRS2 and VAMOS support
Up to 4 WCDMA carriers with 4.6 MHz minimum carrier separation
Multi-carrier LTE signal with 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz,
and 20 MHz carrier bandwidth
Multi RAT operation with a combination of GSM, WCDMA, and LTE
Input voltage range 36 - 57 V DC; minimum startup voltage is 40.5 V DC

Flexi Multiradio RRH 2TX 60W+60W, cont.
Benefits
End-user benefits
Operator benefits
One sector Flexi Remote Radio Head supports 2 TX MIMO with high output power
(2 x 60W) for hot spot dense urban capacity sites. It enables easy outdoor
installation close to antennas by maximizing BTS site capacity and coverage for
one sector. FHDB supports 35 MHz TX/RX bandwidth.
FHDB Flexi RRH 2TX 2RX 900 MHz provides the following features:
2x60 W output power with two power amplifiers
optimization for single sector deployment with 2TX MIMO
optical chaining support by HW (two optical connectors with 6 Gbit/s interfaces)
IP65 with -40C to +50C with convection cooling
external alarms and outputs
AISG2.0 Antenna tilt support with external connector (RS485)
Flexi Multiradio RRH 2TX 60W+60W
The supported functions are:

Chaining up to three RF Modules with OBSAI
RP3-01
Integrated antenna line supervision
MHA and RET support
Digital and control circuitry, optical interface, DC
power input, and other necessary functionalities
Integrated DC line OVP, Class II rated to 5kA
pulse
Input DC voltage monitoring
FHDB 900 MHz FHEB 1800 MHz

TX filter frequency range 925-960 MHz 1805-1880 MHz
RX filter frequency range 880-915 MHz 1710-1785 MHz
TX instantaneous bandwidth 35 MHz 35 MHz
RX instantaneous bandwidth 35 MHz 60 MHz
TX filter bandwidth 35 MHz 75 MHz
RX filter bandband 35 MHz 75 MHz
Duplex spacing 45 MHz 95 MHz
LED indications:
Colour Indication
Red, blinking Operation degraded: Major alarm on the RF Module
Red, stable Faulty: Critical alarm on the RF Module
Software download in progress or
Yellow, blinking Configuration in progress: RF resources are being setup,
but not yet activated
Until software download begins or
Yellow, stable The carriers are blocked from BTS or
There is no connection to any System Module
Green, blinking Software downloading and updating
Software configuration is complete or
Green, stable Supervisory: RF resources activated and transmission is possible or
Working normally, no alarm on the RF Module
Stable Red for less than 5 seconds
Switched ON, but the next conditions are not reached yet
and changes to Stable Yellow
Stable Red for less than 5 seconds The module is in the process of resetting
Periodic Red and Green Antenna line device faulty/degraded (RF Module only)
Cylcling Colors (Red, Yellow, and
Module Highlighting
Green), each color stable for 500 ms
2x60 W RRH does not have a TX status LED and the BTS Manager reports its status LED state only

BW and configurations for different Bands
Frequency/Bandwidth TX/RX 900MHz 35/35 MHz (FHDB) 1800MHz 35/60MHz (FHEB)
GSM TRXs 6+6 6+6
WCDMA Carriers 4 + 4 carriers 4 + 4 carriers

LTE BW 1.4/3/5/10/15/20 MIMO 1.4/3/5/10/15/20 MIMO
2 RAT mode for RRH unit GSM and/or WCDMA and/or LTE GSM and/or WCDMA and/or LTE
(Dedicated or Concurrent mode for MCPA)
Output power Up to 60W+60W Up to 60W+60W
MCPA Concurrent mode(s)** - 5G+1U/1L(5MHz) - 5G+1U/1L(5MHz)

Max supported by HW: - 2G+3U - 2G+3U
GSM/LTE, GSM/WCDMA - 4G+1L(10MHz) - 4G+2U/1L(10MHz)
GSM/WCDMA/LTE - 2G+1U+1L(10MHz) - 2G+1U+1L(10MHz)
WCDMA/LTE -2U+1L(10MHz) -2U+1L(10MHz)
-2G+1L(15MHz) -2G+1L(15MHz)
(The capacities shown here are per MCPA -1U+1L(15MHz) -1U+1L(15MHz)
or per branch. RRH has 2 MCPA branches. - 4G+2x2L(15MHz) MIMO with 2 MCPAs - 4G+2x2L(15MHz) MIMO with 2 MCPAs
So the total RRH HW capacity is twice the
MCPA Concurrent Mode as shown here)

Flexible RRH configurations

Dual Duplexer to enable MIMO and 2-way diversity
schemes for 1 sector (2 antenna ports / module)
Up to 6+6 MIMO or 12 with 1 RRH RRH (FHxB) X
Duplexer
TX MCPA
Capacity extensions with chaining RX main LNA
Optical RP3
12+12+12 with 3 RRH
Duplexer
Cost optimized for 1 sector MIMO TX MCPA
configurations LNA
RX main
Configurations:
Minimum: up to 6+6 MIMO (1 module)
Maximum: up to 12+12+12 (3 RRH)
With these power steps:
1 TRX * 60W (2 ant/sect) Flexi RRH 2TX 900 and 1800
MCPA1 MCPA2 RRH unit
2 TRX * 30W (2 ant/sect)
3 TRX * 20W (2 ant/sect) GSM 1TRX@60W/TRX 1TRX@60W/TRX 2TRX@60W/TRX
Dedicated 2TRX@30W/TRX 2TRX@30W/TRX 4TRX@30W/TRX
4 TRX * 15W (2 ant/sect) Mode 3TRX@20W/TRX 3TRX@20W/TRX 6TRX@20W/TRX
5 TRX * 12W (2 ant/sect) 4TRX@15W/TRX 4TRX@15W/TRX 8TRX@15W/TRX
5TRX@12W/TRX 5TRX@12W/TRX 10TRX@12W/TRX
6 TRX * 8.5 W (2 ant/sect) 6TRX@8.5W/TRX 6TRX@ 8.5W/TRX 12TRX@8.5W/TRX

Example of carriers allocation in 3 sector site for sector configuration type I:
Utilized RF module
FRGP (20 MHz Tx, 20 MHz Rx, 60 W output power)
Possible carriers combination
up to 1+1+1 WCDMA and up to 15 MHz LTE
Sector 1 Sector 1 Sector 2 Sector 2 Sector 3 Sector 3

LCR2: Tx & Rx LCR2: Tx & Rx LCR4: Tx & Rx LCR4: Tx & Rx LCR6: Tx & Rx LCR6: Tx & Rx
Sector 1 Sector 1 Sector 2 Sector 2 Sector 3 Sector 3
LCR1: Tx & Rx LCR1: Tx & Rx LCR3: Tx & Rx LCR3: Tx & Rx LCR5: Tx & Rx LCR5: Tx & Rx
WCDMA: 1+1+1 MIMO, 30W power per carrier

LTE: 1+1+1 MIMO, 30W power per carrier, 15 MHz channel BW

License Key:
WCDMA LK logic is same as for any other WCDMA BTS except for single carrier, 20W O/P
power for each branch is included in the 3 sector RF Module pricing
No additional branch activation licenses are required
If maximum RF power per branch exceeds 20W, the existing 40W or 60W power licenses
need to be ordered accordingly
8W license needs to be ordered separately, if required
Existing 2nd carrier activation licenses need to be ordered in case no. of carriers in each
branch is more than one

WCDMA Release RU40

RNC Release RN7.0
BTS Flexi WN8.0

RAN2489
Carrier Bandwidth 3.8MHz

Improves GSMWCDMA re-farming spectrum efficiency
2.2 MHz 2.0

2.6 MHz
2.6 MHz MHz
f[MHz] f[MHz]
BCCH WCDMA 4.2MHz PC TCH BCCH WCDMA PC TCH

GSM 0.2MHz GSM 0.2MHz GSM 0.2MHz 3.8MHz GSM 0.2MHz

RAN2489 - Carrier Bandwidth 3.8MHz, cont.
WCDMA can be deployed with different carrier bandwidth requirements using Flexi WCDMA BTS
filtering technology
It is possible to select 3.8 MHz carrier bandwidth in uplink for WCDMA operation
Especially useful when operator's frequency spectrum where UMTS is to be deployed is limited.
Decreased carrier bandwidth need will ease refarming deployment compared to standard Flexi
WCDMA BTS solution.
The basic assumption is that GSM and UMTS base stations will be co-sited when using 3.8 MHz
deployment.
Benefits
End-user benefits
Operator benefits
This feature benefits operator as follows:
improved refarming solution with more efficient UMTS introduction

CAPEX savings thanks to better spectrum efficiency (maximum Multiradio HW
utilization)
Two additional GSM channels are obtained with 3.8 MHz compared to 4.2 MHz
bandwidth solution.

Transceiver Hardware supporting 3.8Mhz bandwidth (TX and RX filters)

FXCA / FXDA / FHDA HW version A.203 or later:
RAN2046 - Flexi 3-sector RF Module 850 (FXCA), RU20 Earlier HW versions of FXCA/FXDA/FHDA are not known
to support 3.8MHz BW. HW versions earlier than A.203
RAN1768 - Flexi 3-sector RF Module 900 (FXDA), RU20 need to be upgraded in order to support 3.8 MHz BW
RAN1895 - Flexi RRH 2TX 900 (FHDA), RU30 EP1
RAN2573 Flexi 3-sector RF module 900 80W (FXDB), RU30 EP2
RAN2558 Flexi RF Module 1800 Triple 80W (FXEB), RU50
RAN2747Flexi RF Module 900J Triple 80W (FXJB), RU50
RAN2489
RAN2046 Flexi 3- RAN1768 Flexi 3- RAN1895 Flexi RAN2573 Flexi 3-

sector RF Module sector RF Module RRH 2TX 900 sector RF Module
850 FXCA 900 FXDA FHDA 900 80W FXDB

Transceiver Hardware partially supporting 3.8Mhz bandwidth (RX filters)

RAN2741 Flexi 3-sector RF Module 850 90W (FXCB), RU30 EP2
RAN2615 Flexi RF Module 900-J Triple 70W (FXDJ), RU30 EP1
RAN2692 Flexi RRH 2TX 900 (FHDB), RU40
RAN2158 Flexi RF Module 1800 Triple 70W (FXEA), RU40
RAN1575 Flexi RF Module 1900 Triple 70W (FXFA), RU20
RAN2489
RAN2615 Flexi RF RAN1575 Flexi RF

RAN2741 Flexi 3- RAN2692 Flexi RAN2158 Flexi RF
Module 900-J Module 1900
sector RF Module RRH 2TX 900 Module 1800
Triple 70W Triple 70W (FXFA
850 90W FXCB (FHDB) Triple 70W (FXEA
(FXDJ),

Release Information
RAS Release - RU40
BTS Release (Flexi 10) - WBTS8.0
BTS HW Release - RFM Rel2.2/RFM Rel2.3/RFM Rel3.0/SM
Rel1/SM Rel2/SM Rel3

Activating Carrier Bandwidth 3.8MHz :

Licence Feature Code 3857 and 4437 (BTS licences)
RAN2489 is activated from BTS SM via BPF parameter: rxBandwidth in
commissioning phase
BTSSM checks whether selected RFM/RRH supports configurable RX BW level
or not
Check is done by BPF property Support.Of.Rx.Bandwidth.List
If property exists, then RFM/RRH supports configurable RX BW level
if property does not exist, then RFM/RRH does not support configurable RX
BW level
Supported BW: 4.2, 4.0, 3.8 (RAN2489 + CN5088)
When the operator does not change RX BW level then rxBandwidth shall be left
empty
All digital filters, uplink and downlink, have to be set-up correctly before the
corresponding carrier is enabled
Carriers must be disabled before any filter configuration is changed
Each change of filter BW requires a WBTS reset
RAN2111
Flexi WCDMA Software Download Capability for Antenna

Line Devices

RAN2111 - Flexi WCDMA Software Download Capability for Antenna
Line Devices
Software download capability introduced for Antenna Line Devices

minimizing service interruption, eliminating the need for site visits and
tower crew visits for ALD software upgrades

RAN2111 - Flexi WCDMA Software Download
Capability for Antenna Line Devices, cont.
The aim of this feature is to enable Antenna Line Device
software upgrades using the BTS Site Manager or NetAct to
initiate the download
Supported devices are MHA (Mast Head Amplifiers), RET
(Remote Electical Tilt), Smart Diplexers
Currently SW downloads requires service interruption in order
to communicate to the ALD - normally a site visit with
approximately 30min service break / antenna line
This feature eliminates site visits
Causes about a 1 minute long degradation to RX levels when
the device restarts

Line Devices
Release Information
RAS Release - RU40

BTS Release - Flexi WBTS8.0
BTS HW Release - RFM Rel1, RFM Rel2, RFM Rel2.1, RFM Rel2.2,
RFM Rel2.3, RFM Rel3.0, SM Rel1, SM Rel2,
SM Rel3.

Line Devices
Activating Flexi WCDMA Software Download Capability for Antenna Line

Devices :
Requires BTS licence Licence feature code 1604
Connect to the BTS with BTS Manager
Check that the licence is installed

Line Devices
Activating Flexi WCDMA Software Download Capability for Antenna Line

Devices :
Open the recommissioning dialogue, navigate to pg14 and tick the checkbox
SW update for antenna line devices in use

Line Devices
Activating Flexi WCDMA Software Download Capability for

Antenna Line Devices :
From the Antenna menu bar select Create/Modify TargetBD_EXD.xml
The following window will open:

Line Devices
This window allows for the creating and modifying of files where the user can
define the software to be downloaded to external devices like MHA and RET using
the normal SW update function
If a TargetBD_EXD.xml file is present, select the Create file from existing
TargetBD_EXD.xml check box and select the desired file from the file selector
If no file is present select Import BTS HW Info to import manufacturer, product
code and HW version information to the table
Import BTS HW Info is shown only in online mode.

Line Devices
Enter missing values in Manufacturer, Product code, HW version and SW version
columns
Browse for the software files

Line Devices
Select the software update option
Normal SW version is
checked. Upgrade is possible
only if SW is different than the
SW installed on ALD device (ALD
SW version is compared to string
typed in SW version column).
Forced SW update is forced,
regardless on ALDs current SW
version and SW version field.
Restricted SW is not updated
to particular ALD.
Select the Save As button to save the TargetBD_EXD.xml file and provide a
name for the file

Line Devices
Select the Update SW button to open the Update SW to BTS Site dialog
box with selected theTargetBD_EXD.xml
Select theActivate SW after update check box and click Update.

RAN2591
Selective BTS Resource Re-Balancing in mcRNC

Load sharing of CSPU resources is optimized
BTS-2 BTS-6
BTS-1
BTS-4
BTS-3 BTS-5
BTS-7
Load Load
Alarm threshold Alarm threshold
BTS-2 BTS-2
BTS-7 BTS-7 BTS-2
BTS-5 BTS-5
BTS-6 BTS-6
BTS-3 BTS-4 BTS-3 BTS-4
BTS-1 BTS-1
CSCP-0 CSCP-1 CSCP-2 CSCP-3 #CSCP CSCP-0 CSCP-1 CSCP-2 CSCP-3 #CSCP

Reallocation of BTSs to a less loaded CSPU is performed in a controlled manner

Common channel resources are statically allocated to CSPUs in a round robin
sequence during the NBAP link configuration phase
Although the CSCP algorithm considers the weight of the WBTS in the selection
algorithm the CSCP load could easily become unstable due to some mass events
Load peaks for CSCPs is generated due to a large number of RRC connections
causing unnecessary RRC connection request rejections
Common Channel reallocation between CSCPs is introduced to rebalance the
CSCP loads
Moderately loaded WBTS are re-allocated from overloaded CSPUs to less loaded
CSPUs based on their load capabilities
Configurable load thresholds and BTS Weights are used to evaluate the load
balance of the CSPUs
The mcRNC profiles the load and the weight trend of the WBTSs
When the set threshold for CSPU is reached or exceeded an alarm is triggered
The rebalancing can be manually triggered when required

The load for each CSCP is calculated by the mcRNC and BTS re-allocation is
started between the CSPUs to keep the CSCP loads balanced
BTSs can be excluded from the rebalancing process by adding the BTS to the
RebalanceBlockBtslist
There is no service break during the re-allocation
A small number of calls may be terminated
The re-allocation will not take place if there are emergency calls ongoing
The BTS cells have CPICH and BCCH transmitting all the time, but the CCH
traffic will have a break of a few seconds
DCHs and Mac-d flows are handed over to the neighboring cells
The feature introduces a new RNC object RNCERM
RAN2591 cannot be used with RAN2117 - RNC2600 Co-siting with mcRNC

New parameters:
Managed
RNCERMId RNCERM Identifier RNCERM
RNCERMChangeOrigin Change origin for RNCERM object RNCERM
RebalanceBlockBtslist Blocked BTSs for BTS resource re-balancing RNCERM
DonateCscpLoadThrHi CPU load high threshold for donating CSCP selection RNCERM
RecvCscpLoadThr CPU load threshold for receiving CSCP selection RNCERM
NumOfDaysForLM Number of days for load measurement period RNCERM
MaxBtsForRebalance Max number of BTSs selected for resource re-balancing RNCERM
CscpOverloadRatioThr Ratio threshold for overloaded CSCP RNCERM
BTSRebalanceEnabled BTS Resource Re-balancing Enabled RNCERM
NbrAMRCallsAllwdToDrop Maximum number of AMR calls allowed to drop RNCERM
Existing alarms:
Alarm ID Alarm name
7786 WBTS OUT OF USE
3773 CSCP OVERLOAD

Activating Selective BTS Resource Re-Balancing in mcRNC :

Licence Feature Code = 3897
Create the RNCERM object with OMS Element manager or with NetAct
Configurator.
The parameters below will be created with default value during the RNCERM
object creation. These parameters can be modified with the OMS Element
manager or using NetAct Configurator after the RNCERM object is created
RNCERM-RebalanceBlockBtslist
RNCERM-DonateCscpLoadThrHi
RNCERM-RecvCscpLoadThr
RNCERM-NumOfDaysForLM
RNCERMMaxBtsForRebalance
RNCERMCscpOverloadRatioThr
RNCERM-NbrAMRCallsAllwdToDrop
Set the RNFC-BTSRebalanceEnabled parameter value to Enabled using the

OMS Element manager or with NetAct Configurator

Release Information
RAS Release - RU40

RNC FlexiPlatform FP6-Cougar
IPA Light IL5


01 - RN33211EN40GLA1 - RU40 Release Hands-On Workshop PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

01 - RN33211EN40GLA1 - RU40 Release Hands-On Workshop PDF

Загружено:

Авторское право:

Доступные форматы

RN3321-40A

RU40 Release Hands-on Workshop

For public use IPR applies

Intellectual Property Rights

For public use IPR applies

After completing this training the participant shall be able to:

- Describe, Activate and test selected RU40 features

For public use IPR applies

For public use IPR applies

RAN1877 End-user experienced DL Throughput

For public use IPR applies

RAN2296 Transport sub-Module "FTIF" Eth+E1/Ta/JT1 for

For public use IPR applies

RAN2117 RNC2600 Co-Sitting with Multicontroller RNC

For public use IPR applies

For public use IPR applies

Layering in RRC Connection Release

For public use IPR applies

RNC triggers layering in order to direct a UE to other WCDMA layer.

Layering is supported from common and dedicated channels

Layering decision takes into account UE band capability

For public use IPR applies

RRC connection setup load can be distributed to desired frequencies .

For public use IPR applies

Target UARFCN is given to

UE goes to Idle Mode and

If layer change is triggered, the new frequency info is included to

For public use IPR applies

For public use IPR applies

No UARFCN Target Info is given to UE when releasing RRC connection

For public use IPR applies

UE is ordered to camp on a specific frequency layer (UARFCN)

For public use IPR applies

M1006C269 RRC Connection Release WCDMA Redirection

For public use IPR applies

For public use IPR applies

The feature code for this feature is 3898.

To set the feature state to ON, use the following command:

HSPA 128 Users per cell

For public use IPR applies

Maximum number of HSPA end users in

Number of users in other states

For public use IPR applies

Max no. of active users in HS CELL_FACH per cell 12

The maximum number of 128 UEs

HSPA users per cell is 128 128 UEs Serving HSUPA

(both HSUPA and HSDPA). users only are

For public use IPR applies

Number of HSPA users will in general increased numbers of

For public use IPR applies

DCH BTS of the active set

C With this feature the UE is taken

For public use IPR applies

For public use IPR applies

For public use IPR applies

Interdependencies between features

Number of HSPA users per cell is increased from 72 to 128.

For public use IPR applies

RAN2382 RAN1016 RAN1848 RAN2262

For public use IPR applies

Network Design Impact of HSPA 128 Users per Cell

HSPA 128 Users

Carrier capacity Downlink spreading