TS-3GBTS-SW-0148-I22

TS-3GBTS-SW-148 Copyright 2013 Nokia Solutions and Networks. All rights reserved. CONFIDENTIAL

APPROVED version 22.0 Page 1

Technical Support Note

TS-3GBTS-SW-0148

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

WCDMA Base Stations

Flexi BTS

WN7.0

Approval date: (10-09-2013)

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

Nokia Solutions and Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their components.

If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Solutions and Networks for additional information.



Table of Contents 1. Compatibility / Dependencies to other products ........................................................................... 6 2. Keywords ..................................................................................................................................... 6 3. Summary ..................................................................................................................................... 6

3.1 ..... Location of the BB conversion tool ......................................................................................... 7 3.2 ..... SW Requirements .................................................................................................................. 7 3.3 ..... HW Requirements .................................................................................................................. 7

4. Detailed description ...................................................................................................................... 7 5. Solution / Instructions ................................................................................................................... 9

5.1 ..... Description of conversion procedure ...................................................................................... 9 5.2 ..... Parameters of the RU30 Conv-tool....................................................................................... 11 5.3 ..... Usage of flexible configuration files ...................................................................................... 22 5.4 ..... Usage of input .txt for selected IDs to be converted ............................................................. 24 5.5 ..... BTS specific settings on processing sets and Rel.99 CE consumptions ............................... 24 5.6 ..... Rel.99 CE license consumption calculated by the tool ......................................................... 25 5.7 ..... Throughput calculation by the tool ........................................................................................ 27 5.8 ..... Information about conversion rules....................................................................................... 32 5.9 ..... Behaviour in case of Flexi System Module Rel.1 .................................................................. 32 5.10 ... NetAct cleanup script ........................................................................................................... 33

5.10.1 Steps of the cleanup procedure ..................................................... 34 6. Note ........................................................................................................................................... 35

6.1 ..... Questions & Answers ........................................................................................................... 35 6.2 ..... Estimated time running the conversion ................................................................................. 38

7. References ................................................................................................................................ 38 8. Appendix .................................................................................................................................... 38

8.1 ..... Description of detailed upgrade steps .................................................................................. 38 8.2 ..... Trouble Shooting .................................................................................................................. 51

8.2.1 Case 1 - Use internal value ............................................................ 51 8.2.2 Case 2 - plan provision validate failure ........................................... 52 8.2.3 Case 3 - No raml20.dtd file ............................................................ 53 8.2.4 Case 4 - RNW parameters are not in export file ............................. 53 8.2.5 Case 5 - R99 CE set to zero after upgrade to WIN7.0 ................. 53 8.2.6 Case 6 Conversion tool does not generate any processing sets 54 8.2.7 Case 7 No existing BTSSC child object ...................................... 54 8.2.8 Case 8 No in BTSSC .................................................. 54

8.3 ..... Standard rules for converting HSDPA .................................................................................. 54 8.3.1 Minimum BB and 16 Users per cell Schedulers ......................... 54 8.3.2 Shared Scheduler and Full Baseband Scheduler (16QAM) 55 8.3.3 Shared Scheduler and Full Baseband Scheduler (64QAM) 55 8.3.4 Shared Scheduler and Full Baseband Scheduler (MIMO) ......... 56 8.3.5 Shared Scheduler and Full Baseband Scheduler (DC-HSDPA) 56

Contact:

Contact your local Nokia Solutions and Networks support



Summary of changes:

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 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 16

th approved version

20th September 16.1 Description added for processing set generation

for mixed configurations

21st September 17.0 17

th approved version.

26th September 17.1 Location of conversion tool added; Chapter 6.2:

Description of conversion procedure: Hint for ordering Rel.99 CEs added. Example extended by calculation of HSUPA PSs

16th October 18.0 18

th approved version.

19th October 18.1 New parameter:

max_throughput_steps_per_scheduler Improvements in description of parameter additional_numberOfHSxPASetx

29th October 19.0 19

th approved version

27th November 19.1 New parameters: force_for_extension and le_file

03rd

December 20.0 20th approved version

26th January 20.1 Extended description for BTS specific settings

Explanations added for parameter predef_CE_consumption.

29th January 20.2 New parameter: transfer_to_PS3 (off/on/on_thrp)



31th

January 21.0 21st approved version

02nd

April 21.1 Some minor re-wording for parameters pre_def_per_SM; upgrade from RU20-> RU30 EP1 or RU30 EP2;

10th September 21.2 New nsn template

10th September 22.0 22

nd approved version



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. COMPATIBILITY / DEPENDENCIES TO OTHER PRODUCTS

