RNC Generix Algorithm Changes and Impact on Counters and Kpi

WCDMA RAN and I-HSPA, Rel. RU30, Operating Documentation, Issue 06

RNC Generic Algorithm Changes and Impact on Counters and KPIs

DN09100723

Issue 01EApproval Date 2012-04-10

Confidential

2 DN09100723Issue 01E

RNC Generic Algorithm Changes and Impact on Coun-ters and KPIs

Id:0900d805809184ebConfidential

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 DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, 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 2012. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal, Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-satzes.

DN09100723 3



Table of contentsThis document has 58 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 Introduction to RU30 algorithm changes and impact on counters and KPIs9

2 Changes visible in pilot/networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1 Increase of M1001C15 RRC_CONN_ACT_FAIL_IU. . . . . . . . . . . . . . . 102.2 Failure counter not updated when radio link restore indication not received

from BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Failure counter M1002C556 REJ_DCH_DUE_POWER_BGR_DL not up-

dated correctly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 HSDPA serving cell change counter

correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Algorithm changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1 Use of maximum HSDPA user amounts returned by BTS. . . . . . . . . . . 143.2 Pre-emption functionalities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Power control of HSUPA DL control channel. . . . . . . . . . . . . . . . . . . . . 163.4 Admission control of HSDPA RT services . . . . . . . . . . . . . . . . . . . . . . . 173.5 DL spreading code handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.6 Internal improvement to downlink code change interface . . . . . . . . . . . 193.7 Preventive overload control triggered by UL loaded state . . . . . . . . . . . 213.8 Branch replacement correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.9 800K RRC connected UEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.10 RNC supports three DC-HSDPA layers. . . . . . . . . . . . . . . . . . . . . . . . . 253.11 RNC chooses the secondary cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.12 3GPP Rel-9 “Total RLC AM buffer size”

supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.13 RNC calculates HS-DSCH MAC-d flow peak rate . . . . . . . . . . . . . . . . . 293.14 Definition of MAC-hs window size changed internally in RNC. . . . . . . . 303.15 Special value of the

MaxBitRateNTRTMACDFlow parameter changed . . . . . . . . . . . . . . . . 313.16 E-DPDCH power interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.17 Prioritization and queuing of L2 resources. . . . . . . . . . . . . . . . . . . . . . . 333.18 Direct state transitions from Cell_DCH to Cell_PCH . . . . . . . . . . . . . . . 343.19 HSDPA serving cell change timing

improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.20 Prioritization of urgent procedures in RNC . . . . . . . . . . . . . . . . . . . . . . 363.21 Improvement to priority-based scheduling functionality . . . . . . . . . . . . . 373.22 Intra-BTS soft handover between LCGs . . . . . . . . . . . . . . . . . . . . . . . . 393.23 Changes to SIB priority handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.24 Measurement result update for optimizing handover control decisions in

case of fast moving UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.25 Initial DL power calculation when blind IFHO is used . . . . . . . . . . . . . . 453.26 HSDPA Measurement Power Offset calculation corrected . . . . . . . . . . 473.27 Multi-Band Load Balancing load weight calculation change . . . . . . . . . 493.28 New consistency check for parameters related to SRNC anchoring . . . 51

4 DN09100723



3.29 Faster RAB set-up and state transition time . . . . . . . . . . . . . . . . . . . . . . 523.30 HSDPA/HSUPA Dynamic Power Allocation corrections. . . . . . . . . . . . . 533.31 Correction to RT-over-NRT triggered by PS streaming mapped to DCH 543.32 Increase of HSUPA users per LCG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.33 GTP extension headers handling change in RNC . . . . . . . . . . . . . . . . . 563.34 H-RNTI allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

DN09100723 5



List of figuresFigure 1 DC-HSDPA with two possible secondary cell candidates . . . . . . . . . . . 26Figure 2 Sector-group-specific LCGs with two system modules . . . . . . . . . . . . . 40

6 DN09100723


Id:0900d80580919e1cConfidential

Summary of changes

Summary of changesChanges between issues 01D (2012-02-20, RU30) and 01E (2012-04-10, RU30)

GTP extension headers handling change in RNC (3.33)

• 3.33 GTP extension headers handling change in RNC has been added.

H-RNTI allocation (3.34)

• 3.34 H-RNTI allocation has been added.

Changes between issues 01C (2012-01-24, RU30) and 01D (2012-02-20, RU30)Faster RAB set-up and state transition time (3.29)3.29 Faster RAB set-up and state transition time has been added.

HSDPA/HSUPA Dynamic Power Allocation corrections (3.30)3.30 HSDPA/HSUPA Dynamic Power Allocation time has been added.

Correction to RT-over-NRT triggered by PS streaming mapped to DCH (3.31)3.31 Correction to RT-over-NRT triggered by PS streaming mapped to DCH has been added.

Increase of HSUPA users per LCG (3.32)3.32 Increase of HSUPA users per LCG has been added.

Changes between issues 01B (2011-12-13, RU30) and 01C (2012-01-24, RU30)800K RRC connected UEs (3.9)3.9 800K RRC connected UEs has been updated.

Prioritization and queuing of L2 resources (3.17)3.17 Prioritization and queuing of L2 resources has been updated.

Improvement to priority-based scheduling functionality (3.21)3.21 Improvement to priority-based scheduling functionality has been updated.

New consistency check for parameters related to SRNC anchoring (3.28)3.28 New consistency check for parameters related to SRNC anchoring has been added.

Changes between issues 01A (2011-11-15, RU30) and 01B (2011-12-13, RU30)Changes visible in pilot/networks (2)2.4 HSDPA serving cell change counter correction has been moved to Changes visible in pilot/networks.

Subsections RU30 version where the change will be introduced and NE SW version in 2.3 Failure counter M1002C556 REJ_DCH_DUE_POWER_BGR_DL not updated correctly have been updated.

Internal improvement to downlink code change interface (3.6)New information has been added to Impacted counters/KPIs and Expected impact subsections.

DN09100723 7


Summary of changes


HSDPA serving cell change timing improvement (3.19)Subsection NE SW version has been updated.

Measurement result update for optimizing handover control decisions in case of fast moving UE (3.24)Subsections RU30 release where the change will be introduced and NE SW version have been updated.

Initial DL power calculation when blind IFHO is used (3.25)3.25 Initial DL power calculation when blind IFHO is used has been added.

HSDPA Measurement Power Offset calculation corrected (3.26)3.26 HSDPA Measurement Power Offset calculation corrected has been added.

Multi-Band Load Balancing load weight calculation change (3.27)3.27 Multi-Band Load Balancing load weight calculation change has been added.

8 DN09100723



Summary of changes

DN09100723 9


Introduction to RU30 algorithm changes and impact oncounters and KPIs

Id:0900d805808c0935Confidential

1 Introduction to RU30 algorithm changes and impact on counters and KPIsThe basic idea of the document is to list down and shortly explain the generic changes of RU30 release. The generic change means that a new or modified functionality is acti-vated by default when the release upgrade is done from RU20 latest MP delivery to RU30.

Note that even though the impact on KPIs is given, no numeric value can be provided. Impact on counters and KPIs is network-specific and can vary even within a network because of traffic and dimensioning. For example, improvements of overload situations are visible only in KPIs calculated for overloaded cells during the overload times.

10 DN09100723


Id:0900d8058091c1e8Confidential

Changes visible in pilot/networks

2 Changes visible in pilot/networks

2.1 Increase of M1001C15 RRC_CONN_ACT_FAIL_IURU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsNone

Short descriptionIn RU20, some RRC drops were counted as normal releases as they could not be dis-tinguished from IMSI Detach case.

In RU30 Main Release, this was corrected and the drops are now counted as abnormal RRC releases because of IU.

Details: In RU20, when RNC received SCCP connection refusal from CN, it never pegged drop counter for it. RNC was not able to differentiate IMSI detach case when CN could send the refusal directly from the case when there is a problem in the Iu link causing the refusal from SCCP. In RU30, it has been changed, so that RNC checks if there was IMSI detach initiated. Then, if SCCP connection refusal is received, RNC is pegged as normal (as in all the earlier releases). If no IMSI detach was initiated and SCCP connection refusal is still received, then RNC pegs drop because of Iu.

Expected impactImpact found in pilot:

• no end-user impact • RNC_339b RRC active failures rate due to IU slight increase of approximately

0.01% • RNC_217f RRC success rate: decrease of less than 0,01%

Reasoning why the change was madePM counter improvement

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic.

NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsM1001C15 RRC_CONN_ACT_FAIL_IU

Reference information-

Other-

DN09100723 11




2.2 Failure counter not updated when radio link restore indi-cation not received from BTSRU30 release where the change will be introducedRU30 Main Release


Short descriptionIn RU20, when state transition to Cell_DCH state with HS-DSCH/E-DCH configuration failed because no synchronization indication (Radio Link Restore Indication) was received from the BTS, radio link failure counter M1002 was not updated. It has been corrected in RU30 Main Release, where radio link failure counters are updated.

