Rnc Gen Alg Changes

WCDMA RAN, Rel. RU40, Operating Documentation, Issue 03

RNC Generic Algorithm Changes and Impact on Counters and KPIs

DN09100723

Issue 02FApproval Date 2013-09-11

Confidential

2 DN09100723Issue 02F

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

Id:0900d80580a23a53Confidential

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 2013. 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 knnen Gefahren durch Laser, Elektrizitt, 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 44 pages.

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

1 Introduction to RU40 algorithm changes and impact on counters and KPIs7

2 Counter changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1 Increase of M1001C107 and M1001C112 RAB_STP_FAIL_PS_xxx_RNC

82.2 M1006C211 increase and M1006C212 decrease . . . . . . . . . . . . . . . . . . 92.3 Increase of RAB active failures due to Iu. . . . . . . . . . . . . . . . . . . . . . . . 10

3 Algorithm changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1 SAB feature activation logic changes . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 MBLB is extended to support DB-DC-HSDPA. . . . . . . . . . . . . . . . . . . . 133.3 Channel type switch in case of RRC connection re-establishment for CS

voice over HSPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 RNC Performance Improvement Due to L2 Call Configuration Optimization

163.5 DMPG Switch UL Data Loss Prevention . . . . . . . . . . . . . . . . . . . . . . . . 173.6 RRM defines MAC logical channel priorities for the radio bearers . . . . 183.7 Direct HSPA allocation for CS voice in target side during inter RNC inter-

frequency handover and blind inter-frequency handover in RAB setup phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.8 Direct state transition from Cell_DCH to Cell_PCH for DCH/DCH configu-ration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.9 The load-based E-DCH 2 ms TTI prevention of the RAN2879: Mass Event Handler feature is applied in the PIC cell. . . . . . . . . . . . . . . . . . . . . . . . 22

3.10 Checking of HSDPA user amounts against LCG and BTS specific user ca-pacity indicated by BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.11 E-DPDCH Power Interpolation is used by default . . . . . . . . . . . . . . . . . 243.12 Core Network Overload handling change . . . . . . . . . . . . . . . . . . . . . . . 263.13 UL DCH bit rate upgrade over Iur handling change. . . . . . . . . . . . . . . . 273.14 Change of HSUPA resource status indication based NRT RB admission

control for UEs having a standalone SRB allocation mapped to E-DCH 28

4 Parameter changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1 The FP max frame size on Iur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2 Iu parameters moved to correct object level in RNW database. . . . . . . 314.3 PLMNId related configuration changes in Iu and Iu-Bc interfaces . . . . . 344.4 Configuration of FlexiIuWeight parameters for IUCS and IUPS . . . . . . 374.5 Configurable QoS marking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6 Default value of the EDCHMACdFlowThroughputTimetoTrigger is

changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.7 PRFILE parameters replaced by new Radio Network database parameters

424.8 IPQM object id for IuCS/IuPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 DN09100723



List of tablesTable 1 IUCS-1 calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Table 2 IUCS-2 calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

DN09100723 5


Summary of changes

Id:0900d80580a23c6cConfidential

Summary of changesChanges between issues 02E (2013-08-19, RU40) and 02F (2013-09-11, RU40)

Change of HSUPA resource status indication based NRT RB admission control for UEs having a standalone SRB allocation mapped to E-DCH (3.14)

3.14 Change of HSUPA resource status indication based NRT RB admission control for UEs having a standalone SRB allocation mapped to E-DCH has been added.

The FP max frame size on Iur (4.1)

4.1 The FP max frame size on Iur has been updated.IPQM object id for IuCS/IuPS (4.8)

4.8 IPQM object id for IuCS/IuPS has been added.

Changes between issues 02D (2013-07-10, RU40) and 02E (2013-08-19, RU40)M1006C211 increase and M1006C212 decrease (2.2)2.2 M1006C211 increase and M1006C212 decrease has been added.

Increase of RAB active failures due to Iu (2.3)2.3 Increase of RAB active failures due to Iu has been added.

Changes between issues 02C (2013-07-04, RU40) and 02D (2013-07-10, RU40)

Direct state transition from Cell_DCH to Cell_PCH for DCH/DCH configuration (3.8)3.8 Direct state transition from Cell_DCH to Cell_PCH for DCH/DCH configuration has been updated.

Iu parameters moved to correct object level in RNW database (4.2)4.2 Iu parameters moved to correct object level in RNW database has been updated.

PLMNId related configuration changes in Iu and Iu-Bc interfaces (4.3)4.3 PLMNId related configuration changes in Iu and Iu-Bc interfaces has been updated.

6 DN09100723


Id:0900d80580a23c6cConfidential

Summary of changes

DN09100723 7


Introduction to RU40 algorithm changes and impact oncounters and KPIs

Id:0900d805809b0e0fConfidential

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

Chapter Algorithm changes documents the functional changes. Chapter Parameter changes explains the generic management parameter changes of the release. The parameters are typically legacy system internal parameters that have been converted to visible operator parameters and thus require some attention from the operator. It is possible for these parameters to change RNC functionalities and such a behavior is also explained in the same generic changes.

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.

The document includes references to the features that do not belong to RU40 release. Even though the document corresponds directly to the RNC SW content in the release, it might also cover some content of the postponed features. Therefore, the referred feature names can be different than the ones in the release content.

8 DN09100723


Id:0900d80580a0b22dConfidential

Counter changes

2 Counter changes

2.1 Increase of M1001C107 and M1001C112 RAB_STP_FAIL_PS_xxx_RNCRU40 release where the change will be introducedRN7.0

Relation to features or corrections-

Short descriptionWhen the UE is in PCH state and the RNC receives RAB Assignment Request from the CN asking to setup new RAB, the RNC needs to page the UE to establish signaling con-nection. If the UE does not respond to paging, the RAB setup shall be counted as failed in statistics.

In RN6.0 there is a fault in counter updates so that all M1001 counter updates are missing in this scenario. Therefore when upgrading to RN7.0, it is expected that small increase in M1001C107 and/or M1001C112 occurs as these counters are corrected in RN7.0 to indicate RAB setup failures due to no response to paging. The failures are counted in RAB_STP_FAIL_PS_xxx_RNC counters because from statistics point of view the RAB is in setup phase, and for that phase there isnt any radio interface related counter available.

Expected impactMinor degradation in RAB Setup and Access Complete Radio KPI after RNC SW upgrade to RN7.0.

Reasoning why the change was madePM counter correction

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

NE SW versionRN7.0

UE dependencyNone

Impacted counters/KPIsM1001C107 RAB_STP_FAIL_PS_INTER_RNCM1001C112 RAB_STP_FAIL_PS_BACKG_RNC

RNC_157a RAB Setup and Access Complete Ratio for NRT Service

Reference information31811ESPE07)

Other-

DN09100723 9


Id:0900d80580a0b0aeConfidential

