RN6.0 2.4 Documentation Set v1.2

RN6.0 2.4 Copyright 2013 Nokia Solutions and Networks. All rights reserved. CONFIDENTIAL APPROVED 1.2

Contact

Contact your local Nokia Solutions and Networks support.

Summary of changes:

9-Oct-2013 0.1 Creation date.

16-Oct-2013 1.0 Approval date.

05-Nov-2013 1.1 Installation paths picture corrected in Installation Instructions.

12-Dec-2013 1.2 Impact document updated.

Generic Delivery

Radio Controllers WCDMA RNC RN6.0 2.4

Document name:

Impact Document

Change Note Forms

Installation Instructions

SW Update Verification Report

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

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

RN6.0 2.4 Impact Document Copyright 2013 Nokia Solutions and Networks. All rights reserved. CONFIDENTIAL APPROVED 1.0 Page 1

Impact Document Id: 2.4 (R6240000) Product Family: Radio Controllers Product: WCDMA RNC Release: RN6.0 Approval date: 12-Dec-2013

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

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


Table of Contents

1. Purpose ........................................................................................................................................... 4

2. SW update delivery effect ............................................................................................................... 4

3. Effects on end-user and operator ................................................................................................... 4 3.1 Changes in RN6.0 2.4 ............................................................................................................... 4

3.1.1 Main corrections in RN6.0 2.4 ............................................................................................. 4 3.1.2 New / changed functionality in RN6.0 2.4 ............................................................................ 6

4. Installation requirements ................................................................................................................. 7 4.1 SW update requirements .......................................................................................................... 7

4.1.1 CCP1D-A plug-in unit specific requirements ....................................................................... 7 4.1.2 Compatibility requirements .................................................................................................. 7

4.2 Release upgrade requirements ................................................................................................ 7 4.2.1 DMX unit's ECC memory single-bit parity error alarm handling .......................................... 7

5. Piloting ............................................................................................................................................. 8

6. Recently identified problems and limitations in RN6.0 .................................................................... 8

7. Effects on end-user and operator in previous SW updates ............................................................ 9 7.1 Changes in RN6.0 2.3.1 ............................................................................................................ 9

7.1.1 Main corrections in RN6.0 2.3.1 .......................................................................................... 9 7.1.2 New / changed functionality in RN6.0 2.3.1 ......................................................................... 9

7.2 Changes in RN6.0 2.3 ............................................................................................................... 9 7.2.1 Main corrections in RN6.0 2.3 ............................................................................................. 9 7.2.2 New / changed functionality in RN6.0 2.3 .......................................................................... 10

7.3 Changes in RN6.0 2.2.1 .......................................................................................................... 12 7.3.1 New / changed functionality in RN6.0 2.2.1 ....................................................................... 13

7.4 Changes in RN6.0 2.2 ............................................................................................................. 13 7.4.1 New / changed functionality in RN6.0 2.2 .......................................................................... 14









7.13 Changes in RN6.0 compared to RN5.0 .................................................................................. 27 7.13.1 RN6.0 1.4/1.3.1 compared to RN5.0 ................................................................................. 27 7.13.2 RN6.0 1.2 compared to RN5.0 .......................................................................................... 28

8. Content deviations for previous release functionality ................................................................... 29 8.1.1 Other limitations ................................................................................................................. 29

9. Release change documentation ................................................................................................... 29

10. Appendices / References .............................................................................................................. 30


Contact:

Contact your local Nokia Solutions and Networks support.

Summary of changes:

27-Aug-2013 0.1 Creation date

16-Oct-2013 1.0 Approval date

12-Dec-2013 1.1 Added Checking for Core Network Identity (CNId) during RANAP RESET as an RN6.0 2.3 improvement in section New / changed functionality in RN6.0 2.3.


1. PURPOSE

The purpose of this document is to describe the SW update delivery effects on the relevant parties and the new and changed functionalities that installing this SW update delivery brings to the customers network.

This document replaces the impact document of the original release delivery.

2. SW UPDATE DELIVERY EFFECT

RN6.0 2.4 is a maintenance package for RN6.0. The main changes included are listed in chapter Effects on end-user and operator. More detailed information of the changes is available in document RN6.0 2.4 Change Note Forms.

Changes in previous maintenance releases are listed in chapter Effects on end-user and operator in previous SW updates.

3. EFFECTS ON END-USER AND OPERATOR

3.1 Changes in RN6.0 2.4

3.1.1 Main corrections in RN6.0 2.4

The main corrections provided in 2.4, compared with 2.3.1, are listed below.

Capacity & Performance corrections affecting service availability for end users (such as services out of use or call drops):

CN RN60_1111: Increase of RAB ACT Fail and RAB STP failures

CN RN60_1124: SHO Branch Deletion failure may cause call drop in subsequent SHO Branch Replacement procedure

CN RN60_1126: PS NRT RRC setup failures due to DSP error 70550004

CN RN60_1198: PS NRT peak rate modification during CS setup causes clear code b16

CN RN60_1228: TRNMax HSPA throughput degradation after relocation

CN RN60_1238: RAB active failures due to incorrect ASN.1 encoding

CN RN60_1254: Call drop during incoming relocation from Huawei RNC which does not use Cell_FACH mapping in Cell_DCH

CN RN60_1272: Cells out of service due to DMCU state changes before system restart completed

Capacity & Performance corrections with no effect on end users:

CN RN60_1073: PSHO 4G-3G need to ask UE capabilities always after a handover from LTE to UTRAN

CN RN60_1141: RAB release requests over Iu-PS increased because GGSN is sending unnecessary GTP user plan errors

Features / functionality corrections:

CN RN60_1109: Service area broadcast process exception leading to unavailability of SAB services

CN RN60_1143: Flexible Iu load sharing is not working correctly with more than two CNs with RN6.0 2.3


Operation & maintenance corrections (no effects on end users):

CN RN60_1093: RNW measurement stopped after switchover

CN RN60_1108: RRC connection setup counters (M1001C6) triggered incorrectly in case of relocation failure

CN RN60_1115: Alarm 2380 CPU TIME DIFFERS FROM CALENDAR TIME is raised

CN RN60_1118: RAB setup failure counter is not updated correctly if UE does not respond to paging

CN RN60_1123: M1006C81 was updated incorrectly in uplink overload when TFCs needed to be restricted

CN RN60_1146: M1002C2 counter updated incorrectly if EDCH user max amount is reached

CN RN60_1153: CM upload and provisioning failure in case more than 20 uploads are performed

CN RN60_1155: PIC activation failed after Iub link break

CN RN60_1159: SFTP not working between OMS and RNC OMU

CN RN60_1160: PCH success rate formula (rnc_1215b) showing values above 100%

CN RN60_1162: M1023 measurements with equivalent PLMN ID

CN RN60_1167: NSN RNC sends Attach request and Routing Area Updates with incorrect MNC

CN RN60_1226: In case DSCR is triggered, RRC does not send correct information in internal message, leading to counter for the release of CS RAB getting incorrectly updated as normal release

CN RN60_1227: Bug in M803C4 LOST_RTP_PACKETS counter

CN RN60_1268: Counter M549C1 MIC_COUNT "Misinserted Cells" is increasing after DMPG restart

CN RN60_1269: Plan provisioning failed, SP OMU not coming to SP-EX

CN RN60_1274: MML session is not possible

Stability corrections:

CN RN60_1119: After software upgrade on RNC, over 200 cells ended up in outage

CN RN60_1127: MXU unit switchover and spare MXU restart happens due to PCI-bus malfunction

CN RN60_1137: File system corrupted because both OMU units write simultaneously to WDU

CN RN60_1156: O&M to NodeB does not work after alarm 3408 (CONNECTION DISTURBANCE)

CN RN60_1204: OMU is not working and RNC is in continuous restart

RN60_1247: Cannot make call in nodeBs, alarms "ACCESS SERVICE REJECT RATE LIMIT EXCEEDED" exist in ICSUs

CN RN60_1255: Operating system exception handler can cause spontaneous reset

CN RN60_1256: Loss of optical signal occasionally not detected correctly at NPGE(P)

CN RN60_1267: Subrack units restart due to spare MXU RECOVERY ACTION FAILURE (alarm 1687)

User Plane Quality corrections:

CN RN60_1138: Mute non-TrFO AMR call for a missing rate-control request


3.1.2 New / changed functionality in RN6.0 2.4

RAN1637: High Speed Cell_FACH (DL) support in RNC

RN6.0 2.4 introduces support for the system feature RAN1637 in RNC *

RAN1637 enables HSDPE usage in Cell_FACH. The logical channels mapped previously to the FACH transport channel can be now mapped to HS-DSCH for improving performance. Furthermore, the channels mapped to HS-DSCH are identified with a unique logical channel ID (value 15).