Expected impactRadio link failures seen in counters M1002 increase if state transition to Cell_DCH state fails because of synchronization failure between BTS and UE. Even though this change increases the number of M1002 failure counters, there is no real performance degrada-tion.

Reasoning why the change was madeRadio link failure counters M1002 have to be updated in this case. Failing state transition with missing Radio Link Restore Indication message corresponds to the failing synchro-nization.


NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsThe following counters are increased:M1002C479 HS-DSCH RELEASE DUE TO RL FAILURE FOR INTERACTIVEM1002C482 HS-DSCH RELEASE DUE TO RL FAILURE FOR BACKGROUNDM1002C539 E-DCH RELEASE DUE TO RL FAILURE FOR INTERACTIVEM1002C540 E-DCH RELEASE DUE TO RL FAILURE FOR BACKGROUNDM1002C594 HS-DSCH RELEASE DUE TO RL FAILURE FOR STREAMINGM1002C611 E-DCH RELEASE DUE TO RL FAILURE FOR STREAMINGM1002C645 HS-DSCH RELEASE DUE TO RL FAILURE FOR AMRM1002C648 E-DCH RELEASE DUE TO RL FAILURE FOR AMR


Other-

12 DN09100723




2.3 Failure counter M1002C556 REJ_DCH_DUE_POWER_BGR_DL not updated correctlyRU30 release where the change will be introducedRU30 EP1

Relation to features or correctionsRelated to the fault corrections:

• M1002C556 not updated in CTS AC rejection case • High AFR linked to Quality of Service implementation

Short descriptionIn RU20 M1002C556 REJ_DCH_DUE_POWER_BGR_DL counter was not updated in case of rejected HSPA/HSDPA to DCH channel type switch because of DL power. Cor-responding counter for interactive traffic class was updated correctly. Thus, NRT DCH setup rejects because of DL power were showing wrongly too low values.

Expected impactWhen compared to RU 20, NRT DCH setup rejects increase SW because M1002C556 REJ_DCH_DUE_POWER_BGR_DL counter starts showing also rejected HSPA/HSDPA to DCH channel type switch events because of DL power.

Reasoning why the change was madeSW operated incorrectly.


NE SW versionRN6.0 1.2

UE dependencyNone

Impacted counters/KPIsThe following counter is increased: M1002C556 REJ_DCH_DUE_POWER_BGR_DL

Reference informationM1002C556 not updated in CTS AC rejection caseHigh AFR linked to Quality of Service implementation

Other-

2.4 HSDPA serving cell change counter correctionRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsCorrection to: handover control updates counter M1008C221 during state transition. HSDPA serving cell change, FACH state transition.

DN09100723 13




Short descriptionDescription of the fault: Handover control updated failure counter M1008C221 SCC_FAILED_DUE_TO_OTHER if throughput based optimization triggered state tran-sition to Cell_FACH immediately after the handover control had initiated serving cell change procedure.

Description of the correction: Counter updating logic in the handover control is corrected so that serving cell change counters are not updated if the procedure is interrupted by state transition to Cell_FACH.

Expected impactHSDPA serving cell change success ratio improves.

Reasoning why the change was madeSummary of the original problem: Handover control updates M1008C221 counter if it receives release indication because of PS throughput optimization while it is waiting for acknowledgement for HSDPA serving cell change request.

HSDPA serving cell change success ratio degrades, though it is not visible to end user.


NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsRNC_733 HSDPA Serving Cell Change Success Rate


Other-

14 DN09100723


Id:0900d80580918307Confidential

Algorithm changes

3 Algorithm changes

3.1 Use of maximum HSDPA user amounts returned by BTSRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRelated to the RAN2124: HSPA 128 users per cell feature.

Short descriptionRNC counts HSDPA user and HS-DSCH MAC-d flow amounts and limits those in RU30 also according to maximum values given by the BTS. BTS gives those limits for each cell and for each HSDPA scheduler.

Private NBAP is used in getting maximum user amount information to RNC (see inter-face specifications).

Expected impactSeveral KPI improvements are expected as there is bound to be less signaling in con-gestion situations.

Reasoning why the change was madeThere has been a request to improve the handling of BTS HSDPA congestion, so that amount of signaling in those cases would decrease.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic depending on BTS SW release. If BTS returns HSDPA capaci-ties, then RNC uses those.

NE SW versionRN6.0

Functionality requires that BTS supports new information elements, planned for RU40.

UE dependencyNone

Impacted counters/KPIsNone


OtherNot verified because of missing BTS functionality.

DN09100723 15


Id:0900d805808c0a2fConfidential

3.2 Pre-emption functionalitiesRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRelated to the RAN2123: Flexi BTS Gigabit Baseband feature.

Short descriptionPre-emption, RT-over-RT, RT-over-NRT, and NRT-over-NRT functionalities in case of BTS congestion are changed.

In RU30 Main Release, the HW resource division of BTS is taken into account in RNC when targets for pre-emption, RT-over-RT, RT-over-NRT and NRT-over-NRT actions are selected. RNC algorithms now follow BTS HW pooling, if BTS signals corresponding information elements.

The change is not visible in external interfaces, but private NBAP is used in getting BTS HW information to RNC.

Expected impactKPI impact may be seen in CE congestion/consumption.

Reasoning why the change was madeTarget selection for pre-emption actions was improved so that there are no wrong pre-emption actions causing delay and extra signaling.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic depending on BTS SW release. If BTS returns the new informa-tion, then RNC uses it.

NE SW versionRN6.0

Functionality requires that BTS supports new information elements.

UE dependencyNone



Other-

16 DN09100723


Id:0900d8058091c1ecConfidential

3.3 Power control of HSUPA DL control channelRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRelated to the following features:RAN1004: Streaming QoS for HSPARAN1689: CS Voice Over HSPA

Short descriptionPower control of HSUPA DL control channel has an impact on admission control of HSDPA RT services.

In HSDPA RT admission control it is taken into account whether the power control of HSUPA DL control channel is in use or not.

The change is not visible in external interfaces, but the use of power control in BTS is interpreted by RNC from BTS capabilities received by means of NBAP.

Expected impactPositive KPI impact can be expected as it is easier to establish HSDPA RT service when power control is in use.

Reasoning why the change was madeFault in AC decision for HSDPA RT services.

Type of change: generic in the SW, license-based or activated by PRFILEThis change is generic and is used if BTS indicates capability for 16QAM HSUPA (Sixteen QAM UL Capability) or to DC-HSDPA+MIMO (Multi Cell and MIMO Capability) feature.

NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsM1002C653 ALLO_HS_DSCH_12_2_AMRM1002C659 ALLO_SUCCESS_EDCH_AMR_12_2and other counters for CS Voice over HSPA


Other-

DN09100723 17


Id:0900d805808c0a31Confidential

3.4 Admission control of HSDPA RT servicesRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRelated to the following features:RAN1004: Streaming QoS for HSPARAN1689: CS Voice Over HSPA

Short description2 ms E-DCH TTI users are taken into account in HSDPA RT admission control.

The change is not visible in external interfaces.

Expected impactKPI impact can be expected.

Reasoning why the change was madeFault in AC decision for HSDPA RT services

Type of change: generic in the SW, license-based or activated by PRFILEThis change is generic.

NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsM1002C653 ALLO_HS_DSCH_12_2_AMRM1002C659 ALLO_SUCCESS_EDCH_AMR_12_2and other counters for CS Voice over HSPA


Other-

18 DN09100723


Id:0900d805808f2d19Confidential

3.5 DL spreading code handlingRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRAN1686: HSPA 72 Users Per Cell

Short descriptionDL spreading code allocation and releasing in RNC for E-RGCH and E-HICH channels is changed. In RU30 Main Release, it is to be done depending on needs. It is not done periodically anymore.

Codes used for E-RGCH and E-HICH channels can be target for code tree optimization procedure.


Expected impactPerformance impact on KPIs expected as the change should decrease code and signa-ture congestion.

Reasoning why the change was madeThe handling of codes used for E-RGCH and E-HICH channels was improved.


NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsRNC_605b HSDPA AccessibilityRNC_913b HSUPA Resource Accessibility


Other-

DN09100723 19


Id:0900d805808eece3Confidential

3.6 Internal improvement to downlink code change interfaceRU30 release where the change will be introducedRU30 Main Release


Short descriptionInternal modification to downlink code change interface is made. Interface is used in a code tree optimization functionality.

Currently, code tree optimization is performed in one phase so that once a new code is reserved, it is kept reserved as long as a code change procedure is rejected or success-fully done (reservation continues).

In the modified procedure in RU30 Main Release, code tree optimization is performed in two phases. It is checked first that the new code is free, but the reservation is made only when the code change procedure is started.

Expected impactThis change decreases probability of code tree congestion and internal procedure colli-sions (failures). Thus, it may improve KPIs slightly.

Reasoning why the change was madeDouble reservation avoided


NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsThe following counters may be impacted. The probability that these are affected is low.