2.2 M1006C211 increase and M1006C212 decreaseRU40 release where the change will be introducedRN7.0

Relation to features or corrections-

Short descriptionWhen the UE is in PCH state and direct state transition to Cell_DCH with DC-HSDPA is triggered, but the UE does not respond to Cell Update Confirm sent by the RNC, it is expected that the M1006C211 FAIL_RB_SETUP_DCHSDPA_NOREP counter is updated.In RN6.0, however, this scenario updated the M1006C212 FAIL_RB_SETUP_DCHSDPA_UE counter that is to measure cases when the UE sends negative response to Cell Update Confirm.

This fault in the counter implementation has been corrected in RN7.0 so that the M1006C211 counter is updated instead of M1006C212. Therefore, when upgrading from RN6.0 to RN7.0, it is expected to see increase of M1006C211 and corresponding decrease of M1006C212.

Expected impactM1006C211 increases while M1006C212 decreases at the same time. The failure rate KPI is not impacted because both are failure counters.

Reasoning why the change was madePM counter correction


NE SW versionRN7.0

UE dependencyNone

Impacted counters/KPIsM1006C211 FAIL_RB_SETUP_DCHSDPA_NOREPM1006C212 FAIL_RB_SETUP_DCHSDPA_UE

Reference information-

Other-

10 DN09100723


Id:0900d80580a1e9abConfidential

2.3 Increase of RAB active failures due to IuRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:Internal Improvement

The affected legacy features/functionality:-

Short descriptionWhen the core network releases SCCP connection without sending IU Release Command before that, the behaviour of RNC counter updates has been changed in RNC SW in above mentioned releases.

The old implementation was such that SCCP connection release triggered by the core network was counted as normal RAB release (RAB active complete) regardless of the SCCP release cause, while in the new implementation only the following SCCP causes are counted as normal release:

End user originated End user congestion End user failure SCCP user originatedWhen the core network releases SCCP connection with any cause other than the men-tioned above without sending IU Release Command before that, it is counted as RAB Active Failure due to IU and thus degrades retainability KPI.

The reason for making this counter implementation change in the RNC is to detect failure situations on core network side in a better way.

Expected impactMinor degradation in RAB Success Ratio (retainability) KPI is expected after upgrading to RU40 if the core network is releasing SCCP connections with a SCCP release cause counted as abnormal without sending IU Release Command.

Reasoning why the change was madeStatistics enhancement to detect core-network-related issues in a better way.


NE SW versionRN7.0, mcRNC 3.0, and ADA 5.0

UE dependencyNone

Impacted counters/KPIsM1001C145 RAB_ACT_FAIL_CS_VOICE_IUM1001C185 RAB_ACT_FAIL_PS_INTER_IUM1001C191 RAB_ACT_FAIL_PS_BACKG_IU

RNC_231d RAB Success Ratio, Voice (CSR)RNC_615c RAB Success Ratio, NRT Services, from Network Perspective

DN09100723 11


Id:0900d80580a1e9abConfidential

The additional failures counted by the above mentioned counters in RU40 were included in the following counters in RU30:M1001C136 RAB_ACT_COMP_CS_VOICEM1001C141 RAB_ACT_COMP_PS_INTERM1001C142 RAB_ACT_COMP_PS_BACKG


Other-

12 DN09100723


Id:0900d80580a27eebConfidential

Algorithm changes

3 Algorithm changes

3.1 SAB feature activation logic changesRU40 release where the change will be introducedThere is no discontinuation to the RAN2.0023: ServiceAreaBroadcast feature. The acti-vation logic is the only element changing.

Relation to features or correctionsRAN2527: SAB Support with 2SCCPCHs

Short descriptionIn RU30 system RAN2.0023 Service Area Broadcast feature is active if NbrOfSCCPCHs is set as '3' and in RU40 system RAN2.0023 Service Area Broadcast feature is active if new parameter WCEL-SABEnabled is set to 'Enabled'. During RU30 to RU40 SW upgrade RNW Database conversion takes care of setting correct WCEL-SAB Enabled value based on WCEL-NbrOfSCCPCHs parameter value.Expected impactNo impact to KPIs is expected.

Reasoning why the change was madePreviously, RAN2.0023 Service Area Broadcast feature was controlled by NbrOfSCCPCHs. From RU40 onwards, there is a switch WCEL-SAB enabled parameter to control this functionality.

The RAN2527: SAB Support with 2SCCPCHs feature has introduced the use of SAB also with two SCCPCHs. As consequence, it is not possible to use the NbrOfSCCPCHs parameter for SAB activation on cell level anymore. In RU40, SAB can be used either with two or three SCCPCHs.

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


UE dependencyNone

Impacted counters/KPIsM1012 Service Area Broadcast


Other-

DN09100723 13


Id:0900d805809f6547Confidential

3.2 MBLB is extended to support DB-DC-HSDPARU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:RAN2179: Dual Band HSDPA 42 Mbps

The affected legacy features/functionality:RAN2172: Multi-Band Load Balancing

Short descriptionRAN2172: Multi-Band Load Balancing is extended to support DB-DC-HSDPA layer selection. DB-DC-HSDPA introduces a new preferred layer definition - DB-DC-HSDPA layer - to be used for the Multi-Band Load Balancing feature.

The following new parameters define the preferred layers for DB-DC-HSDPA-capable UE on a service-by-service basis:

PFL-PFLDBHSDNRT-PrefLayerDBHSDNRT defines the preferred layers for DB-DC-HSDPA-capable UE that has only NRT RAB(s) allocated.

PFL-PFLDBHSDStr-PrefLayerDBHSDStr defines the preferred layers for DB-DC-HSDPA-capable UE that has a streaming RAB and 0...3 NRT RAB(s) allocated.

PFL-PFLDBHSDAMR-PrefLayerDBHSDAMR defines the preferred layers for DB-DC-HSDPA-capable UE that has only an AMR RAB allocated.

PFL-PFLDBHSDAMRNRT-PrefLayerDBHSDAMRNRT defines the preferred layers for DB-DC-HSDPA-capable UE that has an AMR RAB, 0...1 streaming RAB, and 1...3 NRT RAB(s) allocated.

These new parameters are visible to the operator if RAN2172: Multi-Band Load Balanc-ing is used even if RAN2179: Dual Band HSDPA 42 Mbps is not used.

Expected impactNo KPI effect is expected. RAN2172: Multi-Band Load Balancing (MBLB) functionalities remain unchanged. The change enables to apply legacy functionalities provided by MBLB to Dual Band Capable UE.

Reasoning why the change was madeDual Band Capable UE can be directed to a desired frequency layer even if Dual Band HSDPA is not deployed in the network.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is valid in SW only if operator uses RAN2172: Multi-Band Load Balancing. It cannot be controlled by feature on/off switch or a license.


UE dependencyRel9 Dual Band Capable UE

Impacted counters/KPIs-


14 DN09100723



