You are on page 1of 124

WCDMA RAN Release RAS06

Features Under Development

DN0671022 Nokia Siemens Networks 1 (124)


Version 1.4.0
The information in this document is subject to change without notice and describes only the product defined in
the introduction of this documentation. This document is intended for the use of Nokia Siemens Networks
customers only for the purposes of the agreement under which the document is submitted, and no part of it
may be used, reproduced, modified or transmitted in any form or means without the prior written permission of
Nokia Siemens Networks. The document has been prepared to be used by professional and properly trained
personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the documentation.
The information or statements given in this document concerning the suitability, capacity, or performance of the
mentioned hardware or software products are given as is and all liability arising in connection with such
hardware or software products shall be defined conclusively in a separate agreement between Nokia Siemens
Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that
the instructions contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be
covered by the document.
Nokia Siemens Networks will correct errors in the document as soon as possible. IN NO EVENT WILL NOKIA
SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR ANY MONETARY LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS
DOCUMENT OR THE INFORMATION IN IT
This document and the product it describes are considered protected by copyrights and other intellectual
property rights according to the applicable laws.
Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia
Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective owners, and they are
mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2007. All rights reserved.

2 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Contents

1 Radio Resource Management and Telecom Features ......................10


1.1 Radio Access Bearer Combinations.......................................................10
1.1.1 Wideband AMR Codec Set (12.65, 8.85, 6.6) ........................................10
1.2 HSDPA ...................................................................................................12
1.2.1 16 kbit/s Return Channel DCH Data Rate Support for HSDPA..............12
1.2.2 HSDPA 15 Codes...................................................................................13
1.2.3 HSDPA Code Multiplexing .....................................................................15
1.2.4 HSDPA 48 Users per Cell ......................................................................17
1.2.5 Shared HSDPA Scheduler for Baseband Efficiency ..............................18
1.2.6 HSDPA Dynamic Resource Allocation ...................................................21
1.3 HSUPA ...................................................................................................24
1.3.1 Basic HSUPA .........................................................................................24
1.3.2 HSUPA Basic RRM ................................................................................27
1.3.3 HSUPA BTS Packet Scheduler..............................................................28
1.3.4 HSUPA Handovers.................................................................................29
1.3.5 HSUPA Congestion Control ...................................................................31
1.3.6 HSUPA with Simultaneous AMR Voice Call...........................................33
1.4 HSPA Mobility ........................................................................................35
1.4.1 HSPA Layering for UEs in Common Channels ......................................35
1.5 User Experience.....................................................................................37
1.5.1 HSDPA 10 Mbps per User .....................................................................37
1.5.2 HSDPA 14.4 Mbps per Cell....................................................................38
1.5.3 HSUPA 2.0 Mbps ...................................................................................39
1.6 Capacity and Efficiency ..........................................................................41
1.6.1 Flexible Iu ...............................................................................................41
1.7 Location Services ...................................................................................43
1.7.1 Emergency Call Redirect to GSM ..........................................................43
1.7.2 Latency Statistics for UE Positioning......................................................44
1.8 Supplementary Telecom Features .........................................................45
1.8.1 MORAN for up to 4 Operators................................................................45

2 Transmission & Transport...................................................................48


2.1 BTS Transport Interfaces .......................................................................48
2.1.1 Ethernet Interface Unit IFUH (Iub User Plane) for AXC .........................48
2.1.2 Ethernet+E1/T1/JT1 Interface Unit (Iub User Plane) for Flexi
WCDMA BTS .........................................................................................49
2.2 Transport Efficiency................................................................................51
2.2.1 Dynamic Scheduling for HSDPA with Path Selection ............................51
2.2.2 Dynamic Scheduling for NRT DCH with Path Selection.........................53
2.2.3 Path Selection ........................................................................................54
2.2.4 Transport Bearer Tuning ........................................................................56
2.2.5 UBR+ for Iub User Plane........................................................................57
2.3 Transport Redundancy...........................................................................59
2.3.1 Flexi WCDMA BTS IMA Based AAL2 Uplink CAC.................................59
2.4 IP Transport ...........................................................................................61

DN0671022 Nokia Siemens Networks 3 (124)


Version 1.4.0
2.4.1 Hybrid BTS Backhaul ............................................................................ 61
2.4.2 ATM over Ethernet for BTS ................................................................... 63

3 Operability............................................................................................ 65
3.1 Network Monitoring and Maintenance ................................................... 65
3.1.1 RNC GUI for BTS Connection Resources............................................. 65
3.1.2 Collection of Key Counters .................................................................... 68
3.1.3 Alarms for PM Measurement Data Transfer Failures ............................ 70
3.1.4 RNC Support for Traffica ....................................................................... 72
3.2 Configuration Management ................................................................... 75
3.2.1 Dynamic Access Class Restriction ........................................................ 75
3.2.2 Selectable RNW Plan Activation Mechanism ........................................ 77
3.2.3 Flexi WCDMA BTS Support for RNS Split............................................. 78
3.2.4 Direct Activation of RNW Changes Using NWI3 ................................... 80
3.3 O&M Security ........................................................................................ 82
3.3.1 Centralised User Information Management for BTS.............................. 82
3.3.2 IP Address & Port based Filtering for BTS LMPs .................................. 83
3.3.3 IP Security for O&M Traffic between RNC and NetAct.......................... 85
3.3.4 Mass Change of Local BTS Passwords ................................................ 86

4 Performance Monitoring ..................................................................... 88


4.1 Measure................................................................................................. 88
4.1.1 3GPP TS 32.403 Related Counter Additions for RAN........................... 88
4.1.2 ATM Transport Statistics Reporting in RAN .......................................... 90
4.1.3 Cell Throughput Measurements in Serving RNC .................................. 92
4.2 Trace ..................................................................................................... 94
4.2.1 HSDPA Subscriber Trace...................................................................... 94
4.2.2 HSUPA Subscriber Trace...................................................................... 96

5 RNC Solution ....................................................................................... 98


5.1 WCDMA RNC Capacity and Connectivity Upgrades............................. 98
5.1.1 Linux Based OMS Replacing NEMU ..................................................... 98
5.1.2 Carrier Connectivity Optimized RNC450 ............................................... 99

6 BTS Solution ...................................................................................... 102


6.1 Flexi WCDMA BTS Site Solutions and Features................................. 102
6.1.1 Flexi WCDMA BTS 3GPP Antenna Tilt Support.................................. 102
6.1.2 Flexi WCDMA BTS AISG MHA Support.............................................. 103
6.1.3 40W Remote Radio Head 2100........................................................... 104
6.1.4 External GPS Synchronisation for Flexi BTS System Module
Rel 1 .................................................................................................... 105
6.1.5 Support for FRMB/C Unit in Flexi WCDMA BTS ................................. 107
6.1.6 FADB Flexi Multiradio Combiner for 900MHz...................................... 108
6.1.7 FACB Flexi Multiradio Combiner for 850MHz...................................... 109
6.1.8 FAGB Flexi Multiradio combiner for 2100MHz .................................... 111
6.2 Common WCDMA BTS Site Solutions and Features.......................... 113
6.2.1 Extended Cell (180km) ........................................................................ 113

4 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
6.2.2 Pico WCDMA BTS with Ethernet Transport .........................................115
6.2.3 WMHD Mast Head Amplifier ................................................................117
6.2.4 Pico WCDMA BTS Rel.2 SW ...............................................................119
6.2.5 UltraSite EDGE Wideband Combiner for WCDMA Refarming.............123

DN0671022 Nokia Siemens Networks 5 (124)


Version 1.4.0
Introduction

This document provides the list of features under development for the WCDMA Radio
Access System Release 06 (RAS06).

The scope of the RAS includes Radio Network Controller (RNC), Base Station (BTS)
and Transmission. The ATM Cross-connect (AXC) unit provides the transmission
interfaces for the BTS. The RAS is managed with the Operations Support System
(OSS) and it interfaces with both circuit-switched (CS) and packet-switched (PS) core
networks (CN) over the Iu interface.

This document describes the features in Nokia Siemens Networks' WCDMA RAS06.
The WCDMA RAS Release 06 specification base line is 3GPP Release 6. All the
features in this document are Nokia Siemens Networks RAS level Features Under
Development and there may be changes to the final solutions due to the final
screening and 3GPP's standardisation changes. This document does not cover the
CN, GSM system and Mobile Station support but only Nokia Siemens Networks
WCDMA RAS level issues.
The content of this document is subject to change mainly due to the status of
standardisation and the actual release definition process.
This document is NON BINDING.

6 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Summary of changes

Version Date Author Approver Changes

1.0.0 - Jyrki Tero Kola Internal version


Kaasinen

1.1.0 2006-10-31 Jyrki Tero Kola First customer version


Kaasinen

1.2.0 2007-04-12 Jyrki Tero Kola Document structure changed to Nokia Siemens
Kaasinen Networks profile.
HSDPA 10 Codes merged with HSDPA 15 Codes. A
separate feature is not needed for HSDPA 10 Codes
as it is a subset of HSDPA 15 Codes feature.
Flexi WCDMA BTS Mast Head RF Module 1.7/2.1
20W renamed to Flexi WCDMA BTS Mast Head RF
Module 1.7/2.1 40W cause output power upgraded to
40W.
Flexi WCDMA BTS Mast Head RF Module 2.1 20W
renamed to Flexi WCDMA BTS Mast Head RF
Module 2.1 40W cause output power upgraded to
40W.
Extended Cell (60km) renamed to Extended Cell
(180km) cause maximum cell range upgraded from
60 to 180 km.
ATM Measurement Administration in RNC linked to
Selectable ATM Measurement Administration in RNC
(RAN1214) and moved to RU10.
Flexi WCDMA BTS Distribution for Long Distance
moved to RU10.
Flexi WCDMA BTS Mast Head RF Module 20W
Carrier Power Support postponed from feature
content.
Wideband AMR Codec Set (12.65, 8.85, 6.6) moved
to RAS06 from RAS05.1ED.
New feature added: HSDPA 10 Mbps per User.
New feature added: HSDPA 14.4 Mbps per Cell.
New feature added: HSUPA 2.0 Mbps.
New feature added: MORAN for up to 4 operators.
New feature added: Flexi WCDMA BTS IMA Based
AAL2 Uplink CAC.
New feature added: RNC GUI for BTS Connection
Resources.
New feature added to: Mass Change of Local BTS

DN0671022 Nokia Siemens Networks 7 (124)


Version 1.4.0
Version Date Author Approver Changes
Passwords.
New feature added: Linux Based OMS Replacing
NEMU.
New feature added: External GPS Synchronisation
for Flexi BTS System Module Rel 1.
New feature added: Sameband Combiner for Flexi
WCDMA BTS 2100MHz.
New feature added: WMHD Mast Head Amplifier.
1.3.0 2007-07-02 Jyrki Tero Kola Nokia Integrated O&M for 3G Pico BTS merged with
Kaasinen Pico WCDMA BTS with Ethernet Transport feature.
Flexi WCDMA BTS Mast Head RF Module 1.7/2.1
40W renamed to 40W Remote Radio Head 1.7/2.1.
Flexi WCDMA BTS Mast Head RF Module 2.1 40W
renamed to 40W Remote Radio Head 2100.
Pico BTS rel. 2 renamed to Pico WCDMA BTS with
Ethernet Transport.
Sameband Combiner for Flexi WCDMA BTS 900MHz
(Tx Carrier Combiner for Dual Duplex Support)
renamed to Sameband Combiner for Flexi WCDMA
BTS 900MHz.
Sameband Combiner for Flexi WCDMA BTS 850MHz
(Tx Carrier Combiner for Dual Duplex Support)
renamed to Sameband Combiner for Flexi WCDMA
BTS 850MHz.
External PHS Filter for Flexi WCDMA BTS
postponed.
New feature added: Support for IPSU unit in Flexi
WCDMA BTS.
1.4.0 2007-11-09 Jyrki Tero Kola Sameband Combiner for Flexi WCDMA BTS 900MHz
Kaasinen renamed to FADB Flexi Multiradio Combiner for
900MHz.
Sameband Combiner for Flexi WCDMA BTS 850MHz
renamed to FACB Flexi Multiradio Combiner for
850MHz.
Sameband Combiner for Flexi WCDMA BTS
2100MHz renamed to FAGB Flexi Multiradio
combiner for 2100MHz.
Support for IPSU unit in Flexi WCDMA BTS renamed
to Support for FRMB/C unit in Flexi WCDMA BTS.
Following BTS features delivery changed On Top of
RAS 06:
40W Remote Radio Head 2100
Support for IPSU unit in Flexi WCDMA BTS
FADB Flexi Multiradio Combiner for 900MHz
FACB Flexi Multiradio Combiner for 850MHz

8 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Version Date Author Approver Changes

40W Remote Radio Head 1.7/2.1 postponed.


New feature added: Carrier Connectivity Optimised
RNC450.
New feature added: Pico WCDMA BTS Rel.2 SW.
New feature added: UltraSite EDGE Wideband
Combiner for WCDMA Refarming.

DN0671022 Nokia Siemens Networks 9 (124)


Version 1.4.0
1 Radio Resource Management and
Telecom Features

1.1 Radio Access Bearer Combinations

1.1.1 Wideband AMR Codec Set (12.65, 8.85, 6.6)

Feature ID: RAN831

Summary: Wideband AMR speech codec enhances audio bandwidth from 300Hz - 3.4
KHz to 50Hz - 7kHz, which improves the transparency of calls. Enhanced lower
frequency response makes voice warmer whilst enhanced higher frequency responce
improves intimacy of voice.

Benefits for the operator: Wideband AMR provides step-like improvement on voice
quality over current telephony solutions without RAN capacity trade-offs since the bit
rates are similar to AMR. The TrFO/TFO needed due to wideband AMR (WB-AMR) will
reduce the need of CN investments.

Functional description: This feature supports a set of WB-AMR codec modes 12.65,
8.85 and 6.6 kbps. WB-AMR provides better speech quality than narrowband AMR
(NB-AMR) and fixed lines (G.711 PCM) between WB AMR capable UEs. To avoid
downsampling from 16 kHz to 8 kHz, yielding to quality degradation, either TFO or
TrFO is needed.
The RNC handles the WB-AMR modes as well as Multi RABs similarly to NB-AMR.
The codec modes 12.65, 8.85 and 6.6 kbps form a set of bit rates (TFS) that is
assigned to every WB-AMR call. The limited TFCS in multi-RAB cases, the
functionality of TFO/TrFO and managing the Iu Support Mode are similar to the feature
AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75).

10 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Operational aspects: This feature can be switched on and off with an operator-
controllable parameter. If the feature is off, the RNC rejects all WB-AMR calls. In
addition, WB-AMR must be enabled at the same time in all RNCs in the operators NW.
The mobility between the RNS is not otherwise possible for WB-AMR calls (the radio
link setup over Iur interface fails as well as SRNC relocation fail).
The BTS supporting this feature must be rolled out in the network before activating this
feature.
The operator can follow up through new counter the setups and durations for each
available WBR AMR codec.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 M13.6 - U3C 3GPP
Rel-5

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC parameter file Long-term ON/OFF
licence

DN0671022 Nokia Siemens Networks 11 (124)


Version 1.4.0
1.2 HSDPA

1.2.1 16 kbit/s Return Channel DCH Data Rate Support for HSDPA

Feature ID: RAN1013

Summary: The uplink (UL) dedicated channel (DCH) data rate of 16 kbit/s for high-
speed downlink packet access (HSDPA) return channel is supported.

Benefits for the operator: OPEX and CAPEX savings can be achieved by more
flexible resource allocations for HSDPA.

Functional description: This feature adds 16 kbps data rate to the set of data rates
available for an HSDPA UL-associated DCH. As a result, the enabled data rates are
16 kbps, 64 kbps, 128 kbps and 384 kbps. Radio resource management (RRM)
features "Flexible upgrade of NRT DCH data rate" and "Throughput-based optimization
of packet scheduler" controls the dynamic selection of HSDPA UL-associated DCH
data rate according to actual utilization of the channel. The utilisation thresholds
controlling the bit rate upgrades and downgrades are operator configurable.
In case of baseband congestion, the "Priority Based Scheduling" feature will
downgrade the existing DCH(s) to a lower data rate. With growing traffic, the existing
DCHs are downgraded from higher data rates eventually down to 16 kbit/s until the
maximum number of users in the BTS is achieved.
This feature provides flexibility for using HSDPA resources. High bit rates can still be
achieved with low number of WSPs either with low load or by adjusting the minimum
allowed bit rate of the UL DCH to 64 kbit/s (less users). By having 16 kbit/s data rate
supported for HSDPA return channel, the operator can optimize the BTS WSP
resource consumption.
Similarly, transport resources are saved, as overbooking functions more efficiently
when there is more granularity on the nominal bit rates.
16 kbps UL-associated DCH is supported also together with AMR/WB-AMR voice call.

Current implementation: Prior to this feature, the supported data rates for HSDPA
UL-associated DCH are 64 kbps, 128 kbps and 384 kbps.

Operational aspects: The BTS SW version required for this feature must be updated
to the network (NW) before activating the feature in the RNC.

12 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
The operator can follow up through new counters when a 16 kbit/s return channel is
selected and the durations of each allocation.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - - - 3GPP


Rel-5

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term ON/OFF
licence

1.2.2 HSDPA 15 Codes

Feature ID: RAN852

Summary: HSDPA 15 Codes allows higher peak rates as well as larger capacity. The
average cell throughput is increased by about 50% in a macro cell environment
compared to having 5 codes. The peak bit rate for single user is 7.2 Mbps. Peak cell
level total throughput is 10.8 Mbps (with code multiplexing). If features RAN1249 and
RAN1305 are activated then the figures are 10 Mbps per User and 14.4 Mbps per Cell.

Benefits for the operator: Higher data rates improve the end user experience.
HSDPA 15 codes provides more cell capacity compared to HSDPA 10 codes solution.
New data service availability results increased revenue. Increased cell capacity means
savings in CAPEX and OPEX.

Functional description: HSDPA 15 Codes feature is a further evolution for the


features Basic HSDPA with QPSK and 5 Codes and HSDPA 16 QAM Support allowing
higher peak data rates and increased average cell throughput. The peak bit rate for
single user is 7.2 Mbps. Peak cell level total throughput is 10.8 Mbps (with code
multiplexing). If features RAN1249 and RAN1305 are activated then the figures are 10
Mbps per User and 14.4 Mbps per Cell.
Depending on the UE category, the RLC payload size of 640 bits may be used when
the HSDPA 15 Codes is enabled.

DN0671022 Nokia Siemens Networks 13 (124)


Version 1.4.0
HSDPA 15 Codes allows higher peak rates as well as larger capacity. The average
HSDPA cell throughput depends on the maximum number of allocated HS-PDSCH
codes. When allocating the maximum of 10 HS-PDSCH codes, the average cell
throughput is increased by about 30% in a macro cell environment compared to having
only 5 HS-PDSCH codes.
Allocating the maximum of 15 HS-PDSCH codes increases the average cell
throughput by about 50% compared to the same 5 code reference scenario. In a
frequency layer dedicated for HSDPA, the gains are significantly higher, as well as in
micro cells.

Current implementation: HSDPA with 5 codes and 16QAM modulation allows 3.6
Mbps air interface peak rate.

