Você está na página 1de 94

RNC Generic Algorithm

Changes and Impact on


Counters and KPIs
DN09100723
Issue 05A
Approval Date 2017-04-04

 
RNC Generic Algorithm Changes and Impact on Counters and KPIs

The  information  in  this  document  applies  solely  to  the  hardware/software  product  (“Product”)  specified
herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective
company within Nokia Group of Companies with whom you have entered into the Agreement (as defined
below).

This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the
purposes  defined  in  the  agreement  between  You  and  Nokia  (“Agreement”)  under  which  this  document  is
distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form
or  means  without  the  prior  written  permission  of  Nokia.  If  You  have  not  entered  into  an  Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this
document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof.

The  document  has  been  prepared  to  be  used  by  professional  and  properly  trained  personnel,  and  You
assume  full  responsibility  when  using  it.  Nokia  welcomes  your  comments  as  part  of  the  process  of
continuous development and improvement of the documentation.

This  document  and  its  contents  are  provided  as  a  convenience  to  You.  Any  information  or  statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an  “as  is”  and  “as  available”  basis  in  this  document,  and  Nokia  reserves  the  right  to  change  any  such
information  and  statements  without  notice.  Nokia  has  made  all  reasonable  efforts  to  ensure  that  the
content  of  this  document  is  adequate  and  free  of  material  errors  and  omissions,  and  Nokia  will  correct
errors  that  You  identify  in  this  document.  Nokia's  total  liability  for  any  errors  in  the  document  is  strictly
limited to the correction of such error(s). Nokia does not warrant that the use of the software in the Product
will be uninterrupted or error-free.

NO  WARRANTY  OF  ANY  KIND,  EITHER  EXPRESS  OR  IMPLIED,  INCLUDING  BUT  NOT  LIMITED  TO
ANY  WARRANTY  OF  AVAILABILITY,  ACCURACY,  RELIABILITY,  TITLE,  NON-INFRINGEMENT,
MERCHANTABILITY  OR  FITNESS  FOR  A  PARTICULAR  PURPOSE,  IS  MADE  IN  RELATION  TO  THE
CONTENT  OF  THIS  DOCUMENT.  IN  NO  EVENT  WILL  NOKIA  BE  LIABLE  FOR  ANY  DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR  ANY  LOSSES,  SUCH  AS  BUT  NOT  LIMITED  TO  LOSS  OF  PROFIT,  REVENUE,  BUSINESS
INTERRUPTION,  BUSINESS  OPPORTUNITY  OR  DATA  THAT  MAY  ARISE  FROM  THE  USE  OF  THIS
DOCUMENT  OR  THE  INFORMATION  IN  IT,  EVEN  IN  THE  CASE  OF  ERRORS  IN  OR  OMISSIONS
FROM THIS DOCUMENT OR ITS CONTENT.

This document is Nokia proprietary and confidential information, which may not be distributed or disclosed
to any third parties without the prior written consent of Nokia.

Nokia  is  a  registered  trademark  of  Nokia  Corporation.  Other  product  names  mentioned  in  this  document
may be trademarks of their respective owners.

Copyright © 2017 Nokia. All rights reserved.

f Important Notice on Product Safety


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

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

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

2 © 2017 Nokia DN09100723 Issue: 05A
RNC Generic Algorithm Changes and Impact on Counters and KPIs

Table of Contents
This document has 94 pages
   
Summary of changes..................................................................... 7
   
1 Introduction to RNC Generic Algorithm Changes and Impact on
Counters and KPIs....................................................................... 12
   
2 Algorithm changes....................................................................... 13
2.1 Releasing RRC connection when RNC has not received IMSI from
core network.................................................................................13
2.2 New license for mcRNC signaling capacity .................................14
2.3 IP Based Route load sharing source IP address selection for
common channels........................................................................ 17
2.4 Maximum number of HS(D)PA Users per cell.............................. 18
2.5 HSRACH overload control functionality....................................... 20
2.6 Change in measuring RAB setup time......................................... 21
2.7 New calculation of HSPA subscribers per cell..............................22
2.8 Capacity reservation for Cell_DCH state HSPA users and
prioritization of HSPA users over HS Cell_FACH users............... 23
2.9 Selection of RAN2172 IFHO trigger counter................................ 25
2.10 Network resiliency for mcRNC..................................................... 26
2.11 License control for mcRNC 10 Gbps Ethernet interfaces............ 26
2.12 Removal of support for the HSDPA static resource allocation..... 27
2.13 PDCP Buffer full packet drop from head of the PDCP queue...... 29
2.14 Replacement of SBTS BTSOM interface with NBAP for RNC
communication............................................................................. 30
2.15 Updating M568C15 IP_EG_BW_CONFIG when IFC is disabled....
30
2.16 Handling of Iu release commands with Out Of UTRAN IE...........31
2.17 RNC ignores SDU Error Ratio and Residual Bit Error Ratio
parameters in RAB modification message................................... 33
2.18 Enhance O&M secure connection algorithms between MCRNC
and OMS...................................................................................... 33
2.19 Support of IMSI and IMEI information elements via Iupc............. 34
2.20 Cancelable HSPA+ post reconfiguration task.............................. 35
2.21 Change to RAN2302 Dynamic HSUPA BLER use with RAN1645
HSUPA 16QAM............................................................................ 37
2.22 Correction to HS-DSCH channel type switch guard timer handling
when RB is mapped to 0/0........................................................... 38
2.23 HSUPA 2 ms TTI and/or F-DPCH can be allocated even if RACH
measurement result is missing.....................................................39
2.24 F-DPCH allocation based on calculated EcNo if RACH
measurement result missing........................................................ 41
2.25 HSUPA E-TFCI amplitude ratio reference point and power offset
optimization to avoid usage of E-TFCI 124 in particular scenarios..
42

DN09100723 Issue: 05A © 2017 Nokia 3
RNC Generic Algorithm Changes and Impact on Counters and KPIs

2.26 Incorrect AC decision for NRT RB when channel type switch to
HSPA was performed................................................................... 44
2.27 Correction of activation time in coincidence of IMEI query and
serving cell change...................................................................... 46
2.28 E-UTRA Capability Enquiry Changes.......................................... 47
2.29 Activation time increase if unsent PDUs in RLC buffer ............... 49
2.30 CM activation time correction.......................................................50
2.31 HS-DSCH/E-DCH setup with "dummy" PS RAB reconfiguration
from PS CN corrected.................................................................. 52
2.32 RAN2980 Measurement Based LTE Layering Change for
Handling CS Call Release without PS RAB................................. 53
2.33 RRC unit overload control incorrectly interprets slowness in RL
setup as ICSU load...................................................................... 54
2.34 RRC unit overload control incorrectly interprets radio resources
congestion as ICSU load..............................................................55
2.35 Improvement to NRT DCH Scheduling for Iur Capacity Requests...
56
2.36 Paging Cell PCH SR degraded after DMCU resource release.... 58
2.37 NBL Process priority change to avoid message que accumulation
during high traffic load in ICSU.....................................................59
2.38 Correction to premature E-DCH release due to triggered CM
measurement cause.....................................................................60
2.39 Frequency merge is not allowed in RAN2991..............................61
2.40 Removal of DMPG switch procedure for cell_fach (HS) to cell_dch
state transitions............................................................................ 62
2.41 Incorrect UL NRT DCH bitrate limitation for HSDPA RB in DRNC
RL.................................................................................................63
2.42 UL Interference correction for RAN3086 CSFB with RIM............ 64
2.43 Correction to decoding of TFCS from RRC container in incoming
HHO............................................................................................. 65
2.44 AMR CDR degraded due to incorrect calculation of TGCFN during
anchoring CM after IFHO over Iur................................................66
   
3 Counter changes..........................................................................68
3.1 Correction to failed incoming inter-RAT handovers and its impact
on counters and KPIs...................................................................68
3.2 Corrected value of Counter M1005C252 MAC-D SETUP
ATTEMPT FOR DC-HSDPA when Secondary Serving HS-DSCH
is removed from a call.................................................................. 70
3.3 Sending of RB mappings to UE corrected in state transition from
cell PCH state (Rel99 cell) to cell FACH state (HS-FACH/HS-
RACH capable cell)......................................................................71
3.4 Counters M1006C229 and M1006C196 update added in PCH-
DCH state transition while MBLB attempted................................ 73
3.5 Cell UPDATE Failure Rate KPI Change.......................................73
3.6 Correction to M1007 CPICH EcN0 Class counter degradation in
WCDMA16................................................................................... 74
3.7 Decrease in HSDPA and HSUPA IFHO Compressed Mode (CM)
counters....................................................................................... 76
3.8 Correction to counter update during unsuccessful SRNS
relocation caused by CN.............................................................. 77

4 © 2017 Nokia DN09100723 Issue: 05A
RNC Generic Algorithm Changes and Impact on Counters and KPIs

3.9 Workaround for UEs which do not send START value after CS call
re-establishment...........................................................................78
3.10 Packet Loss after AMR Re-establishment due to Old HFN Used
by RNC.........................................................................................79
3.11 UE DPCCH DTX Capability Is Not Updated to Counter and KPI for
UEs that Arrive to RNC via Incoming ISHO................................. 80
3.12 Excluding RABs already being released from RAB re-
establishment counter updating................................................... 81
3.13 UL DCH rejection counter (for example: M1002C401,
M1002C402) pegging correction during state transition.............. 82
3.14 Cell-based Maximum Bit Rate Limitation for NRT DCH Is Also
Used for RL Allocations in DRNC................................................ 83
   
4 Alarm changes............................................................................. 86
4.1 SIGTRAN alarm improvements....................................................86
4.2 Additional 7761 alarms raised during NBAP link break................87
4.3 Alarm 3295 raised for signaling capacity control on mcRNC....... 88
   
5 Parameter changes......................................................................90
5.1 Minimum reduced E-DPDCH gain factor..................................... 90
5.2 RACH and HS-RACH preamble signatures parameter change...91
5.3 New category for Obsolete Parameters....................................... 92
5.4 Removal of IBFD parameter alarmEnabled and replacement of
parameter bfdEnabled............................................................. 93

DN09100723 Issue: 05A © 2017 Nokia 5
RNC Generic Algorithm Changes and Impact on Counters and KPIs

List of Tables
Table 1 SBHCA counters................................................................................ 15
Table 2 SIGTRAN alarm mapping...................................................................86

6 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Summary of changes
Counters and KPIs

Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.

Changes between issues 04A (2016-10-26, WCDMA16 MP4.0) and 05A (2017-03-03,
WCDMA16 MP5.0; 2017-04-04, WCDMA16 MP5.0 P8)

UE DPCCH DTX Capability Is Not Updated to Counter and KPI for UEs that Arrive
to RNC via Incoming ISHO
• UE DPCCH DTX Capability Is Not Updated to Counter and KPI for UEs that Arrive to
RNC via Incoming ISHO has been added.

AMR CDR degraded due to incorrect calculation of TGCFN during anchoring CM


after IFHO over Iur
• AMR CDR degraded due to incorrect calculation of TGCFN during anchoring CM
after IFHO over Iur has been added.

Packet Loss after AMR Re-establishment due to Old HFN Used by RNC
• Packet Loss after AMR Re-establishment due to Old HFN Used by RNC has been
added.

E-UTRA Capability Enquiry Changes


• E-UTRA Capability Enquiry Changes has been modified to clarify that even if DCH
3.4 kbit/s SRB is allocated the E-UTRA capabilities are still requested.

Improvement to NRT DCH Scheduling for Iur Capacity Requests


• Improvement to NRT DCH Scheduling for Iur Capacity Requests has been modified
to reflect new counters affected.

Cell-based Maximum Bit Rate Limitation for NRT DCH Is Also Used for RL
Allocations in DRNC
• Cell-based Maximum Bitrate Limitation for NRT DCH is used also for RL Allocations
in DRNC has been added.

Correction to decoding of TFCS from RRC container in incoming HHO


• Correction to decoding of TFCS from RRC container in incoming HHO has been
added.

UL DCH rejection counter (for example: M1002C401, M1002C402) pegging


correction during state transition
• UL DCH rejection counter (for example: M1002C401, M1002C402) pegging
correction during state transition has been added.

Excluding RABs already being released from RAB re-establishment counter


updating

DN09100723 Issue: 05A © 2017 Nokia 7
   

Summary of changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

• Excluding RABs already being released from RAB re-establishment counter updating
has been added.

UL Interference correction for RAN3086 CSFB with RIM


• UL Interference correction for RAN3086 CSFB with RIM has been added.

Workaround for UEs which do not send START value after CS call re-
establishment
• Workaround for UEs which do not send START value after CS call re-establishment
has been added.

Incorrect UL NRT DCH bitrate limitation for HSDPA RB in DRNC RL


• Incorrect UL NRT DCH bitrate limitation for HSDPA RB in DRNC RL has been
added.

Removal of DMPG switch procedure for cell_fach (HS) to cell_dch state transitions
• Removal of DMPG switch procedure for cell_fach (HS) to cell_dch state transitions
has been added.

Correction to counter update during unsuccessful SRNS relocation caused by CN


• Correction to counter update during unsuccessful SRNS relocation caused by CN
has been added.

Decrease in HSDPA and HSUPA IFHO Compressed Mode (CM) counters.


• Decrease in HSDPA and HSUPA IFHO Compressed Mode (CM) counters. has been
added.

Alarm 3295 raised for signaling capacity control on mcRNC


• Alarm 3295 raised for signaling capacity control on mcRNC has been added.

Frequency merge is not allowed in RAN2991


• Frequency merge is not allowed in RAN2991 has been added.

Changes between issues 03H (2016-08-11, WCDMA16 MP3.0) and 04A (2016-10-26,
WCDMA16 MP4.0)

Correction to premature E-DCH release due to triggered CM measurement cause


• Correction to premature E-DCH release due to triggered CM measurement cause
has been added.

Correction to M1007 CPICH EcN0 Class counter degradation in WCDMA16


• Correction to M1007 CPICH EcN0 Class counter degradation in WCDMA16 has
been added.

RRC unit overload control incorrectly interprets slowness in RL setup as ICSU


load

8 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Summary of changes
Counters and KPIs

• RRC unit overload control incorrectly interprets slowness in RL setup as ICSU load
has been added.

NBL Process priority change to avoid message que accumulation during high
traffic load in ICSU
• NBL Process priority change to avoid message que accumulation during high traffic
load in ICSU has been added.

Cell UPDATE Failure Rate KPI Change


• Cell UPDATE Failure Rate KPI Change has been added.

Paging Cell PCH SR degraded after DMCU resource release


• Paging Cell PCH SR degraded after DMCU resource release has been added.

Improvement to NRT DCH Scheduling for Iur Capacity Requests


• Improvement to NRT DCH scheduling for Iur capacity requests has been added.

RRC unit overload control incorrectly interprets radio resources congestion as


ICSU load
• RNC unit overload control incorrectly interprets radio resources congestion as ICSU
load has been added.

Changes between issues 03G (2016-06-22, WCDMA16 MP3.0) and 03H (2016-08-11,
WCDMA16 MP3.0)

RAN2980 Measurement Based LTE Layering Change for Handling CS Call Release
without PS RAB
• RAN2980 Measurement Based LTE Layering change for handling CS call release
without PS RABNew has been added.

RRC unit overload control incorrectly interprets slowness in RL setup as ICSU


load
• RRC unit overload control incorrectly interprets slowness in RL setup as ICSU load
has been added.

Changes between issues 03F (2016-06-17, WCDMA16 MP3.0) and 03G (2016-06-22,
WCDMA16 MP3.0)

Activation time increase if unsent PDUs in RLC buffer


• Activation time increase if unsent PDUs in RLC buffer has been added.

Sending of RB mappings to UE corrected in state transition from cell PCH state


(Rel99 cell) to cell FACH state (HS-FACH/HS-RACH capable cell)
• Sending of RB mappings to UE corrected in state transition from cell PCH state
(Rel99 cell) to cell FACH state (HS-FACH/HS-RACH capable cell) has been added.

CM activation time correction


• CM activation time correction has been added.

DN09100723 Issue: 05A © 2017 Nokia 9
   

Summary of changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Counters M1006C229 and M1006C196 update added in PCH-DCH state transition


while MBLB attempted
• Counters M1006C229 and M1006C196 update added in PCH-DCH state transition
while MBLB attempted has been added.

HS-DSCH/E-DCH setup with "dummy" PS RAB reconfiguration from PS CN


corrected
• HS-DSCH/E-DCH setup with "dummy" PS RAB reconfiguration from PS CN
corrected has been added.

Changes between issues 03E (2016-03-03, WCDMA16) and 03F (2016-06-17,


WCDMA16 MP3.0)

Removal of support for the HSDPA static resource allocation


• Note regarding the functionality of the RAN312 HSDPA dynamic resource allocation
feature parameters in WCDMA16 release has been added.

Changes between issues 03D (2016-02-18, WCDMA16) and 03E (2016-03-03,


WCDMA16)

Additional 7761 alarms raised during NBAP link break


• Additional 7761 alarms raised during NBAP link break has been added.

Changes between issues 03C (2016-01-21, WCDMA16) and 03D (2016-02-18,


WCDMA16)

Correction of activation time in coincidence of IMEI query and serving cell change
• Correction of activation time in coincidence of IMEI query and serving cell change
has been added.

E-UTRA Capability Enquiry Changes


• E-UTRA Capability Enquiry Changes has been added.

Corrected value of Counter M1005C252 MAC-D SETUP ATTEMPT FOR DC-HSDPA


when Secondary Serving HS-DSCH is removed from a call
• Corrected value of Counter M1005C252 MAC-D SETUP ATTEMPT FOR DC-HSDPA
when Secondary Serving HS-DSCH is removed from a call has been added.

Changes between issues 03B (2015-12-04, WCDMA16) and 03C (2016-01-21,


WCDMA16)

HSUPA E-TFCI amplitude ratio reference point and power offset optimization to
avoid usage of E-TFCI 124 in particular scenarios
• HSUPA E-TFCI amplitude ratio reference point and power offset optimization to
avoid usage of E-TFCI 124 in particular scenarios has been added.

Incorrect AC decision for NRT RB when channel type switch to HSPA was
performed

10 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Summary of changes
Counters and KPIs

• Incorrect AC decision for NRT RB when channel type switch to HSPA was performed
has been added.

Changes between issues 03A (2015-11-13, WCDMA16) and 03B (2015-12-04,


WCDMA16)

F-DPCH allocation based on calculated EcNo if RACH measurement result missing


• F-DPCH allocation based on calculated EcNo if RACH measurement result missing
has been added.

HSUPA 2 ms TTI and/or F-DPCH can be allocated even if RACH measurement


result is missing
• HSUPA 2 ms TTI and/or F-DPCH can be allocated even if RACH measurement
result is missing has been added.

Changes between issues 03 (2015-08-15, WCDMA16) and 03A (2015-11-13,


WCDMA16)

Cancelable HSPA+ post reconfiguration task


• Cancelable HSPA+ post reconfiguration task has been added.

Change to RAN2302 Dynamic HSUPA BLER use with RAN1645 HSUPA 16QAM
• Change to RAN2302 Dynamic HSUPA BLER use with RAN1645 HSUPA 16QAM
has been added.

Correction to HS-DSCH channel type switch guard timer handling when RB is


mapped to 0/0
• Correction to HS-DSCH channel type switch guard timer handling when RB is
mapped to 0/0 has been added.

Changes between issues 01G (2015-06-30, RU50 and RU50 EP1) and 03 (2015-08-
15, WCDMA16)
This is the first WCDMA16 issue of the RNC Generic Algorithm Changes and Impact on
Counters and KPIs document.
It has been updated to include changes in RNC16 and mcRNC16 software.

DN09100723 Issue: 05A © 2017 Nokia 11
   

Introduction to RNC Generic Algorithm Changes and RNC Generic Algorithm Changes and Impact on
Impact on Counters and KPIs Counters and KPIs