Other-

DN09100723 15


Id:0900d805809b0f9fConfidential

3.3 Channel type switch in case of RRC connection re-estab-lishment for CS voice over HSPARU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:Internal modification

The affected legacy features/functionality:RRC connection re-establishment

Short descriptionUE with CS voice over HSPA channel configuration can be changed to DCH configura-tion with RRC connection re-establishment procedure after radio link failure.

If the new cell were UE is camped after radio link failure does not have HSPA available also DCH configuration can be offered with this new implementation. In the old imple-mentation only the same configuration what UE had could be offered. In case it was not available the call was dropped.

Expected impactAMR drop rate is reduced for CS voice over HSPA users.

Reasoning why the change was madeThe change is made because it is better to switch channel type than to drop the user. This change is done as generic as no reasons to keep only the old functionality was seen.



UE dependencyChannel type switch during RRC connection re-establishment is supported from Rel7 UE onwards.

Impacted counters/KPIsThe M1006C186 RRC RE-ESTABLISH SUCCESS RT counter is affected if CS voice over HSPA feature is in use. Otherwise, no counter is affected.


Other-

16 DN09100723



3.4 RNC Performance Improvement Due to L2 Call Configura-tion OptimizationRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:-


Short descriptionDue to L2 SW optimization, DMPG load caused by L3 - L2 call configuration messages is decreased. This is achieved by relocating a part of the call configuration SW to DSP from the DMPGs PPC processor. The load decrease on PPC is notable, while the load increase on DSP is negligible. By reducing the PPC load, an improvement in overall per-formance of DMPG and the whole RNC can be seen under heavy load conditions.

Expected impactImprovement can be seen in the HSDPA Resource Accessibility for NRT Traffic resource KPI. This is possible in the situation where with a certain traffic mix, DMPG load before the optimization was (near) overload and has lowered after the optimized SW has been taken into use.

KPI name: HSDPA Resource Accessibility for NRT TrafficKPI abbreviation: HSDPA res acc NRT trafKPI ID: RNC_605b

Reasoning why the change was madeThe change improves the performance of the RNC.

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

NE SW versionRN7.0

UE dependencyNone

Impacted counters/KPIsReduction of the DMPG CPU load can be seen in the M592C0 AVERAGE_LOAD counter.


Other-

DN09100723 17


Id:0900d805809f656fConfidential

3.5 DMPG Switch UL Data Loss PreventionRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:Internal modification (DMPG Switch UL Data Loss Prevention)


Short descriptionDMPG switch is improved to prevent data loss in UL. DMPG switch is a procedure where L2 resources a transferred between DMPGs (or other processing entities in RNC) in the following cases:

UE state transitions between Cell_FACH and Cell_DCH with HS-DSCH (HSDPA) are selected as the DL transport channel type.

There is a transport channel type change between DCH and HS-DSCH.In some cases during UE state transitions between Cell_FACH and Cell_DCH with HS-DSCH (HSDPA) selected as the DL transport channel type, the UL data was lost during the DMPG switch, which caused a delay in TCP connection establishment. In these tran-sitions to/from Cell_FACH, UL data is now buffered and delivered further instead of dropping, like DL data. This enables fast TCP connection establishment in all situations.

Expected impactNo KPI impacts. End-to-end TCP connection establishment time may improve during transitions to/from Cell_FACH.

Reasoning why the change was madeThe change was requested by a customer.


NE SW versionRN7.0

UE dependencyNone

Impacted counters/KPIsNone

Reference informationInternal modification (DMPG Switch UL Data Loss Prevention)

Other-

18 DN09100723


Id:0900d805809f4f23Confidential

3.6 RRM defines MAC logical channel priorities for the radio bearersRU40 release where the change will be introducedRU40

Relation to features or correctionsRAN2494: Fast Cell_PCH Switching

Short descriptionMAC logical priorities for radio bearers other than SRB1, SRB2 and SRB3 are shifted to a lower value to get the three highest values for SRB1, SRB2 and SRB3.

Expected impactNo impact to KPIs is expected. Priority values are changed, but the order of priorities of different radio bearer types remains the same.

Reasoning why the change was madeThe change was made to give possibility of setting a higher priority to some SRBs (for example SRB2). SRB2, that is used for messages with activity time, can have higher priority than the other SRBs.



UE dependencyNone



Other-

DN09100723 19


Id:0900d805809b0f3dConfidential

3.7 Direct HSPA allocation for CS voice in target side during inter RNC inter-frequency handover and blind inter-fre-quency handover in RAB setup phaseRU40 release where the change will be introducedRU40



Short descriptionEarlier, the DCH was always allocated for AMR in target side during inter RNC inter-fre-quency handover and blind inter-frequency handover in RAB setup phase. From now on, HSPA allocation is made in target side if possible. However, if HSPA cannot be allo-cated, the DCH allocation can be made as earlier.

Expected impactNo impact to KPIs is expected.

Reasoning why the change was madeUse of CS voice over HSPA can be increased.



UE dependencyUE supporting CS voice over HSPA



Other-

20 DN09100723



3.8 Direct state transition from Cell_DCH to Cell_PCH for DCH/DCH configuration RU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:RAN2494: Fast Cell_PCH switching

The affected legacy features/functionality:RAN1232: RNC Fast Call Setup from Cell_PCH state

Short descriptionIn RU40 direct state transitions from Cell_DCH to Cell_PCH are also made for UEs in DCH/DCH configuration (in RU30, this was limited only to E-DCH/HSDPA and DCH/HSDPA UEs). This increases state transitions from Cell_DCH to Cell_PCH.

Expected impactFrom now on, also the connections that have DCH/DCH configuration can benefit from faster channel type switching from Cell_DCH to Cell_PCH. This does not only mean old R99 UEs, but any UE that has been allocated such a channel configuration, for example because of HSDPA congestion.

Reasoning why the change was madeThe changes has been made to get full benefits of the RAN2494: Fast Cell_PCH switch-ing feature where signaling procedures are optimized by not sending unchanged param-eters. The restriction of Cell_DCH to Cell_PCH transition for DCH/DCH configuration was removed simultaneously and the handling was generalized for channel type config-urations.

Type of change: generic in the SW, license-based or activated by PRFILEThis is a generic change in the SW and the default value of the controlling parameter RNFC-DCHtoPCHEnabled is enabled. If this parameter is modified to disabled value, then the direct state transitions for all channel types are prohibited excluding the cases that are triggered by UE sending Signalling Connection Release Indication message with the cause IE.

Direct state transition from Cell_DCH to Cell_PCH for DCH/DCH configuration can be disabled separately via PRFILE parameter RU40_MAINT_02,(2,2098). When the lowest significant bit (1st bit) of parameter 2,2098 is set to value 1 and RNFC-DCHtoPCHenabled is set to enabled, then the functionality is as in RU30 and state tran-sitions from Cell_DCH to Cell_PCH are made only when UE has EDCH/HSDPA or DCH/HSDPA configuration.