This mapping aims for better end-user experience with quicker Cell_FACH response times and high bit rates in Cell_FACH, as well as high resource efficiency in RNC and BTS.

For more information about this feature, see the document WCDMA RAN, Rel. RU30, Feature Descriptions and other related documentation in RU30 Operating Documentation.

* Note that RN6.0 2.4 provides RAN1637 support in RNC. Full support for this system feature is dependent on BTS as well and currently targeted to WN7.0 2.3. The feature has not been piloted on live network.

UE-related workarounds

Technical Support Note TN-RNC-SW-149 PRFILE workarounds for 3rd

part vendor issues contains following RN6.0 2.4 related UE workarounds:

UE resets during ongoing data transfer after CPC activation

Some Nokia UE models restart during ongoing data transfer if CPC is activated. A PRFILE-controllable workaround is needed in RNC to disable CPC for these users.

By default, the workaround is disabled, but can be separately activated by PRFILE parameter 007:0398 see TN-RNC-SW-149 for the instructions.

Alarms 1239 and 3188 as consequence of 070A10009 and 070A10008 DSP error codes

Some UE models send a URA UPDATE message to UTRAN while in Cell_FACH, and this interferes with RNC if it was proceeding with some other RRC procedure at the same time. This eventually leads to a dropped call, as the behaviour is not allowed from the UE in the Cell_FACH state.

A workaround has been made in RNC to ignore the URA UPDATE request from the UE when the UE is in Cell_FACH state and RNC has another RRC procedure ongoing. This workaround is activated by default (without a PRFILE parameter).


4. INSTALLATION REQUIREMENTS

4.1 SW update requirements

For the installation requirements of this maintenance package, refer to the Installation Instructions document.

4.1.1 CCP1D-A plug-in unit specific requirements

To minimize risk for error situations in BIOS and FPGA SW update to CCP1D-A Plug-In-Units during Maintenance Package update it is possible to update BIOS and FPGA SW to OMU and RSMU units beforehand. This can be done with (bios_fpga_wa.tel) macro with HIT Tool.

Updating the BIOS and FPGA SW with bios_fpga_wa.tel to OMUs and RSMUs which are configured with CCP1D-A PIUs takes less than 5 minutes. This procedure does not affect on normal ongoing functions of IPA-RNC.

If CCP1D-A Plug-In-Units are used as OMU or RSMU, this workaround procedure is mandatory prior Maintenance Package update.

The macro and SW are change delivery specific (e.g. CCP1D-A BIOS and FPGA Workaround for RN6.0 2.4 update).

4.1.2 Compatibility requirements

This delivery does not contain changes in RNC external interfaces. There are no compatibility requirements for this delivery. This compatibility is verified using NSN end-to-end equipment with a limited selection of 3rd party mobile phones.

4.2 Release upgrade requirements

Release upgrade installation (local) is supported only from RN5.0 MP2 or later SW level.

Release SW upgrade using RAN1653 Remote RNC SW Management feature is supported starting from RN6.0 1.3.1. The required source SW level is RN5.0 MP5 or later.

4.2.1 DMX unit's ECC memory single-bit parity error alarm handling

RN5.0 SW did not monitor single-bit parity error frequency but RN6.0 has that functionality. The SUPPRO program block uses a leaky bucket algorithm in monitoring and sets an alarm 1003 PARITY ERROR IN RAM after the number of single bit parity errors exceeds the max allowed value. Alarm 1003 triggers recovery actions and further actions depend on the functional unit redundancy principle:

WO-EX OMU, RSMU or ICSU:

o Spare unit is SP-EX: fault switchover. Old WO-EX goes to TE-state for diagnostic

o Spare unit is not SP-EX: WO-EX unit gets FLTY status. System makes fault switchover after spare unit enters to SP-EX state

SP-EX OMU, RSMU or ICSU: unit goes to TE-state for diagnostic

WO-EX GTPU: unit goes to TE-state for diagnostic


In RN6.0 there is small risk that SUPPRO sets the alarm 1003 PARITY ERROR IN RAM during the SW upgrade, and it is recommended to prevent alarm 1003 recovery action via MML-command ZAFC:P:RCY:1003; before the SW upgrade from RU20 to RU30.

5. PILOTING

RN6.0 2.4 SW has been piloted in live customer network. No KPI changes noted when compared to previous RN6.0 2.3 SW.

Pilot network characteristics:

RNC type: RNC2600 capacity step 3

OMS type: Integrated OMS

BTS type: FlexiBTS

Interface types: IuPS IP, IuCS ATM, Iur ATM

Other elements: NetAct OSS5.4 CD3, MSS M15 MFGU2700, MGW U52361P2

6. RECENTLY IDENTIFIED PROBLEMS AND LIMITATIONS IN RN6.0

-


7. EFFECTS ON END-USER AND OPERATOR IN PREVIOUS SW UPDATES

7.1 Changes in RN6.0 2.3.1

7.1.1 Main corrections in RN6.0 2.3.1

Compared to the previous maintenance package (2.3), 2.3.1 includes the following corrections (for details, see the Change Note Forms document):

CN RN60_1133: Flexible Iu load sharing is not working correctly with more than two CNs with RN6.0 2.3

RNC load-sharing data calculation functionality has been corrected.

CN RN60_1136: CM upload and provisioning failure in case more than 20 uploads are performed.

The O&M program plan handling process (BORDER) has been modified to clear internal resources after successful completion of RNWPLAN/IP/ATM operations.

7.1.2 New / changed functionality in RN6.0 2.3.1

None.


7.2.1 Main corrections in RN6.0 2.3

The main corrections provided in 2.3, compared with 2.2.1, are listed below.

Capacity & Performance corrections affecting service availability for end users (such as services out of use or call drops):

CN RN60_1031: CS paging received during Cell_DCH-to-Cell_PCH or Cell_DCH-to-Ura_PCH state transition leads to call setup failure

CN RN60_1038: RNC sends empty RadioLinkReconfigurationPrepare over Iur if LOW-HIGH power offsets changes during CTS

CN RN60_1080: Inter-RAT HO back to LTE failed after successful Inter-RAT HO from LTE to 3G

Capacity & Performance corrections with no effect on end users:

CN RN60_1003: PrxNoise increased in RU30 compared to RU20

CN RN60_1028: Optimization of DSP capacity reservation for Cell_FACH-state UEs in RNC2600


CN RN60_1026: CS RAB setup failures from Cell_FACH are increasing M1001 counters with incorrect failure cause

CN RN60_0929: BOIMED process has crashed and O&M connections are down for a while

CN RN60_0967: Increase of M802C19 AVE_USERS_CELL_DCH due to problem in RRC resource supervision

CN RN60_1052: RAN2883: It is not possible to remove a password policy from a user


Stability corrections:

CN RN60_0931: BRM hand crash

CN RN60_0953: SAS Centric position failures and 3390 alarms with Polaris SAS

CN RN60_0969: RAB and HS failures due to l2pext monitoring

CN RN60_1050: CCH DSP gets stuck


PRFILE-controlled changes

This is a short description of enhancements controlled by PRFILE parameters. For full details and effects of parameter changes, refer to the change note forms and PRFILE Descriptions document.

CN RN60_1036: CS RAB Active Failure Counter improvement

When this functionality is enabled, CS RAB Active Failures are reported to the last Serving RNC cell also in situations where both a PS and a CS connection exists and after radio link failure UE makes CellUpdate from DRNC (over Iur). When this functionality is disabled, the counters are updated for DRNC object bts_id=0 / cell_id=0 in such a situation.

The following counters are affected:

o M1001C146 RAB ACTIVE FAILURES DUE TO RADIO INT FOR CS VOICE

o M1001C162 RAB ACTIVE FAILURES DUE TO RADIO INT FOR CS DATA STREAM

This functionality is controlled by PRFILE parameter 007:0397 RNC_L3_CONTROL_032, with the following values:

Value (HEX) Meaning

0 (default value) Functionality is disabled.

1 Functionality is enabled.

CN RN60_1048: TFCS limitations for WCDMA BTS RAN2262 and for UE capability issues (RAN580 and RAN830)

These improvements are two-fold, each controlled by a PRFILE parameter:

o Limitation of multi PS bearer uplink transmission in DCH configuration for RAN2262

With RAN2262, a WBTS cannot decode more than 6 UL DCHs, or 2 DCHs with Turbo coding, received in one radio frame. RNC needs to limit a UEs capability in transmission of the PS DCHs (limit the UL TFCS) so that the requirements of the WBTS are fulfilled, though the same number of PS DCHs is still possible to be set up. If the number of the Turbo-encoded UL PS NRT and PS DCHs exceeds 2, limitation of the UL TFCS set for the multi PS NRT DCH transmission will be done so that UE cannot transmit with more than 2 PS NRT DCHs at a time in the TTI of the DCH, while it can transmit freely with the other bearers.