1 Introduction to RNC Generic Algorithm


Changes and Impact on Counters and KPIs
The RNC Generic Algorithm Changes and Impact on Counters and KPIs (GEN)
document summarizes generic changes introduced to the most recent version of the
Nokia WCDMA RNC software for a particular system release.
Generic changes are to be understood as new or modified functionalities that are
introduced into the RNC after a SW release upgrade. This particular GEN issue
documents changes introduced after an upgrade to WCDMA16 software.

• Algorithm changes describes purely functional changes.
• Counter changes explains generic counter-related changes in the release.
The descriptions in this chapter will also document any impact on RNC functionality
originating from these counter-related changes.
• Alarm changes documents high-level changes in alarm mapping, such as the
substitution or extension of a given alarm set.
The descriptions in this chapter will also document any impact on RNC functionality
originating from these alarm-related changes.
• Parameter changes presents generic management parameter changes introduced to
the SW release.
These parameters will typically be legacy internal parameters that are promoted as
visible parameters. The descriptions in this chapter will also document any impact on
RNC functionality originating from these parameter changes.

g Note: No actual quantitative estimations can be provided for impacted counter or KPI
values. Counter and KPI values are by nature network-specific and subject to traffic and
dimensioning considerations.

g Note: The document may cover postponed features from previous system releases.
Feature names may differ from the names listed in WCDMA Operating Documentation.

Each individual change description specifies the particular software version and Nokia
RNC products to which they apply.

12 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

2 Algorithm changes

2.1 Releasing RRC connection when RNC has not


received IMSI from core network
RUxx release(s) where the change is introduced
RU40, RU50, WCDMA 16
Applicable SW versions

RNC RU40 RN7.0 5.0


RU50 RN8.1 1.0
WCDMA 16 RNC16
mcRNC RU40 mcRNC3.0 4.0
RU50 mcRNC4.1 1.0
WCDMA 16 mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: PR 90011ESPE03

Change description
It has been noticed that on certain occasions core network SGSNs do not to send the
IMSI of a UE to the RNC, either because the authentication procedure has not been
completed or due to a bug in the implementation. The RNC does not know the reason for
not having received said IMSI in either case. In these cases, the RNC cannot page
devices with missing IMSI in Cell_PCH state if the RNC performed state transition after
device inactivity.
A two-phase workaround has been implemented. In phase 1, the RNC does not allow
the transition to PCH state for UEs whose IMSI has not been received from the CN.
These UEs are left in FACH state, at the cost of additional network resources.
Phase 2 complements the previous workaround by freeing devices that go inactive in
Cell_FACH state. When a UE whose IMSI has not been received is in Cell_FACH state
and the RNC detects further inactivity in Cell_FACH, the RNC releases the user's RRC
connection instead if performing a state transition to Cell_PCH.

Expected impact
The impact of SGSN failure to send the IMSI of a particular UE will be minimized, so that
it is still possible to reach those UEs for which IMSI has not been received, as they are
kept in Cell_FACH state. Moreover, if the IMSI has not been provided due to an
incomplete authentication procedure, this change will give time to the SGSN to re-
transmit the authentication request and either:
• Re-transmit the authentication request and release the RRC connection of the user
after a failed authentication procedure.
• Continue the call after having successfully completed the authentication.

DN09100723 Issue: 05A © 2017 Nokia 13
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

With Phase 2 of the workaround network resources are not reserved, but the release of
RRC connections will cause increases in counter M1001C15
RRC_CONN_ACT_FAIL_IU.

Reason(s) behind the change


Without the change UEs could still be moved to PCH state even if the SGSN had not
provided the corresponding IMSI. In this situation RNCs were unable to page such UEs.
Without the Phase 2 change network resources are unnecessarily reserved for those
UEs for which no IMSI has been sent. However, the release of RRC connections impacts
counter M1001C15 RRC_CONN_ACT_FAIL_IU. It is possible to deactivate Phase 2 by
manually modifying PRFILE parameter 002:2129 RU40_MAINT_33.

Impacted counters/KPIs
With Phase 2 of the correction activated, the following counters are expected to be
pegged more often:
• M1001C15 RRC_CONN_ACT_FAIL_IU

The following counters will also be pegged, depending on RRC establishment cause:
• M1001C635 SRB_ACT_FAIL_CONV
• M1001C636 SRB_ACT_FAIL_STREA
• M1001C637 SRB_ACT_FAIL_INTERA
• M1001C638 SRB_ACT_FAIL_BACKG
• M1001C639 SRB_ACT_FAIL_OTHER

Type of change
Phase 1 is generic in the SW. It cannot be deactivated.
Phase 2 is activated by default. It can be deactivated with the 002:2129
RU40_MAINT_33 PRFILE parameter.

UE dependency
n/a
Reference information
See the corresponding release PRFILE descriptions document for instructions on how to
activate and deactivate Phase 2 of the change. PRFILE descriptions can be found in
NOLS under the Care section, published alongside the Release Documentation package
for a particular product.

2.2 New license for mcRNC signaling capacity


RUxx release(s) where the change is introduced
WCDMA 16

Applicable SW versions

14 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

mcRNC: mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:
RAN3057 mcRNC signalling capacity license

Change description
A new signaling capacity license is introduced in mcRNC16 to control the usage of
signaling capacity on mcRNC HW Rel.2 controller. This license carries the 5385 feature
code and is required to be installed in the controller before the system can be taken to
live network use.

g Note: This license must be installed in mcRNC4.1 before the SW is upgraded to
mcRNC16. Otherwise the RNC PS throughput capacity will be severely limited, to
approximately 100Mbps in total. In practice this is equivalent to no PS data throughput.

Signaling capacity is defined by the total number of the following procedures taking place
simultaneously within the system:
• CS voice RAB setup
• Cell_DCH state PS user plane allocation
• Cell_PCH to Enhanced Cell_FACH transition

Signaling capacity is estimated on the basis of Successful Busy Hour Call Attempts
(SBHCA), taking into account the following counters:

Table 1 SBHCA counters
Number Name
M1022C21 HS-DSCH/E-DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR
INTERACTIVE
M1022C22 HS-DSCH/E-DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR
BACKGROUND
M1022C23 HS-DSCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR INTERACTIVE
M1022C24 HS-DSCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR BACKGROUND
M1022C25 HS-DSCH/DCH ALLO AFTER HS-DSCH/DCH REQ FOR INTERACTIVE
M1022C26 HS-DSCH/DCH ALLO AFTER HS-DSCH/DCH REQ FOR BACKGROUND
M1022C27 DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR INTERACTIVE
M1022C28 DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR BACKGROUND
M1022C29 DCH/DCH ALLO AFTER HS-DSCH/DCH REQ FOR INTERACTIVE
M1022C30 DCH/DCH ALLO AFTER HS-DSCH/DCH REQ FOR BACKGROUND
M1022C31 DCH/DCH ALLO AFTER DCH/DCH REQ FOR INTERACTIVE
M1022C32 DCH/DCH ALLO AFTER DCH/DCH REQ FOR BACKGROUND
M1022C190 HS-DSCH/E-DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR STREAMING
M1022C191 HS-DSCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR STREAMING
M1022C192 HS-DSCH/DCH ALLO AFTER HS-DSCH/DCH REQ FOR STREAMING

DN09100723 Issue: 05A © 2017 Nokia 15
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Table 1 SBHCA counters (Cont.)
Number Name
M1022C193 DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR STREAMING
M1022C194 DCH/DCH ALLO AFTER HS-DSCH/DCH REQ FOR STREAMING
M1022C195 DCH/DCH ALLO AFTER DCH/DCH REQ FOR STREAMING
M1001C115 RAB ACCESS COMPLETIONS FOR CS VOICE
M1006C220 CELL_PCH TO ENHANCED CELL_FACH SUCCESSFUL

Signaling capacity is measured in kilo BHCA (kBCHA), using the following formula:

Where the signaling capacity reporting period corresponds to the sampling period of the


SBHCA counters.

When determining the required licensed mcRNC signaling capacity, operators are
expected to calculate signaling capacity on the basis of SBHCA counters as shown in
OSS/NetAct.

g Note: The calculation will depend on the selected sampling interval and the particular
network traffic during the sampling period. This means that a calculation based on a
sample taken during normal network will not accommodate the capacity needed to deal
with occasional traffic peaks.

The same signaling capacity formula is used internally by the mcRNC to check live
signaling capacity usage against licensed signaling capacity. The mcRNC samples
SBHCA counters in 30 second intervals. If the capacity in use approaches the licensed
capacity limit, the RNC raises alarm 3294 LICENCE CAPACITY WARNING, with
Feature code 5385 as additional information.

Expected impact
A new KPI RNC_5537a Average Signaling Capacity Usage is introduced to
calculate mcRNC average signaling capacity usage.
Four new counters are added in Measurement 802 to monitor the signaling capacity
usage on the mcRNC:

Counter name Explanation


M802C26 SIGNALING_CAPA_USE_AVE Average signaling capacity usage within
30s sample period.
M802C27 SIGNALING_CAPA_USE_MAX Maximum signaling capacity usage value
calculated over 30s sample period.
M802C28 Installed licensed capacity.
SIGNALING_CAPA_LICENSED

16 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Counter name Explanation


M802C29 PS_THR_LIMIT_DUR_SIGN Duration of RNC Iu-PS throughput
limitation due to exceeded licensed
capacity.

Reason(s) behind the change


Licensing signaling capacity makes it possible for operators to scale mcRNC signaling
capacity according to their network's actual needs, saving CAPEX though a "Buy as you
Grow" sales approach.

Impacted counters/KPIs
KPIs:
• RNC_5537a Average Signaling Capacity Usage

Average Signaling Capacity Usage Counters:
• M802C26 SIGNALING_CAPA_USE_AVE
• M802C27 SIGNALING_CAPA_USE_MAX
• M802C28 SIGNALING_CAPA_LICENSED
• M802C29 PS_THR_LIMIT_DUR_SIGN

Type of change
The change is license based.

g Note: This license is mandatory for BCN-B2 mcRNC and shall always be installed in
live network mcRNCs under WCDMA 16.

UE dependency
n/a
Reference information
RAN3057 mcRNC signalling capacity license
WCDMA RAN WCDMA 16 System Upgrade

2.3 IP Based Route load sharing source IP address


selection for common channels
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN2897 User Plane Traffic
Differentiation for IuPS and Iur

DN09100723 Issue: 05A © 2017 Nokia 17
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Change description
The IP Based Route load sharing source IP address selection logic for the common
channels has been changed within RU50 EP1. Earlier the source IP addresses for the
common channels of any cell have been selected with a round robin manner from the
group of source IP addresses (IPRO) related to the IP Based Route instance (IPBR).
With IPBR load sharing the IP terminations of the common channels of one cell have got
distributed over the source IP addresses related to the IPBR.
The new functionality concentrates the common channels of the cells of one BTS to one
source IP address within the RNC. With this approach the common channels IP layer
termination can be found located to one network processing unit (RNC2600 NGPE,
mcRNC EIPU). The source IP address selection takes place for the first cell of the BTS
once the common channels are established for example during the cell unlock operation.
Once the source IP address has been allocated for the first cell of the BTS the rest of the
common channels related to the cells of the BTS follow the same allocation.
The concentrated common channel source IP address selection helps to keep the
common channels related to the cell of the BTS located in the same place. This will
make the possible debugging of the system behaviour easier and in case of a severe
network processing unit failure the effects are distributed to more limited group of cells
compared to the earlier implementation.

Expected impact
The common channel IP termination is concentrated to the same source IP address
within the IP Based Route load sharing in RU50 EP1. Earlier the common channel
terminations have been distributed over the source IP addresses related to the IP Based
Route instance.

Reason(s) behind the change


The concentrated common channel source IP address selection helps to keep the
common channels related to the cell of the BTS located in the same place. This will
make the possible debugging of the system behaviour easier. Also, in case of a severe
network processing unit failure, the effects will be distributed to a more limited group of
cells compared to the earlier implementation.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN2897 User Plane Traffic Differentiation for IuPS and Iur

2.4 Maximum number of HS(D)PA Users per cell


Applicable SW versions

RNC RNC16
mcRNC mcRNC16

18 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Relation to features or corrections


Feature/fault correction introducing the change:
• RAN2518: HS Cell_FACH, Enhanced
• RAN2869: HSPA Subscriber Increase
Affected legacy features/functionality:
• RAN2124: 128 HSPA Users per Cell
• RAN1686: 72 HSPA Users per Cell
• RAN1464: HSDPA 64 Users per Cell

Change description
The limit on maximum number of HS(D)PA Users per cell has been changed in WCDMA
16. The number of configured Common E-DCH Resources, defined by the WCEL
parameter HSRACHCommonEDCHRes, is reduced from the maximum number of
HS(D)PA users per cell as defined by parameters:
• WCEL HSPA128UsersPerCell
• WCEL HSPA72UsersPerCell
• WCEL HSDPA64UsersEnabled
• RNC HSDPA48UsersEnabled
This has no effect if HS-RACH is not activated in the cell. The maximum amount of
HSDPA users in CELL_DCH state per cell will be concurrent with the amount established
by the existing capacity features, RAN2124: 128 HSPA Users per Cell, RAN1686: 72
HSPA Users per Cell and RAN1464: HSDPA 64 Users per Cell.

Expected impact
The maximum per-cell number of HSDPA users in Cell_DCH state is expected to be
reduced.

Impacted counters/KPIs
Counters showing HSDPA and HSUPA user amounts per cell are expected to decrease:
• RNC_645c Average number of simultaneous HSDPA users
• RNC_1686a Maximum number of simultaneous HSDPA users per
cell
• RNC_1036b Average number of simultaneous HSUPA users
• RNC_1036b Average number of simultaneous HSUPA users
• RNC_1687a Maximum number of simultaneous HSUPA users per
cell
The maximum numbers of simultaneous HS(D)PA users is expected to be reduced by
the value of WCEL parameter HSRACHCommonEDCHRes. Depending on particular
profile and traffic scenarios, the average number of simultaneous HS(D)PA users per cell
may also be reduced.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

DN09100723 Issue: 05A © 2017 Nokia 19
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

2.5 HSRACH overload control functionality


Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:
• RAN2518: HS Cell_FACH, Enhanced
• RAN2869: HSPA Subscriber Increase
Affected legacy features/functionality:
• RAN2124: 128 HSPA Users per Cell
• RAN1686: 72 HSPA Users per Cell
• RAN1464: HSDPA 64 Users per Cell

Change description
When the unit load serving HSRACH services exceeds a certain threshold, the RNC
sends overload indications for those cells which generate the most frames per TTI
(transmission time interval). Affected BTSs respond to these congestion/overload control
frames by gradually reducing common E-DCH resources.
When the unit load serving HSRACH service returns to levels below the overload
threshold, RNC/UP sends congestion control indication frames with status “OFF” for
those same cells which were earlier notified to reduce common E-DCH resources.
Affected BTSs respond by gradually increasing the number of common E-DCH
resources.

Expected impact
For cases when the unit load serving HSRACH services exceeds the threshold value,
BTSs limit/reduce common E-DCH resources for their cells. This will also limit the
number of HSRACH UEs admitted into those cells.

Reason(s) behind the change


HSRACH requires a congestion control functionality similar to HSUPA, as the increase of
common E-DCH resources generates increases in uplink traffic towards the RNC.

Impacted counters/KPIs
Overload scenarios will present a decrease in counter:
• M1006C319 - MAX NUMBER OF HS-FACH/HS-RACH USERS PER CELL

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

20 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

2.6 Change in measuring RAB setup time


Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: PR067019

Change description
The implementation of RAB setup time counters in the M1001 Service Level
measurement has been changed so that they are only updated during the initial RAB
setup. These counters will no longer be updated during in RAB reconfigurations.
In earlier RNC SW, RAB setup time counters were also updated during RAB
reconfigurations. In these scenarios time counters (for example M1001C233
AVG_RAB_SETUP_TM_PS_INTER) were in fact not being incremented: only the
denominator counter (for example M1001C234 DENOM_RAB_SETUP_TM_PS_INTER)
was incremented by 1. This behavior resulted in misleading RAB setup time statistics: in
scenarios with frequent RAB reconfigurations, the RAB setup time KPI went down as the
denominator increased but the numerator did not. The counters were not able to
accurately measure how long it takes to perform the initial RAB setup.
In the new implementation, the RAB setup time counters are not updated at all during
RAB reconfigurations. The related KPIs will show more reliable values, reflecting the real
call setup time experienced by end users.

Expected impact
If RAB reconfigurations are occurring in the network, the change will result in a small
increase in the RAB setup time KPI. The zero time counter updates due to
reconfigurations stop occurring, and the RAB setup time denominator counter
decreases.
The impact of this change can be evaluated from the difference of RAB setup time
denominator counters (for example M1001C234) and RAB Access Complete counters
(for example M1001C120), as RAB Access Complete counters are still updated during
reconfigurations.

Reason(s) behind the change


The change was made as a general improvement to produce more reliable RAB setup
time statistics.

Impacted counters/KPIs
After the change the following counters are expected to decrease:
• M1001C224 DENOM_RAB_SETUP_TM_CS_VOICE
• M1001C234 DENOM_RAB_SETUP_TM_PS_INTER
• M1001C236 DENOM_RAB_SETUP_TM_PS_BACKG

DN09100723 Issue: 05A © 2017 Nokia 21
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

g Note: Because the corresponding time counters M1001C223, M1001C233,
M1001C235 do not change, the RAB setup time KPI increases.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.7 New calculation of HSPA subscribers per cell


Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:
• RAN1637/RAN1913 High speed Cell_FACH
• RAN2869 HSPA Subscriber Increase
Affected legacy features/functionality:
• RAN2124 128 HSPA Users per Cell
• RAN1686 72 HSPA Users per cell
• Other HSPA user/cell features

Change description
The calculation of HSPA user amount per cell has been changed. From WCDMA 16
onwards, Cell_FACH state users utilizing high speed common channels (HS Cell_FACH)
are also taken into account for calculation of HSPA user amount per cell, together with
Cell_DCH state HSPA users.

Expected impact
The maximum number of HSPA + HS Cell_FACH users is limited to the cell’s licensed
capacity. If a cell's HSPA licensed capacity is exceeded, DCH/DCH allocation is tried
instead.

Reason(s) behind the change


UEs utilizing HS-RACH/HS-FACH consume resources on BTS and RNC. Thus, the
number of UEs utilizing HS Cell_FACH is included into cell-level HSPA user amount
calculations.

Impacted counters/KPIs
The total amount of HSxPA users is shown via M1006C321, which can be expected to
increase:
• M1006C317 HS-FACH NOT ALLOCATED DUE TO MAX USERS

22 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

The amount of blocked users due the HSPA capacity limit can be followed via the
following counters:
• M1006C317 HS-FACH NOT ALLOCATED DUE TO MAX USERS
• M1002C475 DCH_SEL_MAX_HSDPA_USERS_INT
• M1002C476 DCH_SEL_MAX_HSDPA_USERS_BGR
• M1006C321 MAX_HSPA_TOTAL_USERS

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
Rel-5 and newer UEs.

Reference information
RAN2869 HSPA Subscriber Increase

2.8 Capacity reservation for Cell_DCH state HSPA


users and prioritization of HSPA users over HS
Cell_FACH users
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:
• RAN1637/RAN1913 High speed Cell_FACH
• RAN2869 HSPA Subscriber Increase
Affected legacy features/functionality:
• RAN2124 128 HSPA Users per Cell
• RAN1686 72 HSPA Users per cell
• Other HSPA user/cell features

Change description
Feature RAN2869 introduced HSPA capacity licensing to WCDMA 16 RNCs. With this
feature RNC is able to measure HSPA users so that the licensed number is not
exceeded. This total of licensed users is equivalent to the sum of HSPA users and HS
Cell_FACH users.
In case RAN2869 capacity licensing is not enabled, the total number of licensed users
per cell will be restricted to existing HSPA users amount: for example, according to
feature RAN1686 72 HSPA Users.

