2G RG10 and RG20 features.pdf

7/22/2019 2G RG10 and RG20 features.pdf

http://slidepdf.com/reader/full/2g-rg10-and-rg20-featurespdf 1/152

Confidential © Nokia Siemens Networks 1 (69)

RG10(BSS) NF & FUD

New Features and Features UnderDevelopment

Ver 2.11.2

Confidential




The information in this document is subject to change without notice and describes only the product defined inthe introduction of this documentation. This document is not an official customer document and Nokia SiemensNetworks does not take responsibility for any errors or omissions in this document. This document is intendedfor the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the

document is submitted. No part of this documentation may be used, reproduced, modified or transmitted in anyform or means without the prior written permission of Nokia Siemens Networks. The documentation has beenprepared to be used by professional and properly trained personnel, and the customer assumes fullresponsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process ofcontinuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity or performance ofthe mentioned hardware or software products are given “as is” and all liability arising in connection with suchhardware or software products shall be defined conclusively and finally in a separate agreement between NokiaSiemens Networks and the customer.

IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL ORCONSEQUENTIAL OR ANY LOSSES SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE,BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA, that might arise from the use of thisdocument or the information in it.

THE CONTENTS OF THIS DOCUMENT ARE PROVIDED "AS IS". EXCEPT AS REQUIRED BY APPLICABLEMANDATORY LAW, NO WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUTNOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE AND NON-INFRINGEMENT, ARE MADE IN RELATION TO THE ACCURACY, RELIABILITY ORCONTENTS OF THIS DOCUMENT. NOKIA SIEMENS NETWORKS RESERVES THE RIGHT TO REVISETHIS DOCUMENT OR WITHDRAW IT AT ANY TIME WITHOUT PRIOR NOTICE.

This document and the product it describes are considered protected by copyrights and other intellectualproperty rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of NokiaCorporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they arementioned for identification purposes only.

Copyright © Nokia Siemens Networks 2010. All rights reserved.




Index

1 Summary of changes ............................. .............................. ............................. ......... 5

2 Introduction ............................ .............................. ............................. ......................... 9

3 BSC & TCSM Products ........................... ............................. .............................. ...... 12

3.1 BSC hardware requirements .............................................................................. 12

3.2 TCSM hardware requirements ........................................................................... 13

3.3 PCU hardware requirements .............................................................................. 13

3.4 BSC HW requirements for new ASW products .............................................. 13

3.5 Integrated IP card for BSC and TCSM .............................................................. 14

3.6 Asymmetrical PCU HW Configuration ............................................................. 15

3.7 Flexi BSC ................................................................................................................. 17

3.8 L3 Connectivity for Flexi BSC ............................................................................ 19

3.9 SDH/SONET Equipment Protection .................................................................. 21

3.10 SW Support of BS2xx@FlexiBSC Family ........................................................ 22

3.11 Flexi Multiradio HW Activation ........................................................................... 23

4 Radio Network Performance ............................ .............................. ......................... 24

4.1

Wideband AMR (WB-AMR) .................................................................................. 24

4.2 Wideband AMR support for TCSM3i ................................................................. 27

4.3 AMR HO Signaling Optimizations ..................................................................... 29

4.4 Tandem Free Operation (TFO) for AMR ........................................................... 30

4.5 A5/3 ciphering ........................................................................................................ 32

4.6 SDCCH and PS Data Channels on DFCA TRX ............................................... 33

4.7 AMR Unpacking Optimization ............................................................................ 34

4.8

105km Extended Cell ............................................................................................ 36

4.9 105km Extended Cell for GPRS/EDGE ............................................................. 38

4.10 Enhanced Satellite Abis Support up to 420ms .............................................. 39

4.11 Paging Coordination ............................................................................................ 40

4.12 Extended CCCH ..................................................................................................... 42

4.13 Extended BCCH ..................................................................................................... 43




4.14 Priority Based Voice Quality .............................................................................. 44

4.15 Merged P- & E-GSM900 ........................................................................................ 45

5 Interworking ........................... .............................. ............................. ....................... 47

5.1 Load Reporting via Iur-G ..................................................................................... 47

5.2 ISHO acceleration via Iur-G ................................................................................ 48

5.3 LTE System Information w/ MML support ....................................................... 49

6 Packet Switched Data ............................. ............................. .............................. ...... 51

6.1 Downlink Dual Carrier .......................................................................................... 51

6.2 PCU2 Acceleration ................................................................................................ 53

7 Operability ......................... .............................. ............................. ............................ 54

7.1 Energy saving mode for BCCH TRX ................................................................. 54

7.2 2G TRX Automatic Power Down ........................................................................ 55

7.3 Secure remote MMI ............................................................................................... 57

7.4 OSI over TCP/IP ..................................................................................................... 59

7.5 Automated RNW O&M log collection ............................................................... 61

7.6 Support of FlexiEdge PWE Counters ............................................................... 62

8 Transmission and Transport ........................... .............................. ......................... 64

8.1 FlexiEDGE Ethernet switching ........................................................................... 64

9 Value Adding Services ........................... ............................. .............................. ...... 65

9.1 Support for Real Time Road Traffic Information ........................................... 65

9.2 Support for Commercial Mobile Alert System (CMAS) ................................ 68

9.3 Blocking of DTMF in Downlink ........................................................................... 69




1 Summary of changes

DATE ISSUE EDITED SUMMARY OF MAIN CHANGESFCD (Feature Candidate Description)

18.05.2007 1.0.0 ReijoLyytinen

RG10(BSS) Program internal version


Approved version


The following features removed- BSS21184, 8k Abis for AMR/FR- BSS21109, Early UL TBF establishment- BSS20519, Proactive extended UL TBF

polling- Separate RLT for AMR DL and UL in

Optimizations10.12.2007 1.3.0 Frode

PaulsenThe following features removed

- Fast Ack/Nack Reporting- Packet Switched Handover (PSHO)- Support for MS Receiver Diversity

16.12.2007 1.4.0 FrodePaulsen

The following features added- AMR unpacking optimization- Automated RNW O&M log Collection- Asymmetrical PCU HW Configuration


The name of BSS20984 has been changed to- Flexi EDGE DTRX Automatic Power Down

The following features removed- Proactive DL TBF Establishment

For “Asymmetrical PCU HW Configuration”:“Functional Description”-Text improved.For “WB-AMR”:“Functional Description”-Text improved.For “WB-AMR support by TCSM3i”:“Functional Description”-Text improved.For “AMR TFO”:“Functional Description”-Text improved.Dependency Tables have been updated for thefollowing features:

- AMR HO Signaling Optimisations- AMR Unpacking Optimisations- Downlink Dual Carrier- Secure Remote MMI- OSU over TCP/IP




FUD (Features Under Development)14.03.2008 2.0.0 Frode

PaulsenThe following features removed from the document

- PCU Restart Handling

- Robust EDGE Retransmission- Improved Extended UL TBF

Chapter 2: Compatibility with other NEs has beenupdated.


The 2G – 2G part of the “Load Aware ISHOadmission” has been separated from the originalfeature and turned into its own feature “BSS30650Load Aware Inter-BSC HO Admission”.


The SGSN dependency for the DL DC feature hasbeen removed.


The PCU-2 Dependency to the ”BSS20097 Automated RNW O&M log collection” has beenremoved.


Removed from RG10(BSS):BSS21141 Load aware ISHO admissionBSS30650 Load aware inter-BSC HO admission


Added to RG10(BSS) :BSS21333 Support for Real Time Road Traffic Inform.


Preliminary Compatibility Tables have beenintroduced into chapter 1. Introduction

17.07.2008 2.3.0 Frode

Paulsen

The classification of ASW and Basic Feature has

been removed


Added to RG10(BSS) :BSS21149 Flexi BSC.


Added to RG10(BSS) :BSS21317 Full support of Append BTScommissioning.


Text modified/improved :BSS21149 Flexi BSC.

30.09.2008 2.6.0 Frode

Paulsen

New Feature introduced :

BSS21323 L3 Connectivity for Flexi BSC.30.09.2008 2.6.0 Frode

PaulsenText updated for :3. BSC & TCSM Products (changed from “tentative” to“actual”).


The Release name changed from “BSS14” to“RG10(BSS)”


New Feature introduced :BSS21234 Support of FlexiEdge PWE Counters.





Feature changed from “Public” to “Internal” :BSS21317 6.6 Full support of Append BTS commissioning .Note: The functionality is still supported, but not

handled/described as sales feature.18.01.2009 2.7.0 Frode

PaulsenCorrection :BTS dependency in the dependency table has beenremoved for the feature “BSS20916 AMR HOSignaling Optimizations".


Feature added to the FUD :BSS21108 SDH/SONET Equipment Protection.

27.02.2009 2.8.0 IsmoHonkalammi

Correction :BSC HW requirements have been updated


Correction :The Compatibility Matrixes in the “Introduction”chapter have been updated.


Added to the WB AMR description :Note that the ”WB AMR Capacity License” is requiredto enable more than 100 simultaneous calls per BSC.


Features added to the FUD :BSS21198 PCU2 AccelerationBSS21270 105km Extended Cell for CSBSS21277 105km Extended Cell for GPRS/EDGE.


Correction ::Compatibility Matrix corrected: Red color for OSS4.2

CD Set 1 with CX7 and EP3..09.09.2009 2.9.2 Frode

PaulsenCorrection ::The PCU2 dependency for “Asymmetrical PCUConfiguration” on page 11 has been removed..


New Features added :Network Evolution

BSS21538 Extended CCCHBSS21497 Enhanced Satellite Abis Support to 420ms Voice and DataBSS20738 Paging Coordination

InterworkingBSS21527 Load Reporting via Iur-GSite Solutions

BSS21469 SW Support of BS2xx@FlexiBSC Family(the introduction ch. has been adapted accordingly)


Dependency Tables have been updated :- BTSplus has been introduced as BTS type- BTS 2nd Gen. has been removed





Correction:Support of “Extended CCCH” for MetroSite BTS hasbeen corrected from “MP3.0” to “MP2.0” in the

dependency table15.04.2010 2.11.0 Frode

PaulsenFeature added.The Feature “Extended BCCH” has been added


Features added.BSS21403 Flexi Multiradio HW ActivationBSS101456 Priority based Voice QualityBSS21528 Iur-g interface phase 2BSS21529 LTE System Info. w/ MML supportBSS101422 Support for CMASBSS101443 Blocking of DTMF in Downlink BSS21238 Merged P-&E-GSM900


Dependency Tables have been updated :- Flexi MultiRadio has been introduced as BTS type- Talk Family BTS has been removed



2 Introduction

This document describes the feature candidates for the Base Station Subsystem (BSS)system release RG10(BSS).

Nokia Siemens Networks RG10(BSS) brings advantages for all operators by enablingamongst others

• Significantly improved voice quality by Wideband AMR

• Enhanced CS service security by new A5/3 Ciphering algorithm

• Doubled bit rates with EDGE evolution

• OPEX savings with low cost transport and BTS energy saving solutions

• OPEX savings with optimised BSC HW solutions

The standardisation baseline of RG10(BSS) release is 3GPP Release 7 September.

The compatibilities for individual NE releases are as follows:

RG10(BSS) consists of the releases: BSC S14, MetroSite CXM7, UltraSite CX7,FlexiEDGE EP3, BTSplus BRG1 and Flexi Multiradio EX3.1.Note :The latter would only be supported from the EP5.1 package of RG10(BSS).

RG10(BSS) is supported by the following NE releases: NetAct OSS5.1 CD set 2, MSCM14.4, MGW U4.2 and SGSN SG7 CD2

The basic BSC S14 software release will be compatible with Talk Family DF7 BTS softwarerelease, but the new RG10(BSS) features with BTS SW impact will not be supported by theTalk Family BTS.

From the S14 MP3.0 also the BTSplus (BTS types from the former BR systems) will besupported. This feature is called BSS21469 “SW Support of BS2xx@FlexiBSC Family.”

BSC SW release S13 will be the last compatible software level for the former Nokia InSiteBTS SW, so no support of RG10(BSS) is foreseen.




RG10(BSS) Compatibility Matrix

BSC BTSplus Talk UltraSite MetroSite Flexi EDGE LMURelease S12 S13 S14 BRx BRG1 DF6 DF7 CX5 CX6 CX7 CXM5 CXM6 CXM7 EP1 EP2 EP3 4.3 4.4 B1.0

S14

CXM7

CX7

EP3

OSS4.1 CD Set 2

OSS4.2

OSS4.2 CD Set 1

OSS5.1 CD Set 1

OSS5.1 CD Set 2

Release LMU4.3 LMU4.4

LMU-B

1.0

S14

CXM7

CX7

EP3

MSC MGW (with MSC-S) SGSN RNC

Release M12 M13 M14.3 M14.4 U2 U3A U3B U3C U4.1 SG5.1 SG6 SG7 RN2.2 RN3 RN4

S14

w/o

WB

AMR

Legend :

Compatibility not applicable

Compatibility not supported

Secondary compatibility

Primary compatibility

Notations used in dependency tables:

The table is used to relate the described BSS features to required systemcomponents:

BSS BSC DX200Platform

BTSUltraSite

BTSMetroSite

BTSFlexiMultiR

BTSplus BTSFlexiEDGE

NetAct SGSN MSC RAN MS

Release - - - - - - - - - - - - -




In the table we use the following notations:SUPPORTED IN:

MSCThis feature is supported in the Nokia MSC (xxx =Nokia Siemens Networks MSC release/featureno) N = No, - = no dependency, X = supportrequired but release not defined.

NokiaSiemensNetworksMetroSite

This feature is supported by Nokia SiemensNetworks MetroSite BTS (xxx = Nokia SiemensNetworks release/feature no) N = No, - = nodependency, X = support required but releasenot defined.

NokiaSiemensNetworksNetAct

This feature is supported in the Nokia SiemensNetworks NetAct (xxx = Nokia Siemens Networksrelease/feature no) N = No, - = no dependency, X= support required but release not defined.

NokiaSiemensNetworksInSite

This feature is supported by Nokia SiemensNetworks InSite BTS (xxx = Nokia SiemensNetworks release/feature no) N = No, - = nodependency, X = support required but releasenot defined

BSC This feature is supported by the BSC (xxx = NokiaSiemens Networks release/feature no) N = No, - =no dependency, X = support required but releasenot defined...

NokiaSiemensNetworksUltraSite

This feature is supported by Nokia SiemensNetworks UltraSite BTS (xxx = Nokia SiemensNetworks release/feature no) N = No, - = nodependency, X = support required but releasenot defined

SGSNThis feature is supported by the SGSN (xxx =Nokia Siemens Networks release/feature no) N =No, - = no dependency, X = support required butrelease not defined.

NokiaSiemensNetworksFlexiEDGE

This feature is supported by Nokia SiemensNetworks FlexiEDGE BTS (xxx = Nokia SiemensNetworks release/feature no) N = No, - = nodependency, X = support required but releasenot defined

NokiaSiemensNetworks2nd Gen.

This feature is supported by the 2nd gen BTS.(xxx = Nokia Siemens Networks release/featureno) N = No, - = no dependency, X = supportrequired but release not defined.

MS The feature sets special requirements to mobilestations (xxx = 3GPP release), - = nodependency, X = support required but releasenot defined.

NokiaSiemensNetworksTalk-family

This feature is supported by Nokia SiemensNetworks Talk-family BTS (xxx = Nokia SiemensNetworks release/feature no) N = No, - = nodependency, X = support required but release notdefined.

HW/FW DEPENDENCY:

NokiaSiemensNetworksPrimeSite

This feature is supported by Nokia SiemensNetworks PrimeSite BTS (xxx = Nokia SiemensNetworks release/feature no) N = No, - = nodependency, X = support required but release notdefined.

BSCHW/FW

This feature requires additional or alternativeBSC hardware or firmware

DX200Platform

This feature is supported by DX200 Platform (xxx= Nokia Siemens Networks release/feature no) N= No, - = no dependency, X = support required butrelease not defined.

BTSHW/FW

This feature requires additional or alternativeBTS hardware or firmware

TC HW/FW This feature requires additional or alternativeTranscoder hardware or firmware

SGSNHW/FW

This feature requires additional or alternativeSGSN hardware or firmware

Operating/ Application

BSS SOFTWARE: Indicates whether this feature is an Operating or

Application SW feature




3 BSC & TCSM ProductsThe S14 level HW requirements were confirmed at E2 (P5) milestone and have alsobeen communicated with the BSC HW Technical Note 174.

3.1 BSC hardware requirementsOn top of Flexi BSC and BSC3i also BSCi and BSC2i will support the S14 SWrelease. Some functionality – like Integrated IP card – will be available only for FlexiBSC and BSC3i 1000/2000 (and additionally for TCSM3i).

The S14 release sets a mandatory HW requirements for the minimum memorycapacity of CPU units in computer units of M98 mechanics BSCs This means there is

a need to extend the memory configuration of BSC3i from S13 level:BSC3i 660 and 1000/2000: 512 MB in BCSU, 1 GB in MCMU and OMU.

BSCi and BSC2i: 512 MB in OMU, MCMU and BCSU.

Flexi BSC has 1 GB in all units as standard.

Minimum Hard Disk size remains same as in S13.

The typical minimum O&M link capacity requirements remain the same as in S13:

BSCi, BSC2i, BSC3i 660: minimum 256 kbit/s, recommended 512 kbit/sBSC3i 1000: minimum 512 kbit/s, recommended 1024 kbit/s

BSC3i 2000: minimum 1024 kbit/s, recommended 2048 kbit/s

Please note that deviations to the figures might exist due to the implications such asnumber of managed objects under BSC, activated features, customer-specific datacollection settings or work processes.

LAN-based O&M connection is currently recommended to all product configurationsand most powerful link option method. Alternatively also digital X.25 connection is

still feasible when multiple 64 kbit/s timeslots are used. However, LAN interfaces aremandatory with higher than 1024 kbit/s data speeds. As with earlier S13 SW releaseanalog X.25 connection with limited link capacity is no longer available with BSC3i1000/2000 configuration + with Flexi BSC only LAN based connection is supported.

Please note also that in BSCi and BSC2i O&M LAN interface requires IP cabling andCPLAN panels as well as external LAN switches and/or routers.

Note : For information on required EPROM upgrades with RG10(BSS) please refer tothe RA Maintenance Status Update issued 16.11.2010 by Jan Jensen with the title:“GSM/EDGE reminder of new EPROM ordering procedure (RG10/S14 upgrades)”




3.2 TCSM hardware requirementsOn top of TCSM3i also TCSM2 will support the S14 SW release. New transcodingrelated Application SW (like Wideband AMR) will be supported only by TCSM3i.

3.3 PCU hardware requirements All existing PCU units (PCU1, PCU2) can still be used with the basic S14 SWrelease. Please note, that all new packet data related application SW (listed below)will require PCU2.

3.4 BSC HW requirements for new ASW products

As with previous SW releases certain application software products set additionalrequirements for BSC hardware. HW requirements for new S14 Application SW(ASW) Products are listed in the following table:

PCU2 plug-in unit is mandatory HWrequirement for:

• Downlink Dual Carrier

Table 1 BSC HW requirements for S14 Application SW products




3.5 Integrated IP card for BSC and TCSM

Feature ID : BSS21157

Summary : This feature integrates the IP/Ethernet interfaces into BSC3i 1000/2000 Abisand Ater- and TCSM3i A- and Ater-interfaces. An ETIP1 plug-in unit, based on CircuitEmulation Service over Packet-Switched Networks (CESoPSN) technology, is equippedin place of an E1/T1 or STM-1/OC-3 unit to provide the IP connectivity. This solutionenables flexible integrated product configuration options between these transmissiontechnologies.

Benefits for the Operator : Transport in GERAN networks is today based mainly onE1/T1 PCM lines. Several backhaul transport technologies are in use besides the nativeE1/T1, like microwave radios, SDH rings/point-to-point connections, ATM etc.

IP based transmission is widely seen as a cost efficient alternative to reduce operabilitycosts, allows easy expansions and is predicted to be even more efficient in future. IPnetworks are or will be readily available in many markets.

IP/Ethernet based transmission is especially suitable as common transport for 2G/3Gsites.

Lower OPEX and IMPEX can be achieved because there is no need for externaltransmission units and no need to use BSC’s interfaces to connect to this equipment.Fast implementation is assured as cabling, power supply etc. issues can be discarded.Integrated solution offers additionally higher reliability, lower power consumption andintegrated O&M via NetAct.

BSC & TCSM HW Requirements : TCSM3i or BSC3i 1000/2000 or Flexi BSC

Dependency Table :BSS BSC DX200

Platform BTSUltraSite

BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 B13 - - - - - - - - - -




3.6 Asymmetrical PCU HW Configuration


Summary : Asymmetrical PCU HW configuration allows operator to add and activatePCU HW in granularity of one and according to traffic needs.

Benefits for the Operator :Optimized and more space and cost efficient PCU HW configuration

Functional Description : Asymmetrical PCU HW configuration allows the operator to add and activate PCU HW ingranularity of one and according traffic needs.

PCU HW is installed into the BSC in granularity of one (+ required amount of PCU HWinto the spare BCSU). BCSUs are equipped with PCU HW units according to trafficneeds, i.e. PCU HW units are added to BCSUs one by one until the full PCU HW unitamount is reached in the BSC.

Asymmetrical PCU HW configuration introduces a definition of the primary spare BCSU.With Asymmetrical PCU HW configuration the primary spare BCSU is configured to haveenough PCU HW units to take over any of the active BCSUs. The system will keep theprimary spare BCSU as the spare BCSU by performing related BCSU switchovers assoon as the BCSU statuses allow this. A related alarm is raised if the primary spareBCSU unit is not in SP-EX state.






BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 - - - - - - - - - - -




3.7 Flexi BSC


Summary : The Flexi BSC name refers to the full support of the Flexi EDGE BTS and itsfuture evolution and also to full the flexibility in the Flexi BSC's capacity and connectivitydimensioning. Flexi BSC is engineered to provide remarkable capacity and low powerconsumption in one single cabinet design.

Benefits for the Operator :Every aspect of this product contributes to high operational efficiency. This BSC offers anew level of capacity efficiency to the marketplace by being the only BSC to support3000 TRXs in one cabinet and to provide the highest traffic handling capacity with 18000Erlang. Additionally it offers a fully integrated solution to provide IP/Ethernet for allinterfaces, which will further strengthen the potential of the Flexi BSC – the full flexibilityin configuring different transmission media will enable the operator to select the mostcost efficient alternative.

Functional Description :The new Flexi BSC configuration will support very high TRX configurations up to 3000TRXs in very compact one single cabinet solution. The cabinet configuration will beflexible from 500TRX to 3000 TRXs in 6 capacity steps. Together with the CircuitSwitched traffic support configuration it will support Packet Switched traffic amounts upto 30 720 Abis links (16kbit/s). The Flexi BSC is based on the DX200 distributedprocessor platform, which efficiently evolves with the commercial Intel processing power

and distributed architecture to new requirements – this applies to the capacity as well asto the functional evolution. All earlier delivered BSC3i configurations can be upgraded tothis latest specification.




Figure:

Dependency Table :BSS BSC DX200Platform

BTSUltraSite

BTSMetroSite

BTSFlexiMultiR

BTSInSite

BTSFlexiEDGE


Release RG10(BSS) S14 - - - - - - OSS5.1CD

SET 2

- - - -




3.8 L3 Connectivity for Flexi BSC


Summary : From S11.5 onwards, the BSC IP Connectivity solution /D/ requires L2/STPinteroperability between ESBs and Multilayer Site Switches. This could reduce thereliability of the IP connectivity and also cause additional complexity in configuring theconnections. This feature removes the L2/STP interoperability requirement. Then BSC IPConnectivity can be integrated to operator backbone without special IP requirements.

Benefits for the Operator :L3 Connectivity gives a more stable and easy-to-configure network compared to usingL2 connectivity.

Functional Description :The L3 Connectivity feature makes BSC IP integration easier for the operator IPbackbone and simplifies ESB configuration. L3 Connectivity is activated by configuring IPaddress/route. Thus, the problematic L2 spanning tree configuration step is not neededfor enabling BSC IP Site Connectivity (in the Multilayer Site Switch).L3 Connectivity means that multilayer functionality from Multilayer Site Switch istransferred to L3 ESB such as MSTP root, virtual gateway and routing. Then, theMultilayer Site Switches are operating as Site Routers from BSC point of view.In the previous (S13) L2 solution, one or several BSC and Multilayer Site Switchesconstitute one spanning area, e.g. called to MSTP region.In the L3 solution, each BSC site has its own MSTP region. Thus Multilayer SiteSwitches and BSCs are not controlled by the same spanning tree. Spanning tree is not

needed to be enabled in Multilayer Site Switch due to BSC.




Figure:

MSTP Region

MSTP Region

MSTP Region

MSTP Region

MSTP Region

IP backbone

BSC

L3 ESBs

L3

L3

L3

L3

L3

L2L2

L2

L2

L2

L2

L2

L2BSC

L2 ESBs

L2 and L3 sites

BSC application and Ethernet interface point of view, there is no need to do configuration