Note that the other bits of the same PRFILE parameter are used for other purposes.


UE dependencyNone

Impacted counters/KPIsThe following counters are expected to increase:

DN09100723 21



M1006C114 CELL_DCH_STATE_TO_CELL_PCH M1006C171 DENOM_ST_TRANS_TIME_PCH_FACH M1006C179 DENOM_ST_TRANS_TIME_DCH_PCHThe following counters are expected to decrease:

M1006C45 CELL_DCH_STATE_TO_CELL_FACH M1006C47 CELL_FACH_STATE_CELL_PCH_INA M1006C177 DENOM_ST_TRANS_TIME_DCH_FACH M1006C181 DENOM_ST_TRANS_TIME_FACH_PCHReference information-

Other-

22 DN09100723


Id:0900d805809c5e75Confidential

3.9 The load-based E-DCH 2 ms TTI prevention of the RAN2879: Mass Event Handler feature is applied in the PIC cellRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:RAN2879: Mass Event HandlerPR73589ESPE03

Short descriptionThe load based E-DCH 2 ms TTI prevention of the RAN2879: Mass Event Handler feature is applied in the cell irrespective of the HSUPA interference cancellation (PIC).

Expected impactIf the load-based E-DCH 2 ms TTI prevention is enabled (WCEL-MassEventHandler) in the PIC cell (WCEL- PICState, WCEL-AdminPICState), the load-based E-DCH 2 ms TTI prevention will start operating in the cell after this change. The change increases the E-DCH 10 ms TTI utilization in highly loaded PIC cells provided that the load based E-DCH 2 ms TTI prevention is enabled. L1 overhead with E-DCH 10 ms is lower than with E-DCH TTI 2 ms. This reduces UL interference. Throughput improvements are expected due to increased E-DCH 10 ms TTI utilization in high loaded PIC cell.

Reasoning why the change was madeFavoring E-DCH 10 ms TTI during high/medium load brings gain also if HSUPA interfer-ence cancellation is applied. PIC usage is expected to be still low and thus generic change is considered to be the most flexible for operators.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic. License for RAN2879: Mass Event Handler is needed for oper-ating the feature in RU40.

NE SW versionRN7.0

UE dependencyE-DCH 2 ms TTI capable UE (E-DCH physical layer category 2, 4 or 6)

Impacted counters/KPIsM5000C320, M5000C322, and M5000C324 (E-DCH 2 ms TTI utilization decreases in the PIC cell during high load)M5000C321, M5000C323, and M5000C325 (E-DCH 10 ms TTI utilization increases in the PIC cell during high load)M1023C8, M1023C10, M1023C19, M1023C20, M1023C21, M1023C22 (Cell through-put measurement)

Reference informationPR73589ESPE03

Other-

DN09100723 23


Id:0900d805809d0f4eConfidential

3.10 Checking of HSDPA user amounts against LCG and BTS specific user capacity indicated by BTSRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:RAN2124: HSPA 128 users per cell

The affected legacy features/functionality:Checking of HSDPA user amount

Short descriptionOriginally, RNC limited HSDPA user amount depending on the used HSDPA capacity features, RNP parameters, and HSDPA capacity received from BTS (cell and HSDPA scheduler specific limits for HSDPA user and HS-DSCH MAC-d flow amounts). These checks were made in admission control phase.

The new functionality allows BTS to allocate also its maximum LCG- and BTS-specific HSDPA user amounts to RNC. RNC does not allow more HSDPA users than indicated within those limits.

Expected impactKPI related to HSPA setup success rate can be improved slightly as RNC knows capacity limitation of the BTS beforehand. Thus, no unnecessary setup attempts occur.

Reasoning why the change was madeThis change has been made to decrease signaling between RNC and BTS, especially in high load situations when the number of HSDPA connection closes to the maximum per LCG or BTS.

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

NE SW versionRNC RN7.0, BTS WN8.0

UE dependencyRel-5 HSDPA UE or later.

Impacted counters/KPIsM1002C416 HS-DSCH SETUP FAILURE DUE TO BTS FOR INTERACTIVEM1002C424 HS-DSCH SETUP FAILURE DUE TO BTS FOR BACKGROUNDM1002C584 HS-DSCH SETUP FAILURE DUE TO BTS FOR STREAMINGM1002C636 HS-DSCH SETUP FAILURE DUE TO BTS FOR CS VOICEM1008C218 HS-DSCH SERVING CELL CHANGES FAILED DUE TO BTS


Other-

24 DN09100723


Id:0900d805809d387cConfidential

3.11 E-DPDCH Power Interpolation is used by default RU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:RAN1645: HSUPA 16QAM

The affected legacy features/functionality:Radio bearer setup/reconfiguration with allocation of E-DCH for use on CELL_DCH state

Short descriptionREL7 3GPP specification introduces E-DPDCH power interpolation formula that can be used instead of E-DPCH power extrapolation formula that was used in previous release for E-DCH. Interpolation method gives possibility to optimize HSUPA POs for high bit rates and low bit rates within one set of HSUPA POs.

UE with HSUPA channel configuration can be configured to use E-DPDCH Power Inter-polation method with one set of HSUPA POs regardless of what the output of HSUPA Dynamic Power Offsets algorithm is.

With E-DPDCH Interpolation method UE can get high peak rate without additional reconfiguration of HSUPA POs when the cell UL air interference load goes down. UE using E-DCH interpolation with defined HSUPA POs does not cause high L1 overhead like UE using E-DCH extrapolation method with HSUPA POs defined for high bit rates.

E-DCH power interpolation method is configured by default if it is supported by UE, BTS, and RNC. It has not been configured over Iur, that is the method used is E-DCH power extrapolation whenever E-DCH active set includes cell(s) which is controlled by DRNC.

Expected impactThe expected impact are lower RTWP, better cell throughput in uplink direction, and higher availability of HSUPA peak rate causing better user experience.

During a pilot it was found that WN7.0 BTS indicates about the support of E-DPCH power interpolation by sending E-DPCH Power Boosting Capability IE within NBAP: AUDIT RESPONSE message towards RNC. Because of that, RN7.0 RNC configured WN7.0 to use E-DPCH power interpolation too in case the UE in question supports it. However, the E-DPCH power interpolation is not fully tested with WN7.0. That is why it is recommended to use the E-DPCH power interpolation with WN8.0 only.

Reasoning why the change was made3GPP Rel-7 introduced E-DPDCH power interpolation as a more efficient method. Thanks to this, E-DPDCH power offset set can be optimal simultaneously both for low and high data rates.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic. It is controlled with PRFILE and by default it is in use. It can be set off by setting PRFILE parameter (002:1868) EDPDCHPowerInterUsage to value 1. This should be set off until all BTSs connected to the RNC have been upgraded to WN8.0.


DN09100723 25


Id:0900d805809d387cConfidential

