TS-3GBTS-SW-0148-I16 - WN7

Nokia Siemens Networks Company Confidential

1 (53)

Technical Support Note TS-3GBTS-SW-0148-I16

Mandatory BB conversion before WN7.0 upgrade by using RU30 Conv-tool WCDMA Base Stations

Flexi BTS Rel2

WN7.0

This document contains following type of information

Informative X Preventive Corrective

Additional categorization Urgent X Security Release Upgrade X SW Update X

Information is classified as Internal Public X Customer Specific


2 (53)

Table of Contents 1. Validity......................................................................................................................................... 5 2. Compatibility / Dependencies to other products ........................................................................... 5 3. Keywords .................................................................................................................................... 5 4. Summary ..................................................................................................................................... 5 5. HW / SW requirements ................................................................................................................ 6 6. Detailed description ..................................................................................................................... 7

6.1 Overview of the RU30 Conv-tool ..................................................... 7 6.2 Description of conversion procedure ............................................... 8 6.3 Parameters of the RU30 Conv-tool ................................................ 10 6.4 Usage of flexible configuration files ............................................... 19 6.5 Usage of input .txt for selected IDs to be converted....................... 21 6.6 BTS specific settings on processing sets and Rel.99 CE consumptions 21 6.7 Rel.99 CE license consumption calculated by the tool ................... 22 6.8 Throughput calculation by the tool ................................................. 23 6.9 Information about conversion rules ................................................ 28 6.10 Behaviour in case of Flexi System Module Rel.1 ........................... 28 6.11 NetAct cleanup script .................................................................... 29

6.11.1 Steps of the cleanup procedure ..................................................... 30 7. Note .......................................................................................................................................... 30

7.1 Questions & Answers .................................................................... 30 7.2 Estimated time running the conversion .......................................... 34

8. References ................................................................................................................................ 34 9. Appendix ................................................................................................................................... 34

9.1 Description of detailed upgrade steps ........................................... 34 9.2 Trouble Shooting ........................................................................... 47

9.2.1 Case 1 - Use internal value ........................................................... 47 9.2.2 Case 2 - plan provision validate failure .......................................... 48 9.2.3 Case 3 - No raml20.dtd file ............................................................ 49 9.2.4 Case 4 - RNW parameters are not in export file ............................ 49 9.2.5 Case 5 - R99 CE set to zero after upgrade to WIN7.0 ................. 49 9.2.6 Case 6 Conversion tool does not generate any processing sets 50

9.3 Standard rules for converting HSDPA ........................................... 50 9.3.1 Minimum BB and 16 Users per cell Schedulers ........................ 50 9.3.2 Shared Scheduler and Full Baseband Scheduler (16QAM) 51 9.3.3 Shared Scheduler and Full Baseband Scheduler (64QAM) 51 9.3.4 Shared Scheduler and Full Baseband Scheduler (MIMO) ......... 52 9.3.5 Shared Scheduler and Full Baseband Scheduler (DC-HSDPA) 52

Contact:

Contact your local Nokia Siemens Networks support

Summary of changes:


3 (53)

12-May-2011 0.1 First draft 22-July 2011 0.2 Updates & parameter 64QAM-set3_thrp added 28-July-2011 0.3 Cleanup description upadated 03-Aug-2011 0.4 Explanation about throughput steps added 12-Aug-2011 0.5 Explanation about throughput steps extended 15-Aug-2011 0.6 Example for throughput calculation extended 17-Aug-2011 1.0 First approved version 23-Sep-2011 1.1 Description extended: Rel.99 CE consumption;

duration time; minor corrections 26-Sep-2011 1.2 Some more detailed descriptions on step 5 & 6 of

conversion procedure 27-Sep-2011 1.3 Minor improvements related to export and

calculation of CE consumption. 27-Sept-2011 2.0 Second approved version 10-Oct-2011 2.1 Bullet in step 5 of conversion procedure removed.

Descriptions of parameters in section 6.3. improved.

13-Oct-2011 2.2 Some minor improvements 17-Oct-2011 2.3 Changes in Throughput calculation 19-Oct-2011 2.4 New parameters added. 24-Oct-2011 3.0 Third approved version 04-Nov-2011 3.1 Additional explanation for throughput distribution 11-Nov-2011 3.2 Chapter Import of XML to NetAct has been

introduced 17-Nov-2011 4.0 Fourth Approved version reference corrected 23-Nov-2011 4.1 Flexible configuration files added 02-Dec-2011 4.2 Missing reference corrected 07-Dec-2011 4.3 Note added: Freeze BB configuration before

upgarde 12-Dec-2011 5.0 Fifths Approved version 27-Dec-2011 5.1 Processing sets for Flexi Rel.1 09-Jan-2012 6.0 Sixth approved version 12-Jan-2012 6.1 New parameter PS_Rel_1; parameter

HSUPA_CE_Consumption_MULTIPLICATOR declared as mandatory.

13-Jan-2012 7.0 Sevenths approved version 25-Jan-2012 7.1 New parameters: max_sched_thrp,

add_throughput_SMx, user_split_according_to_sched; new .txt file for listing BTS IDs to be converted

25-Jan-2012 8.0 Eights approved version 31-Jan-2012 8.1 Detailed upgrade steps have been included into

appendix 9. 14-Feb-2012 8.2 New parameters for conversion tool version 4.0 15-Feb-2012 9.0 Ninth approved version 01-Mar-2012 9.1 Parameter user_split_according_to_sched added 02-Mar-2012 10.0 Tenth approved version 13-March-2012 10.1 Some minor updates CELG-> LCELG for objects

to be exported; new parameter: PS_according_to_minimum_rule; Chapter for trouble shooting added.

20-March-2012 11.0 Eleventh approved version 21-April-2012 11.1 Added: Case 6 for trouble shooting 03-May-2012 11.2 Chapter 9.2 removed as pre-evalation during


4 (53)

import has to be skipped; Q&A section extended by FSM replacement

05th May 2012 12.0 Twelfth approved version 11th May 2012 12.1 Q&As extended:Q5 check # Rel.99 CEs to be

ordered; Q6: Naming convention for SCFs 24th May 2012 13.0 Thirteenth approved version

Description for addl Rel.99 CEs for CCCH subunits; addl bullet to describe behavior of hot insert for Flexi Rel.2 into WN6.0; removal of the parameters: user_split_according_to_sched, share_of_HSUPA_PS; change of behavior for the parameter: PS_according_to_minimum_rule

02nd July 13.1 Introduction of new parameters: additionalR99CEs_per_SM_x, Rel.99Ceconsumpt_CCC; Extended description for Flexi Rel.1 Editorial improvements

03rd July 14.0 Fourteenth approved version 06th July 14.1 Q&A added 09th July 14.2 Parameters added and input XML for BTS specific

settings 23rd July 15.0 Fifteenth approved version 13th August 15.1 Summary part extended to explain additional

background about tools usage. Chapter 9 / sub-chapter new plan provisioning; extended Explanation what happens in case of conversion has not been applied.

23st August 16.0 16th approved version


5 (53)

Purpose This document contains generic information about products. These can be instructions that explain problem situations in the field, instructions on how to prevent or how to recover from problem situations, announcements about changes or preliminary information as requirements for new features or releases.

1. VALIDITY

Product Category 1 Category 2 WCDMA Flexi BTS

2. COMPATIBILITY / DEPENDENCIES TO OTHER PRODUCTS

NA

3. KEYWORDS

WN7.0 upgrade, RU30 Conv-tool, BB commissioning, Flexi Rel 2.

4. SUMMARY

Within RU30/I-HSPA Rel.4 a new baseband concept is introduced for Flexi Rel. 2 BTSs: RAN 2123 Flexi BTS Gigabit Baseband. The new concept required a conversion from RU20s/I-HSPA Rel.3 baseband to RU30s/ I-HSPA Rel.4 baseband. The conversion is supported by the tool RU30BBconv tool which is part of WBTS 7.0 SW delivery. The conversion using the tool has to be executed before upgrading the BTS to WBTS 7.0.