changes (IP addressing and routing).



BTSMetroSite

BTSFlexiMultiR




SET 2

- - - -




3.9 SDH/SONET Equipment Protection


Summary : A highly reliable and redundant transport connection between the network elements is ofmajor importance for any operator and his business. This becomes even more importantwith STM-1/OC-3 interfaces because of the high capacity of one optical fibreSDH Equipment Protection is standardized solution and compatible with other supplier’sequipment in a multivendor environment.

Benefits for the Operator :In spite of an eventual drop out of one transmission interface unit the connectionbetween the network elements will sustain, thus preventing a break down in the mobilenetwork traffic and corresponding revenues and subscriber satisfaction.

Functional Description :Equipment protection is in addition to the 2N line redundancy (MSP 1+1 optical)supported with the BSC3i configuration. Equipment protection fulfills the resiliencyoptions for various operator needs. It brings full 2N equipment redundancy for opticalinterface units (ETS2).

BSC & TCSM HW Requirements : The Flexi BSC Family or TCSM3i for combined

BSC3i/TCSM3i installation.



BTSMetroSite

BTSFlexiMultiR




SET 2

- - - -




3.10 SW Support of BS2xx@FlexiBSC Family


Summary :So far the BTS types BTSplus or the BS24x, BS4x, BS288 and BS82 II have only beencompatible with the BSC types BSC72/BSC120/eBSC. With this feature these BTS typescan also be used together with, and controlled by, the FlexiBSC family.

Benefits for the Operator :The introduction of the new FlexiBSC can be deployed in areas where the BTS typesBS24x, BS4x, BS288 and BS82 II are being used. Moreover, these BTS types can becombined with the BTS types FlexiEDGE, Metro Site, Ultra Site, etc. in a common BSCarea controlled by one OSS system via NetAct.

Functional Description :The BS2xx SW, Abis interface and BTS/BSC functional split have been adapted to theFlexiBSC. Moreover, where relevant the FlexiBSC functionality has been extended toalso support the legacy BS2xx functionality.

BSC & TCSM HW Requirements : The Flexi BSC Family and TCSM3i (or a MGW) arerequired.



BTSMetroSite

BTSTalkFamily



Release RG10(BSS) S14MP3.0 AndPCU2

- - - - BRG19-40

- OSS5.1CD

SET 2

- - - -




3.11 Flexi Multiradio HW Activation


Summary :The BSS system will hereby also support this new Flexi Multiradio BTS type that is alsocapable to run (beyond 2G/GSM) 3G and LTE radio standards.

Benefits for the Operator :The same HW can be (re)used for different radio network technologies like GSM, UMTSand LTE thus saving OPEX and CAPEX.

Functional Description :This BTS can work standalone in either one technology or in sharing mode, sharingGERAN with LTE, GERAN with 3G, or 3G with LTE. The shared modules inside the BTSare Radio Modules (RM). The system modules (for GERAN ESMB system module andfor 3G & LTE FTM system module) are not shared and thus the M-plane functionalitiesare not impacted.

The Flexi Multiradio wil support all the BSS features except:• Combined O&M and Telecom signaling• Extended Cell - Long Reach TSL (FlexiEDGE BTS)• 105km Extended Cell (FlexiEDGE BTS)• Extended Cell for GPRS/EDGE• 105km Extended Cell for GPRS/EDGE• Double Power TRX for Flexi EDGE BTS i

BSC & TCSM HW Requirements : The Flexi BSC Family is required.



BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14EP5.1

- - - EX3.1 - - OSS5.1CD

SET 2

- - - -




4 Radio Network Performance

4.1 Wideband AMR (WB-AMR)


Summary : Wideband Adaptive multi rate (WB AMR) brings voice communication to newera with a new speech codec family. Audible improvements include warmer and clearertone due to extended bandwidth towards both lower and higher frequencies.

Wide Band Adaptive Multi-Rate (WB-AMR) uses a twice as high sampling rate comparedto current voice services in mobile and fixed line telephony. Together with highersampling frequency the transcoding algorithms are improved as well in WB-AMR.Furthermore audio capabilities of current handsets e.g. with integrated MP3 players arewell ahead of AMR quality, thus motivating to improve voice service capabilities as well.

WB-AMR codec set supported by BSS consists of 12.65, 8.85 and 6.60 kbps codecrates, which are currently the same as in WCDMA RAN.

Benefits for the Operator :Increased revenue expected by longer and more frequent voice calls.

Improved end user experience: WB-AMR provides significant speech qualityenhancements compared to AMR, fixed line telephony or xDSL VoIP. Even musicapplications are possible through enhanced audio bandwidth. With clear audibleenhancements, MS to MS conversations will become more transparent and callers will

feel like being closer to each other. Furthermore the transmission of the finer nuances ofthe human voice will make communicating more complete.

As soon as the end-user has once experienced this quality, he will most likely not bewilling to change back to non-WB-AMR anymore if a choice is being offered. With WB-

AMR mobile voice calls will be used more frequently and continue longer. WB-AMR willboost wire-line to mobile substitution and provide advantages towards the competitionfrom emerging voice technologies e.g. VoIP over xDSL.

For dual mode operators WB-AMR provides also service continuity between WCDMAand GSM and enhances the probability to establish a WB-AMR call. Thus WB-AMR willsupport the "2G network to complement 3G" strategy of the operator.

Functional Description :

The Wide Band Adaptive Multi-Rate codec (AMR-WB) was developed by 3GPPincluding 5 codec rates ranging from 6.6 to 23.85 kbps and including rate adaptationmechanisms as in AMR.

Audio sampling rate of 16000 samples per second, linked with WB specific algorithmsenhances audio frequency band to 50 Hz - 7000Hz for WB-AMR, which is significantincrease compared to 300 Hz - 3400Hz frequency band for existing voice services e.g. inG.711 or AMR. This new sampling rate restricts the use of WB codec to MS to MS calls.

According to listening tests further quality gains from higher WB codec modes than 12.65




are seen small, thus set of three codecs i.e. 6.6, 8.85 and 12.65 carried with GSMmodulated channel are to be supported by RG10(BSS).

Like in AMR, the codec mode can be chosen based on the radio conditions, yielding tooptimal audio performance through rate adaptation. The codec mode can be changedevery 40 ms in GSM. The codec also includes a source controlled rate adaptationmechanism, which allows it to encode speech at a lower average rate by taking speechinactivity into account.

WB-AMR requires end to end TFO (Tandem Free Operation) support, because downsampling in transcoding would invalidate WB properties of sound. If TFO is not possibletranscoding to G.711 is used, and the G.711 restricts the audio frequency range to 300 -3400 Hz. Indeed e.g. in inter PLMN WB-AMR calls it needs to be ensured that thetransport chain is transparent to carry TFO.

WB-AMR transcoding functions will be available in the NSN Media Gateway (MGW) with Ater-support. Alternatively feature BSS21218 offers WB-AMR support for TCSM3i.

Figure : WB AMR makes voice warmer and makes the speaker appear closer

BTS HW : Edge MetroSite TRX is needed for this feature. UltraSite Edge Baseband unit(BB2E or BB2F) is needed for this feature

MSS:For this WB AMR feature ( BSS20960) : NSN Rel-4 Core. i.e. MSC Server with MGW.For Rel 99 core networks please use the BSS21218 Wideband AMR support for TCSM3i

MS: WB-AMR capable MS required

Important logis t ical NOTE : This feature item (BSS20960) is valid for up to 100

G.711

300-

3400

WB

AMR

50-

7000

Hz

Nuances

Presence

Warmth




simultaneous calls in total on one BSC and is being sold per TRX supporting it. Theadditional item BSS21312 "Wideband AMR Capacity License" is required for additionalcapacity in steps of 100 simultaneous calls per BSC up to max 16 steps per BSC. Afterthis limit the additional steps are FOC.



BTSMetroSite

BTSFlexiMultiR




EP5.1

- CX7.0 CXM7.0

EX3.1

BRG19-40

EP3.0 OSS5.1CD

SET 2

- U4.2M14.4

- Rel5

*) Quality based NB WB is not supported.




4.2 Wideband AMR support for TCSM3i


Summary : This feature adds Wideband AMR (WB-AMR) support for TCSM3i.

Benefits for the Operator : This feature provides the same general benefits as theBSS20960 WB-AMR feature with the NSN MGW, and may additionally be used togetherwith other vendor’s standard compliant core networks with either Rel99 (e.g. NSNCS5.0) or Rel4 architectures, as long as they support WB-AMR.

Additionally it protects investments to the new TCSM3i far into the future.

Functional Description : This feature provides WB-AMR by transcoder TCSMS3iconnected to the GSM/EDGE core network via the standardized A-interface.

Figure:

BSC & TCSM HW : TCSM3i


MS: WB-AMR capable MS required

Impo rtant logis t ical NOTE : To allow faster rollout, this feature item (BSS21218) isvalid for up to 100 simultaneous calls in total on one BSC and is being sold per TRXsupporting it. The additional item BSS21312 "Wideband AMR Capacity License" isrequired for additional capacity in steps of 100 simultaneous calls per BSC up to max 16steps per BSC. After this limit the additional steps are FOC.






BTSMetroSite

BTSFlexiMultiR




EP5.1

- CX7.0 CXM7.0

EX3.1

BRG19-40

EP3.0 OSS5.1CD

SET 2

- U4.2M14.4

- Rel5




4.3 AMR HO Signaling Optimizations


Summary : This feature optimizes HO signaling for AMR in order to reduce the call droprate for intracell handovers. The number of intracell handovers may increase with theutilization of HR.

Benefits for the Operator : CAPEX savings by reducing call drop rate for intracellhandovers.

Functional Description : FACCH channel used for signaling is less robust for poor radioconditions than the most robust AMR codecs (i.e. AFS4.75) thereby limiting the coverageand capacity gains that can be achieved with AMR. One way of increasing signalingperformance is to reduce the size of signaling messages in such a way that one L3message fits e.g. into one L2 frame.

Possible redundant information, e.g. unnecessary frequency information elements, isremoved in intra-cell handovers. The speed to perform intra cell handovers or AMRpacking/unpacking is improved.

MS: AMR capable MS required


Platform BTSUltra

Site

BTSMetro

Site

BTSFlexi

MultiR

BTSplus BTSFlexi

EDGE


Release RG10(BSS) S14 - - - - - - - - - - -




4.4 Tandem Free Operation (TFO) for AMR


Summary : This feature enhances the BSS support of TFO to also include AMR inaddition to the existing FR and EFR support. It applies to both the TCSM3i and the NSN(ex-Nokia) Ater-in-MGW solution. Tandem Free Operation (TFO) is intended to avoid thetraditional double speech encoding/decoding (G.711 <->AMR) in MS to MS (2G) or MSto UE (2G/3G), and thereby improving the voice quality and potentially reducing thetransport capacity need inside the core network.

Benefits for the Operator : CAPEX and OPEX savings by lowering bandwidth and costsfor core network links towards BSC

Operator can protect core network investments through common (Rel4) core network forWCDMA and BSS. Operators can obtain substantial savings in Rel4 core networktransmission capacity e.g. 4 times more voice calls can be provided, if TrFO/TFOInterworking is used between the core nodes.

Functional Description : TFO for AMR-FR and AMR-HR will be supported for calls thatare within the same network or to another GSM / UMTS network that supports TFOversion 6.3. With either AMR-FR or AMR-HR at the local end the TFO can be used witha GSM AMR-FR, GSM AMR-HR or UMTS-AMR2 (narrowband AMR) call at the remoteend.

To ensure TFO compatible operation with best voice quality in all these cases the 3GPPrecommended AMR narrow band configuration is used, with fixed modes of 12.2, 7.4,5.9, 4.75 kbit/s for AMR-FR and fixed modes of 7.4, 5.9, 4.75 kbit/s for AMR-HR.Note: AMR-FR <-> AMR-HR call in TFO keeps the AMR-FR radio channel, so that the




TFO is available while keeping the optimum radio channel setup at both ends of the call.In this case the AMR-FR side is constrained to only use the 3 lower codec rates, whichmatches the AMR-HR codec set.

If WB-AMR is also used in the network then the Immediate Codec Type optimization willensure that AMR-WB call with TFO is used if both ends of the call support the AMR-WBoperation.

The existing TFO for the GSM FR, EFR and HR codecs is still supported, as TFOversion 0.0 operation, so that if both ends of the call use the same (FR, EFR or HR)codec then TFO is used. This TFO operation is a separate feature from the AMR TFOoperation and can be active in a network at the same time as AMR TFO operation, butthere is no TFO operation if one end (local or remote) of a call is using AMR and theother end (remote or local) is using FR, EFR or HR codec.

TFO vs. TrFO:Tandem Free Operation (TFO): call configuration where a transcoder device is physicallypresent in the signal path, but the transcoding functions are bypassed. TFO uses in-bandsignaling for control. In-band TFO provides no direct saving of transmission costs, bute.g. proprietary G.711 removal schemes may be used.

Transcoder Free Operation (TrFO): call configuration where no transcoder device isphysically present and hence no control or conversion or other functions associated withit are activated. TrFO is currently specified only for WCDMA and not for GSM Radio andis thus not applicable to RG10(BSS). TrFO uses out-of-band signaling for control. TrFOprovides direct transmission savings in core network.


MS: AMR capable MS required



BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14

EP5.1

- CX7.0 CXM7.0

EX3.1

BRG19-40 EP3.0 OSS5.1CDSET 2

- SR3.1U4.2M14.3

- X




4.5 A5/3 ciphering


Summary : A5/3 is a new, more secure; 3GPP standardized ciphering method and isbased on the same core algorithm as used in WCDMA. Ciphering is performed by theBTS. BSC selects the ciphering algorithm based on the information received from theMSC and the information about allowed and supported algorithms in the BSS and MS.

Benefits for the Operator : A5/3 gives the possibility to use more secure cipheringmethod over radio interface.

Functional Description : A new, more secure ciphering method has been standardizedand is advised to take in use to replace the A5/1 algorithm. A5/3 is based on Kasumi F8which is also used in WCDMA RAN.Ciphering is performed by the BTS burst by burst. The BSC selects the cipheringalgorithm based on the information received from the MSC and the information aboutallowed (and supported) algorithms in the BSS.

In the BTS, the A5/3 algorithm will be supported only by the EDGE BB of the TRX,because in EDGE BB has enough DSP capacity for this feature. Therefore, the BSCmust check if the TRX is A5/3 capable before selecting the ciphering algorithm. BSC willuse the BB Unit Type parameter, which was added to the Abis O&M interface in S13.

Note: Current standardization sets a restriction for changing ciphering algorithm duringDTM reallocation. DTM Assignment Command message does not include Cipher ModeSetting IE before 3GPP Rel-7 and that's why ciphering algorithm could not be changedfor Rel-6 MSs during reallocations between EDGE TRXs supporting A5/3 and GPRSTRXs supporting A5/1. For Rel-6 MSs ciphering mode shall be changed with assignmentprocedure, which means leaving the DTM mode for a while. A Rel-7 MS will indicate itssupport for ciphering mode change during DTM assignment procedure.

BTS HW: Edge MetroSite TRX is needed for this featureUltraSite Edge Baseband unit (BB2E or BB2F) is needed for this

Operational Aspects : In BTS SW the support for A5/3 is included in the same SWpackage with A5/1.

MS: A5/3 capable MS required. For DTM Rel 7 MS is required with support for cipheringmode change during DTM assignment.

Dependency Table :BSS BSCS DX200


BTSMetroSite

BTSFlexiMultiR




EP5.1

- CX7.0 CXM7.0

EX3.1

BRG19-40

EP3.0 OSS5.1CD

SET 2

- U4.1M14.3

- X




4.6 SDCCH and PS Data Channels on DFCA TRX


Summary : The gains from the feature Dynamic Frequency and Channel Allocation(DFCA) introduced in BSS11.5 can be fully exploited by also supporting the SDCCH andGPRS/EDGE channels in the DFCA layer. No separate planning for additional non-DFCA TRX is then required which saves frequency bands significantly.

Benefits for the Operator: CAPEX savings by improved data and radio networkperformance; i.e. more capacity when DFCA gains to its full potential. SDCCHcapacity is no more limited to regular TRXs.OPEX savings by no need for separate planning for additional non-DFCA TRX.

Functional Description : The current DFCA feature can handle only Circuit Switched(CS) traffic and thus Packet Switched (PS) layer and CS layer must be separated(different TRXs). As PS traffic is increasing it often requires more than one TRX (BCCH)which consumes frequencies from dynamic DFCA layer and decreases spectralefficiency, and causes some extra needs for planning/management as well.

With this extension to the DFCA feature it will be possible to assign SDCCH and PStraffic also to DFCA TRXs. Then it would be only BCCH TRX that remains out of DFCA'sreach. PS territory would upgrade and downgrade freely over TRXs without DFCArelated restrictions. Similarly, both static and dynamic SDCCH channels would bepossible in DFCA layer.

BTS HW: MetroSite EDGE TRX is needed for this feature.UltraSite EDGE Baseband unit (BB2E or BB2F) is needed for this feature.

SW Prerequisite: DFCA feature (BSS11052) is needed.

Dependency Table :BSS BSCS DX200


BTSMetroSite

BTSFlexiMultiR




EP5.1

- CX7.0 CXM7.0

EX3.1

N EP3.0 OSS5.1CD

SET 2

- - - -




4.7 AMR Unpacking Optimization


Summary :This feature provides new AMR quality and handover parameters to avoid uselessunpacking in intracell FR/HR handovers.

Benefits for the Operator :CAPEX savings and improved network quality by reducing drop call rate.


Optimal functionality of unpacking is very important for AMR. To further optimizeunpacking two new parameters are introduced in HO algorithm.

1. Lower RX level thresholds for quality based intra cell handovers

If RX level is below this threshold then AMR unpacking, packing and interferencehandovers (the new type) are not allowed.

In case of rapid field strength drop, quality also typically drops. This easily triggers AMRunpacking handovers. If the field drop is high enough quality goes such bad that themobile cannot possibly decode the handover assignment, thus the mobile cannotperform HO. Normally radio link timeout timer controls the time how long the mobile canbe unreachable before the TCH is deactivated and the call is seen as a drop. This canbe e.g. 16 seconds. But when a handover is started is used a fixed 6 seconds timer tocontrol handover success. If the MS does not answered during this time eithersuccessful or not successful handover, the BSC deactivates the target channel and alsothe source channel. This is a drop. So without an intracell handover start the MS haveabout 10 seconds more time to get out off bad coverage.2. Lower quality threshold to prevent interference and AMR intracell handovers

If the quality is on that level or worse then intracell quality based HOs are not started.

Basically this is the same thing than the level limit but based on quality. When the MSmoves around a corner it can happen that it's own RX level is not changing but theinterferer gets rapidly a lot stronger. This can cause that the MS quality drops to e.g. 7thlevel. In the 7th level can easily happen that the MS fails SACCH decoding and hencecannot identify any handover assignment request. Consequences of this are then thesame as when a handovers is started in rapid field drop case.

The same filtering windows sizes are used for level and quality.




MSC: 3GPP Rel5 TS 48.008 compliancy required for information transfer from BSS/RANto RAN/BSS.



BTSMetroSite

BTSFlexiMultiR




SET 2

- X - -




4.8 105km Extended Cell


Summary :This feature enhances the Extended Cell function through extending the cell radius fromthe existing maximum of 70 km to up to 105 km. It is supported by the BTS Base Stationand is for CS Services only.

BSS21270 “105km Extended Cell for GPRS/EDGE” complements this feature andprovides a similar capability for PS Services.

Benefits for the Operator :This feature allows operators to serve larger coverage areas from the BTS (such ascoastal or very sparsely populated regions).

Current Implementation :With the existing BSS13 feature, support for Extended Cells up to a maximum radius of70 km is provided.

For this implementation, an Extended Cell is served by two “types” of TRX (N-TRX andE-TRX):

• N-TRXs serve the Normal coverage area

• E-TRXs serve the Extended coverage area

The N-TRXs provide coverage up to a maximum distance of 35 km from the BTS. The

position (and thus overlap) of the 35 km wide extended coverage area (served by the E-TRXs) may be adjusted as required. Consequently, the outer limit of the extendedcoverage area is between 35 km and 70 km from the BTS.

For an E-TRX, the timing of the receiver is delayed in relation to the transmitter so thatthe TRX can serve the area beyond the normal cell range of 35 km. The receiver delay isconfigured at the BTS according to the required cell radius extension. The maximumdelay introduced corresponds to a time of approximately 40% of a single timeslot. Note,however, that from the transmission perspective there is no timing (or other) differencebetween an N-TRX and E-TRX. The MS listens to the BCCH, which is provided by oneof the N-TRX in the cell, regardless of whether the MS is moving in the normal orextended coverage area of an Extended Cell.


Feature BSS21277 builds upon the principles employed for the up to 70 km extendedcell ranges and provides support for reaches up to 105 km from the BTS. This isachieved through delaying TRX reception (in relation to TRX transmission) of up toapproximately 80% of a single timeslot. Here, in addition to the N-TRX and E-TRX, theSuperextended TRX (or S-TRXs) is employed.

In an Extended Cell, the BTS observes and uses the Timing Advance (TA) parameter toreport the distance an MS has moved into a coverage area to the BSC.

The timeslots of an S-TRX are configured in the same way as those of an E-TRX. The(up to) 80% reception delay introduced means that the S-TRX RACH (E-RACH) overlapsonly with timeslots 0 and 1 of the N-TRX on the same frequency and therefore theexisting N-TRX configuration does not need to be changed:




• The E-RACH occupies TSL 0 of one S-TRX per extended cell. The timeslotaccommodating the E-RACH is tuned to the same frequency as the timeslotaccommodating the BCCH/RACH in order that it can receive access burststransmitted by an MS in the super extended coverage area. The Downlink direction ofthe E-RACH timeslot is unused - The BCCH (of the N-TRX) serves all three coverageareas.

• It is preferable that TSL 1 of the E-RACH S-TRX is configured as SDCCH. Forthe case of a TRX failure, the SDCCH would also be swapped across to the new TRX.

• TSL 1 of the BCCH N-TRX is unused, since its reception overlaps with that ofthe E-RACH timeslot on the same frequency.

The remaining six timeslots of the E-RACH S-TRX can be used for user traffic.

Only the BCCH BTS of an Extended Cell may accommodate E-TRX(s) and S-TRX(s).

As indicated above, in order to achieve continuous Extended Cell coverage and smooth

MS movement between coverage areas, all three TRXs (N-TRX; E-TRX and S-TRX)must be configured into a Super Extended Cell. It is also very important that adjacentareas of the Extended Cell overlap. This ensures:

• That excessive switching between adjacent areas of an Extended Cell is alleviated

• The MS can move between coverage areas without service interruption

Within a Super Extended Cell, it is possible to configure S-TRXs without E-TRXs,however, there would then be a discontinuity between the normal and super extendedcoverage areas since intra-cell handovers between the normal and super extended areaare not possible.

Triggering of intra-cell handovers between the different cell areas is based on the Timing Advance (TA) reported by the BTS and the MAX/MIN parameters. An intra-cell handoverbetween the normal and super extended area is not possible since these two areas donot overlap with one another.

External handovers (from 2G or from 3G) are performed either to the super extendedarea or to the actual cell area where the mobile is located - if the Long Reach TSL(FlexiEDGE BTS) feature is activated.


Platform BTSUltra

Site

BTSMetro

Site

BTSFlexi

MultiR

BTSplus BTSFlexi

EDGE


Release RG10(BSS) S14MP3.0

EP5.1

- N N

EX3.1

N EP3.0MP2.0

OSS5.1CD

SET 2

- - - -




4.9 105km Extended Cell for GPRS/EDGE


Summary :This feature enhances the Extended Cell function through extending the cell radius fromthe existing maximum of 70 km to up to 105 km. It is supported by the Flexi EDGE BTSBase Station and is for PS Services only.

BSS21277 “105km Extended Cell (FlexiEDGE BTS)” complements this feature andprovides a similar capability for CS Services.

Benefits for the Operator :This feature allows operators to serve larger coverage areas from the BTS (such ascoastal or very sparsely populated regions).

Functional Description :The PS timeslot (EGTCH) configuration rules for S-TRXs are the same as those for E-TRXs. (E)GPRS channels (EGTCH) are manually configured for S-TRXs and constitutea fixed EGTCH territory, which cannot be utilized for CS traffic. Also, the constituenttimeslots cannot be dynamically moved between the CS and PS territories.

During radio resource allocation, the PCU allocates resources to an MS to either an S-TRX; E-TRX or N-TRX depending upon the MS location - the PCU has either alreadystored the coverage area information of the MS or determines it through the access burstreceived from the MS.



BTSMetroSite

BTSFlexiMultiR




EP5.1

- N N

EX3.1

N EP3.0MP2.0

OSS5.1CD

SET 2

- - - -




4.10 Enhanced Satellite Abis Support up to 420ms