This functionality is controlled by PRFILE parameter 002:1914 RN60_MAINT_39, with the following values:


Value (HEX) Meaning

Limitation of UL TFCS if more than 1 UL PS DC

Limitation of UL TFCS if more than 2 UL PS DCHs

0 (default value) Disabled Disabled

1 (recommended value)

Enabled Disabled

10 Disabled Enabled

o TFCS limitation of multimode AMR (AMR + PS R99) due to UEs TFCS capability limitations

When enabled, this functionality allows a multimode AMR call to be downgraded to its lowest AMR mode, in order to avoid bit-rate limitations of PS DCHs if a UEs TFCS capability is limited.

This functionality is controlled by PRFILE parameter 002:1905 RN60_MAINT_29, with the following values:

Value (HEX) Meaning

0 (default value) Functionality is disabled.

10 Functionality is enabled.

New IFC implementation

RN6.0 2.3 contains a correction to a fault NA05102458 (IFC timer 1200ms slow start related to high RTT values in ping tests) where ping result was very poor when interval between ping messages was over 1200 ms. The internal flow control in RNC was restricting the data transmission too much in the beginning of the service. The silent period timer was 1200 ms and after that the data transmission was restarted from low throughput values. As a correction the shaping of data transmission is updated for the current data transmission capabilities when IFC is enabled. The TCP type data transmission flow is now preserved, which decreases the buffering on RNC in DL data transmission. This increases also the performance of burst-related data transmission scenarios, e.g. ping or Internet traffic. RN6.0 CN RN60_1047: IFC timer 1200ms slow start related to high RTT values in ping tests.

Increase of RAB active failures due to Iu

Before RN6.0 2.3, when the core network released an SCCP connection with the SCCP release cause Unqualified without sending an IU Release Command before that, it was counted as a normal RAB release (RAB Active Complete).

M1001C136 RAB_ACT_COMP_CS_VOICE

M1001C141 RAB_ACT_COMP_PS_INTER

M1001C142 RAB_ACT_COMP_PS_BACKG


Instead, as of RN6.0 2.3 the RNC implementation has been changed so that the Unqualified SCCP release cause triggers RAB Active Failure due to an IU counter update:

M1001C145 RAB_ACT_FAIL_CS_VOICE_IU

M1001C185 RAB_ACT_FAIL_PS_INTER_IU

M1001C191 RAB_ACT_FAIL_PS_BACKG_IU

As an impact, there is minor degradation in the following retainability KPI if the core network is using the Unqualified cause:

RNC_231d RAB Success Ratio, Voice (CSR)

RNC_615c RAB Success Ratio, NRT Services, from Network Perspective

The reason for doing this counter implementation change in the RNC is to detect better the failure situations on core network side that would trigger the CN to release connections with the Unqualified cause.

This change will also be reflected in document RNC Generic Algorithm Changes and Impact on Counters and KPIs in RU30 Operating Documentation.

Checking for Core Network Identity (CNId) during RANAP RESET

As per 3GPP specifications, the Core Network Identity (CNId) must be unique over the network and it should match with the value in integrated NE. In some cases it has been noticed that CNId have been incorrectly configured in the network causing e.g. a huge amount of paging failures after CN restart when CN has to page UEs by IMSI. Also managing of IMSI paging in the correct way in the IuFlex configuration is not possible if CNId is incorrectly configured.

Before RN6.0 2.3, CNId was not checked during RANAP RESET procedure (done e.g. after Iu link break, CN restart etc), making it possible that RANAP for that interface comes up although CNId was incorrectly configured in the system.

From RN6.0 2.3 onwards, implementation was changed and CNId checking is done already during RANAP RESET procedure to avoid any problems in traffic later on.


The main corrections provided in 2.2.1 are listed below.

Capacity & performance corrections affecting service availability for end users (such as services out of use or call drops):

CN RN60_0919: Occasional CS call drop due to RAB reconfiguration failure when multi-mode AMR is enabled

CN RN60_0923: Occasional AMR call failure due to problem in AMR codec set reconfiguration

CN RN60_0926: Sleeping cell, UE cannot camp on a cell due to SIB scheduling problem

CN RN60_1000: DL power control problem with F-DPCH increasing M1022C58 and M1022C64 counters

Capacity & performance corrections with no effect on end users:

CN RN60_0914: Full DL NRT capacity of FDPCH enabled cell was not utilized


CN RN60_0992: RNC OMU IP cannot be configured with 192.X.X.X IP


CN RN60_0942: Setting daylight saving time with RN6.02.2 fails

Workaround

Technical Support Note TN-RNC-SW-149 PRFILE workarounds for 3rd

part vendor issues, section 4.12 has been updated in NOLS with a UE-related workaround for 2.2.1. The workaround addresses a problem where some UEs incorrectly reject AMR RAB reconfiguration.


PRFILE-controlled change

CN RN60_0945: Separately activated Intra-BTS MBLB layer change counters (M1006C24x).

As referred in the CN, a new PRFILE-controllable improvement has been implemented for measuring MBLB (multi-band load balancing) intra-BTS layer changes in PCH/FACH-to-DCH transitions.

PRFILE 007:0392 RNC_L3_CONTROL_027

Default value is 0H, by which the new functionality is disabled, i.e. the counters shown below are updated only in inter-BTS layer changes.

New functionality can be enabled by value 1H. When enabled, the following counters are updated both for intra-BTS and inter-BTS layer changes in PCH/FACH to DCH transition due to MBLB:

o M1006C240 ATT_INT_BTS_PCH_FACH_TO_DCH o M1006C241 SUCC_INT_BTS_PCH_FACH_TO_DCH o M1006C242 FAIL_INT_BTS_PCH_FACH_TO_DCH


This chapter compares 2.2 main changes against 2.1. RN6.0 2.2 brings a wide range of corrections that impact the services available for End users, Statistics, O&M and NE Stability areas. Only some of the fault corrections are listed below, not all. Corrections affecting Service Availability for End users (services out of use, call drops etc.):

CN RN60_0872: CS RAB drops due to high RAB load in SGSN

CN RN60_0702: Increase of RRC and HSDPA setup failures due to RNC

CN RN60_0789: HSDPA Retainability KPIs decreased day by day after a heavy overload observed in the network

CN RN60_0703: RAB modification fails if transport layer information is not included when modifying NAS sync info


CN RN60_0850: NBAP process gets stuck in the middle

CN RN60_0701: RAB PS failures due to DSP error 70620002 and 70620001

CN RN60_0707: UL peak rate limitation to 2 Mbps missing in case UE coming from CELL_FACH state (2*SF2)

Corrections affecting Network Stability (outages etc.):

CN RN60_0907: NPGEP overloaded (refer to TS-RNC-SW-193 Critical Problems and Workarounds for RN6.0)

CN RN60_0884: Excessive computer log writings causing RSMU CPU overload Corrections affecting Statistics/KPIs (no impact to End users):

CN RN60_0779: High PS RAB Access Fail due to MS after RU30 EP2 Upgrade

CN RN60_0778: PS RAB access failure counters incorrectly updated after Inter-System Handover

CN RN60_0890: RAB active failure not updated in SRNC relocation with 2 Core Network

Operation and Maintenance related corrections (no impact to End users):

CN RN60_0806: BTS O&M connection is not established after OMU switchover

CN RN60_0823: RNC O&M application raises false 7750 alarm

CN RN60_0791: Timeout when adding new users to RNC with ZIAH command

CN RN60_0725: Unable to read MML measurements with ZT2I command

CN RN60_0794: Plan failures do not give the cell details where the failure has occurred

There is a correction related to TS-RNC-SW-168: Removing alarm blocks and FBAN flags if HMS Update Macro is aborted:

CN RN60_0822: HMS transmission line can be disabled forever after HMS HIT macro abort

There are improvements related to TS-RNC-SW-189: Enhanced algorithms for optimizing RRM functionalities of RU30:

CN RN60_0879: HSUPA allocation failures with limited WN7.0 HSUPA baseband HW resources

CN RN60_0893: Cell_PS UL power based limitation to UL NRT DCH bitrates

CN RN60_0908: BRM does not receive activity indication causing an increased inactive power reservation

The above TS-RNC-SW-189 changes are controlled using PRFILE parameters, see next chapter. Other new functionality supported in RN6.0 2.2 is described shortly in the same chapter.


The following PRFILE controllable improvements have been implemented in 2.2. Introduced in TS Note TS-RNC-SW-189: Enhanced algorithms for optimizing RRM functionalities of RU30:

Cell_PS UL power based limitation to UL NRT DCH bitrates


o 15th bit of the PRFILE parameter 007:0283 o By default the new functionality is switched off o CN RN60_0893

BRM does not receive activity indication causing an increased inactive power reservation