NA

2. KEYWORDS

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

3. 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. The procedure can be applied for both - upgrading BTSs from RU20 to RU30 EP1 or from RU20 to RU30 EP2. 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. 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 5.9.

3.1 Location of the BB conversion tool

Tool is located in NOLS, Product Related Tools -> Radio Access Network Tools -> RU30 Conv Tool

3.2 SW Requirements

Conversion tool: .NET 3.5 Microsoft environment

OSS5.4 CD1 (RAN2131: Automatic License Distribution- feature activated for handling the complete conversion procedure)

3.3 HW Requirements

WCDMA Flexi BTS (tool is applied for Flexi BTS)

4. DETAILED DESCRIPTION

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 directory where script is executed, 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.

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)

5. SOLUTION / INSTRUCTIONS

5.1 Description of conversion procedure

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

The steps below provide functional descriptions. Screen shots showing detailed steps have been added to Appendix 8.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 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. Do not use any options from Export Options window (under Options button).

Objects to be exported:



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. For Rel.99 CEs, the tool calculates the Rel.99 CE consumption, which are Rel.99 CEs reduced from existing CEs @ RU20. The difference from existing RU20 CEs is needed to be ordered. See chapter 5.6 and Q&As describing more details 6.1.

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 5.2), 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: 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.

5.2 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. In case of usage of predefined values, e.g. predef_HSDPA_PS_x or pre_def_thrp_per_SM_x, predef_HSU_PS, predef_CE_consumption this parameter is ignored.

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. In case of usage of predefined values, e.g. predef_HSDPA_PS_x or pre_def_thrp_per_SM_x, predef_HSU_PS , predef_CE_consumption, this parameter is ignored.

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



increased by 1, which results that the BTSs will request one additional license. In case of usage of predefined values, e.g. predef_HSDPA_PS_x or pre_def_thrp_per_SM_x, predef_HSU_PS , predef_CE_consumption, this parameter is ignored.

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. In case of usage of predefined values, e.g. predef_HSDPA_PS_x or pre_def_thrp_per_SM_x, predef_HSU_PS , predef_CE_consumption, this parameter is ignored.

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. In case of usage of predefined values, e.g. predef_HSDPA_PS_x or pre_def_thrp_per_SM_x, predef_HSU_PS , predef_CE_consumption, this parameter is ignored.

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. In case of usage of predefined values, e.g. predef_HSDPA_PS_x or pre_def_thrp_per_SM_x, predef_HSU_PS, predef_CE_consumption, this parameter is ignored.

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. In case of usage of predefined values, e.g. predef_HSDPA_PS_x or pre_def_thrp_per_SM_x, predef_HSU_PS, predef_CE_consumption, this parameter is ignored.

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. In case of usage of predefined values for Rel.99, this parameter is ignored.

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 5.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.

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.

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_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.

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.

predef_CE_consumption: This parameter assigns a fix value for CE consumption, without considering any schedulers or HSUPA processing sets. To make it absolutely clear: Setting this value does not mean to assign a fix value for Rel.99 CEs, which are available after the upgrade to RU30. This parameter allows to define a fix value of Rel.99 CEs to be reduced from CEs available @ RU20 (see chapter 5.6).

PS_Rel_1: This parameter can be on/off. Default is on. As described in chapter 5.9, 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.

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: 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. Only can be used in combination with pre_def_PS_per_SM_xx.

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. Only can be used in combination with pre_def_PS per_SM_xx_DC.

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

pre_def_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.

max_throughput_steps_per_scheduler In case of two active schedulers, this parameter defines the maximum number of throughput steps, which will be assigned to a scheduler. In case the # of throughput steps assigned to a scheduler is exceeded, the schedulers throughput is limited to the value



max_throughput_steps_per_scheduler. The missing throughput steps will be assigned to the 2nd schedule. Example: 2 schedulers; 24 throughput steps to be distributed for the SM; max_throughput_steps_per_scheduler:= 12; If sched 1 would get 15 steps and sched 2 would get 9 steps, then decrease 3 steps from sched 1 and add these 3 steps to sched 2, which will result to: sched 1: 12 steps and sched 2: 12 steps; In case the value max_throughput_steps_per_scheduler is selected too low, which would not allow to get distributed all the throughput steps, the parameter is ignored and the throughput is assigned without considering that parameter. In case of one active scheduler in use, this parameter is ignored as well.

force_for_extension = off /FSMC/FSMD/FSME