Summary :So far satellite services have caused ca. 300ms one-way delay to transmission paths(used mainly in Abis). Due to the (transport) network technological evolution (DynamicBW allocation", "Optimized TDM via packets" and "Local Switching") the satelliteenvironment has changed and we might face delays up to 400ms.

Benefits for the Operator :Support of Satellite Abis links can be guaranteed, even with the extended delays causedby the new transport network technologies.

Functional Description :Comprehensive tests have been carried out to verify that our BSS system can tolerateup to 420ms delays on the Abis interfaces..



BTSMetroSite

BTSFlexiMultiR




- - - - N - - - - - -




4.11 Paging Coordination


Summary :BSC performs Paging Coordination between PS and CS internally without DTM and Gsinterface (i.e. in NMO II). BSC forwards all CS paging messages to the PCUs; the PCUwhich finds the MS (IMSI) in packet transfer state initiates the paging procedure to thecells belonging to the paging area.

Benefits for the Operator :The subscribers will be pageable for CS calls also when connected in PS mode withoutdeploying NMO I and DTM support E2E and therefore without implementing Gsinterface.

The Paging Coordination implementation brings improved paging success rate(reduction of lost pagings). Therefore it consequently offers to the operators thepossibility to achieve higher ARPU, less help desk calls, and reduced churn rate.

In comparison with the other alternative solution (Full DTM and Gs support) PagingCoordination introduces CAPEX and OPEX savings.

Current Implementation :Currently, in NMO II mode, the GPRS core network and the BSC do not provide CSPaging coordination. Both the CS and PS paging requests are sent to the MS on CCCHpaging channel (PCH). This means that, if a DTM-capable MS is in packet transfer

mode, it does not necessarily monitor the PCH channel and, therefore, does not respondto the CS paging.

Only in NMO I it is the core network that provides Paging Coordination so that CS pagingrequests to GPRS-attached MSs are sent to the PCU via the SGSN. This requires Gsinterface between MSC and SGSN. The PCU then provides CS paging on the PACCHchannel if the MS is in packet transfer mode. If the MS is in packet idle mode, it is pagedfor a CS call on the PCH channel.

Functional Description :With the Paging Coordination the MSC sends a CS paging request to the BSC whichthen broadcasts the paging request further to the PCUs. When a PCU receives a CSpaging, the PCU examines whether it has a TBF for the given IMSI. If the PCU does nothave a TBF for that IMSI, then the PCU just ignores the CS paging request message.Otherwise, it sends a PACKET PAGING REQUEST message to the MS on the PACCHchannel, if the MS is in packet transfer mode, and initiates a paging procedure on thosecells that belong to the given paging area (MCC + MNC + LAC + CI). The CS pagingrequest message contains the IMSI of the mobile.

If the MS is in packet idle mode and if there is a PCCCH in the cell, then the MS is CSpaged on PPCH. In other cases, the MS is paged on PCH.

BSC HW Prerequisite: PCU2 or PCU2E





PlatformBTSUltraSite

BTSMetroSite

BTSFlexiMultiR


SGSN MSC RAN MS


- - - - - - - - - -




4.12 Extended CCCH


Summary :This feature adds more radio time slots for the CCCH use e.g. in larger BTSconfigurations or heavily loaded cells. Especially, increased use of PS servicesintroduces plenty of CCCH load per user.

Benefits for the Operator :This feature improves paging success rate and makes call establishments shorter,especially in congested cells. Also network optimisation becomes leaner since otherdimensioning tasks e.g. LA/RA downsizing can be avoided.

Current Implementation :Up to now only single CCCH channel could be supported.

Functional Description :Extended CCCH feature increases CCCH channel capacity in the cell up to four CCCHtimeslots in total. Extended CCCH channel allocated in time slots 2, 4 or 6 contains oneBCCH block and 9 CCCH blocks presented in figure 4.12.1.

Figure 4.12.1. TDMA frame mapping for FCCH + SCH + BCCH + CCCH/9

MS: The handset must be capable of allocating up to 4 TS for CCCH.



BTSMetroSite

BTSFlexiMultiR




EP5.1

- CX7.0MP3.0

CXM7.0

MP3.0

EX3.1

BRG19-40

EP3.0MP3.0

OSS5.2

CDset 1

- - - X




4.13 Extended BCCH


Summary :TD-SCDMA GSM IW leads to long SI messages which have to be split up into severalmessages. Thus the UE needs more time to read them; and that means more time forHO and Update. To reduce the time to read such long SI messages on the GSM sidethis feature will bring more space for SI by increasing the number of BCCH subchannelsfro one to two.

Benefits for the Operator :Extended BCCH feature reduces time of handovers and update by reducing amount ofindividual SI 2 quater messages.

Current Implementation :Up to now only one BCCH subchannel was available.

Functional Description :With the Extended CCCH feature operator can define new BCCH channel to the timeslot 0. This new BCCH channel type contains of BCCH block, extended BCCH block and8 not combined CCCH blocks. Following picture presents TDMA frame mapping for thenew CCCH channel. Only SI2quater system info messages are sent on 2nd BCCHsubchannel. SI2quater sending is moved from normal BCCH to extended BCCHsubchannel..

Figure 4.13.1. TDMA frame mapping for FCCH + SCH + BCCH/2 + CCCH/11



BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14EP5.1 - CX7.0MP3.0 CXM7.0MP3.0 EX3.1 BRG19-40 EP3.0MP3.0 OSS5.2CD

set 2

- - - -




4.14 Priority Based Voice Quality


Summary :HR or AMR HR can be allocated for lower tariff users.

Benefits for the Operator :Operator may provide voice quality per subscription e.g. for providing flat rate voice tariffwhile quality for normal tariff is not compromised.

Current Implementation :Up to know the conditional allocation of HR was based on load situation or service typeonly. With this feature also the priority of the subscriber will be considered.

Functional Description :BSC allocates, independently of network load, HR or AMR HR for users indicating pre-emption vulnearibility (PVI=Y).

Unpacking of AMR HR to AMR FR can either be prevented, allowed normally or allowedwhen packing load threshold is not yet exceeded. This can be controlled with UTPFILparameter.



BTSMetroSite

BTSFlexiMultiR




- CX7.0MP3.0

CXM7.0MP3.0

EX3.1 BRG19-40

EP3.0MP3.0

tbd - - - -




4.15 Merged P- & E-GSM900


Summary : A number of P-GSM / E-GSM feature enhancements have already been provided inearlier software releases. This feature complements these through combining the P-GSM and E-GSM frequency bands into one and removing the specific handlingpreviously required for P-GSM only handsets.

Benefits for the Operator :This new feature introduces an improved spectral efficiency through the merging of theP-GSM and E-GSM Bands. Furthermore, the general operability of the network isimproved and simplified.

Functional Description :Originally, PGSM900 and EGSM900 resources were managed separately andconfigured as separate cells within the BSC, with handover support between them. Overlater software releases (BSS11.5, BSS12 and BSS13) a number of enhancements wererealised in order to increase the integration of the two frequency bands.

In former releases, PGSM900 and EGSM900 frequencies can be used within a singleBTS object and support for PGSM-only handsets has been maintained. However, incases where the BCCH carrier of a PGSM900-EGSM900 BTS is on the PGSM900frequency band there are currently operational aspects that must be considered, whichwould be unnecessary if all GSM900 handsets in the network also supported theEGSM900 band.

These operational aspects are:• It is possible to combine PGSM900 and EGSM900 frequencies only in the BCCH

BTS and with such a BCCH BTS it is not possible to employ GSM900 frequencies inany other BTS object of the segment

• It is not possible to use RF Hopping and (E)GPRS on the same TRX• Baseband Hopping cannot be employed• It is not possible to use super reuse TRXs• DFCA Hopping cannot be employed• Static SDCCH resources must be configured for the PGSM900 TRXs• The BSC limits the dynamic reconfiguration of SDCCHs to be within the PGSM900

TRXs

• The BSC limits the actions of FACCH setup to be within the PGSM900 TRXs• The feature High Speed Circuit Switched Data is not supported

It would no longer be necessary to consider these if it can be assumed that all GSM900handsets in the network support EGSM900. This is the basis for this feature, MergedPGSM900 and EGSM900, which complements the existing PGSM900-EGSM900 featureenhancements, combining the two frequency bands into one and removing the specifichandling previously required for PGSM-only handsets. The feature then eliminates theabove operational aspects.

Note that generically for GSM systems, the maximum number of available GSM900

frequencies in a PGSM900-EGSM900 segment is 16 (17 if ARFCN 0 is included).




This feature represents the final step in a series of enhancements that have beenintroduced.



BTSMetroSite

BTSFlexiMultiR




- CX7.0MP2.0

CXM7.0MP2.0

EX3.1 BRG19-40

EP3.0MP2.0

tbd - - - -




5 Interworking

5.1 Load Reporting via Iur-G


Summary :Iur-G is an IP based interface that provides a logical connection between two BSCs orbetween a BSC and an RNC. It supports the exchange of load information, which can beused to either triggering handovers.

Benefits for the Operator :With this load reporting via new Iur-G interface the inter-working between 2G and3G/TD-SCDMA can be improved, for example: * unneccessary handover attempts can be avoided and related signaling through coreNW can be reduced* inter RAT ping-pong effect can be reduced* success rate of critical handovers can be improved

Current Implementation :Without this feature handovers may be directed towards overloaded cells.

Functional Description :This feature enables direct IP interface between BSC and TD-RNC network elementscalled Iur-g. The signalling protocol is based on 3GPP RNSAP extended by some TD-SCDMA specific modifications.

From possible Iur-g procedures, this feature contains basic Iurg-procedures and RNCinitiated load reporting from BSC to RNC. RNC may initiate reporting for set of cellsunder interest, where the reporting type can be either 'On Demand', 'Periodic' or 'Event'.

In order to facilitate load reporting BCS needs to measure cell load in terms ofpercentage of free radio time slots from total capacity.

Based on the load information from BSC, RNC may choose the best target cell to triggerthe 3G->2G handover.



BTSMetroSite

BTSFlexiMultiR




- - - - - - - - - - -




5.2 ISHO acceleration via Iur-G


Summary :BSC allocates TCH resource for incoming ISHO in advance based on request sent byTD RNC via Iur-g.

Benefits for the Operator :Inter-system handover from 3G to 2G duration is decreased and this may improvedropped call rate

Functional Description :RNC initiates enhanced relocation procedure by sending Enhanced Relocation ResourceRequest message to BSC over Iur-g interface. According to information included in therequest BSC allocates TCH. BSC also allocates unique D-RNTI that is associated toallocated TCH and sends response that includes D-RNTI and Handover Command toRNC over Iur-g interface. When RNC receives response it sends simultaneouslyHandover Command to mobile and Relocation Required message with D-RNTI includedto MSS. MSS sends Handover Required message (D-RNTI is included) to BSC. BSCidentifies pre-allocated TCH with D-RNTI and does not allocate TCH again but sendsHandover Acknowledgement to MSS and connects A interface to pre-allocated TCH.When mobile appears to pre-allocated channel BSC sends Handover Complete to MSS.

At this phase relocation from 3G to 2G has been completed.



BTSMetroSite

BTSFlexiMultiR




- - - - - - tbd - - - -




5.3 LTE System Information w/ MML support


Summary :GSM/EDGE - LTE Interworking consists of several possible mobility procedures:

Figure: Possible GSM/EDGE - LTE Interworking Mobility Procedures.

The RG20 (BSS) Release supports LTE Interworking through the LTE SystemInformation feature, which enables the operator to introduce neighbouring LTE cell andparameter information into the BSS. Once configured, Handsets will then be able toexecute an autonomous Cell Reselection from a GSM cell to an LTE cell (when theHandset is in either the idle state or packet idle state)..

Benefits for the Operator :This feature provides the basic interworking capability with LTE, enabling coveragecontinuity and thus an improved end user experience in multi-RAT networks

Current Implementation :Without this feature .

Functional Description :The RG20 (BSS) Release supports LTE Interworking through the LTE SystemInformation feature, which enables the operator to introduce neighbouring LTE cell andthe relevant parameter information into the BSC.

Up to eight adjacent LTE cells may be configured per GSM cell. The LTE neighbour cell

parameters of the cell are defined in 3GPP Rel.8 standards and when the Handset is inidle mode they are indicated to the Handset via their inclusion in system information type2q messages on the BCCH Channel.

A number of new parameters are defined for the handling of the LTE Cells, includingthose for the following:

• MCC; MNC• Carrier Frequency• Handling of Barring of LTE Cells• Prioritisation• Levels for Reselection

• Etc…




Once the relevant cells and parameters have been configured then Handsets would beable to execute an autonomous Cell Reselection from a GSM cell to an LTE cell (whenthe Handset is in either the idle state or packet idle state).

Two potential solutions are being considered in order to provide Voice Call Continuityfrom LTE to GSM/EDGE:

• CS Fallback - where Voice Services / Emergency Calls are directed from LTEtowards GSM/EDGE through an Inter System NACC capability (please refer toBSS21355 for more details)

• Single Radio Voice Call Continuity (SRVCC) - where the Core Network translates theVoIP Call across as an incoming CS voice Handover for GSM/EDGE

The NetAct support for this feature will be provided by RG20(BSS), in RG10(BSS) it will

be managed by means of MML command .



BTSMetroSite

BTSFlexiMultiR




- - - - - - N - - - -




6 Packet Switched Data

6.1 Downlink Dual Carrier


Summary : This feature enables the possibility to allocate radio slots in two separate DLcarriers for one user in the same cell.

Benefits for the Operator : CAPEX and OPEX savings by doubling downlink throughputall over the cell area for improved service continuity with LTE or HSPA. Increasedrevenues and end user experience by streaming of high quality video exploiting the latest

video capabilities of handsets.

Downlink Dual Carrier (DLDC) also significantly increases the resource efficiency(up to 160%) due to the trunking gain .

Functional Description : In a downlink dual carrier configuration, radio resources areassigned to a single MS on two radio frequency channels. One of these channels can bee.g. the in BCCH carrier and other in a TCH with frequency hopping.MS receives both radio frequency channels, thus DL throughput can be doubled. In theUL direction the MS may dynamically alternate between the carriers, to maximizeutilization of uplink resources.

The feature doubles downlink peak throughput up to 592 kbps. The average throughputcan exceed 300kbps which enables e.g. streaming of high quality video.




With this feature it is possible to add more PS users in the network to experience e.g.100 kb/s as shown in figure.

Operational Aspects : Abis may need re-dimensioning to support higher bit rates.

BSC HW: PCU2

MS: GPRS/EDGE capable Rel-7 MS

Dependency Table :


BTSUltraSite

BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 - - - - - - - - - - 3GPPRel-7




6.2 PCU2 Acceleration


Summary : This feature reduces the PING delay for PS services and shortens thelatency by 20 ms.

Benefits for the Operator : Enhanced end-user experience by faster responses for PSservices. It also contributes to bridging the performance gap between 2G and 3G / LTE

Functional Description : The inter process communication in the PCU2 has beenimproved by halving the reading cycle of the internal protocol buffers. This results in asubstantial latency gain, which is applicable to all existing MS types. The first PING timeis reduced to 470ms.

Figure: Ping delay roadmap for the BSS releases

BSC HW: PCU2

Dependency Table :


BTSUltraSite

BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 - - - - - - - - - - -

239

208

191

169

206

186

166

140

0

100

200

300

BSS11.5 BSS12 BSS13 RG10

ms

AverageMinimum

PCU2 AccelerationFlexi EDGE BTS

PCU2

Measured values for 32B PINGExtended UL TBF




7 Operability

7.1 Energy saving mode for BCCH TRX


Summary : This feature introduces a new configurable power saving mode for BCCHTRXs in Flexi EDGE BTSs and in UltaSite BTSs.

Benefits for the Operator : Lower network OPEX by reduced energy consumption.

Functional Description : With Energy Saving Modes for BCCH TRX the dummy burstson idle timeslots of the BCCH carrier are transmitted at 2 dB lower power level, and theBSC will use 2 dB dynamic power control on circuit switched TCHs in the BCCH TRX.

Together these feature (BSS20958 and BSS20984 Automatic (scheduled) Power Down))give reduced electricity consumption throughout the whole day. Also the Energy savingmode for BCCH TRX feature can be set according to the time of day, so that (forexample) it is active overnight, during the period of low traffic.

Figure :

Current Implementation : This is a new functionality

BTS HW : Edge UltraSite TRXs or FlexiEDGE is needed to support this feature






BTSMetroSite

BTSFlexiMultiR




EP5.1

- CX7.0 N

EX3.1

N EP3.0 OSS5.1CD

SET 2

- - - -

7.2 2G TRX Automatic Power Down


Summary : This feature introduces new energy saving mechanism for FlexiEDGE BTS.With this feature operator can shutdown Dual TRX to save energy (electricity) during thelow traffic periods. The shutdown is controlled by the current load situation.

Benefits for the Operator : Lower network OPEX by reduced energy consumption.

Functional Description : Feature brings in functionality to shutdown TRXs. During thelow traffic hours the BSC can take the TRX out of service and command the Flexi EDGEBTS to turn off the -48V supply to the Dual TRX.

Estimated Power Saving for Dual TRX is around 40 Watts. The feature can be used forconfiguration where is there more than one Dual TRX in a cell.

Estimated power savings in different configurations:Flexi EDGE BTS 4+4+4 shutdown to 2+2+2 120 WattsFlexi EDGE BTS 6+6+6 shutdown to 2+2+2 240 WattsFlexi EDGE BTS 8+8+8 shutdown to 2+2+2 360 WattsFlexi EDGE BTS 12+12 shutdown to 2+2 400 Watts

This feature can be utilized in Flexi EDGE BTS configurations were there are 2-6 DualTRXs (3 ... 12 carriers) in the cell.

Interdependencies between Features : Feature cannot be utilized for DTRXs that have

Baseband Hopping or Antenna Hopping enabled

BTS HW: This feature requires Flexi EDGE BTS



BTSMetroSite

BTSFlexiMultiR




EP5.1

- N N

EX3.1

N EP3 OSS5.1CD

SET 2

- - - -




7.3 Secure remote MMI


Summary : Secure Shell protocol (SSH) could be utilized in remote BSC MML sessions.

Benefits for the Operator : Enhanced risk management and OPEX savings by improvedO&M network security.

Functional Description : Telnet is replaced with SSH (Secure Shell) protocol in MMLinterface (MMI)SSH protocol provides encryption, integrity protection and server authentication, whichimproves the security of MML interface. Especially the user names and passwords arenot delivered in clear text any more.Integrity protection and server authentication prevents manipulation of MML commandsduring the transfer.

Figure :




Current Implementation : Telnet is supported in remote man to machine interface(MMI).

Interdependencies between Features : When this feature is turned on, Telnetconnection cannot be used anymore in BSC MML sessions.



BTSMetroSite

BTSFlexiMultiR




SET 2

- - - -




7.4 OSI over TCP/IP


Summary : This feature introduces TCP/IP protocol support for BSS O&M Interfacesbetween NetAct and BSC and for the interface towards Cell Broadcast Center (CBC).

Benefits for the Operator : Reduced CAPEX and OPEX due to the TCP/IP usageinstead of ISO IP routers.

Functional Description : Feature introduces tunneling the Q3 based BSC - NetActinterface inside TCP/IP. This feature removes the need for using ISO IP routers in DCNNetwork. Licenses for these kinds of OSI routers are expensive compared to today’sTCP/IP routers.

With this feature the 3 routers indicated in the figure below (current situation) will no

more be needed::

This feature brings changes to functionality that is at the moment responsible for data divisionbetween digital X.25 and LAN (ISO IP). With OSI over TCP implementation all IP traffic comingfrom OMU Ethernet port is pure TCP/IP. This means:

– extra router (Cisco 2811) for OSI traffic tunneling is not needed – simplifies BSC site IP configuration – no dependence on Cisco routers any more – O&M Security can be enabled

▪ can be utilized with IPSec feature• OSI traffic comes also through TCP/IP stack of OMU

▪ Improves handling of usernames & passwords of OSI services – O&M redundancy

▪ Existing BSC site IP implementation is redundant. It can be fullyutilized

TCP/IP based interface can also utilized now towards Cell Broadcast Center.




Current Implementation : O&M interface is based on 'OSI based interface' where PCMor ISO IP can be utilized

BTS HW Requirements : None.



BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 B13 - - - - - OSS5.1CD

SET 2

- - - -




7.5 Automated RNW O&M log collection


Summary : This feature introduces new logging functionality in BSC.

Benefits for the Operator : OPEX saving due to faster troubleshooting time

Functional Description :Storing of Radio Network Fault Data.This feature stores all relevant RNW specific operations in BSC into the log file in theOMU's disk.

RNW O&M operations which will be log are:o initializationo recovery

o TRX swapo SI sendingo lock/unlocko conf data sendingo BCF/BTS/TRX reseto system restarto BCSU/PCU restarto BVC creation/deletion/state changingo Gb up/downo plan activation

In fault cases the operator can now sends the log file to Nokia Siemens NetworksTechnical Support for fault tracing.

Begin of RNW specific operation BSC program block writes to the log detailedinformation about operation. This is fingerprint what the system is going to do. Onlyrelevant information is written into the log which helps fault tracing. After RNW operationhas been executed BSC program block writes to the log how operation was succeeded.

Also all error situations are written into the log. So fault solving is easier when we cantrace from every single operation what was planned and how it was succeeded.



BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 - - - - - - - - - - -




7.6 Support of FlexiEdge PWE Counters


Summary : New counters are introduced to monitor Flexi EDGE BTS Pseudo WireEmulation transmission plug-in unit.

Benefits for the Operator : OPEX savings by improved PWE optimization capabilitiesbased on statistics.


The Pseudo Wire Tunnel BTS Measurements report the performance data about thePseudo Wire (PW) functionality in BTS and BTS supervised units in PW mode.The data is reported in the Q1 Supervision Block (SB) level and collected from every unitin PW mode at BTS supervision.

These counters have been added to the PW Tunnel measurements:

118000 RECEIVED PW PACKETSNumber of received PW packets containing erroneous and non- erroneous packets.

118001 TRANSMITTED PW PACKETSThe total number of transmitted PW packets.

118002 LOST PW PACKETSNumber of lost PW packets. The PW packets that are dropped during packetprocessing or got lost during transport at the PSN.

118003 EARLY PW PACKETSNumber of received PW packets outside sequence number window due to early arrival.

118004 LATE PW PACKETSNumber of received PW packets outside sequence number window due to late arrival.

118005 AVERAGE OF PACKET DELAY VARIATIONThe average of jitter buffer packet delay variation.

118006 MAXIMUM OF PACKET DELAY VARIATIONThe maximum of jitter buffer packet delay variation over measurement period.

118007 MINIMUM OF PACKET DELAY VARIATIONThe minimum of jitter buffer packet delay variation over measurement period.

The TRE Ethernet Measurements report performance data about the functionality of theEthernet interface in a BTS. The data is reported in Q1 Supervision Block (SB) level. Thedata is collected from every BTS with a transport plug-in unit supporting Ethernettransport interface.

These counters have been added to the TRE Ethernet measurements:

119000 RECEIVED ETHERNET FRAMESNumber of received Ethernet frames containing erroneous and non- erroneous frames.

119001 ERRORED ETHERNET FRAMESNumber of received errored Ethernet frames.




119002 TRANSMITTED ETHERNET FRAMESNumber of transmitted Ethernet frames

119003 RECEIVED ETHERNET OCTETS

The number of octets in valid frames received on the interface119004 TRANSMITTED ETHERNET OCTETS

The number of octets in valid frames sent on the interface



BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 - N N N N EP3.0 OSS5.1

CDSET 2

- - - -




8 Transmission and Transport

8.1 FlexiEDGE Ethernet switching


Summary : With Ethernet Switching on the FlexiEDGE plug-ins FIQA and FIYA it ispossible to use more than one Ethernet Interface; currently two FE´s and one GE areavailable. Thereby external IP/Eth equipment/networks can be connected, such as DCN(Data Communication Network).

Benefits for the Operator : Additional equipment with IP/Eth interfaces can beconnected to the FlexiEDGE BTS 2nd FE/ GE interface, e.g. DCN for BBU, Webcam,shelter monitoring etc.

Also user traffic from another IP/Eth BTS could be connected and bundled to oneEthernet stream without being QoS aware.

Functional Description : The existing Ethernet switch on FIQA and FIYA has beenenhanced by a SW upgrade. There is no traffic shaping as 3G BTS is responsible for thisfunction (in case of co-siting). There is no QoS based switching as management capacityneeded for site equipment is assumed to be low, resulting in low switching interference.There is no VLAN based switch, as VLAN tagging is seen responsibility of FlexiBTS, siteequipment.



BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 - - - - - EP3.0 - - - - -




9 Value Adding Services

9.1 Support for Real Time Road Traffic Information


Summary : This feature provides real-time information from the RAN network aboutMS/subscriber movements that will be used by a 3rd-party road traffic informationprovider to supplement existing traffic information sources (i.e. Radio traffic channels)with a new generation real-time traffic / navigation capability.This feature is exclusive for VF operators.

Benefits for the Operator : The VF operator can either provide real time RANinformation via probes to the Abis or implement this feature and avoid costly and

operationally intensive probes.