o 16th bit of the PRFILE parameter 007:0283 o By default the new functionality is switched off o CN RN60_0908

HSUPA allocation failures with limited WN7.0 HSUPA baseband HW

resources o PRFILE parameter 007:0388 o By default the NRT DCH bit rate limitation functionality due to

HSUPA congestion is disabled o CN RN60_0879

Other PRFILE improvements:

Improvement for temporary offset increase for E-RGCH/E-HICH signatures

o PRFILE 002:1918 o Default value for the PRFILE is 0H and improvement is disabled with it o CN RN60_0877

Occasional long delay during plan provisioning if BTS recovery ongoing at the same time

o PRFILE 002:1915 o By default, this new correction is enabled and it is recommended to keep

it enabled o CN RN60_0903

PRFILE controllable improvement to use higher initial code power during Inter-freq HHO from Huawei to NSN RNC

o PRFILE 002:1913 o With default value 0H, new functionality is disabled i.e.4 dB is used as

Delta value. Recommended value is 8H for the parameter, i.e., 8dB is used as Delta value.

o CN RN60_0876

Recovery of non-performing DSP based on DSP severe errors o PRFILE 002:1760, PRFILE 002:1904 o Default value for both of the parameters is 0H. Functionality is enabled

with recommended configuration with default values. o CN RN60_0878

The following new functionalities are included:

New DSP code memory protection functionality o This change note extends DSP code memory protection functionality for

CDSP-DH based DMCU covering DSP platform code. Similar DSP application code protection has been provided earlier in RN6.0 2.1 with CN RN60_0675: DSP code protection phase 1.

o CN RN60_0790: DSP code protection phase 2.


The service terminal command tcpdump option C improved and add option L, which can be avoid overload situation

o CN RN60_0719: tcpdump improvement for DMX unit to avoid RANDISK full which will cause high load of CPU


This chapter compares 2.1 main changes against 2.0.1. RN6.0 2.1 brings wide range Statistics and Counter corrections. Also important corrections impacting to services available for End users have been contained. Only some of the fault corrections are listed below, not all. Corrections effecting Service Availability for End users (services out of use, call drops etc.):

CN RN60_0633: High rate RRC abnormal release with cause IU

CN RN60_0660: HHO fails because inconsistent setup parameters

CN RN60_0614: All cells of one BTS site could not become WO

CN RN60_0648: RNC out of service and spontaneously restarting

CN RN60_0650: RNC expects UE in Cell_PCH incorrectly

CN RN60_0612: Severe error is reported during cell removing phase leading call drop

Corrections effecting to Statistics/KPIs (no impact to End users):

CN RN60_0616: PS RAB setup fails during Cell_FACH to Cell_DCH transition

CN RN60_0606: High RRC call drop rate

CN RN60_0647: RRC success is decreasing

CN RN60_0646: RT channel create failure caused 3343 AAL5 CHANNEL OPENING FAILURE alarms

CN RN60_0355: NetAct getting PM files with WBTS-0/WCEL bigger than 0

CN RN60_0639: Counter M1000C382 AVE_RESID_UL_POWER is not updated when HSUPA IC is disabled

CN RN60_0662: M1008C66 IF_COM_MOD_STA_NOT_POS_NRT found increased after RU30

CN RN60_0659: Huge data values in RCPM Sum of squared net throughput and Sum of squared transmission time counters

CN RN60_0644: Wrong M568C7 and M568C8 measurement counter values (min and max connection amount per IPBR calculated wrongly)

CN RN60_0621: Duplicate measurement data in OMS

CN RN60_0627: Incorrect counter updated during SCC failure from AC

CN RN60_0657: Remote Event Window parameter display text in ZQAR command is not correct


CN RN60_0605: Counters of SDH higher order path 2 and 3 of measurement 201 STM-1 INTERFACE MEASUREMENT were increased even though used VC mapping is VC-4

CN RN60_0634: RRC Connection Active Failure due to IU is counted as RRC Connection Active Failure due to RNC

Operation and Maintenance related corrections (no impact to End users):

CN RN60_0631: DSP supervision failure during busy hours

CN RN60_0615: Slave DMPG spontaneous restart

CN RN60_0672: Suspicious characters seen in the supplementary info of 7750 alarm in MML and in the Netact alarm monitor

CN RN60_0571: Program block communication error during system restart (TOT/OPT)

CN RN60_0619: Successful HSUPA disabling under both cells in DC-HSDPA configuration

CN RN60_0641: Remote monitoring of Chorus Unit does not work properly with MM3STE

CN RN60_0649: Data File Size Modification Showing Error UNREASONABLE VALUE

Corrections effecting to Network Stability:

CN RN60_0628: Working ICSU restarted

CN RN60_0640: ESA40-A will restart after power off-on of UB1 or UB2

This correction brings new ESA40-A software but updating ESA40-A with this correction is not mandatory in RN6.0. For upgrading ESA40-A software, refer to Special Conditions for Installation on Change Note.

Network Security corrections:

CN RN60_0610: Frames with wrong VLAN are carried through NPGE

Supported new functionality in RN6.0 2.1 is described shortly in next chapter.


The following PRFILE controllable improvements have been implemented:

RAN2827 RL deletion cause and BTS logging improvement: o By default this feature is active but there is PRFILE parameter 002:1889

to control logging functionality. Refer to RN6.0 2.1 CN RN60_0678.

Cells in blocked state with SIB optimization enabled after ADJx reached 90: o Q_offset2 parameter sending can be separately activated with PRFILE

002:1912 RN60_MAINT_36. RNC will pack Q_offset only if PRFILE is separately enabled. With default value, RNC will not pack Q_offset. Refer to RN6.0 2.1 CN RN60_0744.

PRFILE controllable improvements above were included already in RN6.0 2.0 SW but these has been tested and verified for RN6.0 2.1. The following change introduces a new DSP code memory protection functionality for CDSP-DH based DMCU covering DSP application code:


CN RN60_0675: DSP code protection phase 1



This chapter compares 2.0.1 main changes against 2.0. RN6.0 2.0.1 contains the correction to problem where Voice calls via IuCS over IP are released by MGW due to RNC problem in RTCP handling (CN RN60_0690). Problem was active with RNC RN6.0 2.0 SW and NSN MGW, when CS calls were connected between RNC and MGW via IP network. Impact was that CS calls were released by NSN MGW (with clear code 885h) because MGW did not receive needed RTCP packets from RNC. Problem can occur when RTCP is activated both in MGW and RNC side. Impact is depending how RTCP supervision is implemented in MGW. With NSN MGW, there are three if options for RTCP user plane monitoring (Option 3 is default functionality in NSN MGW):

o Option 1 - RTCP not used o Option 2 - RTCP packed sending and receiving activated, no RTCP

monitoring o Option 3 - RTCP packed sending and receiving activated, RTCP monitoring

active

In case of Option 3 i.e. when RTCP monitoring is active, NSN MGW releases calls in case of continuous RTCP supervision failures. Problem can be detected from MGW side as huge number of alarms 1299 (RTCP SUPERVISION FAILURE). Impact to end user is CS call failures; operator can see this as increase of CS call setup and drop rate. The correction for the NPGE(P) partial diagnostic ATNI failure is also included (CN RN60_0691). NPGE(P) partial diagnostic ATNI fails and system changes the unit to SE-OU state. The problem occurs only if new NPGE(P) unit is configured after SW upgrade from RN5.0 to RN6.0. The ATNI diagnostic failure does not happen if there is IP configuration created on NPGE(P) unit on RN5.0 package, or command ZQRN or ZQRS on interface has been used on new NPGE(P) unit. The interface unit does not carry traffic because it is in SE-OU state after failed diagnostic.


No new or changed functionality.



This chapter compares 2.0 main changes against 1.5. Only some of the fault corrections are listed below, not all. Corrections effecting Statistics (KPIs):

CN RN60_0456: DRRC is not performed if cells are present in different frequency bands

CN RN60_0483: RL Addition/Reconfiguration failure during HO from ALU-SRNC to NSN-DRNC

CN RN60_0453: HSDPA DL data transfer freezes for a couple of seconds

CN RN60_0450: UE blocked at FACH for long time after PS RL reconfiguration failure

CN RN60_0419: RNC DL stall data

CN RN60_0496: DRNC IP Iur overbooking is not working

CN RN60_0532: Increase of M1001C122 counter (RAB SETUP ASS FAIL FOR CS VOICE CALL DUE TO UE)

CN RN60_0536: Sleeping cells due to SIB12 corruption

CN RN60_0596: RNC block NAS messages and freeze mobile which cannot access services during several minutes

CN RN60_0681: During CS RAB release, counter for RAB release is updated incorrectly as a normal release

CN RN60_0686: Counter update error: M100629 SUCC_RB_SETUP_BLIND_HO updates in target cell when Blind handover fails