RNC_605b HSDPA AccessibilityM1001C3 RRC SETUP FAIL DUE TO AC M1001C80 RAB SETUP FAILURES DUE TO AC FOR CS VOICE M1001C85 RAB SETUP FAILURES DUE TO AC FOR CS DATA CONV M1001C90 RAB SETUP FAILURES DUE TO AC FOR CS DATA STREAM M1001C100 RAB SETUP FAILURES DUE TO AC FOR PS DATA STREAM M1022C9 PACKET CALL SETUP FAIL DUE TO AC FOR INTERACTIVE M1022C10 PACKET CALL SETUP FAIL DUE TO AC FOR BACKGROUND M1022C184 PACKET CALL SETUP FAIL DUE TO AC FOR STREAMINGM1000C76 NO CODES AVAILABLE SF4M1000C77 NO CODES AVAILABLE SF8M1000C78 NO CODES AVAILABLE SF16M1000C79 NO CODES AVAILABLE SF32M1000C80 NO CODES AVAILABLE SF64M1000C81 NO CODES AVAILABLE SF128M1000C82 NO CODES AVAILABLE SF256

Reference information

20 DN09100723


Id:0900d805808eece3Confidential

-

Other-

DN09100723 21


Id:0900d805808c0a9bConfidential

3.7 Preventive overload control triggered by UL loaded stateRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRelated to the RAN1644: Continuous Packet Connectivity feature.

Short descriptionPreventive overload control actions (that is, release of users on extended inactivity timers) are triggered also when UL is found to be loaded (earlier downlink only). This functionality is used also with the RAN1686: HSPA 72 Users Per Cell feature.

The functionality is controlled with the following RNP parameters:

• RNC-ULLoadStateTTT • WCEL-ULLoadStateHSUOffset • WCEL-ULLoadStateHSUBRLimit



Reasoning why the change was madeThere has been a request to enable the preventive overload actions in all possible HSDPA and HSUPA congestion cases.

Type of change: generic in the SW, license-based or activated by PRFILEThis change is generic.

NE SW versionRN6.0


UE dependencyNone

Impacted counters/KPIsRNC_605b HSDPA AccessibilityRNC_913b HSUPA Resource Accessibility


Other-

22 DN09100723


Id:0900d805808c0abaConfidential

3.8 Branch replacement correctionRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsCorrection to: handover control incorrectly attempts branch replacement if UE has three intra BTS branches in active set. Intra-BTS SHO replacement.

Short descriptionBranch replacement fails because 4th radio link under the same BTS is not supported.

Description of the fault: If reported event 1a is converted to e1c (because of full active set) handover control did not check if the replacement was allowed. If the new cell is 4th RL for the same BTS as other active set cells, replacement cannot be made.

Description of the correction: If intra-BTS replacement is attempted in situation, where all cells are already under the same BTS, handover control must reject the replacement and instead remove the worst active set cell. Thus, if e1a is converted to e1c, conditions for the branch replacement must be evaluated before actual SHO request.

Expected impactBetter SHO KPI

Reasoning why the change was madeSHO KPI success rate is affected because of failed branch replacement attempts. In the worst case scenario, if a new cell to be added is very good and other active set cells are very bad and event 1b is not received for bad cells, the call might drop.


NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsRNC_153 Soft Handover Success rate RTRNC_191 Soft Handover Success rate NRT


Other-

DN09100723 23


Id:0900d805808fca5eConfidential

3.9 800K RRC connected UEsRU30 release where the change will be introducedRU30 EP1

Relation to features or correctionsRelated to the RAN2379: 800K RRC Connected UEs in RNC feature.

Short descriptionRAN2379: 800K RRC Connected UEs in RNC has a few generic changes that are appli-cable to all products without control by feature parameter/license:

1. RNC allocates uplink scrambling code to only Cell DCH users in RNC, to enable support for 800K UEs. Uplink scrambling code allocated to UE remains valid in cell DCH state. Uplink scrambling code is released on state change to FACH/PCH states, and a new uplink scrambling code is allocated to UE on state transition back to Cell DCH state. Currently, fixed value of Uplink scrambling code remains valid till lifetime of RRC connection.

2. RNC supports ICSU unit load balancing because of CPU load during URA/Cell update. If URA/Cell update is performed because of URA/Cell reselection / periodi-cal URA/Cell update cause and ICSU unit that handles RRC connection CPU load level is 'High' and some other ICSU unit CPU load is “Medium” or “Low” level, RNC initiates ICSU unit CPU load balancing. RNC initiates RANAP:IU RELEASE REQUEST for Iu-PS with Miscellaneous Cause: Network Optimisation. RRC con-nection is released for the UE on receiving RANAP: IU RELEASE COMMAND from SGSN. After that, once a new RRC connection is setup, less loaded ICSU unit is selected.

3. RNC supports ICSU unit load balancing because of high number of RRC connec-tions in ICSU during URA/Cell update. If URA/Cell update is performed because of URA/Cell reselection / periodical URA/Cell update cause and number of RRC con-nections in ICSU is 'High' and if number of RRC connections in some other ICSU unit is “Medium” or “Low” level, then RNC initiates ICSU unit load balancing. RNC initiates RANAP:IU RELEASE REQUEST for Iu-PS with Miscellaneous Cause: Network Optimisation. RRC connection is released for the UE on receiving RANAP: IU RELEASE COMMAND from SGSN. After that, when a new RRC connection is setup, less loaded ICSU unit is selected.

Expected impactImprovement of several KPIs because of prevention of CPU overload

Reasoning why the change was made

1. The change is required to support 800K UEs.2. Higher number of supported UEs require RNC internal load balancing.3. Higher number of supported UEs require RNC internal load balancing.

Type of change: generic in the SW, license-based or activated by PRFILEThe changes are generic.


UE dependencyNone

24 DN09100723





Other-

DN09100723 25


Id:0900d805808f0e80Confidential

3.10 RNC supports three DC-HSDPA layersRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRAN1907: DC-HSDPA with MIMO 84 MbpsRAN1906: DC-HSDPA 42 Mbps

Short descriptionThis change is valid only if more than two DC-HSDPA layers can be configured in the same sector.

Tcell value defines the group of cells, from which the cell pair is formed by the RNC. The same Tcell value must be set to all DC-HSDPA-capable cells, from which the cell pair is formed. The same Tcell value is allowed in three DC-HSDPA cells in the same sector provided that they have adjacent frequencies within the same frequency band. It is also possible to define two distinct DC-HSDPA cell pairs in the sector. In this case, the first two cells forming the first pair must have the same Tcell value and the other two cells forming the second pair must have another Tcell value that differs from the Tcell value of the first pair.

Expected impactNo KPI effect. This change provides operators with more options to deploy DC-HSDPA, but it is not directly visible in KPI performance.

Reasoning why the change was madeRNC was extended to support more than two DC-HSDPA layers in the same sector.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is valid in SW only if operator can configure more than two DC-HSDPA layers in the same sector. Change is controlled by the RAN1906: DC-HSDPA 42 Mbps feature on/off switch and license.

NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIs-


Other-

26 DN09100723


Id:0900d805808f0e8cConfidential

3.11 RNC chooses the secondary cellRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRAN1907: DC-HSDPA with MIMO 84 Mbps

Short descriptionThis functionality is valid only if there is more than one possible secondary cell candi-date. It means that there are three DC-HSDPA layers configured in the same sector.

The secondary serving cell selection is executed always when the first HS-DSCH MAC-d flow is setup for the UE in Cell_DCH state including HHO and in case of SCC. If DC-HSDPA must be configured off in Cell_DCH state, for example, because of non-sup-ported RAB combinations, the secondary cell is not reselected, but the original second-ary cell can be used if DC-HSDPA is configured in use again in the same primary serving cell.

Figure 1 DC-HSDPA with two possible secondary cell candidates

The secondary cell selection in case of DC-HSDPA follows the preference order below:

1. 64QAM-capable secondary cell is chosen if 64QAM can be configured in use for the UE in the primary cell.

2. RNC chooses the secondary cell, where the absolute number of existing HS-DSCH MAC-d flows is lower. If the absolute number of existing HS-DSCH MAC-d flows is the same, candidates are considered equal and secondary cell can be chosen freely.

Expected impactNo KPI effect. This change provides operators with more options to deploy DC-HSDPA, but it is not directly visible in KPI performance.

Reasoning why the change was madeRNC was extended to support more than two DC-HSDPA layers in the same sector.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is valid in SW only if operator can configure more than two DC-HSDPA layers in the same sector. Change is controlled by the RAN1906: DC-HSDPA 42 Mbps feature on/off switch and license.

NE SW versionRN6.0

UE dependency

DN09100723 27


Id:0900d805808f0e8cConfidential

None



Other-

28 DN09100723



3.12 3GPP Rel-9 “Total RLC AM buffer size” supportedRU30 release where the change will be introducedRU30 Main Release


Short descriptionThis change is valid for every 3GPP Rel-9 HSDPA UE.