Expected impact
Licensed users are allowed into the cell according to the FCFS (first come, first served)
principle.

DN09100723 Issue: 05A © 2017 Nokia 23
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

To ensure that the total number of licensed users is distributed between DCH and FACH
states, a given number of Cell_DCH state HSPA users can be reserved by modifying
PRFILE parameter 007:0521 HSPA_DCH_MIN_RES.
The value of this parameter indicates that certain capacity will be reserved for HSPA
Cell_DCH state users in the cell. When this minimum reservation is activated, HS-FACH
users are not allowed to use this capacity.

g Note: By default this minimum reservation is not active. The licensed number of HSPA
users cannot be guaranteed, as the total number includes both Cell_DCH and
Cell_FACH users.
There is an additional possibility to establish pre-emption for HS Cell_FACH users with
that same 007:0521 parameter, so that HSPA users have higher cell access priority than
HS Cell_FACH users.

Reason(s) behind the change


The change adds flexibility for controlling the feature. With the minimum HSPA Cell_DCH
reservation, older release UEs (without HS Cell_FACH capability) can have higher
access probability in high load cases. With the HS Cell_FACH pre-emption functionality,
the UEs which have had the longest allocation on HS Cell_FACH can be moved to the
Cell_PCH state to make room for new users.

Impacted counters/KPIs

• M1006C317 HS-FACH NOT ALLOCATED DUE TO MAX USERS


Number of times when HS-FACH is not allocated for the user, or when HS-FACH
allocation is released, due to HSPAtot user amount restriction.
• M1002C475 DCH_SEL_MAX_HSDPA_USERS_INT
Number of times when the DCH channel type is selected for interactive class
connections due to maximum amount of HSDPA users or MAC-d flows in the WBTS,
local cell group or cell.
• M1002C476 DCH_SEL_MAX_HSDPA_USERS_BGR
Number of times when the DCH channel type is selected for background class
connections due to maximum amount of HSDPA users or MAC-d flows in the WBTS,
local cell group or cell.
• M1006C321 MAX_HSPA_TOTAL_USERS
Number of HSPA users both HSPA and HS Cell_FACH.

Type of change
The functionalities are controlled via PRFILE parameter 007:0521
HSPA_DCH_MIN_RES. Refer to PRFILE descriptions (DN0948854) for instructions on
how to modify the parameter value.
UE dependency
Rel-7 and newer UEs

Reference information
RAN2869 HSPA Subscriber Increase
PRFILE descriptions (DN0948854)

24 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

2.9 Selection of RAN2172 IFHO trigger counter


Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN2172 Multi-Band Load Balancing
Change description
The selection logic of RAN2172 Multi-Band Load Balancing trigger counters
M1008C296, M1008C297, M1008C298, M1008C299 has been enhanced in RNC16
release to better show the most significant factor in the layer selection logic.
In earlier releases the trigger cause counter to be updated was selected as the one
where the source and target cell preference score difference is highest, even if the target
cell score absolute value was lower than the source cell score.
In the new WCDMA 16 implementation, the trigger cause counter that is selected must
fulfill both these conditions:
• having the highest preference score difference
• having its target cell score higher than the source cell score

Expected impact
The distribution of counters M1008C296, M1008C297, M1008C298 and M1008C299
may be different than with earlier RNC SW. However, the total amount of IFHO attempts
is not expected to change. This SW change does not impact the MBLB algorithm itself
but is only a statistical change.

Reason(s) behind the change


The change was made as a general improvement of MBLB statistics.

Impacted counters/KPIs
After the change, the distribution of following counters may be different than with earlier
RNC SW:
• M1008C296 MBLB IFHO ATTEMPTS WITH UE BAND CAPA
• M1008C297 MBLB IFHO ATTEMPTS WITH SERVICE AND UE FEATURE
CAPA
• M1008C298 MBLB IFHO ATTEMPTS WITH RSCP
• M1008C299 MBLB IFHO ATTEMPTS WITH LOAD

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

DN09100723 Issue: 05A © 2017 Nokia 25
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

2.10 Network resiliency for mcRNC


Applicable SW versions

mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN3005 Network resiliency for
mcRNC.

Change description
1. A new PRNC Root object containing RNC Service object will appear in mcRNC RNW
DB. This change is independent of the activation status of RAN3005 Network
resiliency for mcRNC. No user actions are required.
2. The mcRNC commissioning procedure is changed to include a new PRNCMODE
parameter. This change is independent of the activation status of RAN3005 Network
resiliency for mcRNC.
The instructions to commission an RNC as BkPRNC (Backup Physical RNC) can be
found within RAN3005 Network resiliency for mcRNC documentation. The default
PRCMODE value ensures that StPRNC (Standard Physical RNC) and PrPRNC
(Protected Physical RNC) commissioning require no additional actions.

Expected impact
There is no expected impact on KPIs or RNC performance.

Reason(s) behind the change

1. The change has been done to differentiate the Physical RNC (PRNC) from the
Logical RNC/RNC service.
2. The commissioning procedure for PrPRNC/StPRNC and BkPRNC is now
differentiated.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN3005 Network resiliency for mcRNC

2.11 License control for mcRNC 10 Gbps Ethernet


interfaces
Applicable SW versions

mcRNC mcRNC16

Relation to features or corrections

26 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Feature/fault correction introducing the change: RAN3112 License control for mcRNC 10


Gbps Ethernet interfaces
Affected legacy features/functionality: RAN2696 mcRNC 10 Gigabit Ethernet Based
Network Connectivity

Change description
The feature RAN2696 mcRNC 10 Gigabit Ethernet Based Network Connectivity was
originally introduced as a trust-based licensed feature in release RU40. The licensing
model for 10GE interfaces is now moved under actual SW license control. The 10GE
interfaces used for external connectivity (SFP+11, SFP+12) will be placed under a
capacity based license which controls the number of 10GE physical interfaces that can
be created in the mcRNC. This license carries the 5328 feature code.

Expected impact
Operators will not be able to create new 10GE interfaces until the proper capacity license
is installed into the system. The capacity license is to be installed according to the
intended total amount of 10GE ports (SFP+11, SFP+12).

Reason(s) behind the change


The licensing model for 10GE external connectivity is changed from trust-based licensing
to SW based license control.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN3112 License control for mcRNC 10 Gbps Ethernet interfaces

2.12 Removal of support for the HSDPA static resource


allocation
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN3219 Obsolete Legacy Feature
Removals
Affected legacy features/functionality: RAN312 HSDPA static resource allocation

Change description
Support for the HSDPA static resource allocation is terminated. Dynamic resource
allocation is applied always to the HSDPA. License control for RAN312 HSDPA dynamic
resource allocation and activation parameter RNFC-

DN09100723 Issue: 05A © 2017 Nokia 27
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

HSDPADynamicResourceAllocation are removed, so that the functions controlled
by them are always enabled.
The RAN312 HSDPA static resource allocation feature consists of the HSDPA dynamic
power allocation and HSDPA dynamic code allocation functions. HSDPA dynamic power
allocation is a HSDPA basic (generic) functionality. It is applied if the HSDPA is enabled
in the cell by the WCEL-HSDPAenabled parameter. HSDPA dynamic code allocation
requires having the HSDPA 15 Codes feature enabled, and more than 5 HS-PDSCH
codes configured in the cell by the WCEL-HSPDSCHCodeSet parameter.

Expected impact
RAN312 HSDPA dynamic resource allocation utilises DL resources, both HSDPA and
DCH, more effectively.

Reason(s) behind the change


HSDPA dynamic resource allocation provides flexible configuration methods and tools
for handling both HSDPA and DCH resources in downlink. HSDPA dynamic resource
allocation makes also HSUPA usage possible in UL. Usage of the HSDPA static
resource allocation is minor in live networks, and thereby the support is terminated to
reduce complexity.

Impacted counters/KPIs
Usage of the HSDPA dynamic power allocation is detected from the counters:
• M1000C232 MINIMUM PTXTARGETPS
• M1000C233 MAXIMUM PTXTARGETPS
• M1000C234 AVERAGE PTXTARGETPS
• M1000C235 PTXTARGETPS DENOM
• M1000C236 MIN HSPA DL POWER
• M1000C237 MAX HSPA DL POWER
• M1000C238 AVE HSPA DL POWER
• M1000C239 HSPA DL POWER SAMPLES
Usage of the HSDPA dynamic code allocation is determined from these counters:
• M1000C248 DURATION OF HSDPA 5 CODES RESERVATION
• M1000C249 DURATION OF HSDPA 6 CODES RESERVATION
• M1000C250 DURATION OF HSDPA 7 CODES RESERVATION
• M1000C251 DURATION OF HSDPA 8 CODES RESERVATION
• M1000C252 DURATION OF HSDPA 9 CODES RESERVATION
• M1000C253 DURATION OF HSDPA 10 CODES RESERVATION
• M1000C254 DURATION OF HSDPA 11 CODES RESERVATION
• M1000C255 DURATION OF HSDPA 12 CODES RESERVATION
• M1000C256 DURATION OF HSDPA 13 CODES RESERVATION
• M1000C257 DURATION OF HSDPA 14 CODES RESERVATION
• M1000C258 DURATION OF HSDPA 15 CODES RESERVATION
Parameters related to the HSDPA static resource allocation and activation of feature
RAN312 HSDPA dynamic resource allocation are removed:
• RNFC-HSDPADynamicResourceAllocation
• WCEL-PtxTargetHSDPA
• WCEL-PtxOffsetHSDPA

28 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

• RNHSPA-HSDPAPriority

g Note: The parameters are removed from the operating documentation since related
feature RAN312 HSDPA dynamic resource allocation is removed. The parameters
functionality does not change until the RNC17 and mcRNC17 SW release.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
HSDPA capable Rel-5 or later UEs.

Reference information
n/a

2.13 PDCP Buffer full packet drop from head of the


PDCP queue
Applicable SW versions

RNC RNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN3235: Optimized TCP packet
Handling at RNC
Change description
Changes have been introduced to the RNC Packet Data Convergence Protocol buffer. A
head drop mechanism is introduced over existing tail drop mechanism at RNC PDCP
buffer level. Dropping packets from head of queue presents advantages in comparison to
the tail drop mechanism during full-buffer or congestion situations. The head drop
mechanism will work irrespective of the activation or deactivation of RAN3235:
Optimized TCP packet Handling at RNC.
With the traditional “tail drop” mechanism, when larger amounts of data are received
from CN, the excess data is dropped from the queue tail. Head of queue to reduce RTT
time for indicating buffer full situation and it is introduced from WDCMA16 release
onwards .The head drop mechanism is independent of feature activation.

Expected impact
Response time to CN for buffer full or congestion situation will be reduced and overall
RTT of DL packets will be improved.

Reason(s) behind the change


It helps to reduce packet drop counts during congestion or buffer full case.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a

DN09100723 Issue: 05A © 2017 Nokia 29
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Reference information
n/a

2.14 Replacement of SBTS BTSOM interface with NBAP


for RNC communication
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: n/a
Change description
There will not be a BTSOM interface between RNC and BTS in the SRAN architecture.
SRAN support for RNC initiated BTS recovery is handled over C-NBAP.
SBTS provides a direct OAM interface towards NetAct, and as such the BTS O&M
interface will not be supported in SRAN. Historically, the BTS O&M is used by RNC for
certain information exchange and recovery procedures, in particular RNC-initiated BTS
recovery. In SRAN these procedures are handled over the common node B application
part, C-NBAP. SBTS and WCDMA BTS inform RNC about the available capabilities as
part of audit procedures, and RNC accordingly makes use of the available method. Due
to direct OAM interfacing towards NetAct, SBTS alarms are no longer mediated to
NetAct via RNC. Alarms raised by SBTS will not be visible in RNC MML/SCLI or OMS
GUIs.

Expected impact
No expected KPI impacts. Obsolete marked parameters can be found within the
Obsolete and All parameter views in NetAct.

Reason(s) behind the change


SRAN architectural requirements demand RNC integration without BTS O&M.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN3252 SBTS BTSOM interface replacement with NBAP for RNC communication

2.15 Updating M568C15 IP_EG_BW_CONFIG when IFC


is disabled
Applicable SW versions

30 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: CR E1209

Change description
The updating principle of counter M568C15 IP_EG_BW_CONFIG is changed in the
WCDMA 16 release. The counter will now also show the configured IP based route
(IPBR) bandwidth in cases when the bandwidth is not used for shaping. This makes it
now possible to calculate a IPBR utilization KPI when the RNC does not perform
shaping: the calculation may be made even when load sharing is used for EIPU/NPGE
units, and in single EIPU/NPGE cases when IFC is disabled.
It is the operator's responsibility to configure a reasonable value for IPBR bandwidth, so
that the utilization KPI provides feasible results.

Expected impact
If the IP based route bandwidth is defined as non-zero value and IFC is disabled, counter
M568C15 shows non-zero values in WCDMA 16, while in previous releases the values
were zero in such configuration.
The behavior of counter M568C15 does not change in configurations where IFC is
enabled.

Reason(s) behind the change


The change was made to make it possible to calculate IP based route utilization
percentage also when IFC is disabled. In this case the operator can configure IPBR
bandwidth to the desired target bandwidth value and see that in counter M568C15 used
as a denominator in IPBR utilization KPI calculation.

Impacted counters/KPIs
The behaviour of counter M568C15 IP_EG_BW_CONFIG depends on the disabled or
enabled status of IFC.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.16 Handling of Iu release commands with Out Of


UTRAN IE
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

DN09100723 Issue: 05A © 2017 Nokia 31
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Relation to features or corrections


Feature/fault correction introducing the change: EFS CR E1161
Affected legacy features/functionality: RAN2067 LTE Interworking

Change description
The change addresses scenarios when UE makes a cell reselection from WCDMA to
LTE, receiving a RANAP: IU RELEASE COMMAND message from CN. Before the
change, RNC was not aware of the reason for this release request and tried to release
the UE RRC connection. This was always unsuccessful, as the UE was already in LTE.
This behaviour wasted RNC resources as RNC waited for a UE response. This waste
was particularly visible when the connection was in Cell/URA_PCH state, as a result of
the paging repetition procedure.
The change ensures that RNC supports the required IEs so that CN can inform the
reason for release in the Iu release command message, avoiding RNC resource waste.
When CN includes the Out of UTRAN IE in a RANAP: IU RELEASE COMMAND
message, RNC avoids the unnecessary delay caused by paging/RRC connection
release. When the received IE has the value Cell reselection to EUTRAN, RNC is
informed that UE has made a cell reselection to LTE: there is no need to page the UE
nor to explicitly release the UE RRC connection. UE dedicated resources are released
locally, minimizing the delay of releasing UE dedicated resources from RNC.

Expected impact
In scenarios where feature RAN2067 LTE Interworking is active and CN includes the Out
of UTRAN IE in RANAP: IU RELEASE COMMAND message, KPI RNC_1215b
Paging - Cell PCH - success ratio is expected to show improvements after
the change.

Reason(s) behind the change


RNC resources are optimised by the removal of unnecessary delays caused by
paging/RRC connection release.

Impacted counters/KPIs
The following paging failure counters are expected to decrease after the change:
• M1006C158 PAGING FAILURE DUE TO NO RESPONSE IN CELL_PCH
• M1006C162 PAGING FAILURE DUE TO NO RESPONSE IN URA_PCH
The following KPI can increase after the change:
• RNC_1215b Paging - Cell PCH - success ratio

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

32 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

2.17 RNC ignores SDU Error Ratio and Residual Bit


Error Ratio parameters in RAB modification
message
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: n/a
Affected legacy features/functionality: RAN930 PS RAB Reconfiguration

Change description
RNC will no longer reject RAB reconfiguration commands containing requests to modify
SDU Error Ratio and Residual Bit Error Ratio. These parameters will be
ignored if the core network requests their modification in the RAB modification phase.

Expected impact
No performance impacts. The number of failed RAB modifications is expected to
decrease.

Reason(s) behind the change


There are live network scenarios where SGSN may ask for SDU Error Ratio or
Residual Bit Error Ratio parameter modification, especially after handovers
from LTE. RNC did not support these parameters and rejected RAB reconfiguration
commands which contained them. This caused RAB releases and the need to setup a
new RAB, resulting in service breaks and increased RNC failure counters.

Impacted counters/KPIs
Counters listing failed RAB modifications are expected to decrease after the change:
• M1001C257 RAB_STP_FAIL_PS_NOT_SUPP_PAR
• M1003C20 RAB_REC_NONSUCC_RNL

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN930: PS RAB Reconfiguration

2.18 Enhance O&M secure connection algorithms


between MCRNC and OMS
Applicable SW versions

DN09100723 Issue: 05A © 2017 Nokia 33
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: PR121187ESPE01
Affected legacy features/functionality: O&M secure connection between MCRNC and
OMS

Change description
When mcRNC establishes secure BTS O&M connection to OMS, it proposes a list of
allowed ciphers in the TLS handshake phase. The list contains also weak ciphers, which
could allow an attacker to downgrade the cipher to a weak/broken cipher via an MITM
attack.
With this correction, mcRNC will propose only strong ciphers. Cipher Suite
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) will be used when establishing
O&M secure connection to OMS.

Expected impact
The change will enable the establishment of a secure connection between MCRNC and
OMS with Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Reason(s) behind the change
The change is implemented to enhance the O&M secure connection by the use of strong
ciphers.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.19 Support of IMSI and IMEI information elements via


Iupc
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN3185 GLONASS Support for
RNC2600
Affected legacy features/functionality:
• RAN2.0041 LCS- Cell Coverage Based (RTT) with Geographical Coordinates
• RAN815 Point-to-Point Iu-pc interface

34 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

• RAN1187 SAS-Centric Iupc


• RAN223 UE Based A-GPS Using External Reference Network
• RAN875 Network Based A-GPS Using External Reference Network
• RAN1296 LCS periodical reporting

Change description
The change ensures that IMSI and IMEI information elements are delivered to the SAS
(Stand-alone SMLC) via PCAP: Position Initiation Request, if case they are known by
RNC.

Expected impact
SAS receives more information about the UE for location calculation.

Reason(s) behind the change


IMSI and IMEI IEs were not supported via Iupc although related 3GPP CRs RP-110226
and RP-131901. It was good time to do the support for IMSI and IMEI information
elements while adding support for GLONASS related IEs via the Iupc interface.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
3GPP 25.453, chapter 9.1.13

2.20 Cancelable HSPA+ post reconfiguration task


Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: Internal improvement done based on log
analysis from RU50EP1 SW features RAN1905 and RAN2221.
Affected legacy features/functionality: Channel type switches and serving cell changes.

Change description
The UE specific resource manager entity (UER) runs a HSPA+ post reconfiguration task
responsible for improving the performance of the HSPA radio bearer. For example, UER
may activate HSPA+ functionalities, update HSDPA parameters or update the E-DCH
symbol rate.

DN09100723 Issue: 05A © 2017 Nokia 35
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

UER automatically triggers the HSPA+ post reconfiguration task after certain RL
operations, such as branch addition, branch deletion, or AMR release. While UER is
running this HSPA+ post reconfiguration task, handover control may however request
higher priority task for quality or mobility reasons, such as channel type switches (CTS),
serving cell changes (SCC), or branch operation.
When RU50EP1 UER has started the HSPA+ post reconfiguration task, it will reject
higher priority tasks (CTS, SCC) with parallel_procedure reason. Higher priority
tasks may be re-attempted after the HSPA+ reconfiguration task is completed,
depending on the radio conditions. This causes delays in quality and/or mobility triggers,
and it is possible that the HSPA+ post reconfiguration task is performed unnecessarily.
WCDMA16 improves the handling of quality and mobility triggers, making it possible to
cancel the lower priority HSPA+ post reconfiguration task. The number of unnecessary
reconfigurations is also decreased.