CN RN60_0688: Counters M1006C200/M1006C201 are not updated while doing Preventive overload control

CN RN60_0697: Failure_source IE's not filled in PMI ticket in case of DSCR over Iur is triggered

CN RN60_0773: Counter is updated to source cell instead of target cell during Blind IFHO with RAB setup phase

CN RN60_0774: Layer 2 resources not released properly due to that RRC freezes

RRC ACT FAIL IU failure counters increased in some environments after RN6.0 2.X update due to a RNC SW correction. From RN6.0 2.0 onwards, RNC updates the failure counter in a scenario where CN sends SCCP disconnect instead of RANAP Iu Release Command when RNC is executing some other RRC procedure. In earlier releases, this was incorrectly counted as a successful release.

Operation and Maintenance related corrections:

CN RN60_0425: RNC changes the profile QoS (SPI) during data call

CN RN60_0526: Dumping error in RAQUEL and BAIDAT databases

CN RN60_0551: WBTS Connection Resources issues

CN RN60_0589: System restart triggered by subsequent RSMU restarts Corrections effecting to Network Stability:

CN RN60_0500: Recovery unnecessarily triggered for MXU/NPxx units, alarm 3510 with supplementary info 48 01

CN RN60_0538: UE went into a CU (rlc_reset_error) loop after Blind IFHO failure

CN RN60_0583: OMU spare disk does not work properly


When UE was lost during a state transition from Cell_DCH to Cell_FACH and it replied very late to RBR, RNC L3 maintained sometimes incorrect information about the UE configuration related to used PDU size. When UE moved next time back to Cell_DCH, RNC L3 did not inform the UE correctly about RLC one sided re-establishment. This problem resulted, depending on the exact timing of the scenario, to DSP severe errors and in the worst case to DSP fatal error 80000006 which caused caused HS DSP restart. For the end user, the above problem is visible as single call drop. For the operator, the above problem causes a decrease in HS retainability

User Plane Quality related corrections:

CN RN60_0587: Small voice gap as AMR bicasting not working during HHO

CN RN60_0602: Noise after few relocations

Improvement in SCC success was noted in RN6.0 2.0 because of the following corrections:

CN RN60_0524 (2.0 CN)

CN RN60_0232 (1.4 CN)

CN RN60_0240 (1.4 CN)

CN RN60_0260 (1.4 CN)

Supported new functionality in RN6.0 2.0 is described shortly in next chapter.


The following features have been implemented:

RAN2879: Mass Event Handler o PRFILE activation instructions delivered based on orders.

RAN2886: Faster OLPC

RAN2778: UE Periodic Measurement Report o PRFILE activation instructions delivered based on orders.

The following PRFILE controllable improvements have been implemented:

WCEL Idle Alarm Timeout: o PRFILE parameter 002:1891 RN60_MAINT_15 determines time interval

after which WCELs staying in BL-INIT state are informed to the user via alarms. Refer to RN6.0 2.0 CN RN60_0486.

RNC correction: o PRFILE parameter 002:1900 RN60_MAINT_25. o With PRFILE activated RNC delivers maxReportedCellsOnRACH as

CurrentCell,when RACH Intra Frequency Measurement Quantity is CPICH-RSCP in SIB11. Refer to RN6.0 2.0 CN RN60_0466.

RNC correction: o PRFILE parameter 002:1886 RN60_MAINT_10. o PRFILE controllable change is implemented to improve WN7.0 BTS HW

reservation. This means that in case of BTS base band HW limitation, BTS capacity can be used more efficiently, and stability of HSUPA


services for 10 ms TTI users with F-DPCH enabled will be better. Refer to RN6.0 2.0 CN RN60_0550.

Flexible user plane capacity: o PRFILE parameter 002:1792 UP_CAP_UPGRADE is used to control

Flexible user plane capacity functionality.

Control for both DRRC and HSDPA layering functionalities between different frequency bands is implemented under:

o PRFILE parameter 002:1776 RN50_MAINT_58. o By default, DRRC is not allowed between frequency bands (change

introduced from RN6.0 1.4 onwards, 1.4 CN RN60_0217: RRC registration failures for all RNCs). Now it can be enabled with this PRFILE parameter in RN6.0 2.0.

RNC workaround for WN6.0 BTS problem: UE stuck after integrity check fail or corrupted UL PDUs:

o PRFILE parameter 002:1775 RN50_MAINT_57. o A workaround has been implemented to prevent UEs to get stuck in

Cell_FACH state after it sends UL messages on SRBs which either fail integrity check in RNC or ASN.1 decoding. Refer to RN6.0 2.0 CN RN60_0676.

HSXPA over Iur with ALU SRNC: o PRFILE parameter 002:1902 RN60_MAINT_26. o As an improvement to allow UE mobility in Inter-RNC scenario with

different RAN vendors, NSN RNC will accept HSDPA over IUR with Compressed Mode inactive or active. Refer to RN6.0 2.0 CN RN60_0677.

The following improvements have been implemented:

CN RN60_0487: APP memory and fast path diagnostics (ATNI) for NP8S1-B and NP2GE-B variants

CN RN60_0488: CCH improvements for memory allocation failure detection

CN RN60_0545: Adding NE information to restart MML command confirmation

CN RN60_0548: CN DRX Cycle length correction in SIB1

CN RN60_0592: ATM OAM sleeping cell problem recovery

A workaround has been implemented for Qualcomm based UEs. If a Qualcomm based UE detects a RL failure during the CS call setup from Cell_FACH, it might hang in a loop, would not recover and the call setup will not succeed. Refer to TS-RNC-SW-149 PRFILE workarounds for 3rd party vendor issues chapter CS call setup failure with invalid configuration in loop which UE does not recover.


This chapter compares 1.5.3 main changes against 1.5. There is a correction to SW fault which may cause problems in the CD installation boot SW update part:

CN RN60_0567: ZWD MML execution failed


This occasional boot SW update problem is related only to CCP1D-A cards.


None.


This chapter compares 1.5 main changes against 1.4. Correction to the problem in which RU30 showed too high PrxNoise level. This can potentially reduce noise floor level. Lower noise floor reduces power spiking in the uplink spectrum as described in TS-RNC-SW-159 (chapter PRX Noise autotuning parametrization):

CN RN60_0413: RU30 shows too high PrxNoise level Main counter corrections:

CN RN60_0321: Counter UL_DCH_SEL_BTS_HW_BGR is increased after BTS upgrade

The following type of statistics counters can change with BTS WN7.0:

UL_DCH_SEL_BTS_HW_xxx is decreased.

UL_DCH_SEL_MAX_HSUPA_USR_xxx is increased.

CN RN60_0410: In Multi-PS scenario Packet_call_ticket is not coming for RAB release request while user plane is active in DCHx/y state

CN RN60_0404: PS and HS session drops increased, counters M1022C57-M1022C66 increased after WN7.0 upgrade

UER was using too high delta-sir values during some scenarios (HSPA to DCH and SCC without SIR measurement) which were causing short power spikes in field testing reducing uplink power usage in some mobility scenarios which may improve retainability KPIs.

CN RN60_0680: Counter ID M1022C16 is not updated when PS NRT RAB setup in CELL_FACH state fails due to transport congestion

CN RN60_0684: HSPA active calls failures due to call release by Handover Control

CN RN60_0685: M1001C81 should be updated instead of M1001C83 when BTS does not respond for CS call setup

CN RN60_0687: After Blind IFHO failure, the counter for setup failure of PS RAB with User Plane is not updated

CN RN60_0693: M1006C230 update wrongly for L3C with on transition from FACH ongoing

CN RN60_0694: In relocation scenario with SL only, extra PMI ticket is coming for RRC normal release after RRC access failure

CN RN60_0695: CN PMI ticket is updated as normal release while this should be updated as active failure

CN RN60_0696: KPI DRA for HSPA Success Rate is more than 100% while MBLB DRA attempt counter has not been updated

CN RN60_0698: NRT in PCH + AMR with MBLB - Service Level RAB establishment counters are incremented on the source cell rather than the target cell


In 1.5 main corrections to improve voice quality:

CN RN60_0369: No audio for WB AMR calls

CN RN60_0398: Watery sound is experienced during Inter-RNC Handover

Main corrections to improve DSP stability:

CN RN60_0346: CDSP-DH DSP C compiler version update for improved DSP stability

CN RN60_0385: RNC Alarm 1239 DSP Supervision Failure from CDSP-DH

CN RN60_0408: RLC DL SDU buffer handling correction for improved DSP stability

Main corrections to improve packet data throughput:

CN RN60_0368: Too sensitive HSUPA CC algorithm causes DL throughput decrease with DC-HSDPA

Correction to A2SP load balancing. PRFILE workaround presented in TS-RNC-SW-180 Hanging UHAPRB hand processes in RSMU of RNC196/RNC450 with ATM transport is not needed anymore:

CN RN60_0344: Alarm 2684 Running out of hands on both RSMU's There is a correction to RNC workaround presented in TS-RNC-SW-167 Workaround to disable Lossless PDU size change support:

CN RN60_0313: Disabling lossless PDU size change in RU30 Supported new functionality in RN6.0 1.5 is described shortly in next chapter.


7.9.1.1 Information CTP request for other PLMN improvement (PRFILE 007:0269)

Some UE models sends invalid selected PLMN to the RNC in MOCN configuration. This can lead to alarms in CN side because RNC trust that selected PLMN is valid for CN. If operator wants to ignore whole initial UE message which contains invalid PLMN, instead to ignore only wrong parameter, then PRFILE parameter need to be set (CN RN60_0400).

7.9.1.2 Video Call is not working with Nortel MGW (PRFILE 002:1892)

This change is RNC workaround for Core Network functionality. Nortel CN requires transport layer address to be sent in different format that RNC currently does.

A workaround has been implemented which will make RNC to send Transport Layer Address in the RAB Assignment Response of length 20 bytes during Video Call setup (CN RN60_0365). Refer to TS-RNC-SW-149 PRFILE workarounds for 3rd party vendor issues.


7.9.1.3 Workaround for UE problem in blind IFHO (PRFILE 002:1888)

There are problems in some UEs to handle blind IFHO (which is part of Multi-Band Load Balancing functionality) done in RB Setup procedure correctly. Workaround has been implemented so that blind IFHO is done first and RB setup immediately after that. The workaround is valid of CS and PS calls where RB setup is done in Cell_DCH state. More information can be found from WCDMA RAN Call Setup and Release Functional Area Description and Handover Control Functional Area Description.

7.9.1.4 Usage of monitored cell measurement results on RACH to define the source cell for blind IFHO (PRFILE 002:1897)

With this PRFILE parameter it is possible to disable the use of monitored cell (intra-frequency neighbor cell) in RACH measurement results. This means that blind IFHO can be triggered only from current cell and the current cell RSCP value is used when defining the initial power for blind IFHO.

7.9.1.5 New commands

In 1.5 there are new commands in RUOSTE service terminal extension for updating the WBTS and MTP3SL weights:

adjusting weight of certain WBTS (IW:;)

adjusting weight of all WBTSs (IW;)

adjusting weight of non-Iub signaling links (IW:0;)

Refer to CN RN60_0402 Support for updating WBTS and MTP3SL object weights for ICSU load balancing after RN5.0/RN6.0 SW upgrade.


This chapter compares 1.4 main changes against 1.3.1. There are no issues seen comparing RN6.0 1.4 with RN6.0 1.3.1 in terms of KPI degradation or functionality limitations. Supported new functionality in RN6.0 1.4 is described shortly in next chapter.


Optional Guaranteed Bit Rate (GBR) IE is supported on Iur interface from RN6.0 1.4 onwards. DRRC is not allowed between frequency bands by default. This change is introduced in RN6.0 1.4 (1.4 CN RN60_0217: RRC registration failures for all RNCs). Control for both DRRC and HSDPA layering functionalities between different frequency bands is implemented under PRFILE parameter 002:1776 RN50_MAINT_58 in RN6.0 2.0. In 1.4 there is a correction pre-installation via OMU switchover in CD installation macro:

In 1.3.1 and 1.4 pilot CDs (up to P6149110) there is a SW fault which may cause problems in CD installation boot SW update part. The correction (CN RN60_0292) is available in 1.4. To prevent this problem to occur during boot SW update the correction for CBYPRBGX.IMG is taken from 1.4 CD and installed into OMU units via OMU


switchovers during the CD installation procedure. This installation is taken care by macro automatically prior to point where Fallback is started to take. With any other SW baseline than 1.3.1 or 1.4 pilot CDs there is no problems and above installation is skipped automatically by macro.


This chapter compares 1.3.1 main changes against 1.3. There are no issues seen comparing RN6.0 1.3.1 with RN6.0 1.3 in terms of KPI degradation or functionality limitations. Key KPI related consideration: NA05068653 Double fold increase on HSDPA Discarded PDUs due to Max Retransmissions

The increase was seen after PP8.7 SW installation with WN6.0 WBTS SW. RN6.0 1.3.1 returns this double fold increase back to normal level. Please note that visibility of this problem is linked to HSPA drop due RL issue according to chapter New / Changed functionality in RN6.0 1.3.1.

In 1.3.1 there is a correction which was informed using Technical Support Note TS-RNC-SW-175 Incorrect Secondary OMS IP address after SW upgrade from RN5.0 to RN6.0. Correction (checking and modification of incorrect address settings) is included in the RN6.0 CD 1.3.1 installation macro. Supported new functionality in RN6.0 1.3.1 is described shortly in next chapter.


7.11.1.1 RNC modification for H-RNTI allocation (PRFILE 002:1939 RN60_INT_FEAT_RES_10)

In RU30, RNC functionality is changed that the H-RNTI value is reserved from the cell level pool, whereas in RU20 it is reserved from BTS level pool. This change in RNC algorithms is done due to new features in RU30 like RAN1637 High Speed Cell_FACH DL and RAN2847 18 Cells BTS Configuration.

Due to the change the H-RNTI value can always change, when a new HS-DSCH is allocated to the cell like in SCC. However, in certain conditions WN6 BTS SW is unable to reconfigure the new H-RNTI value which leads to HSDPA call drop. The condition for the issue to happen is as follows:

BTS is configured with shared scheduler license(i.e. one Machs scheduler serves multiple cells) one scheduler is hosted in one DSP Machs core

More than 1 HSDPA cell is hosted in a scheduler with the same frequency (not dual carrier) this will most likely happens in 1+1+1 scenario

If SCC is triggered between these cells with the change in H-RNTI the problem occurs

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


RNC workaround enables BTS level H-RNTI pool, ref CN RN60_0216. Actual correction is targeted in WN6.0 MP4.4.


This chapter compares 1.3 main changes against 1.2.


The following feature has been implemented:

RAN2731: 300G Hard Disk - HDS30-A The following feature has been implemented and ready for piloting:

RAN2746: Fast HSPA Mobility feature RN6.0 1.3 introduces the following correction which requires special actions to get it into use:

Valid SAC information missing from CDR after inter SGSN SRNS Relocation (CN RN60_0152, PRFILE 002:1935)

This is new functionality in RN6.0 1.3. This change is not active with default value 0H. Please follow the detailed instructions in the Change Note.

7.13 Changes in RN6.0 compared to RN5.0

7.13.1 RN6.0 1.4/1.3.1 compared to RN5.0

Following findings are concluded comparing RN6.0 1.3.1 performance against the pre-upgrade RN5.0 SW levels.

Key KPI related consideration:

RN6.0 SW activates the direct Cell_DCH to Cell_PCH transition by default (see chapter CONTENT DEVIATIONS FOR PREVIOUS RELEASE FUNCTIONALITY). This enables higher PCH state utilization which in turn causes more need for paging. This may cause an impact on the HSPA access ability due to UE KPI. RN6.0 (and RN5.0 MP5) changes the minimum E-TFCI when E-TTI=2ms is used. This enables UE to send data with minimum E-TFCI even if it is Tx power limited. Because of this it is important to follow the TS Note 159 recommendations for CPICHRSCPThreEDCH2MS (see TS-RNC-SW-159 chapter Changing E-DCH minimum set E-TFCI when E-TTI=2ms is used) and the new recommendations for HSUPA initial SIR target offset enhancement (see TS-RNC-SW-159 chapter HSUPA Initial SIR target offset enhancement). NA05046934: E-DCH 2ms TTI Utilization (%) increase from 20 to 26%

The increase took place after upgrade from RN5.0 PP2.11 and is due to correction in RN5.0 MP5 PR 54963ESPE03: UE Tx power issue with HSUPA 2ms TTI which enables that UE can send data although its Tx power limited


state in edge of cell. This causes less RLC SRB/PS resets with E-TTI=2ms configuration and may decrease the NRT re-establishment due to rlc resets.

NA05046107: L2 KPI - "RRC Connection Re-Establishment Fail Rate for RT" increased from 4.35% to 12.72%

The increase took place after upgrade from RN5.0 PP2.11, and was seen because baseline SW did not include correction for NA04855636: RRC_RE_EST_FAIL_NOREPLY_RT Counter Not Incrementing (CN RN50_1170 in RN5.0 MP3).

NA05047397: RAB Setup Time CS Voice, around 40ms improvement

Change is seen in RNC2600 after RN5.0 PP2.11 upgrade. NA05046940: Increase of Noise Floor of the System (dBm) by ~ 0.5db

Unloaded system noise level increases having a potential impact to Admission Control. This is expected behavior, see TS-RNC-SW-159.