New values for the "Total RLC AM buffer size" for REL-9 UE (1150, 1250 kB) shall be supported irrespective of the DC-HSDPA or MIMO usage (TS 25.331 10.3.3.34 RLC Capability).

Expected impactNo KPI effect. RNC uses new 3GPP Rel-9 UE capabilities when received without KPI effect.

Reasoning why the change was madeRNC supports 3GPP Rel-9.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is valid in SW always when UE sends new 3GPP Rel-9 capability. It is not controlled by specific on/off switch or license.

NE SW versionRN6.0

UE dependency3GPP Rel-9 UE

Impacted counters/KPIsNo impact expected as the relative number of Rel-9 UEs is expected to be very low.


Other-

DN09100723 29



3.13 RNC calculates HS-DSCH MAC-d flow peak rateRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRAN1907: DC-HSDPA with MIMO 84 MbpsRAN1906: DC-HSDPA 42 Mbps

Short descriptionThis change is valid only if DC-HSDPA is used.

RNC L3 provides RNC L2 with the HS-DSCH MAC-d flow peak rate. Calculated peak rate is used by RNC L2 for internal resource reservation. It is not visible externally.

Peak rate is calculated separately for DC-HSDPA with and without 64QAM. In earlier releases, peak rate was calculated only for DC-HSDPA with 64QAM.

The highest possible value for the HS-DSCH MAC-d flow peak rate is as follows in case of DC-HSDPA 42 Mbps:

• 27752 kbps if DC-HSDPA is configured in use without 64QAM • 41928 kbps if DC-HSDPA and 64QAM are configured in use

Expected impactNo KPI effect. This change related to RNC internal implementation. Change in L2 resource reservation is not visible in KPI performance.

Reasoning why the change was madeRNC internal implementation was aligned with DC-HSDPA without 64QAM cases.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is valid in SW only if DC-HSDPA is used. The change is controlled by the RAN1906: DC-HSDPA 42 Mbps feature on/off switch and license.

NE SW versionRN6.0

UE dependencyNone



Other-

30 DN09100723


Id:0900d8058091c1eeConfidential

3.14 Definition of MAC-hs window size changed internally in RNCRU30 release where the change will be introducedRU30 Main Release


Short descriptionRNC defines the MAC-hs window size (NBAP) and MAC-hs window size/ MAC-ehs window size (RRC) for the priority queue each time HS-DSCH MAC-d flow is setup. RNC internal parameter MAChstxwindowsize defines the MAC-hs window size for each HS-DSCH category for the transmitting side. Correspondingly, RNC internal parameter parameter MAChsrxwindowsize defines the MAC-hs/MAC-ehs window size for the receiving side.

RNC internal parameters are modified so that they define the value of the MAC-hs/ehs window size to be signaled to the UE/BTS according to the service and HS-DSCH physical layer category. This is a generic change for all HSDPA configurations.

Expected impactNo KPI effect because only RNC internal implementation changes. MAC-hs/ehs window size signaled to BTS and UE remains unchanged.

Reasoning why the change was madeObtaining MAC-hs/ehs window size was made more rational inside of RNC.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is valid in SW always when HSDPA is used. It is not controlled by specific on/off switch or license.

NE SW versionRN6.0

UE dependencyNone



Other-

DN09100723 31


Id:0900d805808f0ebcConfidential

3.15 Special value of the MaxBitRateNTRTMACDFlow parameter changedRU30 release where the change will be introducedRU30 Main Release


Short descriptionThis change is valid always if HSDPA is used in the RNC.

Old special value (65535) of the MaxBitRateNRTMACDFlow parameter is replaced with the new special value (0). Meaning of the special value remains the same, that is HS-DSCH MAC-d flow peak rate is not limited. The change is made to support HS-DSCH peak rates up to 84 Mbps. The value 0 is also the new default value. Operation and maintenance (O&M) converts the default and special value in release upgrade accord-ingly.

Expected impactNo KPI effect. Changed interpretation of the special value does not affect KPI perfor-mance.

Reasoning why the change was madeThis change makes it possible to extend range of the MaxBitRateNRTMACDFlow parameter up to 84 Mbps.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is valid in SW always when HSDPA is used in the RNC. It is not controlled by specific on/off switch or license.

NE SW versionRN6.0

UE dependencyNone



Other-

32 DN09100723


Id:0900d805808c0b1fConfidential

3.16 E-DPDCH power interpolationRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsRelated to the RAN1645: HSUPA 16QAM feature

Short descriptionThe E-DPDCH power interpolation is used in specified HSUPA 2 ms and 10 ms data rates, when the criteria for E-DPDCH power interpolation usage are fulfilled. The E-DPDCH power interpolation usage with specified HSUPA 2 ms and 10 ms data rates is generic functionality. Note that for HSUPA 16 QAM, the E-DPDCH power interpolation method is always used.

Expected impactHigh KPI impact can be expected.

Reasoning why the change was madeHSUPA power interpolation provides high gain because it is possible to define gain factors so that they are optimal for low and high bit rates simultaneously.


NE SW versionRN6.0


UE dependencyUE indicates if it supports HSUPA power interpolation (Rel-7).



Other-

DN09100723 33



3.17 Prioritization and queuing of L2 resourcesRU30 release where the change will be introducedRU30 EP2


Short descriptionRNC UP resources (for example, RLC, MAC, FP) are reserved based on service priority. If there are UP congestion, then UP resources for higher priority services are allocated first.

Prioritization is defined in ICSU unit and is made always when L2 resources are allo-cated, for example in RRC connection setup and in RAB setup phases.

Expected impactDuring UP congestion situation, KPIs of high priority services may get better and KPIs of low priority services may worsen.

Reasoning why the change was madeIt is more important to serve high priority services in congestion situation.



UE dependencyNone

Impacted counters/KPIsThe following KPIs (some of them) are impacted in UP congestion situations:

• RNC_20b RRC Connection setup Success Ratio • RNC_30a RAB Setup and Access Complete Ratio for Voice • RNC_157a RAB Setup and Access Complete Ratio for NRT Service • RNC_605b HSDPA Resource Accessibility for NRT Traffic • RNC_913a HSUPA Resource Accessibility for NRT Traffic • RNC_916b Packet Session Setup Success Ratio (SSSR)


Other-

34 DN09100723


Id:0900d805808c0b22Confidential

3.18 Direct state transitions from Cell_DCH to Cell_PCHRU30 release where the change will be introducedRU30 Main Release


Short descriptionDirect transition from Cell_DCH to Cell_PCH is by default enabled in RU30 Main Release. In RU20, it was disabled by default because of some problematic UE models. RU30 RNC is able to recognize problematic UEs and therefore it is able to use direct state transitions safety with UEs that work properly. It is recommended to keep direct state transitions enabled with RU30 Main Release.

Expected impactNo impacts expected.

Reasoning why the change was madeTypically, Cell_FACH state is used only for a few seconds without any activity. Direct state transition saves UE battery.

Type of change: generic in the SW, license-based or activated by PRFILEDirect state transitions can be disabled with PRFILE 7,307.

NE SW versionRN6.0


UE dependencyNo UE dependencies. Problematic UEs can be identified.

Impacted counters/KPIsState transition counter: M1006C114 Cell_DCH State to Cell_PCH


OtherThe direct state transitions have not caused any problems in piloting phase.

DN09100723 35


Id:0900d805808f0cb0Confidential

3.19 HSDPA serving cell change timing improvementRU30 release where the change will be introducedRU30 EP1


Short descriptionCFN activated HSDPA serving cell change is implemented instead of timer-based acti-vation. More accurate CFN is obtained from BTS synchronization and used to activate the new configuration during SCC.

Expected impactPotential impact to HSPA success rate and drop rate

Reasoning why the change was madeTiming accuracy of HSDPA serving cell change is optimized in RNC with the help of BTS synchronization procedure for PS HSDPA service.



UE dependencyRel-5

Impacted counters/KPIsRNC_733a HSDPA Serving Cell Change Success Rate


Other-

36 DN09100723


Id:0900d805808f0e2aConfidential

3.20 Prioritization of urgent procedures in RNCRU30 release where the change will be introducedRU30 EP1

Relation to features or correctionsFault correction: UER cannot cancel NRT UP creationFault correction: RU20: Q5 30.6-0A UER did not respond to ccm_control_s (suspend)

Short descriptionProblem: Currently, during the RNC procedures that contain re-attempt(s) using repeated message sequences, RNC is not able to handle more urgent procedures, such as soft handover branch additions, replacements or deletions. That may cause a release or a drop of connection. In case of resource congestion, the NRT user-plane setup and upgrade procedures consist of several re-attempts. Separate channel types and bit rates in allocation procedure, separate serving cell candidates in allocation procedure, DCH upgrades with several re-attempts and Priority-Based Scheduling procedures can cause delay in more urgent procedures.

Solution: The RNC implementation is now improved so that it can cancel ongoing lower priority procedures if more urgent ones need to be performed immediately.

Expected impactAfter optimization, RNC is able to process more urgent procedures, such as soft/softer handover branch addition, more rapidly. The number of coincidental connection releases and drops are assumed to decrease.