Operational aspects: The maximum and sustained user data rates may be lower than
the air interface peak bit rate depending on the number of simultaneous HSDPA users,
RNC, BTS processing capacity and Iub dimensioning. Whole UltraSite WSPC card(64
CE)/Flexi BTS sub-module(80CE) is required to enable HSDPA with 15 codes to the
cell. With code shared HSDPA scheduler, up to three cells in the BTS can be handled
by one UltraSite WSPC/Flexi BTS sub-module. HSDPA 15 codes requires also the
HSDPA Dynamic Resource Allocation feature to operate and for dynamic adjustment
of the cell resources.
HSDPA 15 codes feature enables the HSDPA code multiplexing by allocating more
than 5 HS-PDSCH codes to the cell. It is recommended to use the HSDPA Code
Multiplexing together with this feature as part of the terminals will be 5 HS-PDSCH
codes capable. With 15 codes supported by the NW and 5 codes by the terminal, the
maximum number of simultaneous users that is beneficial from spectral efficiency point
of view is 15/5=3.
The operator can follow up through new counters the number of original and re-
transmissions (separate counters) with 6-15 codes per used modulation (QPSK,
16QAM). There are already the corresponding counters for 1-5 codes.
HSDPA 15 codes requires whole UltraSite WSPC card/Flexi BTS sub-module of
processing capacity to be reserved for 1-3 cells, depending on the required throughput
and number of users. Shared HSDPA scheduler for BB efficiency feature (WSPC or
Flexi BTS sub-module per 2-3 cells) can provide upto 48 users per scheduler, and 10.8
Mbps throughput per scheduler. Cell dedicated scheduler (WSPC or Flexi BTS sub-
module per cell), can provide upto 48 users per cell and 14.4 Mbps throughput per cell.
HSDPA 48 users per cell is a separate feature, without it 16 users per cell is
supported.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - SGN3 - 3GPP


Rel-5

14 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term capacity
licence

1.2.3 HSDPA Code Multiplexing

Feature ID: RAN853

Summary: HSDPA code multiplexing enables simultaneous transmission of (max)


three HSDPA users within a single cell during a single Transmission Time Interval
(TTI).
Code multiplexing improves the code resource utilization and subsequently, improves
the cell throughtput 30-50% and beyond.

Benefits for the operator: Improved end user experience is acquired thanks to better
cell throughput in the case of simultaneous users supporting maximum 5 codes.
CAPEX and OPEX savings result from increased cell capacity.

Functional description: This feature allows sending data packets to more than one
HSDPA user simultaneously in each 2ms TTI. Code multiplexing can be used when at
least two high-speed secondary control channel (HS-SCCH) codes are allocated by
the RNC. With this feature 2-3 users can be code multiplexed on HS-PDSCH
depending on HS-PDSCH and HS-SCCH allocation. The available code and power
resources are evenly shared between the scheduled users.
Decision on how many users are scheduled per cell is done independently on each
TTI. The general rule is that when the UE category with the highest scheduling metric
from proportional fair scheduling algorithm is supporting less codes than the cell has
available, then potentially (in case the first user cannot use all the available power) a
second UE is scheduled as well. The second UE to be scheduled is the one with the
second highest scheduling metric. If the two scheduled UEs are both supporting max 5
codes each, then a third user is potentially scheduled as well.
Note that code multiplexing does not provide any throughput gains in a case where the
UEs support as many codes as the NW. In such a scenario, the optimal strategy from
spectral efficiency point of view is to schedule a single user at a time. This decreases
the power spent for control channels (only one HS-SCCH needed instead of several)
and increases the gain from proportional scheduling.

DN0671022 Nokia Siemens Networks 15 (124)


Version 1.4.0
With code multiplexing it is possible to use code space larger than five codes also with
UEs that support only five codes. The NW capacity gain from code multiplexing is
similar to gain from 15 codes in the case where most of the users are supporting
maximum 5 codes.

Current implementation: Without code multiplexing a single user is scheduled in a


cell per TTI.

Operational aspects: HSDPA code multiplexing is possible only when more HS-
PDSCH codes are allocated in the BTS than the UEs in the NW can support
(otherwise cell level code multiplexing does not bring any capacity gain). Thus the
prerequisites for this feature are the activation of the feature HSDPA 10 Codes or
HSDPA 15 Codes and a code allocation of more than one HS-SCCH and more than 5
HS-PDSCHs per cell in the BTS. As more than 5 HS-PDSCH codes are required,
HSDPA Dynamic Resource Allocation feature is required as well for dynamic
adjustment of the cell resources.
The operator can see through new counters the number of multiplexed users for each
TTI in each cell.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - - - 3GPP


Rel-5

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term ON/OFF
licence

16 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
1.2.4 HSDPA 48 Users per Cell

Feature ID: RAN1033

Summary: Maximum number of simultaneous HSDPA users in a cell is increased to


48.

Benefits for the operator: CAPEX and OPEX savings are achieved by increased
simultaneous HSDPA end users in a cell. Instant access to data services after
momentary inactivity periods improves the end user experience.

Functional description: This feature allows 48 simultaneous HSDPA users per cell.
This consumes the whole UltraSite WSPC card/Flexi BTS sub-module per cell.
A higher number of users allows higher user volumes to be served. The end user
experience is improved in any ON/OFF type of service, that is, a service with
momentary inactivity periods, since higher number of users can be kept on cell_DCH
state for longer periods. Such services are, for example, web or WAP browsing and
gaming.

Current implementation: Currently, the maximum number of simultaneous HSDPA


users per cell is 16. This is achieved by dedicating 32 Channel Elements (CE) from
one UltraSite WSPC card/Flexi BTS sub-module for each HSDPA capable cell.

Operational aspects: HSDPA 48 Users per Cell feature requires a whole WSPC card
(64 CE)/Flexi BTS sub-module (80 CE) of processing capacity to be reserved for the
cell. For example, in case a WSPC/Flexi BTS sub-module is handling three cells with
Shared HSDPA Scheduler for Baseband Efficiency, the 48 users is the total maximum
over all the three cells. All 48 users can be in a single cell in case the other two cells
do not have HSDPA users.

The Iub and BTS baseband dimensioning is rational only if the 16 kbit/s Return
Channel DCH Data Rate Support for HSDPA is deployed together with this feature.
Otherwise, the UL DCHs require too high capacity. It is also recommended to enable
HSDPA Dynamic Resource Allocation and HSDPA 10 codes or HSDPA 15 codes
features together with this feature as a whole WSPC card/Flexi BTS sub-module is
required for HSDPA 48 Users per Cell feature, so more than 5 HS-PDSCH codes is
beneficial to be used as well.

The operator can follow up through new counters the duration of situations when there
are more than 16 simulaneous HSDPA users in a cell. The accuracy of the counters
are in steps of 4 (17-20, 21-24, ... , 45-48). There are already counters for situations
when there are less than 16 HSDPA users in a cell (in steps of two).

DN0671022 Nokia Siemens Networks 17 (124)


Version 1.4.0
Hardware requirements: WSPC card per HSDPA scheduler is required in UltraSite
BTS. Pico BTS supports 32 users per cell.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - - - 3GPP


Rel-5

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term ON/OFF
licence

1.2.5 Shared HSDPA Scheduler for Baseband Efficiency

Feature ID: RAN1034

Summary: This feature enables simultaneous HSDPA transmission to (max) three


HSDPA-capable cells by using a single UltraSite WSPC card or one sub-module in
FlexiBTS.
Shared HSDPA Scheduler supports 48 HSDPA users per BTS. 10.8 Mbps maximum
HSDPA throughput per BTS is provided. 15 codes per cell and 45 codes per BTS are
supported. The peak bit rate for single user is 7.2 Mbps. If feature RAN1249 is
activated then the figure is 10 Mbps per User.

Benefits for the operator: Statistical multiplexing gain and superior baseband
efficiency result CAPEX and OPEX savings. HSDPA throughput and users from up to
three cells can be multiplexed in single Shared HSDPA Scheduler requiring only one
ultraSite WSPC card/Flexi BTS sub-module. Superior performance is gained with a
minimum number of CEs.
Increased HSDPA capacity means increased revenue and better end user experience.
HSDPA capacity is increased both in terms of number of users supported and cell
throughput. The increased capacity improves end-user performance with higher
average bitrates.

18 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Functional description: The Shared HSDPA Scheduler for Baseband Efficiency
allows a single UltraSite WSPC card (Flexi BTS sub-module to handle the processing
of HSDPA for 1, 2 or 3 cells simultaneously. 48 simultaneous HSDPA users are
supported by the card. These users can be divided in any combination among the cells
handled by the card.
It is possible to use all 15 HSDPA codes in all three cells simultaneously with the
Shared HSDPA Scheduler for Baseband Efficiency scheduler. However, on each TTI
the total bit rate over all cells has to be below 10.8 Mbps. Therefore, even though there
is no code limitation, the throughput is limited to 10.8 Mbps per UltraSite WSPC
card/Flexi BTS sub-module. On those TTIs where the total bit rate for all scheduled
UEs would exceed 10.8 Mbps, the NodeB will clip data from the highest bit rate user
so that the maximum limit of 10.8 Mbps is not exceeded.
Note that 15 codes simultaneously in each cell is beneficial even with the total bit rate
limitation, since in optimal link adaptation the number of codes is increased prior to
increasing coding rate or modulation. For example, the 15th code should be taken into
use already at 2.4 Mbps when codes are available, since spectrally this is more
efficient than using less codes but having higher order modulation or less robust error
protection coding.
Therefore, all 45 codes of three cells can be taken to full use when the total throughput
in the BTS is 3*2.4 Mbps = 7.2 Mbps. As a result, the ability to use all 15 codes in each
cell simultaneously increases the practical average cell throughputs significantly, even
though the theoretical peak throughputs are not affected.
The benefit of the Shared HSDPA Scheduler for Baseband Efficiency is more efficient
utilization of baseband capacity. For 1+1+1 configuration, one UltraSite WSPC
card/Flexi BTS sub-module with Shared HSDPA Scheduler for Baseband Efficiency
offers almost the same performance as three UltraSite WSPCs/Flexi BTS sub-
modules. The loss in performance is due to fact that the total combined bit rate on
each TTI has to be below 10.8 Mbps. However, as the air interface limits the average
cell throughput to around 2 Mbps in macro environment, there is no real difference in
cell level throughput.
Note that code shared scheduler is offering clearly better performance on the air
interface than using 32 CE reservation per cell (RAS05.1 configuration). This is
because with code shared scheduler each cell is capable of achieving the peak bit rate
of 10.8 Mbps when other cells are not loaded. Also as code shared scheduler has no
limitation on the number of codes (as opposed to max five codes per cell with RAS05.1
configuration), the link adaptation algorithm is able to use spectrally more efficient
method of increasing number of codes beyond five before going to more robust coding
rate and higher order modulation. This means that on given SINR conditions, 1+1+1
NodeB with code shared scheduler offers significantly better throughput than static
allocation of 5 codes per sector.

Current implementation: Currently there are two options for baseband allocation of
HSDPA users in the BTS:
- Option one (minimum baseband allocation): Single UltraSite WSPC card/Flexi BTS
sub-module serves three HSDPA capable cells and the HS-DSCH transmission is time

DN0671022 Nokia Siemens Networks 19 (124)


Version 1.4.0
multiplexed between the cells (only one HSDPA cell can be transmitted to at each
TTI). The maximum air interface peak rate is 3.6 Mbps and maximum 16 simultaneous
HSDPA users per BTS can be served. 32 CE from UltraSite WSPC card/Flexi BTS
sub-module is consumed for HSDPA.
- Option two (dedicated baseband allocation): Single UltraSite WSPC card/Flexi BTS
sub-module is dedicated for each HSDPA cell (all HSDPA cells can transmit
simultaneously). 32 CE from each UltraSite WSPC card/Flexi BTS sub-module is
consumed for HSDPA, and the remaining 32 CE are used for DCH traffic (or common
channels). The maximum air interface peak rate is 3.6 Mbps per cell and 16
simultaneous HSDPA users per cell can be served.

Operational aspects: Shared HSDPA Scheduler for Baseband Efficiency for BTS
feature requires a whole WCPC card (sub-module in case of FlexiBTS) of processing
capacity to be enabled for two to three cells in the BTS. In normal case, the best option
is to allow single WSPC/Flexi BTS sub-module to handle three cells. A second WSPC
can be added so that cell A is handled by first WSPC and cells B and C by the second
WSPC. This will increase the total maximum number of simultaneous HSDPA users to
96 and the total maximum bit rate to 21.6 Mbps. Note that in the vast majority of cases
only one WSPC is sufficient for HSDPA, and only on the busiest sites a second WSPC
could be added.
To utilize the whole WSPC capacity, the following RAS level features are
recommended to be used together with Shared HSDPA Scheduler for Baseband
Efficiency for BTS:
- HSDPA Code multiplexing: If there are users in all three sectors of the BTS, Shared
HSDPA Scheduler for Baseband Efficiency for BTS will schedule one user per cell in
the BTS on each TTI. This will use the available power in the most efficient manner. In
case some sector(s) do not have UEs for which there would be data in the BTS buffer,
code multiplexing will take care that all three users will be simultaneously scheduled in
the BTS. This will occur only if it is beneficial from the spectral efficiency point of view.
In practice, this means that if in some sector the primarily scheduled user is not able to
use all the available power and codes. Thus it is beneficial to schedule a second (or
even third) user in that particular sector.
- HSDPA 48 Users per Cell: This feature allows 48 simultaneous HSDPA users per
cell. However, in case the WSPC card is handling several cells, the total number of
users in those cells can be at maximum 48.
- The Iub and BTS baseband dimensioning is advisable only if the 16 kbit/s Return
Channel DCH Data Rate Support for HSDPA is deployed together with this feature.
Otherwise the UL DCHs require too high capacity.
- HSDPA 15 (or 10) codes: The HSDPA 15 codes feature allows 15 HS-PDSCH codes
to be used from single cell, corresponding to maximum 45 HS-PDSCH codes per
WSPC with BTS level code multiplexing feature.
- HSDPA Dynamic Resource Allocation feature to operate for dynamic adjustment of
the cell resources.

20 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
The operator can follow up through new counters the consumption of HSUPA related
Channel Elements per LCG. There are already counters for total CE consumption for
all services per LCG.
The congestion related to CE shortage - when RNC requests a RL setup or RL
reconfiguration - can be followed up via existing counters.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 RN3.0 WBTS4.0 WBTS4.0 - - - - - - 3GPP
Rel-5

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA BTS LK Long-term ON/OFF
licence

1.2.6 HSDPA Dynamic Resource Allocation

Feature ID: RAN312

Summary: Dynamic HSDPA channelisation codes allocation enables full cell resource
utilization, better end-user experience and increased NW capacity.

Benefits for the operator: Gain in cell throughput is achieved as the cell resources
are better utilized for varying traffic mix. Operator control on resource division between
NRT DCH and HSDPA allows flexible support of different pricing strategies for DCH
and HSDPA data.

Functional description: NodeB will dynamically control the amount of power used for
HSDPA, the HSDPA power can be controlled each TTI, i.e. in 2 ms interval. All the
power left after DCH traffic, HSUPA control channels and common channels is used
for HSDPA. This means that as long as there is HSDPA traffic in the cell, all the
available PA power can be efficiently utilized.
RNC will still schedule the NRT DCH bit rates. The higher bit rates the RNC allocates
for NRT DCHs, the less there is "spare" power that the NodeB can use for HSDPA. To

DN0671022 Nokia Siemens Networks 21 (124)


Version 1.4.0
avoid situations where very unfair distribution of power is created between HSDPA and
NRT DCH users, the RNC will take into account both the current number of NRT DCH
and HSDPA users in the cell when allocating NRT DCH bit rates. By default, the RNC
will treat NRT DCH and HSDPA users equal in the sense that NRT DCH bit rates are
allocated in such way that roughly equal amount of tx power per user will be available
to both NRT DCH users and HSDPA users. This does not mean that each user would
have equal bit rates. It simply means that if in a 20 W cell there happens to be 8 W of
RT & common channel load, then about 12 W is available for NRT traffic. This 12 W is
then divided so that in case of 2 NRT DCH users and 10 HSDPA users, about 2 W
would be given to DCH side and 10 W to HSDPA side. The RNC does not directly
guide the NodeB in allocating the power for HSDPA, but the RNC does affect this
implicitly by decision of NRT DCH bit rates.
On an operator choice, the priority between NRT DCH and HSDPA can be weighted
so that power is aimed to be spent in relation p1: p2, where p1 represents the target tx
power per user available for NRT DCH and p2 the target tx power per user available
for HSDPA. In addition, users with higher Traffic Handling Priority (THP) can be
counted more important when deciding the division between power for NRT DCH side
and HSDPA side. THP is not taken into account in actual HSDPA scheduling, but all
HSDPA users are given roughly equal resources according to proportional fair
scheduling principle.
The code allocation is dynamically following the power allocation. In practice this
means that once the NRT DCH bit rates have been decided, based on equal power
criterion, the code requirements for the DCH side have been fixed. All other codes are
then given to the HSDPA (operator may leave some margin to allow fast voice call
allocation). In case of new DCH connections (for which the bit rate is again determined
based on power criteria), the required amount of HSDPA codes are given back to the
DCH.

Current implementation: The RNC allocates fixed codes. In RAS05.1, the power is
allocated dynamically by the BTS by the feature HSDPA Dynamic Power Allocation.
The minimum adjustment period of HSDPA power is 100 ms in RAS05.1 and 2 ms in
RAS06.

Operational aspects: The BTS SW version required for this feature must be updated
to the NW before activation of the feature in the RNC.
The operator can control whether to favour the NRT DCH or HS-DSCH via the RNC
management parameters. This is possible for both codes and power. For power the
PtxTargetPS threshold is set dynamically by observing the non-HSDPA power and
PtxTotal. The PtxTargetPS is a new target for the NRT DCHs that is adjusted by the
RNC, so that power per user on DCH side and on HSDPA side is roughly equal unless
unequal priorities have been set. The operator can also set PtxTargetPSmin that
guarantees the minimum NRT DCH power over HSDPA.
The RT DCHs always follow the existing PtxTarget threshold.

22 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
The operator can follow up through:
1) New counters when the UE accesses the HS-DSCH related to state transition from
CELL-FACH
2) The allocation durations of different HSDPA Codes (0, 5, 6-15) in each cell
(counters for codes 6-15 only updated if supporting features are taken into use),
3) The times when a HS-DSCH setup happens directly from DCH,
4) The number of requested SF in each cell and
5) The average and maximum PtxTargetPS used.
There are already existing counters for the HSDPA power levels in each WCELL
(specific to UltraSite and FlexiBTS).

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term ON/OFF
licence

DN0671022 Nokia Siemens Networks 23 (124)


Version 1.4.0
1.3 HSUPA

1.3.1 Basic HSUPA

Feature ID: RAN826

Summary: This feature provides the High Speed Uplink Packet Access (HSUPA)
functionality, also known as Enhanced Uplink DCH (E-DCH). HSUPA functionality is
based on the following techniques:
- BTS controlled scheduling of the E-DCH within the limits set by the RNC
- Physical layer retransmission handling in the BTS

Benefits for the operator: Increased UL average and peak data rates improve the
end user experience. CAPEX and OPEX savings result from increased cell UL
capacity and increased Iub and BTS HW efficiency. New data service availability
increases revenue.

Functional description: The basic characteristics of the feature are listed below:
- HSUPA is supported only with co-existence of HSDPA.
- All cells in the BTS can be enabled for HSUPA.
- Maximum number of HSUPA users per BTS is 24 (in larger than 6 cell configurations
two local cell groups have to be used, and then HSUPA is handled independently on
both local cell groups). The maximum number of HSUPA users in a cell is 20, limited
by available signatures in E-RGCH/E-HICH channels. One E-AGCH and one E-
RGCH/E-HICH code channels are configured to each serving E-DCH cell. Maximum
number of simultaneous HSUPA serving users is 19 in a cell, and one signature is
reserved for non-serving HSUPA users.
- Operator can choose to set a lower threshold to the maximum number of users per
cell and per BTS.
- TTI of 10 ms is used for maximizing the resulting UL range.
- The largest supported E-DCH category is 3 (1.44 Mbps), corresponding to two
parallel codes of spreading factor four (2xSF4).
- HSUPA activation requires a static reservation of UltraSite WSPC card/Flexi BTS
sub-module) capacity. Rest of the HSUPA baseband capacity is fully pooled across
cells, and also dynamically shared with R'99 traffic. Up to two UltraSite WSPC
cards/Flexi BTS sub-modules can be in HSUPA use, R'99 traffic allowing.