NA05046950: Increase on DCH to HS-DSCH Channel Switch Fail Rate (%) from 0.8 to 1% and other counters

The increase took place after upgrade from RN5.0 PP2.11, and is expected behavior due to changes made in RN5.0 MP5, CN RN50_1626: RAN1642 MIMO not always activated if only once cell in Active Set.

NA05078647: HSDPA and HSUPA Resource and PS DCR increased by around 0.2% after PP8.7

7.13.2 RN6.0 1.2 compared to RN5.0

The findings are concluded comparing RN6.0 1.2 performance against the pre-upgrade RN5.0 SW levels. Key KPI related consideration:

HSDPA/HSUPA drops due to RL failure (M1002 counters) increased by ~0.8-1.3% after RN5.0 PP2.11 -> RN6.0 upgrade due to the known counter updating correction originally released in RN5.0 MP3 (see TS-RNC-SW-148 chapter HSDPA Release Failure increase) and also included in RN6.0.

Average DPMG unit load decreases ~5-10% in RNC2600 configuration. This is expected behavior due to architectural change in RNC SW. This is implemented only in RNC 2600 configuration.

RAB release counter impact due to the fault in RN5.0 (NA05074358: PMI ticket for CS part is missing for multi-RAB call). In case of multi-RAB call, cell update from IUR comes and directed signaling connection re-establishment triggers. During this procedure CS RAB was released but RNC did not update counter for CS RAB release. This has been corrected in RN5.0 MP5 so that RNC updates counter for CS RAB release during directed signaling connection re-establishment. This can be seen in RAB release counters as CS RAB release increase while comparing SW level lower than RN5.0 MP5 to RN6.0 SW level.


8. CONTENT DEVIATIONS FOR PREVIOUS RELEASE FUNCTIONALITY

By default all UEs except Nokia release 6 UE will perform direct transition to Cell_PCH in RN6.0 if there is inactivity/low utilization for HSPA/HSDPA call. This avoids unnecessary state changes (which reduces signaling) when data transfer is finished.

8.1.1 Other limitations

For OMU units, use the following USB devices:

Kingston DataTraveler G2

Kingston DataTraveler 101 G2

Kingston DataTraveler 2.0

SanDisk Cruzer 7.01

9. RELEASE CHANGE DOCUMENTATION

WCDMA RAN, Rel. RU30, Changes DN0979644 WCDMA RAN, Rel. RU30, Operating Documentation

Changes in RU30 includes information

Hardware changes

Alarm changes

Measurement changes

Changes in key performance indicators

MML Command Changes

Parameters Changes

Changes in configuration parameters

Changes in configuration parameters for radio network

Changes in configuration parameters for ATM transport plan

Changes in configuration parameters for IP transport plan

Current version of configuration parameters includes comparison between RN5.0 MP2 and RN6.0.


10. APPENDICES / REFERENCES

Technical Support Notes: RNC problem report instructions, TS-RNC-SW-038

RU20 impact on counters, TS-RNC-SW-148

PRFILE workarounds for 3rd party vendor issues, TS-RNC-SW-149

Recommended parameter set and enhanced algorithms for optimizing RRM functionalities, TS-RNC-SW-159

Workaround to disable Lossless PDU size change support, TS-RNC-SW-167

Incorrect Secondary OMS IP address after SW upgrade from RN5.0 to RN6.0, TS-RNC-SW-175

Hanging UHAPRB hand processes in RSMU of RNC196/RNC450 with ATM transport, TS-RNC-SW-180

Removing alarm blocks and FBAN flags if HMS Update Macro is aborted, TS-RNC-SW-168

Enhanced algorithms for optimizing RRM functionalities of RU30, TS-RNC-SW-189

Critical Problems and Workarounds for RN6.0, TS-RNC-SW-193

WCDMA RAN, Rel. RU30, Operating Documentation

PRFILE Descriptions, DN0948854

RN6.0 Release Upgrade Instructions for Local SW Installation, DN0986528

WCDMA RAN, Rel. RU30, Changes, DN0979644

Changes in Configuration Parameters for Radio Network, ATM Transport Plan, and IP Transport Plan, DN70357656

RN6.0 Release Compatibility Report, DN0984199


Disclaimer

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

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

Nokia Solutions and Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SOLUTIONS AND NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

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

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

Copyright 2013 Nokia Solutions and Networks. All rights reserved.

RN6.0 2.4 Change Note Forms Copyright 2013 Nokia Solutions and Networks. All rights reserved. CONFIDENTIAL APPROVED 1.0 Page 1

Change Note Forms Id: 2.4 (R6240000) Product Family: Radio Controllers Product: WCDMA RNC Release: RN6.0 Approval date: 16-Oct-2013

Summary of changes:

04-Jul-2013 0.1 Creation date 16-Oct-2013 1.0 Approval date

Noka Solutions and Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their components. If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Solutions and Networks for additional information.

Copyright 2013 Nokia Solutions and Networks. All rights reserved. CONFIDENTIAL 1(2)

Radio Controllers

CN-id: RN60_1061

Title: Cell's stays barred even CS and PS core raise up Version of the SW-build: Q6 1.49-0 Valid for Product(s): RNC References: Reason for the Change Note: Description of the fault: Cells stay barred even CS and PS core raise up. When sib sending for IU state change is cancelled due to new IU state change request, the new request is put in queue with forced SIB3 flag, so that SIB3 is not left inconsistent. While this request is still in queue, again new request for same CN is received with opposite status, then queue is cleared, but the forced SIB3 flag is lost. Thus SIB3 is not broadcasted further, leaving barring status inconsistent. Description of the correction: Correction done in REKOVE to copy forced SIB3 flag in case queued request is cleared. Thus in case of repeated IU link break, if a request from queue is cleared, SIB3 is still broadcasted while handling new request to avoid inconsistent cell barring status in SIB3. Corrected Fault Reports: 124422ESPE02 Cell's stays barred even CS and PS core raise up Modified components: Component Version REK_QXQX 12.36-0 NSN Testing Information: REK_QXQX.PAC Module testing: Done System Testing: Passed Change effects: Effects on end-user Effects on Operator


Other effects New functionality Customer Impact Operation & Maintenance: Operability Special Conditions for installation: Testing Instructions for the change: Pre-requirements: RNC with cells in working state, with Flex IU configuration. The exact configuration in this case is: IUO 1 PLMN id 244/89 2 IU-CS (CN index 1, 7) and 2 IU-PS (CN index 4, 6) IUO 2 PLMN id 244/88 2 IU-CS (CN index 2, 8) and 2 IU-PS (CN index 3, 5) For repeated CN state change, a macro is used to simulate continuous CN state changes. Test execution: This problem occurred in repeated CN state change using macro, exact steps are mentioned below, but repeated execution of these steps is required to reproduce the scenario. 1) When the cells are in working state, change all IU link states to disabled. The cells are barred. 2) Then bring up all IU links up one by one. The first IU link brought up for example is CN index 5. Before SIB3 is broadcasted, CN index 5 is disabled again, and SIB sending is thus cancelled. 3) Now, bring up CN index 5 up again. With this, the disabled state CN index change indication, which is in queue is removed, and enabled request is handled. Expected results: After third step, SIB3 is broadcasted with 'not barred' status. Unexpected results: After third step, SIB3 is not broadcasted at all, thus leaving cells in 'barred' state.


Radio Controllers

CN-id: RN60_1062

Title: Cells power estimation data periodic validity check was failing in the cell specific RRM Version of the SW-build: Q6 1.49-0 Valid for Product(s): RNC References: Reason for the Change Note: The original problem was, that cells power estimation data periodic validity check was failing in the cell specific RRM. The check reported errors on the cell power estimation data. In extreme cases, this could impact to the call setup KPIs, as the cell estimation data is used in the cell AC functionality. The problem was, when NRT activity indication was received for UE, which was not yet reconfigured for state transition (CCH to DCH) scenario, the NRT estimation data was incorrectly updated to the cell data. There is no workaround, but the estimation data is re-calculated with 10 sec interval, which fixes the issue. As a correction proper checks for the NRT DCH activity/inactivity indication handling is added, that the estimation data is correctly updated. Corrected Fault Reports: 103904ESPE04 BRM estimated cell data is incorrectly updated when NRT DCH activity indication is received before the UE setup is completed Modified components: Component Version BRM_QDQX 16.67-0 NSN Testing Information: BRM_QDQX.PAC Module testing: Done

Copyright 2013 Nokia Solutions and Networks. All rights reserved. CONFIDENTIAL Company Confidential

2 (2)

Change effects: Effects on end-user Effects on Operator Other effects New functionality Customer Impact Capacity & Performance: Call Setup Success Special Conditions for installation: Testing Instructions for the change: Pre-requirements: Test execution: This correction cannot be tested using the operator interface commands. The correction is tested internally in NSN test lab and proved to be fully functional. Expected results: - Unexpected results: -