Running the conversion can be seen as part of BTSs upgrade.

BB conversion is mandatory to perform for all sites before WN7.0 SW upgrade.

In case the conversion has not been applied, the upgraded BTS would not be enabled for HSxPA. Based on the RU20s configuration, conversion rules define how many baseband resources the customer will get. This has commercial impact. Before running the conversion, these rules have to be agreed between the customer and NSN. According to these commercial agreements, the conversion tools parameters as described in that document have to be set accordingly. In general the conversion is executed by NSN. If the conversion is intended to be executed by the customer, NSNs customer team has to accept that. This document describes how to make the BB conversion by using RU30 Conv-tool before upgrading BTS to WN7.0 (RU30) level.


6 (53)

Based on WBTSs baseband configuration on WN6.0 SW level the BTSs baseband configuration on WN7.0 level is calculated. Information about different processing sets For converting RU20s BB configuration into RU30s BB configuration NSNs conversion tool RU30Conv Tool has to be used. This conversion is part of the BTSs upgrade from RU20 to RU30 (WN 6.0 -> WN7.0) and results into a dedicated number of HSDPA BTS Processing Set 1, HSDPA BTS Processing Set 2, HSDPA BTS Processing Set 3, HSUPA BTS Processing Set, Rel. 99 CEs and configured HSDPA throughput. For HSDPA: HSDPA BTS Processing Set 1: 32Users/7.2Mbps HSDPA BTS Processing Set 2: 72Users/21Mbps HSDPA BTS Processing Set 3: 72Users/84Mbps For HSUPA: HSUPA BTS Processing Set: 24Users/5.8Mbps For Rel. 99 traffic Rel.99 CEs are introduced. As the RU30s baseband concept has been introduced for Flexi Rel.2 only, the conversion becomes effective for Flexi Rel. 2 only. As within WN6.0 an extension module can be added without re-commissioning, in those cases the BTS SCF will not contain Rel.2 System Module information. Consequently the conversion will make some assumptions, which allows to generate processing sets for these mixed configurations (SM1 & SM2), which have been extended in WN6.0 without re-commissioning. Details have been described in chapter 6.9.

5. HW / SW REQUIREMENTS

SW REQUIREMENTS:

Conversion tool: .NET 3.5 Microsoft environment OSS5.4 CD1 (RAN2131: Automatic License Distribution- feature

activated for handling the complete conversion procedure) Remark: If the parameters user_split_according_to_sched and

share_of_HSUPA_PS are set to off (cia cml), then OSS 5.3 CD1 can be used

HW REQUIREMENTS:


7 (53)

WCDMA Flexi BTS (tool is applied for Flexi BTS)

6. DETAILED DESCRIPTION

6.1 Overview of the RU30 Conv-tool

The tool is Windows based and needs .NET 3.5 Microsoft environment.

Input of the tool is a XML file (RAML 2.0) containing configuration data from the BTS SCF (Site Commissioning File) and RNC RNW (Radio Network).

In the same directory a file called raml20.dtd must be available.

The key data used for the conversion are:

From BTS:

Type of scheduler used in BTS

Kind of HW used (Rel.1 and / or Rel.2)

Number of schedulers

MIMO enabled / disabled

From RNC

HSDPA enabled / disabled

HSUPA enabled / disabled

HSPA72UsersEnabled

HSUPAXUsersEnabled

DC-HSDPA enabled/disabled

64 QAM enabled/disabled

Based on conversion rules implemented in the tool, the tool generates as output:

XML file (RAML 2.0) containing RU30 BB configuration (dedicated number of HSDPA BTS Processing Set 1, HSDPA BTS Processing Set 2, HSDPA BTS Processing Set 3, HSUPA BTS Processing Set, Rel. 99 CE consumption and Throughput via the parameter hsdpaSchedList) and

Text file containing # HSDPA BTS Processing Set 1, # HSDPA BTS Processing Set 2, # HSDPA BTS Processing Set 3, # HSUPA BTS Processing Set and Rel. 99 CE consumption, which allows the operator to see how many licenses need to be loaded to the NetAct pools before upgrading the BTSs to RU30.


8 (53)

XML file, which contains a list of BTSs, which have been converted to be used for the cleanup script

Remarks:

1) The tool generates Rel. 99 CE license consumption. After the upgrade to RU30 the BTS calculates the real number of Rel. 99 CEs via installed CE licences Rel.99 CE license consumption.

2) The tool has input parameters, which allow flexible handling of conversion rules agreed between customers and customer teams. Consequently additional Rel.99 CEs can be assigned and HSxPA processing set configuration can be extended or reduced. Via those parameter settings it can be selected, if commissioned throughput should be affected or not affected.

Tools delivery consists on the following files:

RU30BBconv.exe (script to run the conversion)

RU30BBconv.exe.config (contains configuration parameters to be opened with a simple editor)

RU30BBconv_Custom.exe.config (used to handle different configuration parameter setting - to be opened with a simple editor)

raml20.dtd (file has to be available in the same directory as the input XML)

RU30BBconv_ReadMe.txt (Read me file)

6.2 Description of conversion procedure

Pre-condition: NetAct has to be upgraded to RU30 level (OSS 5.3 CD 3 or higher)

The steps below provide functional descriptions. Screen shots showing detailed steps have been added to Appendix 9.1.

Freeze of BTSs to be migrated. No modification on BB configuration allowed anymore.

1) For the BTSs to be converted (possible approach, e.g. all BTSs belonging to a RNC): Use the CM Operations manager in NetAct Configurator to upload BTS


9 (53)

site configuration and hosting RNCs RNW data into the NetAct Configurator Database. After that upload, all BTS Site Configuration data and RNC RNW data is available in the NetAct Database.

2) Export that RU20s configuration (RNC RNW and BTS SCF) from the NetAct DataBase into an RAML 2.0 file using internal parameter values

Objects to be exported:

. Do not use any options from Export Options window (under Options button).

RNC : WBTS, WCEL BTS : BTSSC, LCEL, LCELG, ANTL

3) Run RU30Conv Tool through exported RAML 2.0 file. According to conversion rules, an output RAML 2.0 file and a readable .txt file will be generated containing dedicated Baseband parameters (# processing sets and # Rel.99CEs consumption). This .txt file shows # licenses needed and have to be ordered and loaded to the NetAct pool.

4) Import generated output RAML 2.0 file back to the NetAct Configurator. 5) Trigger NetAct configurator to create SCF (Site Commissioning Files) and

download these SCFs to all related BTS (part of the conversion). BTSs are still on RU20. The BTSs accept these parameters, but dont use them.

6) Upgrade the related BTSs to RU30. New BB parameters will become effective. i. Feature RAN2131: Automatic Licence Distribution to Flexi BTS

automatically loads all licenses needed. ii. Use License Manager application on NetACt, and check the new

HSDPA/HSUPA and R99 CE capacity Licence are ACTIVE and the old Licence Based BTS channel capacity INACTIVE.

Remark: In case RAN2131 is disabled, licenses have to be assigned manually.

7) Optional Step: Run NetAct Cleanup script for deleting licenses no longer needed

a. Script deletes licenses from BTS and returns capacity to the NetAct pool.

b. Input for that script is XML file from the RU30ConvTool

Remark: Cleanup script is packaged on OSS53CD3_LIC_5.30.42 or later

Note 1: The script has defined input parameters (chapter 6.3), which allow to modify the standard conversion rules. In alignment between customer and customer team those parameters have to be set accordingly. In case these parameters have not been set, conversion is performed according to standard conversion rules. Note 2:


10 (53)

The script generates a readable .txt file, which shows # licenses needed. Those licenses have to be ordered and loaded to the NetAct pool, before the BTS is upgraded to RU30. Note 3: As the cleanup script removes the NWS licenses, it should be applied only when it is ensured that no rollback is needed. Otherwise a rollback would require the re- installation of licenses.