UE dependencyThis is an optional functionality for Rel-7 and newer UEs. The UE indicates its support to RNC in the RRC: RRC CONNECTION SETUP COMPLETE message by including the Support for E-DPDCH power interpolation formula IE within the UE radio access capability IE.

Impacted counters/KPIsM1000C320 - M1000C341M1001C666 - M1001C670M1017C53 - M1017C57

Reference informationHSUPA RRM in RNC FADRNC Counters

Other-

26 DN09100723


Id:0900d805809d3968Confidential

3.12 Core Network Overload handling changeRU40 release where the change will be introducedRU40


The affected legacy features/functionality:CN Overload handling

Short descriptionIn RU40 Core Network (CN) Overload can be controlled with 10 steps. Traffic towards overloaded CN is restricted to as many steps as indicated in RANAP: OVERLOAD message. One step means about 10% restriction of the traffic. Handling of legacy overload timers has not been changed.

Expected impactTraffic can be restricted based on overload level indicated by CN.

Reasoning why the change was madeIn the legacy implementation there were only two steps of CN overload levels. The first step of CN overload could already restrict almost all traffic towards overloaded CN.



UE dependencyNone

Impacted counters/KPIsNo counters are expected to increase.The following counters are expected to decrease (in low CN overload level): M1001C15 RRC_CONN_ACT_FAIL_IU


Other-

DN09100723 27


Id:0900d805809d6cc7Confidential

3.13 UL DCH bit rate upgrade over Iur handling changeRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:PR 105330ESPE04

The affected legacy features/functionality:RAN1231: HSPA Over Iur

Short descriptionIn the RAN1759: I-BTS Sharing feature bit rate upgrade over Iur for RB mapped to DCH/DCH is handled so that if upgrade does not succeed (congestion in DRNC side),then smaller upgrade is not tried right away, but the whole upgrade is retried when next capacity request is received after a short penalty time. The same functionality was used also in HSDPA over Iur case (DCH/HS-DSCH over Iur), although that is not part of the original HSPA over Iur feature.

Thanks to this change, the bit rate upgrade retries are allowed always for DCH/HS-DSCH cases over Iur and that does not depend on the use of the RAN1759: I-BTS Sharing feature.

Expected impactThere is no impact if I-BTS Sharing feature is not in use.

If I-BTS Sharing feature is in use, then:

KPIs indicating user UL DCH bit rates over Iur in DCH/HS-DSCH cases improve. KPIs indicating the amount of RNSAP signaling over Iur worsen.Reasoning why the change was madeThe change (correction) has been made to keep the original HSPA over Iur functionality, also when I-BTS Sharing feature is in use.

Type of change: generic in the SW, license-based or activated by PRFILEGeneric in the SW. There is no PRFILE control.

NE SW versionRN7.0 1.0

UE dependencyNone.

Impacted counters/KPIsM1004C39 RL RECONF PREP SYNCH OVER IUR FOR DCH MOD ON SRNC


Other-

28 DN09100723


Id:0900d80580a27e72Confidential

3.14 Change of HSUPA resource status indication based NRT RB admission control for UEs having a standalone SRB allocation mapped to E-DCHRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:PR 43766ESPE05

The affected legacy features/functionality:RAN973: HSUPA Basic RRM

Short descriptionThe HSUPA admission control of RNC contains many separate AC steps. One AC step is the local cell group level checking of the HSUPA resource status indication whose status is reported by BTS in a Radio Resource Indication message.

The AC step was done for the new E-DCH MAC-d flow established for the first PS NRT RB of the UE. When the status for the LCG was reported as No free EDCH capacity, the setup of the new E-DCH MAC-d flow was not allowed by the AC.

The problem was with the allocation of maximum supported number of HSUPA users to a LCG of the BTS. In cases where all the HSUPA HW capacity was consumed in a LCG, the setup of new E-DCH MAC-d flow was no longer possible for the PS NRT RB, as BTS reported to RNC in such case that there is no free E-DCH capacity in a HSUPA resource status indication.

When UE was having the E-DCH MAC-d flow established only for the standalone SRB, the setup of the E-DCH MAC-d flow was not possible for the PS NRT RB of the UE as admission control denied it for the received HSUPA resource status indication.

This caused that the maximum number of HSUPA NRT users, which was the specified capacity of the BTS HSUPA HW configuration, was not possible to allocate. UE that already has the E-DCH MAC-d flow established for SRB does not require any additional HW resources from the BTS over the minimum reservation when the E-DCH MAC-d flow is established for the PS NRT bearer.

To solve this problem, the handling of the HSUPA resource status indication in the admission control has been changed. In instances where the E-DCH MAC-d flow is already established for the SRB of UE, the setup of the E-DCH MAC-d flow for the new PS NRT RB is allowed. This makes it possible to allocate the maximum supported HSUPA NRT user amount in an LCG level.

Expected impactHSUPA accessibility can be increased. The change is expected to be really marginal, however, and therefore no impact is seen.

Reasoning why the change was madeThis change allows to use the maximum HSUPA HW capacity in a BTS. No negative impacts come with it as it corrects a design flaw.


NE SW version

DN09100723 29


Id:0900d80580a27e72Confidential

RN7.0 1.0

UE dependencyNone

Impacted counters/KPIsSome BTS configurations might have lower number of HSUPA AC rejections due to BTS HW limitation. This is seen from the following counters (lower value expected):

M1002C517 UL_DCH_SEL_BTS_HW_INT M1002C518 UL_DCH_SEL_BTS_HW_BGR Reference information-

Other-

30 DN09100723


Id:0900d80580a23a8eConfidential

Parameter changes

4 Parameter changes

4.1 The FP max frame size on IurRU40 release where the change will be introducedRU40

Relation to features or correctionsGeneric parameter harmonization with mcRNC.

Short descriptionA parameter in RNW database is changed. The former RNC/IUR - maxHSDPAFPSizeForATMIur (Maximum HS-DSCH FP size for ATM Iur) is replaced with RNC/IUR - MaxFPDLFrameSizeIur (Maximum FP downlink frame size Iur). During RU30 to RU40 SW upgrade, the value of the old parameter is automatically transferred by the RNW Database conversion program to the new parameter.


Reasoning why the change was madeThe original parameter name and description were not proper and they were also slightly misleading. The parameter had ATM mentioned in the name even though it was applied on IP Iur interfaces as well. Changing the name to equal to mcRNCs relevant parameter makes the Iur configuration between different RNC variants more straightfor-ward.

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


UE dependencyNone


Reference informationWCDMA Radio Network Configuration Parameters

Other-

DN09100723 31



4.2 Iu parameters moved to correct object level in RNW databaseRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:Internal improvement


Short descriptionThere are several IU Operator-related parameters that are located in incorrect object level in legacy implementation. They are moved to correct object level, that is new parameters are defined in correct radio network objects and the replaced parameters are removed. RNW DB conversion program takes care of these parameter changes in legacy networks.