24 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
For UltraSite BTS it is possible to enable HSDPA and HSUPA in three sectors on a
single shared WSPC card, using RAS05 HSDPA 16 users per BTS scheduler. This
allows operators to roll out fast and cost efficient HSUPA service.
In case of high capacity UltraSite BTS HSPA sites, operator can select as alternative
HSUPA activation on separated WSPC cards. WSPC (64 CE) per BTS or WSPC per
cell for HSDPA can be used to increase HSDPA capacity.
These together provide high capacity HSPA solution.
- The maximum peak data rate per user is 1.44 Mbps as coded L1 bit rate (error
protection coding is not counted into bit rate but L1 retransmissions are). If feature
RAN979 is activated then peak data rate per user is 2.0 Mbps.
- One UltraSite WSPC card/Flexi BTS sub-module supports up to 24 HSUPA users
- The minimum combined L1 baseband throughput of all users per UltraSite WSPC
card/Flexi BTS sub-module is 4.2 Mbps.
- HSUPA channel coding functionality includes E-DCH Absolute Grant Channel (E-
AGCH), E-DCH Relative Grant Channel (E-RGCH) and E-DCH Hybrid Automatic
Repeat Request (ARQ) Indicator Channel (E-HICH) encoding in DL and E-DCH
Dedicated Physical Data Channel (E-DPDCH) and E-DCH Dedicated Physical Control
Channel (E-DPCCH) decoding in UL.
- HSUPA Hybrid Automatic Repeat Request (H-ARQ) operation handling per UE in E-
DCH Medium Access Control (MAC-e) entity within a BTS.
- HSUPA Service Indicator is supported.
The total cell data rate for HSUPA users is scheduled between the HSUPA capable
UEs in a cell. Scheduling is performed by the NodeB in a fast cycle by using mainly
relative grants. All UEs get as much bit rate as they can send in non-congested case.
In case of congestion, roughly equal noise rise contribution is allowed for each user.
For facilitating smooth mobility operations with non-HSUPA capable BTSs, Signaling
Radio Bearer (SRB) is mapped on DCH.
HSUPA traffic is mapped on a dedicated Iub virtual channel connection (VCC),
allowing Iub capacity consumption be optimized for NRT HSUPA traffic, while
preserving the QoS of real-time services, which are mapped on another VCC. The
operator may also configure a minimum service level for HSUPA by dedicating a
minimum amount of baseband channel elements (CEs) for HSUPA.
HSUPA improves the UL packet data performance by providing higher data rates over
the whole cell area, increasing the peak data rate and reducing delay. HSUPA also
increases the system capacity by improving the cell throughput and the efficiency of
the transport and BTS hardware resources. HSUPA benefits are especially significant
for bursty high bit rate applications.
In a non-congested, single user case the maximum bit rates are greatly improved,
since instead of practical maximum of 384 kbps with R'99, 1.4 Mbps can be reached
with HSUPA. In a loaded NW with congestion, the capacity gain from HSUPA is
expected to be on the order of 20%-50%.

DN0671022 Nokia Siemens Networks 25 (124)


Version 1.4.0
HSUPA Service Indicator indicates the HSUPA capability to the UEs. HSUPA capable
cell means that the UE may consider this cell/any cell in the same sector as part of the
HSUPA coverage area to display HSUPA service indication.

Current implementation: Prior to HSUPA, the maximum practical peak bit rate is 384
kbps, UL packet scheduling is handled by the RNC and retransmissions are handled
by the RLC (as opposed to L1 HARQ retransmissions in HSUPA).

Operational aspects: HSUPA will dynamically share the baseband capacity with DCH
traffic. The operator may commission a minimum fixed reservation for HSUPA, but the
rest of the capacity is dynamically allocated to HSUPA when DCH does not need it. As
default, 8CE reservation is done when the first HSUPA cell is configured to the local
cell group. The operator can follow the capacity need from the counter indicating the
number of HSUPA capable UEs in the cell.
The operator can through new counters:
1) See the number of HSUPA capable UEs per cell,
2) See the average and maximum number of used CEs for HSUPA,
3) See the power levels of the HSUPA DL Physical Channel,
4) See the power levels of the HSUPA E-DCH Channels,
5) See the number of HSUPA users per cell.
HSDPA Dynamic Resource Allocation feature is required for HSUPA.
Iub re-configuration is required for HSUPA.

Hardware requirements: Pico BTS supports 6 users per cell.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - SGN3 - 3GPP


Rel-6

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term capacity
licence

26 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
1.3.2 HSUPA Basic RRM

Feature ID: RAN973

Summary: This feature provides the essential Radio Resource Management (RRM)
functionality for HSUPA operation.

Functional description: HSUPA RRM in the RNC algorithm reserves the required
codes and power for the E-AGCH, E-RGCH and E-HICH physical channels in DL. In
UL, a certain noise rise is reserved for the BTS packet scheduler. This allows admitting
the DCH users according to the normal admission control procedure in the RNC while
the remaining noise rise margin is efficiently utilised for the HSUPA.
HSUPA RRM algorithm in the RNC makes also the E-DCH allocation decisions. The
decision between DCH and E-DCH allocation for a UE is based on the service (RAB
parameters), resource availability, multi-RAB combination and UE capability. HSUPA
is supported only with co-existence of HSDPA per UE.
HSUPA RRM algorithm in the RNC configures also the RLC layer, radio bearer,
transport channel and physical channel configuration for an E-DCH user based on
RAB parameters. This feature introduces operator controllable RLC parameters for RB
mapped on DCH, E-DCH or HS-DSCH. E-DCH is released based on low throughput
detection in both UL and DL.
Furthermore, HSUPA RRM algorithm in the RNC performs combined power and
throughput based (hybrid) admission decision and packet scheduling for R99 DCH
and/or E-DCH users in the cell. HSUPA RRM algorithm in the RNC performs HSUPA
outer loop power control.

Operational aspects: Power allocation for HSUPA users can be controlled via
operator configurable parameters.
The operator can follow up through the counters the allocation requests and success
vs. failures of the E-DCH channel.
The operator can follow up through the counters the throughput of the E-DCH channel
in both RNC and BTS.
There will also be counters for following the minimum/average/maximumpower levels
for:
- HS-PDSCH HS-SCCH E-AGCH E-RGCH or E-HICH transmission
- E-AGCH E-RGCH and E-HICH transmission

DN0671022 Nokia Siemens Networks 27 (124)


Version 1.4.0
Along with this feature there will be also be provided counters for measuring packet
calls. A packet call means a NRT transport channel setup in any of the possible
transport channels (DCH, HS-DSCH or E-DCH). There will packet call related counters
for e.g:
- Packet call request in UL and DL and packet set up failures,
- Packet call requests, allocations and releases separated per DCH/DCH, DCH/HS-
DSCH or E-DCH/HS-DSCH,
- Packet call channel switches for e.g:
-- DCH/HS-DSCH<->DCH/DCH (not 0/0),
-- E-DCH/HS-DSCH<->DCH/DCH (not 0/0)

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - - - 3GPP


Rel-6

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW HSPA - -

1.3.3 HSUPA BTS Packet Scheduler

Feature ID: RAN968

Summary: HSUPA BTS Packet Scheduler is a fast BTS based scheduler determining
the bit rates to be used on E-DCH.
Moving packet scheduling from the RNC to BTS is the key change in HSUPA
compared to Rel'5. The BTS is able to make much faster decisions when the RNC
does not have to be consulted. This increases the efficiency at which especially bursty
data can be treated by the packet scheduler.

Benefits for the operator: Increased UL data throughput improves the end user
experience. In addition, increased cell UL capacity results CAPEX and OPEX savings.

28 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Functional description: HSUPA BTS Packet Scheduler (PS) is a cell specific
scheduler using 10 ms scheduling periods with both Absolute Grants (AG) and
Relative Grants (RG). The scheduling decisions are based on the maximum allowed
noise rise, minimum throughput and the physical layer feedback from the UEs in a cell.
The HSUPA BTS PS also takes into account the available baseband resources not
needed for R'99 DCHs.
In a case where air interface and NW resources are not limiting the data rates, each
UE is given as much bit rate as they request, up to maximum of 1.44 Mbps, and if
feature RAN979 is activated then upto 2.0 Mbps. The scheduling grant determined by
the PS is applicable to all HARQ processes of the UE (Refer to HSUPA Congestion
Control).

Current implementation: Without HSUPA the RNC will determine UL bit rates. This
happens on relatively slow cycle compared to the BTS-based HSUPA scheduling.

Operational aspects: The operator can follow up through new counters the total and
re-transmitted amount of MAC-e data in the BTS.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - - - - - 3GPP


Rel-6

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW HSPA - -

1.3.4 HSUPA Handovers

Feature ID: RAN970

Summary: This feature brings soft/softer handovers and serving cell changes for
HSUPA users allowing HSUPA in the whole cell coverage area and between the cells.

DN0671022 Nokia Siemens Networks 29 (124)


Version 1.4.0
Benefits for the operator: This feature enables full mobility for the HSUPA users and
widens the coverage area of a given bit rate. The gain is significant especially with high
bit rates. Soft handover (SHO) gain for E-DCH is similar in magnitude to traditional
R'99 DCH SHO.

Functional description: The following intra-frequency soft/softer handovers are


supported for E-DCH:
- Intra BTS intra RNC softer handover,
- Inter BTS intra RNC soft handover.
In case of SHO, the active set for DCH can be different from the active set for E-DCH.
This allows adding a cell not supporting E-DCH into the active set. In addition, in case
of inter-BTS inter-RNC soft handover, the E-DCH will not be configured to a SHO
branch under the drift RNC. The serving E-DCH cell follows the serving cell for HS-
DSCH of the UE. Thus the algorithms of HSDPA are followed. The HS-DSCH and E-
DCH serving cell is always the same cell.
DCH to E-DCH channel switching is carried out if there is a need to change the serving
DCH cell into a cell supporting E-DCH. E-DCH to DCH channel switching is carried out
if there is a need to change the serving E-DCH cell into a cell not supporting E-DCH or
a cell under the drift RNC. E-DCH to DCH channel switching is also needed before
compressed mode is activated for inter-frequency or inter-system measurements.
E-DCH to DCH channel switching is carried out if there is a need to change the serving
E-DCH cell into a cell not supporting E-DCH or a cell under the drift RNC. E-DCH to
DCH channel switching is also needed before compressed mode is activated for inter-
frequency or inter-system measurements.

Operational aspects: The benefits from E-DCH SHO are best achieved when all the
cells in a particular area are HSUPA enabled. Having only DCH-capable cells among
E-DCH cells does not allow optimal UL power control to be applied. DCH only cells can
be added to DCH active set of the E-DCH call, but they are not able to affect to the
used E-DCH power.
Through new counters the operator can monitor the HSUPA Serving Cell changes and
SHO related to the HSUPA Active Set.

Hardware requirements: Pico BTS supports 12.7 Mbps

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - - - 3GPP


Rel-6

30 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW HSPA - -

1.3.5 HSUPA Congestion Control

Feature ID: RAN992

Summary: With HSUPA Congestion Control, the RNC detects congestion on the Iub
and notifies the BTS about the congestion. HSUPA packet scheduler in the BTS takes
actions on the air interface to reduce the congestion.
By preventing congestion on the Iub, the feature prevents radical loss of throughput
when the RLC retransmissions start to accumulate due to Iub congestion. This allows
tighter Iub dimensioning to be used. Additionally, mobiles do not generate extra
interference by sending data that cannot be forwarded to the RNC by the BTS.

Benefits for the operator: CAPEX and OPEX savings are achieved by increased Iub
efficiency and cell UL capacity. Congestion control is the enabler for efficient Iub with
HSUPA. Also UL capacity is improved by avoiding loss of packets, which are already
sent over air interface.
The end user experience is improved by increased UL data throughput. Without the
congestion control, throughput would be impacted by packet loss.

Functional description: 3GPP R6 includes mechanisms for Iub HSUPA data


congestion detection and control as follows:
1) Build-up delay, detected using the reference time; and
2) Frame loss, detected using the Frame sequence number.
The BTS attaches a Connection Frame Number (CFN) to the each Frame Protocol E-
DCH data frame. By the CFN field the RNC is able to detect if there is delay variation
in the Iub interface. The BTS also attaches the Frame Sequence Number to each
Frame Protocol E-DCH data frame. By the Sequence Number field the RNC is able to
notice frame losses, which is an indication that packets have been lost in the Iub
interface due to congestion.
Congestion detection is done in the RNC. Congestion detection algorithm for Iub
congestion is based on the Multilevel ECN (Explicit Congestion Notification) method.
MECN algorithm introduces three delay thresholds instead of two thresholds, which
are used in the ECN algorithm. MECN algorithm uses three different thresholds when

DN0671022 Nokia Siemens Networks 31 (124)


Version 1.4.0
congestion severity is evaluated: minimum delay (Min_th), middle delay (Mid_th) and
maximum delay (Max th).
When there is increase in delay, the probability of rate reduction for all connections
increases at the same time. The algorithm selects independently for each flow whether
the data rate is decreased and sends congestion indication towards the BTS. In case
of detected E-DCH FP frame loss, the RNC will send a corresponding congestion
indication to the BTS. The restricting timer controls the maximum rate of indications.
The congestion detection algorithm follows a two threshold probability curve similar to
ECN. The probability of sending Congestion Indication begins to increase when the
processing load exceeds the lower threshold and saturates to a level given as a
parameter when the load reaches the upper threshold.
Congestion handling is implemented at the BTS. HSUPA Packet scheduler in BTS
reduces gradually the bit rate of the E-DCH MAC-d flow when congestion indication is
received, and resumes to normal operation when "No TSN congestion" indication is
received from the RNC or the BTS has not received additional congestion indications
during a period defined by a timer.

Figure:

Current implementation: Without the congestion control the HSUPA packet


scheduler in BTS does not react to Iub congestion.

Operational aspects: The Operator can through new counters see the
1) The number of congestion indications sent to BTS due to Iub delay buildup,
2) The number of congestion indications sent to BTS due to exceeded FP loss rate,
3) The number of congestion indications due to RNC_LED (load early detection), that
is RNC internal load control.
Together with the already available MAC-d flow setup counters the HSUPA
Congestion rate for Iub can be seen.

32 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 RN3.0 WBTS4.0 WBTS4.0 x - OSS4.2 - - - 3GPP
Rel-6

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW HSPA - -

1.3.6 HSUPA with Simultaneous AMR Voice Call

Feature ID: RAN974

Summary: This feature provides both HSUPA services and AMR voice calls
simultaneously.

Benefits for the operator: Simultaneous high speed data services and AMR voice
calls in UL improve the end user experience.

Functional description: PS data connection over E-DCH is supported simultaneously


with AMR voice call over DCH, this ensures that an AMR voice call initiation does not
influence the NRT service data flow.

Operational aspects: The AMR codec mode is selected according to feature AMR
Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75).
The operator can monitor the simultaneous AMR + E-DCH allocations and releases
through new counters.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - - - 3GPP


Rel-6

DN0671022 Nokia Siemens Networks 33 (124)


Version 1.4.0
SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term ON/OFF
licence

34 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
1.4 HSPA Mobility

1.4.1 HSPA Layering for UEs in Common Channels

Feature ID: RAN1011

Summary: UEs are directed to correct layer according to their HSDPA and high-speed
uplink packet access (HSUPA) capability in state transition from Cell_FACH to
Cell_DCH.

Benefits for the operator: CAPEX savings can be achieved as the HSPA capability
can be implemented using the HSPA layering. Choosing the correct layer for the UE
on each transition to cell_DCH guarantees correct layer based on the UE capability on
all practical mobility scenarios. When several layers support HSPA, the feature
chooses the layer in an optimal manner based on expected DL throughput on each
HSPA layer.

Functional description: This feature transfers UEs to correct layer based on their
HSDPA and HSUPA capability. The transfer occurs in connection with state transition
from Cell_FACH to Cell_DCH.
Non-HSDPA UEs are transferred to the non-HSDPA layer. The HSDPA capable UEs
are transferred to the layer that supports HSDPA. The HSUPA capable UEs are
transferred to layer that supports HSUPA. If there are several HSDPA or
HSDPA&HSUPA layers, load sharing is utilised. On HSPA layers, the selection
criterion is the highest DL throughput (most power per user available for HSDPA).
In addition, this feature covers some enhancements to the Directed RRC Connection
Setup for HSDPA Layer feature. The requested service in the radio resource control
(RRC) Connection Setup Request is taken into account in decision making so that only
HSDPA UEs requesting interactive and background services are transferred to the
HSDPA layer.
Also HSUPA capability is taken into account when selecting the layer. The interworking
with the directed RRC connection setup feature enables the non-HSDPA load sharing
between all the layers. The UE that cannot manage with frequency change in the RRC
connection setup phase or in the state transition phase is detected and the feature is
not used for that specific connection.

Current implementation: Without the feature the layer selection is only done at the
RRC connection setup.

DN0671022 Nokia Siemens Networks 35 (124)


Version 1.4.0
Operational aspects: The operator can switch the feature (and parts of it) on and off
on a cell basis with a management parameter.
Through new counters the operator can follow up:
1) The signaling DCH allocations for layer changes from non-HSDPA to HSDPA layer
and vice versa in the RRC setup phase and
2) When the UE is directed from non-HSDPA to HSDPA layer or vice versa in
Cell_FACH to Cell_DCH state transition.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - 3GPP
Rel-5

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term ON/OFF
licence

36 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
1.5 User Experience

1.5.1 HSDPA 10 Mbps per User

Feature ID: RAN1249

Summary: The peak bit rate on HSDPA for single user is increased to 10 Mbps.

Benefits for the operator: HSDPA 10 Mbps feature allows higher peak bit rates for
single user.

Functional description: HSDPA category 9 UE is capable of 10 Mbps peak air


interface bit rate with 15 codes. With this feature a category 9 UE may receive data
with its maximum bit rate when 15 codes for HSDPA are allocated in the cell.

Current implementation: Currently the peak bit rate for single user is 3.6 Mbps.

Interdependencies between features: HSDPA 15 Codes is needed for this feature.

Operational aspects: The maximum and sustained user data rate may be lower than
the peak bit rate depending on the number of simultaneous HSDPA users, radio
channel conditions and Iub dimensioning.
The current counters for RLC and MAC layer throughput can be used for HSDPA
throughput monitoring.
The counters are found inthe Radio Connection Performance RLC AM and Cell
Throughput Measurements.
The Traffica tool can be used to see the ATM layer throughput on Iub in real time.
The counters are found in Traffic load of ATM VC connections report.

Hardware requirements: CDSP-C interchangability D required in RNC (See


TN_RNC_HW_2007_055).

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - SG6.0 - 3GPP


Rel-5

DN0671022 Nokia Siemens Networks 37 (124)


Version 1.4.0
SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term ON/OFF
licence

1.5.2 HSDPA 14.4 Mbps per Cell

Feature ID: RAN1305

Summary: Cell maximum throughput is increased to 14.4 Mbps with cell dedicated
scheduler.

Benefits for the operator: CAPEX savings in BTS baseband thanks to increased
average cell throughput with dedicated scheduler.

Functional description: If HSDPA code multiplexing is used, the maximum theoretical


cell level throughput for simultaneously scheduled HSDPA users is 14.4 Mbps. With
the Rel-6 HSDPA UE categories the maximum theoretical cell level throughput as
defined by 3GPP is 13.9 Mbps with two cat 9 or cat10 terminals. Practical throughput
achievable with this feature is limited by radio reception:
Maximum theoretical throughput would require the use of coding rate close to 1, i.e. it
would require error free reception. Targeting to error free reception reduces the system
efficiency and capacity. In all practical conditions the throughput will be degraded if
using coding rates close to 1, i.e. having effectively no error correction.
Quality of radio reception depends on aspects such as transmitted signal strength,
radio channel and interference, transmitter and receiver imperfections.
Operational aspects: The HSDPA cell throughput can be monitored via existing BTS
counters.