Note 4: Before starting the export of the configuration data, the baseband configuration of the BTSs to be exported has to be frozen. No re-configuration is allowed anymore.

6.3 Parameters of the RU30 Conv-tool

These parameters impact the BB configuration calculated by the tool and consequently the # of licenses requested by the BTS. Before the conversion is executed, those parameters have to be agreed between the customer and NSN.

Especially the parameter HSUPA_CE_Consumption_Multiplicator needs dedicated attention, as it significantly impacts the number of Rel.99 CEs available after the conversion. It may risk that after the conversion the BTS is running out of Rel.99 CEs.

Those parameters have to be agreed between the customer and NSN. additional_numberOfHSDPASet1: to add additional number of HSDPA

Processing Set 1 for the BTSs to be converted, in case no Like2Like conversion is required (operator gets more). This parameter does not impact the throughput calculation and not the calculated number of used CE licenses. E.g., if that parameter is set to 1, then for all BTSs in the conversion, the configuration parameter for # of processing set 1 are increased by 1, which results that the BTSs will request one additional license.

Set1_throughput: This parameter is similar to additional_numberOfHSDPASet1, but also impacts the throughput calculation. Via that parameter it is possible to add or to reduce # of HSDPA processing set 1 , which impacts both: # of configured processing set 1 (and consequently related licenses) and throughput.

additional_numberOfHSDPASet2: to add additional number of HSDPA Processing Set 2 for the BTSs to be converted, in case no Like2Like conversion is required (operator gets more). This parameter does not impact the throughput calculation and not the calculated number of used CE licenses. E.g., if that parameter is set to 1, then for all BTSs in the conversion, the configuration parameter for # of processing set 2 are


11 (53)

increased by 1, which results that the BTSs will request one additional license.

Set2_throughput: This parameter is similar to additional_numberOfHSDPASet2, but also impacts the throughput calculation. Via that parameter it is possible to add or to reduce # of HSDPA processing set 2, which impacts both: # of configured processing set 2 (and consequently related licenses) and throughput.

additional_numberOfHSDPASet3: to add additional number of HSDPA Processing Set 3 for the BTSs to be converted, in case no Like2Like conversion is required (operator gets more). This parameter does not impact the throughput calculation and not the calculated number of used CE licenses. E.g., if that parameter is set to 1, then for all BTSs in the conversion, the configuration parameter for # of processing set 3 are increased by 1, which results that the BTSs will request one additional license.

Set3_throughput: This parameter is similar to additional_numberOfHSDPASet3, but also impacts the throughput calculation. Via that parameter it is possible to add or to reduce # of HSDPA processing set 3, which impacts both: # of configured processing set 3 (and consequently related licenses) and throughput

additional_numberOfHSUPASet: to add additional number of HSUPA

Processing Set , in case no Like2Like conversion is required (operator gets more). This parameter does not impact the calculated number of used CE licenses.

additionalR99CEs: to add additional number of Rel.99 CEs, in case no Like2Like conversion is required (operator gets more). As the configuration parameter for Rel.99 CEs has been increased, the BTS will request that additional amount on Rel.99 CE licenses.

HSUPA_CE_Consumption_Multiplicator: CE consumption for HSUPA. This parameter is needed to be set explicitly and needs dedicated attention.

HSDPA_CE_Consumption_Multiplicator: The HSDPA Rel.99 CE

Consumption is calculated according to the formula below in chapter 6.6; Via that multiplicator this value can be modified.

minBB_set1_thrp: This parameters allows to add or to reduce Processing set 1 for the dedicated conversion rules related to the Minimum BB / 16 Users per cell scheduler. The throughput is impacted as well.

16QAM_set2_thrp: This parameters allows to add or to reduce Processing set 2 for the dedicated conversion rules related to the Shared Scheduler/ Full Baseband Scheduler in the 16QAM case. The throughput is impacted as well.


12 (53)

64QAM-set2_thrp: This parameters allows to add or to reduce Processing

set 2 for the dedicated conversion rules related to the Shared Scheduler/ Full Baseband Scheduler in the 64QAM. The throughput is impacted as well.

64QAM-set3_thrp: This parameters allows to add Processing set 3 for the

dedicated conversion rules related to the Shared Scheduler / Full Baseband Scheduler in the 64QAM case. The throughput is impacted as well.

MIMO_set2_thrp: This parameters allows to add or to reduce Processing set

2 for the dedicated conversion rules related to the MIMO case. The throughput is impacted as well.

MIMO_set3_thrp: This parameters allows to add or to reduce Processing set

3 for the dedicated conversion rules related to the MIMO case. The throughput is impacted as well.

DC_set2_thrp: This parameters allows to add or to reduce Processing set 2 for the dedicated conversion rules related to the Dual Cell case. The throughput is impacted as well.

DC_set3_thrp: This parameters allows to add or to reduce Processing set 3 for the dedicated conversion rules related to the Dual Cell case. The throughput is impacted as well;

predef_PS_2_ FBB_2or3_16QAM: In case of 16QAM and usage of two or

three full baseband schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well

predef_PS_2_FBB_2or3_64QAM: In case of 64QAM and usage of two or

three full baseband schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.

predef_PS_2_shared_1_16QAM: In case of 16QAM and usage of one

shared schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.

predef_PS_2_shared_1_64QAM: In case of 64QAM and usage of one

shared schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well

predef_PS_2_FBB_6_16QAM: In case of 16QAM and usage of six full

baseband schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.

predef_PS_2_FBB_6_64QAM: In case of 64QAM and usage of six full

baseband schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.


13 (53)

predef_PS_2_shared_2_16QAM: In case of 16QAM and usage of two shared schedulers, this parameters assigns a fix number for Processing Set 2. The throughput is impacted as well.

predef_PS_2_shared_2_64QAM: In case of 64QAM and usage of two

shared schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.

predef_HSU_FBB_2or3_16QAM: In case of 16QAM and usage of two or

three full baseband schedulers, this parameter assigns a fix number for HSUPA Processing Sets.

predef_HSU_FBB_2or3_64QAM: In case of 64 QAM and usage of two or

three full baseband schedulers, this parameter assigns a fix number for HSUPA Processing Sets.

predef_HSU_shared_1_16QAM: In case of 16QAM and usage of one

shared schedulers, this parameter assigns a fix number for HSUPA processing sets.

predef_HSU_shared_1_64QAM: In case of 64QAM and usage of one

shared schedulers, this parameter assigns a fix number for HSUPA processing sets

predef_HSU_ FBB_6_16QAM: In case of 16QAM and usage of six full

baseband schedulers, this parameter assigns a fix number for HSUPA Processing Sets.

predef_HSU_ FBB_6_64QAM: In case of 64 QAM and usage of six full

baseband schedulers, this parameter assigns a fix number for HSUPA Processing Sets.

predef_HSU_shared_2_16QAM: In case of 16QAM and usage of two

shared scheduler, this parameters assigns a fix number for HSUPA Processing Sets.

predef_HSU_shared_2_64QAM: In case of 64QAM and usage of two

shared scheduler, this parameters assigns a fix number for HSUPA Processing Sets.

predef_CE_consumption: This parameter assigns a fix value for CE

consumption, without considering any schedulers or HSUPA processing sets.

PS_Rel_1: This parameter can be on/off. Default is on. As described in

chapter 6.10, processing sets may be generated for Flexi Rel.1. By setting that parameter to off, no processing sets will be generated for FSM Rel.1, but on the other hand there will be no PS set generation in case of online FSM Rel.2 extension. If it is sure that within WN6.0 no extension modules have been inserted, this parameter can be set to off.


14 (53)

max_sched_thrp: If the parameter has been set to true, related to the types

of the cells, maximum throughput (granularity 3) is defined to the scheduler. The standard conversion tables are not taken into account. The number of HSDPA processing set 2 is set accordingly in order to have number of licenses aligned with throughput assigned.

Example:If assignment of the cells to the scheduler has been the following:

scheduler 1 -> 3 SC cells; 2 MIMO cells Scheduler gets assigned 3 * 21 + 2 * 42 = 147 Mbps == 7 * 3 thrp steps (7 * 21 Mbps).

add_throughput_SM_M: Without increasing # processing sets, this parameter adds additional throughput to the Master System Module compared to standard conversion without increasing. The intention of that parameter is to be prepared for future capacity increase, once the operator installs the licenses accordingly.

add_throughput_SM_S: Without increasing # processing sets, this parameter adds additional throughput to the Slave System Module compared to standard conversion. The intention of that parameter is, to be prepared for future capacity increase, once the operator installs the licenses accordingly.

pre_def_PS_2_per_SM_x: For every SM_X (C,D,E), this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.

pre_def_PS_3_per_SM_x For every SM_X (C,D,E), this parameter assigns a fix number for Processing Set 3. The throughput is impacted as well.

pre_def_PS_2_per_SM_x_DC For every SM_X having assigned at least one DC configuration, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well. For that SM, the value of the parameter pre_def_PS_2_per_SM_x is not considered.

pre_def_PS_3_per_SM_x_DC For every SM_X having assigned at least one DC configuration, this parameter assigns a fix number for Processing Set 3. The throughput is impacted as well. For that SM, the value of the parameter pre_def_PS_3_per_SM_x is not considered.

pre_def_HSU_per_SM_x For every SM_X (C,D,E), this parameter assigns a fix number for HSUPA PS

pre_def_HSU_per_SM_x_DC:


15 (53)

For every SM_X having assigned at least one DC configuration, this parameter assigns a fix number for HSUPA Processing Sets. For that SM, the value of the parameter pre_def_HSU_per_SM_x is not considered.

pre_def_thrp_per_SM_x For every SM_X (C,D,E), this parameter assigns a fix throughput.

pre_def_thrp_per_SM_x_DC For every SM_X having assigned at least one DC configuration, this parameter assigns a fix throughput. For that SM, the value of the parameter pre_def_thrp_per_SM_X is not considered.

predef_HSU_PS This parameter assigns a fix number of HSUPA Processing sets independently from any pre-conditions.

predef_HSDPA_PS_x (x=1,2,3) This parameter assigns a fix number of HSDPA Processing sets x independently from any pre-conditions

PS_according_to_minimum_rule: off/on o off: conversion tool does not add throughput and does not add #

processing sets. BTS by itself adds throughput, if needed.

o On: minimum rule is considered in the conversion tool => conversion tool does add throughput and related # of processing sets.

Rel99CEconsumpt_CCCH (off/on

)

On: In case of CCCH processing resources included in Flexi Rel2 system module are not sufficient for current BTS cell configuration, additional CCCH processing subunit(s) are allocated. These CCCH processing subunits consume Rel.99 CE licenses. In RU20, one subunit capacity was 36CEs and in RU30 its capacity has been increased to 48CEs. For that reason per each additional CCCH subunit, the conversion tool subtracts 12 CEs from the CE consumption, which means that during the upgrade, additional 12 CEs licenses are given for free. Off:CCCH processing resources are not considered and no Rel.99 CEs are substracted from the consumption

additionalR99CEs_per_SM_x (x = C,D,E) For every SM_x (C,D,E), this parameter assigns additional Rel.99 CEs.

predef_PS_2_shared_3_16QAM

In case of 16QAM and usage of three shared schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.


16 (53)

predef_PS_2_shared_4_16QAM In case of 16QAM and usage of four shared schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.

predef_PS_2_shared_5_16QAM In case of 16QAM and usage of five shared schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.

predef_PS_2_FBB_5_16QAM In case of 16QAM and usage of five full baseband schedulers, this parameter assigns a fix number for Processing Set 2. The throughput is impacted as well.

Remark 1:

a) Rules for setting the parameters pre_def_PS_y_per_SM_x / pre_def_PS_y_per_SM_x_DC.

Setting one parameter, but no values for the others results that pre_def_PS_y_per_SM_x = pre_def_PS_y_per_SM_x_DC the other parameters get the value 0

Example 1 :

Setting the parameter pre_def_PS_2_per_SM_D_DC=3, but no values for the other pre_def_xx_per_SM parameters, we assumed: pre_def_PS_2_per_SM_C_DC=0 pre_def_PS_2_per_SM_D_DC=3 pre_def_PS_2_per_SM_E_DC=0 pre_def_PS_2_per_SM_C=0 pre_def_PS_2_per_SM_D=3 pre_def_PS_2_per_SM_E=0

Example 2:

Setting the parameter pre_def_PS_2_per_SM_D=3, but no values for the other pre_def parameters, we assumed: pre_def_PS_2_per_SM_C=0


17 (53)

pre_def_PS_2_per_SM_D=3 pre_def_PS_2_per_SM_E=0 pre_def_PS_2_per_SM_C_DC=0 pre_def_PS_2_per_SM_D_DC=3 pre_def_PS_2_per_SM_E_DC=0

b) Setting explicit values for the parameters pre_def_PS_y_per_SM_x / and pre_def_PS_y_per_SM_x_DC without assigning values for the others, results in assigning the value 0 for the other parameters.

Example 3: Setting the parameter: pre_def_PS_2_per_SM_D=3 AND pre_def_PS_2_per_SM_D_DC=6, we assumed: pre_def_PS_2_per_SM_C=0 pre_def_PS_2_per_SM_D=3 pre_def_PS_2_per_SM_E=0 pre_def_PS_2_per_SM_C_DC=0 pre_def_PS_2_per_SM_D_DC=6 pre_def_PS_2_per_SM_E_DC=0 c) pre_def_thrp_per_SM_x only can be used in combination with

pre_def_PS xx Via pre_def_PS xx you will assign processing sets resulting in dedicated licenses. The throughput can be modified via pre_def_thrp_per_SM_x. Example 4: Operator sets: pre_def_PS_2_per_SM_E_DC=2 througput assigned for FSME is always 42Mbps But setting pre_def_thrp_per_SM_E= 12 (== 84Mbps), would result that 2 PS2s per FSME have been assigned with throughput configured: 84Mbps for FSME Example 5: FSME (HSDPA without DC) + FSME (HSDPA with DC) Pre-condition:

Predef_PS_2_per_SM_E = 2 (=> 2x21Mbps = 6 throughput steps) Predef_PS_2_per_SM_E_DC = 4 (=> 4x21Mbps = 12 throughput

steps)


18 (53)

Case 1: pre_def_thrp_per_SM_E = 9 pre_def_thrp_per_SM_E_DC = 12 total throughput for BTS = 9+12 throughput steps Case 2: pre_def_thrp_per_SM_E = -1 pre_def_thrp_per_SM_E_DC = 12 total throughput for BTS will be = 12 + 6 (Predef_PS_2_per_SM_E for MSM / pre_def_thrp_per_SM_E_DC for ESM ) Case 3: pre_def_thrp_per_SM_E = 9 pre_def_thrp_per_SM_E_DC = -1 total throughput = 12+9 throughput steps (pre_def_thrp_per_SM_E for MSM and pre_def_thrp_per_SM_E_DC for ESM) Case 4: pre_def_thrp_per_SM_E = -1 pre_def_thrp_per_SM_E_DC = -1 total throughput = 6+12 throughput steps (taken from Predef_PS_2_per_SM_E and Predef_PS_2_per_SM_E_DC)

The two parameters shareOfHSUPALicences and shareOfHsdpaUser always are part of the output XML generated.

Remark 2:

shareOfHsdpaUser : The parameter shareOfHsdpaUser is set depending on the number of schedulers of the LCGs it had in RU20. Example: If there are two LCGs and LCG1 has 2 schedulers and LCG2 has 1 scheduler then in RU30 LCG1 should have 66% of the users and LCG2 34% of the users. shareOfHSUPALicences: Depending on the number of processing sets calculated for the LCGs, the share of HSUPA licenses is set accordingly. Example: If there are two LCGs and the conversion tool calculates for LCG1 3 HSUPA PSs and for LCG2 7 HSUPA PSs, then shareOfHsupaLicenses for LCG1 will be 100% x 3/(3+7) = 30% and shareOfHsupaLicenses for LCG2 will be 100% x 7/(3+7) = 70%. Without that parameter setting, the conversion tool would give 10 processing sets in total and without defining the parameter shareOfHSUPALicences, the processing sets would be distributed evenly (5 for each LCG). In case the need to switch off (not to generate these parameters), the command interface can be used:


19 (53)

[-user_split_according_to_sched on/off] [-share_of_HSUPA_PS on/off]

Remark 3:

In case of usage of the parameters pre_def_HSU_per_SM_x, pre_def_HSU_per_SM_x_DC and predef_HSU_PS, the parameter shareOfHSUPALicences is calculated according to the following rules:

- if there exists Rel1 FSM then the LCG which is located in Rel2 ESM gets 100% of HSUPA licenses

- if there is no Rel1 FSM in configuration then each LCG gets share of licenses proportional to number of HSPA enabled cells (WCEL objects corresponding to LCEL objects of that LCG which have HSDPAEnabled or DCellHSDPAEnabled set to true).

- In case of just one LCG, then this parameter is not generated. In case the need to switch off, the command interface still can be used:

[-share_of_HSUPA_PS on/off]

6.4 Usage of flexible configuration files

This functionality allows to apply user specific configuration files. In addition to the configuration file RU30BBconv.exe.config, applying the option -- config - an additional configuration file can be entered. That overwrites the settings of RU30BBconv.exe.config. Applying that option, offers the possibility to have common values in RU30BBconv.exe.config and in addition different customer specific config files. The format of that customer specific configuration file is as defined in the custom_config_file template:

99 99 99 99


20 (53)

69

1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


21 (53)

6.5 Usage of input .txt for selected IDs to be converted

In addition to the option - li BTS-Ids-list to define the list of BTS Ids to be converted, the BTS IDs can be listed in a .txt file: Example: 3,5,20-25,600-950. Or instead of separating via commas, separate lines can be used.

6.6 BTS specific settings on processing sets and Rel.99 CE consumptions

For dedicated BTSs, this enhancement allows specific settings on processing sets and Rel.99 CE consumption. The parameter -obj_spec_config allows to enter an XML file containing BTS specific settings for HSxPA processing sets and Rel.99 CE consumption: -obj_spec_config . These setting are defined via an input XML having the structure as described by the example as shown below: 45 5 1 4 0 7 345 15 9 4 0 3 67 90 1 5


22 (53)

8 0

Remarks: o Setting of these parameters is optional. If a parameter is missing, then

settings from the configuration files resp. command line are used o If a BTS ID is not listed, then all parameter settings are taken from the

configuration files resp. command line

6.7 Rel.99 CE license consumption calculated by the tool

As in WBTS 7.0, CE capacity is replaced by HSxPA processing sets, licensed CE capacity from WBTS 6.0 will be reduced accordingly and remaining Rel.99 CE licenses will be assigned to the WBTS7.0. This CE license reduction can be impacted by parameters (see chapter 6.3)

HSDPA_CE_Consumption_Multiplicator HSUPA_CE_Consumption_Multiplicator additionalRel.99CEs Rel.99CEconsumpt_CCCH additionalR99CEs_per_SM_x

which have to be agreed between NSN and the customer before the conversion is executed. The reduction of Rel.99 CEs licenses is called Rel99 CE consumption. # Rel.99 CE licenses @ WBTS7.0 = max {# CE licenses @ WBTS 6.0 - Rel99 CE consumption, 0} ; # Rel.99 CE licenses @ WBTS7.0 is calculated by the BTSs startup. Rel.99 CE consumption is calculated in the following way: Rel99 CE consumption of HSPA for one BTSHSDPA_CE_Consumption + HSUPA_CE_Consumption - additionalR99CEs ;

:

HSDPA_CE_Consumption = ((number of 16 per BTS schedulers x 36 Rel99 CEs) + (number of 16 per cell schedulers x 36 Rel99 CEs) + (number of full BB schedulers


23 (53)

x 72 Rel99 CEs) + (number of efficient BB schedulers x 72 Rel99 CEs))* HSDPA_CE_Consumption_Multiplicator; HSUPA_CE_Consumption = # HSUPA processing sets * HSUPA_CE_Consumption_Multiplicator; Note 1:

Consequently, in case Rel.99 CE consumption is higher than # CE licenses @ WBTS 6.0 (Feature Code 308), WBTS7.0 will not get Rel.99 CE licenses.

Note 2:

In case of CCCH processing resources included in Flexi Rel2 system module are not sufficient for current BTS cell configuration, additional CCCH processing subunit(s) are allocated. These CCCH processing subunits consume Rel.99 CE licenses. In RU20, one subunit capacity was 36CEs and in RU30 its capacity has been increased to 48CEs. For that reason per each additional CCCH subunit, the conversion tool subtracts 12 CEs from the CE consumption, which means that during the upgrade, additional 12 CEs licenses are given for free (via configuration parameters, this behavior can be switched off).

6.8 Throughput calculation by the tool

For a better understanding we consider the example below:

3+3+3 configuration, FSMD+ FSME, 2xLCG, FRGP+FRGF HSDPA 64 QAM enabled DC is used on F1 & F2; HSUPA activated on all layers 4 Schedulers (3 shared schedulers - 64QAM, Dual Cell - and 1 shared

scheduler - 64 QAM) 2 x LCGs used LCG 1 assigned to SM1; LCG2 assigned to SM0 (SM: System Module)

Cell9

Cell3

Cell6

Cell7

Cell1

Cell4 Cell5

Cell8

Cell2f1

f2

f3

Tcellgroup#2

Tcellgroup#3

Tcellgroup#4

Tcellgroup#1

LCG 1

LCG 2


24 (53)

Based on HSDPA Processing sets calculated, the throughput is calculated and distributed to the schedulers. The distribution is in steps each step get 7.2 Mbps. In the example above we get:

for 3 shared schedulers (64QAM, DC) : 2 PS 2 and 1 PS 3 and for the shared scheduler on frequency 3 we get 1 PS 2.

In total 21 steps = 151 Mbps have to be distributed.

The assignment of cells to the scheduler is according to the TCell Values assigned in RU20. TCell values are from 0..9 and according to 3GPP they are grouped into TCellGroups:

TCellGroup 1: TCell values 0,1,2 TCellGroup 2: TCell values 3,4,5 TCellGroup 3: TCell values 6,7,8 TCellGroup 4: TCell values 9

The assignment of TCellGroups to schedulers in RU30 is as follows

scheduler 1: TCellGroup1, TCellGroup 3 scheduler 2: TCellGroup 2, TCellGroup 4

Sched1 SM0: 3 cells; (64QAM cells); cell7, cell8, cell9 Sched2 SM0: 0; Sched1 SM1: 2 cells (DC cells); cell 2, cell 5 Sched2 SM1: 4 cells (DC cells); cell 1, cell3, cell4, cell6 The granularity of throughput step distribution of processing sets is: Processing Set 1 Processing Set 2 Processing Set 3 t.put step granularity (7.2 Mbps)

1 3 3

Our example shows: 3 PS2 and 1 PS 3. In total 3 * ( 3 steps) + 1 *(4 * 3 steps) = 21 steps to be distributed;


25 (53)

Distribution of schedulers is according to weights: Type of cell Weight MIMO 4 DC 3 64QAM 1 else 1

Distribution of cells:

Weight Type of cell Cells @ Sched 1 (SM0)

Cells @ Sched 2 (SM0)



4 MIMO 0 0 0 0 3 DC 0 0 2 4 1 64QAM 3 0 0 0 1 else 0 0 0 0

Calculation of throughput - based on weight distribution:

Weight @

Sched 1 (SM0) Weight @ Sched 2 (SM0)

Weight @ Sched 1 (SM1)