Functional Description : This feature collects select terminal data as it occurs (event-driven) in the BSC and utilizes a new IP-SIGTRAN-based Interface between the BSCand an external server called the Vendor Network Probe (VNP). The collected terminaldata (MS in dedicated mode) will be delivered from the BSC to the VNP using eitherIMSI or IMEI information coding.

The mobile network is aware of the mobile state (e.g. cell handover), mobile timingadvance and mobile identity (IMSI/IMEI). The 3 rd-party road traffic information providerutilizes this key RAN data for determining mobile location and movement and ties it

together with associated mapping information for real-time computed subscriberservices.

The integration of the feature into the RAN requires network planning for determining thenumber of VNPs required since they are dimensioned by Erlang capacity. In addition, theIP-integration of the VNPs needs also to occur since these servers are integral to thesolution and are co-located in the operator’s network and need connectivity to the BSCsas well as to the external 3 rd-party road traffic information provider.

The feature can also be implemented in a shared RAN environment since the feature isspecific to each vendor’s RAN and the VNP used by this feature is specific to NSN (usedfor both BSS and BR RAN). A 3 rd-party RAN will have its own VNP supporting their BSCfeature; However, the VNPs will have connectivity between all deployed VNPs (fully

meshed connections) in the operator’s network..




Figures :

Real-Time Road Traffic Information - System internal view





RAN HW : VNP Rel1.0 is needed to support this feature

MS: None



BTSMetroSite

BTSFlexiMultiR




SET 2

- - - -




9.2 Support for Commercial Mobile Alert System (CMAS)


Summary : This feature provides the CMAS support required as mandatory by the USauthorities.

Benefits for the Operator : With this solution the US operator will be compliant with therequirements specified as mandatory by FCC.


• Feature introduces telecom and operational enhancements into existing basicCell Broadcast (CB) and Discontinuous Reception (DRX) functionalities based onCommercial Mobile Alert System (CMAS) standards and FCC regulatoryrequirements in North America. The feature is also a step towards support ofglobal ETWS (Earthquake and Tsunami Warning) defined by 3GPP for Rel-9 andRel-10

• as part of BSS6084 Cell Broadcast (CB) functionality:

o SMS-CB message “Repetition Period” extended up to 1 hour

o Additional performance monitoring counters which define BSC successrate of SMS-CB message broadcasting on cell level

o Cell level logging for SMS-CB messages (including SMS-CB Message IDand Serial Number) which failed during BSC transmission phase.

• as part of BSS6025 SMS-CB DRX functionality:

o Improved handset battery performance with flexible “Schedule-Period” on Air interface.

The feature is partly compliant with 3GPP TS 23.041, 48.058 (BSC-BTS) and 44.012(air). For SCMAS 3GPP standards are yet not available.

Figures :


MS: None



BTSMetroSite

BTSFlexiMultiR




- - - - - - OSS55.2 CD

set 3

- - - -




9.3 Blocking of DTMF in Downlink


Summary : In certain areas DTMF transmission to mobile devices has been misused tocontrol illegal remote devices via the downlink voice channel to GSM mobiles. In suchareas this can be prevented by the activation of this feature, i.e. by the deactivation ofthe DTMF tones in the transcoder.

Benefits for the Operator : In areas with conflicts and violence this feature can improvethe general security level. It could be required or appreciated by the authorities.

Functional Description : DTMF tones are used for remotely control or trigger securitythreatening (explosive) devices.

DTMF tones will be blocked in the TCSM3i if the calling party is another source, such as

- other operators network

- fixed land line phone

- international Gateway

- external tone generator.

Figures :


MS: None



BTSMetroSite

BTSFlexiMultiR



Release RG10(BSS) S14 - - - - - - tbd - - - -




RG20 (BSS) / RG25 (BSS)Releases

Features Under Development

Version 2.5.0

Confidential




The information in this document is subject to change without notice and describes only the productdefined in the introduction of this documentation. This document is not an official customer document andNokia Siemens Networks does not take responsibility for any errors or omissions in this document. Thisdocument is intended for the use of Nokia Siemens Networks customers only for the purposes of the

agreement under which the document is submitted. No part of this documentation may be used,reproduced, modified or transmitted in any form or means without the prior written permission of NokiaSiemens Networks. The documentation has been prepared to be used by professional and properlytrained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networkswelcomes customer comments as part of the process of continuous development and improvement ofthe documentation.

The information or statements given in this documentation concerning the suitability, capacity orperformance of the mentioned hardware or software products are given “as is” and all liability arising inconnection with such hardware or software products shall be defined conclusively and finally in aseparate agreement between Nokia Siemens Networks and the customer.

IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATIONOR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT,INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES SUCH AS BUT NOT LIMITED TO LOSS OFPROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA, that mightarise from the use of this document or the information in it.

THE CONTENTS OF THIS DOCUMENT ARE PROVIDED "AS IS". EXCEPT AS REQUIRED BY APPLICABLE MANDATORY LAW, NO WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESSFOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE MADE IN RELATION TO THE

ACCURACY, RELIABILITY OR CONTENTS OF THIS DOCUMENT. NOKIA SIEMENS NETWORKSRESERVES THE RIGHT TO REVISE THIS DOCUMENT OR WITHDRAW IT AT ANY TIME WITHOUTPRIOR NOTICE.

This document and the product it describes are considered protected by copyrights and other intellectualproperty rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of NokiaCorporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, andthey are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2010. All rights reserved.




1 Summary of Changes.....................................................................................6

2 Introduction...................................................................................................11

2.1 RG20 (BSS) Operator Value.........................................................................12

2.2 RG25 (BSS) Operator Value.........................................................................13

2.3 RG20 (BSS) / RG25 (BSS) Compatibility Information and Matrix ............. 13

2.4 Hardware Dependency Summary - RG20 (BSS) & RG25 (BSS) Features 18

3 Hardware Product Solutions for the RG20 (BSS) Release........................21

3.1 BSC Hardware Requirements......................................................................21

3.2 Transcoder Hardware Requirements..........................................................22

3.3 PCU Hardware Requirements......................................................................22

3.4 BSC Hardware Requirements for new Software Features ........................ 23

3.5 Flexi BSC Capacity Evolution......................................................................25

3.6 TCSM3i Capacity Evolution .........................................................................26

4 Hardware Product Solutions for the RG25 (BSS) Release........................27

4.1 BSC Hardware Requirements......................................................................27

4.2 Transcoder Hardware Requirements..........................................................28

4.3 PCU Hardware Requirements......................................................................28

4.4 BSC Hardware Requirements for new Software Features ........................ 28




5 Software Product Solutions - Features Under Development....................29

5.1 Radio Network Performance........................................................................29 5.1.1 Energy optimised TCH Allocation ......................... .............................. ................... 29 5.1.2 OSC Half Rate with SAIC MS .............................. ................................. ................. 31 5.1.3 Circuit Switched Dynamic Abis Pool .............................. ............................... ......... 36 5.1.4 Merged P- & E-GSM900 ............................... ............................... .......................... 38 5.1.5 OSC Full Rate with SAIC MS.......... ............................... ............................... ......... 40 5.1.6 8k TRAU for OSC AMR FR......... ............................... .............................. .............. 42

5.2 Packet Switched Data...................................................................................44

5.2.1 DL DC Territory Procedures .......................... ............................... ......................... 44 5.2.2 TRX Specific Link Adaptation for DLDC ............................ ............................. ....... 45

5.2.3

Inter-BSC NACC ............................ ............................. .............................. ............. 46

5.2.4 Inter System NACC......................... ............................... .............................. .......... 48 5.2.5 Inter System NACC for LTE............................ ............................. .......................... 50

5.3 Transmission & Transport ........................................................................... 51

5.3.1 A over IP ............................ .............................. ............................. ......................... 51 5.3.2 Abis Delay Measurement (TDM, PWE3)................................... ............................. 54 5.3.3 Packet Abis over IP/Ethernet .......................... .............................. ......................... 55 5.3.4 Packet Abis over TDM .......................... ............................. ............................ ........ 56 5.3.5 Packet Abis over Satellite ............................ ............................. ............................. 57 5.3.6 Packet Abis Security ......................... ............................ ............................ ............. 57 5.3.7 Packet TRS for UltraSite / BTSplus .......................... .............................. ............... 58 5.3.8 Packet Abis Congestion Reaction............................ ............................ .................. 59 5.3.9 Local Switching for Packet Abis........................... .............................. .................... 60 5.3.10 Packet Abis Sync. ToP IEEE1588v2 ............................. ............................. ........... 61 5.3.11 Packet Abis Synchronous Ethernet ........................... ............................. ............... 62 5.3.12 Packet Abis Delay Measurement........... ............................... ............................... .. 63 5.3.13 FlexiPacket Radio Connectivity ............................. .............................. .................. 64 5.3.14 Packet Abis IP/TDM Aggregation ......................... .............................. ................... 66

5.4 Operability.....................................................................................................68

5.4.1 PCU Restart Handling...................................... .............................. ........................ 68 5.4.2 Automatic EDAP Reallocation in PCU ............................ .............................. ......... 68 5.4.3 Energy saving mode for BCCH TRX.............. ................................ ........................ 70 5.4.4 Fast BSS Restart .............................. ............................. .............................. .......... 71 5.4.5 Flexi BTS Autoconnection............. ............................. .............................. .............. 73

5.5 Multiradio Interworking................................................................................74

5.5.1 LTE System Information ........................... ............................. .............................. .. 74 5.5.2 RF Sharing GSM - LTE.............................. ............................... ............................. 76 5.5.3 IMSI-based Handover .............................. ............................. .............................. ... 77 5.5.4 GSM - WCDMA Interworking........................... .............................. ........................ 77




5.6 Site Solutions................................................................................................78

5.6.1 Cositing with BS2xx .......................... ............................. .............................. .......... 78 5.6.2 Integrated IP card for BSC and TCSM............... ............................. ....................... 80 5.6.3 BS2xx Loop Protection with Flexi BSC .......................... .............................. .......... 81

5.7 Location Services.........................................................................................82

5.7.1 Geo-Redundant SMLC over Multi-Homed Lb Interface ............................. ............ 82




1 Summary of Changes

DATE ISSUE EDITED SUMMARY OF MAIN CHANGES

09.05.2008 1.0.0 Paul J.Dawson

Initial version.

09.06.2008 1.0.1 Paul J.Dawson

General updates and corrections.

Feature BSS21238, Merged P- & E-GSM900included.

07.07.2008 1.0.2 Paul J.Dawson

Format update.

General updates and corrections for featuredescriptions.

29.10.2008 1.1.0 Paul J.Dawson Document title and corresponding featuredescription updates included.

New Features (and descriptions) included:

− BSS21454, Packet Abis over IP/Ethernet

− BSS21440 , Packet Abis over TDM(MLPPP)

− BSS21438 , Packet Abis over Satellite

− BSS21444 , Packet Abis Security

− BSS21443 , Packet TRS for UltraSite /BTSplus

− BSS21445, Packet Abis Congestionreaction

Updates for Feature:

− BSS21288, GSM/EDGE - LTE Interworking

11.11.2008 1.1.1 Paul J.Dawson Compatibility information for features BSS21443and BSS21445 corrected.




18.12.2008 1.2.0 Paul J.Dawson

New Features (plus descriptions) included intothe RG20 Release:

−

BSS20083, Inter-BSC NACC− BSS21045 , Inter System NACC

− BSS21355 , Inter System NACC for LTE

Features removed from the RG20 Release:

− BSS21345, QoS Streaming

− BSS20708, Packet Switched Handover

and document aligned correspondingly.

13.03.2009 1.3.0 Paul J.Dawson

General updates. Compatibility information forfeatures BSS21309, BSS21343, BSS21392updated.

Features (plus descriptions) included into theRG20 Release:

− BSS21232, Automatic EDAP Reallocation inPCU

− BSS21327, Local Switching for Packet Abis

Features removed from the RG20 (BSS)Release:

− BSS21335, Precise Paging

− BSS21361, Dynamic PCU2 Pooling

and document aligned correspondingly.




30.06.2009 2.0.0 Paul J.Dawson

Document Title updated. BSS21440 FeatureTitle updated.

Features (plus descriptions) included into theRG20 (BSS) Release:

− BSS21439, Packet Abis Sync. ToPIEEE1588v2

− BSS30450, Packet Abis SynchronousEthernet

− BSS21353, LTE System Information(replaces BSS21288)

Features removed from the RG20 (BSS)Release:

− BSS21288, GSM/EDGE - LTE Interworking(replaced with BSS21353)

Chapter 2 extended and CompatibilityInformation included.

Chapter 3 extended and Hardware DependencyInformation included.

General updates for the RG20 (BSS) features.

24.09.2009 2.1.0 Paul J.Dawson

Compatibility information for feature BSS21309updated.

AoIP Feature ID information updated.

Description for features BSS20083, BSS21045and BSS21443 updated.

Feature (plus description) included into theRG20 Release:

− BSS30395, Packet Abis DelayMeasurement




30.11.2009 2.2.0 Paul J.Dawson

Compatibility Information for all features andSection 2.2 Compatibility Matrix updated.

New Summary Tables 1 and 2 included.Feature Title updated for BSS21316 andBSS21309.

Features (plus description) included into theRG20 Release:

− RG301397, Cositing with BS2xx

− BSS21503, FlexiPacket Radio Connectivity

05.03.2010 2.3.0 Paul J.Dawson

Section 2, Introduction, has been updated.

Section 3, Hardware Product Solutions, has

been updated and Table 7 included.Compatibility Information for the featuresBSS21341, BSS30380, BSS21454 andBSS21440 updated.

Description for feature BSS21353 has beenupdated, accounting for feature support inRG10 (BSS) EP Release (Note: There is no change from the earlier defined RG20capability).

Description and Compatibility Information for

features BSS21309 and RG301397 updated.Features (plus description) included into theRG20 Release:

− BSS30385, Circuit Switched Dynamic AbisPool

− BSS21498, Geo-Redundant SMLC overMulti-Homed Lb Interface

Support extended to the BTSplus Base Stationtype for the RG10 (BSS) features:

− BSS20958 , Energy saving mode for BCCHTRX

− BSS21157, Integrated IP card for BSC andTCSM

Tables 1 and 2 updated, correspondingly.




14.05.2010 2.4.0 Paul J.Dawson

General update to all relevant sectionsaccounting for the RG25 (BSS) Release.

Section 4, RG25 (BSS) Hardware information,has been added.

Logistics and Compatibility Information for thefeature BSS21309 updated.

Compatibility Information for the featureBSS30385 updated.

Summary updated for feature BSS30380.

Features (plus description) included into theRG25 (BSS) Release:

− BSS21534, OSC Full Rate with SAIC MS

− BSS21325, 8k TRAU for OSC AMR FR

− BSS21520, RF Sharing GSM - LTE

− BSS21539, Packet Abis IP/TDM Aggregation

− RG601668, BS2xx Loop Protection withFlexi BSC

Support extended to the BTSplus Base Stationtype for the features:

−

BSS12158, IMSI-based Handover− BSS10101, GSM - WCDMA Interworking


29.06.2010 2.5.0 Paul J.Dawson

Minor text corrections.

Compatibility Matrix (Section 2.3) extended withfull details for RG25 (BSS).

Feature Title updated for BSS21392.

Description for features BSS21353 andBSS21355 have been updated.

BSS21327, Local Switching for Packet Abis re-allocated to RG25 (BSS). CompatibilityInformation updated.

BSS21299, High Symbol Rate in DL (REDHOT-B) and BSS21298, High Symbol Rate in UL(HUGE-B) re-allocated to RG30 (BSS).




2 Introduction

This document describes the Features Under Development for the Base StationSubsystem (BSS) releases RG20 (BSS) and RG25 (BSS).

The Nokia Siemens Networks release RG20 (BSS) provides advantages for all operators,through supporting:

• Voice Capacity / Spectral Efficiency Enhancements - maximising the utilisationof the existing infrastructure and providing CAPEX / OPEX efficient capacityupgrade solutions through the unique OSC (Orthogonal Sub Channel) capability.

• CAPEX / OPEX Efficient Enhanced Transport solutions - achieved throughemploying the Packet Abis and AoIP Solutions.

• Extended BTS Energy Saving solutions - beyond those already realised in theRG10 (BSS) Release.

• Enhanced GSM/EDGE-LTE Interworking - Providing coverage continuity and animproved end user experience. Maximising the use of existing GSM/EDGEresources and employing support for NACC (Network Assisted Cell Change).

• EDGE Evolution - Building upon the existing RG10 (BSS) Downlink Dual Carriersolution.

The RG25 (BSS) Release builds upon the capabilities provided by RG20 (BSS),enhancing the value through extending the OSC function to include OSC Full Rate andthus improving network Quality. Packet Abis IP/TDM Aggregation saves CAPEX/OPEXcosts through enabling an even greater transmission efficiency for Packet Abis over TDM

configurations. Local Switching for Packet Abis further reduces the Abis bandwidthrequirement and CAPEX/OPEX savings are also reflected in the GSM-LTE Interworkingextension. In addition, the new features introduced for the BTSplus Base Station typeprovide an even greater level of function across the network (for Operators with thisconfiguration scenario).




2.1 RG20 (BSS) Operator Value

BSC & TCSM Solution: The BSC / Transcoder solution for the RG20 (BSS) Releaseprovides enhancements to the product capacity as well as the optional new interfacemodules to support the Packet Abis and A over IP feature capabilities.

BTS Solution: With RG20 (BSS), the Flexi BTS Autoconection feature enables fasterand more efficient rollouts and also OPEX savings in normal operation. Furthermore, theFlexi EDGE BTS provides the necessary interfacing for the Orthogonal Sub Channel(OSC) and Packet Abis capabilities.

Radio Network Performance: The Orthogonal Sub Channel (OSC) feature providesenhancements to a number of key network aspects, addressing capacity, spectralefficiency and coverage. In addition, it is a key OPEX saving enabler. Yet further spectralefficiencies may be realised through the Merged P- and E-GSM900 capability.

Transmission Solutions: The Packet Abis and A over IP features introduced with RG20(BSS) enable IP Networking for both the Abis- and A-Interfaces. They realise capacity(via an integrated Abis Optimization) and CAPEX/OPEX savings; increase flexibility andenable a simpler network operation / maintenance. Beyond this, FlexiPacket RadioConnectivity extends the unique Nokia Siemens Networks “Zero Footprint” Flexi-basedsolution.

Operability: The Fast BSS Restart feature enables a significant reduction in BSSdowntime and consequently acts to increase network availability and of course revenue.The Automatic EDAP Reallocation in PCU and PCU Restart Handling features reduceOPEX and increase PCU availability, also acting to boost revenue.

Packet Switched Data: NACC reduces the service outage during cell changes,enhancing the performance for services that require higher throughput or shorter delays.The Dual Carrier in Downlink feature enhancements enable throughput performanceincreases and improve the efficiency of the PCU allocation.

Multi-radio Interworking: NACC support for WCDMA and LTE reduce the serviceoutage for multi-RAT interworking. Furthermore, NACC with LTE may be used ( whereRIM is supported ) as an extension for the CS Fallback Voice Call Continuity solution.Basic LTE interworking with GSM/EDGE provides continuity of coverage in the network.

Energy Savings: Amongst the other key advantages indicated above, the OrthogonalSub Channel (OSC) feature enables energy (OPEX) savings through reducing thenumber of TRXs and combining losses. In addition, the feature Energy optimised TCH

Allocation further enhances the possible OPEX savings.




2.2 RG25 (BSS) Operator Value

BTS Solution - RG25 (BSS) extends support for the RG20 (BSS) / RG25 (BSS) featureset to the Multiradio BTS. Furthermore, support for the BTSplus is further enhanced withthe Loop Protection feature (amongst others), which increases network redundancy andavailability, ensuring revenue flow. Importantly, support for OSC Full Rate and Half Rateis now also provided for the UltraSite BTS, extending the advantages provided by OSCutilisation to a potentially wider network area.

Radio Network Performance - With RG25 (BSS), the OSC Solution is extended toinclude OSC Full Rate, enhancing Quality within the network. It enables the samecapacity as AMR Half Rate, but achieves this with a higher MOS quality. With the 8kTRAU feature, the Operator is able to introduce OSC Full Rate into the network withouthaving to modify the existing legacy Abis transmission solution.

Transmission Solutions - Packet Abis IP/TDM Aggregation builds upon the RG20 (BSS)Packet Abis solution, realising further capacity savings via statistical multiplexing gains.Local Switching for Packet Abis continues this approach and provides mechanisms to yetfurther reduce the Abis bandwidth requirement.

Multi-radio Interworking - GSM-LTE Concurrent Mode operation deepens the supportfor LTE, realising CAPEX savings through hardware sharing and reducing OPEX costs

via the modular solution. Critically, flexibility is also increased, enabling a faster, moreflexible and simpler migration to LTE.

2.3 RG20 (BSS) / RG25 (BSS) Compatibility Information and Matrix

Where applicable and in general, the RG20 (BSS) and RG25 (BSS) software features aremanaged via Licence Key. A summary table is included below:

Feature ID Feature Licence Key

BSS21309 OSC Half Rate with SAIC MS Y

BSS30385 Circuit Switched Dynamic Abis Pool Y

BSS21222 Energy optimised TCH Allocation Y

BSS21238 Merged P- & E-GSM900 Y

BSS21343 DL DC Territory Procedures N*

BSS21392 TRX Specific Link Adaptation for DLDC N*




Feature ID Feature Licence Key

BSS20083 Inter-BSC NACC YBSS21045 Inter System NACC Y

BSS21355 Inter System NACC for LTE Y

BSS21353 LTE System Information Y

BSS21368 Flexi BSC Capacity Evolution N

BSS21371 TCSM3i Capacity Evolution N

RG301397 Cositing with BS2xx N

BSS21341 A over IP, Transcoder in BSS Y

BSS30380 A over IP, Transcoder in MGW Y

BSS21454 Packet Abis over IP/Ethernet Y

BSS21440 Packet Abis over TDM Y

BSS21438 Packet Abis over Satellite Y

BSS21444 Packet Abis Security Y

BSS21443 Packet TRS for UltraSite / BTSplus Y

BSS21445 Packet Abis Congestion reaction N*

BSS21327 # Local Switching for Packet Abis Y

BSS21439 Packet Abis Sync. ToP IEEE1588v2 Y

BSS30450 Packet Abis Synchronous Ethernet Y

BSS21271 Abis Delay Measurement (TDM, PWE3) Y

BSS30395 Packet Abis Delay Measurement Y

BSS21503 FlexiPacket Radio Connectivity N

BSS21316 Flexi BTS Autoconnection Y

BSS20045 PCU Restart Handling N

BSS21232 Automatic EDAP Reallocation in PCU N

BSS21362 Fast BSS Restart N

BSS21498 Geo-Redundant SMLC over Multi-Homed Lb Interface

N*

BSS21534 # OSC Full Rate with SAIC MS Y

BSS21325 # 8k TRAU for OSC AMR FR Y

BSS21520 # RF Sharing GSM - LTE Y

BSS21539 # Packet Abis IP/TDM Aggregation Y

RG601668 # BS2xx Loop Protection with Flexi BSC N

* The dependant feature(s) is(are) Licence Key Managed.# The feature is supported from the RG25 (BSS) Release.

Table 1: Licence Key Managed Feature Summary for RG20 (BSS) & RG25(BSS).




The compatibility of the NE releases for RG20 (BSS) and RG25 (BSS) is as follows:

RG20 (BSS) consists of the releases: BSC S15; MetroSite CXM8.0; UltraSiteCX8.0; Flexi EDGE EX4.0 and BTSplus BRG2.

RG20 (BSS) is supported by the following NE releases: NetAct OSS5.2 CDSet 3; MSC M15 and SGSN SG8.

RG25 (BSS) consists of the releases: BSC S15 EPx.0; MetroSite CXM8.1;UltraSite CX8.1; Flexi EDGE EX4.1; Flexi Multiradio EX4.1 and BTSplusBRG2.1.

RG25 (BSS) is supported by the following NE releases: NetAct OSS5.3 CDSet 1; MSC M15 and SGSN SG8.

Concerning the BSC / Transcoder, the upgrade from RG20 (BSS) to RG25 (BSS) will belike an “EP Release” upgrade. Note that the respective BTSs also need to be upgradedin order that the new functionality provided in RG25 (BSS) can be supported.

The BSCi / BSC2i / TCSM2 and Talk Family BTS systems are compatible (supported) bythe RG20 (BSS) Release. Also, the new RG20 (BSS) features are not supported by theTranscoder TCSM2 and Talk Family BTSs.

The BSCi / BSC2i and TCSM2 and Talk Family BTS systems are compatible (supported)by the RG25 (BSS) Release. Also, the new RG25 (BSS) features are not supported bythe Transcoder TCSM2 and Talk Family BTSs.




The standardisation baseline of the RG20 (BSS) and RG25 (BSS) releases is 3GPPRelease 8, Meeting #41.




Notations used in the dependency tables:

The table is used to relate the described BSS features to required systemcomponents:


BTSUltraSite

BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTSFlexi

Multiradio

BTSBTSplus