Radio Controllers

CN-id: RN60_1063

Title: RRC states stack issue with log writing "check_for_empty_stack" Version of the SW-build: Q6 1.49-0 Valid for Product(s): RNC References: Reason for the Change Note: Problem description: During paging while RNC was receiving IU Release command, IU Release command was not handled due to which call was not released. Correction description: RNC is modified such that on receiving IU Release command during paging, it will release the call correctly. Corrected Fault Reports: 38774ESPE07 RRC states stack issue with log writing Modified components: Component Version RRC_QXQX 19.49-0 NSN Testing Information: RRC_QXQX.PAC Module testing: Done Change effects: Effects on end-user Effects on Operator Other effects


New functionality Customer Impact Capacity & Performance: Call Completion Success Special Conditions for installation: Testing Instructions for the change: Pre-requirements: RRC connection. PS RAB setup. CELL_DCH to CELL_PCH transition. Test execution: RRC receives DL DATA indication which starts paging. UE does not responds to paging. IU Release command arrives at RRC. Expected results: Call should be released. Unexpected results: Call is not released.


Radio Controllers

CN-id: RN60_1064

Title: Cell_FACH to Cell_DCH attempt fails occasionally Version of the SW-build: Q6 1.49-0 Valid for Product(s): RNC References: Reason for the Change Note: Problem Description: During HSPA User Plane setup, Radio Bearer Reconfiguration was sent to UE but UE doesn't respond. RNC is unaware of the UE configuration and updates its internal table according to the latest configuration sent to UE. So, after local transition to Cell_FACH, when Cell Update is received RNC is not able to remove transport channel information correctly from UE. In some cases this causes next Cell_FACH to Cell_DCH attempt to fail. Correction Description: Now RNC will revert back to Old Transport channel configuration when UE does not respond so that when UE sends Cell update then RRC tells the UE to delete correct transport channels. Corrected Fault Reports: 124115ESPE02 RU40: iphone 4 report configuration_unsupported after fach_relocation then esablish userplane for hspa NRT call Modified components: Component Version RRC_QXQX 19.50-0 NSN Testing Information: RRC_QXQX.PAC Module testing: Done Change effects: Effects on end-user Effects on Operator


Other effects New functionality Customer Impact Capacity & Performance: Call Setup Success Special Conditions for installation: Testing Instructions for the change: Pre-requirements: RRC Connection Exists. PS RAB Exists. Test execution: Source Side : 1. HSPA UP setup for PS RAB, RBR is Sent to UE. 2. UE doesn't responds to RBR. 3. UE is moved to local CELL_FACH state. 4.CELL Update over IUR is received by RNC and UE is moved to Target RNC. Target Side : 1. FACH Relocation with PS RAB. 2. State transiton from CELL_FACH to CELL_DCH is triggered. Expected results: UE is successfully moved to CELL_DCH state, Unexpected results: UE sends negative acknowledgement for RBR during state transition from CELL_FACH to CELL_DCH.


Radio Controllers

CN-id: RN60_1065

Title: RNC does not start up if mounted disk is initialized and empty Version of the SW-build: Q6 1.49-0 Valid for Product(s): RNC References: Reason for the Change Note: Description of the fault: POZMAN program block cannot distinguish the empty disk and cannot mount. Workaround: Plug out or power off the empty disk. Description of the correction: When POZMAN founds system has two different databases (disks), it will mount the disk to new folder "/shadows2" separately and checks if the "SOMAFIGX.IMG" file exists. If both exist return EDEADLK error and trap in restart loop. If only one exists and another does not, mounting is done the existing disk to "/shadows" and system can start up properly. Corrected Fault Reports: 124357ESPE02 RNC doesn't start-up if mounted disk is intialized and empty NA05450237 After WDU-0 change and OMU switchover MML commands not working. Modified components: Component Version BOPCC1DA 1.42-0 BOPCCP18 2.24-0 EKLIPSGX 6.35-0 POZMANGX 4.27-0 NSN Testing Information: EKLIPSGX.PAC Module testing: Done POZMANGX.PAC Module testing: Done BOPCCP18.PAC Module testing: Done


BOPCC1DA.PAC Module testing: Done Functional Testing: Passed System Testing: Passed Change effects: Effects on end-user Effects on Operator Other effects New functionality Customer Impact Stability: Network Element Restarts Operation & Maintenance: Operability Special Conditions for installation: Testing Instructions for the change: Pre-requirements: 1. Set one WDU to TE-EX STATE 2. Use ZIWI / ZIWK cmd initinal the WDU Test execution: Do system restart by ZUSS cmd Expected results: System can restart and all unit are OK. Unexpected results: system can't find the disk and can't start up.


Radio Controllers

CN-id: RN60_1072

Title: PCAP Position Activation Response is not sent Version of the SW-build: Q6 1.49-0 Valid for Product(s): RNC References: Reason for the Change Note: UE positioning measurement is not completed if Intra-RNC Hard Handover takes place during measurement period. Problem occurs because Handover Control re-initializes all its UE positioning measurement related internal data structures when Intra-RNC HHO is performed. As result, measurement is not interpreted as active and results are not forwarded to Location Services when UE sends a positioning related report for a measurement that was started before the HHO. Fault was corrected to Handover Control SW, so that it will preserve the positioning measurement related internal data structures throughout the HHO, which allows handling the UE measurement report properly if it is received only after the HHO. Corrected Fault Reports: NA05368255 PCAP Position Activation Response does not send Modified components: Component Version HA3_QDQX 22.62-0 NSN Testing Information: HA3_QDQX.PAC Module testing: Done Change effects: Effects on end-user

Copyright 2013 Nokia Solutions and Networks. All rights reserved. CONFIDENTIAL Company Confidential

2 (2)

Effects on Operator Other effects New functionality Customer Impact Operation & Maintenance: LCS (positioning) Special Conditions for installation: Testing Instructions for the change: Pre-requirements: Test execution: This correction cannot be tested using the operator interface commands. The correction is tested internally in NSN test lab and proved to be fully functional. Expected results: - Unexpected results: -


Radio Controllers

CN-id: RN60_1073

Title: PSHO 4G-3G need to ask UE capabilities always after a handover from LTE to UTRAN Version of the SW-build: Q6 1.49-0 Valid for Product(s): RNC References: Reason for the Change Note: Summary of the original problem: RNC does not receive full UE capabilities during inter-RAT handover from LTE to UTRAN and then RNC did not enquire also the UE Radio Access Capabilities from the UE. Because of the missing complete UE capability information, RNC could not make handover decisions for the UE correctly. Description of the correction: Correction has been made in RNC to ask the UE Capability after inter-RAT handover from LTE to UTRAN has been completed. Effects on operator: Inter-RAT handover is not working in this case. Corrected Fault Reports: NA05370986 PSHO 4G-3G need to ask UE capabilities always after a handover from LTE to UTRAN Modified components: Component Version RRC_QXQX 19.52-0 NSN Testing Information: RRC_QXQX.PAC Module testing: Done System Verification: Passed Change effects: Effects on end-user


Effects on Operator Other effects New functionality Customer Impact Capacity & Performance: Handover Success Special Conditions for installation: Testing Instructions for the change: Pre-requirements: Inter-RAT handover from LTE to UTRAN supported and enabled. Test execution: Inter-RAT handover to GSM after Inter-RAT handover from LTE. Expected results: Inter-RAT handover to GSM works. Unexpected results: Inter-RAT handover to GSM is not done.


Radio Controllers

CN-id: RN60_1074

Title: PCAP Position Parameter Modification is not sent Version of the SW-build: Q6 1.49-0 Valid for Product(s): RNC References: Reason for the Change Note: RNC does not send PCAP Modification information to IuPC during Inter-frequency Intra-RNC handover. This happens only if RNC sent Radio Bearer Reconfiguration message to the UE during the Intra-RNC hard handover. If RNC send hard handover command to the UE using Transport Channel Reconfiguration or Physical Channel Reconfiguration then RNC sends PCAP Modification Command to the UE. Correction has been made in the RNC to send PCAP Modification information also if Radio Bearer Reconfiguration message was used during Intra-RNC hard handover. Corrected Fault Reports: NA05370168 PCAP Position Parameter Modification does not send Modified components: Component Version RRC_QXQX 19.57-0 NSN Testing Information: RRC_QXQX.PAC Module testing: Done Change effects: Effects on end-user Effects on Operator


Other effects New functionality Customer Impact Operation & Maintenance Special Conditions for installation: Testing Instructions for the change: Pre-requirements: Positioning Measurements started and UE is capable of th

RN6.0 2.4 Documentation Set v1.2

Documents

Transcript of RN6.0 2.4 Documentation Set v1.2