Reasoning why the change was madeThis will have some positive effect on KPIs. The effect is visible when there is any kind of resource congestion.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic in the SW.


UE dependencyNone

Impacted counters/KPIsThe change will improve Soft Handover Success Rate. An improvement in Retainability KPIs may also be visible.

The following counters will show improved results:M1007C15 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFICM1007C32 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR NRT TRAFFIC


Other-

DN09100723 37



3.21 Improvement to priority-based scheduling functionalityRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsInefficient pre-emption and PBS functionality RN4.0 CD1.35 and exists in all SW up to RN4.0 CD2.1.

Short descriptionThis improvement is behind PRFILE parameter in RU20 and generic in RU30 Main Release.

Currently, priority-based scheduling procedure in BTS, Iub transport, downlink spread-ing code, uplink interference and downlink power congestion in initial bit rate allocation can drop several users who have lower bit rate than initial one either to Cell_FACH state or to DCH/DCH 0/0.

As an example, when using initial bit rate of 64 kbps and minimum bit rate of 16 kbps, the incoming NRT RB with initial bit rate allocation 64 kbps may lead to release of up to four NRT RBs with minimum bit rate 16 kbps in case of BTS, transport, downlink spread-ing code, uplink interference and downlink power congestion. Then, the same users are moved to CELL_FACH state or to DCH/DCH 0/0 trying to have DCH resources. This leads to the release of other 16 kbps users.

The improvement is such that in case of congestion due to BTS, transport (Iub and Iur) or RNC HW congestion (U-plane), RNC retries the setup with the lower bit rates. The re-tries are performed down to the configured minimum bit rate of the cell instead of the current initial bit rate. In case of congestion, because of downlink spreading code, uplink interference and downlink power, RNC functionality is similar, but it does not include the re-tries, as now resource situation is known by the allocating SW process. If the minimum bit rates still face the BTS or Iub Transport, downlink spreading code, uplink interference, and downlink power congestion, then priority-based scheduling procedure is triggered. NRT DCH handling will be valid for both Rel99 (DCH/DCH) and HSDPA (DCH/HSDPA) users.

Prioritization of NRT candidates is performed in the following sequence:

1. NRT DCH users having higher bit rate than initial bit rate in QoS priority order2. NRT DCH users having higher bit rate than minimum bit rate in QoS priority order3. minimum bit rate users in Qos priority order

Currently, prioritization of NRT candidates is done so that QoS has the highest priority.

Expected impactIn the new functionality, only one user is released in priority-based scheduling procedure because the incoming user requests the minimum bit rate and all possible candidates in the procedure have at least the minimum bit rate. This means the transmission of less users is interrupted.

Reasoning why the change was madeThere have been several operator requests not to enable release of several users in priority-based scheduling functionality. This became evident during RU20 traffic increase and was changed immediately.

Type of change: generic in the SW, license-based or activated by PRFILE

38 DN09100723



RU20: New functionality can be enabled by the PRFILE (007:0298 RN40_MAINT_028). By default, the new functionality is disabled. By setting the bit1 of the parameter to value 1, minimum bit rate allocation in BTS and TRS congestion through PBS is enabled. By setting the bit2 of the parameter to value 1, minimum bit rate allocation in downlink spreading code, uplink interference, and downlink power congestion through PBS is enabled.

RU30 Main Release: new functionality is always on, no PRFILE checking is done.

NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsWith the new functionality, Packet Service Setup Success Ratio is improved. More NRT connections will keep their DCH >0 allocation. Thus, also fewer state transitions from CELL_DCH to CELL_FACH or CELL_PCH RRC states are performed.

The following counters will show improved results:M1022C99 INITIAL DCH ALLOCATION SUCCESS FOR NRT BITRATE 64 KBPS AND LOWER ULM1022C100 INITIAL DCH ALLOCATION SUCCESS FOR NRT BITRATE 64 KBPS AND LOWER DLM1000C157 RB RELEASE BY PBS DUE TO AAL2 CONGESTION M1000C158 RB RELEASE BY PBS DUE TO BTS CONGESTIONM1000C159 RB RELEASE BY PBS DUE TO INTERFERENCE CONGESTIONM1000C160 RB RELEASE BY PSB DUE TO SPREADING CODE CONGESTION


Other-

DN09100723 39


Id:0900d805808f0ecaConfidential

3.22 Intra-BTS soft handover between LCGsRU30 release where the change will be introducedRU30 EP2

Relation to features or correctionsRAN2394: Extended BTS site capacity

Short descriptionRNC needs to support Intra-BTS soft handover between cells which belong to different Local Cell Groups (LCGs) to support sector group specific Local Cell Groups of BTS.

Sector-group-specific Local Cell Groups means that a defined group of sectors is com-missioned to one LCG and that LCG is processed inside one system module. That-means that one frequency can be processed in several system modules. In case of frequency-layer-based Local Cell Groups, all cells in the same frequency are commis-sioned to one LCG and thus processed in one and the same system module. Each system module is a separate BTS from the BB resource management point of view. It means that only BB resources of the system module, where the LCG is allocated, can be used for that particular sector group (or frequency layer).

In Figure 2 Sector-group-specific LCGs with two system modules, LCG 1 (sector group 1) is handled in system module 1 and LCG 2 (sector group 2) in system module 2. Soft handover is performed between the LCGs.

Figure 2 Sector-group-specific LCGs with two system modules contains an example of a six-sector BTS with 24 cells on four carrier frequencies commissioned to sector-group-specific LCGs. LCG 1 (sector group 1) is handled in system module 1 and LCG 2 (sector group 2) in system module 2. Soft handover is performed between the LCGs.

40 DN09100723



Figure 2 Sector-group-specific LCGs with two system modules

The RNC receives the LCR ID - LCG ID mapping information from the BTS for every local cell resource (LCR) in Audit Response and Resource Status Indication messages. The RNC uses this information when deciding intra-BTS handover type, that is it performs Soft HO (RL setup) when the handover takes place between cells which have different LCG ID and Softer HO (RL addition) when handover takes place between cells which have the same LCG ID.

The RNC effects of the new intra-BTS handover type are described in the following WCDMA RAN and I-HSPA, Rel. RU30, Issue 04 onwards operating documentation:

• WCDMA RAN and I-HSPA Handover Control (DN03471612)

– chapter 1 Handover control– chapter 9.3 The DL power control request– chapter 10.1.3 Reporting event 1C for replacing cells in the active set– chapter 10.1.8 Softer handover between cells within one base station– chapter 10.1.9 Soft handover between Local Cell Groups or base stations within one

RNC– chapter 10.1.10 Inter-RNC soft and softer handover

• WCDMA RAN and I-HSPA RRM HSDPA (DN0638161)

– chapter 10.1 HSDPA mobility handling with the Serving HS-DSCH Cell Change– chapter 10.2 HSPA over Iur – chapter 10.2.1 Soft Handover Over Iur– chapter 10.3.1 Serving cell selection

• WCDMA RAN and I-HSPA RRM HSUPA (DN70303923)

DN09100723 41



– chapter 1.2.2 HSUPA handovers– chapter 15.1 Soft handovers– chapter 15.1.1 E-DCH active set– chapter 15.1.5 Soft handover over Iur– chapter 15.3.3 Channel type switch from E-DCH to DCH

• WCDMA RAN and I-HSPA RRM Admission Control (DN0423863)

– chapter 13.7 Congestion of BTS resources– chapter 13.8 Congestion of Iub transmission capacity– chapter 17.10.1 Cell Shutdown– chapter 20.2 HSDPA UL SIRerror measurement

Expected impactSector group specific LCGs decrease the number of softer handovers and increase the number of soft handovers. Because adding softer handover branch to the same LCG does not require more BTS resources and adding soft handover branch to another LCG requires more BTS resources, use of sector group specific LCGs may decrease Soft Handover Success Ratio (RAN_KPI_0020).

Reasoning why the change was madeThe RNC change was made to support sector-group-specific LCGs and larger BTS con-figurations.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic in the SW.


The functionality is available when sector-group-specific LCGs are configured in the BTS that supports the configuration.

UE dependencyNone

Impacted counters/KPIsM1007C15 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFICM1007C32 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR NRT TRAFFICM1007C10 CELL ADDITION REQUEST ON SHO FOR RT TRAFFICM1007C11 CELL DELETION REQUEST ON SHO FOR RT TRAFFICM1007C12 CELL REPLACEMENT REQUEST ON SHO FOR RT TRAFFICM1007C27 CELL ADDITION REQUEST ON SHO FOR NRT TRAFFICM1007C28 CELL DELETION REQUEST ON SHO FOR NRT TRAFFICM1007C29 CELL REPLACEMENT REQUEST ON SHO FOR NRT TRAFFIC

M1007C16 UNSUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFICM1007C33 UNSUCCESSFUL ACTIVE SET UPDATES ON SHO FOR NRT TRAFFIC