NetAct SGSN MSC RAN MS Licensing

Release - - - - - - - - - - - - - - -

In the table we use the following notations:

SUPPORTED IN:

MSC This feature is supported in the MSC (xxx = MSCrelease/feature no) N = No, - = no dependency, X= support required but release not defined.

DX200PlatformThis feature is supported by DX200 Platform(xxx = release/feature no) N = No, - = nodependency, X = support required but releasenot defined.

NetAct This feature is supported in the NetAct (xxx =release/feature no) N = No, - = no dependency, X= support required but release not defined.

BSC This feature is supported by the BSC (xxx =release/feature no) N = No, - = no dependency, X= support required but release not defined...

MS The feature sets special requirements to mobilestations (xxx = 3GPP release), - = nodependency, X = support required but releasenot defined.

SGSN This feature is supported by the SGSN (xxx =release/feature no) N = No, - = no dependency, X= support required but release not defined.

Talk-family

This feature is supported by Talk-family BTS (xxx

= release/feature no) N = No, - = no dependency,X = support required but release not defined. HW/FW DEPENDENCY:

UltraSite This feature is supported by UltraSite BTS (xxx =release/feature no) N = No, - = no dependency, X= support required but release not defined

BSCHW/FW

This feature requires additional or alternativeBSC hardware or firmware

MetroSite This feature is supported by MetroSite BTS (xxx =release/feature no) N = No, - = no dependency, X= support required but release not defined.

BTSHW/FW

This feature requires additional or alternativeBTS hardware or firmware

FlexiEDGE

This feature is supported by Flexi EDGE BTS (xxx= release/feature no) N = No, - = no dependency,X = support required but release not defined

TC HW/FW This feature requires additional or alternativeTranscoder hardware or firmware

FlexiMultiradio

This feature is supported by Flexi Multiradio BTS(xxx = release/feature no) N = No, - = nodependency, X = support required but release notdefined

SGSNHW/FW

This feature requires additional or alternativeSGSN hardware or firmware

BTSplus This feature is supported by BTSplus BTS (xxx =release/feature no) N = No, - = no dependency, X= support required but release not defined Licensing

BSS Licensing: Provides information on the method of LicenceControl.




2.4 Hardware Dependency Summary - RG20 (BSS) & RG25 (BSS) Features

A summary list of the BSS and MS Hardware Dependancies is included in the tablebelow:

Feature ID Feature BSC TSCM BTS MS

BSS21309 OSC Half Rate with SAIC MS - - FE, FM,UltraSite # Rel.6

BSS30385 Circuit Switched Dynamic Abis Pool - - FE, FM,UltraSite # -

BSS21222 Energy optimised TCH Allocation - - - -

BSS21238 Merged P- & E-GSM900 - - - EGSM900

BSS21343 DL DC Territory Procedures - - - Rel.7

BSS21392 TRX Specific Link Adaptation for DLDC - - - Rel.7

BSS20083 Inter-BSC NACC - - - Rel.5

BSS21045 Inter System NACC - - - Rel.5

BSS21355 Inter System NACC for LTE - - - Rel.8

BSS21353 LTE System Information - - - Rel.8

BSS21368 Flexi BSC Capacity Evolution Flexi BSC - - -

BSS21371 TCSM3i Capacity Evolution - TCSM3i - -RG301397 Cositing with BS2xx - - FE, FM -

BSS21341 A over IP, Transcoder in BSS - TCSM3i - -

BSS30380 A over IP, Transcoder in MGW

BSC3i1000/2000

or FlexiBSC

- FE, FM -

BSS21454 Packet Abis over IP/Ethernet

BSC3i1000/2000

or FlexiBSC

- FE, FM -

BSS21440 Packet Abis over TDM

BSC3i1000/2000

or FlexiBSC

- FE, FM -

BSS21438 Packet Abis over Satellite

BSC3i1000/2000

or FlexiBSC

- FE, FM -





BSS21443 Packet TRS for UltraSite / BTSplus

BSC3i1000/2000

or FlexiBSC *

- UltraSite,BTSplus -

BSS21445 Packet Abis Congestion reaction

BSC3i1000/2000

or FlexiBSC

- FE, FM -

BSS21327 # Local Switching for Packet Abis

BSC3i1000/2000

or FlexiBSC

- FE, FM -

BSS21439 Packet Abis Sync. ToP IEEE1588v2

BSC3i1000/2000

or FlexiBSC

- FE, FM -

BSS30450 Packet Abis Synchronous Ethernet

BSC3i1000/2000

or FlexiBSC

- FE, FM -

BSS21271 Abis Delay Measurement (TDM, PWE3)

BSC3i1000/2000

or FlexiBSC *

- FE, FM -

BSS30395 Packet Abis Delay Measurement

BSC3i1000/2000

or FlexiBSC

- FE, FM -

BSS21503 FlexiPacket Radio Connectivity - - FE, FM -

BSS21316 Flexi BTS Autoconnection - - FE, FM -

BSS20045 PCU Restart Handling - - - -

BSS21232 Automatic EDAP Reallocation in PCU - - - -

BSS21362 Fast BSS Restart - - - -

BSS21498 Geo-Redundant SMLC over Multi-Homed Lb Interface

- - - -





BSS21534 # OSC Full Rate with SAIC MS - - FE, FM,UltraSite Rel.6

BSS21325 # 8k TRAU for OSC AMR FR - - FE, FM,UltraSite -

BSS21520 # RF Sharing GSM - LTE - - FM -

BSS21539 # Packet Abis IP/TDM Aggregation

BSC3i1000/2000

or FlexiBSC

- FE -

RG601668 # BS2xx Loop Protection with Flexi BSC - - BTSplus -

Key:FE - Flexi EDGE BTSFM - Flexi Multiradio BTS (Features supported from the RG25 (BSS) Release).* - For the integrated CESoPSN solution# - The feature is supported from the RG25 (BSS) Release.

Table 2: Hardware Dependency Summary for the RG20 (BSS) & RG25 (BSS) Features.




3 Hardware Product Solutions for the RG20 (BSS) Release

As indicated at an earlier stage, with the C3 of the RG20 (BSS) Release, a confirmation ofthe product hardware related requirements can be provided and has been communicatedthrough the BSC Hardware Technical Note - TS-BSC-HW-0178.

In addition, Technical Note TS-BSC-HW-0181 details the new Hardware Items that havebeen developed for the BSC and Transcoder Products and which are supported at thenew S15 - RG20 (BSS) - Software Release level.


3.1 BSC Hardware RequirementsBeyond the Flexi BSC and BSC3i, the BSCi and BSC2i support the RG20 (BSS) softwarerelease. Some functions - such as the ETP / ETP-A module required for the Packet Abisand A over IP features - are available only for the Flexi BSC, BSC3i 1000/2000 andadditionally for the TCSM3i.

The RG20 (BSS) Release sets the same mandatory minimum hardware requirement asper the RG10 (BSS) Release, described below:

Minimum CPU Memory Size:

• Is as per the RG10 (BSS) Release

• Flexi BSC has 1 GB in all units as standard

• BSC3i 660 and 1000/2000: 512 MB in BCSU, 1 GB in MCMU and OMU

• BSCi and BSC2i: 512 MB in OMU, MCMU and BCSU

Minimum Hard Disk Size:• Is as per the BSS13 and RG10 (BSS) Releases

• BSC3i: 9GB

• BSCi and BSC2i: 4GB




Typical Minimum O&M Link Capacity Requirement:

• Is as per the BSS13 and RG10 (BSS) Releases

• BSC3i 2000: minimum 1024 kbit/s, recommended 2048 kbit/s


• BSCi, BSC2i, BSC3i 660: minimum 256 kbit/s, recommended 512 kbit/s

Please note that the figures presented above are calculated estimates that have not yetbeen confirmed in live usage and consequently changes may potentially arise.

Please also note that some deviation to these figures may exist arising from the number

of managed objects under the BSC, the activated features, customer specific datacollection settings, work processes, etc…

A LAN-based O&M connection is currently recommended for all product configurationsand is the most powerful link option method. Alternatively, a digital X.25 connection is stillfeasible when multiple 64kbit/s timeslots are employed. LAN interfaces are mandatory fordata speeds higher than 1024 kbit/s. As for the earlier BSS13 software release, an analogX.25 connection with limited link capacity is no longer available with the BSC3i 1000/2000configuration; and as for the earlier RG10 (BSS) release, with the Flexi BSC only a LANbased connection is supported.

Please also note that in BSCi and BSC2i the O&M LAN interface requires IP cabling andCPLAN panels as well as external LAN switches and/or routers.

3.2 Transcoder Hardware RequirementsBeyond the TCSM3i, the TCSM2 supports the base RG20 (BSS) software release. Notethat the new transcoder related capabilities are only supported by the TCSM3i.

3.3 PCU Hardware Requirements

The PCU1 is supported by the RG20 (BSS) release. The new packet data relatedsoftware features listed below will require the PCU2.




3.4 BSC Hardware Requirements for new Software Features As for previous software releases, certain software products set additional requirementsfor the BSC hardware. An initial hardware requirement for the new RG20 (BSS) software

features is listed in the following table:

The PCU2 Plug-in unit is a mandatory hardware requirement for:• DL DC Territory Procedures

• TRX Specific Link Adaptation for DLDC

• Inter-BSC NACC

• Inter System NACC

• Inter System NACC for LTE

• Cositing with BS2xx

Table 3: Initial PCU2 Hardware requirements for RG20 (BSS) software features.

Furthermore:

The ETP Plug-in unit (for Flexi BSC / BSC3i1000/2000) is a mandatory hardwarerequirement for:

• Packet Abis over IP/Ethernet

• Packet Abis over TDM

• Packet Abis over Satellite

Table 4: Initial BSC Hardware requirements for RG20 (BSS) software features.

Also:

The ETP-A Plug-in unit (for Flexi BSC, BSC3i1000/2000 and TCSM3i) is a mandatoryhardware requirement for:

• A over IP





Additionally:

A new version of the ETS2 (STM-1) module isrequired for:



Finally:

An additional pair of LAN Switch (ESB24-D) Modules (i.e. 2xESB24-D Modules) is a mandatory requirement for the BSC3i

1000/2000 or Flexi BSC in order to interconnect ETP and / orETP-A Modules for:• Packet Abis over IP/Ethernet


• Packet Abis over Satellite

• A over IP


Hardware requirements for the software features introduced in earlier software releasesshould be reviewed separately.




3.5 Flexi BSC Capacity Evolution


Summary : The Flexi BSC was introduced with the RG10 (BSS) Release to complement theexisting members of the Flexi BSC product family - The BSC3i 660 and the BSC3i 1000/2000.The Flexi BSC is designed to provide both a leading capacity and low power consumption in asingle cabinet solution and is fully flexible in capacity and connectivity dimensioning. With theRG20 (BSS) Release, this evolution is continued through the introduction of a new Intel CPUenabling the capacity to be further extended to support up to 4200 TRXs in one single cabinet.

Benefits for the Operator : Every aspect of the Flexi BSC contributes to its high operationalefficiency. The solution offers a unique level of capacity efficiency - being the only BSC in themarketplace to support up to 4200 TRXs in one cabinet, whilst providing the highest traffic

handling capacity of 25000 Erlang. Additionally, it offers a new level of efficiency intransmission, through enabling the Packet Abis and A over IP functions through the new ETP /ETP-A modules - which can be also be used in the BSC3i 1000/2000 and TCSM3i. The FlexiBSC, through offering full flexibility in configuration for different transmission media will enablethe operator to realise the most cost efficient solution for their requirements.

Functional Description : The new Flexi BSC configuration supports very high TRXconfigurations with up to 4200 TRXs in an extremely compact, single cabinet solution. Alongwith support for Circuit Switched traffic, it supports Packet Switched services with up to 30 720

Abis links (16kbit/s). Scalability and flexibility are the key drivers allowing the tuning of thecapacity and transmission connectivity to the specific levels required by the operator.

The Flexi BSC is based on the DX200 distributed processor platform, which efficiently evolveswith the available commercial Intel processing power; and the distributed architecture enablesthe solution to meet new and evolving requirements.

All earlier BSCs of the Flexi BSC product family (BSC3i 660, BSC3i 1000/2000 and the FlexiBSC from RG10 (BSS) ) may optionally be upgraded to provide this latest capability.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - (Y) (Y) (Y) (Y) (Y) 1) (Y) - - - - -

1) The feature is supported with the RG25 (BSS) Release.




3.6 TCSM3i Capacity Evolution


Summary : The TCSM3i Transcoder was introduced with the BSS12 Release. The extremelyhigh channel capacity of the TCSM3i is now yet further extended with a new configurationsetup - supporting up to 14400 traffic channels in an ETSI environment and 11400 trafficchannels in an ANSI environment for a stand-alone installation. The capacity of the combinedBSC / Transcoder solution remains at the market leading 34000 channel level (introduced withthe BSS13 Release), but the packing density has been further increased, so that this can nowbe realised with two cabinets instead of the current three.

Enhancements to the BSC connectivity have also been realised, where up to 272 differentBSCs can now be connected to a combined BSC / Transcoder solution and up to 30 for stand-alone configurations.

A new transmission interfacing option will also be available for the A over IP function - enabledvia the ETP-A interface module.

Benefits for the Operator : The following benefits are realised:

• CAPEX Savings, through combining the enhanced capacity of the TCSM3iwith a flexible site installation

• OPEX Savings, through reduced transmission, site and O&M costs

In addition to the significant benefits of the TCSM3i for existing combined BSC / TCSMsolutions, that is, native optical A-interfaces for fast installation and clear transmission and sitecost savings, the major capacity increase enables a new flexibility in BSC / Transcoder siteinstallations. Moreover, a greater number of BSCs can now be served by a single transcodingentity, simplifying the network design.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - (Y) (Y) (Y) (Y) (Y) 1) (Y) - - - - -





4 Hardware Product Solutions for the RG25 (BSS) Release

A confirmation of the product hardware related requirements has been communicatedthrough the BSC Hardware Technical Note - TS-BSC-HW-0183.


4.1 BSC Hardware RequirementsBeyond the Flexi BSC and BSC3i, the BSCi and BSC2i support the RG25 (BSS) softwarerelease. The RG25 (BSS) Release sets the same mandatory minimum hardwarerequirement as per the RG20 (BSS) Release, described below:

Minimum CPU Memory Size:

• Is as per the RG10 (BSS) and RG20 (BSS) Releases

• Flexi BSC has 1 GB in all units as standard

• BSC3i 660 and 1000/2000: 512 MB in BCSU, 1 GB in MCMU and OMU

• BSCi and BSC2i: 512 MB in OMU, MCMU and BCSU

Minimum Hard Disk Size:

• Is as per the BSS13, RG10 (BSS) and RG20 (BSS) Releases

• BSC3i: 9GB

• BSCi and BSC2i: 4GB

Typical Minimum O&M Link Capacity Requirement:

• Is as per the BSS13, RG10 (BSS) and RG20 (BSS) Releases



• BSCi, BSC2i, BSC3i 660: minimum 256 kbit/s, recommended 512 kbit/s

Please note that the figures presented above are calculated estimates that have not yetbeen confirmed in live usage and consequently changes may potentially arise.




Please also note that some deviation to these figures may exist arising from the numberof managed objects under the BSC, the activated features, customer specific datacollection settings, work processes, etc…

A LAN-based O&M connection is currently recommended for all product configurationsand is the most powerful link option method. Alternatively, a digital X.25 connection is stillfeasible when multiple 64kbit/s timeslots are employed. LAN interfaces are mandatory fordata speeds higher than 1024 kbit/s. As for the earlier BSS13 software release, an analogX.25 connection with limited link capacity is no longer available with the BSC3i 1000/2000configuration; and as for the earlier RG10 (BSS) and RG20 (BSS) releases, with the FlexiBSC only a LAN based connection is supported.

Please also note that in BSCi and BSC2i the O&M LAN interface requires IP cabling andCPLAN panels as well as external LAN switches and/or routers.

4.2 Transcoder Hardware RequirementsBeyond the TCSM3i, the TCSM2 supports the base RG25 (BSS) software release. Notethat the new transcoder related capabilities are only supported by the TCSM3i.

4.3 PCU Hardware RequirementsThe PCU1 is supported by the RG25 (BSS) release.

4.4 BSC Hardware Requirements for new Software Features As for previous software releases, certain software products set additional requirementsfor the BSC hardware. For the RG25 (BSS) Release, there are currently no additionalhardware requirements.

Hardware requirements for the software features introduced in earlier software releasesshould be reviewed separately.




5 Software Product Solutions - Features Under Development

5.1 Radio Network Performance5.1.1 Energy optimised TCH Allocation


Summary : The RG10 (BSS) Release feature set encompasses a significant capability forminimising power consumption and consequently reducing operator OPEX costs. Withthe RG20 (BSS) Release, this new feature builds upon the RG10 (BSS) capability, furtherreducing the BTS power consumption through adapting the voice call allocation proceduresuch that allocation to the BCCH TRX is also based upon the Downlink received signallevel information.

Benefits for the Operator : The RG10 (BSS) Release provides a significant capability forminimising power consumption and consequently reducing OPEX costs for the operator.This new RG20 (BSS) feature enhances this energy saving potential at the BTS, furtherdecreasing the OPEX costs for the operator.

It also acts to reduce the Downlink interference level, through the improved power levelmanagement realised.

Functional Description : Currently, the allocation of radio timeslots (RTSL) in a cell isbased upon the sequential availability of resources and also the value of the TRP (TRXPriority In TCH Allocation) parameter. Timeslots which are occupied by calls with a lowDownlink Rx Level have a maximum radiated power at the BTS. Typically, there will becases where calls demanding a high Downlink transmit power (where the measuredDownlink Rx Level is low) are allocated to a non-BCCH TRX and calls with a lowDownlink transmit power (where the measured Downlink Rx Level is high) are allocated tothe BCCH TRX. Since the BCCH TRX is operating on maximum power an "excessive"transmit power is being used for calls with a high Downlink Rx Level (simply because theyhave been allocated to the BCCH TRX). Equally, calls with a lower Downlink Rx Levelwhich are allocated to a non-BCCH TRX result in a higher total power consumption (if theBCCH TRX is occupied by calls with a higher Downlink Rx Level).

Figure: Current TCH Allocation Mechanism.

Distant MS allocated to theTCH TRX => due to low

TCH TRXo erates at full Near MS allocated to the

BCCH TRX => PC not

BCCH TRXo erates at full




Consequently, the BTS power consumption could thus be reduced if the circuit switchedTCH allocation procedure to the BCCH TRX also takes the reported downlink receivedsignal level information into account.

The Energy optimised TCH Allocation feature provides a mechanism that optimises theselection of the BCCH and non-BCCH TRXs for TCH allocation within a BSC in terms ofpower consumption. This means that the total power consumption in the BTS can bereduced, consequently saving OPEX costs.

Two new segment level parameters:

• Lower DL RX lev for BCCH TRX preference (LDRB)

• Upper DL RX lev for BCCH TRX preference (UDRB)

Lower and Upper Downlink Rx Level thresholds, for BCCH TRX preference in TCHallocation will be introduced. With these parameters the operator is able to define aDownlink Rx Level window for BCCH TRX preference. If the measured Downlink RxLevel is within this window, the BSC will attempt to allocate the call to the BCCH TRX,otherwise it will be allocated to a non-BCCH TRX.

Figure: Energy optimised TCH Allocation Mechanism for TCH Allocation.

Furthermore, this window based approach (where a Lower Rx Level threshold is used inaddition to the Upper Rx Level threshold), accommodates networks which employ RFHopping. In this case, calls with a very poor Downlink Rx Level (receive level close to theDownlink receiver sensitivity level) are allocated to a non-BCCH TRX in order to benefitfrom the hopping gain (the BCCH TRX is not used in hopping). This approach thenmaintains the existing call drop rate.




It is currently estimated that Energy optimised TCH Allocation will enable transmit powerreductions of the order of 1.5 to 2.5dB, translating into an up to around 10% powerconsumption improvement over the existing mechanism. The gain is highest in lower tomedium TRX loading levels (approximately up to 60% loading of TRXs). For increasingloads beyond this level the influence of the feature reduces and consequently the gainsalso reduce. Furthermore, the higher the number of non-BCCH TRXs in a cell, thegreater is the saving in power consumption. Of course, the gain also depends upon theparticular parameter settings.

Operational Aspects: The Downlink Rx Level based TRX prioritisation is applied onlyduring call setup and for intra-BSC handovers. For external handovers the Downlink RxLevel is not known by the target BSC and consequently the TRX selection is performedaccording to the existing TRP parameter setting. Furthermore, the feature is only appliedto CS Calls.

Should the feature BSS08037, Enhanced Coverage by Frequency Hopping, be in use inthe network, it is recommended not to simultaneously employ both features within a cell.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - Y Y N Y Y 1) Y - - - - - LicenceKey

Control


5.1.2 OSC Half Rate with SAIC MS


Summary : Orthogonal Sub Channel (OSC) introduces a doubling of the voice channelcapacity, such that with the new RG20 (BSS) feature, OSC Half Rate with SAIC MS, fourusers can now share the same radio Timeslot. Only SAIC and AMR support are requiredfrom the Handset.

The increase in voice channel capacity is realised through the adoption of a quaternarymodulation scheme in the Downlink and utilising spatially orthogonal sub-channels in theUplink. These two solutions, combined with AMR, enable the possibility to serve twoHandsets which support single antenna interference cancellation (SAIC), simultaneouslyin a single radio traffic channel.

OSC not only introduces a step change in network capacity, it is achieved in a veryenergy efficient manner, reducing the total energy requirement at the BTS, saving furtherOPEX costs for the operator.




Benefits for the Operator : Normally, when an operator needs to increase capacity this isachieved through extending the BTS configuration (via increasing the TRX and combinerport count), increasing the combining loss and potentially impacting coverage. OSC canprovide for this increased capacity without requiring new TRXs (or related hardware) andavoiding the network impact. Consequently, for the operator an increased capacity canbe provided more easily and CAPEX/OPEX effectively.

Through the capacity improvements realised by OSC, a reduced number of TRX isnecessary in order to realise a specific capacity or spectral efficiency. Consequently, theenergy consumption required per Erlang may be reduced by as much as 50% with OSC.

Furthermore, OSC Half Rate with SAIC MS provides a profitable network growth path foroperators, with minimised CAPEX and OPEX costs. The coverage area can bemaintained in capacity extensions and the need to add new sites is avoided, thus,lowering or delaying considerably the operator’s expenditure. For new network

deployments, the increased capacity per TRX achievable through OSC can be used toeffectively reduce the required site density (and consequently CAPEX/OPEX costs)through the reduced combining losses now possible.

Alternatively, since OSC Half Rate with SAIC MS increases the voice capacity potential,the feature can also be employed to release capacity for additional data traffic.

Most importantly, contra to the 3GPP Rel.9 VAMOS (Voice services over Adaptive Multi-user Orthogonal Sub channels) capability, which of course requires the availability andsufficient penetration of Rel.9 Handsets, with the Nokia Siemens Networks OSC solution,the existing Handsets supporting AMR and SAIC are sufficient. This is available today and thus operators can derive the full gains from OSC immediately .

Functional Description : Orthogonal Sub Channel (OSC) introduces a doubling of thevoice channel capacity, such that with the new RG20 (BSS) feature, OSC Half Rate withSAIC MS, four users can now share the same radio Timeslot. Only SAIC (the Handsetmust indicate its support for SAIC to the network) and AMR support are required from theHandset.

The two OSC Sub-channels are identified as OSC-0 and OSC-1, in a TCH/H. The OSCSub-channels are independent of one other, that is, they have an independent RadioResource layer signalling. Separation between the simultaneous connections in a TCH isrealised through the use of individual training sequences.

Individual Training SequencesThe separation of the two simultaneous users in Downlink and Uplink is enabled throughemploying different training sequences, whilst the other channel parameters can be thesame as that for a normal GMSK modulated channel. This enables the use of normalSAIC handsets for OSC. The Sub-channel specific Training Sequence Codes (TSC) areorganised as TSC pairs, which provide the lowest cross-correlation.

Multiplexing in the DownlinkIn the Downlink, the BTS uses Quaternary Phase Shift Keying (QPSK) modulation whichis composed from two orthogonal sub channels. These are received by the legacy SAICHandsets as normal GMSK. Separate reception of one of the Sub-channels is achieved




as they are orthogonal and through the different training sequences employed for theSub-channels.

The figure below shows the mapping of Users A and B in the QPSK modulationconstellation, where User A is mapped to the first bit and User B to the second bit:

Figure: Multiplexing in the Downlink.

Multiplexing in the UplinkIn the Uplink, Handsets employ standard GMSK transmission and simultaneous Sub-channels are differentiated via the training sequences and propagation path.

Antenna Diversity (two antennas) is required for the BTS, in order to facilitate reception ofthe two simultaneous users - This is inherent, resulting from the degree of freedom rule,applied for MU-MIMO (Multi User - Multiple Input, Multiple Output) systems in general,

which states that the number of simultaneous users can be the same as the number ofreceiving antennas. Please refer to the figure below. The radio propagation paths in theUplink are generally uncorrelated due to the separate locations of the users.