Sum of weights: 3+0+6+12 = 21

0*4 + 0*3+3*1 + 0*1 = 3

0*4 + 0*3+3*0 + 0*1 = 0

0*4 + 2*3+3*0 + 0*1 = 6

0*4 + 4*3+3*0 + 0*1 = 12

Throughput steps for distribution

21(steps) * (3/21)=3 steps (~22Mbps)

21(steps) * (0/21)=0 steps (~0 Mbps)

21(steps) * (6/21)=6 steps (~43 Mbps)

21(steps) * (12/21)=12 steps (~86Mbps)

Remark 1: For each System Module, a maximum of two schedulers are existing. Remark 2: There is existing a Minimum Throughput rule, which means that the sum of throughput steps commissioned for SM has to be at minimum the result value: Sum_Throughput_Min = ROUNDDOWN (( Nbr_Non_MIMO_Cells per SM + 2 x Nbr_MIMO_Cells per SM - 1) / 6) x 12 throughput steps + granularity_step; In case the previously calculated throughput steps are not fulfilling that rule, additional throughput steps will be assigned.


26 (53)

Our example: SM1: Rounddown ((6 + 2 * 0 1)/6)*12 + 3 = 3; SM0: Rounddown ((3 + 2 * 0 1)/6)*12 + 3 = 3; As in our example the minimum rule is fulfilled no steps are added.

Result is the following:

771 3 0 1 0 0 2 6 1 1 12 1 2 0 3 1 7


27 (53)

What happens in case the throughput cannot be distributed evenly ?Lets have 3 PS2 and 1 PS3, which means to distribute 21 throughput steps. Example: Weight Type of cell Cells @

Sched 1 (SM0)




4 MIMO 0 0 0 0 3 DC 4 0 0 0 1 64QAM 0 0 4 0 1 else 0 0 0 0

Calculation of throughput - based on weight distribution:

Weight @ Sched 1

(SM0) Weight @ Sched 2 (SM0)



Sum of weights:12+0+6+4 = 16

0*4 + 4*3+3*0 + 0*1 =12

0*4 + 0*3+3*0 + 0*1 = 0

0*4 + 0*3+4*1 + 0*1 = 4

0*4 + 0*3+3*0 + 0*1 = 0

Throughput steps for distribution (should be)

21(steps) * 12/16)= 15.75 steps

21(steps) * (0/16)=0 steps (~0 Mbps)

21(steps) * (4/16)=5,25 steps

21(steps) * (12/16)=0 steps

rounded steps

3 (granularity) * rounddown(15.75/3) = 3*5 = 15

0 3 * rounddown(5.25/3) = 3*1 = 3

0

18 < 21 => 3 steps to distribute in addition. Who gets the 3 addl steps ? The remaining steps are distributed between those schedulers, which

0.75/15.75 = 0.047619

2.25/5.25 = 0,428


28 (53)

relatively should get more (0,428 > 0.047619 => SM1. Sched1 Final distribution of steps

15 0 3 + 3 = 6 0

6.9 Information about conversion rules

There are existing pre-defined conversion rules, which can be impacted via setting of dedicated parameters shown in chapter 6.3. For HSDPA the number of processing sets is evaluated by mainly checking type and number of schedulers (see chapter 9.2)

For HSUPA, the number of HSUPA processing sets is calculated by checking the number of users or by assigning a predefined number.

6.10 Behaviour in case of Flexi System Module Rel.1

The new BB concept has been introduced for Flexi Rel.2 onwards and is not applied for Flexi Rel.1. In case of upgrading Flexi Rel.1, the conversion tool is not needed to be applied, but it does not harm if applied, as the conversion tool would not generate output for Flexi Rel.1. In that case, during the upgrade, the Rel.1 BTS just sets the parameter numberOfR99ChannelElements to that value, which equals the number of CEs, which have been available in RU20.

But it is important to note, that within WN6.0 an extension module can be added without re-commissioning. In those cases where re-commissioning has not been performed after extension module insertion, the BTS SCF will not contain extension module information. So even extension module is Rel.2 version the conversion tool would not generate Processing Sets, which would result that for those mixed sides no HSxPA would be commissioned.

Due to missing information within the SCF, the following algorithm has been implemented: 1) Sites having FSM Rel.1 as master system module and FSM Rel.1 as

extension module, no processing sets will be generated. 2) For sites having FSM Rel.1 in SCF only, it is assumed that FSM Rel.2

extension module is existing, if at least one of the following HSPA+ features have been enabled:


29 (53)

- RAN 1686 HSPA 72 Users Per Cell - RAN1643 HSDPA 64QAM - RAN1470 2ms TTI

These HSPA+ features are controlled by RNC, but can be enabled / disabled on cell level and BTS level

Consequently these features can be disabled for all Flexi Rel.1 (as these are anyway not supported by Flexi Rel.1).

In case of proper configuration (not configured for Flexi Rel.1 ), no Processing Sets are generated

Otherwise Processing Sets will be generated for Flexi Rel.1 - does not harm, but uses Processing Sets and Rel.99 CEs from the pool.

This can be compensated via providing extra / additional Rel.99 CEs and processing sets

As additional option, in case it is sure that no extension modules have been inserted online within WN6.0, we have a parameter PS_Rel_1 (on

- In that case no processing sets will be generated for FSM Rel.1, but on the other hand there will be no PS set generation in case of online FSM Rel.2 extension.

/off), which can be set to off.

In case a Rel.2 extension module has been added in WN6.0 without re-commissioning, but none of the features above has been activated, the conversion tool will not generate processing sets. In that case, the WN7.0 BTS needs to be commissioned with HSxPA after having upgraded to WN7.0

In case of doubts, if online inserted extension modules are existing or not, it recommended to run the conversion having set the parameter PS_Rel_1 = on.

6.11 NetAct cleanup script

The NetAct License Manager command line interface is used to cleanup the unnecessary license after WBTS upgrade. The conversion is aimed to replace licences supporting RU20s/I-HSPA Rel.3 baseband by licences for RU30s/ I-HSPA Rel.4 baseband. The NetAct cleanup returns capacity to the NetAct pool, removes NMS licences from the NetAct Licence Manager and also deletes no longer needed licenses from BTSs. This is an optional step to be performed and only should be performed when it is ensured that no rollback is required. Input for that script is the XML file from the RU30ConvTool containing a list of BTSs the conversion should be performed. Licenses which are cleaned up are:

RAN1034 Shared HSDPA Scheduler for Baseband Efficiency (no longer

needed for Flexi Rel.2) RAN912 Licence Based BTS Channel Capacity (no longer needed at

all)

RAN 912 licenses are cleaned up for both Flexi Rel.1 and Flexi Rel.2 and licenses for RAN1034 are cleaned up for Flexi Rel. 2 only. In case of mixed BTS


30 (53)

configurations (BTS contains both Flexi Rel1. and Flexi Rel.2), RAN1034 licenses are not cleaned up. Note 3: The cleanup script only should be applied for BTSs, which have been upgraded successfully.

6.11.1 Steps of the cleanup procedure

The cleanup procedure consists of two steps: - first cleanup of license manager data base and repository and then deletion of

licenses from WBTSes. During the conversion phase the NetAct Licence Manager searches for NMS licences for the given list of WBTSes. The capacity allocated for those WBTSes is returned to the NetAct pool.

- Second step deletion of the NMS licenses from the WBTSes. This step should be triggered manually after the WBTS migration is completed. Opfiles are created by the conversion tool. The default directory for the opfiles is $HOME/lic_conversion_opfile. The opfiles can be executed with license manager command line tool.

How to call consecutive steps of the NetAct cleanup: Using liccuimx run the conversion step by typing in command line:

liccuimx -op licenceConversion inputFile -deleteFromNEs T

Note: option deleteFromNEs causes creation of delete operation files. The opt files will not be executed automatically!

Run licconvdelmx.sh to delete license files from BTSes:

licconvdelmx.sh