M1007C13 CELL ADDITION FAILURE ON SHO FOR RT TRAFFICM1007C14 CELL REPLACEMENT FAILURE ON SHO FOR RT TRAFFICM1007C30 CELL ADDITION FAILURE ON SHO FOR NRT TRAFFICM1007C31 CELL REPLACEMENT FAILURE ON SHO FOR NRT TRAFFIC

M1007C6 SOFTER HANDOVER DURATION ON THE SRNC SIDE FOR RT TRAFFICM1007C7 SOFTER HANDOVER DURATION ON THE DRNC SIDE FOR RT/NRT

42 DN09100723



TRAFFICM1007C25 SOFTER HANDOVER DURATION ON THE SRNC SIDE FOR NRT TRAFFICM1007C26 INTER-RNC SOFT HO DURATION ON THE SRNC SIDE FOR NRT TRAFFIC


Other-

DN09100723 43


Id:0900d8058091c1f4Confidential

3.23 Changes to SIB priority handlingRU30 release where the change will be introducedRU30 Main Release


Short descriptionSIB (System Information Broadcast) priority parameters are used as a weight to decide the precedence of SIBs at Uu interface. The SIBs with higher priority are sent more often than compared to the SIBs of lower priority. SIB4, SIB6, SIB12 are meant for connected mode UEs and contain similar information as sent in SIB3, SIB5 and SIB11 respectively and always delivered with the same priority as SIB3, SIB5 and SIB11 respectively. Therefore, there is no need for a separate priority value for SIB4/SIB6/SIB12.

SIB7 is delivered with the highest priority. Therefore there is no need to provide priority for it.

This change means the handling of parameters SIB4_priority, SIB6_Priority, SIB7_Prirority and SIB12_Priority becomes obsolete and is removed.

Note: these parameters are still visible in RU30 user interface. They will be removed in RU40.

Now the system also makes a sanity check that SIB11_Priority, SIB15_Priority, SIB18_Priority and SIB19_Priority are not higher than SIB1_Priority, SIB2_Priority, SIB3_Priority and SIB5_Priority and fixes the prioritization.

Expected impactFaster cell re-selection times if the parameters are set wrongly.

Reasoning why the change was madeIt was seen in the testing that the cell reselection time was depending on this parame-terization.


NE SW versionRN6.0

UE dependencyNone

Impacted counters/KPIsNone. There are no counters measuring the cell reselection times. The impact can be observed from UE only.


Other-

44 DN09100723


Id:0900d805808ef020Confidential

3.24 Measurement result update for optimizing handover control decisions in case of fast moving UERU30 release where the change will be introducedRU30 EP1

Relation to features or corrections -

Short descriptionFast moving call may drop unnecessarily due to non-optimal Handover Control (HC) decisions. This is because Handover Control does not always take all information from the latest measurement into account in HC decision if reports are received during an ongoing handover procedure. This can delay starting of a critical handover procedure, which in turn can cause a call drop.

As correction, handling of measurement reports received during an ongoing handover procedure is improved to reduce unnecessary delays:

1. During an ongoing handover procedure, if measurement event 1A/1C triggered cell is not included in the latest measurement report (cell weakens fast), the addi-tion/replacement for that cell is not started anymore after completion of an ongoing handover procedure.

2. During an ongoing handover procedure, if measurement event 1C is transformed by HC to event 1B (Event 1C triggered by a weak cell), the deletion is not done if it requires serving cell change (SCC) to be performed first. This allows the SCC to be done separately first, and then start the next ASU based on fresh measurement reports. Otherwise, transformation of event 1C to 1B follows the existing principles described in Handover Control FAD.

Expected impactCall drops decrease,especially in case of fast moving UE, because of more optimal handover decisions.

Reasoning why the change was madeSW operated incorrectly. The SW did not use all available information from the measure-ment report.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic to avoid maintaining two different HO decision paths.


UE dependencyNone

Impacted counters/KPIsSlight improvement on Call Drop Rate (CDR) and retainability in the areas having fast moving UEs

Reference informationHandover Control Functional Area Description

Other-

DN09100723 45


Id:0900d805808eee06Confidential

3.25 Initial DL power calculation when blind IFHO is usedRU30 release where the change will be introducedRU30 EP1

Relation to features or correctionsRAN2289: Blind IFHO in RAB setup phase and RAN2172: Multi-Band Load Balancing

increased HS-DSCH & E-DCH UE Setup Failures After Blind Handover Activation

Short descriptionRAN2289: Blind IFHO in RAB setup phase feature uses the CPICH RSCP measure-ment from the RACH reported by the UE for decision making in the blind inter-frequency handover. That feature introduces the possibility to change the RACH intra-frequency measurement quantity from CPICH EcN0 to CPICH RSCP. The CPICH EcN0 has been used when defining the DL initial power for the first radio link. When measured CPICH EcN0 is not available it might happen that calculated initial DL power is too small for UEs far away from base station antenna in HSDPA cell. Problems appear especially when blind FIHO is done to higher frequency band.

Now the DL initial power calculation is improved so that the CPICH RSCP which UE has reported is taken into account when defining the initial DL power. This enables to boost DL initial power for first radio link when UE is far away from BTS antenna. The change is generic but can be deactivated or the functionality can be modified via PRFILE param-eter (002:1765RN60_MAINT_48).

Expected impactImproved HS-DSCH & E-DCH setup success rate when blind IFHO is activated..

Reasoning why the change was madeIt was discovered that sometimes the initial DL power was insufficient in HSDPA cell for UEs far away from BTS antenna.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic when RAN2289: Blind IFHO in RAB setup phase feature is acti-vated (or only CPICH RSCP has been defined as RACH intra-frequency measurement quantity with RACHIntraFreqMesQuant parameter), but it can be deactivated or the functionality can be modified via PRFILE parameter (002:1765RN60_MAINT_48).


UE dependencyNone

Impacted counters/KPIsNumber of setup failures for HS-DSCH and E-DCH setups (SETUP_FAIL_UE_HS_DSCH_INT and SETUP_FAIL_EDCH_UE_INT) when the RAN2289: Blind IFHO in RAB setup phase feature is activated (or only CPICH RSCP has been defined as RACH intra-frequency measurement quantity with RACHIntra-FreqMesQuant parameter).

Reference informationDL initial power modification for situation when blind IFHO is activated.

Other

46 DN09100723


Id:0900d805808eee06Confidential

-

DN09100723 47


Id:0900d805808eef45Confidential

3.26 HSDPA Measurement Power Offset calculation correctedRU30 release where the change will be introducedRU30 EP1

Relation to features or correctionsFault correction: HSDPA measurement power offset is always 5 db

Short descriptionIn RU20 and earlier releases HSDPA Measurement Power Offset (MPO) was calculated incorrectly. RNC uses the maximum cell transmission power (Pmax) in calculation of MPO. In RU20 and earlier releases Pmax in dBm was rounded down to the closest integer. Incorrect rounding caused too low Pmax values for MPO calculation, which caused too low MPO values signalled to BTS and UE when HS-DSCH MAC-d flow was setup. In RU30 MPO calculation will be corrected.

For more information on HSDPA MPO calculation, see HSDPA RRM in RNC FAD.

Expected impactMPO, that RNC signals to BTS and UE, will be on the average slightly higher after cor-rection. Higher MPO will be seen as higher CQI values reported by the UE. There will be no impact on HSDPA performance because MPO is just a reference power for CQI reporting and BTS adjusts (compensates) reported CQI according to the real available HS-PDSCH transmission power.

Reasoning why the change was madeSW operated incorrectly.



UE dependencyRel-5 HSDPA UE

Impacted counters/KPIsReported CQI distribution counters (BTS):

M5000C8 / REPORTED CQI DISTRIBUTION - CLASS 0M5000C9 / REPORTED CQI DISTRIBUTION - CLASS 1M5000C10 / REPORTED CQI DISTRIBUTION - CLASS 2M5000C11 / REPORTED CQI DISTRIBUTION - CLASS 3M5000C12 / REPORTED CQI DISTRIBUTION - CLASS 4M5000C13 / REPORTED CQI DISTRIBUTION - CLASS 5M5000C14 / REPORTED CQI DISTRIBUTION - CLASS 6M5000C15 / REPORTED CQI DISTRIBUTION - CLASS 7M5000C16 / REPORTED CQI DISTRIBUTION - CLASS 8M5000C17 / REPORTED CQI DISTRIBUTION - CLASS 9M5000C18 / REPORTED CQI DISTRIBUTION - CLASS 10M5000C19 / REPORTED CQI DISTRIBUTION - CLASS 11M5000C21 / REPORTED CQI DISTRIBUTION - CLASS 13M5000C22 / REPORTED CQI DISTRIBUTION - CLASS 14M5000C23 / REPORTED CQI DISTRIBUTION - CLASS 15

48 DN09100723


Id:0900d805808eef45Confidential