User-A

User-B

Deciphering Decoding


V-MIMO

Receiver Abis

V-MIMO

TRXUser-A

User-B



V-MIMO

Receiver Abis

V-MIMO

TRX

Figure: Multiplexing in the Uplink.

Channel Rate AdaptationOSC in the Downlink direction has an approximate 3 dB reduction in performance (incomparison with AMR HR), thus it may not be applicable for the most demanding radioconditions. Through employing AMR Full Rate and AMR Half Rate together with the newOSC Half Rate capability, the network capacity can be increased without compromisingthe voice quality (arising from the 3dB reduction). Typically, OSC Half Rate may be usedin over 50% of connections. The allocation of different channel rates in relation to thecarrier to interference (C/I) ratio is depicted in the figure below:

(0,0)

(0,1) (1,1)

(1,0)I

Q (User-A, User-B)

(0,0)

(0,1) (1,1)

(1,0)I

Q (User-A, User-B)




HRFR DHRHR DHRDHRDHR

C/Ic.d.f.

~8 dB~10%

~12 dB~50%



C/Ic.d.f.

~8 dB~10%

~12 dB~50%

Figure: Channel Rate Adaption for AMR Full Rate, Half Rate and OSC Half Rate.

The existing AMR channel rate adaptation solution, that is, packing / upacking is extendedfor OSC Half Rate by introducing new quality and Rx level thresholds.

With OSC Half Rate with SAIC MS, the target channel for OSC packing is always aTCH/H where an AMR call is currently ongoing and which offers a sufficient signal leveland quality. For an ongoing AMR HR connection, another appropriate AMR call (wherethe Uplink Rx levels of the connections may be adjusted sufficiently closely) is searchedfor.

With the OSC multiplexing procedure, an AMR call is handed over to the target TCH. Theoriginal channel rate of the AMR connection to be handed over may be either Half Rate orFull Rate. Consequently, a direct multiplexing from AMR FR to OSC HR is possible. Thetarget for the multiplexing handover is however a TCH/H.

Unpacking (de-multiplexing) of an OSC HR channel, may either result from a deterioratingquality of an OSC HR connection or by the weakening of the Uplink Rx level balancebetween the OSC Sub-channels. In the former case, de-multiplexing is performed (bydefault) to a Full Rate TCH. However, with BSS21120, “AMR Unpacking Optimisation”,the de-multiplexing Handover may be to either a Half Rate TCH or a Full Rate TCH,depending upon the radio conditions. If the reason for de-multiplexing is the excessiveUplink Rx level difference between the multiplexed calls, the handover is primarily madeto a Half Rate TCH.

With BSS21483, “Improved AMR Packing and Unpacking”, the de-multiplexing Handovermay also be triggered based upon the connection specific Rx level criteria introduced bythe feature.

Power Control with OSCIn the Downlink, power control is naturally common for both Orthogonal Sub-channels,consequently, the highest Tx power required is that which is employed. In the Uplink, thereceived power at BTS is aligned by means of power control and an appropriate userpairing.




Double Stealing for FACCH The BTS steals voice blocks from both the OSC Sub-channels and sends GMSK insteadof QPSK for FACCH signalling in order to boost the FACCH performance. If the FACCHoccurs simultaneously in both OSC Sub-channels or a SID frame is sent in another thenQPSK is employed. The feature, BSS20916, “AMR HO Signalling Optimisation” may beemployed to enhance performance in terms of Call Drop Rate and MOS Statistics (sincefewer FACCH blocks are then needed during a Handover procedure).

Dynamic Allocation of Abis Resources from a Shared Pool It is important to consider, that employing OSC Half Rate will always require additionaltransport capacity, since two 8kbit/s Abis Timeslots are required to support the pairedOSC Half Rate Calls (OSC-0 and OSC-1). That is, a maximum of four 8kbit/s AbisTimeslots are now required for a single Radio Timeslot. There are two practical solutionsfor this, to either employ:

1. A Packet Abis solution (BSS21454, Packet Abis over IP/Ethernet orBSS21440, Packet Abis over TDM)

2. BSS30385, Circuit Switched Dynamic Abis Pool (CSDAP)

Please refer to the appropriate sections of this document for further details. The Sub-channel OSC-0 uses the existing Abis transport resources and the legacy TSC of theTRX.

BSC Capacity AspectsThe voice channel handling capacity of the BSC remains unchanged with the introductionof the OSC Half Rate with SAIC MS feature. With Half Rate, when defining the maximumallowed channel configuration for a BSC (or rather, BCSU), the BSC calculates all HRcapable Radio TSLs as two channels. With OSC Half Rate, when defining the maximumpossible configuration for a BCSU, the BSC calculates an AMR HR capable Radio TSLwhere OSC Half Rate is enabled as three channels. This must be accounted for duringthe planning for deployment of OSC.

Operational Aspects :

A sufficient LAPD signalling link capacity is required in order to manage the increasedradio measurements and signalling resulting from the increased number of calls per TRXwith OSC. A minimum 32kbit/s LAPD signalling link is required when OSC is enabled in aTRX.

The triggering of OSC Half Rate multiplexing is based upon the traffic loading in a BTS.The triggering load limit - “Limit for Triggering OSC DHR Multiplexing” - is a newparameter, based upon a similar definition for load as that for the traditional parameterswith AMR Half Rate Packing. The load limit parameter also serves as a BTS specificcontrol function for the feature, with which it is possible to turn the feature ON and OFF ina particular BTS.

OSC Half Rate is not applied to Emergency Calls.




Impor tan t Log i s t i c s Note : This feature item (BSS21309) is valid for up to 100simultaneous OSC HR Call Pairs in total for one BSC. The additional item BSS101419“OSC HR Capacity Licence” is required for additional OSC capacity beyond this initial

allocation and is required for each step of 100 simultaneous OSC HR Call Pairs per BSC.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S151)

- Y 2) N N Y 3) Y 4) N 5) - - - - Y6)

LicenceKey

Control

1) The features (and licence keys for) BSS30060, “AMR Capacity (HR)” and BSS01073, “Rx Diversity” are

required. The feature BSS20082, “Support for Single Antenna Interference Cancellation” is optional.2) The feature is supported with the RG25 (BSS) Release. Also:I. Either EDGE or OSC is supported within one TRX Module - both cannot be supported within the

one Module.

II. If Baseband Hopping is used, then all of the carriers within a BTS Object must be of type OSC orEDGE.

3) This feature is also supported by the existing Flexi EDGE BTS Dual TRX Module, but not with the fullfeature capability:

I. Either EDGE or OSC is supported within one Dual TRX Module - both cannot be supportedwithin the one Dual TRX Module.


The new version of the Flexi EDGE BTS Dual TRX is required for full compatibility.4) The feature is supported with the RG25 (BSS) Release.5) Supported via RG301397, Cositing with BS2xx.6) A 3GPP Rel.6 capable Handset is required - The Handset must indicate its support for SAIC to the

network.

5.1.3 Circuit Switched Dynamic Abis Pool


Summary : Since two 8kbit/s Abis Timeslots are required to support the paired OSC HalfRate Calls (OSC-0 and OSC-1) with BSS21309, then practically either a Packet Abissolution or the Circuit Switched Dynamic Abis Pool (CSDAP) feature is required in orderto support the additional Abis capacity that must be managed when employing OSC.

Functional Description : For the standard Abis interface, a fixed 16kbit/s transmissioncapacity is allocated for each Radio Timeslot (TSL) from the available Abis ETPCM.When BSS21309, “OSC Half Rate with SAIC MS” is deployed, then additional Abistransmission capacity is necessary for each Radio TSL, since two (OSC) Half Rate Callsare now multiplexed on to one single Half Rate TCH. Although possible, it is generally notefficient to allocate double the fixed transmission capacity for each Radio TSL, since theextra transmission capacity is only necessary during higher load scenarios, when OSC

Calls are activated within the cell. Alternatively, the new Circuit Switched Dynamic AbisPool feature offers the possibility to create and manage common transmission pool(s) -shared capacity - for OSC Half Rate Calls within the BCF.




Figure: CSDAP Timeslot Allocation within the Abis.

Circuit Switched Dynamic Abis Pool(s) (CSDAPs) are created per BCF (BTS Site) andshared by all TRXs within the BCF. Up to four CSDAPs are possible per BCF, with up toa maximum of 1000 CSDAPs supported per BSC.

A CSDAP may be allocated to the same or indeed a different Abis ETPCM than thatwhich is being used by the TRX, but it must be created using consecutive PCM Timeslots(as illustrated in the figure above). Thus, the size of a CSDAP ranges from 1…31 TSL foran E1 (respectively 1…24 for a T1), with a granularity of 1 PCM Timeslot. If required, thetransmission resources for all TRXs of a BCF cabinet may be allocated to one singleCSDAP.

Note that since the OSC Half Rate CS Calls are independent, then no synchronisation isnecessary between the TRAU Frames associated with the paired OSC-0 / OSC-1 Calls.

Benefits for the Operator : The Operator avoids the need to configure additional fixed Abis transmission capacity when taking OSC Half Rate into use through the CSDAPfeature, which then provides a CAPEX/OPEX efficient solution.






BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - Y 1) N N Y Y 1) N 2) - - - - - LicenceKey

Control

1) The feature is supported with the RG25 (BSS) Release.2) Supported via RG301397, Cositing with BS2xx.

5.1.4 Merged P- & E-GSM900


Summary : A number of P-GSM / E-GSM feature enhancements have already beenprovided in earlier software releases. This feature complements these through combiningthe P-GSM and E-GSM frequency bands into one and removing the specific handlingpreviously required for P-GSM only handsets.

Benefits for the Operator : This new feature introduces an improved spectral efficiencythrough the merging of the P-GSM and E-GSM Bands. Furthermore, the generaloperability of the network is improved and simplified.

Functional Description : Originally, PGSM900 and EGSM900 resources were managedseparately and configured as separate cells within the BSC, with handover supportbetween them. Over later software releases (BSS11.5, BSS12 and BSS13) a number ofenhancements were realised in order to increase the integration of the two frequencybands.

Up to the RG20 (BSS) Release, PGSM900 and EGSM900 frequencies can be usedwithin a single BTS object and support for PGSM-only handsets has been maintained.However, in cases where the BCCH carrier of a PGSM900-EGSM900 BTS is on thePGSM900 frequency band there are currently operational aspects that must be

considered, which would be unnecessary if all GSM900 handsets in the network alsosupported the EGSM900 band.




These operational aspects are:

• It is possible to combine PGSM900 and EGSM900 frequencies only in the

BCCH BTS and with such a BCCH BTS it is not possible to employGSM900 frequencies in any other BTS object of the segment

• It is not possible to use RF Hopping and (E)GPRS on the same TRX

• Baseband Hopping cannot be employed

• It is not possible to use super reuse TRXs

• DFCA Hopping cannot be employed

• Static SDCCH resources must be configured for the PGSM900 TRXs

• The BSC limits the dynamic reconfiguration of SDCCHs to be within thePGSM900 TRXs

• The BSC limits the actions of FACCH setup to be within the PGSM900TRXs

• The feature High Speed Circuit Switched Data is not supported

It would no longer be necessary to consider these if it can be assumed that all GSM900

handsets in the network support EGSM900. This is the basis for this RG20 (BSS)feature, Merged PGSM900 and EGSM900, which complements the existing PGSM900-EGSM900 feature enhancements, combining the two frequency bands into one andremoving the specific handling previously required for PGSM-only handsets. The featurethen eliminates the above operational aspects.

Note that generically for GSM systems, the maximum number of available GSM900frequencies in a PGSM900-EGSM900 segment is 16 (17 if ARFCN 0 is included).

This RG20 (BSS) feature represents the final step in a series of enhancements that havebeen introduced.

A new parameter for the segment control of the feature will be implemented.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - (Y) (Y) (N) (Y) (Y) 1) (Y) - - - - Y2)

LicenceKey

Control

1) The feature is supported with the RG25 (BSS) Release.2) An EGSM900 capable Handset is required.




5.1.5 OSC Full Rate with SAIC MS


Summary : The RG20 (BSS) Release enabled the possibility for OSC Half Rate to beintroduced into the network, providing significant and otherwise unachievable , Capacityand Spectral Efficiency improvements for the Operator. RG25 (BSS) now introducesOSC Full Rate for UltraSite, Flexi EDGE and Flexi Multiradio BTSs.

Benefits for the Operator : Whereas OSC Half Rate targets Capacity / SpectralEfficiency enhancements in the network; the advantage provided by OSC Full Rate is aQuality improvement. It is estimated that with OSC Full Rate the quality increase in MOS(Mean Opinion Score) could vary between 0.2 and 0.35, over that achievable withstandard AMR Half Rate.

Another advantage of OSC Full Rate is the enhanced dynamic behaviour achievedthrough interleaving over 8 bursts (with OSC Full Rate), in comparison with interleavingover 4 bursts (used for AMR Half Rate).

Most importantly, as for OSC Half Rate, contra to the 3GPP Rel.9 VAMOS (Voiceservices over Adaptive Multiuser Orthogonal Sub channels) capability, which of courserequires the availability and sufficient penetration of Rel.9 Handsets, with the NokiaSiemens Networks OSC solution, the existing Handsets supporting AMR and SAIC aresufficient. This is available today and thus operators can derive the full gains from OSCimmediately .

Functional Description : The RG20 (BSS) Release enabled the possibility for OSC HalfRate to be introduced into the network, providing significant and otherwiseunachievable , Capacity and Spectral Efficiency improvements for the Operator. Themotivations for deploying OSC Full Rate differ from those for OSC Half Rate - OSC HalfRate targets Capacity, whereas OSC Full Rate targets Quality. Both features enhanceCapacity and Spectral Efficiency, however, OSC Full Rate can be used to increasecapacity in Cells which are otherwise spectral and/or quality constrained. In comparisonwith standard AMR Half Rate, a performance improvement is achieved for the samenumber of allocated Calls. That is, the utilisation of CODEC modes with high source bitrates (of up to 12.2kbit/s) is possible, in comparison with the case for AMR Half Rate,where the source bit rate is limited to 7.4kbit/s. Generally, the procedures andmechanisms employed for OSC Half Rate are also applicable for OSC Full Rate.

OSC Full Rate does not increase the potential TRX voice channel capacity - up to 16Calls per TRX are supported - which can also be achieved using Half Rate channels.However, two narrowband AMR FR calls multiplexed into a single TCH/F with OSC FullRate will provide a better End-user experience through improved voice quality incomparison with standard AMR Half Rate.

The OSC Full Rate and OSC Half Rate features may be used in parallel. In this scenarioit may happen that the criteria for each of the two procedures are met simultaneously. Ifthis is the case, the BSC will first attempt to initiate OSC Half Rate multiplexing and ifunsuccessful, it will then try to initiate OSC Full Rate multiplexing.




When both AMR Half Rate Packing and OSC Full Rate multiplexing are in use in a BTS,the BSC will perform OSC Full Rate multiplexing only for the AMR Full Rate calls whichhave sufficient Rx quality for OSC Full Rate multiplexing and insufficient Rx quality for

AMR Half Rate Packing. That is, AMR Half Rate Packing is preferred, if possible.

As is the case for OSC Half Rate, it is important to consider that employing OSC Full Ratewill generally require additional transport capacity, since two 16kbit/s Abis Timeslots arerequired to support the paired OSC Full Rate Calls (OSC-0 and OSC-1). That is, amaximum of two 16kbit/s Abis Timeslots are now required for a single Radio Timeslot.There are three practical solutions for this, to either employ:

1. A Packet Abis solution (BSS21454, Packet Abis over IP/Ethernet orBSS21440, Packet Abis over TDM)

2. BSS30385, Circuit Switched Dynamic Abis Pool (CSDAP)

3. BSS21325, 8k TRAU for OSC AMR FR

Please refer to the appropriate sections of this document for further details. Note thatthrough employing the 8k TRAU for OSC AMR FR capability, the existing legacy Abistransmission solution remains unaffected.

Note that for the UltraSite BTS type, either solution (2) or (3), above, may be employed.

With OSC Full Rate, when defining the maximum possible configuration for a BCSU, theBSC calculates an AMR FR capable Radio TSL in a BTS where OSC Full Rate is enabled

as two channels.

Operational Aspects : Following a similar philosophy as employed for OSC Half Rate, anew parameter “Limit for Triggering OSC DFR Multiplexing” indicates the triggering loadlevel for OSC Full Rate multiplexing. Furthermore, the load limit parameter also serves asa BTS specific control function for the feature, with which it is possible to turn the featureON and OFF in a particular BTS (as per OSC Half Rate).

As is the case for OSC Half Rate, OSC Full Rate increases TRX signalling in comparisonwith AMR Full Rate. Consequently, the Operator is recommended to define at minimum32kbit/s LAPD signalling link when OSC Full Rate is enabled for a TRX.

As per OSC Half Rate, OSC Full Rate is not applied to Emergency Calls.

Impor tan t Log i s t i c s Note : This feature item (BSS21534) is valid for up to 100simultaneous OSC FR Call Pairs in total for one BSC. The additional item BSS402011“OSC FR Capacity Licence” is required for additional OSC capacity beyond this initialallocation and is required for each step of 100 simultaneous OSC FR Call Pairs per BSC.






BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG25 S15EPx.0

1)

- Y 2) N N Y 3) Y N 4) - - - - Y5)

LicenceKey

Control

1) The features (and licence keys for) BSS20249, “AMR FR Licence Control” and BSS01073, “RxDiversity” are required. The feature BSS20082, “Support for Single Antenna Interference Cancellation”is optional.

2) For the UltraSite EDGE BTS TRX:I. Either EDGE or OSC is supported within one TRX Module - both cannot be supported within the

one Module.


3) This feature is also supported by the existing Flexi EDGE BTS Dual TRX, but not with the full featurecapability:

I. Either EDGE or OSC is supported within one Dual TRX Module - both cannot be supportedwithin the one Dual TRX Module.


The new version of the Flexi EDGE BTS Dual TRX is required for full compatibility.4) Supported via RG301397, Cositing with BS2xx.5) A 3GPP Rel.6 capable Handset is required - The Handset must indicate its support for SAIC to the

network.

5.1.6 8k TRAU for OSC AMR FR


Summary : BSS21325, 8k TRAU for OSC AMR FR enables the possibility to activate twoOSC AMR Full Rate Calls within the fixed transmission allocated for a single radioTimeslot using a legacy Abis connection.

The two OSC AMR Full Rate Calls are transferred inside the legacy Abis transmissionallocated for a single radio Timeslot (that is 2x 8kbit/s Abis Timeslots) when 8kbit/s TRAU

Frames are used on the Abis and AMR CODECs are limited to 7.4k (that is, 7.4k, 5.9k or4.75k) for the OSC Full Rate Call. The OSC-0 Call is transferred in the first half and theOSC-1 Call transferred in the second half of the Abis Timeslot.

Benefits for the Operator : BSS21325 increases the range of solutions possible for OSCFull Rate. It enables operators to activate OSC Full Rate in a BTS, without making anychanges to the existing legacy Abis transmission. Naturally, the alternative Packet Abissolution could be used instead. Note that the 8k TRAU for OSC AMR FR feature offersan effective 100% Abis Capacity gain for OSC Full Rate in comparison with the CSDAPcapability.




An OSC Full Rate call enabled with the 8k TRAU for OSC AMR FR feature, provides animproved speech quality beyond that possible with AMR Half Rate, even though the samelegacy Abis transmission is utilised.

The CSDAP feature may also be active simultaneously with 8k TRAU for OSC AMR FR -The preferred solution being defined by parameter.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



1)

- Y N N Y Y N 2) - - - - - LicenceKey

Control

1) The feature (and licence key for) BSS21534, “OSC Full Rate with SAIC MS” is required.2) Supported via RG301397, Cositing with BS2xx.




5.2 Packet Switched Data

5.2.1 DL DC Territory Procedures

Feature ID: BSS21343

Summary : This feature enhances the territory handling procedures such that by defaultan operator is able to maintain a smaller PS territory, which may then be extended uponrequirement - when a Downlink Dual Carrier (DL DC) capable terminal enters the cell.

Benefits for the Operator : The operator must no longer configure RTSL for PS data inorder to reserve capacity for DL DC terminals, since this can now be performed on an asrequired basis.

Functional Description : This feature enhances the existing Downlink Dual Carrierfeature capability. Without these territory procedures DL DC allocation is possible only incases where there are RTSLs configured for PS data on two TRXs (that is, PS territory ontwo TRXs) in a cell. Consequently, the operator must configure a greater amount ofRTSLs by default for PS services. In practice this does not decrease the CS voicecapacity in a cell since CS voice has a higher priority than PS data (and consequently thePS territory would be downgraded to allow room for more CS voice calls). However, forscenarios such as the voice Busy Hour, this feature realises a mechanism to provideexisting DL DC capable terminals with DL DC allocation for the case that the territory wasdowngraded at the time the initial allocation was made for the PS data connection. Withthis feature, the PCU requests more RTSL to the PS territory in order to give DL DCcapable terminals allocation on 2 TRXs.

Figure: Territory Handling Procedure Enhancement.

TRX 1 (BCCH)

TRX 2

CC SD SD PS PS PS PS PS

CS CS CS PS PS PS PSCS

Territory enhancesdynamically toanother carrier dueto DL DC allocation,if CS traffic loadallows it, becauseCS has priority overPS.

TRX 3CS CS CS CS CS CS CSCS

TRX 4 CS CS CS CS CS CS CSCS






BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 Y 1) Y Y N Y Y 2) Y - - - - Y3)

4)

1) The PCU2 is required.2) The feature is supported with the RG25 (BSS) Release.3) A 3GPP Rel.7 capable Handset is required.4) The feature (and licence key for) BSS21228, Downlink Dual Carrier is required.

5.2.2 TRX Specific Link Adaptation for DLDC


Summary : Since the radio conditions of the individual carriers belonging to a DownlinkDual Carrier configuration are different, it is beneficial to adapt the used MCS codingschemes separately.

Benefits for the Operator : Enhanced throughput for services. Improved end usedexperience.

Functional Description : For this capability, the PCU uses the individual carriermeasurement reports from the Handset during Downlink Dual Carrier allocation tooptimise the utilised MCSs in the Downlink individually in order to enhance thethroughput.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 Y 1) Y Y N Y Y 2) Y - - - - Y

3)

4)

1) The PCU2 is required.2) The feature is supported with the RG25 (BSS) Release.3) A 3GPP Rel.7 capable Handset is required.4) The feature (and licence key for) BSS21228, Downlink Dual Carrier is required.




5.2.3 Inter-BSC NACC


Summary : The Inter-BSC Network Assisted Cell Change (IB-NACC) feature is anextension to the existing BSS11.5 feature, Network Assisted Cell Change (NACC).Currently, NACC supports cell changes executed among cells which are under the controlof a single BSC. IB-NACC extends the benefits introduced with NACC to all of the cellsacross the entire GSM/EDGE network. IB-NACC is based on the 3GPP Release 5 RANInformation Management (RIM) protocol and the NACC RIM application.

Benefits for the Operator : An improved end user experience and increased revenuethrough improved quality and call success rates. Inter-BSC NACC enables a constantcell change performance over the entire GSM/EDGE network. Reduced cell reselection

times enable services requiring high throughput or short delay times. Further,applications can operate with shorter data buffering. The improved end user experiencesupports the operator in retaining customers.

Functional Description : Upon entering a new cell, the Handset must first acquire the cellSystem Information. The network broadcasts the cell system information in severalseparate BCCH messages following a periodic cycle. The Handset must first receive thisbasic cell system information before it can access the cell. Without the NACC solution,the time required to receive the relevant information depends upon the system informationmessage repetition rate and also the cell change timing in relation to the systeminformation message transmission cycle. Consequently, when NACC is not used the cell

change causes a variable and significant data transmission outage.

With NACC, the network sends an initial set of cell system information to the Handsetwhen it's still camping on the originating cell. This initial set of information contains thedetails required by the Handset in order to be able to access the target cell. Once theHandset has accessed the target cell and started data transmission the network thensends further cell system information on the Handset specific associated signallingchannel.

Inter-BSC NACC enabled by the RAN information management protocol, RANInformation Management (RIM), is a part of the BSSGP protocol. BSSGP allowsmessage transport via the Gb-interface. 3GPP Release 5 defines new messagesenabling the RIM procedures.

The RIM protocol also allows for information exchange between two BSS. The Gn-interface GTP protocol also needs the support of RIM message transport and routing.The Core Network performs the routing of the RAN Information to the correct BSS basedon the cell identification. The actual data included in the RAN Information is transparentfor the Core Network.

RIM is a generic protocol employed to deliver information between the BSS. NACC is thefirst application which utilises RIM.

The BSS requiring information is called the controlling BSS; and the BSS providing theinformation is called the serving BSS. A single BSS can of course realise both roles, thatis, requesting information from cells whilst at the same time providing information to




another BSS (that is, for the Inter-BSC NACC feature, the system information may betransferred bi-directionally between the two BSCs).