Within WN6.0 it was possible to add an extension module without re-commissioning (hot insert). In those cases where re-commissioning has not been performed after extension modules insertion, the BTS SCF does not contain extension module information. For those sides the conversion tools output can be wrong (wrong number of processing sets generated; wrong distribution on throughput). This option solves the problem. Sides where hot insert has been applied should be converted by applying the parameter force_for_extension. The module type, which has been inserted, is indicated by FSMC or FSMD or FSME. Note: The option force_for_extension only has to be applied for BTSs, which really have been extended via hot insert. For restricting the BTSs to be converted, the li, resp. li_file option can be applied.

transfer_to_PS3 (off/on/on_thrp).

This parameter instructs the tool always to report PS3 results. Just based on the number of processing sets calculated, independently on type of processing sets (PS1, PS2, PS3), conversion tool always reports processing set 3.

o In case of transfer_to_PS3 = on, just processing sets are calculated without impacting the throughput.

o In case of transfer_to_PS3 =on_thrp, processing sets are calculated by increasing the throughput.



Example: If tool would generate # PS2=4; # PS3=2, applying that parameter transfer_to_PS3, results that conversion tool generates #PS3 = 6. In case of transfer_to_PS3 = on, tool generates #PS3 = 6 and throughput = 4*21 + 2*84 = 252Mbps. In case of transfer_to_PS3 =on_thrp, tool generates #PS3 = 6 and throughput = 6 * 84Mbps = 504Mbps.

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 results to: 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, results to: 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=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, results to: 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)

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) Remark 2: The two parameters shareOfHSUPALicences and shareOfHsdpaUser always are part of the output XML generated. shareOfHsdpaUser : Setting 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:



[-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]

5.3 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



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

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

In addition to the option - li to define the list of BTS Ids to be converted, the BTS IDs can be listed in a .txt file (option li_file : Example: 3,5,20-25,600-950. Or instead of separating via commas, separate lines can be used. Analogously, the options -le respectively -le_file can be applied to exclude BTSs from the conversion.

5.5 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 . The following parameters are allowed for the BTS specific settings:

either additionalR99CEs or predef_CE_consumption

pre_def_HSU_PS

pre_def_HSDPA_PS_1

pre_def_HSDPA_PS_2

pre_def_HSDPA_PS_3 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 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 o either additionalR99CE or predef_CE_consumption can be applied,

as both together does not make sense

5.6 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. The CE license reduction can be impacted by parameters (see chapter 5.2)

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 BTS: HSDPA_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 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). Note 3: The conversion tool offers the possibility to assign a fix value of Rel.99 CE consumption (see parameter: predef_CE_consumption). To make it absolutely clear: Setting this value does not mean to assign a fix value for Rel.99 CEs, which are available after the upgrade to RU30. This parameter allows to define a fix value of Rel.99 CEs to be reduced from CEs available @ RU20. The number of CEs, which have been assigned to an NE can be retrieved by using the NetAct license manager.



Example: #CEs@RU20_BTS = 500 predef_CE_consumption= 200

Rel99CEs@RU30BTS = 500 200 = 300

5.7 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)

72 users per cell enabled

Cell9

Cell3

Cell6

Cell7

Cell1

Cell4 Cell5

Cell8

Cell2f1

f2

f3

Tcellgroup#2

Tcellgroup#3

Tcellgroup#4

Tcellgroup#1

LCG 1

LCG 2

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; 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)




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. The assignment of the throughput steps needed to fulfill the minimum rule is done by the BTS itself. 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



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:





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 relatively should

0.75/15.75 = 0.047619

2.25/5.25 = 0,428



get more (0,428 > 0.047619 => SM1. Sched1

Final distribution of steps

15 0 3 + 3 = 6 0

Remarks on HSUPA: This conversion results in 7 HSUPA processing sets. For each LCG, # of processing sets is calculated. LCG1 gets 4 HSUPA processing sets (as SM1 supports 80 UEs) and LCG2 gets 3 HSUPA processing sets, as 72 users per cell enabled, but SM0 does not support 80 UEs.

5.8 Information about conversion rules

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

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

5.9 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. In case of mixed configuration (master Rel.1 and extension Rel.2), processing sets are generated for the extension, if HSxPA has been configured.

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:

- 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/off), which can be set to off.

- 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.

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.

5.10 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 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.

5.10.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.

6. NOTE

6.1 Questions & Answers

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

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:

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 then 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.

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.xml.

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.

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.

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

6.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.

7. REFERENCES

Dimensioning WCDMA RAN: Flexi BTS Baseband (DN0981084)

8. APPENDIX

8.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

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



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



2. Export Actual configuration for conversion

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



Its also possible to select a complete RNC:



Define object classes to be exported: For BTS:

For RNC



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



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 0 2

Importing



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



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

5. New plan provision



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



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

8.2 Trouble Shooting

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

8.2.1 Case 1 - Use internal value



8.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.



8.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.

8.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.

8.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 having values, resulting in very high consumption.

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



8.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.

8.2.7 Case 7 No existing BTSSC child object

Incomplete information in the input .xml:

Reasons:

No upload from BTSs site configuration and hosting RNCs RNW data into the NetAct Configurator Database has been performed (Step 1 of conversion procedure)

Wrong NetAct Version used respectively missing 3G SCF Mgmt license

8.2.8 Case 8 No in BTSSC

Incomplete information in the input .xml:

Reasons:

No upload from BTSs site configuration and hosting RNCs RNW data into the NetAct Configurator Database has been performed (Step 1 of conversion procedure)

Wrong NetAct Version used respectively missing 3G SCF Mgmt license

8.3 Standard rules for converting HSDPA

8.3.1 Minimum BB and 16 Users per cell Schedulers



8.3.2 Shared Scheduler and Full Baseband Scheduler (16QAM)

8.3.3 Shared Scheduler and Full Baseband Scheduler (64QAM)

Users: 16 Users: 32 72 72

Mbps: 3,6 Mbps: 7,2 21 84 Users Mbps

# od schedulers Users Mbps # of PS1 # of PS2 # of PS3 Users Mbps

1 16 3,6 1 32 7,2 16 3,6

2 32 7,2 1 32 7,2

3 48 10,8 2 64 14,4 16 3,6

4 64 14,4 2 64 14,4

5 80 18 3 96 21,6 16 3,6

6 96 21,6 3 96 21,6

7 112 25,2 4 128 28,8 16 3,6

8 128 28,8 4 128 28,8

9 144 32,4 5 160 36 16 3,6

10 160 36 5 160 36

11 176 39,6 6 192 43,2 16 3,6

12 192 43,2 6 192 43,2

Total capacity

RU30 Difference

Total capacity

RU10/RU20




1 72 14 1 72 21 7

2 144 28 2 144 42 14

3 216 42 3 216 63 21

4 288 56 4 288 84 28

5 360 70 5 360 105 35

6 432 84 6 432 126 42

7 504 98 7 504 147 49

8 576 112 8 576 168 56

9 648 126 9 648 189 63

10 720 140 10 720 210 70

11 792 154 11 792 231 77

12 864 168 12 864 252 84

RU10/RU20 RU30 Difference

Total capacity Total capacity




1 72 21 1 72 21

2 144 42 2 144 42

3 216 63 3 216 63

4 288 84 4 288 84

5 360 105 5 360 105

6 432 126 6 432 126

7 504 147 7 504 147

8 576 168 8 576 168

9 648 189 9 648 189

10 720 210 10 720 210

11 792 231 11 792 231

12 864 252 12 864 252

RU20 RU30 Difference




8.3.4 Shared Scheduler and Full Baseband Scheduler (MIMO)

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




1 72 28 1 72 84 56

2 144 56 1 1 144 105 49

3 216 84 2 1 216 126 42

4 288 112 3 1 288 147 35

5 360 140 4 1 360 168 28

6 432 168 5 1 432 189 21

7 504 196 6 1 504 210 14

8 576 224 7 1 576 231 7

9 648 252 8 1 648 252

10 720 280 8 2 720 336 56

11 792 308 9 2 792 357 49

12 864 336 10 2 864 378 42

Difference


RU20 RU30




1 72 42 1 72 84 42

2 144 84 1 1 144 105 21

3 216 126 2 1 216 126

4 288 168 2 2 288 210 42

5 360 210 3 2 360 231 21

6 432 252 4 2 432 252

7 504 294 4 3 504 336 42

8 576 336 5 3 576 357 21

9 648 378 6 3 648 378

10 720 420 6 4 720 462 42

11 792 462 7 4 792 483 21

12 864 504 8 4 864 504

RU20 RU30 Difference




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 Solutions and 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 Solutions and 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 Solutions and 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 Solutions and Networks and the customer. However, Nokia Solutions and 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 Solutions and Networks will, if deemed necessary by Nokia Solutions and Networks, explain issues which may not be covered by the document.

Nokia Solutions and Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SOLUTIONS AND NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR 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.

NSN is a trademark of Nokia Solutions and Networks. Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright 2013 Nokia Solutions and Networks. All rights reserved.

TS-3GBTS-SW-0148-I22

Documents

sw requirements

bb conversion tool

additional information

environmental services

confidential approved

mandatory bb conversion

environmental policy

bts specific settings