Expected impact
The number of required reconfigurations is decreased. Quality and mobility triggers are
handled faster.
The change may increase the number of successful CTS to R99 and SCCs, and
decrease the number of parallel procedure rejections for those same CTS. This
increases R99 channel utilization, which can cause R99 NRT code blocking.

Reason(s) behind the change


Need to improve the execution order of quality/mobility triggers vs HSPA+ allocations
and to avoid unnecessary reconfigurations.

Impacted counters/KPIs
The purpose of the change is to improve HSPA retainability:
• HSDPA Resource Retainability for NRT Traffic RNC_609a
• HSUPA resource Retainability for NRT Traffic RNC_919b
The change may increase the values of the following counters:
• M1022C35 PS_SWI_HS_E_TO_D_D_INT
• M1022C36 PS_SWI_HS_E_TO_D_D_BGR
• M1022C37 PS_SWI_HS_D_TO_D_D_INT
• M1022C38 PS_SWI_HS_D_TO_D_D_BGR
Downlink spreading code consumption may also increase, increasing the values of the
following access failure counters:
• M1022C236: PACKET CALL SETUP FAIL DUE TO AC CODE FOR NRT
• M1022C9: PACKET CALL SETUP FAIL DUE TO AC FOR INTERACTIVE
• M1022C10: PACKET CALL SETUP FAIL DUE TO AC FOR BACKGROUND
This new functionality decreases soft handover branch addition delay when there is
parallel procedure ongoing. Shortened additional delay in soft handovers results in a
more optimal configuration of active sets. This may decrease the received uplink
interference in neighboring cells, which would be visible in the following counters:
• M1000C0 AVE_PRXTOT_CLASS_0
• M1000C2 AVE_PRXTOT_CLASS_1
• M1000C4 AVE_PRXTOT_CLASS_2

36 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

• M1000C6 AVE_PRXTOT_CLASS_3
• M1000C8 AVE_PRXTOT_CLASS_4

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
NA05845668

2.21 Change to RAN2302 Dynamic HSUPA BLER use


with RAN1645 HSUPA 16QAM
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: PR080244
Affected legacy features/functionality: RAN2302 Dynamic HSUPA BLER

Change description
In feature RAN2302 Dynamic HSUPA BLER the effective throughput (% of max UE
throughput) is measured by OLPC entities for the corresponding PS NRT RAB. In case
HSUPA 16QAM is used for PS NRT high enough peak rate is not typically reached and
thus the peak BLER state is not reached.
The change decreases by 50% the DynHSUPABLERMaxRateThrB and
DynHSUPABLERMaxRateThrC2 thresholds and rounds them up to the nearest integer
value for the Dynamic BLER usage with HSUPA 16QAM.

Expected impact
The change enables the HSUPA 16QAM connection to retrieve the peak BLER state
more easily.

Reason(s) behind the change


The change is needed to make an efficient use of Dynamic HSUPA BLER together with
HSUPA 16QAM. After the change, PS RB using HSUPA 16QAM will be moved more
easily to peak BLER state, using a lower BLER target.

Impacted counters/KPIs
The change is expected to decrease the value of the following counters:
• RNC_917a HSUPA MAC-e BLER

Type of change
The change is generic in the SW. It cannot be deactivated.

DN09100723 Issue: 05A © 2017 Nokia 37
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

UE dependency
n/a
Reference information
n/a

2.22 Correction to HS-DSCH channel type switch guard


timer handling when RB is mapped to 0/0
RUxx release(s) where the change is introduced
WCDMA16

Applicable SW versions
RNCRNC16
mcRNCmcRNC16

Relation to features or corrections


Affected legacy features/functionality:
RAN2172 Multi-Band Load Balancing, RAN2980 Measurement Based LTE Layering,
RAN2264 Smart LTE Handover

Change description
Change Request CR2241 enabled MBLB IFHO and LTE Compressed Mode
measurements to be run in scenarios where no existing user services with user plane
allocation (that is, DCH0/0 transport allocated for NRT-PS RAB). When a user having
HS-DSCH/E-DCH allocation is about to start compressed mode (CM) measurements,
but CM measurements with E-DCH transport channel allocation are not supported, then
user plane releases will also take place if PS RB is inactive when RNC initiates the E-
DCH release procedure as precondition for CM. In this HS-DSCH (with E-DCH) release
scenario, the legacy (Handover Control) algorithm will trigger the HS-DSCH channel type
switch guard timer, HSDSCHCTSwitchGuardTimer, in order to prevent immediate
reconfiguration attempts back to HS-DSCH.
This method of handling HSDSCHCTSwitchGuardTimer has been found to cause an
initial low throughput period for users whose activity resumes during the MBLB
IFHO/LTE CM measurement: in this cases HS-DSCH re-allocation is blocked, so that
only DCH/DCH transport is allowed, until the expiration of the guard timer. This delay is
not present in scenarios where the CR2241 change is not implemented, since CM
measurement are run with allocated HS-DSCH.
A change has been introduced into the HSDSCHCTSwitchGuardTimer handling in
Handover Control (HC): HC will not start HSDSCHCTSwitchGuardTimer when
reconfiguration to DCH0/0 is done due to TrCH mapping to 0/0. This allows HS-DSCH
usage to be resumed as soon as user inactivity ends.

Expected impact
Initial periods of low user throughput are avoided in scenarios where RAN2980,
RAN2264 or RAN2172 are enabled. User activity resumes during CM measurement on
DCH0/0 configuration.

38 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Reason(s) behind the change


HSDPA/HSPA accessibility degradation after CR2241 implementation.

Impacted counters/KPIs
The change is expected to decrease the values of the following counters:
• M1022C27 DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR
INTERACTIVE
• M1022C28 DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR
BACKGROUND

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
Rel. 5 onwards.

Reference information
n/a

2.23 HSUPA 2 ms TTI and/or F-DPCH can be allocated


even if RACH measurement result is missing
RUxx release(s) where the change is introduced
WCDMA16

Applicable SW versions
RNCRNC16
mcRNCmcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:
NA05791187, PR051453
Affected legacy features/functionality:
RAN1470: HSUPA 2 ms TTI
RAN1201: Fractional DPCH

Change description
Before this change, RNC did not allocate HSUPA 2 ms TTI/F-DPCH in state transitions
from common channels to CELL_DCH state when RRC cell update message did not
include RACH measurement results. This caused frequent radio bearer reconfiguration
with E-TTI change from 10 ms to 2ms and/or F-DPCH allocations, when the first
event/periodic measurement report received in CELL_DCH state includes CPICH EcNo
and CPICH RSCP measurement results. Many of these reconfigurations were
unnecessary and diminished uplink bit rate during the initial ramp-up phase of the call.

DN09100723 Issue: 05A © 2017 Nokia 39
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

The lack of RACH measurement results is mainly seen in networks where Deferred
Measurement Control Reading is enabled, with WCEL parameter
DefMeasCtrlReadingset to 1.
The change ensures that, during E-DCH TTI selection in situations when either CPICH
EcNo or CPICH RSCP measurement results are not available in state transition to
CELL_DCH state, E-TTI 2 ms configuration is allocated if the calculated load-based
CPICH EcNo is greater than the value of parameter
LoadBasedCPICHEcNoThreEDCH2MS.
• The load-based CPICH EcNo calculation considers primary CPICH code power and
transmitted carrier power.
• The default value of parameter LoadBasedCPICHEcNoThreEDCH2MS is 0, which
ensures that E-TTI=2 ms TTI cannot be allocated during state transitions to
CELL_DCH if RACH measurement results are missing.
• 2 ms TTI usage can be increased by setting parameter
LoadBasedCPICHEcNoThreEDCH2MS to the recommended value of -8 dB.

The change enables the allocation of F-DPCH configurations without radio quality
criteria, for situations when either CPICH EcNo or CPICH RSCP measurement results
are not available in state transition to CELL_DCH.

Expected impact
E-TTI=2ms and F-DPCH can be allocated in state transition to CELL_DCH in case
CPICH EcNo and CPICH RSCP are not available.

Reason(s) behind the change


The change increases the amount of E-TTI=2ms, and increases the amount of F-DPCH
allocations. This results in better end user experience in networks were Measurement
Control Reading is enabled, reducing the number of unnecessary radio bearer
reconfigurations after state transitions to CELL_DCH.

Impacted counters/KPIs
The following counters are expected to increase:
• M1002C664ALLO_EDCH_SRB_SRNC
• M5000C320 MACE_PDUS_2MS_TTI
• M5000C321 MACE_PDUS_10MS_TTI
• M5000C322 MACE_PDU_DATA_2MS_TTI
• M5000C323 MACE_PDU_DATA_2MS_TTI

The following KPIs are expected to increase:
• RNC_2053a Avg HSUPA 10ms TTI Users
• RNC_2052a Avg HSUPA 2ms TTI Users
• RNC_1934a PS access failures due to UE
• RNC_1965a PS RAB retainability failures due to radio
• RNC_1963B PS RAB retainability due to UE

40 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Possible degradations caused by F-DPCH changes can be reduced by disabling
Deferred Measurement Control Reading, setting the value of WCEL parameter
DefMeasCtrlReading to 0.

g Note: This modification can add about 500 ms to CS call setup times.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
Rel. 6 UEs supporting HSUPA (E-TTI=2ms)
Rel.7 or newer UEs supporting F-DPCH

Reference information
n/a

2.24 F-DPCH allocation based on calculated EcNo if


RACH measurement result missing
RUxx release(s) where the change is introduced
WCDMA16

Applicable SW versions
RNCRNC16
mcRNCmcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:
PR085977
Affected legacy features/functionality:
RAN1201: Fractional DPCH

Change description
Before this change, it was possible to perform F-DPCH allocations in scenarios where no
radio quality checking was performed during state transition to CELL_DCH, without
receiving UE RACH measurement results. These measurement results were most
frequently missing in networks with enabled Deferred Measurement Control Reading,
having WCEL parameter DefMeasCtrlReading set to 1. This kind of F-DPCH
allocations resulted in PS access and retainability problems
The change ensures that whenever common pilot channel (CPICH) EcNo or CPICH
RSCP measurement results are not available during the state transition to CELL_DCH,
F-DPCH can only be allocated if the calculated load-based CPICH EcNo value is greater
than the value defined by parameter LoadBasedCPICHEcNoSRBHSPA.

DN09100723 Issue: 05A © 2017 Nokia 41
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

• The load-based CPICH EcNo calculation considers primary CPICH code power and
transmitted carrier power.
• The default value of parameter LoadBasedCPICHEcNoSRBHSPA is -25 dB, which
from the radio condition point of view still allows F-DPCH allocations in sub-optimal
conditions.
• After the change, the recommended value for parameter
LoadBasedCPICHEcNoSRBHSPA is -8 dB.

Expected impact
Radio quality criteria are taken into account in the decision phase of F-DPCH allocations
in case no RACH measurement result are received during the state transition to
CELL_DCH. The recommended LoadBasedCPICHEcNoSRBHSPA value of -8 dB
ensures the decrease of blind F-DPCH allocations.
Overall usage of F-DPCH is expected to decrease.

Reason(s) behind the change


PS access and retainability improvements.

Impacted counters/KPIs
The following counters are expected to change:
• M1002C664ALLO_EDCH_SRB_SRNC
• M5000C321 MACE_PDUS_10MS_TTI

The following KPIs are expected to increase:
• RNC_2053a Avg HSUPA 10ms TTI Users
• RNC_1934a PS access failures due to UE
• RNC_1965a PS RAB retainability failures due to radio
• RNC_1963B PS RAB retainability due to UE

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
Rel.7 or newer UEs supporting F-DPCH.

Reference information
n/a

2.25 HSUPA E-TFCI amplitude ratio reference point and


power offset optimization to avoid usage of E-TFCI
124 in particular scenarios
Applicable SW versions

42 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

RNC RN8.1 4.0
RNC16 1.0
mcRNC mcRNC4.1 4.0
mcRNC16 1.0

Relation to features or corrections


Feature/fault correction introducing the change: Internal change.
Affected legacy features/functionality: Radio bearer setup and Radio bearer
reconfiguration procedures when E-DCH is configured with E-TTI=2ms and E-DPDCH
power interpolation method.

Change description
It was noticed that HSUPA E-TFCI amplitude ratio reference points for 2*SF2+2*SF4
when using E-DPDCH power interpolation and E-TTI=2ms were not optimal from the
BTS HSUPA scheduler point of view. These reference points presented high BLER,
mainly for E-TFCI 124. E-TFCI 124 from 2ms E-TFCI table 0 had poor decoding
performance at BTS and required higher UL power compared to E-TFCI 125. This
affected the peak throughput results with 2ms power interpolation UEs.
Legacy HSUPA power offset values for maximum allowed symbol rate 5760 ksps
(2*SF2+ 2*SF4) with E-TFCI table 0 were as follows:

E-TFCI value Amplitude ratio for E-DPDCH High bit rate


9 42/15
35 60/15
51 75/15
79 75/15
118 60/15
127 95/15

New HSUPA POs are defined to avoid usage of E-TFCI 124. After the change, HSUPA
power offset values for maximum allowed symbol rate 5760 ksps (2*SF2+ 2*SF4) with E-
TFCI table 0 are as follows:

E-TFCI value Amplitude ratio for E-DPDCH High bit rate


9 42/15
51 75/15
80 75/15
118 67/15
123 84/15
127 106/15

Expected impact
With the optimized HSUPA power offset for 2*SF2+2*SF4 set, usage of E-TFCI 124 can
often be avoided. The data transmission is more stable, with lower noise rise and lower
BLER, which results in an increase of peak throughput.

DN09100723 Issue: 05A © 2017 Nokia 43
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Reason(s) behind the change


With the optimized HSUPA power offsets the usage of E-TFCI 124 can be avoided.

Impacted counters/KPIs
As the change may increase throughput, the following counters can experience value
increases:
• M1001C733-M1017C57: USER UL THROUGHPUT DISTRIBUTION
The following HSUPA and HSDPA KPIs may increase:
• RNC_5460a: Average HSUPA user throughput
• RNC_1883c: Active HSUPA cell throughput
The following HSUPA KPIs may be reduced:
• RNC_917a: HSUPA MAC-e BLER

Type of change
The change is generic in the SW. EDPDCH Power Interpolation is controlled via PRFILE
parameter 002:1868 EDPDCHPowerInterUsage. Additionally, PRFILE parameter
002:2117 RU40_MAINT_2 can be modified to increase the maximum E-DCH bit rate
so that E-TFCI 124 can be avoided. See PRFILE descriptions (DN0948854) for further
information.

UE dependency
Rel-7 or newer UE supporting E-DPDCH power interpolation method and E-TTI 2ms.

Reference information
PRFILE descriptions (DN0948854)

2.26 Incorrect AC decision for NRT RB when channel


type switch to HSPA was performed
Applicable SW versions

RNC RN8.1
RNC16 1.0
mcRNC mcRNC4.1
mcRNC16 1.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05857496
Affected legacy features/functionality: Power based Admission Control for the HSUPA
PS call setups, RAN1905: DC-HSUPA

Change description
HSPA AC should deny HSUPA NRT RB allocation when the cell UL power is high and
the conditions of Power based Admission Control for the HSUPA call setups are
enabled. The function of this power based AC phase is to avoid high levels of UL
interference by limiting the NRT HSUPA allocations in the cell. In scenarios where

44 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

channel type switch (CTS) to HSPA was performed along with simultaneous SRB CTS to
HSPA or HSUPA, incorrect AC decisions for NRT RB were taking place.
• If there were no HS-DSCH resources requested from the CELL PS entity, HSUPA
AC failure of NRT RB was not handled correctly by the CELL PS entity and the
requests were incorrectly accepted. Despite the active conditions of Power based
Admission Control for the HSUPA call setups in the cell, allocation of HSPA NRT RB
was allowed in these CTS scenarios. If the SRB RB AC was successful but NRT RB
AC was not passed due to Power based Admission Control for the HSUPA, the CTS
request should have been rejected.
HSPA AC failure can happen in the following CTS scenarios, where both NRT and SRB
channel types are requested to be switched, and when the HS-DSCH (serving cell)
allocation does not exist in the new UE configuration under the CELL PS entity handling
the HSUPA AC.
1. NRT RB CTS requests from HSDPA to HSPA AND SRB RB CTS from DCH to
HSUPA or HSPA
When the HS-DSCH (serving cell) exists in the current UE configuration. AC failure
can happen in this case, if there are multiple RLs over multiple BTS for this UE and
the CELL PS entity is located in such BTS, where only HSUPA resources are
requested. So there are no HS-DSCH (serving cell) allocation under the CELL PS
entity of the new UE configuration.
2. NRT RB CTS requests from DCH to HSPA AND SRB RB CTS from DCH to HSUPA
or HSPA
When CTS is requested from R99 channel type,there is no existing serving cell
allocation for the UE. AC failure can happen in this case, if there are multiple RLs
over multiple BTS for this UE, and the CELL PS entity is located in such BTS, where
only HSUPA resources are requested.

Expected impact
After the introduction of this change, HSUPA AC does no longer allow NRT RB HSPA
allocations in the CTS when NRT RB allocation on HSPA channel type is denied by the
Power based Admission Control for the HSUPA call setups functionality. This is expected
to have a positive effect on RTWP levels, as interference levels decrease due to less L1
overhead in the UL.

Reason(s) behind the change


HSPA AC has been changed to correctly take into account NRT RB HSUPA AC
rejections in CTS scenarios where the SRB RB is simultaneously switched to HSPA or
HSUPA channel type.

Impacted counters/KPIs

• M1000C320 RECEIVED TOTAL WIDEBAND POWER CLASS 0 RTWP_CLASS_0
• M1000C321 RECEIVED TOTAL WIDEBAND POWER CLASS 1 RTWP_CLASS_1
• M1000C322 RECEIVED TOTAL WIDEBAND POWER CLASS 2 RTWP_CLASS_2
• M1000C323 RECEIVED TOTAL WIDEBAND POWER CLASS 3 RTWP_CLASS_3
• M1000C324 RECEIVED TOTAL WIDEBAND POWER CLASS 4 RTWP_CLASS_4
• M1000C325 RECEIVED TOTAL WIDEBAND POWER CLASS 5 RTWP_CLASS_5
• M1000C326 RECEIVED TOTAL WIDEBAND POWER CLASS 6 RTWP_CLASS_6
• M1000C327 RECEIVED TOTAL WIDEBAND POWER CLASS 7 RTWP_CLASS_7
• M1000C328 RECEIVED TOTAL WIDEBAND POWER CLASS 8 RTWP_CLASS_8
• M1000C329 RECEIVED TOTAL WIDEBAND POWER CLASS 9 RTWP_CLASS_9

DN09100723 Issue: 05A © 2017 Nokia 45
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

• M1000C330 RECEIVED TOTAL WIDEBAND POWER CLASS 10 RTWP_CLASS_10
• M1000C331 RECEIVED TOTAL WIDEBAND POWER CLASS 11 RTWP_CLASS_11
• M1000C332 RECEIVED TOTAL WIDEBAND POWER CLASS 12 RTWP_CLASS_12
• M1000C333 RECEIVED TOTAL WIDEBAND POWER CLASS 13 RTWP_CLASS_13
• M1000C334 RECEIVED TOTAL WIDEBAND POWER CLASS 14 RTWP_CLASS_14
• M1000C335 RECEIVED TOTAL WIDEBAND POWER CLASS 15 RTWP_CLASS_15
• M1000C336 RECEIVED TOTAL WIDEBAND POWER CLASS 16 RTWP_CLASS_16
• M1000C337 RECEIVED TOTAL WIDEBAND POWER CLASS 17 RTWP_CLASS_17
• M1000C338 RECEIVED TOTAL WIDEBAND POWER CLASS 18 RTWP_CLASS_18
• M1000C339 RECEIVED TOTAL WIDEBAND POWER CLASS 19 RTWP_CLASS_19
• M1000C340 RECEIVED TOTAL WIDEBAND POWER CLASS 20 RTWP_CLASS_20
• M1000C341 RECEIVED TOTAL WIDEBAND POWER CLASS 21 RTWP_CLASS_21

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
TS-RNC-SW-159 : Recommended parameter set and enhanced algorithms for
optimizing RRM functionalities
TS-RNC-SW-137 : Admission control modifications