RIM has two operational modes. In the single request mode , the serving BSS sends therequested information only upon request. In the multiple request mode , the serving BSSmust deliver updates for the requested information if there is a change in the information.

The IB-NACC solution is based upon the multiple request RIM operation mode . When thePCU detects a cell change to a cell controlled by a different BSC it sends a RANInformation Request to the SGSN. The request contains the target cell identification. TheCore Network routes the request to the correct BSC (the BSC where the target cell islocated). The target BSC responds to the request by providing the requested target cellsystem information. The target BSC (where the target cell is located) stores the requestand provides all updates for requested cell system information. In case the adjacencybetween cells is removed or the cell GPRS capability is removed, the BSCs agree on

deleting the RAN Information relation.

Figure: Inter-BSC RAN Information flow.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S151)

Y 2) Y Y N Y Y 3) Y - X 4) - - Y5)

LicenceKey

Control

1) Note that the feature, BSS11506, Network Assisted Cell Change (NACC) is required.2) The PCU2 is required.

3) The feature is supported with the RG25 (BSS) Release.4) RIM (RAN Information Management) Support is required from the PS Core Network.5) A 3GPP Rel.5 Handset is required.




5.2.4 Inter System NACC


Summary : Inter System NACC (Network Assisted Cell Change), IS-NACC, enables anRNC to request NACC reports from a GSM/EDGE BSC. The NACC information is usedwhen an Handset executes a cell change from a WCDMA Cell to a GSM/EDGE Cell.Note that for the opposite case, the BSC does not request NACC reports from an RNCsince this does not impact the actual cell reselection outage time.

The RNC sends the necessary neighbour cell System Information messages to theHandset in the serving cell before the actual cell change occurs, therefore, the TBF canbe established quickly in the target cell.

Benefits for the Operator : Minimised service outage in conjunction with WCDMA GSM/EDGE cell re-selection. Cell change times (WCDMA GSM/EDGE) may bereduced by around 1 Second.

The improved end user experience supports the operator in retaining customers.

Functional Description : Upon entering a new cell, the Handset must first acquire the cellSystem Information. The network broadcasts the cell system information in severalseparate messages following a periodic cycle. The Handset must first receive this basiccell system information before it can access the cell. Without the NACC solution, the timerequired to receive the relevant information depends upon the system information

message repetition rate and also the cell change timing in relation to the systeminformation message transmission cycle. Consequently, when NACC is not used the cellchange causes a variable and significant data transmission outage.

With NACC, the network sends an initial set of cell system information to the Handsetwhen it's still camping on the originating cell. This initial set of information contains thedetails required by the Handset in order to be able to access the target cell. Once theHandset has accessed the target cell and started data transmission the network thensends further cell system information on the Handset specific associated signallingchannel.

The WCDMA source system must have the necessary information available about thetarget BSC - solved via the RIM procedures that are carried transparently across the CoreNetwork.

The WCDMA source system must also be able to transmit the information to the Handset- provided by the air interface Rel.5 RRC support.




Figure: Inter System RAN Information flow.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S151)

Y 2) Y Y N Y Y 3) Y - X 4) - X 5) Y6)

LicenceKey

Control

1) Note that the features, BSS11506, Network Assisted Cell Change (NACC) and BSS20083, Inter-BSCNACC are required.

2) The PCU2 is required.3) The feature is supported with the RG25 (BSS) Release.4) Inter System RIM (Radio Information Message) Support is required from the PS Core Network.5) Inter System RIM (Radio Information Message) Support is required from the WCDMA RAN.6) A 3GPP Rel.5 Dual mode GPRS/EDGE Handset is required.




5.2.5 Inter System NACC for LTE


Summary : The Inter System NACC for LTE solution extends the NACC support toinclude GSM/EDGE - LTE Interworking, providing a similar improvement as is realised forthe Inter System NACC (WCDMA) solution.

Inter System NACC for LTE enables the LTE RAN to request NACC reports from aGSM/EDGE BSC. The NACC information is used when a Handset executes a cellchange from an LTE Cell to a GSM/EDGE Cell. Note that for the opposite case, the BSCdoes not request NACC reports from the LTE RAN since this does not impact the actualcell reselection outage time.

The LTE RAN sends the necessary neighbour cell System Information messages to the

Handset in the serving cell before the actual cell change occurs, therefore, the TBF canbe established quickly in the target cell.

Benefits for the Operator : Minimised service outage in conjunction with LTE GSM/EDGE cell re-selection.

Furthermore, a faster Voice Call fallback solution from LTE to GSM can be provided,important for example, for Emergency Calls.

The improved end user experience also supports the operator in retaining customers.

Functional Description : The Inter System NACC for LTE solution extends the NACCsupport to include GSM/EDGE - LTE Interworking, providing a similar improvement as isrealised for the Inter System NACC (WCDMA) solution.

Furthermore, the Inter System NACC for LTE feature may be used ( where RIM issupported ) as an extension for the CS Fallback Voice Call Continuity solution.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S151)

Y 2) Y Y N Y Y 3) Y - X 4) - X 5) Y6)

LicenceKey

Control

1) Note that the features, BSS11506, Network Assisted Cell Change (NACC) and BSS20083, Inter-BSCNACC, are required.

2) The PCU2 is required.3) The feature is supported with the RG25 (BSS) Release.4) Inter System RIM (Radio Information Message) Support is required from the PS Core Network.5) Inter System RIM (Radio Information Message) Support is required from the LTE RAN.6) A 3GPP Rel.8 Dual/Tri mode GPRS/EDGE Handset is required.




5.3 Transmission & Transport

5.3.1 A over IP

Feature ID(s) :

1. BSS21341 - A over IP, Transcoder in BSS

2. BSS30380 - A over IP, Transcoder in MGW

Summary : There are two architecture options:

1. Transcoder function is located in the BSS - BSS21341

2. Transcoder function is located in the Core Network - BSS30380

Figure: Architecture Options for A over IP.

Note that the configuration of Legacy Abis and A over IP with Transcoder in the MediaGateway (MGW) is a Feature Candidate for the RG30 (BSS) Release (please see belowfor details).

Benefits for the Operator : The key benefit arises from the CAPEX / OPEX savings thatcan be derived through employing IP networking. The flexibility of the solution is alsoincreased. Further, configuration is also simpler in Multipoint A type network scenarios.

With Transcoder in the BSS, the existing transcoder capacity can be used along with thenew IP-connectivity at the A-interface.

With Transcoder in the Core Network, voice quality is enhanced since tandem coding isno longer necessary and latency is also improved. A reduced transcoding capacity isrequired in the BSS (realised in the Core Network).

ETP-A MGW

Requires Packet Abis

Aover IP

BTSETP-A

MGW A

over IP

TCSM3i

Abis orPacket Abis




Functional Description : There are two architecture options:

1. The Transcoder function is located in the BSS (that is, the standard GSM architecture).The Transcoder is the A over IP termination point.

The G.711 / RTP / IP protocol is employed.

2. The Transcoder function is located in the Core Network (that is, the 3G networkarchitecture). The BSC is the A over IP termination point. At the same time, the BSChides the mobility from the Core Network.

The CODECx / RTP / IP protocol is employed.

The supported scenarios are:

Figure: Packet Abis Scenarios in combination with A over IP.

Figure: Legacy Abis Scenario in combination with A over IP.

The fourth alternative of Legacy Abis & A over IP with Transcoder in the Media Gateway(MGW) is a Feature Candidate for the RG30 (BSS) Release.

BTSLegacy Abis

ETP- R4 Core

Aover IP

TCSM3

Flexi BSC or BSC3i 1000/2000

Legacy Abis + AoIPTC in BSS

ETPETP-A

CorePacket Abisover IP/Eth

Aover IP

ETP

Packet Abisover TDM

ETS2ETP-

Core Aover IP

TCSM3

Flexi BSC or BSC3i 1000/2000FlexiEDGE

FlexiEDGE

Packet Abis + AoIPTC in MGW

Packet Abis + AoIPTC in BSS




For the Transcoding in BSS scenario, the ETP-A module is required for the TCSM3i,which is managed from the BSC via Ethernet. For this configuration both A over TDMand A over IP are supported within the same TCSM3i. The Abis interface may be eitherPacket Abis (requiring both the ETS2 and ETP modules) or Legacy Abis.

When transcoding is performed within the Core Network, then the Abis interface must bea Packet Abis type. Calls to Handsets on Packet Abis are routed on A over IP directly tothe Core Network transcoder. Calls to Handsets on a Legacy Abis are routed via theTCSM3i to the Core Network (as normal). A handover between a Packet Abis BTS and aLegacy Abis BTS is managed by the Core Network as an “Internal Handover”.

Dependency Table:BSS BSC DX200


BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S151)

Y 2) Y 3) Y 3) N Y 3) Y 3) 4) Y 3) - - Y 5) - - LicenceKey

Control

1) The feature (and licence key for) BSS21323, L3 Connectivity for Flexi BSC product family is required.Furthermore, for the “Transcoder in Core Network” scenario either:I. BSS21440, Packet Abis over TDM or

II. BSS21454, Packet Abis over IP/Ethernet is required.2) The BSC3i 1000/2000 or Flexi BSC (and optionally the TCSM3i) along with the ETP-A interface module

are required:I. BSC3i 1000 (one cabinet): 2 ETP-A Modules.

II. BSC3i 2000 and Flexi BSC (two cabinets): 4 ETP-A Modules.III. TCSM3i (RG10 or earlier): 3 Modules per cabinet.IV. TCSM3i (RG20): 5 Modules per cabinet.V. With the ETP-A Module in the BSC, the LAN switch extension for BSC3i 1000/2000 and Flexi BSC

with the latest LAN switch version (ESB24-D) is necessary.3) For the “Transcoder in Core Network” scenario either the Flexi EDGE (or Multiradio) BTS is required.4) The feature is supported with the RG25 (BSS) Release.5) The MSC Release M15 is required.




5.3.2 Abis Delay Measurement (TDM, PWE3)


Summary : Abis delay measurement for either TDM based networks or networks utilisingintegrated / standalone pseudo-wire equipment solutions.

Benefits for the Operator : It is increasingly important for operators to be able to monitorthe SLA levels of their TDM and PSN backhaul leased lines realised with pseudo-wiresolutions since this impacts the EDGE throughput and call success rate. Even for E1leased line cases today there is a reduction in transparency of the supporting technology,since it may be satellite Abis, CESoPSN etc… which introduce delay.

Functional Description : Through looping back a Timeslot in the BSC, the bi-directionaldelay is measured in the BTS. The network delay is the delay between the networkinterfaces of the NE's involved:

Figure: Delay components of the measurement delay.

The end-to-end delay is the measured delay from measurement entity to measuremententity. This delay includes the network delay and the delay through entities inside theNE's (e.g. network interfaces). This is valid for both user- and signalling-traffic in currentimplementations of TDM and PWE network interface cards and also if standalone

pseudo-wire (PWE) equipment solutions are used.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 Y 1) N N N Y 2) Y 2) 3) N - - - - - LicenceKey

Control

1) For the integrated CESoPSN solution, the BSC3i 1000/2000 or Flexi BSC with supporting interface isrequired.

2) A FIEA / FIPA / FIFA / FIYA / FIQA Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.3) The feature is supported with the RG25 (BSS) Release.

TDMdatanetwork

TDMdataMeasuremen

tentity

round trip

Networkinterface

Networkinterface

BTS BSC

BTS internal delay BSC internal delaynetwork delay

BTS internal delay BSC internal delay




5.3.3 Packet Abis over IP/Ethernet


Summary : This fully integrated feature enables the transport of Abis information using nativeIP over Packet Switched Networks (via Ethernet).

Benefits for the Operator : The operator is able to employ Packet Switched Networks in orderto provide the transport backhaul for the Abis traffic, offering significant OPEX savings due tothe more cost effective physical media (Ethernet) and the simplified operation andmaintenance of the network that can then be derived. In addition to the physical media benefit,Packet Abis also offers significant bandwidth savings in comparison with traditional TDM- orPWE-based packet transport since it introduces a very efficient and fully integrated AbisOptimization capability. The integrated Abis Optimization also facilitates the introduction of

high bandwidth features such as EDGE Evolution and OSC without necessarily increasing thebackhaul bandwidth capacity requirement. Bandwidth can be shared by CS, PS and Signallingtraffic. There are no predefined limitations except the total available bandwidth provided by thephysical link.

Functional Description : The Packet Abis solution removes the traditional TDM Abis structure,where the static relationship between the Air and the Abis Interfaces is eliminated. Further,

Abis Optimization through the removal of silence and idle frames, multiplexing and bandwidthsharing for the CS-Userplane; PS-Userplane; Control-Plane and Management-Plane achievessignificant bandwidth savings. If no data needs to be sent then no capacity is occupied /utilised.

The Packet Abis U-Plane is transported over UDP/IP and the C-Plane/M-Plane is transportedover SCTP/IP. The physical interface supported is Ethernet.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 Y 1) N N N Y 2) Y 2) 3) N 4) - - - - - LicenceKey

Control

1) The feature (and licence key for) BSS21323, L3 Connectivity for Flexi BSC product family is required.Furthermore, the BSC3i 1000/2000 or Flexi BSC with the ETP interface module is required:I. BSC3i 1000 (one cabinet): 2+2 ETP Modules.

II. BSC3i 2000 (two cabinets): 6+6 ETP Modules.III. Flexi BSC: 6 + 6 ETP Modules.IV. With the ETP Module, the LAN switch extension for BSC3i 1000/2000 and Flexi BSC with the latest

LAN switch version (ESB24-D) is necessary.2) The FIYA / FIYB or FIQA / FIQB (depending upon the Synchronisation requirement) Module is

necessary for the Flexi EDGE (or Flexi Multiradio) BTS.3) The feature is supported with the RG25 (BSS) Release.4) Supported via RG301397, Cositing with BS2xx.




5.3.4 Packet Abis over TDM


Summary : This fully integrated feature enables the transport of Abis information using nativeIP over Time Division Multiplexed (TDM) Networks.

Benefits for the Operator : The operator can utilise the existing installed TDM Infrastructure,easing the introduction of the Packet Abis solution.

As for Packet Abis over Ethernet, Packet Abis over TDM also offers significant bandwidthsavings in comparison with traditional TDM transport since it introduces a very efficient andfully integrated Abis Optimization capability. The integrated Abis Optimization also facilitatesthe introduction of high bandwidth features such as EDGE Evolution and OSC without

necessarily increasing the backhaul bandwidth capacity requirement. Bandwidth can beshared by CS, PS and Signalling traffic. There are no predefined limitations except the totalavailable bandwidth provided by the physical links. This can result in E1/T1 leased line and/orMicrowave Radio license savings.

Functional Description : The Packet Abis solution removes the traditional TDM Abis structure,where the static relationship between the Air and the Abis Interfaces is eliminated. Further,

Abis Optimization through the removal of silence and idle frames, multiplexing and bandwidthsharing for the CS-Userplane; PS-Userplane; Control-Plane and Management-Plane achievessignificant bandwidth savings. That is, if no data needs to be sent then no capacity isoccupied/utilised.

The Packet Abis U-Plane is transported over UDP/IP/MLPPP and the C-Plane/M-Plane istransported over SCTP/IP/MLPPP. The physical interface supported is TDM.

Multiple E1 or T1 interfaces effectively provide a “virtual common bandwidth” using MLPPP.Packet Abis over TDM is supported by all existing FlexiEDGE BTS transport sub-modules,including FIFA. For the FIYA and FIQA Modules the TDM Interfaces are utilised.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



Control

1) The feature (and licence key for) BSS21323, L3 Connectivity for Flexi BSC product family is required.The BSC3i 1000/2000 or Flexi BSC with the ETP and a new version of the ETS2 interface module arerequired:I. BSC3i 1000 (one cabinet): 2+2 ETP Modules.

II. BSC3i 2000 (two cabinets): 6+6 ETP Modules.III. Flexi BSC: 6 + 6 ETP Modules.IV. With the ETP Module, the LAN switch extension for BSC3i 1000/2000 and Flexi BSC with the latest

LAN switch version (ESB24-D) is necessary.

2) The FIEA; FIPA; FIFA, FIYA or FIQA Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.3) The feature is supported with the RG25 (BSS) Release.4) Supported via RG301397, Cositing with BS2xx.




5.3.5 Packet Abis over Satellite


Summary : This feature enables the possibility for Packet Abis to be used across Satellite Links(either TDM or Ethernet based). Packet Abis is robust to the impairments introduced bySatellite links.

Benefits for the Operator : Significant CAPEX and OPEX savings can be realised byoperators since the fully integrated Abis Optimization function reduces the bandwidthrequirements for the cost intensive Satellite Link. Since the Packet Abis solution is fullyintegrated, operators do not need to invest in additional external Abis Optimization equipmentfor the Satellite connection.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



Control5)

1) The BSC3i 1000/2000 or Flexi BSC with:I. The ETP interface module is required for Packet Abis over IP/Ethernet.

II. The ETP and a new version of the ETS2 interface module are required for Packet Abis over TDM.2) The FIEA; FIPA; FIFA, FIYA or FIQA Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.3) The feature is supported with the RG25 (BSS) Release.4) Supported via RG301397, Cositing with BS2xx.5) Further, Packet Abis and Satellite Abis Software and Licence Keys are required.

5.3.6 Packet Abis Security


Summary : This feature introduces integrated IP Security for Packet Abis over Ethernetapplications. IPSec Authentication provides measures against “man in the middle” attacks andis implemented for the CS- & PS-Userplanes; C-Plane and M-Plane. IPSec Encryptionmeasures ensure privacy (against eavesdropping) and are implemented for the CS-Userplane.IPSec Integrity measures provide protection against unauthorised data modification for the CS-& PS-Userplanes; C-Plane and M-Plane.

Benefits for the Operator : CAPEX/OPEX savings for the operator. Operators who intend touse public Packet Switched Networks for the transport solution will certainly face securityissues when they implement a native IP capability. This Packet Abis Security solution offers afully integrated security capability without the need for external hardware. It will also simplifymaintenance since it is managed by existing Network Elements.






BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



Control

1) The BSC3i 1000/2000 or Flexi BSC with supporting interface module is required.2) The FIYA / FIQA Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.3) The feature is supported with the RG25 (BSS) Release.4) Supported via RG301397, Cositing with BS2xx.

5.3.7 Packet TRS for UltraSite / BTSplus


Summary : This feature enables Abis transport over Packet Switched Networks (Ethernetbased) for existing UltraSite and BTSplus Base Station systems by means of a hardwareupgrade for the BTS (with the ESMx Module). The ESMx Module performs a TDM - Ethernet(CESoPSN) conversion. In addition to the basic media conversion provided, it also allows asmooth upgrade to support features such as OSC and EDGE Evolution (via a co-sitedFlexiEDGE BTS).

Benefits for the Operator : The operator is able to employ a Packet Switched Network tosupport the transport backhaul for the Abis traffic, offering significant OPEX savings from themore cost effective physical media (Ethernet) and also a simplified operation and maintenanceof the network.

Furthermore, operators are also able to protect their investment, through upgrading existingBase Stations with the new ESMx Module, allowing a smooth upgrade to support features suchas OSC and EDGE Evolution (via a co-sited FlexiEDGE BTS).

Dependency Table :

BSS BSC DX200Platform BTSUltraSite

BTSMetroSite

BTSTalkFamily

BTSFlexiEDGE

BTS FlexiMultiradio BTSBTSplus NetAct SGSN MSC RAN MS Licensing

Release RG20 S15 Y 1) Y 2) N N N N Y 2) - - - - - LicenceKey

Control

1) For the integrated CESoPSN solution, the BSC3i 1000/2000 or Flexi BSC with supporting interface isrequired.

2) The ESMx Module with media conversion capable software is required for the UltraSite and BTSplusBTSs.




5.3.8 Packet Abis Congestion Reaction


Summary : Packet Abis offers a fully shared dynamic bandwidth with a configurable upper limit.In order to avoid the situation where PSN SLA agreements are violated (CIR, CommittedInformation Rate) for Packet Abis over Ethernet, this feature detects and reacts to congestionand also monitors bandwidth usage. Further, it also enables efficient overbooking for Packet

Abis over IP/Ethernet and TDM.

Congestion reactions:

• PS Data and AMR CODEC Adaptation

• Handover

• Puncturing (defined discard of speech samples)

• Call Admission Control

Benefits for the Operator : This feature enables overbooking, increases the optimisation gainand prevents violations of PSN SLA Agreements.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 Y 1) N N N Y 2) Y 2) 3) N 4) - - - - - 5)

1) The BSC3i 1000/2000 or Flexi BSC with supporting interface module is required.2) The FIEA; FIPA; FIFA, FIYA or FIQA Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.3) The feature is supported with the RG25 (BSS) Release.4) Supported via RG301397, Cositing with BS2xx.5) The Packet Abis Software and Licence Key are required.




5.3.9 Local Switching for Packet Abis


Summary : Local Switching for Packet Abis introduces an integrated capability to switch Intra-BTS / Inter-BTS (within a cluster) calls locally without requiring any external hardware. Thefeature is supported with both BSS21440, Packet Abis over TDM and BSS21454, Packet Abisover IP/Ethernet scenarios and is therefore transport media independent. Calls may beswitched via the integrated ESMx Module within the BTS equipment or alternatively via anexternal router solution in the Transmission Network, depending upon the topology andconfiguration of the transport network.

Benefits for the Operator : Local Switching for Packet Abis further enhances the possiblebandwidth (OPEX) Savings realised with the Nokia Siemens Networks Packet Abis solution.

This is achieved through the improved bandwidth gains from switching local voice calls locallyon top of the Abis Optimisation achieved from the Packet Abis solution itself. OPEX Savingsare achieved by reducing the bandwidth capacity requirements in combination with SatelliteLinks, Microwave Radio Links, TDM Leased Lines or within Packet Switched Networks.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



Y 1) N N N Y 2) Y 2) N 3) - - - - - LicenceKey

Control 4)

1) The BSC3i 1000/2000 or Flexi BSC with supporting interface module is required.2) The FIEA; FIPA; FIFA, FIYA or FIQA Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.3) Supported via RG301397, Cositing with BS2xx.4) Either Packet Abis over IP/Ethernet or Packet Abis over TDM Software and Licence Keys are required.




5.3.10 Packet Abis Sync. ToP IEEE1588v2


Summary : The feature Packet Abis Sync. ToP IEEE1588v2 provides a further synchronisationoption for Packet Abis over IP/Ethernet networking scenarios.

Timing over Packet (IEEE1588v2) is a transparent synchronisation solution for PacketSwitched Networks, where a standardised protocol is employed to transparently synchronisebase stations across Layer 2 or Layer 3 networks. The protocol utilised is IEEE1588v2 (whichis also known as the Precision Timing Protocol or PTP). The Timing over Packet (ToP) ServerClock is located at the BSC and provides the synchronisation information to the BTSs Sites.The integrated BTS capability (or ToP Slave Clock) recovers the clock signal from the Timingover Packet data it receives.

Benefits for the Operator : Since no external equipment (i.e. GPS receiver) or E1 is necessaryfor synchronisation at the BTS site then CAPEX savings can be derived. Further, there is alsothe possibility to employ a single Timing Server (Master) solution for both WCDMA andGSM/EDGE Networks. In addition, OPEX savings result from the improved bandwidthefficiency beyond that which is achievable with CESoPSN Adaptive Timing. Furthermore, thissolution is potentially more robust to network impairments than Adaptive Timing, thus lowerquality Packet Switched Networks could be employed for the transport backhaul solution.



BTSMetroSite

BTSTalk

Family

BTS

FlexiEDGE

BTS Flexi

Multiradio

BTS

BTSplus



Control 5)

1) The BSC3i 1000/2000 or Flexi BSC with supporting interface module is required.2) The FIYB or FIQB Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.3) The feature is supported with the RG25 (BSS) Release.4) Supported via RG301397, Cositing with BS2xx.5) The Packet Abis over IP/Ethernet Software and Licence Key are required.




5.3.11 Packet Abis Synchronous Ethernet


Summary : The feature Packet Abis Synchronous Ethernet provides a further synchronisationoption for Packet Abis over IP/Ethernet networking scenarios.

Synchronous Ethernet is an end-to-end synchronisation solution for packet based backhaulnetworks. It provides a frequency synchronisation capability, but without time / phasesynchronisation. The solution employs the received Ethernet signal edges, comparing thearrival times, and then adjusts the clock signal accordingly.

Benefits for the Operator : Synchronous Ethernet provides a stable synchronisation solutionfor Packet Switched Networks which is not dependent upon the network loading or any other

network impairments. It provides OPEX savings since the realisation is more efficient than anyother Timing over Packet (ToP) solution. It is the only possible synchronisation solution thatdoes not require an external synchronisation source for Packet Radio links.

Furthermore, SSM (Synchronisation Status Message) management is supported by thesolution, which enhances the synchronisation overview and fault management across theoverall network for the operator.

Operational Aspects : Note that in order to maximise the quality of the transmitted clocksignal all intermediate nodes (for example in a BTS chain) should support the SynchronousEthernet capability.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



Control 5)