The following parameters are in practice IU Operator specific parameters and are thus moved from IUCS and IUPS objects to IUO:

1. RNC/IUCS-IuBarringDelayTimerCS is replaced by RNC/IUO- IuBarringDelayTimerCS.

2. RNC/IUCS-IuBarringRecoveryGroupCS is replaced by RNC/IUO- IuBarringRecoveryGroupCS.

3. RNC/IUCS-IuBarringRecoveryTimer is replaced by RNC/IUO- IuBarringRecoveryTimerCS.

4. RNC/IUPS-IuBarringDelayTimerPS is replaced by RNC/IUO- IuBarringDelayTimerPS.

5. RNC/IUPS-IuBarringRecoveryGroupPS is replaced by RNC/IUO- IuBarringRecoveryGroupPS.

6. RNC/IUPS-IuBarringRecoveryTimer is replaced by RNC/IUO- IuBarringRecoveryTimerPS.

7. RNC/ IUCS - CNDRXLength is replaced by RNC/IUO-CSCNDRXLength.8. RNC/ IUPS - CNDRXLength is replaced by RNC/IUO-PSCNDRXLength.9. RNC/ IUPS - PS_NMO is replaced by RNC/IUO-PS_NMO.10. RNC/IUCS- CS_T3212 is replaced by RNC/IUO - CS_T3212.Conversion Rules:

1. RNW DB conversion copies IUCS - IuBarringDelayTimerCS parameter value present in the smallest Managed Object ID (IUCS) to IUO-IuBarringDelayTimerCS having the same PLMN id.

2. RNW DB conversion copies IUCS - IuBarringRecoveryGroupCS parameter value present in the smallest Managed Object ID (IUCS) to IUO- IuBarringRecoveryGroupCS having the same PLMN id.

3. RNW DB conversion copies IUCS - IuBarringRecoveryTimer parameter value present in the smallest Managed Object ID (IUCS) to IUO- IuBarringRecoveryTimerCS having the same PLMN id.

32 DN09100723



4. RNW DB conversion copies IUPS - IuBarringDelayTimerPS parameter value present in the smallest Managed Object ID (IUPS) to IUO- IuBarringDelayTimerPS having the same PLMN id.

5. RNW DB conversion copies IUPS - IuBarringRecoveryGroupPS parameter value present in the smallest Managed Object ID (IUPS) to IUO- IuBarringRecoveryGroupPS having the same PLMN id.

6. RNW DB conversion copies IUPS - IuBarringRecoveryTimer parameter value present in the smallest Managed Object ID (IUPS) IUO- IuBarringRecoveryTimerPS having the same PLMN id.

7. RNW DB conversion copies IUCS - CNDRXLength parameter value present in the smallest Managed Object ID (IUCS) to IUO- CSCNDRXLength having the same PLMN id. If RNFCMOCNEnabled parameter is set as enabled, then RNW DB Con-version sets the same value of IUO- CSCNDRXLength among all IU Operators.

8. RNW DB conversion copies IUPS - CNDRXLength parameter value present in the smallest Managed Object ID (IUPS) to IUO- PSCNDRXLength having the same PLMN id. If RNFCMOCNEnabled parameter is set as enabled, then RNW DB Con-version sets the same value of IUO- PSCNDRXLength among all IU Operators.

9. RNW DB conversion copies IUPS - PS_NMO parameter value present in the smallest Managed Object ID (IUPS) to IUO- PS NMO having the same PLMN id. If RNFC-MOCNEnabled parameter is set as enabled, then RNW DB Conversion sets the same value of IUOPS_ NMO among all IU Operators.

10. RNW DB conversion copies IUCS - CS_T3212 parameter value present in the smallest Managed Object ID (IUCS) to IUO- CS T3212 having the same PLMN id. If RNFC-MOCNEnabled parameter is set as enabled, then RNW DB Conversion sets the same value of IUO- CS_T3212 among all IU Operators.

The following parameter is in practice RNC-specific parameter and is thus moved from IUCS object to RNC object:IUCS - CSAttachDetachAllowed is replaced by RNC- CSAttachDetachAllowed.Conversion Rule:RNW DB conversion copies IUCS - CSAttachDetachAllowed parameter value present in the smallest Managed Object ID (IUCS) to RNC- CSAttachDetachAllowed.Expected impactNo impact to KPIs is expected.

Reasoning why the change was madeThese parameters are moved from Iu interface level to Iu Operator.level. There is no point to define values for them per each Iu interface separately as in practice they need to have similar values in Iu interfaces of a specific IU Operator. Violating this rule in the legacy implementation may cause severe consequences like call drops. With this change this kind of invalid Iu configurations are eliminated, and in general there are less parameters in Iu interface for user to consider as these are moved to upper level in managed object hierarchy.

The addressed Iu Link Break Protection mechanism parameters are IU Operator (IUO) specific parameters. IU Link protection mechanism works only when all the CN nodes for certain domain are all non-functional.

CNDRXLength parameters are IU Operator (IUO) specific parameters.

DN09100723 33



PS_NMO and CS_T3212 timer are IU Operator (IUO) specific parameters.CSAttachDetachAllowed Configuration is an RNC specific parameter.Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic.


UE dependencyNone


Reference informationCustomer Documentation; WCDMA Radio Network Configuration Parameters

Other-

34 DN09100723


Id:0900d805809f61cbConfidential

4.3 PLMNId related configuration changes in Iu and Iu-Bc interfacesRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:Internal Improvement


Short descriptionMapping of IU Operator and PLMNId parameters to IUCS, IUPS and CBCI objects are changed. In legacy implementation PLMNId of IUCS, IUPS, and CBCI are used to link these interface objects to IU Operator (IUO). IUCS, IUPS and CBCI are now mapped to correct IU Operator (IUO) via new IUOId parameter, and PLMNId is removed from inter face objects. IU Operators PLMNId will be defined only in IUO object and thus it is now mandatory to have at least one IUO object created in the RNC. RNW DB conversion program takes care of these parameters new mappings and potential IUO Objectcre ation in legacy networks.

1. RNC/IUCS -GlobalCNId PLMNid has been replaced by RNC/IUCS/IUOIdentifier.

2. RNC/IUPS -GlobalCNId PLMNid has been replaced by RNC/IUPS/IUOIdentifier.

3. RNC/CBCI -CBCPLMNId has been replaced by RNC/CBCI IUOIdentifier.4. RNC/IUCS -GlobalCNId -CNId has been replaced by RNC/IUCS-CNId.5. RNC/IUPS -GlobalCNId -CNId has been replaced by RNC/IUPS-CNId.6. WCEL-WCELCSCNId and WCEL-WCELPSCNId have been removed.Conversion rules:

1. During upgrade RNW DB conversion program matches IUCS-GlobalCNId- PLMNid with IUO-PLMNid and fills the corresponding IUO-IUOid in IUCS-IUOIdentifier.