2.27 Correction of activation time in coincidence of IMEI


query and serving cell change
Applicable SW versions

RNC RNC16 2.0
mcRNC mcRNC16 2.0

Relation to features or corrections


Feature/fault correction introducing the change: PR114255
Affected legacy features/functionality: RAN3082: Device Detection

Change description
The introduction of feature RAN3082: Device Detection has caused that in some rare
situations the coincidence of the IMEI query of device detection and of a serving cell
change (SCC) procedure (type of active setup update (ASU) procedure) can lead to a
failure of the first PS RAB setup and of the ASU procedure, and possibly to dropping of
the call.
The problem can happen when PS RAB establishment need initiates the call setup or
state transition to the Cell DCH state, and when for the PS RAB setup an IMEI query is
launched after going to DCH state, and when also radio conditions in the DCH state
immediately necessitate an SCC-ASU procedure, which uses activation time.
A standard correction for the problem is now introduced to the SCC-ASU procedure.

46 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Expected impact
After the introduction of this change, users will experience less call drops or RAB setup
failures when RAN3082: Device Detection is activated. Operators will notice less call
drops, SCC-ASU failures and RAB setup failures when RAN3082: Device Detection is
activated.

Reason(s) behind the change


Due to the IMEI query of feature RAN3082: Device Detection, this change is necessary
in order to avoid call performance degradation.

Impacted counters/KPIs
When the ASU procedure fails due to the problem following counters can be
incremented:
• M1006C124 AS_UPDATE_RL_ADD_NOREPLY
• M1008C217 SCC_FAILED_DUE_TO_UE
• M1007C60 UNSUCC_UPDATES_ON_SHO_HSDPA
• M1007C16 UNSUCC_UPDATES_ON_SHO_FOR_RT
If call is released because of the problem, then following is incremented:
• M1001C21 RRC_CONN_ACT_FAIL_RNC
When RAB setup was ongoing and it also failed due to the problem, then following
counters can be incremented:
• M1001C112 RAB_STP_FAIL_PS_BACKG_RNC
• M1001C107 RAB_STP_FAIL_PS_INTER_RNC
Following Capacity & Performance KPIs can be impacted:
• Call Completion Success
• Handover Success
• Call Setup Success

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN3082: Device Detection

2.28 E-UTRA Capability Enquiry Changes


Applicable SW versions

RNC RN8.1 4.0
RNC16 1.0
mcRNC mcRNC4.1 4.0
mcRNC16 1.0

Relation to features or corrections


Feature/fault correction introducing the change:

DN09100723 Issue: 05A © 2017 Nokia 47
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

n/a
Affected legacy features/functionality:
• RAN1797 Common Channel Setup
• RAN2264 Smart LTE Handover
• RAN2717 Smart LTE Layering
• RAN2980 Measurement based LTE Layering

Change description
The following changes are introduced:
• E-UTRA capabilities of the user equipment (UE) are only requested for a limited set
of LTE frequency bands.
• When E-UTRA capabilities are requested from the UE during RRC connection setup
procedure, the SRBs are either:
– mapped to dedicated channel (DCH) using 13.6 kbit/s bit rate (if SRB DCH 13.6
kbit/s experiences congestion, 3.4 kbit/s may be retried and even if DCH 3.4
kbit/s SRB is allocated the E-UTRA capabilities are still requested)
– mapped to enhanced dedicated transport channel (E-DCH) in UL (in Cell_FACH
or Cell_DCH state)

• If the UL SRB is not mapped to E-DCH (in Cell_FACH or Cell_DCH state), E-UTRA
capabilities of the UE are not requested with the UE Capability Enquiry procedure.
• Handover to LTE is prevented when E-UTRA capabilities of the UE are not available.
• E-UTRA capabilities of the UE are not requested in emergency call cases.

Expected impact
RRC Connection Setup KPI is expected to improve.
The Spreading Code Blocking rate in DL KPI might deteriorate.

Reason(s) behind the change


With the increased number of supported E-UTRA bands and consequent number of CA
combinations, the UE E-UTRA Capability IE in the RRC CONNECTION SETUP
COMPLETE message has increased. If the maximum RRC message size is exceeded
and the RRC connection setup time is increased, RRC connection setup failures might
occur. The issue is expected to have a big impact on upcoming UE models. The change
permits the enquiry of E-UTRA capabilities of the UE only for a limited set of LTE
frequency bands, with fast SRB, or both.
To also prevent UE Capability Enquiry procedure failure because of the size of UE E-
UTRA Capability IE, the procedure is triggered only when fast SRB is available.
UE E-UTRA Capability is not normally required in emergency call cases. If UE E-UTRA
Capability is not available, the handover to LTE is not triggered.

Impacted counters/KPIs
The following KPI might deteriorate:
• Spreading Code Blocking rate in DL

48 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

The following KPI is expected to improve:
• Sum of RRC Connection Setup Time

The usage of the following counters is expected to increase:
• M1006C23 RRC_CONN_SETUP_COMP_SENT
• M1002C8 DCH_ALLO_LINK_13_6_SRNC

The usage of the following counters is expected to decrease:
• M1006C20 RRC_CONN_RQ_FAIL
• M1002C7 DCH_ALLO_LINK_3_4_SRNC

Type of change
The changes are activated by default. The changes can be deactivated by PRFILE
parameter 002:2136 RU40_MAINT_40 except the emergency call change.

UE dependency
Only Release 10 or newer UEs support E-UTRA capability enquiry for a limited set of
LTE frequency bands.

Reference information
PRFILE descriptions (DN0948854)

2.29 Activation time increase if unsent PDUs in RLC


buffer
Applicable SW versions

RNC RNC16 2.0
mcRNC mcRNC16 2.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05894654
Affected legacy features/functionality: Synchronized RRC procedures

Change description
In the problematic scenario, there were PDUs of previous RRC messages still in RLC
transmission buffers when serving cell change was attempted with
RRC:RadioBearerReconfiguration. The calculation of the activation time for the
RRC:RadioBearerReconfiguration did not take into account that the PDUs in the
RLC buffer must be sent first, and they will delay the sending of
RRC:RadioBearerReconfiguration. If the delay was big enough, then the UE
could not receive the RRC:RadioBearerReconfiguration before the activation
time expired, and the UE went out of synch with BTS, which had already taken the new
configuration into use.

DN09100723 Issue: 05A © 2017 Nokia 49
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

The problem is corrected so that the activation time is increased if there are unsent
PDUs in the RLC transmission buffer.

Expected impact
When the activation time for the RRC:RadioBearerReconfiguration is increased
in case there are unsent PDUs in RLC transmission buffer, then the UE will not go out of
synch so easily with the BTS.

Reason(s) behind the change


Probability of out-of-synch situations can be decreased.

Impacted counters/KPIs
The following are the affected counters:
• M1008C217 HS-DSCH SERVING CELL CHANGES FAILED DUE TO UE
• M1022C63 HS-DSCH/E-DCH PACKET CALL REL DUE TO OTHER FAIL
FOR INTERACTIVE
• M1022C64 HS-DSCH/E-DCH PACKET CALL REL DUE TO OTHER FAIL
FOR BACKGROUND
• M1022C65 HS-DSCH/DCH PACKET CALL REL DUE TO OTHER FAIL FOR
INTERACTIVE
• M1022C66 HS-DSCH/DCH PACKET CALL REL DUE TO OTHER FAIL FOR
BACKGROUND

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.30 CM activation time correction


Applicable SW versions

RNC RNC16 3.0
mcRNC mcRNC16 3.0

Relation to features or corrections


Feature/fault correction introducing the change: PR153828

Change description
It has been seen that with RU50EP1 SW, the calls are dropped more often after
compressed mode (CM) activation. Calls have been continuing well as long as the last
“old” active set cell has been good enough and has not been removed from the active
set. In these calls that are dropped after CM activation, new soft handover branches that
are added into active set the CM timing has been different, which leads to different timing
between the UE and BTS.

50 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Two cases were detected which may cause different timing between the UE and BTS
and these are now corrected:
• CM timing calculated similarly regardless of RNC RLC DL buffer status. RNC RLC
DL buffer status is already taken into account in activation time calculation. It is
corrected, so that now, CM timing is also calculated similarly with information of RNC
RLC DL buffer status (CM activation time delayed based on DL buffering status).
Implementation was similar already in RU40 SW, but this problem may occur more
often with RU50EP1 SW because, for example, combined CTS+CM procedure is
used and may cause that more often measurement control messages are buffered in
DL RNC RLC buffer before the active set update happens.
• In RN8.1 3.0 SW, “SFN start time” is not updated along with RB reconfiguration.
When the new RL was setup with “old SFN start time”, it can cause timing
differences between the CM activation timing done, along with RB reconfiguration,
and with the new SHO branch. It has been corrected so that “SFN start time” is
updated during RB reconfiguration.

Expected impact
When the CM timing problem corrected in the scenario in question, there will be less
AMR call drops and mute calls.

Reason(s) behind the change


With the CM timing problem correction, AMR call drops and mute calls can be
decreased.

Impacted counters/KPIs
The following counters are affected:
• M1001C146 RAB ACTIVE FAILURES DUE TO RADIO INT FOR CS VOICE
• M1007C16 UNSUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT
TRAFFIC
• M1006C186 RRC RE-ESTABLISH SUCCESS RT
• M1006C187 RRC RE-ESTABLISH FAIL UE RT
• M1006C188 RRC RE-ESTABLISH FAIL NO REPLY RT
• M1006C189 RRC RE-ESTABLISH SUCCESS MULTI RAB
• M1006C190 RRC RE-ESTABLISH FAIL UE RT
• M1006C191 RRC RE-ESTABLISH FAIL NO REPLY RT

The following KPIs are affected:
• RNC_410d RAB Active FR for CS Voice due to Radio
• RNC_2726a Unsuccessful Inter-Frequency HO, RT
• RNC_2727a Unsuccessful Inter-Frequency HO, NRT
• RNC_2728a RRC conn drops Inter-Frequency HO, RT
• RNC_2729a RRC conn drops Inter-Frequency HO, NRT
• RNC_2715a Unsuccessful Inter-system handover, RT
• RNC_2716a Unsuccessful Inter-system handover, NRT
• RNC_2717a Connection drops during ISHO, RT
• RNC_2718a Connection drops during ISHO, NRT

DN09100723 Issue: 05A © 2017 Nokia 51
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.31 HS-DSCH/E-DCH setup with "dummy" PS RAB


reconfiguration from PS CN corrected
Applicable SW versions

RNC RNC16 3.0
mcRNC mcRNC16 3.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05906946
Affected legacy features/functionality: CRE1262 SDU Error Ratio modification

Change description
The problem was that during PS User Plane setup, the RRC received the so called
"dummy" PS RAB reconfiguration (no parameter change) from PS CN, and as a result of
this, the RRC cleared the ongoing UP setup status from its internal data structures. This
led to a situation where the RRC had wrong information about the resources configured
for the service in question.
The fault has now been corrected to RRC so that if there is a PS RAB reconfiguration
request where RAB parameters are not changed, then the RRC will not remove ongoing
procedures from its internal tables.

Expected impact
With this correction, the RRC will have correct information about the resources
configured for the service in question. With the correct information, there will not be
delays in data transfer.

Reason(s) behind the change


With help of this correction, delays in data transfer can be avoided in the scenario in
question.

Impacted counters/KPIs
Affected counters:
• M1002C413 HS-DSCH SETUP FAILURE DUE TO RNC INTERNAL FOR
INTERACTIVE
• M1002C529 E-DCH SETUP FAILURE DUE TO OTHER REASONS FOR
INTERACTIVE

Type of change

52 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.32 RAN2980 Measurement Based LTE Layering


Change for Handling CS Call Release without PS
RAB
Applicable SW versions

RNC RNC16 4.0
mcRNC mcRNC16 4.0

Relation to features or corrections


Feature/fault correction introducing the change:
RAN2980 Measurement Based LTE Layering change for handling CS call release
without PS RAB
Affected legacy features/functionality:
RAN2980: Measurement Based LTE layering

Change description
LTE redirection decision-making logic is changed for CS call release when PS RABs are
being setup simultaneously.
The preconditions for LTE redirection CS-only scenario where logic change takes effect
are:
• enabled RAN2980
• RNWDB LTELayeringMeasActivation = 1, measurement for all triggers
• enabled T3 trigger (CS RAB release)
• existing CS RAB
• non-existing PS RABs

Before WCDMA16, LTE redirection decision-making logic denied LTE redirection when
PS RAB was being setup during CS release (CS call ends causing CS RAB release). It
unnecessarily delayed the LTE transfer of the user equipment (UE) until the next LTE
redirection conforming the LTE trigger. From WCDMA16 onwards, LTE redirection
decision-making logic change addresses it by initiating blind LTE redirection instead of
denying LTE redirection.

Expected impact
For the end user, the change aims for faster transfer back to the LTE after the CS call in
the specific CS-only scenario.

Reason(s) behind the change

DN09100723 Issue: 05A © 2017 Nokia 53
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

For the end user, the change aims for faster transfer back to the LTE after the CS call in
the specific CS-only scenario.

Impacted counters/KPIs
If there is a PS RAB setup ongoing while LTE redirection is already initiated for the
specific CS-only scenario, PS RAB setup fails and the following counters are pegged:
• M1001C107 RAB SETUP FAILURES DUE TO RNC FOR PS DATA INTERAM
• M1001C112 RAB SETUP FAILURES DUE TO RNC FOR PS DATA BACKG
• M1001C71 RAB SETUP ATTEMPTS FOR PS DATA INTERA
• M1001C72 RAB SETUP ATTEMPTS FOR PS DATA BACKG

RNC_576e KPI Packet Service Setup Success Ratio (CSSR) is also impacted through


the following pegged counters:
• M1001C71 RAB SETUP ATTEMPTS FOR PS DATA INTERA
• M1001C72 RAB SETUP ATTEMPTS FOR PS DATA BACKG

Counters that increase in this context does not mean a defect. It means that PS RAB
setup is not possible anymore to 3G as the UE was already going to LTE. PS RAB setup
happens in LTE when the UE makes a successful LTE transfer.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.33 RRC unit overload control incorrectly interprets


slowness in RL setup as ICSU load
Applicable SW versions

RNC RNC16 3.0
mcRNC mcRNC16 3.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05920698, NA05931100
Affected legacy features/functionality: RNC overload control.

Change description
The RRC unit overload control algorithm interpreted RL setup slow responding BTS
falsefully as RNC itself, or its ICSU units were under overload. The algorithm was
already later corrected to RNC17 and mcRNC17 releases in such a way that external
non-RNC load factor cannot influence the algorithm behavior anymore. This is ensured
so that the RNC/ICSU load metrics that the algorithm uses as feedback information to
limit new RRC connection request attempts is based solely on metrics on how ICSU
handlers can keep up with the offered workload with the CPU time presently granted to
them.

54 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Expected impact
RNC capacity as number of voice calls and data calls, or its throughput will not be
compromised anymore, and no ICSU CPU utilization drop should occur anymore
because BTS responding slowly the RL setups.

Reason(s) behind the change


Customer fault report (RNC16) and complements in telecom PET test capability for
simulating slow responding BTS (RNC17, mcRNC17).

Impacted counters/KPIs
The fault and its correction impacts the following accessibility KPIs:
• Voice Call Setup Success Ratio (RRC+CU)
• Packet Service Setup Success Ratio (CSSR)
• ICSU (cRNC) CPU utilization
• USPU (mcRNC) CPU utilization

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.34 RRC unit overload control incorrectly interprets


radio resources congestion as ICSU load
Applicable SW versions

RNC RNC16 4.0
mcRNC mcRNC16 4.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05948460
Affected legacy features/functionality: RNC overload control

Change description
The RRC unit overload control algorithm that controls the admission of RRC connection
requests was not properly protected from an external (to ICSU/USPU) load factor that
resulted false (mimic) condition of ICSU/USPU unit processing latency for RRC
connection setups that is used as feedback loop for the window based control.
The missing protection for RRC unit overload mimic condition was caused delayed
responding RNC BTS specific RRM entity that under radio resource congestion can
perform queuing for SRB UP resource admittance. Such delayed procedure for RRC
connection setup on Cell_DCH will slow down RRC connection setup completion from
RRC overload control algorithm point of view, which in turn will slow down the servicing
of new RRC connection requests and decrease ICSU/USPU CPU utilization.

DN09100723 Issue: 05A © 2017 Nokia 55
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

The sufficient algorithm protection from such external load factor is now implemented
such way that RNC BTS specific RRM entity will provide interim ACK back to UE specific
RRM entity that in turn can now acknowledge back to RRC overload control algorithm
that RRM is queuing the SRB UP request and RRC algorithm does not need to wait for
its completion time that is not predictable.

Expected impact
RNC RRM entity AC performed queuing of SRB UP resource request and its
accumulated delays to RRC connection setup completion cannot anymore slow down
the RRC overload control algorithm servicing of new RRC connection requests when
there is no RRC unit overload present.

Reason(s) behind the change


A customer fault report (RNC16).

Impacted counters/KPIs
The fault and its correction impacts the following accessibility KPIs and RRC unit
utilization:
• Voice Call Setup Success Ratio (RRC+CU)
• Packet Service Setup Success Ratio (CSSR)
• ICSU (cRNC) CPU utilization
• USPU (mcRNC) CPU utilization

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.35 Improvement to NRT DCH Scheduling for Iur


Capacity Requests
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN3219/CR S2287 Obsolete Legacy
Feature Removals
Affected legacy features/functionality:
• NRT DCH setup/modification over Iur
• RAN1759 Support for I-HSPA Sharing and Iur Mobility Enhancements

56 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Change description
RAN1759 feature included two functionalities; Iur mobility Enhancements and support for
I-HSPA Sharing. In WCDMA16 I-HSPA sharing functionality is removed along with
RAN1759 license. During this removal NRT DCH scheduling over Iur changed as
described below.
Before WCDMA16, if RAN1759 license was not installed or was set OFF, NRT DCH
capacity requests for DRNC RLs was handled as follows:
• RT AC
• instant allocation
• higher prioritization over the SRNC NRT DCH allocations

In WCDMA16 RAN1759, license does not exist anymore and the handling is the same
as in the previous release when the RAN1759 license was installed and set ON. This is
generic change, and NRT DCH capacity requests for DRNC RLs are handled for now
always as follows:
• NRT DCH scheduling with max queuing time based on parameter WCEL-
CrQueuingTimeDL
• equal prioritization with SRNC NRT DCH allocations
There is no change in the handling if RAN1759 license was already installed and set on.

Expected impact
Improvement in the resource allocation of the RNC border area cells.

Reason(s) behind the change


Support for I-HSPA functionality has become obsolete so it was removed along with the
RAN1759 license.

Impacted counters/KPIs
If RAN1759 license has not been used earlier by network operator, then RL Reconf Prep
Sync IUR DCH Add SRNC Fail Rate and RL Reconf Prep Sync IUR DCH Mod SRNC
Fail Rate may increase.
RL Reconf Prep Sync IUR DCH Add SRNC Fail Rate (M1004C41-M1004C47) /
(M1004C41):
• M1004C41 RL RECONF PREP SYNCH OVER IUR FOR DCH ADD ON DRNC
• M1004C47 RL RECONF PREP SYNCH OVER IUR FOR DCH ADD ON DRNC
READY