1) The BSC3i 1000/2000 or Flexi BSC with supporting interface module is required.2) The FIYB or FIQB Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.3) The feature is supported with the RG25 (BSS) Release.4) Supported via RG301397, Cositing with BS2xx.5) The Packet Abis over IP/Ethernet Software and Licence Key are required.




5.3.12 Packet Abis Delay Measurement


Summary : Packet delay measurement for packet transport networks employing thePacket Abis over TDM or Packet Abis over IP/Ethernet features, utilising integratedequipment solutions.

Benefits for the Operator : Moving to packet based transport networks, it is increasinglyimportant for operators to be able to monitor the realised SLA levels of the transportbackhaul as this impacts the EDGE throughput, call success rate and other important KPIvalues. Even for E1 leased line cases, today there is a reduction in transparency of thesupporting technology, since it may be satellite Abis, CESoPSN etc… which introducedelay.

Functional Description : Through looping back special UDP measurement packets in theBSC, the bi-directional round-trip-time delay is measured in the BTS. In a Quality ofService (QoS) aware Packet Switched Network, the highest applicable QoS class will bemeasured. The network delay is the delay between the network interfaces of the NE'sinvolved:

Figure: Delay components of the packet delay measurement.

The end-to-end delay is the measured delay from measurement entity to measuremententity. This delay includes the network delay and the delay through entities inside theNE's (e.g. network interfaces). The feature minimises the impact of internal delays in thefinal result.






BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S151)

Y 2) N N N Y 3) Y 3) 4) N 5) - - - - - LicenceKey

Control

1) Either BSS21454, Packet Abis over IP/Ethernet or BSS21440, Packet Abis over TDM is required.2) The BSC3i 1000/2000 or Flexi BSC is required.3) The FIEA; FIPA; FIFA, FIYA or FIQA Module is required for the Flexi EDGE (or Flexi Multiradio) BTS.4) The feature is supported with the RG25 (BSS) Release.5) Supported via RG301397, Cositing with BS2xx.

5.3.13 FlexiPacket Radio Connectivity


Summary : FlexiPacket Radio support with the Flexi EDGE (or Flexi Multiradio) BTSfurther extends the scope of the Nokia Siemens Networks unique “Zero Footprint” solutionrealised with the Flexi BTS Platform. The FlexiPacket Radio solution providestransmission support for chain and spur networking applications, enabling a directinterfacing between FlexiPacket Radio and the Flexi EDGE (or Flexi Multiradio) BTS.

Benefits for the Operator : The key and indeed unique benefit for the Operator is theextension of the “Zero Footprint” capability realised by the Flexi EDGE (and FlexiMultiradio) BTSs. This fully outdoor compatible solution provides an optimised integratedSite Solution, reducing the number of modules and interfaces; minimising cabling;enhancing MTBFs and providing an integrated worry free solution, where the Operatoreffectively hands over their interoperability concerns and issues to Nokia SiemensNetworks.

CAPEX investments are reduced through reducing the necessary hardware.

OPEX costs are reduced through the extension of the “Zero Footprint” capability to alsoinclude the transmission solution. Furthermore, the efficient and faster installation andcommissioning procedures enable an improved time to service and thus revenue flow.Moving on to the operational mode, the maintenance procedures and operations aresimplified, which reduces on-going OPEX costs for the Operator. In addition, thisintegrated solution also minimises power consumption, yet further pushing down OPEXcosts.

Furthermore, and also from the operational perspective, management of the remotemicrowave station is realised via the local Flexi EDGE (or Flexi Multiradio) BTSmanagement port, simplifying both the operation and management procedures for thelink.




Figure: Management of the remote microwave station via LMT.

Functional Description : The evolving capacity and networking needs of Operators areefficiently supported by the Nokia Siemens Networks FlexiPacket Radio microwavetransmission solution. It meets the backhaul challenges of today and also provides forthose that Operators will be facing in future, including the evolution towards IP andEthernet solutions.

Figure: Direct interfacing of FlexiPacket Radio to the Flexi EDGE (Flexi Multiradio) BTS.

Customers are now accustomed to the advantages provided by the Nokia SiemensNetworks Flexi BTS Platform, including the unique “Zero Footprint” capability. Naturallythey seek to extend this position and the FlexiPacket Radio solution efficiently enablesthis.

This complete solution is fully outdoor compatible and thus provides for the widestpossible range of applications, consequently offering an ideal and optimised integratedSite Solution. Support for direct interfacing between the Flexi EDGE (or Flexi Multiradio)BTS and FlexiPacket Radio reduces complexity and the number of modules andinterfaces. This enables a minimised cabling and also the MTBF for the complete solutionis enhanced.

ESMx




As well as supporting efficient installation and commissioning procedures, the operationalmode is also eased through simpler maintenance processes and operations.

From the networking perspective, both chain and spur type applications are supported bythe FlexiPacket Radio solution.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - N N N Y Y 1) N - - - - - SupplementaryLicence

Management


5.3.14 Packet Abis IP/TDM Aggregation


Summary : Packet Abis IP/TDM Aggregation realises a statistical multiplexing function forchained Flexi EDGE BTSs employed within a Packet Abis over TDM configurationscenario. A pooling of all transmission resources is thus realised, providing a capability

beyond that possible with simple grooming.

A multi-stage aggregation function is realised (at every node of the chain), whichmaximises the efficiency of the solution.

Figure: Multi-stage Aggregation maximises the Efficiency and thus Saving.

Flexi BSC

SDH

FIU19E +SDH node

FlexiEDG

FlexiEDGE

FlexiEDGE

FIU19E

FlexiEDGE




Benefits for the Operator : Packet Abis IP/TDM Aggregation provides a statisticalmultiplexing gain and is thus able to realise resource savings beyond that possible withPacket Abis alone, as illustrated in the figure below:

Figure: Transmission Saving through Packet Abis IP/TDM Aggregation.

The anticipated gain is of the order of 20% to 40% (depending upon the particular configurationand traffic profile). Even greater gains can be anticipated for unbalanced load distributionsbetween Cells / across Sites.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



1)

Y 2) N N N Y N N - - - - - LicenceKey

Control

1) BSS21440, Packet Abis over TDM is required.2) The BSC3i 1000/2000 or Flexi BSC with supporting interface module is required.

FixedTDM

PA o TDM(per BTS)

PA IP/TDMAggregation

Transmission resourcesOccupied




5.4 Operability

Optimise

5.4.1 PCU Restart Handling


Summary : This feature introduces support for a single PCU restart in the BSC.

Benefits for the Operator : The feature improves both normal and fault recovery scenariooperations. For normal operational actions requiring a restart of the PCU (such asmodifications to Dynamic Abis Pools), the single PCU restart is now possible, instead ofrestarting the complete BCSU, resulting in a reduced impact for active traffic carried bythe BSC. This advantage is also applicable for recovery actions following a PCU modulefailure.

Functional Description : This feature enables the restart of one of the logical PCUsinstead of the complete BCSU unit. For the existing implementation, the whole BCSU unitmust be restarted in some cases or if a fault is raised in one of the PCUs.

This new feature is particularly applicable for the BSC3i 1000/2000, where there could beas many as ten logical PCUs (five PCU2 plug-in modules) in one BCSU unit. For normaloperational actions requiring a restart of the PCU (such as modifications to Dynamic AbisPools), the single PCU restart is now possible, instead of restarting the complete BCSU,resulting in a reduced impact for active traffic carried by the BSC. Additionally, when aPCU fault is detected, first the faulty PCU will be restarted and if that does not solve theproblem then a restart or switchover of whole BCSU unit is then initiated. Support isavailable for both the PCU1 and the PCU2.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - (Y) (Y) (N) (Y) (Y) 1) (Y) - - - - - -


5.4.2 Automatic EDAP Reallocation in PCU


Summary : The Automatic EDAP Reallocation in PCU feature removes the need formanual (MML) actions related to EDAP modifications. It enables an automaticreallocation of only those timeslot allocations of the logical PCM (within the PCU) which

are impacted by EDAP changes. Further, it optimises the usage of the RG20 (BSS) PCURestart Handling feature capability.




Through this new feature, the BSC automatically minimises the number and duration ofPS Data service outages resulting from EDAP changes.

Benefits for the Operator : The automatic nature of the feature enables OPEX savingsfor the operator and the service outage reduction enhances revenues. The AutomaticEDAP Reallocation in PCU feature provides the following advantages for the operator:

• Network planning optimisation of the logical PCM (within the PCU) capacity

• Simplified EDAP handling procedures, saving time as well as OPEX

• Elimination of CS Call service outages resulting from EDAP changes

• Reduced PS Data service outages due to EDAP changes

Functional Description : The Automatic EDAP Reallocation in PCU feature maintainscontiguous timeslot allocations for the logical PCM (within the PCU). The feature employsthe same internal mechanism for timeslot reallocations as is utilised by the RG20 (BSS)PCU Restart Handling capability.

Figure: Introducing an automatic re-allocation capability.

Operational Aspects : The feature is automatically enabled with the RG20 (BSS)

Release software and is supported by both the PCU1 and PCU2 units. EDAP changescan now be performed without requiring manual BCSU switchovers / PCU restarts in theBSC.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S151)

- (Y) (Y) (N) (Y) (Y) 2) (Y) - - - - -

1) The RG20 (BSS) feature BSS20045, PCU Restart Handling is required.2) The feature is supported with the RG25 (BSS) Release.

32x64kbit/s

EDAP #1

Free

BSC

PCU

PCU

PCUEDAP #2

EDAP #3

Logical PCM(within the PCU)




5.4.3 Energy saving mode for BCCH TRX


Summary: With the RG20 (BSS) Release, support for this existing RG10 (BSS) feature isnow also extended to the BTSplus BTS type. The feature introduces a new configurablepower saving mode for the BCCH TRXs of the BTSplus Base Station.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - Y N N Y Y Y - - - - - LicenceKey

Control




Configuration Management

5.4.4 Fast BSS Restart


Summary : This feature increases the network availability for service through reducing thedowntime required for a controlled BSC restart.

Benefits for the Operator: Increased revenue and network availability through thereduced cell downtime now required for BSC software installations and maintenancerestarts.

With this feature the radio network cell downtime resulting from BSC software installations

may be reduced by between 33 to 80%, depending upon the BSC and BTS configuration(for the case that the system restart is triggered without a radio network restart and that allBTSs support the feature). The particular saving is of course dependent upon the numberof BTS supporting this capability that are connected to the BSC. Indeed, savings can berealised even with a single BTS, with the advantage increasing linearly, with the numberof supporting BTSs.

Functional Description : This functionality is realised through the following restartimplementation:

•

System restart without a Radio Network restart, triggerered through theappropriate MML command(s).

• The BSC informs the BTSs supporting this capability that it will initiate asystem restart. The BTSs are also informed of the system restartcompletion, and following this the BTS continue operation in anormal working state.

• Once the BSC is in the normal working state, it brings the TRXsof supporting BTSs back into their normal working state without a restart.

• Once these BTSs have achieved the normal working state, the BSC then

initiates a restart for the other remaining BTSs.

In practice, the BSC system restart handling is changed to include a new parameter todefine the new reset type (system restart without Radio Network reset).




The anticipated improvements are indicated via the examples included in the table below:

RNW Objects in BSC Reduced Cell DowntimeBCFs: 165

BTSs: 330

TRXs: 660 35 – 72 %

BCFs: 250

BTSs: 500

TRXs: 1000

33 – 75 %

BCFs: 500

BTSs: 1000

TRXs: 2000

35 – 80 %

BCFs: 750

BTSs: 1500

TRXs: 3000

35 – 80 %

Table 8: Anticipated Improvement with the Fast BSS Restart Procedure.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - Y N N Y Y 1) Y - - - - - -





5.4.5 Flexi BTS Autoconnection


Summary : This feature enables a faster, automated integration of new Flexi EDGEBTSs into the BSS network, generally eliminating the requirement to use the standarddownload device. For cases where there are Radio transmission hops or the PCM line isshared between BTSs, the standard download device must be utilised, however, theintegration is nevertheless faster and less prone to error.

Benefits for the Operator : The feature enables a simpler installation and reduction of therollout time for new Flexi EDGE BTSs, improving the efficiency of installation teams.Consequently, the time to service / revenue is improved for the operator.

Further, during the maintenance phase (after the network rollout has beencompleted), the feature continues to support the speeding up of change processes,reducing errors and consequently OPEX costs for the operator.

Functional Description : The Flexi BTS Autoconnection feature both simplifies andspeeds up the BTS commissioning process, enabling an automatic connectionbetween the BSC and BTS via the OMUSIG link.

The supporting transmission connectivity must be in place in order to allow the possibilityfor this automated BTS integration capability. Finally, an integrated Radio Networkplanning process enables further automation improvements.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - N N N Y Y 1) N - - - - - LicenceKey

Control





5.5 Multiradio Interworking

5.5.1 LTE System Information


Summary : GSM/EDGE - LTE Interworking consists of several possible mobilityprocedures:

Figure: Possible GSM/EDGE - LTE Interworking Mobility Procedures.

The RG20 (BSS) Release supports LTE Interworking through the LTE System Informationfeature, which enables the operator to introduce neighbouring LTE cell and parameterinformation into the BSS. Once configured, Handsets will then be able to execute anautonomous Cell Reselection from a GSM cell to an LTE cell (when the Handset is ineither the idle state or packet idle state).

Benefits for the Operator : This feature provides the basic interworking capability withLTE, enabling coverage continuity and thus an improved end user experience in multi-RAT networks.

Functional Description : The RG20 (BSS) Release supports LTE Interworking throughthe LTE System Information feature, which enables the operator to introduceneighbouring LTE cell and the relevant parameter information into the BSC.

Up to eight adjacent LTE cells may be configured per GSM cell. The LTE neighbour cellparameters of the cell are defined in 3GPP Rel.8 standards and when the Handset is inidle mode they are indicated to the Handset via their inclusion in system information type2q messages on the BCCH Channel.

A number of new parameters are defined for the handling of the LTE Cells, includingthose for the following:

• MCC; MNC

• Carrier Frequency

• Handling of Barring of LTE Cells

• Prioritisation




• Levels for Reselection

• Etc…

Once the relevant cells and parameters have been configured then Handsets would beable to execute an autonomous Cell Reselection from a GSM cell to an LTE cell (whenthe Handset is in either the idle state or packet idle state).

Two potential solutions are being considered in order to provide Voice Call Continuityfrom LTE to GSM/EDGE:

• CS Fallback - where Voice Services / Emergency Calls are directed fromLTE towards GSM/EDGE through an Inter System NACC capability (please

refer to BSS21355 for more details)• Single Radio Voice Call Continuity (SRVCC) - where the Core Network

translates the VoIP Call across as an incoming CS voice Handover forGSM/EDGE

SRVCC has no impact on the BSS, however, the feature BSS21355, Inter System NACCfor LTE may be used ( where RIM is supported ) as an extension for the CS Fallbacksolution.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 - (Y) (Y) (N) (Y) (Y) 1) (Y) - - - Y 2) Y3)

LicenceKey

Control

1) The feature is supported with the RG25 (BSS) Release.2) LTE System Release RL10 is required.3) A 3GPP Rel.8 capable Handset is required.




5.5.2 RF Sharing GSM - LTE


Summary : The GSM-LTE Concurrent Mode operation is supported through this feature.Common Multi-carrier Power Amplifiers (MCPAs) are employed to simultaneouslytransmit both the GSM and LTE signals via a common RF Module.

Figure: GSM-LTE Concurrent Mode operation with the Flexi Multiradio BTS.

Benefits for the Operator : Significant CAPEX (through hardware sharing) and OPEX(through increased modularity, reducing the number of items and thus spare part) costsavings can be achieved with this solution. Furthermore, a faster upgrade process to LTE

is achieved, resulting in a quicker access to LTE revenues. It enables a differentiatedapproach across the network for re-farming scenarios, allowing solutions depending uponthe particular Site requirements. Finally, the increased sharing results in a lower totalpower consumption, further driving down OPEX costs.

Also, for the single MCPA employed to transmit both GSM / LTE signals, the RF outputpower can be flexibly shared between them.

In addition, since no external combining mechanism (introducing losses) is necessary, thecomplexity of the antenna system is reduced, leading to a simpler installation. Only onefeeder and antenna system is required for both GSM and LTE.

The realised capability thus simplifies the GSM to LTE frequency re-farming process forthe Operator.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



- N N N N Y 1) N - - - - - LicenceKey

Control

1) Supported for the 900MHz and 1800MHz frequency Bands.

For example, 3 GSM TRX and1 LTE Carrier per shared MCPA

f210 MHzf1 f3

MultimodeSystem Module

LTE SW

GSM/LTE RFModule

Flexi Multiradio BTS

GSM/EDGESystem Module




5.5.3 IMSI-based Handover


Summary: With the RG25 (BSS) Release, support for this existing feature is now alsoextended to the BTSplus BTS type. IMSI-based Handover enables handover controlbetween networks of different operators according to the identity (IMSI) of a Subscriber. Ifa Subscriber belongs to a Subscriber Group (SG) and the IMSI can be recognised, it ispossible to perform Handovers within GSM Networks or to WCDMA Networks.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



- Y Y Y Y Y Y - - - - - LicenceKey

Control

5.5.4 GSM - WCDMA Interworking


Summary: With the RG25 (BSS) Release, support for this existing feature is now alsoextended to the BTSplus BTS type. This feature introduces a load-based Handovercapability for the BTSplus Base Station.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus



- Y Y Y Y Y Y - - - - - LicenceKey

Control




5.6 Site Solutions

5.6.1 Cositing with BS2xx

Feature ID : RG301397

Summary : Support for the BTSplus Base Station via the Flexi BSC was implemented inthe RG10 (BSS) Release.

With RG20 (BSS), a Cositing solution for BTSplus with either the Flexi EDGE or FlexiMultiradio BTS now supports a further extension of existing BTSplus site deployments.

The solution employs the Multi-BCF (Base Station Control Function) capability, facilitatingthat TRXs from both the BTSplus and the Flexi EDGE (or Flexi Multiradio) BTSs may beemployed within a single cell and that a common BCCH TRX (from either the BTSplus or

Flexi EDGE / Flexi Multiradio BTS) is utilised.

Figure: Cositing example, with BTSplus and the Flexi EDGE BTS in RG20 (BSS).

The Cositing solution is applicable for both indoor and outdoor Site applications.

Flexi BSC

Single AbisTransport

Sync. & E1

Flexi EDGE BTS BTSplus

Segment 1 BTS1 BTS4

Segment 2 BTS2 BTS5

Segment 3 BTS3 BTS6

BTS1BTS4

BTS2BTS5

BTS3

BTS6

air inlet

CF

CU CU CU CU

CU CUCU CU

ACOM

ACOM

ACOM

ACOM

DI A

MC

DI A

MC

Cor

Cor

Cor

Cor

BS-240

O N ON O O N O O O N ON O N ONONO

air inlet

air inlet air inlet

air inlet air inlet




Benefits for the Operator : With RG20 (BSS), the Cositing solution enhances the supportfor existing BTSplus deployments through enabling the possibility to provide features thatare not inherently supported by the BTSplus at the existing BTSplus sites.

Furthermore, the support for existing deployments is now further enhanced, wherecapacity extensions can now also be provided through either the Flexi EDGE or FlexiMultiradio BTSs.

Functional Description : The Cositing capability provided with the RG20 (BSS) Releaserealises a number of key functions:

• Cositing possibility with the Flexi EDGE BTS (via the Multi-BCF capability)

• Cositing possibility with the Flexi Multiradio BTS (via the Multi-BCFcapability)

• BTSplus Transport Sharing solution with the Flexi EDGE / Flexi MultiradioBTS

• BTSplus RF Equipment Sharing with the Flexi EDGE / Flexi Multiradio BTS

• Mechanical Integration of the Flexi Multiradio BTS into the Outdoor BS-241BTS Service Shelter

For Cositing configurations, the Flexi EDGE (or Flexi Multiradio) BTS acts as theSynchronisation Master, providing the necessary synchronisation signal to the BTSplus:

Figure: Cositing Synchronisation Solution.

Further, a single Abis interface to the Flexi BSC is provided via the Flexi EDGE (or FlexiMultiradio) BTS.

Flexi BSC Abis

Sync.

Flexi EDGE BTSBTSplus

air

CBF

C C C C

C CC C

ACOM

ACOM

ACOM

ACOM

DI A

MC

DI A

MC

Cor

Cor

Cor

Cor

BS-

O O O O O O O O O OO O

air

air air

air air

E1

Master Slave




The site solution may employ an RF Equipment Sharing scenario and in this case, Antennas, TMA/MHA (tower amplifier) modules and RF cabling may be shared by theBTSplus and Flexi EDGE / Multiradio BTSs for Receiver Diversity cases; whilst thetransmit path employs dedicated antennas.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 1) N N N Y Y 2) Y - - - - - -

1) The PCU2 is required.2) The feature is supported with the RG25 (BSS) Release.

5.6.2 Integrated IP card for BSC and TCSM


Summary : With the RG20 (BSS) Release, support for this existing RG10 (BSS) feature isnow extended to the BTSplus Base Station.

An ETIP1 plug-in module, based on Circuit Emulation Service over Packet-SwitchedNetworks (CESoPSN) technology, is equipped in the BSC3i / Flexi BSC instead of theusual E1/T1 or STM-1/OC-3 unit in order to provide a direct termination of IP Connectivity.The corresponding CESoPSN interfacing capability is enabled in the BTSplus via theintegrated CES-COBA + ETHCON Modules.



BTSMetroSite

BTSTalk

Family

BTSFlexi

EDGE

BTS FlexiMultiradio

BTSBTSplus


Release RG20 S15 1) (N) (N) (N) (Y) (Y) (Y) 2) - - - - - -

1) The BSC3i 1000/2000 or Flexi BSC is required.2) The CES-COBA and ETHCON Modules are required at the BTSplus.




5.6.3 BS2xx Loop Protection with Flexi BSC

Feature ID : RG601668

Summary : BS2xx Loop Protection increases transmission redundancy within a sub-network. The traffic is sent across both paths of the loop and thus for the case of a trafficinterruption there is a seamless switchover in the Loop Master (located next to the FlexiBSC) to the alternative path:

Figure: Increased Redundancy via Loop Protection.

Benefits for the Operator : The increased redundancy reduces OPEX costs through adirect reduction in Site visits. The increased network availability assures the revenueflow, reducing Dropped Calls and enhancing the network KPIs.

Furthermore, the increased redundancy assists the Operator maintain the microwavenetwork integrity during periods of extreme weather.

Dependency Table :

BSS BSC DX200Platform BTSUltraSite

BTSMetroSite

BTSTalkFamily

BTSFlexiEDGE

BTS FlexiMultiradio BTSBTSplus NetAct SGSN MSC RAN MS Licensing


- N N N N N Y - - - - -

SDHPDH

MetroHubLoop Master Flexi BSC

Protecteddomain

BTS2xx BTS2xx

BTS2xx

BTS2xx




5.7 Location Services

5.7.1 Geo-Redundant SMLC over Multi-Homed Lb Interface


Summary : The Lb Interface was introduced to the BSC in order to extend the LocationServices (LCS) capability. It was designed and implemented to support a single SMLC(Serving Mobile Location Center) with one M3UA point code and two multi-homedassociations that can be provisioned for LCS. This feature extends the existing capability,to enable support for two geo-redundant SMLCs over multi-homed Lb interface, withpriority association.

Benefits for the Operator : The feature increases the level of redundancy for the M3UA

and SCCP on the Lb Interface, by enabling the possibility to prioritise one M3UA/SCCPassociation over another redundant association. In addition, the deployed SMLC Serverscan be deployed in separate geographic locations (now two SMLC Servers), if theOperator elects to support this architecture.

Functional Description : With the RG20 (BSS) Release, the Lb Interface is enhanced tosupport a higher reliability, through being connected to two SMLC Servers belonging tothe same logical and geo-redundant SMLC Cluster. It allows a multi-association on theLb Interface between the BSC and the two geo-redundant SMLC Servers with priority, sothat the association with the higher precedence will always be the preferred connection

used by the BSC and SMLC for communication.The BSC supports priority SCCP association to better balance the traffic between the twogeo-redundant SMLC Servers. Each SMLC will have two unique IP Addresses and sharethe same M3UA point code between the two SMLC Platforms.

Two SMLC Servers can now be geographically separate from one another, providingadditional redundancy. The BSC supports the SMLC Servers, where each SMLC has twounique IP Addresses and only one M3UA point code that is shared between the two Sites.The BSC will be provisioned with two sets of IP Addresses (thus a total of four IP

Addresses) for the SMLC with shared point code. At any particular time, the M3UArouting key is unique with one specific set of IP Addresses, so that only one SMLC at a

time is communicating with the BSC.



SMLC - A

Geo-redundant pairMCUA Point Code

1-1-10

MTP Point Code

1-1-11

SMLC - BGeo-redundant pair

MCUA Point Code

1-1-10

NSN BSC

Association 1

SMLC - A

Association 2

SMLC - B

2G RG10 and RG20 features.pdf

Documents

Transcript of 2G RG10 and RG20 features.pdf