Hardware requirements: Dedicated UltraSite WSPC/Flexi BTS sub-module per cell


for HSDPA is needed in the BTS.
Pico BTS supports maximum 12.8 Mbps

38 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW HSPA - -

1.5.3 HSUPA 2.0 Mbps

Feature ID: RAN979

Summary: The highest supported user peak rate on E-DCH is 2.0 Mbps,
corresponding to two parallel codes of spreading factor two (2xSF2) and 10 ms TTI.

Benefits for the operator: HSUPA peak rate is increased up to 2.0 Mbps per user.

Functional description: HSUPA category 5 UE is capable of 2.0 Mbps peak air


interface bit rate. HSUPA categories 4 and 6 have 2.0 Mbps peak bit rate in case of 10
ms TTI. 2.0 Mbps user peak rate on E-DCH is supported in RNC and BTS user plane
processing and in configuration (e.g. RLC) of L2 done by L3. BTS supports reception
of two SF/2 multicodes with 10 ms TTI.

Current implementation: The highest supported user peak rate on E-DCH is 1.44
Mbps, corresponding to two parallel codes of spreading factor four (2xSF4) and 10 ms
TTI.

Operational aspects: The operator can:


1. In BTS: through new E-DCH (MAC-e) throughput (counters to follow the HSUPA cell
throughput.
2. In RNC: through new RLC counters to follow the HSUPA user throughput.

Hardware requirements: Pico BTS supports maximum 1.44 Mbps

DN0671022 Nokia Siemens Networks 39 (124)


Version 1.4.0
Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - SGN3 - 3GPP


Rel-6

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW HSPA RNC LK Long-term capacity
licence

40 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
1.6 Capacity and Efficiency

1.6.1 Flexible Iu

Feature ID: RAN834

Summary: Flexible Iu feature provides a standardised mechanism for connecting


multiple MSCs and SGSNs to an RNC within a single operator NW. Flexible Iu is also
known as 'Iu Flex' and 3GPP uses the names 'Intra Domain Connection of RAN Nodes
to Multiple CN Nodes' and 'Multipoint Iu/Gb/A'.

Benefits for the operator: Flexible Iu provides CAPEX and OPEX savings resulting
from efficient CNs resource utilization and load balancing. Increased service
availability and better NW resilience improve the end user experience.

Functional description: This feature introduces the concept of Pool Areas. A UE may
roam freely within a Pool Area (in either connected or idle mode) without the need to
change the CN serving node. The figure below shows an example of the Pool Area
configurations in the NW.
Pool Area configurations are done in the CN nodes. Pool Areas themselves are not
visible to the RAN but the RNC configuration has to be done according to the CN Pool
Area configurations so that the RNC is able to route signalling messages to any CN
node within a Pool Area.
The NAS Node Selector function (NNSF) is a mechanism used for selecting the CN
node for the UE. The UE derives the value of the parameter NRI from the (P)-TMSI or
IMSI and sends the NRI to the RNC in the Initial Direct Transfer message. The RNC
selects the CN node corresponding the NRI value configured in its database.
The NNSF in the RNC contains also the CN node recovery functionality, which
balances the load between the CN nodes of a pool in different cases, for example, with
CN node failure, SW/HW update or adding or removing a CN node to/from the pool.

DN0671022 Nokia Siemens Networks 41 (124)


Version 1.4.0
Figure:

Current implementation: This is a new feature.

Interdependencies between features: Simultaneous usage of Flexible Iu and the


Multi-Operator RAN feature is not possible.

Operational aspects: The relevant PM Measurements already include the possibility


of multiple CN IDs in the measurement object.

Hardware requirements: This feature does not require any new or additional HW.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 M13.0 SG6.0 U2 -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

42 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
1.7 Location Services

1.7.1 Emergency Call Redirect to GSM

Feature ID: RAN1177

Summary: 3G emergency call is directed to 2G NW as the latter one is assumed to


provide better location service. If there is another call attempt within 60 seconds, the
call is established in 3G NW.

Benefits for the operator: CAPEX and OPEX savings can be achieved if the operator
can utilize the existing 2G positioning system for emergency calls.

Functional description: When UE is trying to make an emergency call to WCDMA


NW, the RNC instructs the UE to make an inter-RAT handover to GSM NW and to
carry on with the emergency call in GSM. If for any reason the handover should fail,
and the UE returns to the WCDMA NW with the emergency call within 60 seconds, the
call is set up and carried out in the WCDMA NW.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

DN0671022 Nokia Siemens Networks 43 (124)


Version 1.4.0
1.7.2 Latency Statistics for UE Positioning

Feature ID: RAN1219

Summary: Statistics of location system's latencies are collected for further analysis.

Benefits for the operator: Better end-user experience can be achieved as the
operator has possibilities to monitor and verify improved location system's
performance.

Functional description: Latency statistics for UE Positioning presents new statistical


latency information concerning the UE positioning. The latency statistics present
overall locationing service latencies, and detailed latency statistics for cell-based and
A-GPS positioning methods. In addition, the feature presents the latency statistics of
emergency call-related (inter-system handover) ISHO features.

Operational aspects: This feature is an extension to feature LCS - Cell Coverage


Based (RTT) with Geographical Coordinates.
New counters for:
- Average positioning latency,
- Average positioning latency in Emergenmcy ISHO,
- Distribution of positioning latency per used positioning method.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

44 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
1.8 Supplementary Telecom Features

1.8.1 MORAN for up to 4 Operators

Feature ID: RAN1452

Summary: Multi-Operator RAN allows 2-4 operators to share radio access network.
Operators' own end-user services are available in the shared network area services.
Sharing operators use their own frequencies and own PLMN-id. Solution is standards-
compatible (3GPP) and it is supported with all 3G terminals. MORAN solution allows
independent control of traffic for each operator; they have dedicated cell level
parameters.

Benefits for the operator: Using MORAN for radio network sharing can enable
operators reduce CAPEX/OPEX and bring 3G services to the mass market quickly.
Although the radio network is shared, the operators still maintain perfromance and
service differentiation capabilities as MORAN allows the use of operator specific cell
level parameters.

Functional description: Nokia Siemens Multi-Operator RAN allows 2-4 operators to


share physical RNCs and BTSs. When this feature is used, all operators have their
own CS and PS interfaces towards the RNC. In such a scenario, the subscribers of
different operators use cells in different carrier layers (frequencies). The differentiation
is based on the Mobile Country Code (MCC) and Mobile Network Code (MNC) of the
cell. Each cell has MCC and MNC corresponding to the operator. This feature is
implemented with an RNC software upgrade and it is compatible with R99 and R4
Core Networks.
Multi-Operator RAN feature:
Enables the operators to reduce the costs of their networks by
sharing BTS and RNC hardware without losing control over
operator-specific radio cells.
Operators can tune their cell Radio Resource Management
parameters and monitor their traffic individually on a cell basis.
Neighbouring cell lists are operator-specific, which enables for
example own inter-system handover decisions.

DN0671022 Nokia Siemens Networks 45 (124)


Version 1.4.0
Operators are free to add additional BTSs in locations where they
want to provide better coverage or more capacity.
Operators can use their own licensed frequencies and PLMN-id.
UEs show the appropriate operator logo.
Global roaming is easy.
No extra support features from UEs needed, works with 3GPP Rel.
99 WCDMA UEs

Typical areas where to use Multi-Operator RAN are:


Initial coverage when the service demand is still low,
Low traffic areas, for example rural and suburban areas,
Places where it is hard to find BTS spots, for example subways.

Cost savings are achieved by sharing the RAN capital and operating expenditure:
RNCs,
BTSs,
Site investments,
Transmission & Transport,
Installation and commissioning,
Operations support system,
Radio network planning.

The described approach provides a technical solution for allowing operators to share
the Radio Access Network. It is required that the shared RAN is operated in co-
operation mode so that:
Network Operation and Maintenance,
Network Dimensioning,
Transport,
Network Planning and
Synchronisation (Iu-interface)
are based on mutual co-operation.
The solution allows operators to individually plan and optimise their own cell
parameters, whereas planning and dimensioning of global RNC parameters and BTS,
RNC and transmission capacity need to be handled in co-operation.

46 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Sharing the RAN offers the operators a lot of freedom in terms of deciding the scope of
their co-operation as well as when and where they want to provide additional capacity
or coverage of their own.

Current implementation: MORAN is originally supporting radio network sharing


between 2 operators.

Interdependencies between features: RAN2.0042 Nokia Multi-Operator RAN.

Operational aspects: Each operator can monitor there own part of MORAN via PLMN
(MCC+MNC) information in PM measurement objects.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC parameter file Long-term ON/OFF
licence

DN0671022 Nokia Siemens Networks 47 (124)


Version 1.4.0
2 Transmission & Transport

2.1 BTS Transport Interfaces

2.1.1 Ethernet Interface Unit IFUH (Iub User Plane) for AXC

Feature ID: RAN1097

Summary: Ethernet interface unit for AXC allowing connection from the BTS to a PS
NW.

Benefits for the operator: A lower number of E1 lines in BTS access transmission
results OPEX savings. This unit makes it possible to use Ethernet transport to carry
the whole Iub traffic or only a part of it, i.e. HSPA traffic.

Functional description: IFUH provides 2x100Base-TX and 1xGigabit Ethernet


interfaces to connect the BTS to a PS NW. The optical Gigabit Ethernet SFP is
optional. In case the whole Iub traffic shall be carried over Ethernet, synchronization
needs to be provided through other means, for example, a 2Mbit/s signal fed from a
neighbouring GSM/EDGE BTS or 2MHz signal fed from a GPS receiver.
IFUH can be added to any AXC configuration in UltraSite Supreme and Optima
cabinets, including AXC Compact.
MetroSite and UltraSite GSM/EDGE BTS upgrade kits offer two AXC slots, meant for
either one AXU and one IFU or for one AXC Compact. In case of AXU the IFUH can
also be used with these cabinets. This implies that synchronization is provided through
other means, for example, a 2Mbit/s signal fed from a neighbouring GSM/EDGE BTS
or 2MHz signal fed from a GPS receiver. In case of AXC Compact, IFUH can not be
used with these cabinets as AXC Compact already occupies the available two slots.
The IFUH can not be applied to Standalone AXC.

48 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
This feature is one of the building blocks of the Hybrid BTS Backhaul feature. The ATM
over Ethernet Application Software is required to activate the Ethernet interfaces.

Operational aspects: IFUH is fully integrated to AXC Manager and NetAct.

Software dependencies:
RAS RNC BTS Ultra BTS BTS AXC NetAct MSC SGSN MGW UE
Flexi Pico
Release RAS06 - WBTS4.0 - - C3.0 OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

2.1.2 Ethernet+E1/T1/JT1 Interface Unit (Iub User Plane) for Flexi


WCDMA BTS

Feature ID: RAN1064

Summary: Interface unit for Flexi WCDMA BTS with PDH and Ethernet interfaces. The
integrated interface unit makes it possible to use packet transport for the BTS without
additional equipment at BTS site.

Benefits for the operator: OPEX savings are achieved by a lower number of E1 lines
in BTS access transmission. This unit makes it possible to use Ethernet transport for
HSPA traffic.

Functional description: FTIA, a hybrid PDH/Ethernet transport sub module, provides


4xE1/T1/JT1 (symmetrical, 120 Ohm), 2x100Base-TX and 1xGigabit Ethernet
interfaces. FTJA, another hybrid PDH/Ethernet transport sub module, provides 4xE1
(coaxial, 75 Ohm), 2x100Base-TX and 1xGigabit Ethernet interfaces.
This feature is one of the building blocks of the Hybrid BTS Backhaul feature. The ATM
over Ethernet Application Software is required to activate the Ethernet interfaces.

DN0671022 Nokia Siemens Networks 49 (124)


Version 1.4.0
Operational aspects: FTIA and FTJA are fully integrated to Flexi Manager and
NetAct.

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release RAS06 - - WBTS4.0 - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

50 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
2.2 Transport Efficiency

2.2.1 Dynamic Scheduling for HSDPA with Path Selection

Feature ID: RAN1099

Summary: This feature is an alternative version of the Dynamic HSDPA Transport


Scheduling feature. This feature provides dynamic packet scheduling functionality with
Path Selection feature.

Benefits for the operator: The end user experience is improved thanks to higher data
throughput. The feature minimizes HSDPA packet losses and thus reduces overall
transport delay between BTS and RNC. In addition, the efficient use of available
transport resources means savings in OPEX.

Functional description: This feature introduces a rate limit functionality, which


controls the combined data rate of multiple VCCs.
The VCCs are grouped into a bundle, which has a common peak cell rate (PCR)
defined. The rate limit functionality takes care that the traffic in the bundled VCCs does
not exceed the PCR set for the bundle. In a bundle there can be VCCs towards only
one BTS. The rate-limited VCC bundle can be used to prevent the cell losses in the
last mile of the transport NW or in another bottleneck area.
Within the bundle, the rate limit functionality respects the VCC characteristics. For the
CBR and UBR+ VCCs the defined minimum bandwidth for the VCCs is guaranteed.
On the other hand, the individual VCC can use all the available capacity of the bundle
if the PCR of the VCC equals to the PCR of the bundle.
As in the Dynamic HSDPA Transport Scheduling, the flow control is based on the
monitoring of AAL2 queue, operator definable Target Delay and four AAL2 buffer
occupancy thresholds. The flow control algorithm however, is improved so that it takes
into account the variable bandwidth of the UBR+ VCC. The traffic situation in other
bundled VCCs and bundle parameters define the bandwidth available for the HSDPA.
The flow control gets the available bandwidth information in short intervals from the
bundling functionality and the thresholds are adjusted accordingly.

DN0671022 Nokia Siemens Networks 51 (124)


Version 1.4.0
Figure:

Current implementation: Dynamic HSDPA Transport Scheduling feature introduces a


RNC internal flow control functionality. It reduces the HSDPA data rate between the
MAC-d entities and AAL2 buffers in the RNC, if the AAL2 queues exceed the buffer
thresholds.

Operational aspects: Path Selection feature is required.


The operator is able to follow through existing counters the RNC AAL2 scheduling
performance for HSDPA traffic:
1) The times when AAL2 CPS packets were dropped from the HSDPA queue due to
Iub congestion,
2) The average and peak delay of packets in the HSDPA queue and
3) The average and peak service rate for the AAL2 packets in the HSDPA queue.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term capacity
licence

52 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
2.2.2 Dynamic Scheduling for NRT DCH with Path Selection

Feature ID: RAN1100

Summary: This feature introduces the flow control functionality for NRT DCH data.
This feature requires Path Selection functionality.

Benefits for the operator: The end user experience is improved thanks to higher data
throughput. The feature minimizes the NRT-DCH packet losses and thus reduces
overall transport delay between the BTS and RNC. Furthermore, OPEX savings result
from efficient use of available transport resources.

Functional description: The operator can overbook the NRT DCH data transmission
by decreasing the activity factor of NRT DCH RAB. Too long AAL2 buffer delays and
buffer overflows can be prevented using the RNC internal flow control functionality.
The flow control mechanism is based on the monitoring of AAL2 queue, operator
definable Target Delay parameter and two AAL2 buffer occupancy thresholds. Lower
threshold triggers a flow control message when queue is growing and the higher
threshold triggers a flow control message when queue is decreasing. These thresholds
are automatically set based on the Target Delay. The flow control algorithm takes into
account the variable bandwidth of the UBR+ VCC. The bandwidth information is
received in short intervals from the bundling functionality.
In addition to the RNC internal flow control, this feature introduces a rate limit
functionality, which controls the combined data rate of multiple VCCs. The functionality
is the same as included in the Dynamic HSDPA Transport Scheduling for Path
Selection. The VCCs are grouped into a bundle, which has a common PCR defined.
The rate limit functionality takes care that the traffic in the bundled VCCs does not
exceed the PCR set for the bundle. In a bundle there can be VCCs towards only one
BTS. The rate-limited VCC bundle can be used to prevent the cell losses in the last
mile of the transport NW or in another bottleneck area.
Within the bundle, the rate limit functionality respects the VCC characteristics. For the
CBR and UBR+ VCCs the defined minimum bandwidth for the VCCs is guaranteed.
On the other hand, the individual VCC can use all the available capacity of the bundle
if the PCR of the VCC equals to the PCR of the bundle.

Operational aspects: Path Selection feature is required.


The operator is able to follow through new counters the RNC AAL2 scheduling
performance for NRT traffic:
1) The times when AAL2 CPS packets were dropped from the NRT queue due to Iub
congestion,

DN0671022 Nokia Siemens Networks 53 (124)


Version 1.4.0
2) The average and peak delay of packets in the NRT queue and
3) The average and peak service rate for the AAL2 packets in the NRT queue.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term capacity
licence

2.2.3 Path Selection

Feature ID: RAN759

Summary: Path Selection allows defining dedicated VCCs for selected types of traffic.
This feature makes it possible to separate, for example, RT-DCH, NRT-DCH and
HSPA traffic to dedicated paths. The paths can have different service categories and
traffic parameters according to the required QoS targets.

Benefits for the operator: OPEX and CAPEX savings are gained in RAN transport
NW. This feature makes it possible to direct different traffic types to separate
transmission paths and use cost-optimized transport media and service categories
according to the specific QoS requirements.

Functional description: Path selection divides the traffic into 3 path types (4 with
HSUPA). Stringent path is designed to be used for RT-DCH, bi-level for NRT-DCH and
tolerant for HSDPA and HSUPA. For each path a dedicated VCC can be configured.
Thus alternative configurations are with 2 or 3 VCCs:
- 4 VCC configuration: dedicated VCCs for HSDPA, HSUPA, NRT-DCH and RT-DCH
- 3 VCC configuration: dedicated VCCs for HSPA, NRT-DCH and RT-DCH
- 3 VCC configuration: dedicated VCCs for HSDPA and HSUPA,
all DCH traffic in another VCC

54 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
- 2 VCC configuration: dedicated VCC for HSPA, all DCH traffic in another VCC
- 2 VCC configuration without HSPA: dedicated VCC for RT-DCH,
another VCC for NRT-DCH
For each interactive traffic class THP group the operator can define whether it is
treated as delay sensitive or delay non-sensitive and accordingly, it is assigned
stringent or bi-level path.
Capability Set 2 for the AAL2 signaling protocol is supported. CS2 AAL2 Path type
parameter is added to AAL2 signaling message if Path Selection feature is used.
The following transport features may provide further benefits when used together with
Path Selection:
- UBR+ for Iub User Plane for the statistical multiplexing gains,
- Transport Bearer Tuning for configurable activity factor for DCHs,
- Dynamic Scheduling for HSDPA with Path Selection for reduced packet loss and
delay on the Iub,
- Dynamic Scheduling for NRT-DCH with Path Selection for reduced packet loss and
delay on the Iub,
- Hybrid BTS Backhaul for using Ethernet for the tolerant path.
- Path Selection feature enables more versatile configurations for HSUPA transport
solution.

Figure:

Current implementation: Route Selection feature allows dedicating a VCC for


HSDPA traffic.

DN0671022 Nokia Siemens Networks 55 (124)


Version 1.4.0
Operational aspects: The operator can detect cell loss using statistical counters
implemented on the line cards of the RNC. When the cell loss becomes too high, more
bandwidth should be allocated for the traffic between the RNC and the hub.
The operator can follow up through new and existing counters 1) the traffic load
percentage for each ATM VCC terminated to RNC 2) the traffic discarded due to ATM
interface congestion per ATM VCC.
New counters are added to the ATM Virtual Channel Connection Measurement.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 C3.0 OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term capacity
licence