RL Reconf Prep Sync IUR DCH Mod SRNC Fail Rate (M1004C42-M1004C48) /
(M1004C42):
• M1004C42 RL RECONF PREP SYNCH OVER IUR FOR DCH MOD ON DRNC
• M1004C48 RL RECONF PREP SYNCH OVER IUR FOR DCH MOD ON DRNC
READY

AC blocking may decrease for SRNC capacity requests, that is, AMR Call Setup
Success Ratio and Packet Session Setup Success Ratio may improve in RNC border
area cells.

DN09100723 Issue: 05A © 2017 Nokia 57
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.36 Paging Cell PCH SR degraded after DMCU resource


release
Applicable SW versions

RNC RNC16 4.0
mcRNC mcRNC16 4.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05930049, NA05931562
Affected legacy features/functionality: Paging on PCH

Change description
If the paging procedure is started, for example, due to DL DT messaging during the
DMCU resource release procedure in the Cell_PCH state, the counter
CELL_UPD_AFTER_PAG_CELL_PCH M1006C157 is not pegged when the UE
responds to paging. This is seen as degradation in paging success rate.
The problem is corrected so that RRC will not initialize the information about the ongoing
paging procedure after the DMCU resource release procedure, and the counter
CELL_UPD_AFTER_PAG_CELL_PCH M1006C157 will be updated appropriately in UE
response.

Expected impact
Paging SR will improve. See Impacted counters/KPI’s.

Reason(s) behind the change


If paging succeeds on PCH, then RRC should update counter M1006C157 and paging
SR should show correct values.

Impacted counters/KPIs
The counter M1006C157 CELL_UPD_AFTER_PAG_CELL_PCH is affected, as well as
the KPI RNC_1215b Pag Cell PCH SR.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

58 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

2.37 NBL Process priority change to avoid message que


accumulation during high traffic load in ICSU
Applicable SW versions

RNC RNC16 4.0
mcRNC Not applicable

Relation to features or corrections


Feature/fault correction introducing the change:
• PR166703: NBL responds too slowly because of message queue accumulation
• PR172799: NBL priory change (DXPARA)

Change description
A core programming block in IP signaling (NBL) responded too slowly because of
message queue accumulation due to high traffic load in ICSU.
This resulted in delayed message handling leading to negative impact on Radio link
setup and call setup KPIs.

Expected impact
Radio link setup fails on ICSU and call setup KPIs are affected during high traffic load on
ICSU.

Reason(s) behind the change


The program block (NBLSTC) was marked at a lower priority level. During high traffic
load in ICSU, due to strict DMX priority order based scheduling, the starving of lower
priority program blocks led to increase message que accumulation for these process.
The priority of the process involved in messaging (NBL) was increased from the current
level so that it avoids message queue accumulation and KPI impacts during high traffic
load conditions.

Impacted counters/KPIs
Reduction on Radio link setup failure on ICSU with high traffic load and improved call
setup KPIs.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

DN09100723 Issue: 05A © 2017 Nokia 59
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

2.38 Correction to premature E-DCH release due to


triggered CM measurement cause
Applicable SW versions

RNC RNC16 4.0
mcRNC mcRNC16 4.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05960795
Affected legacy features/functionality:
• HSUPA
• RAN1276 HSDPA Inter-frequency Handover

Change description
In the WCDMA16 release onwards, RNC may unnecessarily reconfigure uplink transport
channel from E-DCH to DCH when an HSPA Serving Cell Change (SCC) was triggered.
This happens due to an SW change in Handover Control implementation where a
triggered IFHO/GSM handover measurement cause is interpreted as a reason to drop E-
DCH allocation in SCC if HSPA Compressed Mode (RAN1668) is not supported by E-
DCH Active Set cells. E-DCH release at this time can, however, be unnecessary
because, depending on cell coverage and RNC configuration, a portion of triggered
IFHO/GSM handover causes never lead to IFHO/GSM measurement due to handover
trigger getting canceled (for example, due to cell improving) before the network can start
Compressed Mode.
With this GEN SW change, the functionality is reverted to what is in use prior to the
WCDMA16 release where E-DCH allocation is retained in SCC regardless of triggered
IFHO/GSM handover causes, and only released at the time IFHO/GSM Compressed
Mode measurement is to be started (in case HSPA Compressed Mode is not supported).

Expected impact
There is reduction in E-DCH releases performed due to Serving Cell change.

Reason(s) behind the change


This change was made to avoid unnecessary reconfiguration of uplink transport channel
from E-DCH to DCH when a HSPA Serving Cell Change (SCC) is triggered.

Impacted counters/KPIs
There is expected decrease in the following counters:
• M1002C537 E-DCH RELEASE DUE HS-DSCH SERVING CELL CHANGE FOR
INTERACTIVE
• M1002C538 E-DCH RELEASE DUE HS-DSCH SERVING CELL CHANGE FOR
BACKGROUND
• M1008C242 E-DCH DOWNGRADED TO DCH IN SCC

60 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

There is expected decrease in the following KPIs:
• E-DCH Rel HS-DSCH SCC (RNC_2013a)
• E-DCH Rel HS-DSCH SCC (RNC_2675a)

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
3GPP Rel-6 or newer UEs supporting E-DCH

Reference information
n/a

2.39 Frequency merge is not allowed in RAN2991


Applicable SW versions

RNC RNC16 3.0
mcRNC mcRNC16 3.0

Relation to features or corrections


Feature/fault correction introducing the change: PR143137
Affected legacy features/functionality: RAN2991 Modification of WCDMA frequency

Change description
Thre are two or more old frequencies within BTS that cannot be changed to the same
new frequency with RAN2991 functionality. That means the frequency merging is not
allowed in the same BTS. Before the change, frequency merging is allowed.

Expected impact
No KPI effect shall be experienced, but frequency merging would be prevented if
operator opts to do so.

Reason(s) behind the change


When more than two frequencies are merged in the cells under the same BTS to one
new frequency with RNW plan, the rollback to the original configuration of the WBTS with
back up RNW plan will fail. Then, it would be long time to recover the WBTS
configuration with cell deletion and recreation. This is unacceptable.

Impacted counters/KPIs
No impact to KPI and counter.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

DN09100723 Issue: 05A © 2017 Nokia 61
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

2.40 Removal of DMPG switch procedure for cell_fach


(HS) to cell_dch state transitions
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: CR#1005
Affected legacy features/functionality:
• cell_fach (HSFACH/HSRACH) -> cell_dch (rel99) state transition
• cell_fach (HSFACH/HSRACH) -> cell_dch (HS[D]PA) state transition
• cell_fach (rel99) -> cell_dch (rel99) state transition
• cell_fach (rel99) -> cell_dch (HS[D]PA) state transition

Change description
Currently, cell_fach (HS) <-> cell_dch (rel99) transition is performed using DMPG switch
procedure. The DMPG switch operation is a heavy task, hence, the CR#1005 was
implemented to avoid the DMPG switch operation for cell_fach (HS) <-> cell_dch (rel99)
state transition. This change was possible because of the fact that the resources for
cell_fach (HS) and cell_dch (rel99) was allocated from the same resource pool.
In order to keep the implementation logic simpler during CR#1005 phase, few changes
were made for overall cell_fach to cell_dch state transition. This resulted in sending the
RLC suspend (and resume) at later phase. Before CR#1005, the RLC suspend (and
resume) was sent much earlier.
For cell_fach (rel99/HS) -> cell_dch (HS[D]PA) state transitions, due to RLC suspend
happening at later phase, there is a possibility of increase in RLC DL PDUs being
discarded for unacknowledged PDUs.

Expected impact
The following are the expected impacts:
• DMPG switch procedure is removed for cell_fach (HS) <-> cell_dch (rel99) state
transitions.
• For cell_fach(rel99/HS) to cell_dch(HS(D)PA) state transitions, there are possibility of
increase in RLC DL UNACKED PDUS discarded at the source user plane.

Reason(s) behind the change


DMPG switch procedure was a heavy task for cell_fach (HS) <-> cell_dch state
transition.

Impacted counters/KPIs
There is an expected increase for the counter M1022C246.

62 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
CR#1005

2.41 Incorrect UL NRT DCH bitrate limitation for HSDPA


RB in DRNC RL
Applicable SW versions

RNC RNC16 5.0
mcRNC mcRNC16 5.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05976376
Affected legacy features/functionality: Cell-specific Packet scheduler

Change description
Cell-specific packet scheduling functionality (CELL PS) determines incorrectly the UL
channel type of the HSDPA radio bearer for DRNC radio links if there is no HSDPA
serving cell allocated in DRNC DCH Active Set (AS) cells. This causes that CELL PS to
use incorrect maximum bitrate parameter in admission decision (that is,
MaxBitRateULPSNRT instead of HSDPAMaxBitrateUL). If MaxBitRateULPSNRT
is smaller than HSDPAMaxBitrateUL, then CELL PS unnecessarily limits and rejects the
capacity request in DRNC.
Additionally, PS rejection counters for UL direction were always updated regardless of
the type of the request. If the capacity was requested for DL direction in DRNC, counters
REQ_PS_INTERA_REJ_UL_SRNC M1002C92 or REQ_PS_BACKG_REJ_UL_SRNC
M1002C94 were updated instead of REQ_PS_INTERA_REJ_DL_SRNC M1002C93 or
REQ_PS_BACKG_REJ_DL_SRNC M1002C95.

Expected impact
CELL PS defines the channel type correctly for capacity requests in DRNC and uses the
correct parameter when defining the maximum bitrate for radio bearer. Thus, the
capacity request is not unnecessarily rejected in DRNC due to max bitrate setting in the
DRNC cell.
In addition, updating of PS rejection counter is corrected to be done based on the
direction for DRNC requests. The direction of the updated counter selected from the
requested bitrates:
• When higher than the current bitrate is requested only in one direction, the counter of
that direction is updated.
• When higher than the current bitrate is requested in both directions, the counter
direction is defined from the higher requested bitrate direction.

DN09100723 Issue: 05A © 2017 Nokia 63
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Other cases the direction is specified to be UL.

Reason(s) behind the change


Correction of the fault NA05976376.

Impacted counters/KPIs
In RNC border area, the following UL PS rejection counters are increased when
MaxBitRateULPSNRT is smaller than HSDPAMaxBitrateUL. These counters are
also increased if there is DL capacity request rejections in DRNC:
• REQ_PS_INTERA_REJ_UL_SRNC M1002C92
• REQ_PS_BACKG_REJ_UL_SRNC M1002C94

The following counters show too low value (DL rejections are incorrectly counted to UL
rejection counters):
• REQ_PS_INTERA_REJ_DL_SRNC M1002C93
• REQ_PS_BACKG_REJ_DL_SRNC M1002C95

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.42 UL Interference correction for RAN3086 CSFB with


RIM
Applicable SW versions

RNC RNC16 5.0
mcRNC mcRNC16 5.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05961002
Affected legacy features/functionality: RAN3086: CSFB with RIM

Change description
RNC gives the minimum value of -110dBm to BTS in Cell setup phase for the initial UL
interference in SIB7. After the cell setup phase, RNC does not register the changes in
UL interference from RIM point of view as BTS has the control for UL interference
adjustment in a cell.
In RIM, system information procedure RNC reports, on the request of the eNB, the MIB,
SIB1, SIB3, SIB5, SIB7 of a cell to eNB. The eNB (Node B in LTE system) can use the
system information of the RNC for directing the UE to the 3G cell with RRC

64 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

CONNECTION RELEASE (Utra BCCH container -Rel9), so that the UE will read the
system information of the 3G cell from the release message. This is supposed to
accelerate the CSFB procedure.
RNC is always reporting the -110dBm to the eNB in RIM procedure. -110dBm as the
initial value for UL interference in the cell is not optimal for UEs in CSFB when traffic
exists or the cell is loaded.
After the PR NA05961002 correction, RNC uses the value -100 dBm as the static value
for the UL Interference of SIB7 in System Information report to eNB.
The value can be adjusted with the PRFILE parameter 002:2152 RU40_MAINT_56
(scale from -110 dBm to -70 dBm, default value = -100 dBm). See the PRFILE
Descriptions document for more information.

Expected impact
If the RAN3086 CSFB with RIM feature is used, the UEs that are doing the CSFB from
LTE to 3G are expected to be gaining from the correction. As the reported UL
interference value in RIM procedure is more suitable for CSFB, the UEs can have faster
access to the common channels of the 3G cell.

Reason(s) behind the change


A UL interference value that is too low was used in the RIM procedure.

Impacted counters/KPIs
No counter or KPI impacts

Type of change
The change is generic in the SW. The change can be, however, deactivated by using the
minimum value of UL interference (-110 dBm). This can be done by setting the PRFILE
Parameter 002:2152 RU40_MAINT_56 to the value “6EH”.

UE dependency
LTE-capable Rel-9 UEs

Reference information
Refer to PR NA05961002 for more information. Refer to the PRFILE Descriptions
document for the activation of the correction.

2.43 Correction to decoding of TFCS from RRC


container in incoming HHO
Applicable SW versions

RNC RNC16 5.0
mcRNC mcRNC16 5.0

Relation to features or corrections


Feature/fault correction introducing the change: PR201102

DN09100723 Issue: 05A © 2017 Nokia 65
   

Algorithm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Affected legacy features/functionality: Incoming inter-RNC HHO

Change description
Without the correction, inter-RNC HHOs may fail if all RBs are mapped to HSPA so that
DCH channel TFCS information is not present in the RRC container. This can happen if
the UL/DL Common Transport Channel Information element is present but it is empty in
the RRC container. Failure causes that UE-specific RRC hand process to crash (1080
alarm seen) when it attempts to decode the non-existing TFCS information. It seems that
Nokia RNC does not, as source RNC, include the common transport channel information
in the RRC container if the element would be empty. So we may encounter the problem
when the source RNC is an RNC of some other vendor.
The correction is that TFCS is not attempted to decode from the common transport
channel information of RRC container of the IU RELOCATION REQUEST message if the
TFCS is not included. Hence, the crash will not happen.

Expected impact
With this correction, the HHO should succeed in these cases.

Reason(s) behind the change


This is an obvious coding error in Nokia target RNC.

Impacted counters/KPIs
With this correction, (actual) KPI Handover success is expected to improve. The
measured KPI value may not be affected since, due to the crash, the UE-specific RRC
hand process may be unable to update the counters affecting the KPI.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

2.44 AMR CDR degraded due to incorrect calculation of


TGCFN during anchoring CM after IFHO over Iur
Applicable SW versions

RNC RNC16 5.0
mcRNC mcRNC16 5.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05984084, NA05978439
Affected legacy features/functionality: Compressed mode, Anchoring, IFHO over Iur

Change description

66 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Algorithm changes
Counters and KPIs

For NA05984084, the Transmission Gap Connection Frame Number (TGCFN) for new
RL setup/addition was calculated incorrectly during anchoring CM after IFHO over Iur.
This means that the new RL will not work properly during CM and can cause a call drop.
The problem is that the current CFN used for calculating TGCFN is derived from the CM
reference cell SFN and frame offset, but the frame offset is not valid anymore after IFHO
over Iur because the CFN is reinitialized during IFHO. The fault was corrected so that the
current CFN is asked from frame protocol when a new SHO branch is added during
anchoring CM, and it is used for calculating TGCFN.
For NA05978439, when the active Transmission Gap Pattern Sequence (TGPS) is
changed during anchoring CM, RNC saves the incorrect SFN. When a new RL setup is
done after it, the TGCFN in RL setup can be wrong, which means that the new RL does
not work properly and the call can drop. Also, after IFHO over Iur if CM is started in
anchoring during some other reconfiguration procedure or other reconfiguration is done
during anchoring CM, RNC can save the incorrect SFN, which can cause using wrong
TGCFN in next RL setups. The fault was corrected so that RNC saves the correct SFN
also during these anchoring CM scenarios.

Expected impact
AMR CDR will improve during anchoring.

Reason(s) behind the change


After the correction AMR calls do not drop so easily during anchoring.

Impacted counters/KPIs
The following counters are affected:
• M1001C146 RAB_ACT_FAIL_CS_VOICE_RADIO
• M1001C58 CALL_RE_ESTAB_ATTS

The following KPIs are affected:
• RNC_231d RAB Success ratio CS Voice
• RNC_410d RAB Active FR for CS Voice due to Radio

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
NA05984084, NA05978439

DN09100723 Issue: 05A © 2017 Nokia 67
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

3 Counter changes

3.1 Correction to failed incoming inter-RAT handovers


and its impact on counters and KPIs
RUxx release(s) where the change is introduced
RU40, RU50 / RU50EP1, WCDMA 16

Applicable SW versions

RNC RU40 RN7.0 5.0


RU50 RN8.1
WCDMA 16 RNC16
mcRNC RU40 mcRNC3.0 3.0
RU50 mcRNC4.1
WCDMA 16 mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:
NA05716787, 122588ESPE04, 124607ESPE04, NA05789380, NA05802104
Affected legacy features/functionality:
HSPA setup, Inter-System Handovers (ISHO)

Change description
When a UE moves to 3G from another RAT through an incoming relocation procedure,
UTRAN receives a successful handover completion message from the UE. This first
uplink message (RRC HANDOVER TO UTRAN COMPLETE) indicates that the UE has
accepted the provided configuration and has entered connected mode in Cell_DCH in
UTRAN. This is considered as successful handover. A handover to UTRAN is
considered successful even if the UE failed to enter Cell_DCH state (for example, failed
L1 sync procedure), as long as the UE accepted the configuration and updated the
stored UTRAN radio network temporary identifiers (RNTIs).
Earlier RNC implementations tried and failed to re-establish the call when the RNC
received a Cell Update message from the UE during the incoming inter-system handover
procedure to 3G. The UE kept re-transmitting Cell Update messages until it entered idle
mode after having retransmitted all the allowed Cell Update messages. As a result,
failure handling could not be done correctly in UTRAN. Consequently also incorrect
counters were updated in this failure scenario.
UTRAN failure handling has been now corrected in the RNC. The change ensures that
the RNC updates the successful handover counters and then initiates call release for
failure handling, in case the RNC receives Cell Update message with cause “radio link

68 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

failure “ or “RLC unrecoverable error“ during an ongoing LTE-to-UTRAN or GSM-to-
UTRAN handover. This call release will be updated in the KPIs as a UE-caused drop for
CS and/or PS RABs.

Expected impact
The correction modifies the RNC behavior during incoming inter RAT handover so that if
UTRAN receives a CELL UPDATE from the UE instead of HANDOVER TO UTRAN
COMPLETE, it is counted as a successful incoming ISHO and then the call is eventually
released after the completion of ISHO signaling. These call releases will have impact on
the retainability KPIs.
No major impact to the end user experience is expected.

Reason(s) behind the change


Call setup and ISHO counters were being updated incorrectly before the correction.

Impacted counters/KPIs
The following counters may increase:

• M1001C391 RRC ACTIVE FAIL DUE TO UE
• M1001C392 RAB ACTIVE FAILURES DUE TO UE FOR CS VOICE
• M1001C397 RAB ACTIVE FAILURES DUE TO UE FOR PS DATA INTERA
• M1001C398 RAB ACTIVE FAILURES DUE TO UE FOR PS DATA BACKG

The following KPIs may be degraded due to the correction:
• RNC_217f RRC Success Ratio (%)
• RNC_231d RAB Success Ratio CS Voice (%)
• RNC_5434A RAB Success Ratio, Voice(CSR) (re-establishment included) (%)
• RNC_615c RAB Success Ratio, NRT Services, from Network Perspective
• RNC_736b RAB Success Ratio, NRT Services
• RNC_1070c_RAB_ACT_FR_VOICE_UE (%)

Additional change impact depends on which SW version was present prior to the update:

• In RU40 releases RN7.0 3.0 or RN7.0 4.0, the “normal release” counter was pegged
instead of the “active failure due to UE” counter. After the update toRNC16 these
counters are expected to present slightly lower values:
– M1001C12 RRC_CONN_ACT_COMP
– M1001C136 RAB_ACT_COMP_CS_VOICE
– M1001C141 RAB ACTIVE COMPLETIONS FOR PS DATA INTERA
– M1001C142 RAB ACTIVE COMPLETIONS FOR PS DATA BACKG

g Note: The absolute decrease is expected to be very small in comparison to the overall
amount of “normal releases”. This decrease might not become clearly visible in
statistics.
Changes in the Packet Call release cause lead to a redistribution of counter values.
These counters are expected to increase:

DN09100723 Issue: 05A © 2017 Nokia 69
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

– M1022C63 HS-DSCH/E-DCH PACKET CALL REL DUE TO OTHER FAIL FOR
INTERACTIVE
– M1022C64 HS-DSCH/E-DCH PACKET CALL REL DUE TO OTHER FAIL FOR
BACKGROUND
These counters are expected to decrease by the same amount:
– M1022C57 HS-DSCH/E-DCH PACKET CALL REL DUE TO RL FAIL FOR
INTERACTIVE
– M1022C58 HS-DSCH/E-DCH PACKET CALL REL DUE TO RL FAIL FOR
BACKGROUND

• Earlier RU40 releases (<RN7.0 3.0) incorrectly pegged setup failure counters. The
following counters are expected to show lower values after updating to RNC16:
– M1002C530 E-DCH SETUP FAILURE DUE TO OTHER REASONS FOR
BACKGROUND
– M1002C529 E-DCH SETUP FAILURE DUE TO OTHER REASONS FOR
INTERACTIVE
– M1002C606 E-DCH SETUP FAILURE DUE TO OTHER REASONS FOR
STREAMING
– M1002C639 HS-DSCH SETUP FAILURE DUE TO OTHER REASONS FOR CS
VOICE
– M1002C643 E-DCH SETUP FAILURE DUE TO OTHER REASONS FOR CS
VOICE
– M1002C421 HS-DSCH SETUP FAILURE DUE TO RNC INTERNAL FOR
BACKGROUND
– M1002C413 HS-DSCH SETUP FAILURE DUE TO RNC INTERNAL FOR
INTERACTIVE
– M1002C581 HS-DSCH SETUP FAILURE DUE TO RNC INTERNAL FOR
STREAMING
– M1001C220 NUMBER OF UNSUCCESSFUL INTER SYS HHO ATTEMPTS
This could be seen as an improvement of following KPIs:
– RNC_605b HSDPA Accessibility for NRT Traffic from User point of View (%)
– RNC_913b HSUPA Resource Accessibility for NRT Traffic (%)

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
Fault analysis for NA05716787, NA05789380 and NA05802104.

3.2 Corrected value of Counter M1005C252 MAC-D


SETUP ATTEMPT FOR DC-HSDPA when Secondary
Serving HS-DSCH is removed from a call
Applicable SW versions

70 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

RNC RN8.1 4.0
RNC16 1.0
mcRNC mcRNC4.1 4.0
mcRNC16 1.0

Relation to features or corrections


Feature/fault correction introducing the change:  PR121030
Affected legacy features/functionality: RAN1906: Dual-Cell HSDPA 42Mbps

Change description
NBAP updates its DC-HSDPA MAC-D setup counters when Secondary Serving HS-
DSCH is added to a call, but it also incorrectly updates one of the counters when it is
removed. After this change the removal operation does not affect the counters.

Expected impact
The value of the counter M1005C252 MAC-D SETUP ATTEMPT FOR DC-HSDPA is
expected to be decreased and match with the related counters M1005C253
SUCCESSFUL MAC-D SETUP FOR DC-HSDPA and M1005C254 FAILED MAC-D
SETUP FOR DC-HSDPA.

Reason(s) behind the change


Counter M1005C252 MAC-D SETUP ATTEMPT FOR DC-HSDPA was incorrectly
updated.

Impacted counters/KPIs

• M1005C252 MAC-D SETUP ATTEMPT FOR DC-HSDPA

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN1906: Dual-Cell HSDPA 42Mbps

3.3 Sending of RB mappings to UE corrected in state


transition from cell PCH state (Rel99 cell) to cell
FACH state (HS-FACH/HS-RACH capable cell)
Applicable SW versions

RNC RNC16 3.0
mcRNC mcRNC16 3.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05913171
Affected legacy features/functionality: RAN1913 HS CELL_RACH

DN09100723 Issue: 05A © 2017 Nokia 71
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Change description
Description of the problem:
• The UE was attempted to move from cell PCH state (without E-RNTI) to cell FACH
state with HSRACH/HSFACH channels after the UE had included "uplink
transmission need" cause in cell update message (CU). The UE did not receive the
response (cell update confirm, CUC) and made a cell re-selection to another
HSRACH-capable cell with cause "uplink transmission need" still on. In the new cell
the radio bearer (RB) mappings to transport channels were present in the CUC
message, but when the UE did not receive even this CUC and sent a new cell
update (CU) with the same cause, the mappings were not included anymore in the
response to that new cell update.
• After the cell re-selection, the cell update confirm message was not sent anymore
through the CCCH channel, and DCCH was used even if the UE had not received
the previous CUC.

The effect of the described error was that when the UE did receive the CUC which did
not include the necessary information of the RB mappings, it sent "invalid configuration"
cause in the next CU, which caused that the RNC could not figure out how to recover
from the situation, and it decided to release the call.
The fault is corrected so that the RB mappings are included in the cell update confirm
(CUC) message until the UE has positively acknowledged them. Here also a
"reconfiguration status indicator" (RSI) field in a new CU is interpreted as a positive
acknowledgement that the UE has received the new configuration. Also, CCCH channel
is used until UE has similarly positively acknowledged the CUC.

Expected impact
When this correction is included, it is expected that call continues smoothly and is not
released in the scenario in question.

Reason(s) behind the change


The call release in the described scenario can be avoided with help of this correction.

Impacted counters/KPIs
The following counters are expected to be decreased:
• M1001C391 RRC_CONN_ACT_FAIL_UE
• M1001C397 RAB_ACT_FAIL_PS_INTER_UE
• M1001C398 RAB_ACT_FAIL_PS_BACKG_UE

The affected KPI is Capacity & Performance (KPI) / Call Completion Success.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

72 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

3.4 Counters M1006C229 and M1006C196 update


added in PCH-DCH state transition while MBLB
attempted
Applicable SW versions

RNC RNC16 2.0
mcRNC mcRNC16 2.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05900952

Change description
Counters M1006C229: PCH TO CELL_DCH ATTEMPTS and M1006C196:
ATTEMPTED PCH TO DCH TRANSITIONS USING UM-RLC were not updated in
case PCH-DCH state transition was started due to downlink data and MBLB was
attempted. As a correction, the counters will be updated in the scenario in question.

Expected impact

• SR URA-PCH to DCH (RNC_2483A) shows correct values.
• M1006C229 PCH TO CELL_DCH ATTEMPTS and M1006C196 ATTEMPTED
PCH TO DCH TRANSITIONS USING UM-RLC show correct values.

Reason(s) behind the change


Affected counters and KPI show correct values after the change.

Impacted counters/KPIs

• SR URA-PCH to DCH (RNC_2483A) shows correct values.
• M1006C229 PCH TO CELL_DCH ATTEMPTS and M1006C196 ATTEMPTED
PCH TO DCH TRANSITIONS USING UM-RLC show correct values.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

3.5 Cell UPDATE Failure Rate KPI Change


Applicable SW versions

RNC RNC16 4.0
mcRNC mcRNC16 4.0

Relation to features or corrections

DN09100723 Issue: 05A © 2017 Nokia 73
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Feature/fault correction introducing the change: NA05933881
Affected legacy features/functionality: Cell Update

Change description
The following are the problems in RU50EP1 SW:
• M1006C227 was not incremented in case there was URA update (instead of cell
update).
• M1006C171 was not incremented in case there was a CU with cause "RLC
unrecoverable error" or "re-enter service area".

M1006C171 was not incremented in case there were multiple UE CU requests and not
the first CUC was answered, that is, only next cycle of CUC receives UMIC: this problem
was found in WCDMA16 release explaining the difference between RU50EP1 vs.
WCDMA16 SW.
As a correction, the counters are now incremented in the situations mentioned above.

Expected impact
3G Cell UPDATE Failure Rate KPI will improve. See the section Impacted counters/KPI’s
for more information.

Reason(s) behind the change


The counter updates were missing in the described scenarios and are now added. CU
failure rate KPI will improve.

Impacted counters/KPIs
The following counters are affected:
• M1006C227 ATT_PCH_TO_FACH
• M1006C171 DENOM_ST_TRANS_TIME_PCH_FACH

The KPI 3G Cell UPDATE Failure Rate KPI is affected.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

3.6 Correction to M1007 CPICH EcN0 Class counter


degradation in WCDMA16
Applicable SW versions

RNC RNC16 4.0
mcRNC mcRNC16 4.0

74 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

Relation to features or corrections


Feature/fault correction introducing the change: NA05938092
Affected legacy features/functionality: Soft Handover counters (M1007)

Change description
In the WCDMA16 1.0 release, M1007 (Soft Handover) EcN0 Class counter update logic
was unintentionally changed due to SW regression, so that UE Intra-frequency Event 1A
measurement report could now trigger a counter update even if all the reported SHO
candidate cells were rejected by Handover Control decision. This resulted in unexpected
increase of total amount of EcN0 class counter updates, as well as in elevation of low
EcN0 class updates compared to higher EcN0 class updates (a common cause for a
rejection is that a call is set up for signaling purposes only, in which case the E1A event
for a candidate cell below certain EcN0 threshold may be disregarded).
With this GEN SW change, EcN0 Class counter update logic is reverted back to that
used in SW releases prior to WCDMA16 1.0, so that counter update is only made when
UE Intra-Frequency measurement Event 1A triggers for a cell that Handover Control also
accepts as a target for handover attempt.

Expected impact
Reduction in total number of updates to EcN0 class counters; relative increase in share
of higher EcN0 class counter updates compared to lower EcN0 class updates.

Reason(s) behind the change


Detected KPI degradation after update to WCDMA16 SW.

Impacted counters/KPIs
There will be an expected decrease in the following counters:
• M1007C38 CELL SPECIFIC CPICH EC/NO - CLASS 0
• M1007C39 CELL SPECIFIC CPICH EC/NO - CLASS 1
• M1007C40 CELL SPECIFIC CPICH EC/NO - CLASS 2
• M1007C41 CELL SPECIFIC CPICH EC/NO - CLASS 3
• M1007C42 CELL SPECIFIC CPICH EC/NO - CLASS 4
• M1007C43 CELL SPECIFIC CPICH EC/NO - CLASS 5
• M1007C44 CELL SPECIFIC CPICH EC/NO - CLASS 6
• M1007C45 CELL SPECIFIC CPICH EC/NO - CLASS 7
• M1007C46 CELL SPECIFIC CPICH EC/NO - CLASS 8
• M1007C47 CELL SPECIFIC CPICH EC/NO - CLASS 9

There will be an expected improvement in the following KPIs:
• Expected reduction in Nbr of Reported EcNo (RNC_1888a)
• Expected improvement in Perc of Excelent ECNo (RNC_1889a)
• Expected improvement in Perc of Good EcNo (RNC_1890a)
• Expected improvement in Perc of Acceptable EcNo (RNC_1891a)
• Expected improvement in Perc of Poor EcNo (RNC_1892a)
• Expected improvement in Perc of Bad EcNo (RNC_1893a)

DN09100723 Issue: 05A © 2017 Nokia 75
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

3.7 Decrease in HSDPA and HSUPA IFHO Compressed


Mode (CM) counters.
Applicable SW versions

RNC RNC16 P7
mcRNC mcRNC16 P7

Relation to features or corrections


Affected legacy features/functionality: Legacy fault related to HSDPA and HSUPA CM
IFHO counter updating corrected in WCDMA16 (Compressed Mode counters)

Change description
Updating of HSDPA and HSUPA IFHO Compressed Mode counters has been corrected.
They are not updated for 2G ISHO compressed mode measurements from WCDMA16
onwards.

Expected impact
HSDPA and HSUPA IFHO Compressed Mode counters are decreased but will show
realistic value.

Reason(s) behind the change


In RU50EP1 or earlier, the HSDPA and HSUPA IFHO Compressed Mode counters (for
example, M1002C623) were incorrectly pegged. The same is also true in case of 2G
ISHO CM measurements were prepared while the UE was in HSDPA or HSPA channel
type, which caused the counters to show big and incorrect values.
The corrected behaviour in WCDMA16 onwards is that when Compressed Mode
measurement preparation concerns ISHO to 2G, and the UE is on HSDPA or HSPA
channel type, HSDPA and HSUPA IFHO compressed mode counters are not updated.

Impacted counters/KPIs
The following counters may decrease:
• ALLOCATION FOR HSDPA IFHO COMPRESSED MODE (M1002C623)
• ALLOCATION FOR HSUPA IFHO COMPRESSED MODE (M1002C676)
• REJECTED HSUPA IFHO COMPRESSED MODE (M1002C678)
• REJECTED HSDPA IFHO COMPRESSED MODE (M1002C625)

Type of change
The change is generic in the SW. It cannot be deactivated.

76 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

UE dependency
n/a
Reference information
n/a

3.8 Correction to counter update during unsuccessful


SRNS relocation caused by CN
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: DRNC SW architecture change related
to RAN2973 Enhanced IMSI Based Call Monitoring. (GEN input through NA05980096:
Increase of incoming SRNC Relocation fails (M1001C63) after RNC SW release upgrade
to WCDMA16 3.0 OT6)
Affected legacy features/functionality: RAN419 SRNS Relocation

Change description
During SRNS relocation procedure with two CNs involved (MSC + SGSN), there are
timers in CNs for waiting for Relocation procedure acknowledge from RNC, and timer in
RNC for waiting for Relocation message from both CNs. If other CN does not send
relocation message (some problem in CN) to RNC, the relocation timer expires first
either in CN, which has sent the relocation message to the RNC, or in RNC. If this timer
expires first in CN, CN releases the Iu connection towards the target RNC. In this case,
relocation failure counter is not updated in older RAN releases. This is corrected in
WCDMA 16 as relocation failure counter is updated in all relocation failure cases. If
relocation timer expires first in RNC, the relevant failure counter is updated already in
older RAN releases.

Expected impact
Relevant relocation failure counter M1001C63 is updated in all relocation failure
scenarios. This may cause the counter M1001C63 in WCDMA 16 to increase.

Reason(s) behind the change


The affected counter show correct values after the change.

Impacted counters/KPIs
The counter M1001C63 NUMBER OF UNSUCCESSFUL SRNC RELOCATION
ATTEMPTS may increase depending on CN functionalities.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

DN09100723 Issue: 05A © 2017 Nokia 77
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

3.9 Workaround for UEs which do not send START


value after CS call re-establishment
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: PR NA05909686/CRE1393

Change description
During CS call re-establishment, some UEs respond incorrectly to RRC:CELL UPDATE
COMPLETE message when the call is ciphered. These 3GPP non-compliant UEs omit
“COUNT-C activation time” IE and “START” IE for CS domain from RRC:TRAFFIC
CHANNEL/PHYSICAL CHANNEL/ RADIO BEARER RECONFIGURATION message.
This causes audio distortion as the ciphering fails due to different ciphering parameter
values used by UE and RNC.
To avoid this, the RNC releases the CS call when it encounters missing ciphering
parameters from the UE during CS call re-establishment.

Expected impact
The new counter for CS call releases by RNC due to missing ciphering parameters from
UE is increased.
The RRC connection release counter due to RNC internal reasons may increase.

Reason(s) behind the change


It is better to release the call when audio distortion is inevitable due to misbehaving UE.

Impacted counters/KPIs
The new counter M1001C399 SPARE_1_SERVICELEVEL is provided for measuring
the number CS call released by RNC due to the UE not providing ciphering parameters
during CS call re-establishment procedure.
The counter M1001C21 RRC_CONN_ACT_FAIL_RNC may increase.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
Yes. Refer to section Change description.

Reference information
n/a

78 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

3.10 Packet Loss after AMR Re-establishment due to


Old HFN Used by RNC
Applicable SW versions

RNC RNC16 5.0
mcRNC mcRNC16 5.0

Relation to features or corrections


Feature/fault correction introducing the change:
PR192254
Affected legacy features/functionality:
CS call re-establishment

Change description
When the UE is transferred to the Cell_DCH state with CS+PS configuration during the
RRC Connection Re-establishment procedure and the Information Element RLC re-
establish indicator (RB5 and upwards) is set to T in the RRC:CELL UPDATE CONFIRM
message, then RRC is not using the latest START value received from the user
equipment (UE) when the ciphering module in RNC is initialized during PS UP setup.
Uplink (UL) packets are dropped and when packet loss does occur, the lost packets are
re-transmitted by the UE until the maximum number of re-transmissions is exceeded and
the UE performs the RLC reset procedure. End users will see it as a significant delay in
data transfer.
The fault is corrected so that if during CS+PS RRC Connection Re-establishment the IE
RLC re-establish indicator RB5 and upwards in theRRC:CELL UPDATE CONFIRM
message is set to TRUE and UP resources are released, then RRC stores the PS
domain START value received in the RRC:CELL UPDATE message to the DCH specific
start value table to be used later (if the User Plane is setup).

Expected impact
Packet loss and significant delay in data transfer are avoided in specific situation.

Reason(s) behind the change


Packet loss causes significant delay in data transfer.

Impacted counters/KPIs
Counter M1022C238 RLC RESET TRIGGERED BY UE might decrease.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
PR192254

DN09100723 Issue: 05A © 2017 Nokia 79
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

3.11 UE DPCCH DTX Capability Is Not Updated to


Counter and KPI for UEs that Arrive to RNC via
Incoming ISHO
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:
NA05978810
Affected legacy features/functionality:
RAN1644: Continuous Packet Connectivity (CPC)

Change description
In an event that a user equipment (UE) came from LTE or 2G to 3G via ISHO, the RNC
internal variable for device type was incorrectly initialized to
DoesNotBenefitFromBatteryConsumptionOptimisation. The CPC-capable UE was not
updated into counter M1001C677: UE_SUPP_CPC, which also affected the KPI
RNC_5579a Share of DPCCH DTX support UEs in network. SW faults were corrected in
WCDMA16 P8 software but KPI and counter effects were not reported in the Generic
Algorithm Changes document.

Expected impact
The counter and KPI are updated properly.

Reason(s) behind the change


The counter and KPI were not updated properly.

Impacted counters/KPIs
Counter M1001C677: UE_SUPP_CPC might increase.
RNC_5579a Share of DPCCH DTX support UEs in network KPI might increase.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
Release 7 or newer UE supporting DPCCH DTX (CPC)

Reference information
NA05978810

80 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

3.12 Excluding RABs already being released from RAB


re-establishment counter updating
Applicable SW versions

RNC RNC16 4.0
mcRNC mcRNC16 4.0

Relation to features or corrections


Feature/fault correction introducing the change: PR156029
Affected legacy features/functionality: RAB re-establishment counters

Change description
If an RAB is already being released and cannot be recovered, but the UE
acknowledgement has not yet been received due to a radio interface problem, then the
RAB should not be taken into account when updating call re-establishment counters. For
example, if an AMR RAB is being released, then the M1006C187
RRC_RE_EST_FAIL_UE_RT should not be incremented when a new CELL UPDATE
message is received after the AMR radio bearers to be released were included in a
preceding CELL UPDATE CONFIRM message.
The scenario is typically such that the UE does not send response to a RADIO BERER
RELEASE command and the call drops; when UE sends a CELL UPDATE, the relevant
radio bearers are included in the CELL UPDATE CONFIRM message marked as
released. If no response is received to this, but a new CELL UPDATE is received, then
the re-establishment failure counter is incremented. This happens, when the correction is
not in place, even if the RAB has already been released in the IU interface.