In the case shown above licconvdelmx.sh uses a default directory with opfiles (i.e. $HOME/ lic_conversion_opfile). Optionally path to directory containing operation files can be given as an input parameter:

licconvdelmx.sh

After successfully finished delete operation particular opfile is removed from the directory.

7. NOTE

7.1 Questions & Answers

Q1: What happens in case conversion is done in day x but SW upgrade is done one week later ?


31 (53)

A1: After the conversion no configuration tasks impacting the baseband (e.g. modifying # Channel Elements, modifying BTS schedulers, modifying # users, modifying HSxPA configurations) should be performed. In the final step of BB conversion the SCFs are downloaded to the BTS. The BTS stores the new RU30 baseband parameters but these parameters are not becoming active. As soon as the upgrade is done the parameters will become effective. In case of long time difference between conversion and upgrade of the BTS having BB changes in between it is recommended to run the conversion tool again and repeat steps 1-5 of the description above.

Q2: What happens in case of BTS resets, before the BTS is upgraded to RU30 ?

A2: There is no impact for the BTS BB conversion procedure

Q3: What happens in case of fallback to RU20 (WN 6) for an already upgraded BTS ?

A3: When SW is downgraded back to WN6, BTS will use the WN6 SCF, which means RU30 specific parameters are no longer used after BTS fallback. RU30 licenses, already downloaded to the BTS are ignored and the BTS continues to operate in RU20 as before.

If the WN6 BTS is required to be upgraded again to >= WN 7.01 and the BB configuration has been changed, the RU30ConvTool is needed to run again and the newly converted parameters have to be downloaded before the next upgrades attempt to WN7.0

Q4: When spare parts are replaced and BTS is already running on WN 7.0. Has the conversion to be executed?

A4: No, in that case, conversion is not needed to be performed. When the BTS is running with WN7.0 SW (conversion has been performed earlier) it means that the commissioning file already contains all WN7.0 parameters that were generated by the conversion tool.

Now when FSM is replaced with another one, usually operator stores the SCF from old FSM before removing the FSM. After the new FSM has been added and the WN7.0 SW has been downloaded/activated to the new FSM, the commissioning file stored is added to new FSM (e.g. using planned commissioning applying BTSs site manager). The sequence to be performed is consistent with the sequence that has been used in previous releases (as WN6.0).

Q5: The conversion tool provides the Rel.99 CE consumption. How to know, how many LKs are needed to be ordered?

A5: As RU20 does not have a configuration parameter (#CEs), and as the conversion tool is based on configuration parameters, it cannot report the number of Rel.99 CEs needed for RU30. It calculates the Rel.99 CE consumption. The information about the number of CEs to be ordered can be obtained in the following way:


32 (53)

a. Check number of existing CEs @ RU20s BTSs which easily can be retrieved by using Netacts license manager

b. Calculate: # Rel.99CEs@RU30 (to be ordered) = CEs @ RU20s BTSs Rel.99 CE consumption calculated by the tool

Example:

a. Check number of existing CEs @ RU20s BTSs by using Netacts license manager.

b) Run conversion and the calculate: #Rel.99 CEs to be ordered for RU30 = value from a) - Rel.99 CE consumption calculated by the tool

Q6: During the conversion a SCF is generated by NetAct, which is used by upgrading the BTS from WN6.0 to WN7.01. In case of a rollback, the previous SCF applied for WN6.0 is taken into use again. If now after some time the conversion is re-executed, a new SCF is generated. How can these SCFs be differentiated and how can it be ensured that wrong SCF is applied in the 2nd upgrade ?

A6: The SCF is generated by NetAct and has the following syntax: SCF_.xml, where version is the NetActs plan id.


33 (53)

In case of an already existing SCF,a new conversion results in a new SCF, where version has been increased by 1: SCF_N.xml -> SCF_N+1

If after the rollback, it is not likely to upgrade in next time to WN7.01 again, previously generated SCF_N.xml can be deleted.

.xml.

Q7: Why is needed NetAct OSS 5.4 CD1 and do you have some more background.

A7: NetAct OSS 5.4 CD1 is needed to ensure that all conversion tools output parameters are supported. The support of the parameters shareOfHSDPAUser, shareOfHSUPALicences has been introduced as an conversion tools extension and requires dedicated NetAct support. Otherwise import to NetAct of the XML file generated fails. These parameters are supported in NetAct OSS 5.4 CD1 but also in some versions of OSS5.3 CD3. To check, if these parameters are supported, please apply the procedure as described below:

DS server: rpm qa|grep CMDBTC example: [racuse11@enest ~]$ rpm -qa|grep CMDBTC Nokia-RAC-CMDBTC-DB-5.0-5.50.23-1 Nokia-RAC-CMDBTC-DB-5.0-5.50.25-1 [racuse11@enest ~]$ NetAct adaptation version must be higher/equal Nokia-RAC-CMDBTC-DB-5.0-5.50.25-1

If the parameters shareOfHSDPAUser, shareOfHSUPALicences are not needed to be part of the output XML, via cml the output generation can be switched off. But in general its recommended to generate these parameters as that ensures settings related to RU20s configuration otherwise the share would be 50%/50%. In case of 1LCG used, these parameters are not relevant.


34 (53)

In addition, OSS 5.4 CD1 does not require any 3G SCF Mgmt license to export all objects needed.

Q8: What happens, if the conversion tool is not applied in BTSs upgrade ?.

A8: If the conversion tool has not been applied, then no processing sets will be configured. Consequently the BTS will not be able to perform HSxPA.

# Rel.99 CEs @RU30 = # CEs@RU20

7.2 Estimated time running the conversion

The time running the conversion for all BTSs of a RNC cluster is estimated by 1h. This includes the steps for uploading BTS and RNC data, exporting BTS and RNW data into the tools input XML file , executing the conversion tool, importing back tools generated XML to NetAct and downloading SCFs to the BTS, before executing the SW upgrade from WN6.0 to WN7.0. This time is an average value and can vary - mainly impacted by the steps for extracting and importing the data and the number of BTS to be converted. For that time estimation we consider an average size of 150 200 WBTS connected to the RNC.

8. REFERENCES

9. APPENDIX

9.1 Description of detailed upgrade steps

0. Precondition NEs work on RU20 and OAM link is connected. All the NEs are connected to NetAct. NetAct should be upgraded to RU30 first. RNC/OMS should be upgraded to RU30. (RAN2131 license auto distribution required) Topology information synchronized between NE and NetAct. Make sure you have enough old license in RU20. 367=1 is not allowed for upgrade.

1. Upload SCF from all BTS and RNC RNW to NetAct in Configurator Start page->Configuration->CM Operations Manager


35 (53)

Upload RNC RNW The RNC path is PLMN-PLMN/RNC-XXX Upload RNW is enough for the conversion; do not select other like ATM, IP, and Signaling to prevent big exported .xml file


36 (53)

Upload BTS SCF The BTS path is PLMN-PLMN/RNC-XXX/WBTS-XX


37 (53)

2. Export Actual configuration for conversion


38 (53)

The BTS path: PLMN-PLMN/RNC-XXX/WBTS-XX


39 (53)

Its also possible to select a complete RNC:


40 (53)

Define object classes to be exported: For BTS:

For RNC


41 (53)

3. Execute offline conversion by tool The tool contain 3 files

How to execute Open command line of your OS from Start->Run->cmd.exe Change directory with cd command to the tools folder. E.g.

D:\yxian\Desktop\RU30BBConvertion\RU30BBconv_1.0> Execute the tool like this

Command format: RU30BBconv.exe


42 (53)

Execute finish

4. Import the new plan to NetAct After the offline conversion, import the converted result as a new plan to NetAct. The result is like this (The file name is output_0621.xml, it depend on what you defined in executing the tool): 594 9 0 1 2 0 2 6 1 1 6 1 2 0 7


43 (53)

0 2 Importing


44 (53)

If status if finish, you can close the window now. You can find the new plan on:


45 (53)

Then approve the new plan, and the plan status will change to approved.

5. New plan provision


46 (53)

During the provisioning, there might be coming validation warnings. But those are not preventing the provisioning of the processing set configuration plan.


47 (53)

Check new plan successfully activate

Check the marked true SCF file in BTS ROM whether it contains the new parameters as the result generated by the tool.

6. Start upgrade Upgrade the BTS from RU20 to RU30. Local, remote, NetAct download are all OK. After SWDL complete, during startup, an online conversion will be proceeded by the BTS itself. This procedure will calculate the R99CEs by using the amount of old CEs and the result R99CEs of offline conversion. Number of R99CEs in RU30=Old CEs amount-Number of offline conv R99CEs After that ,new parameters will be set to BTS

9.2 Trouble Shooting

Please find below cases which may help in case of trouble shooting:

9.2.1 Case 1 - Use internal value


48 (53)

9.2.2 Case 2 - plan provision validate failure

This case is not related to conversion tool itself, but is met it quite often.

During the provisioning, there might be coming validation warnings. But those are not preventing the provisioning of the processing set configuration plan.

The validation fail means that some of the values in the plan provided doesnt meet the rules defined by SEM.


49 (53)

9.2.3 Case 3 - No raml20.dtd file

Some of the new user would forget to copy this file to the folder of output xml file in the very beginning of using.

This file is to translate the xml file for conversion tool.

9.2.4 Case 4 - RNW parameters are not in export file

In this case, if one BTS only has BTSSC parameters in the export file, then the BTS would not be converted by the tool.

So if you get thas problem, please check if the RNW parameter upload has been successfully.

9.2.5 Case 5 - R99 CE set to zero after upgrade to WIN7.0

Example. We have 300 channel element license in WN6.0. But the CE consumption calculated by convert tool is 420. That means after the upgrade:

# Rel.99 CE licenses @ WBTS7.0 = 300 - 420 = -120

When BTS asks for related licenses, # Rel.99 CE licenses to be requested==0.

This may happen, in case of HSxPA consumption parameters

Those consumption values are commercial values to be agreed between customer and CT.

having values, resulting in very high consumption.


50 (53)

9.2.6 Case 6 Conversion tool does not generate any processing sets

Check, if all objects needed for the conversion have been selected for the export:

RNC : WBTS, WCEL BTS : BTSSC, LCEL, LCELG, ANTL

If all of those objects have been selected and the conversion still does not produce output (in the output XML all values for processing sets are set to the value 0), a reason may be that LCELG:lCelIdList has not been exported.

This may happen, if the NetAct license 3G SCF Mgmt license is missing. In that case install the license, make a new upload and then perform a new export.

Applying OSS5.4 CD1 (as listed in chapter HW/SW requirements) or higher NetAct releases does no longer require that NetAct license.

9.3 Standard rules for converting HSDPA

9.3.1 Minimum BB and 16 Users per cell Schedulers

Users: 16 Users: 32 72 72Mbps: 3,6 Mbps: 7,2 21 84 Users Mbps

# od schedulers Users Mbps # of PS1 # of PS2 # of PS3 Users Mbps1 16 3,6 1 32 7,2 16 3,62 32 7,2 1 32 7,23 48 10,8 2 64 14,4 16 3,64 64 14,4 2 64 14,45 80 18 3 96 21,6 16 3,66 96 21,6 3 96 21,67 112 25,2 4 128 28,8 16 3,68 128 28,8 4 128 28,89 144 32,4 5 160 36 16 3,610 160 36 5 160 3611 176 39,6 6 192 43,2 16 3,612 192 43,2 6 192 43,2

Total capacity

RU30 Difference

Total capacity

RU10/RU20


51 (53)

9.3.2 Shared Scheduler and Full Baseband Scheduler (16QAM)

9.3.3 Shared Scheduler and Full Baseband Scheduler (64QAM)


# od schedulers Users Mbps # of PS1 # of PS2 # of PS3 Users Mbps1 72 14 1 72 21 72 144 28 2 144 42 143 216 42 3 216 63 214 288 56 4 288 84 285 360 70 5 360 105 356 432 84 6 432 126 427 504 98 7 504 147 498 576 112 8 576 168 569 648 126 9 648 189 6310 720 140 10 720 210 7011 792 154 11 792 231 7712 864 168 12 864 252 84

RU10/RU20 RU30 Difference

Total capacity Total capacity


# od schedulers Users Mbps # of PS1 # of PS2 # of PS3 Users Mbps1 72 21 1 72 212 144 42 2 144 423 216 63 3 216 634 288 84 4 288 845 360 105 5 360 1056 432 126 6 432 1267 504 147 7 504 1478 576 168 8 576 1689 648 189 9 648 18910 720 210 10 720 21011 792 231 11 792 23112 864 252 12 864 252

RU20 RU30 Difference



52 (53)

9.3.4 Shared Scheduler and Full Baseband Scheduler (MIMO)

9.3.5 Shared Scheduler and Full Baseband Scheduler (DC-HSDPA)

Disclaimer

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given as is and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR


# od schedulers Users Mbps # of PS1 # of PS2 # of PS3 Users Mbps1 72 28 1 72 84 562 144 56 1 1 144 105 493 216 84 2 1 216 126 424 288 112 3 1 288 147 355 360 140 4 1 360 168 286 432 168 5 1 432 189 217 504 196 6 1 504 210 148 576 224 7 1 576 231 79 648 252 8 1 648 25210 720 280 8 2 720 336 5611 792 308 9 2 792 357 4912 864 336 10 2 864 378 42

Difference


RU20 RU30


# od schedulers Users Mbps # of PS1 # of PS2 # of PS3 Users Mbps1 72 42 1 72 84 422 144 84 1 1 144 105 213 216 126 2 1 216 1264 288 168 2 2 288 210 425 360 210 3 2 360 231 216 432 252 4 2 432 2527 504 294 4 3 504 336 428 576 336 5 3 576 357 219 648 378 6 3 648 37810 720 420 6 4 720 462 4211 792 462 7 4 792 483 2112 864 504 8 4 864 504

RU20 RU30 Difference



53 (53)

FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA, THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

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

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

Copyright Nokia Siemens Networks 2011. All rights reserved.

1. VALIDITY2. COMPATIBILITY / DEPENDENCIES TO OTHER PRODUCTS3. KEYWORDS4. SUMMARY5. HW / SW REQUIREMENTS6. DETAILED DESCRIPTION6.1 Overview of the RU30 Conv-tool6.2 Description of conversion procedure6.3 Parameters of the RU30 Conv-tool6.4 Usage of flexible configuration files6.5 Usage of input .txt for selected IDs to be converted6.6 BTS specific settings on processing sets and Rel.99 CE consumptions6.7 Rel.99 CE license consumption calculated by the tool6.8 Throughput calculation by the tool6.9 Information about conversion rules6.10 Behaviour in case of Flexi System Module Rel.16.11 NetAct cleanup script6.11.1 Steps of the cleanup procedure

7. NOTE7.1 Questions & Answers7.2 Estimated time running the conversion

8. REFERENCES9. APPENDIX9.1 Description of detailed upgrade steps9.2 Trouble Shooting9.2.1 Case 1 - Use internal value 9.2.2 Case 2 - plan provision validate failure9.2.3 Case 3 - No raml20.dtd file9.2.4 Case 4 - RNW parameters are not in export file9.2.5 Case 5 - R99 CE set to zero after upgrade to WIN7.09.2.6 Case 6 Conversion tool does not generate any processing sets

9.3 Standard rules for converting HSDPA9.3.1 Minimum BB and 16 Users per cell Schedulers9.3.2 Shared Scheduler and Full Baseband Scheduler (16QAM)9.3.3 Shared Scheduler and Full Baseband Scheduler (64QAM)9.3.4 Shared Scheduler and Full Baseband Scheduler (MIMO)9.3.5 Shared Scheduler and Full Baseband Scheduler (DC-HSDPA)

Documents

TS-3GBTS-SW-0148-I16 - WN7