2.2.4 Transport Bearer Tuning

Feature ID: RAN1096

Summary: This feature allows the operator to configure the activity factors of Iub
transport bearers. By optimizing the activity factor of different transport bearers it is
possible to have higher number of simultaneous users in the system.

Benefits for the operator: OPEX and CAPEX savings and improved end user
experience are achieved by support of increased number of simultaneous data calls.

Functional description: The activity factor is defined as the relation between average
cell rate and peak cell rate. Average cell rate and Peak cell rate are part of bearer
specific AAL2 Link characteristics (ALC).
Tuning the activity factors is recommended to be done by the operator, based on the
information of the actual activity of the bearers. In case the actual activity exceeds the
configured activity factor, there is a risk of traffic loss on Iub, and consequently, the
performance of the system as a whole is degraded.

56 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Risk related to traffic loss can be reduced by utilizing this feature with RAN06 Path
selection, UBR+ for Iub user plane, and Dynamic scheduling for nrt DCH with Path
selection.

Current implementation: Currently, the activity factor is not available in the user
interface, but instead predefined values are used. An activity factor of 60% is assumed
for voice bearers and an activity factor of 100% for nrt data bearers.
For signaling radio bearers (SRBs) an activity factor of 10% is assumed from RAN04
onwards and the activity factor of SRBs is operator selectable, out of three predefined
values.

Operational aspects: For the transport VCC reserved bandwith there exist already
CAC based counters.
For AAL2 Scheduling monitoring in each VCC see the "Dynamic Scheduling for
HSDPA Path Selection" and "Dynamic Scheduling for NRT DCH Path Selection"
counters.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

2.2.5 UBR+ for Iub User Plane

Feature ID: RAN1095

Summary: This feature introduces a new ATM service category for Iub interface. The
UBR+ service category increases the transport efficiency and makes it possible to
benefit from statistical multiplexing gain in the RAN transport. UBR+ is intended to be
used together with the Path Selection feature.

DN0671022 Nokia Siemens Networks 57 (124)


Version 1.4.0
Benefits for the operator: More efficient usage of the available Iub capacity mean
OPEX and CAPEX savings in transport NWs.

Functional description: UBR+ VCC is defined by its Minimum Defined Cell Rate
(MDCR) and Peak Cell Rate (PCR). User traffic is able to utilize the free capacity up to
the PCR value, and a guarantee of MDCR is given in order to support a minimum
throughput in case of high Iub load.
With Path Selection, one UBR+ VCC can be used for NRT-DCH traffic, and another
UBR+ VCC can be used for HSDPA traffic. It is recommended to keep the real time
traffic in CBR VCC to maintain the QoS. In this kind of configuration, UBR+ VCCs can
share the free capacity up to the defined PCR. Capacity of MDCR is guaranteed also
in case of high Iub load.
Since the NRT traffic carried over the DCH has more stringent Iub delay requirements
than HSPA, priorities need to be defined so that it is delivered with lower delay and
delay variation. This is supported with UBR+ parameters that are operator
configurable:
- MDCR value for NRT-DCH should be set high enough for the guaranteed throughput.
- Among multiple UBR+ VCCs, priority can be assigned by parameters settings.
Division of excess bandwidth between NRT-DCH VCC and HSDPA VCC should be set
so that NRT-DCH gets higher priority over HSDPA. (At NB/RSxxx this configurable
prioritization is not available)

Current implementation: In previous releases, the UBR is supported for O&M traffic
and CBR is applied for all other traffic; user plane and control plane VCCs.

Operational aspects: The operator can follow up through new counters in RNC:
1) The INGRESS and EGRESS ATM cell traffic for each RNC ATM Interface
distributed per ATM Service Classes: CBR, UBR and UBR+,
2) The discarded traffic due to ATM layer congestion per ATM interface.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC SGSN MGW UE

Release RAS06 RN3.0 WBTS4.0 WBTS4.0 WP2.0 C3.0 OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN FTM LK Long-term ON/OFF
licence

58 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
2.3 Transport Redundancy

2.3.1 Flexi WCDMA BTS IMA Based AAL2 Uplink CAC

Feature ID: RAN1319

Summary: Available capacity for FlexiWCDMA BTS AAL2 uplink AAL2 admission
control is modified in case of a link failure in a terminating IMA group.

Benefits for the operator: In case of a E1/T1 link failure in an IMA group, admission
control limits traffic to the value corresponding to the number of operational links in an
IMA group. This results in a high quality of service for the admitted connections, even
in case of a link failure.

Functional description: When an individual E1/T1 connection in an IMA group fails,


the FlexiBTS notices this through a physical layer alarm (Loss of signal), and
associates this with a particular IMA link. IMA group will reconfigure itself to a lower
number of links available.
Consequently FlexiBTS modifies the capacity available to equal the number of links
available in the IMA group
New calls are now admitted only up to the actual capacity available.
When the link is corrected, or when the user adds a new link to the group, the IMA
group reconfigurs to the full number of links, and then the CAC will resume full capacity

Figure:

DN0671022 Nokia Siemens Networks 59 (124)


Version 1.4.0
Current implementation: In the current release, FlexiWCDMA BTS Uplink Admission
control available capacity is not modified by IMA link failures.

Interdependencies between features: This feature has no related or interworking


features.

Hardware requirements: This feature does not require any new or additional HW.

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release RAS06 - - WBTS4.0 - - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

60 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
2.4 IP Transport

2.4.1 Hybrid BTS Backhaul

Feature ID: RAN1063

Summary: Hybrid BTS Backhaul system solution makes it possible to offload HSPA
traffic to a separate path between the BTS and RNC. The less delay sensitive HSPA
and optionally also NRT-DCH traffic can be directed to Ethernet transport NW whereas
RT-DCH can be directed to TDM NW.
Hybrid BTS Backhaul system solution consists of several separate and alternative HW
units and equipment and SW features.

Benefits for the operator: OPEX savings are achieved through a reduced number of
E1 lines needed at NodeB. This system solution allows using low cost transport media
for HSPA and NRT-DCH traffic.

Functional description: Hybrid BTS Backhaul is based on emulating one or multiple


ATM VCCs over a PS NW. The emulation is performed in accordance with the PWE3
specification of IETF, meaning that ATM cell flows are tunneled through the PS NW.
ATM cells are concatenated inside IP packets. The Pseudo Wire extends between the
BTS and a stand-alone gateway. The BTS provides 2 Fast Ethernet interfaces and an
optional Gigabit Ethernet interface (SFP module) towards the NW. On the RNC site,
the corresponding gateway provides STM1/OC3 interfaces towards the RNC and a
Gigabit Ethernet interface towards the NW.
In order to offload only HSPA traffic to the PS NW, Hybrid BTS Backhaul can be
combined with the Route Selection or Path Selection feature. In this case, only the
ATM VCCs dedicated to HSDPA/HSUPA are emulated, while all other ATM VCCs are
conveyed over TDM technologies.
In case the BTS is not connected to a TDM, NW synchronization has to be provided
through other means, for example, a 2MHz signal fed from a neighboring GSM/EDGE
BTS or a GPS receiver.
Hybrid BTS Backhaul is an umbrella feature consisting of the following building blocks:
- BTS Ethernet interfaces for UltraSite WCDMA BTS and Flexi WCDMA BTS,
- RNC site gateway,
- ATM over Packet Application Software for BTS,

DN0671022 Nokia Siemens Networks 61 (124)


Version 1.4.0
- Route Selection or Path Selection Application Software for RNC, in case only HSPA
traffic shall be offloaded.
As an alternative to BTS Ethernet interfaces a stand-alone gateway can be deployed
to the BTS site. The gateway provides E1/T1/JT1 interfaces towards the BTS and a
Fast Ethernet interface towards the NW. The Pseudo Wire then extends between the
gateway on the BTS site and on the RNC site.

Current implementation: Without Hybrid BTS Backhaul, all data is carried by ATM
over E1 or SDH.

Operational aspects: ATM VCCs destined for emulation are configured and managed
similarly to traditional TDM interfaces. The BTS Ethernet interfaces and associated
PWE3 functionality are fully integrated to existing BTS and RAN O&M systems.
Fault Management: the status of the physical Ethernet interfaces is monitored, errors
are detected (loss of carrier, LOS) and consequent alarms are raised. The status of the
Pseudo Wires is monitored using the VCCV-BFD protocol for connectivity verification.
VCCV-BFD provides a light weight mechanism that enables monitoring the service
continuity over the PS NW. When a fault is detected an alarm is raised at both the BTS
and the stand-alone gateways.
Performance Management: comprehensive data is collected, starting from physical
layer to the highest PW protocol layer. On each layer, received packets (distinguished
in error free and erroneous packets) and transmitted packets are counted. ATM
Performance Management data is available the same way as for traditional TDM
interfaces.
The performance of AXC and FlexiBTS hybrid backhaul interface can be followed
through new counters; 1) ingress/egress traffic amount of Ethernet interface 2)
discarded traffic due to Ethernet interface traffic shaping 3) errors detected by Ethernet
interface. The Error events related to the functionality of Pseudo Wire Emulation are
also visible through related counters in AXC and FlexiBTS.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 - WBTS4.0 WBTS4.0 x C3.0 OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN - -

62 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
2.4.2 ATM over Ethernet for BTS

Feature ID: RAN1142

Summary: ATM packets can be transported over Ethernet, allowing the use of low
cost transport media between BTS's and RNC.

Benefits for the operator: A lower number of E1 lines in BTS access transmission
results Opex savings. This feature makes it possible to use low cost transmission
media for HSPA traffic.

Functional description: One or multiple ATM VCCs are emulated over a PS NW. The
emulation is performed in accordance with the Pseudo Wire Emulation Edge to Edge
(PWE3) specification of IETF, meaning that ATM cell flows are tunneled through the
PS NW. The ATM cells are concatenated inside IP packets.
This feature is one of the building blocks of the Hybrid BTS Backhaul feature. The ATM
over Packet is supported for Ethernet interfaces on IFUH (UltraSite WCDMA BTS) and
FTIA / FTJA (Flexi WCDMA BTS).

Current implementation: This is a new feature.

Interdependencies between features: This feature will often be used together with
RAS06 Path Selection feature to enable the Hybrid Backhaul solution.
In case all WCDMA traffic can be transported over the Ethernet interface an alternative
synchronisation option needs to be selected (2MHz, GPS, 2Mbit/s)

Hardware requirements: AXC: IFUH


Flexi WCDMA BTS: FTIA, FTJA (FTIB in RU10)

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 - WBTS4.0 WBTS4.0 - C3.0 OSS4.2 - - - -

DN0671022 Nokia Siemens Networks 63 (124)


Version 1.4.0
SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN FTM LK Long-term ON/OFF
licence

64 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
3 Operability

3.1 Network Monitoring and Maintenance

3.1.1 RNC GUI for BTS Connection Resources

Feature ID: RAN1199

Summary: This feature introduces new functionality to view RNC connection


recources for BTS in RNC GUI object browser application.

Benefits for the operator: OPEX savings because of easier and faster
troubleshooting capabilitites in RNC.

Functional description: The feature improves trouble shooting with RNC element
manager by introducing new RNC GUI solution for tracking the operational status of
different BTS connections and involved RNC HW units with their operating statuses.
The BTS Connection Resource information shall include the following information:
RNC
- RNC identification.
WBTS
- WBTS name (RNW parameter WBTSName),
- WBTS additional information (RNW parameter BTSAdditionalInfo),
- Related Connection Configuration Identifier.
WCELs
- WCEL state,

DN0671022 Nokia Siemens Networks 65 (124)


Version 1.4.0
- HS-DSCH operative state,
- LcrId,
- LAC,
- Cid,
- SAC,
- RAC,
- UARFCN,
- PriScrCode,
- UE count,
- Operational states of Common channels (FACH, PCH, RACH, FACH-C/Connect,
FACH-C/Idle, FACH-U and FACH-S)
- Related DMCU units for Common channels,
- Snapshot of amount of calls (emergency, signalling link, AMR, RT CS, NRT CS, RT
PS, NRT PS, HSDPA and HSUPA),
Iub link configuration
- C-NBAP link,
- External TPI (ATM interface, VPI, VCI),
- ATM interface status,
- Operational state,
- Related ICSU index,
- D-NBAP links (1-6),
- External TPI (ATM interface, VPI, VCI),
- ATM interface status,
- Operational state,
- Related ICSU index,
- AAL2 signalling links (1-6),
- ATM interface status,
- External TPI (ATM interface, VPI, VCI),
- Operational state,
- Related ICSU index,
- AAL2 user plane links (1-18),
- ATM interface status,
- External TPI (ATM interface, VPI, VCI),

66 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
- Operational state,
- Related A2SU,
- AAL2 path id,
- A2EA,
- Route ID,
- AAL2 path bandwidth (UL / DL),
- Average total load of AAL2 path (UL / DL),
- Number of unsuccessful resource reservations,
- Number of successful resource reservations,

Figure:

Current implementation: WBTS connection related data can be seen in RNW Object
Browser (for example: NBAP link states) and by using MML's (for example: ATM link
status). The information is scattered into different user interfaces.

Interdependencies between features: This feature has no interaction with other


features.

Hardware requirements: This feature has no special HW requirements.

DN0671022 Nokia Siemens Networks 67 (124)


Version 1.4.0
Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

3.1.2 Collection of Key Counters

Feature ID: RAN1160

Summary: The feature enables NetAct to provide a set of Key Counters in short
intervals in a single new measurement. Key counters are collected from the existing
cell level measurements produced by RNC.

Benefits for the operator: CAPEX savings are achieved when accurate
measurements are required. OPEX savings result from a possibility to improve
measurement utilisation.

Functional description: NetAct provides a new Key Counter measurement, which


can include a collection of priority counters from the cell level measurements produced
by the RNC. The data is accessible the same way as any other PM data via NetAct
tools and interfaces.
Key Counter measurement provides an opportunity for capacity savings in the NW
management systems. The source measurements can be collected in parallel with the
Key Counter measurement, but the measurement interval for the new measurement
can be set to be different. This enables using the Key Counter measurement to collect
some of the data more frequently, without compromising too much on the system
capacity by collecting everything at the finest granularity. The new measurement can
be collected for example at 15min interval while keeping the source measurements on
60 minutes.

68 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
There will be more flexibility on configuring the contents of the new measurement in
OSS5, but this requires manual commissioning tasks, and there are restrictions also
on, for example, retaining data over changes in the measurement definition.
The measurement id for Key Counter measurement will be M1050. This is just for the
administrative purposes of the measurement itself. The counters in the key counter
measurement will have the same Mxxxx Id and abbreviation as used in the
"originating" measurement.

Figure:

Current implementation: Currently, the whole measurement with all the counters
needs to be collected if any of the included counters is needed. The interval of the
whole measurement has to be set according to the finest time granularity needed for
any of its counters.

Interdependencies between features: There are no dependencies with other RAN


features, but the basic PM data collection system has to be in place before the feature
can be utilized.

Operational aspects: The feature can be used via the normal PM data collection and
activation mechanisms once installed and activated.
The Key Counter measurement is only available from NetAct, but it can be forwarded
via the open OMeS interface towards other management systems.
There can be only one Key Counter measurement, and the definition of that has to be
consistent over the network.
The supported intervals are 15, 30 and 60 minutes. In addition, the interval has to be
shorter than or equal with the interval of the source measurements where the Key
Counters is based on. The maximum interval for a source measurement is 60 minutes.

DN0671022 Nokia Siemens Networks 69 (124)


Version 1.4.0
The Key Counter measurement will contain 500 counters, and those have to be from
the WCEL level measurements that are produced by RNC (M1000, M1001, M1002,
M1005, M1006, M1007, M1008 and M1010), not for example from mediated BTS
measurements.
The schedule of the source measurements will be adjusted to 24 hours, 7 days a
week.
Modifications on the measurement content are only possible in OSS5. This will require
manual commissioning. During commissioning there might be inconsistencies or
missing PM data for the related measurements. Depending on the nature of changes,
the data history from NetAct PM DB might also be lost for the Key Counter
measurement.

Hardware requirements: The feature has no special hardware requirements.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

3.1.3 Alarms for PM Measurement Data Transfer Failures

Feature ID: RAN1161

Summary: The feature introduces new alarms for noticing problems in PM data
collection.

Benefits for the operator: OPEX savings result from faster discovery of problems in
measurement collection mechanism.

Functional description: This feature introduces new alarms for ensuring correct
information about the problems in the PM data transfer.

70 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
New alarms are introduced for the following failure situations:
- OMS is not able to retrieve Measurement data from RNC OMU or BTS,
- NetAct is not able to retrieve Measurement data from OMS,
- There are problems in measurement data processing,
Alarms are cancelled when the situation is recovered.
There are various in-built mechanisms for recovering from problems, so the alarms are
only generated for situations that:
- Result in loss of data,
- Require explicit action for resolution,
- Indicate a problem in performance of measurement data processing or transfer,
The new PM alarms are only intended to cover the PM specific aspect of the data pipe.
There are separate mechanisms to notice, for example, general problems with DCN or
RNC - BTS connections.
New group for OMS alarms is added (71000-72000). New alarm introduced by this
feature are:
-71000 PM FTP CONNECTION FAILED,
-71001 MEASUREMENT DATA NOT TRANSFERRED,
-71002 MEASUREMENT DATA ERROR,
-71003 OMS MEASUREMENT DATA PROCESSING OVERLOAD.

Current implementation: There are mechanisms for noticing generic O&M related
failures, for example, DCN breaks, but mostly no indicators for the PM specific
problems.

Interdependencies between features: There are no dependencies to other RAN


features as such, but the basic FM and PM functionality has to be available.

Operational aspects: The feature is usable via the normal NetAct monitoring tools
once the feature has been activated.

Hardware requirements: This feature has no special HW requirements.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

DN0671022 Nokia Siemens Networks 71 (124)


Version 1.4.0
SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

3.1.4 RNC Support for Traffica

Feature ID: RAN1150

Summary: Traffica tool supports real time monitoring of RNC measurements. Real
time information is available on both transport and radio layer.

Benefits for the operator: Statistical data is available in real-time.

Functional description: Traffica tool is taken into use also for the RNC
measurements. Traffica supports real time monitoring and this can be used, for
example, for troubleshooting purposes.
Information is provided on both transport and radio layer:
- For example, external ATM VC counter, AAL2 path CAC statistics, Internal CAC
statistics and
- For example, call handling counters.
The Traffica Tool gets the data from one up to three RNC(s) by pre-defined event
based Real-time Traffic Reports (RTT).
The following event triggered reports are UE specific, i.e. they include also IMSI of the
user thus enabling to monitor events related to a specific subscriber:
- RRC/RAB report for Service use cases provides detailed information of each RRC
connection and RAB that is established or released in the RNC.
- Soft Handover Failure event triggered report for Mobility use cases.
Periodic reports that are produced with 60 second interval:
- External AAL2 transport resource report for Resource use cases.
- Internal AAL2 transport resource report for Resource use cases. With this report it is
possible to see for example the number of HSPA users per DMPG.
- ATM VC Traffic report provides information on the transferred data on RNC external
ATM interfaces. This is related to Throughput use cases.

72 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
- Call resource handling report. This report can be used for example to view the
number of services (SRB, RT, NRT, HSPA) in each ICSU.
- Call resource error code report. This report shows the number of most common error
codes related to call resource allocations, the reasons for errors can be for example
DMPG resource shortage or Iub congestion.
The listed Use Cases are documented in WCDMAN RAN System
Documentation/Monitor.
RNC sends each RTT via dedicated interface to the Primary Traffica Network Server.
There is always one Primary Traffica Network Server for each RTT. This means that
simultaneously only one Traffica Server can receive the same RTT. Traffica analyses
the data and creates KPI:s based on the data. These KPI:s can be visualized in
Traffica Real-time graphs.
Event data is also stored in Traffica database for short periods of time for
troubleshooting purposes. Optionally both KPI:s and RTT:s can be exported from
Traffica system to long term storage for long term reporting purposes.