2. During upgrade RNW DB conversion program matches IUPS-GlobalCNId- PLMNid with IUO-PLMNid and fills the corresponding IUO-IUOid in IUPS-IUOIdentifier.

3. During upgrade RNW DB conversion program matches CBCI-CBCPLMNId with IUO-PLMNid and fills the corresponding IUO-IUOid in CBCI-IUOIdentifier.

4. During upgrade RNW DB conversion program copies IUPS-GlobalCNId -CNId into RNC/IUPS -CNId.

5. During upgrade RNW DB conversion program copies IUCS-GlobalCNId -CNId into RNC/IUCS -CNId.

6. During upgrade RNW DB conversion program copies IUPS-GlobalCNId -CNId into RNC/IUPS -CNId.

In addition, if operator uses Basic RNC functionality and has not configured IUO object in RNW Database, then during upgrade RNW DB conversion program internally creates a single instance of IUO object with IUOid as 1.

DN09100723 35



The following parameters are copied from IUCS/IUPS object to IUO instance:

IUCS-GlobalCNId -MCC to IUO-PLMNId-MCC (for IPA RNC and mcRNC) IUCS-GlobalCNId -MNC to IUO-PLMNId-MNC (for IPA RNC and mcRNC) IUCS-GlobalCNId -MNCLength to IUO-PLMNId-MNCLength (for IPA RNC

andmcRNC) IUPS-GlobalCNId -MCC to IUO-PLMNId-MCC (for Flexi Direct RNC) IUPS-GlobalCNId -MNC to IUO-PLMNId-MNC (for Flexi Direct RNC) IUPS-GlobalCNId -MNCLength to IUO-PLMNId-MNCLength (for Flexi Direct

RNC)

Exception handling:

1. There might have been IUO object(s) in RU30 defined with default PLMNIds (= MCC/MNC=65535). Such idle IUO objects with default PLMNIds are not needed anymore in RU40 and they do not cause functional problems, but for clarity reasons operator should remove these idle IUOs from RNW DB.

2. In RU30 CBCI CBCPLMNId should always belong to one operator only, that is there should be one CBCI-CBCPLMNId only. If CBCI CBCPLMNId is still mapped to several IUO-PLMN ids in RU30, then during upgrade RNW DB conversion program fills IUOid in CBCI-IUOIdentifier corresponding to the first PLMNId in CBCI-CBCPLMNId list.


Reasoning why the change was madeTarget of these changes have been to clarify and simplify the mapping of Iu and Iu-Bc interfaces to the IU Operator. In legacy implementation this mapping is done via PLMNId parameter which has been defined in IUO, IUCS,IUPS and CBCI objects. This is now simplified as PLMNId is only in IUO object and user may configure IU interface with the same logic in all feature combinations, for example with or without RAN Sharing there must be always at least one IUO Object with valid Iu Operator specific parameters. In addition, some Iu parameters that are no more used in our solutions are removed. PPLMNId of IU Operator is now defined only in one place, that is in IUO object, and Iu& Iu-Bc interface objects are associated to correct IU Operator (IUO) with a new IUOIdentifier parameter.PLMNId is defined in IUO object only and thus IUCS-GlobalCNId and in IUPS-Global-CNIds are removed. Local CNId is still needed as an interface identifier and thus new parameters IUCS-CNId and IUPS-CNId are defined.Type of change: generic in the SW, license-based or activated by PRFILEThe change is generic.


UE dependencyImpacted counters/KPIs-

Reference informationCustomer Documentation: WCDMA Radio Network Configuration Parameters

36 DN09100723



Other-

DN09100723 37



4.4 Configuration of FlexiIuWeight parameters for IUCS and IUPSRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:Internal improvement


Short descriptionNew parameters CSFlexiIuWeigth and PSFlexiIuWeigth are introduced in IUCS and IUPS object respectively. Currently, the number of NRIs configured to each CN node determines the weight of the node in Flexible Iu load sharing. This mechanism of using number of NRIs for load sharing is replaced by adding new CSFlexiIuWeigth parameter to each IUCS and PSFlexiIuWeigth to each IUPS object which is to be used for load sharing purposes by RANAP entity. The weight value used in load sharing decision is weight value of CN node divided by sum of all weight values of CN nodes for the domain of one operator.

RNW DB conversion program takes care of these parameter changes in legacy net-works.

Conversion Rule:During upgrade RNW DB conversion program maps the relative weight values used in Flexi Iu load sharing which is currently based on number of NRIs configured for IUCSand IUPS object to CSFlexiIuWeigth and PSFlexiIuWeigth parameters. The conversion counts the sum of number NRIs configured for each domain and operator. The sum is used to provide relative operator/domain specific weight of IUCS/IUPS object by counting the number of NRIs configured to object and dividing the number of NRIs with sum of NRIs. The relative value is then multiplied with 100 and rounded to nearest integer. The values less than 0.5 percent are set to zero. The generated values are filled to CSFlexiIuWeigth and PSFlexiIuWeigth parameters.

Example: The following information is mentioned in IUCS/IUPS object.

IUCS-1

Min NRI Max NRI Count

0 1 2

100 200 101

1023 1024 1

SUM 104

Table 1 IUCS-1 calculations

38 DN09100723



Flex IU weight for IUCS-1:

104/(104+295)*100=26

Flex IU weight for IUCS-2:

295/(104+295)*100=74


Reasoning why the change was madeThe legacy configuration to use number of NRIs for Flexible Iu load sharing is complex and the target of the change is to simplify the configuration without reducing any load sharing functionality.



UE dependencyNone


Reference informationCustomer Documentation; WCDMA Radio Network Configuration Parameters

Other-

IUCS-2

Min NRI Max NRI Count

201 201 1

202 495 294

SUM 295

Table 2 IUCS-2 calculations

DN09100723 39



4.5 Configurable QoS markingRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:RAN2448: Configurable QoS Marking


Short descriptionGeneric attribute naming related the Iu-PS interface GTP ECHO DSCP marking has been changed. Attribute name RNTRM - SignallingToDSCP has changed to RNTRM - DSCPForGTPSignalling.Expected impactParameter name change does not affect KPIs and it improves the operability.

Reasoning why the change was madeThe old parameter name caused confusion. New parameter name better describes the purpose.


NE SW versionRNC RN7.0, mcRNC3.0, and ADA5.0

UE dependencyNone



Other-

40 DN09100723



4.6 Default value of the EDCHMACdFlowThroughputTime-toTrigger is changedRU40 release where the change will be introducedRU40


The affected legacy features/functionality:E-DCH inactivity detection

Short descriptionThe default value of parameter EDCHMACdFlowThroughputTimetoTrigger defining E-DCH inactivity time is aligned with the HS-DSCH inactivity time. In RU30HSDSCH uses time-to-trigger value 0 s (default) for the low utilization (data inactivity) measurement, whereas E-DCH uses 5 s (default) time-to-trigger for the low throughput (data inactivity) measurement. After this change in RU40, HSPA (HS-DSCH & E-DCH) inactivity takes approximately 3 s (Averaging Window + Time-to-Trigger) before Cell_DCH to CCH state transition.