M5000C24 / REPORTED CQI DISTRIBUTION - CLASS 16M5000C25 / REPORTED CQI DISTRIBUTION - CLASS 17M5000C26 / REPORTED CQI DISTRIBUTION - CLASS 18M5000C27 / REPORTED CQI DISTRIBUTION - CLASS 19M5000C28 / REPORTED CQI DISTRIBUTION - CLASS 20M5000C29 / REPORTED CQI DISTRIBUTION - CLASS 21M5000C30 / REPORTED CQI DISTRIBUTION - CLASS 22M5000C31 / REPORTED CQI DISTRIBUTION - CLASS 23M5000C32 / REPORTED CQI DISTRIBUTION - CLASS 24M5000C33 / REPORTED CQI DISTRIBUTION - CLASS 25M5000C34 / REPORTED CQI DISTRIBUTION - CLASS 26M5000C35 / REPORTED CQI DISTRIBUTION - CLASS 27M5000C36 / REPORTED CQI DISTRIBUTION - CLASS 28M5000C37 / REPORTED CQI DISTRIBUTION - CLASS 29M5000C38 / REPORTED CQI DISTRIBUTION - CLASS 30

Reference informationHSDPA RRM in RNC, Functional Area Description

Other-

DN09100723 49


Id:0900d805808f1610Confidential

3.27 Multi-Band Load Balancing load weight calculation changeRU30 release where the change will be introducedRU30 EP1

Relation to features or correctionsRelated to feature: RAN2172: Multi-Band Load BalancingFault correction: RU30_Pilot_SBM: MBLB: Equation of load weight calculation need to be modified

Short descriptionIn RAN2172: Multi-Band Load Balancing load (MBLB) is one factor used in decision making. Decision of MBLB handover is done based on calculated preference score which is sum of preferred layer, band, RSCP and load related weights.

Load weight has been earlier calculated with the following equation:

LaySelWeightLoad is value of management parameter PFL-LaySelWeightLoad. HSPA-loadLevel indicates the HSPA load level in the cell. The value can be from 1 up to 22. LowLoadPreference is set to value 1000 if parameter PFL-LaySelLowLoadPref is set to 'enabled' and there is low load in the cell. Otherwise, it is set to value 1.

The preference score is calculated to all frequencies for which a possible target cell for MBLB handover and for the source frequency exists. The equation shows that all the frequency layers will get the same value for LaySelWeightLoad, which is the value taken from PFL-LaySelWeightLoad parameter. From the decision making point of view, it does not make any difference which value between 1 and 10000 is used PFL-LaySelWeight-Load parameter as the absolute change is identical to all calculated preference scores. Only using value 0 makes difference as it makes the LoadWeight to 0 meaning that load does not have effect on decision making.

To improve configurability of how HSPA load level affects the decision making, the fol-lowing modification is made to the equation:

This increases the flexibility of configuration. However, the functionality before this change can be kept. If any value between 1 and 10000 is used before the change, exactly the same functionality can be kept by configuring the PFL-LaySelWeightLoad parameter to value 1. The same is true about the value 0. Using any value from 2 to 10000 after this change can change the functionality, depending on how other weight- related parameters are set (PFL-LaySelWeightPrefLayer, PFL-LaySelWeightBand and PFL-LaySelWeightRSCP).

Preference_score PrefLayerWeight BandWeight RSCPWeight LoadWeight+ + +=