Figure:

Current implementation: This can be done by basic counters but the time to obtain
the information is tied to the measurements intervals. The intervals - at shortest 15
minutes, usually 1 hour - are too long for this kind of troubleshooting.

Operational aspects: Connectivity:


- RNC may send data to 10 Traffica servers
- Each Traffica server may be connected to max 3 RNC
Feature management:
- The feature is managed via Traffica server and NetAct.
New parameters:
- There is a new parameter to set the RNC Traffica feature state
(ENABLED/DISABLED) in RNC.

DN0671022 Nokia Siemens Networks 73 (124)


Version 1.4.0
Monitoring aspects of the feature (besides the provided RTT data):
- An alarm is set from the Traffica server to NetAct in case connection to some RNC is
lost.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW NetAct RAN - -

74 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
3.2 Configuration Management

3.2.1 Dynamic Access Class Restriction

Feature ID: RAN1128

Summary: This feature introduces more flexible ways of controlling Radio Network
Access and Domain Specific Access Class (DSAC) restriction.
Operator can specify the Radio Network Access Restriction (RNAR) level separately in
two different location areas and the DSAC restriction level in four different location
areas for both core types.

Benefits for the operator: The feature makes it possible to control and restrict the
user traffic in emergency situations.

Functional description: This feature brings enhancement to the current RNAR and
the DSAC restriction features by adding the usage of the cell groups.
User can define 10 traffic restriction groups. Each group has the type of restriction
defined: 'RNAR' or 'CS-DSAC' or 'PS-DSAC'. Each group has its own id, restriction
level definition and the functionality can be activated independently for each group.
Each cell can be connected to a 'Radio Network Access Regulation function' or
'Domain Specific Access Restriction' group by selecting the group id for the cell.
In addition, it is possible to activate the RNAR functionality and DSAC restriction for all
cells in the RNC with one selection.
Compliance:
3GPP Rel.6 TS 25.331 v6.5.0

DN0671022 Nokia Siemens Networks 75 (124)


Version 1.4.0
Figure:

Current implementation: In the RNAR function, one cell group is supported and cells
are selected to the group one by one.
The DSAC restriction can be set separately to both CN domains but the access class
restriction level is the same for both core types. The restriction interval is common for
the RNAR function and DSAC restriction cell groups.

Interdependencies between features: Both 'Radio Network Access Function' and


'Domain Specific Access Class Restriction' are paused when RNW plan activation
using fast mode is initiated. If traffic restriction period ends (timer set for Restriction
Interval expires) during plan activation then new restriction information is not sent to
cells. New restiriction information (updated Access Class barred list) is sent to cells
after RNW plan activation is complete.

Operational aspects: Using Dynamic Access Class Restriction


Feature is configured by using conventional configuration management operations
towards RNC from NetAct or RNC EM applications. Traffic restriction is applied by
setting the parameters related to this feature so that wanted restriction level is
achieved.
Activating Direct Activation of RNW Changes Using NWI3
The feature is optional. To activate the feature related NetAct license have to be
bought.

Hardware requirements: This feature has no special HW requirements.

76 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - 3GPP
Rel-6

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC parameter file Long-term ON/OFF
licence

3.2.2 Selectable RNW Plan Activation Mechanism

Feature ID: RAN212

Summary: This feature introduces a control mechanism for activation speed and NW
availability in the RNW configuration plan activation operation. Three alternative modes
are supported.

Benefits for the operator: OPEX saving are acquired thanks to the possibility for
faster RNW configuration.

Functional description: The operator can select which way the plan will be activated.
The safe activation mode is the slowest and has less influence to the traffic while the
fast activation method may have influence to the existing traffic.
1 Safe activation mode (existing method):
Plan is activated with the current method: one object at the time. This method has
minimal affect to the traffic.
2 Normal activation mode:
The existing NW is taken into account so that simultaneous operations are not done to
adjacent wcells. This method has moderate affect to the traffic.
3 Fast activation mode:
The object dependencies are ignored. Operations are done parallel as a mass
operation. This method has biggest effect to the traffic.

DN0671022 Nokia Siemens Networks 77 (124)


Version 1.4.0
The purpose of the feature is to enable faster activation time for the RNW plan.

Current implementation: In current implementation, the safe activation mode (mode


1) is available.

Interdependencies between features: 'Radio Network Access Regulation Function'


(RNAR) and 'Domain Specific Access Class Restriction'(DSAC) are paused when
RNW plan activation using 'fast' mode is started. The existing traffic restriction applied
in cells by using RNAR and DSAC will remain same until RNW plan activation is
complete.

Operational aspects: NetAct Radio Access Configurator provides user the possibility
to select the 'activation mode' that will be used. Activation mode can be set individually
for each operation.

Hardware requirements: This feature has no special HW requirements.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW NetAct RAN NetAct -

3.2.3 Flexi WCDMA BTS Support for RNS Split

Feature ID: RAN1059

Summary: The feature enables RNS Split plan management concept support for the
FlexiBTS.
The execution of RNS split operation for the FlexiBTS can be planned in advance and
the BTS outage due to operation is decreased.

78 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Benefits for the operator: OPEX savings are achieved due to the reduced time of
WCDMA Flexi BTS configuration and reduced amount of possible human errors during
configuration process.

Functional description: With this feature the configuration of the FlexiBTS transport
module is included in the RNS Split concept.
The FlexiBTS transport configuration upload, download and activation operations can
be triggered from the NetAct RNS split application. The configuration data is
transferred from the NetAct to the NE via NWI3 interface in XML format. The RNC
mediates the NWI3 plan management interface to the BTS O&M interface for the
FlexiBTS. FlexiBTS forwards the configuration file information to the FTM.
The operator can also schedule the configuration upload, download and activation
operations.

Current implementation: Currently, the RNS Split operations can be executed only
with Ultra BTSs. All RNS configuration actions for a FlexiBTSs must be done manually.

Interdependencies between features: This feature requires activation of the following


licensed feature:
* Automated RNS split

Operational aspects: Feature can be used by activating the NetAct RNS split
application and by using the NetAct RNS split application for the uploading, planning,
downloading and activation of the FlexiBTS transport configuration files.

Hardware requirements: This feature has no special HW requirements.

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release RAS06 RN3.0 - WBTS4.0 - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW NetAct RAN NetAct -

DN0671022 Nokia Siemens Networks 79 (124)


Version 1.4.0
3.2.4 Direct Activation of RNW Changes Using NWI3

Feature ID: RAN1084

Summary: This feature provides a mechanism for making direct parameter changes in
the RNW configuration from the NetAct.

Benefits for the operator: OPEX savings are achieved because of faster RNW
parameter changes from NetAct.

Functional description: With this feature, the NetAct Radio Access Configurator user
is able to perform direct operations to individual parameters in the RNW configuration.
The changes are distributed to the NW online without separate activation procedure.
The following operations are supported
- Create
- Modify
- Delete
- Lock / Unlock (WCEL)

Current implementation: In the current implementation, the RNW configuration


changes are distributed to the NW as plan files with separate download and activation
procedures. The plans are a good alternative for mass operations, but for small
operations the plans are too tedious to create, pre-activate and activate.

Interdependencies between features: Direct activation request can not be executed


during RNW plan operation (plan upload, rollback, download or activation). In case
there are both Direct Activation and RNW plan operations to be done for same RNC
then NetAct does Direct Activation operations first.

Operational aspects: Using Direct Activation of RNW Changes Using NWI3:


Feature can be used by activating the NetAct Radio Access Configurator application
and by using the application for the small RNW configuration modifications.
Activating Direct Activation of RNW Changes Using NWI3:
The feature is optional. To activate the feature related NetAct license have to be
bought.

Hardware requirements: This feature has no special HW requirements.

80 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW NetAct RAN NetAct -

DN0671022 Nokia Siemens Networks 81 (124)


Version 1.4.0
3.3 O&M Security

3.3.1 Centralised User Information Management for BTS

Feature ID: RAN618

Summary: This feature enables a centralized user account management for BTS from
NetAct.

Benefits for the operator: The centralized RAN system security results enhanced risk
management and OPEX savings.

Functional description: Both BTS element manager user and BTS host are identified
to fulfill the security requirements.
This feature enables new user creation, password change and user deletion. User is
able to manage the access to the O&M NW separately for each group or individual of
the maintenance personnel on a BTS access level. BTS users have one type of
authorization access profile in use.
In login phase the network entity checks the user access right from the authentication
server located in the NetAct.
With this feature the user can access different network systems with the same user
name and password.

Current implementation: In previous releases, the centralized user information


management has been implemented for the RNC and AXC.

Interdependencies between features: This feature interacts with a feature


"Centralized User Event Log Management for BTS" which has been planned to
upcoming release.

Operational aspects: BTS users have only one type of authorization access profile in
use.
BTS tries first to authenticate user from the local user database, if no success after
that from the centralized user repository.

Hardware requirements: This feature has no special HW requirements.

82 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 RN3.0 WBTS4.0 WBTS4.0 x C3.0 OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW NetAct RAN NetAct -

3.3.2 IP Address & Port based Filtering for BTS LMPs

Feature ID: RAN1159

Summary: This feature allows defining selectively the access to/from IP DCN from/to
all entry points at NodeB site. Filtering is based on source and destination IP address
and port information.
This feature improves protection of
- IP DCN from harmful IP traffic originated from NodeB
- NodeB from harmful IP traffic arriving from IP DCN

Benefits for the operator: Enhanced risk management is achieved because of


improved RAN system security.

Functional description: The feature implements the means of access protection to


the Ultra Site WCDMA BTS's transmission (AXC) and Flexi WCDMA BTS's
transmission.
It is possible to filter IP traffic based on source and destination IP address and
TCP/UDP port number. This IP traffic supervision is covering all packet flows in
WCDMA BTS.
Feature introduces a new mode to define more selectively the access to/from IP DCN.
Since WAM offers also an LMP, this feature increases security with respect to all
NodeB LMPs.
The operator can select between the following modes, independently for each of the
three packet flows:

DN0671022 Nokia Siemens Networks 83 (124)


Version 1.4.0
- In unrestricted mode, all IP traffic is allowed to pass through,
- In restricted mode, no IP traffic is allowed to pass through,
(Only available for AXC LMP <> IP DCN packet flow because WAM/AXC need at least
IP connectivity towards Netact/NEMU),
- In restricted mode with exceptions, the AXC IP routing function validates the source
and destination information of each incoming IP packet against the configuration in the
related table. IP packets not matching the criteria are discarded.
Whether only IP addresses or ports as well need to match is a matter of configuration.
It is possible to configure IP filter rules for AXC/FlexiBTS locally or remotely with site
configuration files or element manager.

Current implementation: So far the operator could only select to either block all or
transparently pass-through all IP traffic between the AXC LMP and IP DCN, by
switching restricted mode on/off. With the IP traffic between the WAM/AXC and IP
DCN there was no possibility for any control at all.

Interdependencies between features: The feature improves the restricted mode


feature in AXC.

Operational aspects: The operator is not obliged to define selectively the access
to/from IP DCN. The system can either be operated in the well-known modes or one
could make use of the benefits of this feature by configuring the source and destination
IP address & port information tables appropriately, independently for the three packet
flows.
AXC LMP <> IP DCN packet flow
- Unrestricted mode
- Restricted mode
- Restricted mode with exceptions
AXC <> IP DCN packet flow / WAM <> IP DCN packet flow
- Unrestricted mode
- Restricted mode with exceptions
Restricted mode is not applicable with these packet flows because WAM/AXC needs
at least IP connectivity towards Netact/NEMU.
The configuration can be modified via remote or local management session.

Hardware requirements: This feature has no special HW requirements.

84 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 - WBTS4.0 WBTS4.0 - C3.0 OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

3.3.3 IP Security for O&M Traffic between RNC and NetAct

Feature ID: RAN33

Summary: This feature enables secure transmission of O&M traffic in the O&M DCN
for the connection between the RNC and NetAct.

Benefits for the operator: Enhanced risk management is gained because of


improved RAN system security. This feature strengthens the protection against both
internal and external hostile attacks.

Functional description: Virtual Private Networks (VPN) is defined for the O&M traffic
between the RNC and NetAct. IPSec is used to encrypt the data.
The most important part of the O&M traffic to be encrypted is naturally the user
management related information. IPSec configuration can be done based on source
and destination IP addresses and port numbers.

Figure:

DN0671022 Nokia Siemens Networks 85 (124)


Version 1.4.0
Current implementation: Currently no encryption is used for the O&M data in
WCDMA RAN.

Interdependencies between features: This feature has no interaction with other


features.

Operational aspects: The feature includes the RNC specific IPSec-related


parameters, see RNC customer documentation.

Hardware requirements: This feature has no special HW requirements.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC parameter file Long-term ON/OFF
licence

3.3.4 Mass Change of Local BTS Passwords

Feature ID: RAN1451

Summary: This feature inttroduces new functioanality for mass change BTS local
passwords remotely

Benefits for the operator: Improved System Security. Reduced effort of password
maintenance

Functional description: New element management functionality is introduced to


make possible remote password changes for Flexi WCDMA BTS.
With this functionality operator can change remotely several BTS passwords remotely.
New functionality is introduced in WN4.0 for Flexi WCDMA BTS element manager
release.

86 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Current implementation: Local passwords are managed via BTS element manager
one by one.

Interdependencies between features: No dependencies to other features.

Operational aspects: No effect.

Hardware requirements: No additional hardware requirements.

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release RAS06 - - WBTS4.0 - - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

DN0671022 Nokia Siemens Networks 87 (124)


Version 1.4.0
4 Performance Monitoring

4.1 Measure

4.1.1 3GPP TS 32.403 Related Counter Additions for RAN

Feature ID: RAN1068

Summary: This feature adds new 3GPP specified counters to Nokia Siemens
Networks Measure Solution.

Benefits for the operator: OPEX savings result from easier operation of multi vendor
NWs.

Functional description: This feature adds the following new 3GPP counters to RAN:
- RAB CS connection set-up time (Maximum),
- RAB PS connection set-up time (Maximum),
- RRC connection set-up time (Maximum),
- Failed RRC re-establishments,
- Successful RRC re-establishments,
- Not replied RRC re-establishments by the UE,
- Attempted radio link additions to active link set (UE side),
- Successful radio link additions to active link set (UE side),
- Attempted radio link additions to active link set not replied by the UE (UE side),
- Attempted radio link deletions from active link set (UE side),

88 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
- Successful radio link deletions from active link set (UE side).
Nokia Siemens Networks specific names of the counters are used in the interface
between the RNC and NetAct. The 3GPP name is used in the NetAct Northbound (=
3GPP Itf-N) interface.

Figure:

Current implementation: 3GPP has specified the RNC based counters for WCDMA
RAN into 32-series specifications. TS 32.642 specifies the UTRAN Network Resource
Model (NRM), which links all counters to a specific resource to enable counter
utilisation in operating the NW. TS32.403 specifies the actual counters. Currently a
subset of the counters specified in TS32.403 is available in Nokia Siemens Networks
RAN.

Interdependencies between features: This feature has no related or interworking


features.

Operational aspects: This feature will be a part of the WCDMA RAN Measure
Solution.

Hardware requirements: This feature does not require any new or additional HW.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

DN0671022 Nokia Siemens Networks 89 (124)


Version 1.4.0
SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

4.1.2 ATM Transport Statistics Reporting in RAN

Feature ID: RAN868

Summary: This feature provides visibility to information from separate NW layers for
building effective ATM transport NW performance reporting to the NetAct.

Benefits for the operator: Efficient tool for ATM transport optimization means OPEX
savings.

Functional description: This feature provides linking between RNW and transport
NW topology for performance statistics. The linking enables building of WBTS specific
transport NW performance reports in the NetAct Reporter and it is possible to combine
all transport resources related to a certain BTS into a single report. In addition, the
mapping is done for the ATM connection type, which means that user plane and
control plane connections can be separated for reporting.
The current reporting in the NetAct is not affected, that is, reports based on ATM layer
connection identifiers are still possible.
The object information in the ATM Measurements provided by the PM function will
contain both the radio and transport topology information.
The feature does not provide any new counters.

90 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Figure:

Current implementation: Performance statistics for ATM layer connections are


identified using the ATM connection identifiers. Because there is no linking available
between the ATM connections and the related RNW elements (for example, BTS), the
operator needs to maintain some mapping table to find out the ATM layer connection
identifiers for different RNW elements.

Interdependencies between features: This feature has no related or interworking


features.

Operational aspects: This feature will be a part of the WCDMA RAN Measure
Solution.

Hardware requirements: This feature does not require any new or additional HW.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

DN0671022 Nokia Siemens Networks 91 (124)


Version 1.4.0
4.1.3 Cell Throughput Measurements in Serving RNC

Feature ID: RAN86

Summary: This feature allows network wide monitoring of the user plane data
throughput on SRNC level towards Iub.
As an example, this feature enables easy monitoring of the distribution of HSDPA and
DCH throughput and provides statistics for HSDPA and DCH capacity optimization.

Benefits for the operator: OPEX savings are gained because of optimized Iub
throughput and transport resource utilization. Increased revenue results from improved
NW data throughput.

Functional description: This feature introduces measurements to follow the user


plane throughput of MAC-d layer for HSDPA (HS-DSCH), HSUPA (E-DCH),
NRT(DCH) and RT (DCH) traffic.
(Note that E-DCH throughput counters are part of RAN973 'HSUPA Basic RRM'
feature).
Counters are provided on cell level for SRNC related traffic.
The new counters in SRNC:
- Signaling RB DCH MAC-d throughput,
- RT CS (AMR, Conversational and Streaming) DCH MAC-d throughput,
- RT PS (Streaming) DCH MAC-d throughput,
- NRT (Interactive and Background) DCH MAC-d throughput,
- NRT (Interactive and Background) HS-DSCH/E-DCH MAC-d throughput,
UL/DL separation is provided, Traffic Class separation is not provided.
The new counters are provided by the MAC user plane functionality in RNC.
The new cell counters will be added to new Cell Throughput Measurement in RNC.
This feature doesn't bring any new alarms.

92 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Figure:

Current implementation: Common channel (RACH, FACH, PCH) MAC-c throughput


counters per cell. HS-DSCH MAC-d throughput counters at BTS per cell.

Interdependencies between features: E-DCH related cell throughput counters are


part of RAN973 'HSUPA Basic RRM' feature.

Operational aspects: This feature will be a part of the WCDMA RAN Measure
Solution.

Hardware requirements: This feature does not require any new or additional HW.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

DN0671022 Nokia Siemens Networks 93 (124)


Version 1.4.0
4.2 Trace

4.2.1 HSDPA Subscriber Trace

Feature ID: RAN234

Summary: This feature introduces HSDPA reporting for Subscriber and Equipment
Trace functionality.

Benefits for the operator: OPEX savings are acquired because of reduced time to
troubleshoot the NEs and UE. Possible troubles can be detected and relevant
measurement data presented simultaneously.

Functional description: New HSDPA related counters to be reported:


1. Basic Trace Type/UE Capability Trace record additions:
- UE HSDPA capability.
2. Basic Trace Type/Active set cell record additions:
- HSDSCH Usage,
- Target cell of HSDPA Serving Cell Change,
- Failure cause and aimed Target Cell(s) if Serving Cell Change fails.
3. Basic Trace Type/Dedicated Transport Channel record additions:
- HS-DSCH release and related cause,
The current Trace counters can be used to see non HSDPA specific issues like related
CN(s), used RAB(s), DL RLC data, state transition etc.
HSDPA Tracing will be an extension to the previously released Trace features.
All previous Trace features are simultaneously available with HSDPA Trace to enable,
for example, simultaneous voice connection tracing.

94 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Figure:

Current implementation: Current implementation enables Trace to be used in a


HSDPA capable NW without disturbance in normal Tracing, but no HSDPA specific
reporting is available.

Interdependencies between features: The HSDPA features must be active in order


to get HSDPA related data to trace records.

Operational aspects: Trace Solution can be used in:


- Capacity and Coverage verification,
- Quality ensurance,
- Troubleshooting.
This feature will be a part of the WCDMA RAN Trace Solution.

Hardware requirements: This feature does not require any new or additional HW.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

DN0671022 Nokia Siemens Networks 95 (124)


Version 1.4.0
4.2.2 HSUPA Subscriber Trace

Feature ID: RAN1052

Summary: This feature introduces HSUPA reporting for Subscriber and Equipment
Trace functionality.

Benefits for the operator: OPEX savings result from reduced time to troubleshoot the
NEs and UE. Possible troubles can be detected and relevant measurement data
presented simultaneously.

Functional description: New HSDPA related counters to be reported:


1. Basic Trace Type/UE Capability Trace record additions:
- UE HSUPA capability.
2. Basic Trace Type/Active set cell record additions:
- EdchUsage (to indicate use of E_DCH),
- Target cell of HSUPA Serving Cell Change,
- Failure cause and aimed Target Cell(s) if Serving Cell Change fails.
3. Basic Trace Type/Dedicated Transport Channel record additions:
- E-DCH release and related cause.
4. Radio Trace Type/Downlink AM RLC record additions:
- E-DCH UL RLC SDU data amounts,
- Active transmission time.
5. Radio Trace Type/Uplink Performance
- UL BLER for E-DCH.
The current Trace counters can be used to see non HSUPA specific issues like related
CN(s), used RAB(s), DL RLC data, state transition etc.
HSUPA Tracing will be an extension to the previously released Trace features.
All previous Trace features are simultaneously available with HSUPA Trace to enable,
for example, simultaneous voice connection tracing.

96 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Figure:

Current implementation: Current implementation enables Trace to be used in


HSUPA capable network without disturbance in normal Tracing. This new feature
introduces HSUPA specific reporting.

Interdependencies between features: The HSUPA features must be active in order


to get HSUPA related data to trace records.

Operational aspects: Trace Solution can be used in


- Capacity and Coverage verification.
- Quality ensurance.
- Troubleshooting.
This feature will be a part of the WCDMA RAN Trace Solution.

Hardware requirements: This feature does not require any new or additional HW.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

DN0671022 Nokia Siemens Networks 97 (124)


Version 1.4.0
5 RNC Solution

5.1 WCDMA RNC Capacity and Connectivity


Upgrades

5.1.1 Linux Based OMS Replacing NEMU

Feature ID: RAN1151

Summary: Linux based OMS replaces Windows based NEMU

Benefits for the operator: New performance management and operability features
can be used without restrictions on the performance and capacity.

Functional description: Linux(RedHat Enterprise 4 update 3) replacing the Windows


platform used in NEMU(Network Management Unit) in the earlier releases and same
time name OMS (O&M Server) will be used instead of NEMU.
Windows based NEMU is not supported in RAS06/RN3.0 anymore.
The OMS functionality does not differ from NEMU. It is responsible for the same tasks
that NEMU but with higher performance and capacity. Linux operating system also
provides high stability for this type of application.
OMS is responsible for the following tasks:
- User interface, both GUI NEMU functionalities and MMI for MML sessions,
- NetAct interface,
- O&M functions in the RNC,
- Post-processing support for measurement and statistics tasks.

98 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Current implementation: In earlier releases Windows based NEMU is used.

Interdependencies between features: RAN1181 RNC NEMU firewall feature is not


used in OMS anymore.

Operational aspects: Windows operating system in NEMu is replaced by Linux in


OMS.

Hardware requirements: MCP18-B is required for OMS.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

5.1.2 Carrier Connectivity Optimized RNC450

Feature ID: RAN1623

Summary: Operator can select either the standard original capacity optimized steps of
RNC450 or coverage optimized solution with high carriers/cell connectivity and lower
maximum PS data throughput.

Benefits for the operator: Wide network coverage can be build under RNC when the
PS data capacities are low. This is beneficial e.g. in case of network rollout phase or in
the markets where the AMR traffic is dominant. Operator can optimize the number of
needed RNCs in the network by selecting right configuration that supports best their
traffic profile.

Functional description: Carrier connectivity solution is supported by each RNC450


configurations. More carriers/cells and NodeBs can be configured under the RNC

DN0671022 Nokia Siemens Networks 99 (124)


Version 1.4.0
having lower PS data throughput. With RNC450/step2-300 AMR capacity is increased
to 6800 and with RNC450/step3-450 carrier optimized configuration AMR capacity is
increased to 10 000 Erl.
RNC HW configuration is always the same between the capacity and coverage
solution. Selection of the configuration mode is done by a SW license keys. HSPA
activation is made using different parameters for each mode.
For RNC450/step1-150 there are four different alternatives for coverage solution.
Step1 solution is already available in RAS05.1 without license key. RNC450/step2-300
and RNC450/step3-450 supports one carrier optimized configuration per each step.
License keys for all steps are introduced in RAS06.
Capacities of the coverage solution are presented in the figure below.
The number of supported HSPA users for different RNC configurations are listed in
RNC450 product description.

Figure:

Current implementation: In RAS05.1 carrier optimized configurations are supported


for RNC450/step1-150 without license control. Coverage optimized configurations are
not supported for RNC450/step2-300 or RNC450/step3-450 in RAS05.1.

100 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Interdependencies between features: This feature has no interdepencies between
other features.

Operational aspects: License keys needs to be installed in RNC450 to define whether


carrier optimsied configuration or standard one is used.

Hardware requirements: Hardware configurations are the same than earlier.

Software dependencies:
RAS RNC BTS BTS BTS AXC NetAct MSC SGSN MGW UE
Ultra Flexi Pico
Release RAS06 RN3.0 - - - - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN RNC LK Long-term capacity
licence

DN0671022 Nokia Siemens Networks 101 (124)


Version 1.4.0
6 BTS Solution

6.1 Flexi WCDMA BTS Site Solutions and Features

6.1.1 Flexi WCDMA BTS 3GPP Antenna Tilt Support

Feature ID: RAN906

Summary: Flexi BTS has integrated Antenna Tilt control HW in Radio module to
control the 3GPP Tilt Antennas. This integrated Antenna tilt HW is enabled by a
specific SW licence. NSN supports offically only antennas that are sold by us. (Today
Kathrein, Powerwave, Andrew)

Functional description: Antenna Tilt is integrated to the RF module of Flexi BTS. It


feeds DC power to the antenna and controls the antenna tilting.
In Flexi BTS this 3GPP specified antenna tilting functionality must be enabled by a SW
licence because the HW is integrated to all RF Modules.

Operational aspects: RET supported antennas will automatically be detected by Flexi


BTS.

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release RAS06 - - WBTS4.0 - - - - - - -

102 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN BTS LK -

6.1.2 Flexi WCDMA BTS AISG MHA Support

Feature ID: RAN908

Summary: Flexi BTS has integrated Bias-T HW in Radio module to control NSN AISG
2.0 MHA's. This integrated HW based SW functionality is to be enabled by a specific
SW licence.

Functional description: Bias-T is integrated to the RF module of Flexi BTS. It feeds


DC power to the MHA and controls the MHA DC power current consumption. If the
current consumption is out of a specified window, an alarm is generated. AISG has
specified additional control functionality for MHA. This control is done over OOK
modulation using the antenna feeder.
In UltraSite, the Bias-Ts have been separate HW units installed to the BTS antenna
connectors and customer has paid the functionality in the Bias-T HW price, typically 6
pieces for a 3 sector BTS.
In Flexi BTS, this AISG 2.0 MHA power feeding and enhanced MHA alarm control
must be enabled by a SW licence because the HW is integrated to all RF Modules.
NSN supports only NSN own MHAs coded with AISG vendor code 'NK'. For 3rd party
MHAs there will be special licence key and supported MHAs need to be decided case
by case.

Current implementation: Used MHA parameters will be entered during comissioning.

Interdependencies between features: RAN905 license not needed if AISG interface


activated (with license).

Operational aspects: AISG supported MHAs will automatically be detected by Flexi


BTS.

Hardware requirements: Support only NSN own AISG compatible MHS with AISG
vendor code 'NK'

DN0671022 Nokia Siemens Networks 103 (124)


Version 1.4.0
Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release RAS06 - - WBTS4.0 - - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN BTS LK -

6.1.3 40W Remote Radio Head 2100

Feature ID: RAN1223

Summary: Flexi WCDMA BTS Mast Head RF Module can be used in various indoor
and outdoor installation options (such as wall, pole, and mast) and site applications
(mini, macro and distributed site solution). The form factor is with antenna shape.

Functional description: - Fully outdoor/indoor capable Mast Head RF Head for Wide
Area solutions
- Optical link between Head and System Module
- Supports Obsai/RP3 -interface (similar interface than in Flexi WCDMA BTS RF
Module)
- No fans
- Supports only DC -voltage
- AC supply can be used when external AC/DC converter with mechanical kit is
connected to Remote Radio Head
- Support for two carriers
- HW is 50W Power amplifier (40W in antenna connector)
- 20W (in antenna connector) is default o/p power. 40W carrier power support
(RAN1002) and second carrier support (RAN1001) are lisenced features
- Operating temperature range -33 - +55C
- Antenna shape

104 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Current implementation: The Flexi Single and Dual RF modules have been used as
remote head solutions.

Interdependencies between features: This feature has no related or interworking


features.

Operational aspects: The Remote Radio Head related parameters will automatically
be detected as e.g. the current RF modules.

Hardware requirements: New Remote Radio Head HW is needed.

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release ON TOP - - WBTS4.0 - - - - - - -
OF RAS06 ED1
Note: Delivered on Top of RAS06.

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

6.1.4 External GPS Synchronisation for Flexi BTS System Module Rel 1

Feature ID: RAN1222

Summary: External GPS syncronisation is needed for the WCDMA BTSs with I-HSPA
and also for other customers that have Ethernet transport solution.

Benefits for the operator: The operators that utilise I-HSPA or Ethernet transport
need GPS syncronization.

Functional description: The BTS will get sync signal (pps) from external GPS device.
GPS signal is needed together with I-HSPA module or when the Ethernet transport is
in use.

DN0671022 Nokia Siemens Networks 105 (124)


Version 1.4.0
The GPS device is over voltage protected by mediator box (FSEG) that includes
following functionalities and parts:
-Power output (12VDC) to the GPS receiver.
-GPS signal transfer from GPS receiver to MDR26 connector in System Module
-Overvoltage protection (4KV) must be guaranteed according to standard for mast
devices which prevents System Module failures.
-IP55 protection.
-Two cables are in use (Sync in from mediator box to Rel1 System Module and 48V
from system Module to Mediator box voltage conversion to GPS receiver (+ 12V))
-In addition to Mediator box integrated GPS receiver and antenna kit(FYGA) is needed.
Separate mounting kit (FYMA) can be used for installation
-Optionally 30m (FYHA) or 100m (FYHB) cables can be used between the GPS
receiver and the Mediator box

Current implementation: No GPS sync available earlier.

Interdependencies between features: This feature has no related or interworking


features.

Operational aspects: No impact.

Hardware requirements: This solution is needed together with Rel1 system module

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release RAS06 - - WBTS4.0 - - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

106 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
6.1.5 Support for FRMB/C Unit in Flexi WCDMA BTS

Feature ID: RAN1463

Summary: FRMB/C Flexi Rectifier Module 6000 is OEM based rectifier solution for all
Flexi BTS based applications. FRMB/C is equal to Flexi BTS module in terms of
dimensions, weight, fixing points and outlook. FRMB/C will be available in indoor IP20
and outdoor IP55 versions. FRMB/C maximum output power is 6kW providing DC
connection point to maximum 2 BTSs and 3 external battery strings.

Benefits for the operator: FRMB/C allows to supply multiple BTSs or different BTS
generations from single unit still providing sufficient charging capacity for bigger battery
banks.

Functional description: FRMB/C consist of maximum three 2kW rectifier module


inside 3U high casing. Amount of rectifier units is configurable on need basis. Same
3U high casing includes also the DC-distribution (BTS and battery breakers), controller
unit with display, LMP port and space for optional over voltage protector.

Current implementation: More powerful alternative for FPAA.

Interdependencies between features: This feature has no interdependencies.

Hardware requirements: This feature has no any HW requirements.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release ON TOP - WBTS4.0 WBTS4.0 - - - - - - -
OF RAS06 ED1 ED1
Note: Delivered on Top of RAS06.

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

DN0671022 Nokia Siemens Networks 107 (124)


Version 1.4.0
6.1.6 FADB Flexi Multiradio Combiner for 900MHz

Feature ID: RAN1139

Summary: Multi Radio Combiner for 900MHz

Benefits for the operator: Enables sharing of one antenna system with two BTSs
operating on the band frequency band

Functional description: Multiradio combiner (MRC) makes it possible to use common


feeders and antennas for GSM and WCDMA systems operating on the same
frequency band. This solution provides a cost efficient way to add a WDCMA BTS to
an existing GSM site by combining signals of the two BTSs into one antenna system.
Using of MRC has minimal performance impact on WCDMA BTS. Low DL insertion
loss of 0.5dB means only minor performance impact in transmit power. MRC losses in
UL path are compensated with a MHA and if the BTS supports an adjustable front end
gain (Flexi WCDMA BTS and UltraSite/Flexi EDGE BTS), impact on sensitivity is
marginal.
MRC concept requires all TX signals of one BTS to be combined in one antenna
feeder. Therefore the dual duplex setup in GSM BTS, which is typically used when
having more than one TRX per sector, has to be removed and an additional wideband
combining stage needs to added (not applicable with cavity combining). UL
performance is maintained with a MHA in a similar way as with WCDMA BTS.

Current implementation: Both BTSs need own antennas, MHAs and feeders.

Interdependencies between features: This feature has no related or interworking


features.

Operational aspects: With MRC, common feeders and antennas can be used for
GSM and UMTS systems operating on the same system band. The solution will make
it possible to build an antenna line sharing site with uncompromised UMTS
performance and some effect on GSM/EDGE DL performance depending on the
number of TRXs per sector.
When MRC is used, all TX signals of GSM BTS need to be combined into one antenna
line when there are more than one TRX per sector. This is done with an additional
wideband combining stage, which introduces a 3.5dB loss to GSM downlink. MHA
must be used with MRC to maintain rx sensitivity of both BTSs.
MHA bias can be fed from either BTSs connected to the MRC. If WCDMA is added to
an exisiting GSM site already using a MHA, the GSM BTS continues feeding and
monitoring the MHA bias. In case MHA is only added to the site because of WCDMA
introduction with MRC, selection of MHA bias feed arrangement must be done
carefully - the BTS not feeding bias must allow MHA usage without bias feeding and
monitoring (e.g. supported with UltraSite EDGE BTS CX5.0CD2 onwards)

108 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Hardware requirements: MRC unit can be installed to a std 19" mechanics or inside a
Flexi 2U casing (FTMA). When MRC is installed outside the 2G BTS, the cabling
between MRC and the two BTSs is done using cable kits found from current jumper
cable portfolio. In case of installing the MRC inside the UltraSite EDGE or CityTalk
BTSs, the needed installation kits include required jumper cables for MRC. When
using MRC and having Flexi WCDMA modules placed inside the UltraSite EDGE BTS
using the horisontal installation kit (FMUB), a special wideband combiner must be used
to perform the additional combining of GSM TX signals - this combiner also includes
the additonal interconnecting cables needed with it.

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release ON TOP - - WBTS4.0 - - - - - - -
OF RAS06 ED1
Note: Delivered on Top of RAS06.

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

6.1.7 FACB Flexi Multiradio Combiner for 850MHz

Feature ID: RAN1079

Summary: Multi Radio Combiner for 850MHz

Benefits for the operator: Enables sharing of one antenna system with two BTSs
operating on the band frequency band

Functional description: Multiradio combiner (MRC) makes it possible to use common


feeders and antennas for GSM and WCDMA systems operating on the same
frequency band. This solution provides a cost efficient way to add a WDCMA BTS to
an existing GSM site by combining signals of the two BTSs into one antenna system.
Using of MRC has minimal performance impact on WCDMA BTS. Low DL insertion
loss of 0.5dB means only minor performance impact in transmit power. MRC losses in

DN0671022 Nokia Siemens Networks 109 (124)


Version 1.4.0
UL path are compensated with a MHA and if the BTS supports an adjustable front end
gain (Flexi WCDMA BTS and UltraSite/Flexi EDGE BTS), impact on sensitivity is
marginal.
MRC concept requires all TX signals of one BTS to be combined in one antenna
feeder. Therefore the dual duplex setup in GSM BTS, which is typically used when
having more than one TRX per sector, has to be removed and an additional wideband
combining stage needs to added (not applicable with cavity combining). UL
performance is maintained with a MHA in a similar way as with WCDMA BTS.

Current implementation: Both BTSs needs own antennas, MHAs and feeders.

Interdependencies between features: This feature has no related or interworking


features.

Operational aspects: With MRC, common feeders and antennas can be used for
GSM and UMTS systems operating on the same system band. The solution will make
it possible to build an antenna line sharing site with uncompromised UMTS
performance and some effect on GSM/EDGE DL performance depending on the
number of TRXs per sector.
When MRC is used, all TX signals of GSM BTS need to be combined into one antenna
line when there are more than one TRX per sector. This is done with an additional
wideband combining stage, which introduces a 3.5dB loss to GSM downlink. MHA
must be used with MRC to maintain rx sensitivity of both BTSs.
MHA bias can be fed from either BTSs connected to the MRC. If WCDMA is added to
an exisiting GSM site already using a MHA, the GSM BTS continues feeding and
monitoring the MHA bias. In case MHA is only added to the site because of WCDMA
introduction with MRC, selection of MHA bias feed arrangement must be done
carefully - the BTS not feeding bias must allow MHA usage without bias feeding and
monitoring (e.g. supported with UltraSite EDGE BTS CX5.0CD2 onwards)

Hardware requirements: MRC unit can be installed to a std 19" mechanics or inside a
Flexi 2U casing (FTMA). When MRC is installed outside the 2G BTS, the cabling
between MRC and the two BTSs is done using cable kits found from current jumper
cable portfolio. In case of installing the MRC inside the UltraSite EDGE or CityTalk
BTSs, the needed installation kits include required jumper cables for MRC. When
using MRC and having Flexi WCDMA modules placed inside the UltraSite EDGE BTS
using the horisontal installation kit (FMUB), a special wideband combiner must be used
to perform the additional combining of GSM TX signals - this combiner also includes
the additonal interconnecting cables needed with it.

110 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release ON TOP - - WBTS4.0 - - - - - - -
OF RAS06 ED1
Note: Delivered on Top of RAS06.

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

6.1.8 FAGB Flexi Multiradio combiner for 2100MHz

Feature ID: RAN1462

Summary: Multi Radio Combiner for 2100MHz

Benefits for the operator: Enables sharing of one antenna system with two BTSs
operating on the band frequency band

Functional description: Multiradio combiner (MRC) makes it possible to use common


feeders and antennas for two WCDMA systems operating on the same frequency
band. This solution provides a cost efficient way to add new WDCMA BTS to an
existing site by combining signals of the two BTSs into one antenna system.
Using of MRC has minimal performance impact on WCDMA BTS. Low DL insertion
loss of 0.5dB means only minor performance degradation in transmit power. MRC
losses in UL path are compensated with a MHA and if the BTS supports an adjustable
front end gain (Flexi WCDMA BTS and UltraSite) the degradation of original sensitivity
is marginal.

Current implementation: Both BTSs needs own antennas, MHAs and feeders.

Interdependencies between features: This feature has no related or interworking


features.