Expected impact
This is only a counter effect. See the section Imapcted counters/KPI’s.

Reason(s) behind the change


If the release of the RAB has already started in the IU interface, the RAB cannot be re-
established; there is no point to update re-establishment counters for such RAB’s.

Impacted counters/KPIs
Following call re-establishment (failure) counters are updated less often with the
correction in place:
• M1006C119 RRC_RE_EST_FAIL_UE_NRT
• M1006C120 RRC_RE_EST_FAIL_NOREPLY_NRT
• M1006C187 RRC_RE_EST_FAIL_UE_RT
• M1006C188 RRC_RE_EST_FAIL_NOREPLY_RT
• M1006C190 RRC_RE_EST_FAIL_UE_MR
• M1006C190 RRC_RE_EST_FAIL_UE_MR

Type of change
The change is generic in the SW. It cannot be deactivated.

DN09100723 Issue: 05A © 2017 Nokia 81
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

UE dependency
n/a
Reference information
n/a

3.13 UL DCH rejection counter (for example:


M1002C401, M1002C402) pegging correction during
state transition
Applicable SW versions

RNC RNC16 4.0
mcRNC mcRNC16 4.0

Relation to features or corrections


Feature/fault correction introducing the change: NA05925686

Change description
The problem is that cell-specific PS did not update NRT capacity request rejection
counters (for example: M1002C401 REJECTED HS-DSCH RETURN CH FOR
INTERACTIVE, M1002C402 REJECTED HS-DSCH RETURN CH FOR BACKGROUND)
during state transition scenario if capacity request was rejected due to high cell load.
This has been corrected so that UL DCH rejection counters (for example: M1002C401,
M1002C402) are pegged during state transition if the capacity request is rejected due to
high UL load.

Expected impact
UL DCH rejection counters are increased but will show realistic value.

Reason(s) behind the change


Incorrect counter update functionality has been corrected.

Impacted counters/KPIs
This change can cause increase in the following counters, but the counters will now
show realistic value:
• M1002C92 NRT DCH REQ FOR PS CALL INTERA CLASS REJECT IN UL IN
SRNC
• M1002C94 NRT DCH REQ FOR PS CALL BACKG CLASS REJECT IN UL IN SRNC
• M1002C93 NRT DCH REQ FOR PS CALL INTERA CLASS REJECT IN DL IN
SRNC
• M1002C95 NRT DCH REQ FOR PS CALL BACKG CLASS REJECT IN DL IN SRNC
• M1002C401 REJECTED HS-DSCH RETURN CH FOR INTERACTIVE
• M1002C402 REJECTED HS-DSCH RETURN CH FOR BACKGROUND
• M1002C577 REJECTED HS-DSCH RETURN CH FOR STREAMING
• M1002C483 REJECTED AMR + HS-DSCH FOR INTERACTIVE

82 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

• M1002C403 REJECTED AMR + HS-DSCH FOR BACKGROUND


• M1002C595 REJECTED AMR + HS-DSCH FOR STREAMING
• M1034C39 HS-DSCH ALLO REJECT UL POWER PER OPER

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

3.14 Cell-based Maximum Bit Rate Limitation for NRT


DCH Is Also Used for RL Allocations in DRNC
Applicable SW versions

RNC RNC16 CD3.0
mcRNC mcRNC16 CD3.0

Relation to features or corrections


Feature/fault correction introducing the change:
PR149723
Affected legacy features/functionality:
Cell-specific Packet Scheduler

Change description
Cell-specific Packet Scheduling (CELL PS) functionality is changed to take into account
the cell-based bit rate limitations also for DRNC RL allocations. Before the change, NRT
DCH bitrate for DRNC RL in initial radio bearer (RB) setup or upgrade was not correctly
limited to the maximum allowed bit rate of the cell (static or dynamic bit rate limitation).
Scheduling of requested bit rate for NRT DCH was attempted even if the bit rate
exceeded the current maximum bit rate setting for the specific RB channel type.
Static maximum bit rate limitation in the cell is defined with the following RNP
parameters:
• Release 99 channel type (DCH/DCH)
– MaxBitRateULPSNRT
– MaxBitRateDLPSNRT
• HSDPA channel type (HS-DSCH/DCH)
– HSDPAMaxBitrateUL

If load-based functions are active, dynamical limitations are applied to a maximum bit
rate in a cell. For example, mass event handler can limit the maximum allowed UL bit
rate to minimum bit rate level.

DN09100723 Issue: 05A © 2017 Nokia 83
   

Counter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Expected impact
After the change, the maximum bit rate setting (static or dynamic) is used in the CELL
PS when the scheduling decision for NRT DCH is done for DRNC RL. Higher than
maximum allowed bit rate is not allocated for DRNC RLs.

Reason(s) behind the change


Correction for fault PR149723

Impacted counters/KPIs
If the cell-specific limitations in the RNC border area cells are not equally configured as
defined with MaxBitRateDLPSNRT, MaxBitRateULPSNRT, and
HSDPAMaxBitrateUL RNP parameters, the following PS rejection counters are
increased (or if the load-based functionalities trigger in the RNC border area cells):
• REQ_PS_INTERA_REJ_UL_SRNC M1002C92
• REQ_PS_BACKG_REJ_UL_SRNC M1002C94
• REQ_PS_INTERA_REJ_DL_SRNC M1002C93
• REQ_PS_BACKG_REJ_DL_SRNC M1002C95

In both cases, PS rejection counter updates happen more frequently if the maximum bit
rate limitation is lower in the DRNC DCH AS cells of the user equipment (UE) than in the
SRNC DCH AS cells. This is because the NRT DCH bit rate selection algorithm first
selects the DCH bitrate from the SRNC cells scheduling decision, which afterwards the
resource allocation is attempted in the DRNC cells.
The following counters might be affected in SRNC:
• M1004C50 RL RECONF PREP SYNCH OVER IUR FOR DCH ADD FAIL ON
SRNC DUE TO RN LAYER CAUSE
• M1004C54 RL RECONF PREP SYNCH OVER IUR FOR DCH MOD FAIL ON
SRNC DUE TO RN LAYER CAUSE
• M1004C82 RL RECONF PREP SYNCH OVER IUR FAIL ON SRNC
• M1004C165 FAIL_NRT_DCH_SETUP_IUR
• M1004C166 NRT DCH UL RECONFIG FAIL FOR NRT RB DUE TO IUR
• M1004C167 NRT DCH DL RECONFIG FAIL FOR NRT RB DUE TO IUR

The following counters might be affected in DRNC:
• M1004C62 RL RECONF PREP SYNCH OVER IUR FOR DCH ADD FAIL ON
DRNC DUE TO RN LAYER CAUSE
• M1004C66 RL RECONF PREP SYNCH OVER IUR FOR DCH MOD FAIL ON
DRNC DUE TO RN LAYER CAUSE
• M1004C83 RL RECONF PREP SYNCH OVER IUR FAIL ON DRNC

RL Reconf Prep Sync IUR DCH Add SRNC Fail Rate [(M1004C41-M1004C47) /
(M1004C41)]:
• M1004C41 RL RECONF PREP SYNCH OVER IUR FOR DCH ADD ON DRNC
• M1004C47 RL RECONF PREP SYNCH OVER IUR FOR DCH ADD ON DRNC
READY

84 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Counter changes
Counters and KPIs

RL Reconf Prep Sync IUR DCH Mod SRNC Fail Rate [(M1004C42-M1004C48) /
(M1004C42)]:

• M1004C42 RL RECONF PREP SYNCH OVER IUR FOR DCH MOD ON DRNC
• M1004C48 RL RECONF PREP SYNCH OVER IUR FOR DCH MOD ON DRNC
READY
• M1004C139 RL RECONF REQ UNSYNCH OVER IUR FAIL ON DRNC DUE
TO RN LAYER CAUSE

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

DN09100723 Issue: 05A © 2017 Nokia 85
   

Alarm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

4 Alarm changes

4.1 SIGTRAN alarm improvements


RUxx release(s) where the change is introduced
RU50 EP1, WCDMA 16

Applicable SW versions

mcRNC RU50 mcRNC4.1 1.0


WCDMA 16 mcRNC16

Relation to features or corrections


Internal change.

Expected impact
Three existing SIGTRAN alarms have been removed. New SIGTRAN alarms have been
implemented, adding more granulated information.

Table 2 SIGTRAN alarm mapping
Old SIGTRAN alarm New SIGTRAN alarm
70314 SIGNALING NETWORK MANAGER 70396 SIGNALING SERVICE INTERNAL
UNAVAILABLE FAILURE
70315 SIGNALING GATEWAY/SIGTRAN
INTERNAL ERROR
70316 SCTP ASSOCIATION FAILURE 70394 SCTP PATH FAILURE
70395 APPLICATION SERVER FAILURE
70399 SCTP ASSOCIATION FAILURE
n/a 70385 SIGNALING RESOURCE
EXHAUSTING
70386 SIGNALING RESOURCE
UTILIZATION EXCEEDED
70387 SIGNALING DISTURBANCES
70388 SCTP ASSOCIATION CONGESTION
70389 REDUCED SIGNALING
CONNECTION ESTABLISHMENT SUCCESS
RATE
70397 SIGNALING ACTIVATION
FAILURE

SIGTRAN alarms 70314 SIGNALING NETWORK MANAGER UNAVAILABLE and


70315 SIGNALING GATEWAY/SIGTRAN INTERNAL ERROR have been replaced by
the single alarm 70396 SIGNALING SERVICE INTERNAL FAILURE.

86 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Alarm changes
Counters and KPIs

SIGTRAN alarm 70316 SCTP ASSOCIATION FAILURE has been replaced by the


new 70399 SCTP ASSOCIATION FAILURE alarm. Alarm 70316 SCTP
ASSOCIATION FAILURE was also indicating APPLICATION SERVER FAILURE, now
there is a separate alarm for that purpose: 70395 APPLICATION SERVER FAILURE.
Alarm70316 SCTP ASSOCIATION FAILURE was also indicating SCTP path failures.
SCTP path failure is now indicated through a new separate alarm: 70394 SCTP PATH
FAILURE.
Six new SIGTRAN alarms have been implemented:
• 70385 SIGNALING RESOURCE EXHAUSTING
• 70386 SIGNALING RESOURCE UTILIZATION EXCEEDED
• 70387 SIGNALING DISTURBANCES
• 70388 SCTP ASSOCIATION CONGESTION
• 70389 REDUCED SIGNALING CONNECTION ESTABLISHMENT SUCCESS
RATE
• 70397 SIGNALING ACTIVATION FAILURE

Expected impact
Three existing and quite generic SIGTRAN alarms have been replaced by new, more
accurate and more granulated SIGTRAN alarms.

Reason(s) behind the change


These new alarms give more detailed information about a problem than the old generic
alarms.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

4.2 Additional 7761 alarms raised during NBAP link


break
Applicable SW versions

RNC RNC16 1.0
mcRNC mcRNC16 1.0

Relation to features or corrections


Feature/fault correction introducing the change: 152671ESPE02, NA05727685,
117346ESPE01, 153041ESPE02, 58381ESPE05, PR063383

DN09100723 Issue: 05A © 2017 Nokia 87
   

Alarm changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Affected legacy features/functionality: n/a

Change description
As a result of a RNW recovery program block enhancement, the timing between starting
CCH recovery and observing C-NBAP link break has been modified in WCDMA16. This
creates a difference in the behaviour of 7761 alarms, which may be now raised more
frequently during NBAP link break. 7771 alarms continue to be raised for both CCH
recovery or NBAP link break.

Expected impact
Additional 7761 alarms regarding CCH deletion/creation may get raised during NBAP
link break.

Reason(s) behind the change


The RNW recovery program block has been enhanced to avoid persistent OMU warm-up
failures and WO/SP instance synchronization failures.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

4.3 Alarm 3295 raised for signaling capacity control on


mcRNC
Applicable SW versions

mcRNC mcRNC16 2.0

Relation to features or corrections


Feature/fault correction introducing the change: CRE1318 Raise alarm 3295 in feature
RAN3057
Affected legacy features/functionality: RAN3057 mcRNC signaling capacity license

Change description
Alarm 3295 licence_capacity_exceeded_a shall be raised while signaling
capacity usage in the mcRNC exceeds the limitation threshold. Before the change, only
alarm 3294 is used as signaling capacity warning.

Expected impact
No KPI effect shall be experienced, but alarm3295 would be observed while signaling
capacity is exceeding the licensed capacity on mcRNC.

88 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Alarm changes
Counters and KPIs

Reason(s) behind the change


In all legacy RNC capacity license control functionalities like in AMR capacity license
control and IUPS throughput capacity license control, both alarms 3294 and 3295 are
used for capacity warning and capacity exceeding. Therefore, for signaling capacity
license control, it is better to also use these two alarms for capacity warning and capacity
exceeding situations to avoid confusion.

Impacted counters/KPIs
No impact to KPI and counter.

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

DN09100723 Issue: 05A © 2017 Nokia 89
   

Parameter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

5 Parameter changes

5.1 Minimum reduced E-DPDCH gain factor


Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN2518: HS Cell_FACH, Enhanced
Change description
A new parameter RNC/MinRedEDPDCH is provided for enabling the transmission of a
Minimum reduced E-DPDCH gain factor information to UE on E-DPDCH, and on SIB5
for UEs on HS-RACH.When enabled:
• A Minimum reduced E-DPDCH gain factor IE is sent to Rel-8 or newer UEs each
time E-DCH is configured or reconfigured (full HSPA configuration).
• Minimum reduced E-DPDCH gain factor information is transmitted via SIB5 for UEs
on HS-RACH.

Expected impact

• Improvement in PS call setup success rate (KPIs RNC_916b, RNC_914c,
RNC_915c)
• Improvement in PS call drops (KPIs RNC_922b, RNC_920b, RNC_921c)
• Reduction in PS call re-establishments (KPI RNC_2720b; counters M1006C39,
M1006C40)
• Simplified functionality management

Reason(s) behind the change


The new parameter RNC/MinRedEDPDCH replaces the old PRFILE parameter
002:2067.

Impacted counters/KPIs
The following KPIs are expected to increase:
• RNC_914c
• RNC_915c
• RNC_916b
• RNC_920b
• RNC_921c
• RNC_922b
The following KPI is expected to decrease:
• RNC_2720b
The following counters are expected to decrease:
• M1006C39

90 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Parameter changes
Counters and KPIs

• M1006C40

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
Rel-8 and later.

Reference information
n/a

5.2 RACH and HS-RACH preamble signatures


parameter change
Applicable SW versions
RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change: RAN2902 RACH Capacity Increase
Change description
In releases prior to WCDMA 16, RACH and HS-RACH preamble signatures were defined
with parameter WCEL AllowedPreambleSignatures. This was a bitmap-type
parameter, where each particular bit indicated whether a certain preamble signature was
used for RACH/HS-RACH.
In WCDMA 16, RACH and HS-RACH preamble signatures are defined with parameter
WCEL RACHPreambleSignatures. This parameter has enumerated values, were the
actual value of the parameter indicates how many signatures are used for RACH/HS-
RACH.

Expected impact
n/a
Reason(s) behind the change
This change enables using greater signature amounts with more flexibility for different
allocations for RACH/HS-RACH preamble signatures.

Impacted counters/KPIs
The following counters cover RACH signature utilization:
• M5000C460 CONF_HS_RACH_SIGNATURES
• M5000C459 UNSUCC_DECODED_R99_RACH
• M5000C458 SUCC_DECODED_R99_RACH
• M5000C457 UNSUCC_R99_RACH_PREAMBLE
• M5000C456 SUCC_R99_RACH_PREAMBLE
The following counters cover HS-RACH signature utilization:
• M5000C465 R99_RACH_UTIL_CLASS_1
• M5000C466 R99_RACH_UTIL_CLASS_2

DN09100723 Issue: 05A © 2017 Nokia 91
   

Parameter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

• M5000C467 R99_RACH_UTIL_CLASS_3
• M5000C468 R99_RACH_UTIL_CLASS_4
• M5000C469 R99_RACH_UTIL_CLASS_5
• M5000C470 R99_RACH_UTIL_CLASS_6
• M5000C471 HS_RACH_UTIL_CLASS_1
• M5000C472 HS_RACH_UTIL_CLASS_2
• M5000C473 HS_RACH_UTIL_CLASS_3
• M5000C474 HS_RACH_UTIL_CLASS_4
• M5000C475 HS_RACH_UTIL_CLASS_5
• M5000C476 HS_RACH_UTIL_CLASS_6

Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN2902 RACH Capacity Increase

5.3 New category for Obsolete Parameters


Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:  RAN3242 Category for Obsolete
Parameters
Change description
With WCDMA 16 Nokia is moving a group of obsolete parameters from Basic and
Advanced categories to a new Obsolete category. This is done in order to simplify daily
operations within NetAct CM Editor and NetAct CM Plan Editor applications.
Each WCDMA CM parameter can have only one categorization value on radio network
element and SW level specific data:
1. Basic category contains parameters that are needed in daily network management.
2. Advanced category comprises network optimization and fine-tuning parameters,
including parameters related to advanced or complex features.
3. Obsolete category applies to parameters that are rarely used or not used at all. The
default value of these parameters can be used on all network setups.

Nokia plans to remove obsolete parameters in later releases, in order to simplify network
and feature management. The removal or any parameters belonging to the obsolete
category will be communicated via release documentation and technical notes. Until
then, operators will be able to access these parameters via the NetAct Obsolete and All
parameter views.

g Note: Nokia values the opinion of operators and looks forward to hear whether any of
the obsolete parameters are still valuable. Feedback can be communicated to Nokia
customer support.

92 © 2017 Nokia DN09100723 Issue: 05A
   

RNC Generic Algorithm Changes and Impact on Parameter changes
Counters and KPIs

Expected impact
No expected KPI impacts. Obsolete marked parameters can be found within the
Obsolete and All parameter views in NetAct.

Reason(s) behind the change


The change has been made so Network operators can reduce operating expenses
(OPEX) by simplifying their plan file and limiting the number of parameters managed via
NetAct CM tools.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
RAN3242 Category for Obsolete Parameters
The updated list of parameters can be consulted in the following documents:
• Multicontroller RNC IP Parameters
• Multicontroller RNC RNW Parameters
• IPA-RNC IP Parameters
• IPA-RNC RNW Parameters

5.4 Removal of IBFD parameter alarmEnabled and


replacement of parameter bfdEnabled
Applicable SW versions

RNC RNC16
mcRNC mcRNC16

Relation to features or corrections


Feature/fault correction introducing the change:  Improvement for the generic IP
transport related functionalities.

Change description
The parameters for the multi-hop path monitoring have been harmonized between IPA-
RNC and mcRNC. In IPA-RNC, reducing the amount of configuration parameters also
simplifies management operations:
• Parameter IBFD – alarmEnabled is removed.
• Parameter IBFD – bfdEnabled is replaced with IBFD – adminState.
BFD multi-hop monitoring can be enabled or disabled with parameter adminState,
which at the same time controls the related alarm functionality.In mcRNC, BFD multi-hop
and ICMP based monitoring will contain a new adminState parameter, following IPA-
RNC functionality. New parameters are also added to provide configuration possibility for
the DSCP (DiffServ) assignment for the related polling messages.

DN09100723 Issue: 05A © 2017 Nokia 93
   

Parameter changes RNC Generic Algorithm Changes and Impact on
Counters and KPIs

Expected impact
The management of BFD multi-hop and ICMP based polling mechanisms is provided
with a simplified interface.

Reason(s) behind the change


Parameter simplification and harmonization between RNC product variants.

Impacted counters/KPIs
n/a
Type of change
The change is generic in the SW. It cannot be deactivated.
UE dependency
n/a
Reference information
n/a

94 © 2017 Nokia DN09100723 Issue: 05A