LoadWeight LaySelWeightLoad 22( HSPAloadLevel ) ] LowLoadPreference⋅–+[=

LoadWeight LaySelWeightLoad 22 HSPAloadLevel ) LowLoadPreference⋅–(⋅=

50 DN09100723


Id:0900d805808f1610Confidential

Expected impactNo impact is expected if the above instructions are followed.

Reasoning why the change was madeTo improve configurability of how HSPA load level affects the decision making

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic when the RAN2172: Multi-Band Load Balancing feature is used.


UE dependencyNone

Impacted counters/KPIsWith PFL-LaySelWeightLoad parameter values from 2 to 10000, the following counters may update differently:

M1006C234 RB SETUP ATTEMPT WITH BLIND HOM1006C235 RB SETUP SUCCESSFUL WITH BLIND HOM1006C240 ATTEMPTED INTER-BTS LAYER CHANGES IN PCH/FACH TO DCHM1006C241 SUCCESSFUL INTER-BTS LAYER CHANGES IN PCH/FACH TO DCHM1008C296 MBLB IFHO ATTEMPTS WITH UE BAND CAPAM1008C297 MBLB IFHO ATTEMPTS WITH SERVICE AND UE FEATURE CAPAM1008C298 MBLB IFHO ATTEMPTS WITH RSCPM1008C299 MBLB IFHO ATTEMPTS WITH LOADM1008C300 SUCCESSFUL MBLB IFHOM1008C306 IFHO MEAS START ATTEMPTS DUE TO MBLB


Other-

DN09100723 51


Id:0900d80580900eceConfidential

3.28 New consistency check for parameters related to SRNC anchoringRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsFeature/fault correction introducing the "Invalid values successfully updated for RNMOBI MO" change.

The affected legacy features/functionalities: handling of mobility-related management parameters in RNMOBI object

Short descriptionNew consistency check is added to the following parameters existing in RNMOBI object:

• AnchorFMciIdentifier • AnchorFMcsIdentifier • AnchorHopiIdentifier • AnchorHopsIdentifier

These parameters refer from RNMOBI to another radio network object instance. When operator creates a new RNMOBI instance or modifies any of RNMOBI’s parameters, RNC SW executes the consistency check to make sure the referred object instances exist in radio network database. The referred objects in RNMOBI are FMCI, FMCS, HOPI, and HOPS. RNW SW creates a new RNMOBI instance or modifies RMNOBI’s parameters only if the referred object instances are present in radio network database.

Expected impactRNMOBI object instance creation or parameter modifications of RNMOBI object via NetAct or OMS UI fails if all the referred object instances of HOPS, HOPI, FMCS, and FMCI are not created in RNC’s radio network database.

Reasoning why the change was madeWithout this check you may have invalid anchoring parameter definitions, that is refer-ences to object instances that do not exist in radio network database.


NE SW versionRNC RN6.0

UE dependencyNone



Other-

52 DN09100723


Id:0900d8058090bcaaConfidential

3.29 Faster RAB set-up and state transition timeRU30 release where the change will be introducedRU30 Main Release


Short descriptionIf transport set-ups towards BTS or L2 resource reservations (for example, MAC-d, RLC or FP) inside RNC are required, the RAB set-up and state transition to Cell_DCH are now faster thanks to L3 SW re-architecture. Previously, transport resources were set up and L2 resources were reserved one by one. In the new SW architecture, transport and L2 resources can be set up partly in parallel.

The change is valid for both IP and ATM configurations.

Expected impactA small improvement to RAB setup time, especially in RNC loaded situations, is visible. The improvement time is tens of milliseconds.

Reasoning why the change was madeSW re-architecture was made to improve the maintainability of the SW.


NE SW versionRN6.0


UE dependencyNone

Impacted counters/KPIsM1001C223 AVG_RAB_SETUP_TM_CS_VOICEM1001C224 DENOM_RAB_SETUP_TM_CS_VOICEM1001C225 AVG_RAB_SETUP_TM_CS_CONVM1001C226 DENOM_RAB_SETUP_TM_CS_CONVM1001C227 AVG_RAB_SETUP_TM_CS_STREAM1001C228 DENOM_RAB_SETUP_TM_CS_STREAM1001C231 AVG_RAB_SETUP_TM_PS_STREAM1001C232 DENOM_RAB_SETUP_TM_PS_STREAM1001C233 AVG_RAB_SETUP_TM_PS_INTERM1001C234 DENOM_RAB_SETUP_TM_PS_INTERM1001C235 AVG_RAB_SETUP_TM_PS_BACKGM1001C236 DENOM_RAB_SETUP_TM_PS_BACKG


Other-

DN09100723 53


Id:0900d8058090bcadConfidential

3.30 HSDPA/HSUPA Dynamic Power Allocation correctionsRU30 release where the change will be introducedRU30 Main Release

Relation to features or correctionsHSDPA Dynamic Resource AllocationHSUPA Dynamic Resource Allocation

Short descriptionRNC affects the HSDPA power allocation indirectly by scheduling NRT DCH bit rates. The higher bit rates the RNC allocates to the NRT DCHs, the less power the BTS can use for HSDPA, and vice versa. RNC applies dynamic adjustment of the target threshold (named PtxTargetPS) for NRT DCH packet scheduling and calculates weight value for NRT DCH users and HSDPA users. Based on the calculated weight value, RNC adjusts PtxTargetPS.

Correspondingly, RNC divides UL interference capacity between UL NRT DCH and HSUPA users by adjusting dynamic target threshold PrxTargetPS.

For more details about dynamic adjustment of the PtxTargetPS and PrxTargetPS, see HSDPA RRM in RNC FAD and HSUPA RRM in RNC FAD, respectively.

1. In RU20 and earlier releases, the maximum number of users taken into account when calculating weight values for PtxTargetPS and PrxTargetPS adjustment were limited to 50. In RU30 the maximum number of users will be increased to 250.

2. In RU20 weight values for PtxTargetPS and PrxTargetPS adjustment were not updated in case SHO RL release scenario. In RU30 this will be corrected.

Expected impactThere is no KPI impact, as both NRT DCH and HSDPA/HSUPA users benefit similarly from these corrections.

Reasoning why the change was made

1. The change was made to guarantee fair DL and UL power allocation between Rel’99 and HSDPA/HSUPA in the future when the number of HSDPA/HSUPA users will increase.

2. SW operated incorrectly.

Type of change: generic in the SW, license-based or activated by PRFILEThe changes are generic.


UE dependencyRel-5 or later HSDPA UE, Rel-6 or later HSUPA UE


Reference informationBRM DPOW weight algorithm corrections

Other-

54 DN09100723


Id:0900d8058091c1f6Confidential

3.31 Correction to RT-over-NRT triggered by PS streaming mapped to DCHRU30 release where the change will be introducedRU30 EP2

Relation to features or correctionsFeature/fault correction introducing the change: PR 103420ESPE02The affected legacy features/functionalities: RAN1004: Streaming QoS for HSPA

Short descriptionIf the admission decision for PS streaming service is not successful, then it is checked if it can be admitted with RT-over-NRT. There was an error in the RT-over-NRT when PS streaming was mapped to DCH transport channel type and this error caused that PS streaming service was admitted too easily. This may result in overload and subse-quently cause overload actions for services that should not be affected by new PS streaming service (the existing PS streaming services, higher priority NRT services).

Expected impactThe correction can lower KPI related to the success rates of new PS streaming service setups (RNC_618a RAB Setup and Access Complete Ratio for Streaming).

Reasoning why the change was madeTo remove the erroneous functionality.



UE dependencyNone

Impacted counters/KPIsM1001C119 RAB ACCESS COMPLETIONS FOR PS DATA STREAMM1001C100 RAB SETUP FAILURES DUE TO AC FOR PS DATA STREAMM1000C142 RB DOWNGRADE BY ENH OVERLOAD CONTROL USING TFC SUBSET M1000C154 RB DOWNGRADE BY ENH OVERLOAD CONTROL USING RL RECONFM1000C166 RB RELEASE DUE TO ENH OVERLOAD CONTROL USING RL RECONFM1000C147 RB DOWNGRADE BY PBS DUE TO INTERFERENCE CONGESTION


Other-

DN09100723 55


Id:0900d8058090bdd1Confidential

3.32 Increase of HSUPA users per LCGRU30 release where the change will be introducedRU30 EP2

Relation to features or correctionsFeature introducing the change: RAN2124: HSPA 128 users per cellLegacy features/functionalities affected: RAN1686: HSPA 72 users per cell

Short descriptionThe maximum HSUPA user amount per LCG is updated from 160 to 480 in RNC.


KPIs related to HSUPA success rate can improve as RNC does not limit the amount of HSUPA users with too low limit in LCG level.

If HSUPA user amount limits set in RNC are not in line with the HSUPA user capacity of BTS, then it is possible that rejected HSUPA users are now more visible in NBAP-related counters instead of admission-control-related counters. This can happen if BTS does not support 480 HSUPA users per LCG and LCG limit is not set in RNC according to actual BTS capacity with the RNP parameter MaxNumberEDCHLCG.

Reasoning why the change was madeRNC was limiting the HSUPA user amount too early based on wrong LCG level limit.




UE dependencyNone

Impacted counters/KPIsM1002C515 UL DCH SELECTED FOR INTERACTIVE DUE TO MAX HSUPA USERSM1002C516 UL DCH SELECTED FOR BACKGROUND DUE TO MAX HSUPA USERSM1002C599 UL DCH SELECTED FOR STREAMING DUE TO MAX HSUPA USERS


Other-

56 DN09100723


Id:0900d805809181efConfidential

3.33 GTP extension headers handling change in RNCRU30 release where the change will be introducedRU30 EP1

Relation to features or correctionsRelated to the RAN750: IP based Iu-PS featureRelated to the correction: RNC does not handle GTP extension header notification cor-rectly

Short descriptionThe RNC implementation is not compliant with 3GPP specification TS 29.060. This has impact on end user experience and causes exceptional procession of UP data when GTP-PDUs with unknown type of GTP extension received in PDCP layer. The following changes have been introduced:

1. RNC will send a Supported Extension Headers Notification to the originator of the GTP PDU only for GTP PDU with an extension header of unknown type, but marked as 'comprehension required‘.

2. RNC can handle multiple extension header in single GTP-PDU correctly, which means all the GTP extension will be stripped out so that only user data will be sent to UE.

Expected impactGTP extension header handling compliant with 3GPP specification (TS 29.060)

End-user experience improved

Reasoning why the change was madeRNC did not handle the GTP-PDU with extension header 3GPP compliantly (TS 29.060).



UE dependencyNone


Reference informationTS 29.060 TS 29.281

Other-

DN09100723 57


Id:0900d8058091920bConfidential

3.34 H-RNTI allocationRU30 release where the change will be introducedRU30 Main release

Relation to features or correctionsRelated to the RAN1637: High Speed Cell_FACH DL feature(number of supported cells, number of supported HSDPA/HSPA users per cell and DC-HSPA users - both primary and secondary HSDPA users)

Short descriptionIn RN6.0 the H-RNTI allocation algorithm in RNC has been moved from BTS level to cell level. The reason for that are the new features and configurations supported by RU30 that require more H-RNTIs.

The H-RNTI has 16 bits and to avoid decoding errors in the UE, it is required that the certain used H-RNTIs have at least 3 bit difference to any other H-RNTI that can be allo-cated. Thus, the maximum number of available H-RNTIs is much lower than 2^16.

From RN6.0 1.3.1 onwards, it is possible to select whether BTS or cell level H-RNTI pool in RNC is used. This is controlled by a PRFILE parameter and the default value is set cell level. If BTS level pool is selected, then the H-RNTI does not change in intra-BTS SCC case.

The functionality (Cell/BTS level H-RNTI pool is used) is controlled via the PRFILE (002:19139 RN60_INT_FEAT_RES_10).

• Bit 0 (1st bit) set 0, Cell level H-RNTI pool is used. This is by default RU30 generic change.

• Bit 0 (1st bit) set 1, BTS level H-RNTI pool is used. See other information.

Expected impactWhile using Cell level H-RNTI pooling during a pilot, the following has been found:In intra-BTS HSDPA SCC case the WN6.0 BTS (with certain configurations) does not use the allocated new H-RNTI after activation time. This leads to a situation where the transmitted DL data carried over HSDPA is not received by UE using new HRNTI (DL cut). This results in:

• RLC reset or RLC unrecoverable error for PS services (or even SRB error if F-DPCH configuration is used).

• HSDPA/HSPA retainability, MAC-hs/ehs retransmission KPIs to be affected.

WN6 BTS configuration and condition when the problem occurs:

• BTS is configured with shared scheduler license (that is, one Mac-hs scheduler serves multiple cells) – one scheduler is hosted in one DSP Mac-hs core.

• More than one HSDPA cell is hosted by the scheduler with the same frequency (not dual carrier) – this most likely happens in 1+1+1 scenario.

• Intra-BTS SCC is triggered between these cells with the change of H-RNTI.

In all the other cases, where SCC happens across the HSDPA cells hosted on different Mac-hs cores/Schedulers, the problem does not occur, though there is a change in H-RNTI during intra-BTS SCC.

Reasoning why the change was madeTo avoid decoding errors in UE it is required that certain used H-RNTIs has at least 3-bit difference to any other available H-RNTI.

58 DN09100723


Id:0900d8058091920bConfidential

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic up to RN6.0 1.3 and can be modified via PRFILE from RN6.0 1.3.1 onwards.

NE SW versionRN6.0 RN6.0 1.3.1

UE dependencyNone

Impacted counters/KPIsHSDPA/HSPA retainability, MAC-hs/ehs retransmissionM1008C217, M1006C118, M1006C186, M5000C47, M1002C539, M1002C479, M1022C57

Reference informationRNC modification for H-RNTI allocationHSDPA and HSUPA and PS DCR increased by around 0.2% after PP8.7or PP8.10WN7.0_1104_654 RLC_RESET after ASU, only when two HSPA users in the same BTS, one HSPA user is OK.

OtherBTS level H-RNTI pool needed only with certain configuration of WN6.0 BTS and is not needed with WN7.0 where the correction exist (WN7.0_1104_654 RLC_RESET after ASU, only when two HSPA users in the same BTS, one HSPA user is OK). The cell level H-RNTI pool is needed at least when the number of HSDPA/HSPA users on CELL_DCH state within a BTS is more than 400 to guarantee at least 3 digit differences of H-RNTI between two HSDPA/HSPA users. Note that with RAN1637: High Speed Cell_FACH DL feature only Cell level H-RNTI pooling can be used.

RNC Generix Algorithm Changes and Impact on Counters and Kpi

Documents

Transcript of RNC Generix Algorithm Changes and Impact on Counters and Kpi