Operational aspects: Common feeders and antennas can be used for 2 x UMTS BTS
operating on the same system band. The solution will make it possible to build an

DN0671022 Nokia Siemens Networks 111 (124)


Version 1.4.0
antenna line sharing site with minimum effect on existing BTS performance and with
maximized new BTS performance.

Hardware requirements: This is a new feature and unit, but this feature does not
require any new or additional HW. No new cable kits etc needed, all required jumper
cables can be found from current portfolio.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 - WBTS4.0 WBTS4.0 - - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

112 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
6.2 Common WCDMA BTS Site Solutions and
Features

6.2.1 Extended Cell (180km)

Feature ID: RAN1127

Summary: Cell radius extended up to 180 km.

Benefits for the operator: Economical method to build WCDMA coverage on rural
areas.

Functional description: 3G extended cell feature can be used to efficiently provide


coverage in coastal and rural area, where big capacity or high data rates are not
needed. Furthermore, new lower WCDMA frequency bands 850 MHz and 900 MHz
make it possible to achieve larger cell sizes and also utilize the existing GSM cell
raster.
The feature is needed also with optical repeater cases (train tunnels, FlexiBTS remote
RF heads) to overcome the decreased cell radius caused by the delay of optical
cables. BTS has the main functionality of this feature. The feature is activated from the
RNC/NetAct with Cell Range parameter. The operator has a possibility to modify Cell
Range Parameter up to 180 km.
In 3GPP, RACH/AICH detection & transmit power control delays define the cell range.
SW implementation support up to 180km cell range. The Extended Cell is verified up to
150 km in RAS06 case of 2-port receiver diversity. The feature activation is based on
SW licences.

Current implementation: Maximum cell range is 20km.

Interdependencies between features: This feature has no impact on other features.

Operational aspects: The basic principles for Extended Cell in WCDMA BTS are as
follows:
- A cell is called Extended Cell when its radius is >20km,
- Cells with radius 20 km are treated according to normal baseband dimensioning
rules,

DN0671022 Nokia Siemens Networks 113 (124)


Version 1.4.0
- CE dimensioning needs to be calculated separately for each Extended Cell. For
example, if there is a 1+1+1 configuration, with 1 * 20 km cell and 2 * 100 km cell, it is
needed to calculate 1* 20 km cell according to normal common channel dimensioning
rules and 2 * 100 km cells according to Extended Cell dimensioning rules,
- Extended Cell CE dimensioning rules are the same for all WCDMA frequencies,
- One or several of the cells in the BTS (supported configurations) can be configured
as Extended Cells.
Extended Cell common channel dimensioning in Flexi WCDMA BTS:
- Up to 60 km cell: 27 CE (UL/DL),
- Up to 120 km cell: 54 CE (UL/DL),
- Up to 180 km cell: 80 CE (UL/DL).
Extended Cell common channel dimensioning rules for UltraSite WCDMA
BTS are as follows, provided that every Extended Cell has its own WSPC:
- Up to 60 km cell: 16 UL / 16 DL CE,
- Up to 120 km cell: 40 UL/ 16 DL CE,
- Up to 180 km cell: 64 UL / 64 DL CE.

Hardware requirements: For UltraSite WCDMA BTS, it is advisable to have at least


one WSPC per Extended cell (+WSP for normal CCCH) for optimal CE consumption.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 RN3.0 WBTS4.0 WBTS4.0 - - OSS4.2 - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
ASW RAN RNC LK Long-term ON/OFF
licence

114 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
6.2.2 Pico WCDMA BTS with Ethernet Transport

Feature ID: RAN923

Summary: WCDMA Pico BTS is a very small indoor BTS. It has a single 5MHz carrier,
carrier frequency can be freely selected within the frequency band by SW and 2-way
receive diversity is supported. The antenna is integrated, it is possible to use also
external antennas.
Pico WCDMA BTS with Ethernet Transport interface has designed to be used together
with the IP transmission.

Benefits for the operator: The Pico WCDMA BTS is designed to enhance coverage
and capacity and serve an additional number of indoor users within a localized
coverage area.
For example, Pico WCDMA BTS can be used to cover white spots where no coverage
is supported by macro BTSs. It can also be used to provide added capacity in local
indoor hot spots and offices, and thereby improve the overall quality in the 3G RNW by
offloading the existing macro-based NW. It's also possible to build cost effcient large
indoor coverage solutions using Pico WCDMA BTS together with a small Distributed
Antenna System (DAS) which can typically include 4-8 antennas.
IP Transport gives operator savings in the transmission costs.

Functional description: The Pico WCDMA BTS is a low power, high capacity 3G
base station, intended for voice and high-speed data services in indoor environments.
The Pico WCDMA BTS is a complete Pico BTS unit with all functionalities in one single
hardware unit that is easy to install and maintain. The Pico WCDMA BTS operates on
a single 5MHz channel and it supports one carrier and one sector with SHO between
other BTSs in the RAN.
A complete Pico WCDMA BTS Pico BTS consists of:
* Support unit, including AC/DC converter,
* BTS unit,
* Internal antenna (optional),
* Cover.
WCDMA IP Pico BTS FUNCTIONALITY
WCDMA Pico BTS unit with IP connect capability. Transmission interface
10baseT/100baseT Ethernet connections from the Iub/LMT connector.
When using the BTS for IP Iub, then the physical Ethernet port of the unit will be used
for the connection between IP-BTS and the centralized functions as OMC and RNC.

DN0671022 Nokia Siemens Networks 115 (124)


Version 1.4.0
Remote management can be done either via NetAct or via a remote LMT (e.g. LMT
connected to Iub LAN). If there's a need to connect a LMT locally on-site, when the
Pico BTS is connected to IP transport, then the BTS console port must be used. The
BTS console port is a serial port which can be accessed from a PC via a standard
RS485 connector. If the PCs does not have built in RS485 ports then it si possible to
use converter between USB and RS485 interfaces.
High quality oscillator in BTS
The WCDMA Pico BTS relies on an oven controlled reference oscillator with the
following specifications:
* Frequency drift up to 100 ppb per year due to aging,
* Frequency drift up to 20 ppb due to temperature variations within Pico BTS
specification.
Since the requirements for a local area BTS is 100 ppb there is no need to
compensate for drift due to temperature variations.
However the BTSs reference oscillator needs to be compensated for drift due to aging
to keep frequency accuracy within 3GPP specifications.
Pico BTS with the IP Transport this is done with timestamps coming from the NTP
server.
Timestamp packet
The Network Time Protocol (NTP) is a standard which makes it possible to
synchronize the clocks of different devices over an Ethernet network.
To compensate the frequency drift due to ageing the Pico BTS will depend on access
to NTP server(s) located at the IP backbone.
The NTP server(s) used for WCDMA Pico BTS shall be of stratum level 2 or better.

Figure:

Current implementation: The current Pico WCDMA BTS offers the two ATM
Transport interfaces: E1/T1/JT1 and STM-1. This feature offers third options to the Iub
transport interfaces, IP transport in Ethernet.

116 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Interdependencies between features: This feature offers HW to Ethernet Tranpsort.
To make it an IP Pico BTS it must be used together with the RAN1594 Pico WCDMA
Release 2 SW.

Hardware requirements: This feature is a hw feature for IP Pico BTS.

Software dependencies:
RAS RNC BTS BTS BTS Pico AXC NetAct MSC SGSN MGW UE
Ultra Flexi
Release ON TOP RN3.0 - - WP2.0 - - - - - -
OF RAS06
Note: Delivered on Top of RAS06.

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

6.2.3 WMHD Mast Head Amplifier

Feature ID: RAN1309

Summary: WMHD Mast Head Amplifier is upgrade on WMHC.

Benefits for the operator: WMHD adds RET output connector and AISG controlling to
WMHC. Remote antenna tilt users saves RET bias-t and installing time.
RF-performance, outlook and price will reamain same as WMHC.

Functional description: The WMHD is a dual amplifier, referred to as a UNIT, which


comprises two identical amplifiers, referred to as LNA1 and LNA2. A general reference
for either LNA1 or LNA2 is MHA. Physically this means one enclosure with two BTS
and ANT ports, one MHA for both branches.
The purpose of the WMHD Standard Gain Dual Masthead Amplifier is to compensate
feeder losses with minimum over gain, and lowest possible noise contribution, the net
effect being to optimize WCDMA BTS receive path sensitivity.

DN0671022 Nokia Siemens Networks 117 (124)


Version 1.4.0
This product has fixed 12dB gain for both branches. Unit is designed for duplex
operation and this requires the use of duplex filters or a filter system within the unit to
provide transmit only path and receive only path through the LNA components.
The WMHD is capable to operate in AISG mode and current alarm mode.
Failure bypass is provided in case of LNA failure. The purpose of the failure bypass
mode is for the MHA to maintain RF signal pass even when a MHA alarm occurs or no
DC power is present. On power up or power recycle of the MHA, alarms will reset and
the unit shall attempt normal operation.
WMHD will also provide output to antenna tilt motor or other device via RET-connector
and additionally through ANT1 port.

Current implementation: WMHC is outdated, there is no AISG support & RET


connector

Interdependencies between features: RAN908

Hardware requirements: This is a new feature and unit, but this feature does not
require any new or additional HW.

Software dependencies:
RAS RNC BTS Ultra BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Pico
Release RAS06 - WBTS4.0 WBTS4.0 - - - - - - -

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

118 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
6.2.4 Pico WCDMA BTS Rel.2 SW

Feature ID: RAN1594

Summary: Pico WCDMA BTS Rel.2 sw main features are IP Transport and NetAct
support.
Pico WCDMA BTS Rel.2 sw can be used together with the following products:
- Pico WCDMA BTS with E1,
- Pico WCDMA BTS with STM-1,
- Pico WCDMA BTS with Ethernet.

Benefits for the operator: IP Transport option for the Pico WCDMA BTS offers a cost
efficient transmission for the indoor solution.
With NetAct support the operator doesn't need a separete network management tool
for the WCDMA Pico BTS's.

Functional description: Pico WCDMA BTS IP sw offers for the operator:


- IP Transport together with the ATM based RNC running RAS05 or RAS06 using
Transmission Gateway Unit TGU,
- Interoperability with NetAct,
- Enabling the operator to install the Pico WCDMA BTS units either:
* directly on the IP backbone (i.e. with public IP addresses),
* or behind firewalls protecting e.g. office LANs, home LAN or other kind of private
LANs.
- IP security protecting both the centralized UTRAN functions (RNC, OMC etc) and the
Pico WCDMA BTS units.
To enable connection to a RNC without IP interconnect a new transmission gateway
unit (TGU) will make the ATM/IP protocol conversion to the IP Pico WCDMA BTS.
IP SECURITY
In order to enable connection of WCMDA Pico BTS units via a public IP Network a
type of VPN client is implemented inside the BTS units; This VPN client will enable an
IPsec protected communication between the BTS unit and the centralized functions
like RNC and NetACt.
The VPN tunnels from the BTS units needs to be terminated in a Security Gateway
SGW located between the "public" IP network and the sensitive centralized functions
as RNC and OMC. The SGW will also act as a firewall in front of the RNC/TGU and

DN0671022 Nokia Siemens Networks 119 (124)


Version 1.4.0
the NetAct, thus protecting these sensitive centralized functions from intrusion and
attacks.
In order simplify management of the VPN connectivity, each BTS unit will establish two
VPN tunnels to the SGW:
- One tunnel for Iub C-plane (NBAP and ALCAP) and OAM,
- One tunnel for Iub U-plane (user plane signalling).
In the BTS each tunnel end-point will have a separate IP address, i.e. on protected
LAN inside of the SGW the BTS will appear have two different IP addresses. The BTS
IP address on the LAN/WAN where it is physically connected will not show up inside
the SGW; That IP address can either be achieved via DHCP or fixed assigned.
NETWORK TOPOLOGY
The figure shows the proposed network architecture for deployment of WCDMA Pico
BTS for IP Network. All other connections shown in the picture are IP connections
using e.g. Ethernet or Gigabit Ethernet.
The following network elements are shown in the figure:
* Pico BTS; WCDMA Pico BTS unit with IP interconnect.
* FW; Firewall protecting some kind of private LAN, e.g. a home LAN or office LAN. A
firewall is most probably using NAT for translating local addresses of the LAN to public
addresses used for the public IP backbone.
* SGW "Security gateway", protecting the RNC/TGU from the public IP backbone. The
SGW handles IKE negotiations with BTSs etc and terminates IPsec tunnels to the
BTSs.
* TGU; The transmission gateway unit (TGU) translates from the ATM based interface
from the RNC to the IP network protocols used for communication with the IP BTS. For
OAM of the TGUs they should be connected to an OAM LAN, where they can be
monitored from TGUM.
* TGUM; a tool for monitoring the state of one or more TGUs.
* RNC; a UTRAN radio network controller (RNC) with ATM interconnect capability the
BTSs.
* OMC Operating and Maintenance Center for OA&M of the UTRAN network, NetAct.
* LMT Local maintenance terminal, a SW tool for managing a single BTS at the time.
The LMT may either be run locally on-site, from OMC (via IPoA connections
terminated in RNC) or from a PC connected to the IUB LAN.
* DHCP Dynamic Host Configuration Protocol Server; which can be used by the nodes
to retrieve a local addresses on the different IP LAN or a public IP addresses for nodes
connected to the IP backbone.
* DNS server used by BTS to lookup e.g. IP addresses of NTP servers and other
public IP addresses needed by the BTS. IP addresses on Iub LAN or OAM LAN are
not handled via public DNS servers.

120 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
* NTP Time Server; used by BTS for time and frequency synchronization.
TRANSMISSION GATEWAY UNIT (TGU)
The IP network solution described herein has been designed to enable introduction of
IP transport to WCDMA Pico BTS units without having to modify the RNC.
This is solved by the introduction of the transmission gateway unit (TGU), which is a
translator between ATM based transmission protocols used by the RNC and the IP
based transmission protocols to the BTS.
In essence the TGU will (partly) hide the IP transport network for the RNC, though
some minor adjustments in the RNC may be needed (e.g. parameter settings and
timer settings)
The TGU is a protocol translator where
- For Iub C-plane it translates between ATM-AAL5 and IP-UDP,
- For Iub U-plane it translates between ATM-AAL2 and IP-UDP.
The transmission gateway unit TGU is based on a 2U compact PCI chassis.
This chassis holds:
- 1-4 TGU processing boards,
- 2 power supply modules (for redundancy),
- 2 fans (for redundancy).
Default configuration is 2 TGU processing boards per TGU.
Interfaces:
STM-1 Interface,
- 4 STM-1 interfaces in each processing board,
- Connector type: SC,
- Interface type: STM-1 155 Mbps, ITU-T G.957-S1.1.
Gigabit Ethernet interfaces
- 2 per processing board,
- Interface 0 is used for OAM,
- Interface 1 is used for IP-Iub.
Ethernet Interface
- Connector type: RJ-45,
- Interface type: Ethernet 1000 Mbps, 1000 BASE-T.
Serial link with RS232 electrical levels to connect to a console.
- Connector type: Mini-DIN-8,
- Interface type: RS232,

DN0671022 Nokia Siemens Networks 121 (124)


Version 1.4.0
- Configuration: 9600 baud, 8 data bits, No parity,1 stop bit, No flow control.
Power Interface
* Connector Type: IEC320 type C15
* Interface Type: 230V AC or 100V AC or 48 V DC, max 500W
TGU Capacity
Each TGU board can handle up to 65535 "connections" between ATM and IP, where
- Each AAL5 PVC consumes one connection.
- Each AAL2 PVC can consume up to 248 connections.
Note that each fully configured AAL2 PVC consumes 248 connections (one per
possible CID) regardless if these connections (CID) are in use or not.
The number of IP-BTS possible to connect to a TGU depends on how many
connections each IP-BTS requires:
- With 1 fully configured UserDataPort per BTS the capacity is 150 IP-BTS per TGU
board (not limited by "connections" but by throughput),
- With 2 fully configured UserDataPorts per BTS the capacity is 130 IP-BTS per TGU
board,
- With 3 fully configured UserDataPorts per BTS the capacity is 85 IP-BTS per TGU
board,
- With 4 fully configured UserDataPorts per BTS the capacity is 65 IP-BTS per TGU
board.

Figure:

122 (124) Nokia Siemens Networks DN0671022


Version 1.4.0
Current implementation: WCDMA Pico BTS has currently ATM transmission with E1
or STM-1 interface and management is done with the Pico specific tool.

Interdependencies between features: This feature has no related or interworking


features.

Hardware requirements: This feature does not require any new or additional HW from
the Pico WCDMA BTS. Releaes 1 ATM Pico BTS's can be used with this feature.

Software dependencies:
RAS RNC BTS BTS BTS Pico AXC NetAct MSC SGSN MGW UE
Ultra Flexi
Release ON TOP RN3.0 - - WP2.0 - - - - - -
OF RAS06
Note: Delivered on Top of RAS06.

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

6.2.5 UltraSite EDGE Wideband Combiner for WCDMA Refarming

Feature ID: RAN1670

Summary: The special UltraSite EDGE wideband combiner is a unit needed for
additional TX combining in 2G BTS when common antennaline sharing is done using
Multiradio combiner (MRC).
This special wbc unit is only needed when MRC is used and Flexi WCDMA modules
are placed inside the UltraSite EDGE cabinet using horisontal installation kit (FMUB).

Benefits for the operator: UltraSite EDGE multimode BTS solution can fully be
exploited in a WCDMA refarming application when MRC is used for common antenna
line sharing - all needed Flexi WCDMA modules and additional wbc required by MRC
can be fitted inside Ultrasite EDGE cabinet (new IDCA/ODCA versions). This does not
only lead to excellent cost and space efficiency, but also prevents risk for increased
site lease cost since no new cabinet is needed with WCDMA introduction.

DN0671022 Nokia Siemens Networks 123 (124)


Version 1.4.0
Functional description: Multiradio combiner (MRC) makes it possible to use common
feeders and antennas for GSM and WCDMA systems operating on the same
frequency band. This solution provides a cost efficient way to add a WDCMA BTS to
an existing GSM site by combining signals of the two BTSs into one antenna system.
MRC concept requires all TX signals of one BTS to be combined in one antenna
feeder. Therefore the dual duplex setup in GSM BTS, which is typically used when
having more than one TRX per sector, has to be removed and an additional wideband
combining stage needs to be added (not applicable with cavity combining).
When using MRC and having Flexi WCDMA modules placed inside the UltraSite
EDGE BTS using the horisontal installation kit (FMUB), the special wideband combiner
must be used to perform the additional combining of GSM TX signals. The new wbc is
placed to the baseband unit rack of the BTS.

Current implementation: Exisiting UltraSite EDGE wide combiners do not support the
additional TX combining required by MRC when Flexi WCDMA modules are placed
inside the UltraSite EDGE cabinet using the horisontal installation kit (FMUB).

Interdependencies between features: The special UltarSite EDGE wbc is only


applicable when MRC is used and Flexi WCDMA modules are placed inside the
UltraSite EDGE BTS using the hosrisontal installation kit (FMUB).

Hardware requirements: The special UltraSite EDGE wbc is only applicable when
MRC is used and Flexi WCDMA modules are placed inside the UltraSite EDGE BTS
using the horisontal installation kit (FMUB). FMUB is only supported by the new
version of IDCA/ODCA cabinets (ver.2xx onwards). The special wbc unit contains the
additonal interconnecting cables needed with it.

Software dependencies:
RAS RNC BTS BTS Flexi BTS AXC NetAct MSC SGSN MGW UE
Ultra Pico
Release ON TOP - - WBTS4.0 - - - - - - -
OF RAS06 ED1
Note: Delivered on Top of RAS06.

SW sales information:
OSW/ASW RAS SW component Licence control in Licence control
network element attributes
OSW RAN - -

124 (124) Nokia Siemens Networks DN0671022


Version 1.4.0