This change of the default value is effective only when creating a new WAC object in the RU40 RNC radio network database. When upgrading the RNC from RU30 SW to RU40 SW, the value of EDCHMACdFlowThroughputTimetoTrigger is not changed but previous value is preserved during the RNW database conversion. If the operator wants to take the new value into use in RU40 after the release upgrade, that can be done by editing EDCHMACdFlowThroughputTimetoTrigger in WAC object.In RU30 parameter EDCHMACdFlowThroughputTimetoTrigger was in RNHSPA object, but it has been moved to WAC object in RU40. WAC is linked to WCEL with parameter WCEL->WACSetIdentifier.Expected impactHHSPA accessibility KPIs are improved as inactive HSPA users are released faster and the dedicated resources are available sooner for other users.

Reasoning why the change was madeE-DCH inactivity time was aligned with the HS-DSCH inactivity time. Faster transition of inactive users to CCH state releases resources for other users, which improves HSPA accessibility.

Type of change: generic in the SW, license-based or activated by PRFILEThe change is valid in SW only if operator uses HSUPA. The change cannot be con-trolled by feature on/off switch or a license.


UE dependencyRel6 HSUPA

Impacted counters/KPIsHSUPA Setup Success Ratio from user perspective (RNC_915c)HSUPA Resource Accessibility for NRT Traffic (RNC_913b)

DN09100723 41




Other-

42 DN09100723



4.7 PRFILE parameters replaced by new Radio Network database parametersRU40 release where the change will be introducedRU40

Relation to features or correctionsFeature/fault correction introducing the change:RAN2852: Terminal Battery Drain Prevention in Cell BroadcastRAN2124: HSPA 128 Users Per CellRAN2494: Fast Cell_PCH SwitchingIFHO Over Iur Enhancements

RAN2830-2831: AMR with DCH 0/0 Support on Iur


Short descriptionThe following management parameters which were implemented and stored in PRFILE are replaced by new Radio Network database parameters:

RAN2852: Terminal Battery Drain Prevention in Cell Broadcastbit1 of PRFILE parameter RN60_INT_FEAT_RES_05 -> WBTS-WCEL-OffsetToBeginCTCHBSIndexRAN2124: HSPA 128 Users Per Cell EFSbit1 of PRFILE parameter RN60_MAINT_37 -> WBTS-WCEL-RsrvdSignaturesOffsetRAN2494: Fast Cell_PCH Switchingbit1 of PRFILE parameter pr_nr_t_rn40_maint_037 -> RNFC-DCHtoPCHEnabledIFHO Over Iur Enhancementsbit1 of PRFILE parameter RN60_MAINT_19 -> RNFC-IFHOOverIurExtRAN2830-2831: AMR with DCH 0/0 Support on Iur bits 0 and 1 of PRFILE parameter 002:1937 -> RNFC-DCH00SuppOnIurEnabledDuring the RNC SW upgrade database conversion program initialize values of these new database parameters based on the legacy parameter values in PRFILE, and thus, there is no user actions expected thanks to this change. This is because the functional-ities managed through these parameters continue similarly as they were configured before the RNC SW upgrade.


Reasoning why the change was madeOperability of these functionalities is improved by providing OMS and NetAct parameter management interface for the impacted functionalities. In addition, management of some of the impacted functionalities is changed from RNC level to WCEL level. In such cases, when impacted functionality in RU30 has been activated in RNC level via PRFILE parameter, RNC automatically activates the functionality to all WCELs of the RNC. Thus, after the RU40 upgrade, the user is able to control the functionality on WCEL level.

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

DN09100723 43



The change is generic in IPA RNC.


UE dependencyNone.



Other-

44 DN09100723


Id:0900d80580a23be9Confidential

4.8 IPQM object id for IuCS/IuPSRU40 release where the change will be introducedRU40

Relation to features or correctionsRelated to the reorganization of the references connected with Iu interface IP transport at radio network configuration.

Short descriptionIUPSIP and IUCSIP object class attribute IPQMIdPS/IPQMIdCS value range has been changed to 1..8. The RU30 level IPQMId default value 0 is no more included in the parameter value range. In the new RU40 implementation it is mandatory to create the IPQM instance first before the related IPQMId reference can be filled in within the IUPSIP and IUCSIP instances. The IPQM instances and related references should be configured according to new operation logics before the release upgrade.


Reasoning why the change was madeThe new operation mode requires explicit configuration of the IPQM instance and related references. This ensures that the system default DSCP mapping at Iu interface is not applied by accident, but it is always based on the operator planning and configu-ration.

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


UE dependencyNone



Other-

RNC Generic Algorithm Changes and Impact on Counters and KPIsTable of contentsList of tablesSummary of changes1Introduction to RU40 algorithm changes and impact on counters and KPIs2Counter changes2.1Increase of M1001C107 and M1001C112 RAB_STP_FAIL_PS_xxx_RNC2.2M1006C211 increase and M1006C212 decrease2.3Increase of RAB active failures due to Iu

3Algorithm changes3.1SAB feature activation logic changes3.2MBLB is extended to support DB-DC-HSDPA3.3Channel type switch in case of RRC connection re-establishment for CS voice over HSPA3.4RNC Performance Improvement Due to L2 Call Configuration Optimization3.5DMPG Switch UL Data Loss Prevention3.6RRM defines MAC logical channel priorities for the radio bearers3.7Direct HSPA allocation for CS voice in target side during inter RNC inter-frequency handover and blind inter-frequency handover in RAB setup phase3.8Direct state transition from Cell_DCH to Cell_PCH for DCH/DCH configuration 3.9The load-based E-DCH 2 ms TTI prevention of the RAN2879: Mass Event Handler feature is applied in the PIC cell3.10Checking of HSDPA user amounts against LCG and BTS specific user capacity indicated by BTS3.11E-DPDCH Power Interpolation is used by default 3.12Core Network Overload handling change3.13UL DCH bit rate upgrade over Iur handling change3.14Change of HSUPA resource status indication based NRT RB admission control for UEs having a standalone SRB allocation mapped to E-DCH

4Parameter changes4.1The FP max frame size on Iur4.2Iu parameters moved to correct object level in RNW database4.3PLMNId related configuration changes in Iu and Iu-Bc interfaces4.4Configuration of FlexiIuWeight parameters for IUCS and IUPS4.5Configurable QoS marking4.6Default value of the EDCHMACdFlowThroughputTimetoTrigger is changed4.7PRFILE parameters replaced by new Radio Network database parameters4.8IPQM object id for IuCS/IuPS

Rnc Gen Alg Changes

Documents

Transcript of Rnc Gen Alg Changes