Vous êtes sur la page 1sur 56

List of Generic Faults

LGF-BSC-2013-08
Radi o Controllers
B as e Station Controll er
S 15, S 16, MCS 15 REL1, MCT1
Approval date: (02-Sep-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.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 1

Table of Contents

1.

Generic faults NEW...................................................................................................................... 5


1.1 STMU HW Protection documentation update for switchovers................................................. 5
1.2 The BSC Periodic Measurement Events are not generated correctly ..................................... 5
1.3 GPRS problem (alarm 7725 TRAFFIC CHANNEL ACTIVATION FAILURE) .......................... 6
1.4 BCSU switchover ................................................................................................................... 6
1.5 All BCSUs failing the diagnostics due to the PCUs................................................................. 7
1.6 During OMU diagnostics, T0MATO in WO-EX MCMU raised 2794 HW BLOCK
FAILURE IN PLUG-IN UNIT alarm to STMU .................................................................................... 7
1.7 After MAINS BREAKDOWN in dual band cell TRXs on 1800 MHz do not come up ............... 8
1.8 BTS Plus: BTS is stuck in BL BTS when reconnect Abis link after break ................................ 9
2. Generic faults OPEN .................................................................................................................... 9
2.1 After PCUM switchover BVCI is in BL_SY for more than 30sec and TBFs in a cell
are dropped ..................................................................................................................................... 9
2.2 CS call setup problem during active PS session................................................................... 10
2.3 MCMU is not giving DHCP address if EMB-0 is put to TE state............................................ 10
2.4 Alarms '3541 ABNORMAL A INTERFACE IP RES RELEASE' ............................................ 11
2.5 Counter: 0500349 CH MODE MOD FAIL, is incrementing occasionally with WBAMR traffic ..................................................................................................................................... 11
2.6 Packet Pseudo Wire Tunnel BTS Measurement (118) for PWE site is not reported in
transmission file ............................................................................................................................. 12
2.7 ZWDL MML outputs DISK NOT UPDATED -error when trying to replace ETP-E
SW 12
2.8 Incorrect average load value in legacy Abis PCU pool after DAP modification ..................... 13
2.9 mcBSC: RNW stays in BL-ETP after module power break ................................................... 14
2.10 Unlock not possible on a LRTCH enabled TRX/BTS ............................................................ 14
2.11 Base station out of service ................................................................................................... 15
2.12 PCU1: Alarm 3164 PCU PROCESSOR OVERLOAD ........................................................... 16
2.13 3273 GPRS/EDGE territory failure ....................................................................................... 16
2.14 After BSS fast restart the BVCI state on BTS remains in BL-SY........................................... 17
2.15 After MP3.0 installation, the BSC is up and some NESIs are missing, PCU is
restarting using MML FXL .............................................................................................................. 17
2.16 A lot parameter take values are not planned after provision plan. ........................................ 18
2.17 Fax call not possible for BSC ............................................................................................... 18
2.18 ZW6R print wrong L3 switch configuration file content ......................................................... 19
2.19 MCMU restart increased after MP5 update .......................................................................... 20
2.20 After MP5.0 Upgraded ETP getting stuck in restart .............................................................. 20
2.21 Paging refused due to BCSU overload ................................................................................. 21
2.22 Lb Interface measurement Query ......................................................................................... 22
2.23 BCSU switchover fails after CP810 to CP1D HW upgrade in FlexiBSC ................................ 22
2.24 MCMU getting stuck in SP-UP ............................................................................................. 23
2.25 "PCU2 CAPACITY LICENCE EXCEEDED" error ................................................................. 23
2.26 DX Error 14226 NS -VC Object not found in DB ................................................................... 24
2.27 Alarm 1024 reported on BCSU due to error code received before process warming ............ 24
2.28 BCXU switchover caused /*** WARM UP FAILURE ***/ ....................................................... 25
2.29 McBSC: Too big values in Packet Abis SCTP Measurement................................................ 26
2.30 ETPA sudden increment of call handling .............................................................................. 26
2.31 MCMU-0 not able to recover from TE-EX state, After Power Reset of Box-0........................ 27
2.32 BCSU switchover stops BCCH reconfiguration .................................................................... 28
2.33 After MP1 installation BCXU goes to TE .............................................................................. 28
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 2

2.34 Wrong MAIO ( =0) broadcasted by BTS after reprinting ...................................................... 29


2.35 BSC spontaneous restart ..................................................................................................... 29
2.36 DX ERROR: 10203 OBJECT DOES NOT EXIST ................................................................. 30
2.37 Inconsistent data in radio resource, TCHDs IN BL-SYS ....................................................... 30
2.38 2G Extended Cell Issue........................................................................................................ 31
2.39 PCUMs in configuring state after PCUMs switchover ........................................................... 31
2.40 DTRX automatic power down - After system hot restart, DTRX power up is not
happening correctly. ....................................................................................................................... 32
2.41 The load of BSCU unit is too high with nominal CS-traffic .................................................... 33
2.42 ETPE unit automatic recovery .............................................................................................. 33
2.43 ETP restart needed after TCSU creation .............................................................................. 34
2.44 Wrong output in ZESI command .......................................................................................... 34
2.45 TFO interoperability enhancements...................................................................................... 35
2.46 CS call establishment fails due rc0_fail_oper_ind_s with cause
call_id_alr_allocated_c ................................................................................................................ 35
2.47 Warning LAPD MSG Distribution Problem............................................................................ 36
2.48 Incessant self-moving restarts and switchover of PCUMs .................................................... 36
2.49 No CS traffic after BSC restart ............................................................................................. 37
2.50 Active MCMU load is 100% .................................................................................................. 38
2.51 Some TCSMs are missing in "BSC TCSM Profile (523)" RS report ...................................... 38
2.52 Unable to delete Semi-permanent connection ...................................................................... 39
2.53 BSC Restart after unexpected MCMU switchover ................................................................ 39
2.54 mcBSC: RRM prints Failure: Illegal WB AMR call amount after every FA call with
WB-AMR codec ............................................................................................................................. 40
2.55 Segments do not get PSE's average PS load value during E/GPRS enabling in
empty PCUs ................................................................................................................................. 40
2.56 HO SR counters show 100% values..................................................................................... 41
2.57 SCF upload to Net Act failed after S15 MP5.0 implementation ............................................. 41
2.58 bts resource data error -log writings occurs in spare MCMU .............................................. 42
2.59 MCMU switchover is not possible ......................................................................................... 43
2.60 BTS MO upload from Net Act is getting failed for Flexi compact BTS ................................... 43
2.61 BSC send disconnect after BTS require handover ............................................................... 44
2.62 One BVCI out of working BVCIs is not coming to WO-EX state randomly ........................... 44
2.63 MP 6.0 Pilot: Degraded TBF Success rate after upgrade ..................................................... 45
2.64 CS call setup problem during active PS session................................................................... 46
2.65 MCMU disturbance "1007 RESTARTED PROGRAM BLOCK" ............................................. 46
2.66 McBSC OMU crashed .......................................................................................................... 47
2.67 Hanged GPRS in several cells - UL TBF discarded .............................................................. 47
2.68 Many 1178 alarms after Enabling DTM function ................................................................... 48
2.69 MCMU reset and switchover failure causing system restart ................................................. 49
2.70 BCSU doesn't switchover when AS7-D card is faulty ........................................................... 49
2.71 Processor time shortage alarm from SC7 (1B1) ................................................................... 50
2.72 BVCI in blocked state for segments with static NSEI ............................................................ 50
2.73 S15 mcBSC SA: BVCI stays in UNBLOCKED-state ............................................................. 51
2.74 S15 MP 4.0:"PXNETM: AS7 RESTART" After BCSU controlled switchover ......................... 51
3. generic faults closed .................................................................................................................. 52
3.1 BSAC-A eSW2.5.1 sensor 'ToP Ref OEM' and 'Sync-E QLOP1 OEM alarm issue .............. 52
3.2 BSAC-A eSW2.5.1 Sync mode (including SEC and BDG) testing failed ............................... 52
3.3 S16 MP0.0 installation macro doesn't copy BOLEROGX image to WDUs root..................... 53
3.4 BJC-A is double restarted after ZUSU MML ......................................................................... 53
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 3

3.5 BVCI in unblocked state after PCUM switchover .................................................................. 54


3.6 Working BCXUs with faulty flags and Radio Network dropped to not available after
cut off power from MCBC0 box ...................................................................................................... 54
3.7 BCSU0&5 abnormal ............................................................................................................. 55

Contact:
Contact your local Nokia Solutions and Networks support
Summary of changes:
27-08-2013

1.0-0

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

First version

Page 4

1. GENERIC FAULTS NEW


1.1 STMU HW Protection documentation update for switchovers
Problem report: 41488ESPE06
Exists in: S15
Correction Target: next documentation delivery of RG20, RG30 and mcBSC
Severity: C - Minor
Customer Impact:
1. Description of the fault
It was identified that automatic recovery mechanism for STMU did not work, because
ZYWR -command was not executed after previous manual/forced switchover.
2. How to observe the fault from the real network?
STMU switchover does not work.
3. What triggers the fault to be active?
STMU HW Protection documentation update for switchovers.
4. How the fault has been corrected in this implementation?
There is documentation update made for customer document 'YW - SDHSONET
Transmission Protection Handling, DN0635597'.
Below note will be added to chapters of the YWF/S/L, before the Examples section. After
this command is executed, please check if the command of YWR should be executed to
ensure the performance of automatic recovery mechanism.
5. How to recover from the fault without this correction?
-

1.2 The BSC Periodic Measurement Events are not generated correctly
Problem report: NA05430728, 40945ESPE07
Exists in: S16
Correction Target: S16.1 0.1.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
During RG30 acceptance tests on BSSTS protocol (feature 1376), the BSC doesnt
generate the Periodic Measurement Events.
2. How to observe the fault from the real network?
No Periodic Measurement sends to VNP.
3. What triggers the fault to be active?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 5

Capability Mask Measurement request from VNP.


4. How the fault has been corrected in this implementation?
Capability Mask Measurement handling is corrected in BSC application by adding the
UTPFIL parameter so that the function get_bssts_meas_mask is not called.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

1.3 GPRS problem (alarm 7725 TRAFFIC CHANNEL ACTIVATION FAILURE)


Problem report: NA05423932
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
GPRS problem (alarm 7725 TRAFFIC CHANNEL ACTIVATION FAILURE).
2. How to observe the fault from the real network?
Modified ETP IP address was not updated in PCU.
3. What triggers the fault to be active?
ETP IP address modification. Once ETP IP address was modified and after ETP restart,
PUB was not updating the modified ETP IP address in DB.
4. How the fault has been corrected in this implementation?
PUBDAT calls the routine "ip_conf_inq_by_tag_r" and checks if the ETP IP address is in
DB and the IP address returned by the routine are different and if both are different,
PUBDAT will update that modified value in DB.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction

1.4 BCSU switchover


Problem report: NA05425282, NA05402724
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: A - Critical
Customer Impact: Operation & Maintenance
1. Description of the fault
BCSU restart lead calling problem.
2. How to observe the fault from the real network?
The fault is observed with MML command ZAHP, alarm 1071 Processor shortage alarm
is observed in program block SC7(1B1) PRB.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 6

3. What triggers the fault to be active?


Transmission fluctuation in A -interface caused ET to go down. SC7 program block
receives lots of blocking message that triggered the fault to be active.
4. How the fault has been corrected in this implementation?
The fault was corrected in the platform routine LSIGNL.
The routine was optimized in order to occupy less CPU load. The minor delay of 10
milliseconds is added the SC7 program block in order to avoid the high BCSU load.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

1.5 All BCSUs failing the diagnostics due to the PCUs


Problem report: NA05418154, 39550ESPE07, NA05408909
Exists in: S15
Correction Target: S15 MP7.0
Severity: B - Major
Customer Impact:
1. Description of the fault
Ethernet PHY loopback tests fails in the main image during commanded diagnostics for
PCU2E cards. The same card passes the diagnostics at all three Ethernet points
(external, PHY and internal) during BIST tests.
2. How to observe the fault from the real network?
Switch BCSU to TEST state (TE) and run commanded diagnostics using the command
ZUDU:BCSU,BCSU_ID:PCUT.
3. What triggers the fault to be active?
The fault becomes active whenever commanded diagnostics is run using MML command
ZUSC due to incorrect initialization of buffers.
4. How the fault has been corrected in this implementation?
The Ethernet PHY loopback test has now been moved after CORE STARTUP in the case
of PCU2E cards. The tests are now being performed once the DSP images are
downloaded.
5. How to recover from the fault without this correction?
It is observed that the Ethernet interface works fine when the card is up in spite of the
failure notice. The same tests when performed as part of BIST are successful.

1.6 During OMU diagnostics, T0MATO in WO-EX MCMU raised 2794 HW BLOCK
FAILURE IN PLUG-IN UNIT alarm to STMU
Problem report: 127436ESPE02
Exists in: S16
Correction Target: S16.1 0.0.0
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 7

Severity: B - Major
Customer Impact:
1. Description of the fault
During OMU diagnostics, T0MATO in WO-EX MCMU raised 2794 HW BLOCK FAILURE
IN PLUG-IN UNIT alarm in STMU units. Then STMU units have FLTY status.
2. How to observe the fault from the real network?
Change OMU to TE state and diagnose it. After diagnostics completes, change OMU to
WO state. When OMU becomes WO-EX state, check alarm history and units' states.
3. What triggers the fault to be active?
The loop tests of STMU and ETIP units are done alternately. The loop path is changed
also alternately. Then TSUPRO will send loop test failure message to T0MATO because
the path is different from the last one. If T0MATO receives two path error messages
continuously, it will raise alarm 2794.
4. How the fault has been corrected in this implementation?
For loop test of STMU or ETIP units, TSUPRO doesn't need to check the path change
when loop test completes.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

1.7 After MAINS BREAKDOWN in dual band cell TRXs on 1800 MHz do not come up
Problem report: NA05439097
Exists in: S16
Correction Target: S16.1 0.1.0
Severity: A - Critical
Customer Impact: Operation & Maintenance
1. Description of the fault
After MAINS BREAKDOWN in dual band cell TRXs on 1800 MHz do not come up.
Mains break means any fault in ET line or connection failure between any connectivity
between BSC and BTS.
2. How to observe the fault from the real network?
After MAINS BREAKDOWN in dual band cell TRXs on 1800 MHz getting stuck in BL-RST
state.
3. What triggers the fault to be active?
Activation and deactivation of 7995 alarm. After MAINS RECOVERY, BTS is not sending
BTS STATE CHANGE for few TRXs within the expected timeframe in BSC since links are
not up for those TRXs at that time.
4. How the fault has been corrected in this implementation?
GUPDAT correction is done by changing the TRX state to BL-RSL. Later when links
recover TRXs will be bought back to WO state.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 8

1.8 BTS Plus: BTS is stuck in BL BTS when reconnect Abis link after break
Problem report: 40472ESPE07, NA05436403
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault
RNW goes to BL-BTS after PCM failure when BTS site type is BTS PLUS.
2. How to observe the fault from the real network?
Alarm 7604 is triggered for BTS Plus. This alarm is sent to GUP with fault type as BTS_C.
3. What triggers the fault to be active?
PCM failure.
4. How the fault has been corrected in this implementation?
This alarm will not be sent to GUP.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2. GENERIC FAULTS OPEN


2.1 After PCUM switchover BVCI is in BL_SY for more than 30sec and TBFs in a cell
are dropped
Problem report: 41450ESPE06
Exists in: S16
Correction Target: S16.1 0.1.0
Severity: B - Major
Customer Impact:
1. Description of the fault
After PCUM switchover BVCI is in BL_SY for 60 seconds and TBFs in a cell are dropped.
2. How to observe the fault from the real network?
After PCUM switchover in a PCU pooling configuration, it was observed that BVCI is
taking more than 30 seconds to come to WO state.
3. What triggers the fault to be active?
During PCUM switchover, if there is other working PCUMs in the pool, and then NSE is
not reset during switchover. In such cases feature bit map will not be sent by PCU and
GBA need not wait for 30 sec to receive feature bit map before starting BVCI deblocking
procedures.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 9

4. How the fault has been corrected in this implementation?


Corrected GBADMI code such that during switchovers when NSE is not reset, then
GUPDAT can be informed that Gb is UP after 5 seconds.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.2 CS call setup problem during active PS session


Problem report: NA05404101, NA05409184, NA05436451
Exists in: S16
Correction Target: S16 PP0.1.6
Severity: B - Major
Customer Impact:
1. Description of the fault
In MCBSC, Paging co-ordination feature is not working together with Precise Paging
Feature.
2. How to observe the fault from the real network?
Cannot perform CS call to subscriber when subscriber has active GPRS connection.
3. What triggers the fault to be active?
Cs_paging_req_s message is not send from ABI to PCUM because the address picked
from location database is wrong, when precise paging feature is active. MCPCU address
information saved in ABIPRB's location_db_tbl was wrong.
4. How the fault has been corrected in this implementation?
The fields in the location database and paging co-ordination database changed in such a
way that PCU PID is saved in the table and the message cs_paging_req_s sent to the
saved PCU PID so that the message reaches in PCUM and paging co-ordination works.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.3 MCMU is not giving DHCP address if EMB-0 is put to TE state


Problem report: 99575ESPE04, 88220ESPE01
Exists in: S16
Correction Target: S16.1 0.1.0
Severity: C - Minor
Customer Impact:
1. Description of the fault?
BJC-A card does not come up if EMB-0 is put to TE state.
Issue exists with mcBSC configurations.
2. How to observe the fault from the real network?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 10

If EMB-0 is falling down to TE-EX or below state and a BJC-A unit restarts.
Card will not come into working state.
3. What triggers the fault to be active?
The DHCP timeout timer is too high. OMU will restart the unit before it has a chance to
change the interface and starts booting from the secondary network interface.
4. How the fault has been corrected in this implementation?
The DHCP Timeout timer will be decreased accordingly,
5. How to recover from the fault without this correction?
Try to bring back the EMB-0 to WO state.

2.4 Alarms '3541 ABNORMAL A INTERFACE IP RES RELEASE'


Problem report: NA05374703
Exists in: MCS15 REL1
Correction Target: S16.1 0.0.0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault?
Alarms '3541 ABNORMAL A INTERFACE IP RES RELEASE' is observed multiple times
in mcBSC.
2. How to observe the fault from the real network?
Check the alarm history using ZAHP command.
3. What triggers the fault to be active?
When a call is released from A interface because of RESET IP RESOURCE,
then RC0 raises this alarm but it doesn't send ACK to AIV and hence ack
is not received by MSC via AIV and MSC keep sending RESET IP RESOURCE
message to BSC and the alarm is raised many times.
4. How the fault has been corrected in this implementation?
RC0PRB is enhanced so that it will send the ACK to AIV correctly in this case
and AIV will send ACK to MSC and this alarm will not be raised many times.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.5 Counter: 0500349 CH MODE MOD FAIL, is incrementing occasionally with WBAMR traffic
Problem report: 120605ESPE02
Exists in: S16
Correction Target: S16.1 0.1.0
Severity: C - Minor
Customer Impact:
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 11

1. Description of the fault?


Counter 0500349: CH MODE MOD FAIL is incrementing with WB-AMR traffic.
Value of used speech codec does not match in IEs CHANNEL MODE and MULTI-RATE
CONFIGURATION in CHANNEL MODE MODIFY message when change from WB-AMR
to NB-AMR is made.
2. How to observe the fault from the real network?
Value of counter 0500349 CH MODE MOD FAIL has increased.
3. What triggers the fault to be active?
Issue is under investigation.
4. How the fault has been corrected in this implementation?
Issue is under investigation.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.6 Packet Pseudo Wire Tunnel BTS Measurement (118) for PWE site is not reported in
transmission file
Problem report: 37581ESPE06
Exists in: S16
Correction Target: S16.1 0.1.0
Severity: C - Minor
Customer Impact: Stability
1. Description of the fault?
BSC is not sending BTS_TRANSMISSION_COMMAND for PWE sites on absolute hrs.
2. How to observe the fault from the real network?
Packet Pseudo Wire Tunnel BTS Measurement (118) for PWE site is not reported in
transmission file.
3. What triggers the fault to be active?
Trigger for the fault to be active is when customer started Pseudo Wire Tunnel BTS
measurement from BSC. When measurement was started, it was observed that BSC was
not sending TRANSMISSION COMMAND to BTS.
4. How the fault has been corrected in this implementation?
No specific correction delivered for this pronto. Pronto was not reproducible with latest
S16 BSC SW.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.7 ZWDL MML outputs DISK NOT UPDATED -error when trying to replace ETP-E
SW

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 12

Problem report: 99740ESPE04


Exists in: S16
Correction Target: S16.1 0.1.0, S15 MP7.0
Severity: C - Minor
Customer Impact:
1. Description of the fault?
Error DISK NOT UPDATED is visible for output of ZWDL -MML when trying to replace
ETP-E SW.
2. How to observe the fault from the real network?
In the output of MML command ZWDL error can be observed, e.g.

FUNCTIONAL PLUG-IN UNIT


UNIT TYPE INDEX RESULT
----------- ------------- ------ETPE-0-0 ETP-0 SUCCESS
ETPE-0-1 ETP-1 DISK NOT UPDATED ,
3. What triggers the fault to be active?
Fault was observed ZWDL command was given too quickly when ETP card has just been
restarted. As the card is just coming up, ETP flash is being used by some process and
cannot handle SW download request.
4. How the fault has been corrected in this implementation?
This is a rare race condition which does not require any SW fix. A different error code
(ERROR CODE: 12346 TOO MANY SIMULTANEOUS OPERATIONS) has been added to
display actual issue.
5. How to recover from the fault without this correction?
Re-execute ZWDL command for the earlier unsuccessful ETP unit.

2.8 Incorrect average load value in legacy Abis PCU pool after DAP modification
Problem report: 69392ESPE03
Exists in: S16
Correction Target: S16.1 0.1.0
Severity: C - Minor
Customer Impact:
1. Description of the fault?
Incorrect average load value in legacy Abis PCU pool after DAP modification; Average
load value of one PCU pool can be taken to use also in other PCU pools when DAP
without load value is visiting some other PCU pool.
2. How to observe the fault from the real network?
There is incorrect average load value in legacy Abis PCU pool after DAP modification.
3. What triggers the fault to be active?

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 13

When BTS is configured into PCU pool (GENA Y) it is tried to define some average load
value to it according other BTSs in same PCU pool. When DAP is moved between PCUs
and some BTSs are attached to it, BTSs GENA
is handled internally and BTS may have some PS-load defined already in its original PCU
pool. Current DAP PCU modification does not separate if that BTS PS-load was real load
or possible some previous average load. This causes case where DAP BTSs in new PCU
pool would have incorrect average load.
This also causes that some new BTSs would get also incorrect average load if they are
added into same PCU pool where DAP BTSs where moved.
4. How the fault has been corrected in this implementation?
Average load value in legacy Abis PCU pool after DAP modification has been corrected.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.
Precaution to avoid this issue: Avoid moving DAP with BTS between PCU pools before
one hour of having that DAP and BTSs in PCU pool first time (to get those BTSs their
actual PS-load defined). Modify DAP PCU in same PCU pool only. Set BTSs GENA N
before DAP modify.

2.9 mcBSC: RNW stays in BL-ETP after module power break


Problem report: 97400ESPE04
Exists in: MCS15 REL1
Correction Target: S16.1 0.1.0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault
RNW stays in BL-ETP after module power break.
2. How to observe the fault from the real network?
After Module Power Break, ETME which takes active role doesn't have any BCF's/PCU
Configured. In BSDATA, PCU's connected to ETME are stuck in configuring state. BCF's
are in BL-ETP state.
3. What triggers the fault to be active?
Module Power Break Up.
4. How the fault has been corrected in this implementation?
With Latest logs, there is NACK with Error code 741from ETME, which results in ALARM
3525.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.10 Unlock not possible on a LRTCH enabled TRX/BTS


Problem report: 40830ESPE07
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 14

Exists in: S16


Correction Target: S16.1 0.1.0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault
Unlock not possible on a LRTCH enabled TRX/BTS.
2. How to observe the fault from the real network?
Lock TRX and Enable LRTCH parameter for a TRX for a flexi multiradio-10/Compact Site
type. Unlock TRX. Unlock operation command will fail.
3. What triggers the fault to be active?
BCF SW version checking is not applicable for FMR-10 or Flexi compact.
4. How the fault has been corrected in this implementation?
Subsitetype checking introduced for LRTCH enabled TRX.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.11 Base station out of service


Problem report: NA05393817
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
Base station out of service.
2. How to observe the fault from the real network?
Try to do a BTS lock/unlock operation. BCFs in some BCSU are going to BL-SYS state
and find an AOM process exception in those BCSUs.
3. What triggers the fault to be active?
In initial (start up) stage, AOM master is reading the configuration details of BCSU from
BYCLIB library. That library dat contains the number of BCF limit per BCSU value i.e.,
maximum number of BCFs can configure per BCSU. AOM master has an internal table for
storing BCF information. The size of the internal table is 500. If the BYCLIB library
returning number of BCF per BCSU value is greater than 500, then the AOM master
internal table will over flow. 500 is the maximum BCFs per BCSU in any type of BSC.
McBSC it is 550.
4. How the fault has been corrected in this implementation?
AOM master is checking the BYCLIB library value. If the maximum number of BCFs per
BCSU is greater than 500 then AOM master will reset BYCLIB value with 500 in AOM.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 15

2.12 PCU1: Alarm 3164 PCU PROCESSOR OVERLOAD


Problem report: NA05346771
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: B - Major
Customer Impact: Stability
1. Description of the fault
Overload alarm 3164 is randomly seen active for PCU for a short time.
2. How to observe the fault from the real network?
Alarm 3164 PCU PROCESSOR OVERLOAD found in alarm history.
3. What triggers the fault to be active?
This fault (CPU load goes up 20-25% of normal) gets triggered of a set of EGPRS
channels L1 re-synchronization happening at a time. The basic trigger of the scenario is
found as crossing the threshold of incompatible L1 frame count for a TRX. In the current
implementation the defense of the threshold cross is to trigger re-synchronization
procedure for all the active GP timeslots of the TRX. In a worst case the TRX which is
affected so do carry the SMCH of a particular DAP, and this causes all the TRXs linked to
the DAP also gets affected and go for L1 re-synchronization. This whole procedure
executing at a moment causes the ABATOR module consuming CPU load for a bit longer
time and results in 3164 alarm for PCU.
4. How the fault has been corrected in this implementation?
When incompatible L1 frame count for a TRX get crossed, the chain reaction of resynchronizations of many GP channels is controlled with only one active GP channel of
TRX is re-synchronized. This avoids a sudden increase in CPU load and the 3164 alarm
trigger possibility is avoided.
5. How to recover from the fault without this correction?
BCSU switchover resolves the issue.

2.13 3273 GPRS/EDGE territory failure


Problem report: NA05325792
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: B - Major
Customer Impact:
1. Description of the fault
3273 GPRS/EDGE TERRITORY FAILURE alarms are observed.
2. How to observe the fault from the real network?
Alarm history shows the alarm 3273.
3. What triggers the fault to be active?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 16

PCU1 internal databases in DAM and DPA go out of sync.


4. How the fault has been corrected in this implementation?
Recovery mechanism of the PCU1 internal database was corrected.
5. How to recover from the fault without this correction?
BCSU switchover.

2.14 After BSS fast restart the BVCI state on BTS remains in BL-SY
Problem report: NA05405177
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault
After BSS fast restart, it is observed that BVCI state remained in BL-SY.
2. How to observe the fault from the real network?
After performing BSS FAST RESTART and executing command "ZEQO:BTS=:GPRS;"
BVCI state remains in BL-SY.
3. What triggers the fault to be active?
During BSS fast restart, the PCUs restart. During the BCF configuration "cell deblock" is
not send to PCU because it is not up. Later When GBADMIN informs GP Interface Up
when it is up. That time GUP fails to handle it.
4. How the fault has been corrected in this implementation?
The variable system_restart_started to FALSE in case of FBSS, after receiving
unit_restart_info_s".
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.15 After MP3.0 installation, the BSC is up and some NESIs are missing, PCU is
restarting using MML FXL
Problem report: NA05400753, NA05394555
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: B - Major
Customer Impact:
1. Description of the fault
After MP3.0 installation, the BSC is up but some NESIs are missing, also PCU is
restarting using MML FXL.
2. How to observe the fault from the real network?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 17

Issue is observed in a BSC having close to maximum number of PCUs (100) configured
with multipoint Gb and without PCU pooling, after MP3.0 installation.
3. What triggers the fault to be active?
In case of some of the GBA internal tables, table size was not enough to handle maximum
NSE/PCU configuration. This was leading to data corruption in memory. Hence GBA PCU
hand table entries were corrupted with invalid entries or zeros. These resulted problems in
PCU hand functionality, thus PCUs were in restarting state and NSE problem occurred.
4. How the fault has been corrected in this implementation?
Corrected GBADMI code such that all tables can handle up to maximum number of NSEs
in the BSC and with proper boundary checking in all places in code while adding entries to
table.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.16 A lot parameter take values are not planned after provision plan.
Problem report: NA05389115
Exists in: S16
Correction Target: S16.1 0.0.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
At the end of the plan provisioning operation, in the generated XML event file, some
parameters take values that are not contained in the plan.
2. How to observe the fault from the real network?
Perform a plan provisioning operation and check the generated XML event file. Some
parameters (e.g.: masterBCF) will have values different from the plan file.
3. What triggers the fault to be active?
In the current code, the value handling for these parameters has been done incorrectly
with a validation using a ternary operator and bitwise AND.
4. How the fault has been corrected in this implementation?
Modified PNCLIB code (i.e. PNCLIBSX.C) based on the values received from MRFPRB
(which is a FBPP module) and given to XEHPRB (which is a RBQ3F module). Note that
the legacy validation has been removed.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.17 Fax call not possible for BSC


Problem report: NA05339838
Exists in: MCS15 REL1
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 18

Correction Target: mcS15 PP0.0-4, S16.1 0.1.0


Severity: A - Critical
Customer Impact: Capacity & Performance
1. Description of the fault
Fax Call is NOT working.
2. How to observe the fault from the real network?
Fax call is not working. "Completed with error message in FAX machine and on the MOC
end, we get "the fax call was not answered" response.
3. What triggers the fault to be active?
Fax call, when data rate modification tried, MSC sent Assignment request again with new
data rate .Abi_assignment_s message has been sent to ABIPRB TCH hand and TCH is
sending message to ETPE.(with wrong ETP message type and ETP ACK that request and
TCH sends CHANNEL ACTIVATION again to BTS and BTS is sending NACK for channel
activation.).
4. How the fault has been corrected in this implementation?
No need of ETPT/E message communication. Skip the ETP communication part. When
abi_assignment_s received for the second time (for data rate change) sent MODE
MODIFY to BTS.
5. How to recover from the fault without this correction?
There should NOT be any data rate change in between the fax call.

2.18 ZW6R print wrong L3 switch configuration file content


Problem report: NA05399761
Exists in: S16
Correction Target: S16.1 0.0.0
Severity: C - Minor
Customer Impact:
1. Description of the fault
After OMU restart reading of SWU configuration files does not show real configuration of
LAN switch.
2. How to observe the fault from the real network?
ZW6R command execute.
3. What triggers the fault to be active?
L3 switch configuration file use the wrong file status flag.
4. How the fault has been corrected in this implementation?
Corrected L3 switch configuration file status flag.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 19

2.19 MCMU restart increased after MP5 update


Problem report: NA05383055, NA05393211, NA05396689, NA05403468, NA05404640
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
MCMU restart increased after MP5 update and Spare MCMU stays in SP-UP state, due to
TFHPRB (Transcoder Fault Handling Program Block) Warm-up failure.
2. How to observe the fault from the real network?
Spare MCMU is restarting multiple times, and following disturbances 1022, 1684, related
to TFHPRB warm-up failure appears in to the system.
HIST CBN30
OMU
SWITCH 2013-05-14 11:16:29.42
* DISTUR MCMU-1 1A003-06 RCXPRO
1001 UNIT RESTARTED
SP-RE 00 02 00 00 01, HIST CBN30
OMU
SWITCH 201305-14 11:17:33.42
NOTICE MCMU-1 1A003-06 RCXPRO
0691 AUTOMATIC RECOVERY ACTION
SP-RE SP-UP 0005 00A0 0855 00000000 00000000 00000000, HIST CBN30
MCMU-1
SWITCH 2013-05-14 11:19:20.82
* DISTUR MCMU-1 1A003-06 USAPRO
1022 PROGRAM BLOCK WARMUP FAILURE
0108 17338d 0005 0259, HIST CBN30
OMU
SWITCH
2013-05-14 11:27:33.45
* DISTUR MCMU-1 1A003-06 RCXPRO
1684 SPARE UNIT WARMUP FAILURE
0003 793d 0005 00A0 FFFF FFFFFFFF
3. What triggers the fault to be active?
"Pre__spv_msg_s" message was sent to PSAPRB until it replies back.
This message sending was continued without checking whether TCSM is up or not. This
in turn created issues like ignoring some alarms like 1010 and some messages. This in
turn created the TFH to restart and MCMU as well.
4. How the fault has been corrected in this implementation?
Sending of the message pre__spv_msg_s to PSAPRB is limited to only 10 times and with
a new interval of 5 sec. If its not replying back then it will come out of the loop and
continues with other operations.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.20 After MP5.0 Upgraded ETP getting stuck in restart


Problem report: NA05380679
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 20

Exists in: S15


Correction Target: S15 MP7.0, S16.1 3.5-0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault?
Protecting ETPE unit going to TE-EX state when system restart with ETPE/T restart is
executed.
2. How to observe the fault from the real network?
Check the alarm after the scenario. Alarm 3571(PROTECTING ETP CONFIGURATION
FAILED) can be seen from PUB on protecting unit and it would have moved to TE-EX
state.
3. What triggers the fault to be active?
When there is a PEP connection between ETP and PCU2D, after system restart with
ETPE/T restart scenario, PCU connection handling bool was not handled correctly
in RC0 and the issue was triggered.
4. How the fault has been corrected in this implementation?
RC0PRB is enhanced so that during system restart with ETPE restarts this bool
is handled correctly and correct ACK is sent to PUB. So that PUB will not
raise alarm on the protecting Unit and ETPE/T will not be moved to TE-EX state.
5. How to recover from the fault without this correction?
ETPE/T restart

2.21 Paging refused due to BCSU overload


Problem report: NA05349548, NA05282464, NA05342901
Exists in: S15
Correction Target: S15 MP6.0, S16.1 3.5-0
Severity: B - Major
Customer Impact:
1. Description of the fault
High BCSU load causing Paging success rate degradation.
2. How to observe the fault from the real network?
BCSU_OVERLOAD_LOWER_LIMIT and BCSU_OVERLOAD_UPPER_LIMIT causing
paging rejection.
3. What triggers the fault to be active?
High load in BCSU due to RCSPRB will result in increase in the
BCSU_OVERLOAD_LOWER_LIMIT and BCSU_OVERLOAD_UPPER_LIMIT counters
and paging gets rejected.
4. How the fault has been corrected in this implementation?
RCSPRB has been optimized to use lesser CUP cycles to perform the desired
functionalities.
5. How to recover from the fault without this correction?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 21

There is no recovery or workaround without correction.

2.22 Lb Interface measurement Query


Problem report: NA05289516
Exists in: S14
Correction Target: S15 MP5.0, S16.1 3.5-0 main package
Severity: A - Critical
Customer Impact:
1. Description of the fault
Cell Identity List in TA response is not in the same order than cells reported in the
Measurement Result.
2. How to observe the fault from the real network?
If the two or several cells are reported with the same Rx level value in the Measurement
Result the Cell Idenrity List is sorted so that cell which have lower BCCH FREQ will be on
the top of the Cell Identity List, means that cells could be in different order in MR and Cell
Identity List.
3. What triggers the fault to be active?
TA request and if the several cells are reported with the same RX level value in the
Measurement Result message.
4. How the fault has been corrected in this implementation?
There is now introduced new UTPFIL parameter which controls how the BSC SW sorts
the Cell Idenrity List. If the parameter is enabled the Cell Idenrity List is sorted in same
order than cells are reported in MR. If parameter is not enabled the existing
implementation takes place.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.23 BCSU switchover fails after CP810 to CP1D HW upgrade in FlexiBSC


Problem report: NA05231658
Exists in: S15
Correction Target: S15 MP6.0, S16.1 3.5-0, mcS15 PP0.0-4
Severity: B - Major
Customer Impact: Capacity & Performance
1. Description of the fault
BCSU switchover fails after CP810 to CP1D HW upgrade in FlexiBSC.
2. How to observe the fault from the real network?
After all CPUs are replaced with CP1D, BCSU switchover fails due to ABI warm up failure
in spare BCSU. ABI exception alarm will follow and spare unit is restarted by system.
3. What triggers the fault to be active?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 22

BYCLIB returns different value for BSC TRX capacity during HW upgrade.
After the last BCSU upgrade, the spare will be having higher buffer size for Statistics
Measurement. But due to warming, the buffer is resized during switchover. This leads to
the exception.
4. How the fault has been corrected in this implementation?
Measurements handled by ABI are locked before the switchover.
After warming, the buffer is resized as per the Capacity. Measurements are unlocked.
5. How to recover from the fault without this correction?
System restart.

2.24 MCMU getting stuck in SP-UP


Problem report: NA05421273, NA05429651
Exists in: S15
Correction Target: S16.1 0.0.0, S15 MP7.0
Severity: B - Major
Customer Impact:
1. Description of the fault
MCMU getting stuck in SP-UP.
2. How to observe the fault from the real network?
Restart the MCMU.
3. What triggers the fault to be active?
Recent functionality change added was sending a pre__spv_msg_s to PSAPRB 10 times
with a time interval of 3secs.
4. How the fault has been corrected in this implementation?
Sending of the message pre__spv_msg_s to PSAPRB has been limited by using UTPFIL
patching and the number of retries increased. Patching reduces the delay in sending
hypothesis_reset_ack_s and prevents spare MCMU from being struck in SP-UP state.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.25 "PCU2 CAPACITY LICENCE EXCEEDED" error


Problem report: NA05363605, NA05373649
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
"PCU2 CAPACITY LICENCE EXCEEDED" error shown after replacing PCU2D cards with
PCU2E cards in BCSU.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 23

2. How to observe the fault from the real network?


When PCU2D cards in a BCSU are replaced with PCU2E cards, after that GTRX
operations show "PCU2 CAPACITY LICENCE EXCEEDED" error.
3. What triggers the fault to be active?
When PCU2D cards in a BCSU are replaced with PCU2E cards and post BCSU
switchover, the track type was not getting updated properly in BSDATA. As a result,
during PCU capacity calculations, calculations are done based on PCU2D type and hence
GTRX operations show "PCU2 CAPACITY LICENCE EXCEEDED" error.
4. How the fault has been corrected in this implementation?
Corrected GBADMI code such that whenever the track type in database is different than
the weakest PCU type returned from BYCLIB routine, the BSDATA is updated with the
right track type during BCSU switchover.
5. How to recover from the fault without this correction?
GB delete/recreate.

2.26 DX Error 14226 NS -VC Object not found in DB


Problem report: NA05368804
Exists in: MCS15 REL1
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
When Resetting the BCN Box in mcBSC, WO MCMU changed to WO-RE again after it
had been WO-EX. This caused the SP MCMU couldnt warm up successfully and couldnt
go to SP-EX, also BCXUs and PCUMs were stuck in WO/SP-RE state.
2. How to observe the fault from the real network?
Resetting the BCN Box in mcBSC.
3. What triggers the fault to be active?
When USAPRO receives mcBSC "restart_notif_s" message, it will spread this message to
its child units.
4. How the fault has been corrected in this implementation?
Stop expanding message "restart_notif_s" to its child units when master unit is none
restart able unit.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.27 Alarm 1024 reported on BCSU due to error code received before process
warming
Problem report: NA05361180
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 24

Exists in: S15


Correction Target: S15 MP6.0, mcS15 PP0.0-5, S16.1 0.1.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
If there is status change of SP-UP on BCSU without SORPRO warming, it may lead to SP
master starting to get messages sent using logical WO-SP address.
2. How to observe the fault from the real network?
After OMU restart alarms 1024 "HAND PROCESS ERROR IN PROGRAM BLOCK" is set
immediately on BCSU.
3. What triggers the fault to be active?
The fault in EPOFFI causes SCDFIL distribution failure sometimes. The message
communication fails when unit state is different in SCDFIL (=WO) and own_unit_state is
=sp.
4. How the fault has been corrected in this implementation?
In the previous change was added functionality to detect invalid block message, if
message is corrupt, message is discarded. But there was some problem in the checking
of block messages; some normal block messages were also discarded. In this new
version of EPOFFI problematic checking was removed.
5. How to recover from the fault without this correction?
There is no workaround or recovery without this correction.

2.28 BCXU switchover caused /*** WARM UP FAILURE ***/


Problem report: NA05376404
Exists in: MCS15 REL1
Correction Target: S16.1 0.1.0
Severity: C - Minor
Customer Impact:
1. Description of the fault
Controlled BCXU switchover failure during traffic conditions having CS calls and SMS
delivery.
2. How to observe the fault from the real network?
Perform a controlled BCXU switchover during traffic conditions having CS calls and SMS
delivery.
3. What triggers the fault to be active?
Leftover messages in message queue that prevents warming up of spare unit and hence a
switchover failure.
4. How the fault has been corrected in this implementation?
Variable initialization has been corrected which originally prevented the messages from
being processed.
5. How to recover from the fault without this correction?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 25

There is no recovery or workaround without correction.

2.29 McBSC: Too big values in Packet Abis SCTP Measurement


Problem report: 37455ESPE05
Exists in: MCS15 REL1
Correction Target: S16.1 0.0.0, S15 MP8.0
Severity: C - Minor
Customer Impact:
1. Description of the fault
There are too big counters in Packet Abis SCTP Measurement.
2. How to observe the fault from the real network?
When gathering the Packet Abis SCTP statistics, the counters have too big values like
below:
"Number of valid counters : 5, 125000 : SCTP_PACKETS_RECEIVED_BSC :
4294967295
125001 : SCTP_PACKETS_SENT_BSC : 4294967294
125002 : SCTP_OCTETS_RECEIVED_BSC : 4294892172
125003 : SCTP_OCTETS_SENT_BSC : 4294892384
125004 : SCTP_PACKET_RETRANSMIT_BSC : 0000000000",
3. What triggers the fault to be active?
The statistics collection during switchover has some problem. The content of IUJFIL and
IUJFIL2 are not changed during switchover. Then below situation may happen: e.g.
BCXU-0 is WO-EX at first, after several switchovers, BCXU-0 becomes WO-EX again, but
the IUJFIL2 and IUJFIL are basically the same with the situation before these switchovers.
In the above situation, for one association in IUJFIL2, the status is UP, and after several
association re-establishments, the new counters in IUJFIL is smaller than the previous
ones, because after every re-establishment, the counters will be re-counted from zero in
SCTP layer. Then the problem happens when IUQSTA does the minus operation.
4. How the fault has been corrected in this implementation?
The current correction will lose the statistics data collected before switchover. The
correction has two parts: (1) In IUQSTA, if the current values are smaller than the previous
counters, without doing the minus operation, the current values will be directly used; (2) In
IUZOCK, before collecting counters from SCTP layer, set all up association counter status
to be down first, in order to avoid possible wrong collection after several signaling unit
switchovers.
5. How to recover from the fault without this correction?
Signaling unit (e.g. BCSU, BCXU) restart.

2.30 ETPA sudden increment of call handling


Problem report: NA05381267, NA05400424, NA05437728
Exists in: S15
Correction Target: S16.1 0.0.0, S15 MP7.0
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 26

Severity: A - Critical
Customer Impact:
1. Description of the fault
ETPA restarted by recovery system due to no ACK for unit alive supervision message.
2. How to observe the fault from the real network?
Use ZAHO/ZHAP to interrogate alarm information, there will be 1010 alarm reported by
RUMMAN for ETPA unit.
3. What triggers the fault to be active?
IMIUDP is responsible for send out/ receive messages between BCSU and ETP unit. The
unit alive supervision message has no ack because the message is dropped in IMIUDP.
The hand process of IMIUDP isn't refreshed on time when it needs to be refreshed, so the
hand stops working.
4. How the fault has been corrected in this implementation?
Refresh the hand immediately when master process receives TIME_QUOTA.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.31 MCMU-0 not able to recover from TE-EX state, After Power Reset of Box-0
Problem report: NA05412381
Exists in: MCS15 REL1
Correction Target: S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
Power reset the first BOX (BOX-1), MCMU or BCXU units within it cannot recover to
normal state.
2. How to observe the fault from the real network?
Power off the first BOX and wait for at least 15 seconds, then power on it.
Wait for about 20min to check states of all units.
3. What triggers the fault to be active?
MCMU-0 didn't recover because its diagnostics failed which was occurred due to HWILIB
exception. BCXU units didn't recover also because their diagnostics failed which were
occurred by DISSYS which took place of DIKTAT to send a message to DGTPRO.
4. How the fault has been corrected in this implementation?
HWILIB returns an error value instead of exception if it is not initialized. If PIU type is BJCA, DISSYS doesn't send the message to DGTPRO.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 27

2.32 BCSU switchover stops BCCH reconfiguration


Problem report: NA05409753
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault
BCSU switchover stops BCCH reconfiguration.
2. How to observe the fault from the real network?
After BCSU switchover, TRX stays in BL-RST state.
3. What triggers the fault to be active?
BCSU switchover when BCCH reconfiguration is ongoing. BCCH reconfiguration happens
e.g. when BCCH TRX is locked and the BCCH channel is moved from locked TRX to
another (WO) TRX under the BTS.
4. How the fault has been corrected in this implementation?
If BCSU restart/switchover occurs during TRX fault/fault cancel recovery scenario in case
of BB/AH hopping and scenario is interrupted and due to that TRX is left to BL-RST state,
then GUPDAT shall change TRX operating state to BL-RSL and set alarm 7705 as
currently in case of non BB/AH hopping BTS.
5. How to recover from the fault without this correction?
BCSU switchover.

2.33 After MP1 installation BCXU goes to TE


Problem report: NA05401685, NA05389712
Exists in: S16
Correction Target: S16 PP0.1.3, S16.1 0.0.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
After S16 eSW GA18 Software Upgrade the INTEL CARD (BJC-A) Units are falling down
during normal operation.
2. How to observe the fault from the real network?
The functional units are falling down.
3. What triggers the fault to be active?
Small glitches towards the BJC-A card.
4. How the fault has been corrected in this implementation?
Our vendor implemented a more fault tolerant CPLD (GA19.4 supports both A1A and A2A
versions) and MMC version which suppose to provide protection against the small
Glitches.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 28

5. How to recover from the fault without this correction?


The unit restarts itself and boots up automatically.
If the unit stucks in RP1 state, the unit have to be Deactivate/Activate on LMP.

2.34 Wrong MAIO ( =0) broadcasted by BTS after reprinting


Problem report: NA05365260
Exists in: MCS15 REL1
Correction Target: mcT1 PP0.0-2, S16.1 0.0.0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault
Wrong MAIO (=0) broadcasted by BTS after reprinting.
2. How to observe the fault from the real network?
Wrong MAIO (=0) broadcasted by BTS after reprinting caused TCH assignment &
handover success rate deterioration.
3. What triggers the fault to be active?
RNW unblocking via FBPP
Details:
For some BCFs GUPDAT is not sending abi_trx_modify_s to ABI hence ABI is using
wrong maio value. For the problematic BCFs,when GUPDAT receives
deblock_plan_obj_s for BTS/TRX unlock,GUPDAT adds TRXs to RF hopping but ABIPRB
will not be updated since corresponding BCF is in locked state. Later as part of BCF reset
also GUPDAT is not updating ABIPRB since radio_tsl.maio value is not equal to NOT
USED(already updated with some value as part of BTS/TRX unlock).
4. How the fault has been corrected in this implementation?
When GUPDAT adds TRXs to RF hopping after deblock_plan_obj_s, then GUP send
abi_trx_modify_s message to ABIPRB.
5. How to recover from the fault without this correction?
Disable and Enable RF hopping.

2.35 BSC spontaneous restart


Problem report: NA05353231, NA05344351, NA05258276
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.1.0, mcS15 PP0.0-4
Severity: A - Critical
Customer Impact:
1. Description of the fault
BSC spontaneous restart.
2. How to observe the fault from the real network?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 29

Try executing the command ZEEL continuously with a macro and try fallback copy or
BCSU switchover.
3. What triggers the fault to be active?
Try executing the command ZEEL continuously.
4. How the fault has been corrected in this implementation?
WO check SP state, if SP is in fatal state, WO will not forward the request to SP.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.36 DX ERROR: 10203 OBJECT DOES NOT EXIST


Problem report: NA05334589, 37401ESPE06, 87888ESPE01, NA05404702
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: B - Major
Customer Impact:
1. Description of the fault
BVCI BL-SY in many segments when GPRS is enabled on large RNW using FBPP.
2. How to observe the fault from the real network?
When trying to enable GPRS in many segment.
3. What triggers the fault to be active?
When trying to enable GPRS in a segment with a PCU which is part of a pool.

4. How the fault has been corrected in this implementation?


Two issues corrected in MRF
1) If GBA ack is delayed, MRF might receive a wrong ack and wrongly assume BVC
creation as success and enable GPRS. To avoid this, MRF should compare the incoming
BTS id with the original BTS id and wait until the correct ack is received or timer expires.
2) When enabling or disabling GPRS in a segment, MRF is not sending cell_conf_data_s
to all PCU2/PCUM in the PSEI. Now code corrected and cell_conf_data_s is sending to all
PCUs in the pool during GPRS enabling/disabling operation.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.37 Inconsistent data in radio resource, TCHDs IN BL-SYS


Problem report: NA05353763
Exists in: MCS15 REL1
Correction Target: mcS15 PP0.0-4, S16.1 0.1.0, S15 MP6.0
Severity: A - Critical
Customer Impact:
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 30

1. Description of the fault


RRM raises 7737 and 7725 alarms which cause degradation in KPIs.
2. How to observe the fault from the real network?
Check Alarm history for 7737 and 7725 alarms.
3. What triggers the fault to be active?
During external HO AoIP request, if HR codec is not available with FR preferred channel
rate and if the call is queued, while allocating the queued call after HR call release then
HR channel is allocated without valid chosen codec. This causes BTS to send Channel
activation NACK causing 7725 to be raised. When 7725 is raised, RRM doesn't handle the
status of SUB Channel correctly. This causes 7737 alarm.
4. How the fault has been corrected in this implementation?
Allocation from Queue is made with FR/HR codec only if there is a valid FR/HR codec in
Queue file.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.38 2G Extended Cell Issue


Problem report: NA05350724
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
2G Extended Cell Issue,
2. How to observe the fault from the real network?
In extended cell configuration, a call in normal area gets handed over immediately after
the call is established.
3. What triggers the fault to be active?
With the introduction of super extended cell feature, low distance HO is always enabled
and for calls in normal area with TA value close to zero, handover triggers immediately
after the call is established.
4. How the fault has been corrected in this implementation?
Code modified to enable low distance HO only when the call is in extended or super
extended area.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.39 PCUMs in configuring state after PCUMs switchover

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 31

Problem report: NA05384519, 94145ESPE01


Exists in: MCS15 REL1
Correction Target: S16.1 0.1.0, S15 MP7.0
Severity: B - Major
Customer Impact:
1. Description of the fault
PCUMs stayed in CONFIGURING state after switchover.
2. How to observe the fault from the real network?
After switchover, ZFXL command will display the PCUMs state as CONFIGURING instead
of WORKING.
3. What triggers the fault to be active?
In controlled BCXU switchover restarting spare BCSU will be sending PCU restarted
notification message to RC0 before new working BCXU sends BCSU switchover
completed notification message to RC0. This caused the problem. ,
4. How the fault has been corrected in this implementation?
Added code to "send bcsu_switchover_completed_s" message from new working BCXU
before "bcsu_pcu_restarted_s" message.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.40 DTRX automatic power down - After system hot restart, DTRX power up is not
happening correctly.
Problem report: 32480ESPE07
Exists in: S14
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
DTRX power up is not happening as expected after the system hot restart.
2. How to observe the fault from the real network?
When RNW is in BL-PWS state, system hot restart triggers.
3. What triggers the fault to be active?
After the system hot restart RRM will lose the information about the TRX which are in BLPWS state, so power up will not be triggered.
4. How the fault has been corrected in this implementation?
After the system hot restart RNW recovery program block will check the TRX state. If the
op_state is BL-PWS then RRM will informed about this blocked TRX.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 32

2.41 The load of BSCU unit is too high with nominal CS-traffic
Problem report: 118845ESPE02
Exists in: S16
Correction Target: S16.1 0.1.0
Severity: C - Minor
Customer Impact: Capacity & Performance
1. Description of the fault?
CPU load in BCSU is above the design target (60%) with nominal CS traffic load. CPU
load in BCSU has increased from the previous release.
2. How to observe the fault from the real network?
CPU loads can be checked during high traffic load using service terminal.
3. What triggers the fault to be active?
High CS traffic load.
4. How the fault has been corrected in this implementation?
Optimization of BSC application is studied, especially handling of BTS measurement
reports. Reasons for increased load of the IP stack are studied.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.42 ETPE unit automatic recovery


Problem report: NA05346507, NA05327275
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.1.0
Severity: B - Major
Customer Impact:
1. Description of the fault
Due to corruption in CS Call State database, DSPs get invalid state data and misbehave.
2. How to observe the fault from the real network?
In the output of ZAHO, Alarm 2794 will be seen with cause 8001.
3. What triggers the fault to be active?
The data structure containing call state variable which is used for indexing was overwritten
by some other process. So while accessing the structure, an invalid function (via function
pointer) outside the code area was called and hence software misbehaved.
4. How the fault has been corrected in this implementation?
Call state validation has been added before accessing the state machine.
5. How to recover from the fault without this correction?
ETP card restarts automatically due to recovery process.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 33

2.43 ETP restart needed after TCSU creation


Problem report: NA05381332
Exists in: MCT1
Correction Target: S16.1 3.5-0 main package
Severity: B - Major
Customer Impact:
1. Description of the fault
After adding new TCSU in CBSC mcETPC restart needed. Without restart of mcETPC call
establishment on the newly added TCSU is not possible.
(CBSC = Client BSC, BSC using mcTC transcoding services, but without mcTC O&M
link).
2. How to observe the fault from the real network?
This problem can be observed after creating new TCSU in CBSC. The CSD call will not be
established on the newly added TCSU.
3. What triggers the fault to be active?
Calls will not be established on newly added TCSU on CBSC.
4. How the fault has been corrected in this implementation?
Fault was introduced because of code changes done in last corrections. So code has
been modified to work it properly.
5. How to recover from the fault without this correction?
There are two ways you can recover from the fault:
1. Reconfigure the new TCSU and commit the changes second time.
2. Restart the mcETPC card but in that case running calls will be getting dropped.

2.44 Wrong output in ZESI command


Problem report: 39538ESPE07
Exists in: S16
Correction Target: S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
Unexpected printout when user tries to display DAPs present.
2. How to observe the fault from the real network?
Execute command ZESI:ID=:;,,
3. What triggers the fault to be active?
The command ZESI:ID=::; gives the output as "TOTAL OF 0 DYNAMIC ABIS POOLS
PRINTED" even though DAPs are present.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 34

4. How the fault has been corrected in this implementation?


The procedure i_execute is modified such that the display is taken care even when the ID
value is not given by the user. If the ID value is not mentioned by the user, then
appropriate values are assigned and the display is shown in expected way.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.45 TFO interoperability enhancements


Problem report: 107512ESPE04
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact: User Plane Quality
1. Description of the fault
Occasional problems in AMR-WB TFO establishment in interoperability testing.
2. How to observe the fault from the real network?
In call traces taken from A interface, there has been noticed, that TFOACK is sometimes
missing from in-band message change.
3. What triggers the fault to be active?
In interoperability testing it was noticed, that TCSM3i does not always send TFOACK
embedded message in TFO negotiation. Lack of TFOACK message was considered to be
the root cause to more serious problems in other vendor's TFO implementation (to not
acknowledge a generic configuration frame) and hence cause the fail of TFO negotiation.
4. How the fault has been corrected in this implementation?
In TFO specification (3GPP 28.062) there is a change in TFO state machine: sending of
one additional TFOACK message has been added to 'wait rate control' state (event 32).
This change of specification was now implemented in TCSM3i. Additionally some other
minor changes were made to TFO state machine implementation according to the
specification 28.062 version 8.0.0.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.46 CS call establishment fails due rc0_fail_oper_ind_s with cause


call_id_alr_allocated_c
Problem report: 125990ESPE02
Exists in: MCS15 REL1
Correction Target: S16.1 0.1.0
Severity: B - Major
Customer Impact:
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 35

1. Description of the fault


CS call establishment fails due "rc0_fail_oper_ind_s" with cause "call_id_alr_allocated_c".
2. How to observe the fault from the real network?
After BCXU restart when a new call is made it fails with the "rc0_fail_oper_ind_s" with
cause "call id already allocated".
3. What triggers the fault to be active?
During bcxu restart, clearing of ETME related calls is not properly implemented. As a
results call id is not cleared from the table during bcxu restart, this triggers the fault to be
active.
4. How the fault has been corrected in this implementation?
During bcxu restart, the clearing of ETME related calls where done on the correct index.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.47 Warning LAPD MSG Distribution Problem


Problem report: NA05389958, 94798ESPE01, NA05378127
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
1583 LAPD MSG DISTRIBUTION PROBLEM alarms observed.
2. How to observe the fault from the real network?
1583 LAPD MSG DISTRIBUTION PROBLEM alarms would be seen high in number. This
alarm is raised when ABRLIB does not have address for incoming messages.
3. What triggers the fault to be active?
ABI or AOM hand address information is removed from ABRLIB in TRXSIG or OMUSIG
deletion and after that there is still messages coming in uplink direction on the link. In this
case wrong messages are coming to ABRLIB which does not have any link address to
forward that message.
4. How the fault has been corrected in this implementation?
The threshold limit for messages coming from the TRXSIG or OMUSIG during one minute
is doubled from 9 to 18.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.48 Incessant self-moving restarts and switchover of PCUMs


Problem report: NA05373803
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 36

Exists in: MCS15 REL1


Correction Target: S16.1 0.0.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
mcBSC: PCUM goes to faulty state when synch loss is seen.
2. How to observe the fault from the real network?
"1010 NO RESPONSE TO UNIT SUPERVISION MESSAGE" observed.
3. What triggers the fault to be active?
PCUM failure occurred during GENA=N/Y.
4. How the fault has been corrected in this implementation?
Fault has been corrected by modified handling of GENA=Y.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.49 No CS traffic after BSC restart


Problem report: NA05371906
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.0.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
BCSU restart led to outage and CS traffic reduced.
2. How to observe the fault from the real network?
Call establishment is not happening. Issue occurs only when MCMU is loaded.
3. What triggers the fault to be active?
DB reads in ABI is failing which is leading to supervision disturbance in ABI.BCSU get
restarted. ABI was waiting response to db reads or did not get enough running time
because some other process in the BCSU was using the time or did not handled all
excessive messages during its start up loop.
4. How the fault has been corrected in this implementation?
Messages pcu_imsi_entry_ind_s, pcu_imsi_entry_upd_s, bsc_data_indication_s,
bsc_data_request_ack_s, bsc_omu_indication_s and abi_aom_link_req_s added to read
away from message queue during startup loop.
5. How to recover from the fault without this correction?
There is no workaround or recovery without this correction.

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 37

2.50 Active MCMU load is 100%


Problem report: NA05366741
Exists in: S15
Correction Target: S15 MP6.0, S16.1 3.5-0 main package
Severity: A - Critical
Customer Impact:
1. Description of the fault
MCMU overload caused by GUPDAT (1B5) observed.
2. How to observe the fault from the real network?
Active MCMU load is 100% and also stack dump log is written.
3. What triggers the fault to be active?
BCSU restart and mean time abi_send_sys_info_s messages are sent.
4. How the fault has been corrected in this implementation?
When slave is active and GUP receives abi_send_sys_infos_s, then GUP was calling
procedure search_slave_tbl, in some case even if the status is TRUE, GUP was not filling
the slave_pid. GUPPRB has been modified in such a way that when slave status is TRUE,
in that case GUP is filling the slave_pid also.
5. How to recover from the fault without this correction?
There is no workaround or recovery without this correction.

2.51 Some TCSMs are missing in "BSC TCSM Profile (523)" RS report
Problem report: NA05358854, A05351941
Exists in: S15
Correction Target: S16.1 0.0.0, S15 MP7.0
Severity: B - Major
Customer Impact:
1. Description of the fault
Some TCSM's do not report ET downtime statistics to BSC upon request.
2. How to observe the fault from the real network?
Some TCSM are missing from "BSC TCSM Profile (523)" RS report.
3. What triggers the fault to be active?
TCSM does not handle ET downtime statistics messages from BSC as it should.
Depending on the TCSM index the statistics may be given correctly or not at all.
4. How the fault has been corrected in this implementation?
Fixed ET downtime statistics message handling.
5. How to recover from the fault without this correction?
Local interface can be used to inquire statistics for individual PCM's in an ET16.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 38

2.52 Unable to delete Semi-permanent connection


Problem report: NA05358037
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.0.0
Severity: B - Major
Customer Impact: Operation & Maintenance
1. Description of the fault
Deletion of semi permanent broadband connection fails.
2. How to observe the fault from the real network?
RBP MML-command execution fails with error:
/*** SEMANTIC ERROR ***/
/*** BROADBAND IS NOT ALLOWED FOR CIRCUIT ***/,,
3. What triggers the fault to be active?
There was unnecessary semantic check in RBP-command.
4. How the fault has been corrected in this implementation?
Fixed erroneous semantic check.
5. How to recover from the fault without this correction?
There is no workaround or recovery without this correction.

2.53 BSC Restart after unexpected MCMU switchover


Problem report: NA05351798
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact: Stability
1. Description of the fault
BSC Restart after unexpected MCMU switchover.
2. How to observe the fault from the real network?
After MCMU SWO or system restart check alarm output (ZAHP/ZAHO),
alarm 1022 PROGRAM BLOCK WARMUP FAILURE from RC0(14F) can be observed
and Spare MCMU will not come to SP-EX state, it will stuck in SP-UP state
and will go to TE-EX state.
3. What triggers the fault to be active?
Message saved in the working MCMU's save list will not allow the SWO.
Hence SP MCMU will go to TE-EX state.
4. How the fault has been corrected in this implementation?
RC0 is enhanced so that if message is saved in the save list of MCMU
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 39

that will be handled and warm up failure will not happen due to message in the save list.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.54 mcBSC: RRM prints Failure: Illegal WB AMR call amount after every FA call with
WB-AMR codec
Problem report: 93982ESPE04
Exists in: MCS15 REL1
Correction Target: S16.1 0.0.0
Severity: C - Minor
Customer Impact:
1. Description of the fault
RRM prints Illegal WB AMR call amount log writing in MCMU computer log after every
FACCH call with WB-AMR codec.
2. How to observe the fault from the real network?
RRM log writing can be seen in MCMU computer log after FACCH call with WB-AMR
codec.
3. What triggers the fault to be active?
RRM internal number of WB-AMR calls is not incremented when FACCH call is made with
WB-AMR codec.
4. How the fault has been corrected in this implementation?
RRM internal number of WB-AMR calls is incremented during a FACCH setup.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.55 Segments do not get PSE's average PS load value during E/GPRS enabling in
empty PCUs
Problem report: 69469ESPE03
Exists in: S16
Correction Target: S16.1 3.5-0 main package
Severity: C - Minor
Customer Impact:
1. Description of the fault
Segments do not get PSE's average PS load value during GPRS enabling.
2. How to observe the fault from the real network?
Segments should get PSE-1's average PS load value during GPRS enabling.
3. What triggers the fault to be active?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 40

Segments 305-308 do not get PSE-1's average PS load value during GPRS enabling
where as segments 301-308 have the same configuration.
4. How the fault has been corrected in this implementation?
Measurement average load and Peak average load was not calculated properly for the
segment while enabling GENA.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.56 HO SR counters show 100% values


Problem report: NA05405202, NA05405431
Exists in: S16
Correction Target: S16 PP0.1.2, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
Incorrect counter updating for cells. BSC_O_SUCC_HO (counter table p_nbsc_ho) and
BSC_O_HO_CMD_ASSG (p_nbsc_traffic) aggregated on SEGMENT LEVEL do not
correspond well to each other. The number of BSC_O_SUCC_HO (successful HOs) is
very often higher than BSC_O_HO_CMD_ASSG (HO attempts).
2. How to observe the fault from the real network?
Measurement files and KPI reports for success rate are showing more than 100% and
measurement files shows 0 values for counters SDCCH_ASSIGN 057021 and
T3101_EXPIRED 057020.
3. What triggers the fault to be active?
BCXU switchover caused the measurements change to "locked " state by ABI. So
counters from locked measurements are not collected at all.
4. How the fault has been corrected in this implementation?
Measurements states are kept during BCXU switchovers.
5. How to recover from the fault without this correction
There is no workaround or recovery without this correction.

2.57 SCF upload to Net Act failed after S15 MP5.0 implementation
Problem report: NA05386464, 124108ESPE02, NA05345135
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 41

BTS/SCF upload failed after S15 MP4.0 installation when the entire BSC was selected for
the operation. Note that this operation was done via Net ACT.
2. How to observe the fault from the real network?
The following error from feedback file indicated so:
PLMN-PLMN/BSC-714630 Kiprusoff
SCF upload failed
GET_BCF_IDS_R FAILED
06/03/13 12:32:51: Error, Also the returned value was -1 in the error log i.e.:
CALLER : 06B2 0000 00 RETURN ADDRESS: 0940 (G0296).000009F2
WRITE TIME: 2013-03-05 12:33:34.25
PARAMETERS: E-08 0938.0000002B 00000002 0938.00000004
USER TEXT : FBUMAS: Fastread get_bcf_ids_r failed:
USER DATA : -1,
3. What triggers the fault to be active?
The return value of the status when successful for the internal procedure 'get_bcf_list__r'
was missing in the code.
4. How the fault has been corrected in this implementation?
Fault has been corrected by adding the return value of the status when successful for the
internal procedure 'get_bcf_list__r'.
5. How to recover from the fault without this correction?
There is no workaround or recovery without this correction.

2.58 bts resource data error -log writings occurs in spare MCMU
Problem report: 69187ESPE03
Exists in: S16
Correction Target: S15 MP6.0, S16.1 0.1.0
Severity: C - Minor
Customer Impact:
1. Description of the fault?
BSC runs data structure restoring procedure in spare MCMU and writes the logs writings.
2. How to observe the fault from the real network?
There are following log writings in spare MCMU:

USER TEXT : C66:bts resource data error, message no:


USER DATA : DF57 0000

USER TEXT : 6: bts resource data error


USER DATA : A5 01 06 01 42,,
3. What triggers the fault to be active?
When DFCA feature is active, the spare MCMU updating is sometimes not done correctly.
This is noticed in spare MCMU and data structures are restored.
4. How the fault has been corrected in this implementation?
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 42

Implementation done to update DFCA counts to SP unit after the downgrade of planned
GP TSLs.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.59 MCMU switchover is not possible


Problem report: NA05392647
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: A - Critical
Customer Impact: Operation & Maintenance
1. Description of the fault
MCMU switchover is not possible. During MCMU switchover Program Block Warm-up
failure alarm is triggered from both GALARM and BTLARM.
2. How to observe the fault from the real network?
MCMU switchover cannot be performed. Spare MCMU does not stay in SP-EX.
3. What triggers the fault to be active?
BCSU switchover followed by MCMU switchover.
4. How the fault has been corrected in this implementation?
Basic Root cause:
BTLARM slave table is corrupted at the time of BCSU restart/switchover.
BTLARM tries to free BCSU slave and checks BCF ID list.
Due to corrupted data in slave table, BTLARM sends invalid BCD ID to GALARM resulting
in GAL exception.
When messages flood GALARM, GAL is not able to respond to USAPRO supervision
message and thus restarted. Correction Detail
------------------Explicit handling of exception done in BTLARM.
When BCF ID is 0 or FFFF, BTLARM does not send gal_repeat_alarm_s to GALARM.
BCF nack list is initialized and BCSU specific operation is ended normally.
5. How to recover from the fault without this correction?
Restart GAL and BTLARM in both active and spare unit.

2.60 BTS MO upload from Net Act is getting failed for Flexi compact BTS
Problem report: 39355ESPE07, 71778ESPE03
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: B - Major
Customer Impact:
1. Description of the fault
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 43

FLEXI MR10 upload fails with the feedback: "BTS SOFTWARE DOES NOT SUPPORT
FLEXI BTS AUTOCONNECTION FEATURE".
2. How to observe the fault from the real network?
Via MML/Net act, perform a SCF Upload for FlexiMultiradio10/Flexi Compact site subtype
which is in WO state. The operation will fail with the below mentioned error in the
feedback file:
BTS SOFTWARE DOES NOT SUPPORT FLEXI BTS AUTOCONNECTION FEATURE"
,
3. What triggers the fault to be active?
Legacy code doesn't have support for FlexiMultiradio10/Flexi Compact site subtype.
4. How the fault has been corrected in this implementation?
Fault has been corrected by adding the support for
FlexiMultiradio10 and Flexi Compact site subtypes in
'bts_level_info_inq_ack_s'. Note that there is no SW
version checks required for these site subtypes.
5. How to recover from the fault without this correction?
Just perform SCF Upload for any other site type like Flexi Edge/ FlexiMultiradio with its
corresponding version and release checks.

2.61 BSC send disconnect after BTS require handover


Problem report: 37167ESPE07
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.1.0
Severity: B - Major
Customer Impact:
1. Description of the fault
BSC send disconnect after BTS require handover.
2. How to observe the fault from the real network?
Disconnect bus cable between ESMA and DTRX.
3. What triggers the fault to be active?
Disconnect bus cable between ESMA and DTRX.
4. How the fault has been corrected in this implementation?
GUP shall send block request to ABI after 3 sec. Now it is 1.7 sec. So that ABI can
complete the action within 3 sec.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.62 One BVCI out of working BVCIs is not coming to WO-EX state randomly
Problem report: 99659ESPE04
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 44

Exists in: S16


Correction Target: S16.1 0.1.0, S15 MP6.0
Severity: C - Minor
Customer Impact:
1. Description of the fault
mcBSC has 9 working BVCI's.
After this site connections to router is lost for a while and connected back. This lead to a
situation where one BVCI out of 9 is not coming in WO-EX state. One BVCI is in
UNBLOCKED state,
2. How to observe the fault from the real network?
In a configuration where there is Multipoint Gb configuration and PCU pooling, when site
connections to router are lost for a while and connected back, the fault occurs randomly.
Occasionally, not all BVCI corresponding to an NSEI will come to working state.
3. What triggers the fault to be active?
This is because of a legacy design issue in GBADMI code in MPGb+PCP scenario
handling. There is an internal structure (g_reset_width) in GBA PCU hand which can hold
only one NSEI at a time and the content of the structure is used in deciding whether PTP
BVC reset needs to be done for an NSEI after signaling BVC reset is completed. In
MPGb+PCP scenarios this structure will contain only one NSEI at a time in a particular
GBA hand. Same GBA PCU hand should handle the operations related to multiple NSEs
and the NSE in this table gets overwritten. As a result PTP BVC will not be reset after SIG
BVC reset for some of the NSEs when MPGb+PCP is configured.
4. How the fault has been corrected in this implementation?
Corrected GBA code such that internal structure (g_reset_width) is modified and it can
hold multiple NSEs associated with the PCU at a time. This will ensure that PTP BVC is
reset for all NSEs of a PCU after Gb break scenarios.
5. How to recover from the fault without this correction?
PSEI reset will resolve the issue.

2.63 MP 6.0 Pilot: Degraded TBF Success rate after upgrade


Problem report: NA05395532, 127618ESPE02, NA05395191
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.1.0
Severity: B - Major
Customer Impact:
1. Description of the fault?
After Package upgraded to MP6 TBF_67 KPI was degraded.
2. How to observe the fault from the real network?
From the KPI report it can be observed that TBF_67 KPI was degraded.
3. What triggers the fault to be active?
After upgrade of the MP6 package fault was always active.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 45

This is being observed from counter data that at certain measurement cycle, counters
maintained at DSP area is not updated in measurement reports. DSP was not able to
send the measurement data when requested by PQ. Due to not updating of correct
counter data from DSP, it is leading to almost zero value of tbf_67 for segments upgraded
on that DSP in some cycles. This is causing degradation in overall tbf_67 KPI.
4. How the fault has been corrected in this implementation?
It was found that due to corruption at DSP, DSP was not able to send the measurement
data.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.64 CS call setup problem during active PS session


Problem report: NA05404101, NA05409184, NA05436451
Exists in: S16
Correction Target: S16 PP0.1.6
Severity: B - Major
Customer Impact:
1. Description of the fault
In MCBSC, Paging co-ordination feature is not working together with Precise Paging
Feature.
2. How to observe the fault from the real network?
Cannot perform CS call to subscriber when subscriber has active GPRS connection.
3. What triggers the fault to be active?
Cs_paging_req_s message is not send from ABI to PCUM because the address picked
from location database is wrong, when precise paging feature is active. MCPCU address
information saved in ABIPRB's location_db_tbl was wrong.
4. How the fault has been corrected in this implementation?
The fields in the location database and paging co-ordination database changed in such a
way that PCU PID is saved in the table and the message cs_paging_req_s sent to the
saved PCU PID so that the message reaches in PCUM and paging co-ordination works.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.65 MCMU disturbance "1007 RESTARTED PROGRAM BLOCK"


Problem report: NA05391023
Exists in: MCS15 REL1
Correction Target: S16.1 0.0.0
Severity: B - Major
Customer Impact: Operation & Maintenance
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 46

1. Description of the fault


MCMU 1007 RESTARTED PROGRAM BLOCK,
2. How to observe the fault from the real network?
GAL program block restart is observed in MCMU, HIST BSC86002TF MCMU-1 SWITCH
2013-05-27 03:24:22.10
* DISTUR MCMU-1 1A002-00-1 USAPRO
(0728) 1007 RESTARTED PROGRAM BLOCK
01FF 770d ,
3. What triggers the fault to be active?
High load in Working MCMU resulting GAL PRB restart in spare unit.
7624 and 7625 alarm set and cancels before RNW initialization phase
are causing extra load to MCMU in BSC System restart.
4. How the fault has been corrected in this implementation?
7624 and 7625 alarm handling is filtered in GUPDAT during BSC restart.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.66 McBSC OMU crashed


Problem report: NA05375438, NA05355165
Exists in: MCS15 REL1
Correction Target: S16.1 3.5-0 main package, S15 MP7.0
Severity: B - Major
Customer Impact:
1. Description of the fault
O&M system connection was broken down.
2. How to observe the fault from the real network?
Not possible to monitor KPIs via O&M.
3. What triggers the fault to be active?
Exception of family 6AE process 000D7.
4. How the fault has been corrected in this implementation?
Corrected "memory_file_close_r" routine not to call "detach_common_r spin locked"which calls "write_to_log_routine" when file handle error detected. ,
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.67 Hanged GPRS in several cells - UL TBF discarded


Problem report: NA05373223
Exists in: MCS15 REL1
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 47

Correction Target: S16.1 0.0.0


Severity: A - Critical
Customer Impact:
1. Description of the fault
Hanging calls are observed after BCXU switchover.
2. How to observe the fault from the real network?
After BCXU switchover, PS calls are not resuming after switchover.
3. What triggers the fault to be active?
BCXU was not informing the completion of switchover to PCUM thus leading blocked
channel.
4. How the fault has been corrected in this implementation?
Modified the code so that ABIPRB will inform switchover completion to all PCUMs to
which it is acting as host.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

2.68 Many 1178 alarms after Enabling DTM function


Problem report: NA05370847, NA05373705
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
BCSU switchover due to alarm 1178 "PREPROCESSOR UNIT DISTURBANCE.
2. How to observe the fault from the real network?
BCSU Switchover due to alarm 1178/2770 is observed in the customer network.
3. What triggers the fault to be active?
From the provided black box it is observed that alarm 1178 PREPROCESSOR UNIT
DISTURBANCE was raised due to the watchdog bite at PCU2. An internal module at
PCU2 (i.e. CM - Component Manager) didnt got scheduled to feed the watchdog timer
resulting in the card SOFT RESET. Here the CM didn't got scheduled because the PQIII
(Power Quick) processor stuck in an infinite loop at PCU2 and this infinite loop at PCU2
originated due to corruption in one of the internal local variable while calculating the MS
TSL from the bitmap in one of the DTM scenario.
4. How the fault has been corrected in this implementation?
As part of the implementation, the reason of local variable corruption is properly handled
in a wrapper function used before all the concerned loops including the problematic loop.
5. How to recover from the fault without this correction?
Automatic BCSU switchover or PCU2 restart will recovers the problem.

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 48

2.69 MCMU reset and switchover failure causing system restart


Problem report: NA05364080, 71407ESPE03
Exists in: S15
Correction Target: S16.1 0.0.0, S15 MP6.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
In multipoint A network happened massive amount of call releasing almost the same time
due to signaling break and caused the overload situation in MCMU.
2. How to observe the fault from the real network?
After transmission break, SS7-channel system is out of use and signaling is prevented.
3. What triggers the fault to be active?
Mass clearing of calls due to BSSAP subsystem failure let to overload in MCMU.
4. How the fault has been corrected in this implementation?
A delay has been added to call releases so that all the calls will not be released at the
same time.
5. How to recover from the fault without this correction?
There is no workaround or recovery without this correction.

2.70 BCSU doesn't switchover when AS7-D card is faulty


Problem report: NA05363281
Exists in: S15
Correction Target: S15 MP6.0, mcS15 PP0.0-5, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
BCSU switchovers and/or MCMU Abnormal switchovers causing System Restart.
2. How to observe the fault from the real network?
Alarms 1071 "PROCESSOR TIME SHORTAGE" from SC7 (1B1) PRB and 1023
"EXCESSIVE DISTURBANCES IN SUPERVISION" are observed.
3. What triggers the fault to be active?
Transmission fluctuation in A -interface caused ET to down due to which circuits also goes
down. Hence SC7 receives lots of blocking message that triggered the fault to be active.
4. How the fault has been corrected in this implementation?
The fault was corrected in the platform routine FISLIB. The routine was optimized in order
to occupy less CPU load.
5. How to recover from the fault without this correction?
The fault cannot be recovered without this correction.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 49

2.71 Processor time shortage alarm from SC7 (1B1)


Problem report: NA05359621, NA05358275, NA05360197
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.0.0
Severity: A - Critical
Customer Impact: Operation & Maintenance
1. Description of the fault
BCSU switchovers and/or MCMU Abnormal switchovers causing System Restart.
2. How to observe the fault from the real network?
Alarms 1071 "PROCESSOR TIME SHORTAGE" from SC7 (1B1) PRB and 1023
"EXCESSIVE DISTURBANCES IN SUPERVISION" are observed.
3. What triggers the fault to be active?
Transmission fluctuation in A -interface caused ET to down due to which circuits also goes
down. Hence SC7 receives lots of blocking message that triggered the fault to be active.
4. How the fault has been corrected in this implementation?
The fault was corrected in the platform routine FISLIB. The routine was optimized in order
to occupy less CPU load.
5. How to recover from the fault without this correction?
The fault cannot be recovered without this correction.

2.72 BVCI in blocked state for segments with static NSEI


Problem report: NA05353021
Exists in: S15
Correction Target: S15 MP6.0, S16.1 0.0.0
Severity: A - Critical
Customer Impact:
1. Description of the fault
After router restart (transmission break), it is found that BVCI is down in most of the
segments connected to PCU having static NSE.
2. How to observe the fault from the real network?
After transmission break whole NSEI doesnt handle PS traffic. Alarms 3030 "BSSGP
VIRTUAL CONNECTION BLOCK PROCEDURE FAILED" and 3031 "BSSGP VIRTUAL
CONNECTION RESET PROCEDURE FAILED" are noticed. BVCI OPERATIONAL
STATE for SEG connected to this NSEI is in BL_SY state.
3. What triggers the fault to be active?
After Gb fluctuation, in certain cases, GBADMI was asking PCUs to start BVCI unblocking
a bit early, before the PCUs have completed SIG BVC RESET.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 50

There was another situation where GBADMI was not allowing SIG BVC RESET request
from PCU when the previous SIG BVC RESET was not successful.
4. How the fault has been corrected in this implementation?
Corrected GBADMI code such that there is enough time for PCU to complete the SIG
BVC reset before GBA starts unblocking the PCUs during Gb fluctuations.
Did correction in GBA code such that when one SIG BVC RESET has failed, then the next
one is allowed and also global recovery permission is granted.
5. How to recover from the fault without this correction?
BCSU switchover should solve the problem.

2.73 S15 mcBSC SA: BVCI stays in UNBLOCKED-state


Problem report: 86519ESPE01
Exists in: MCS15 REL1
Correction Target: S16.1 3.5-0
Severity: B - Major
Customer Impact: Capacity & Performance
1. Description of the fault
BVCI stays in UNBLOCKED-state.
2. How to observe the fault from the real network?
After MCMU switchover, GPRS territory upgrade process is not triggered.
3. What triggers the fault to be active?
MCMU switchover during GPRS territory guard time.
4. How the fault has been corrected in this implementation?
Timer handling of GPRS territory guard time is added to SP-MCMU.
5. How to recover from the fault without this correction?
GENA toggle.

2.74 S15 MP 4.0:"PXNETM: AS7 RESTART" After BCSU controlled switchover


Problem report: 37174ESPE06, NA05391044
Exists in: S15
Correction Target: S15 MP7.0, S16.1 0.0.0
Severity: B - Major
Customer Impact:
1. Description of the fault
Log writing "PXNETM: AS7 RESTART" seen after BCSU controlled switchover.
2. How to observe the fault from the real network? , In S15MP04 with LRNW Packet Abis
set-up, after BCSU controlled switchover the following error log is found: CALLER :
011C 0000 00 RETURN ADDRESS: 000C (L0001).00048416
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 51

WRITE TIME: 2012-10-23 10:56:29.21


PARAMETERS: E-01 0014.000004CC 00000001 000C.0004808B
USER TEXT : PXNETM: AS7 RESTART
USER DATA : 0D,
3. What triggers the fault to be active?
AS7 restart was because CCNETM got the switchover cancelled message
(re_switchover_cancelled_s). GUP dat failed the switchover as the
delay GUP registered was less.
4. How the fault has been corrected in this implementation?
Increased the time limit from 2 ms to 100 ms,
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

3. GENERIC FAULTS CLOSED


3.1 BSAC-A eSW2.5.1 sensor 'ToP Ref OEM' and 'Sync-E QLOP1 OEM alarm issue
Problem report: 97744ESPE01, 97531ESPE01, 97656ESPE01, 97754ESPE01
Exists in: BCN_MAINT
Correction Target: S16 PP1.0-3
Severity: B - Major
Customer Impact:
1. Description of the fault , these two kinds of sensors alarm wouldnt be triggered
anymore: Sync-E QLOP1 OEM 0x01 0xa8
ToP Ref OEM 0x01 0xab,
2. How to observe the fault from the real network?
3. What triggers the fault to be active?
4. How the fault has been corrected in this implementation?
5. How to recover from the fault without this correction?

3.2 BSAC-A eSW2.5.1 Sync mode (including SEC and BDG) testing failed
Problem report: 97754ESPE01, 97531ESPE01, 97744ESPE01, 97656ESPE01
Exists in: BCN_MAINT
Correction Target: S16 PP1.0-3
Severity: B - Major
Customer Impact:
1. Description of the fault

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 52

BSAC-A Sync mode including SEC and BDG function seems doesnt work in Esw2.5.1.
2. How to observe the fault from the real network?
3. What triggers the fault to be active?
4. How the fault has been corrected in this implementation?
5. How to recover from the fault without this correction?

3.3 S16 MP0.0 installation macro doesn't copy BOLEROGX image to WDUs root
Problem report: 43776ESPE05
Exists in: S16
Correction Target: S16 0.1.2, added to CD_Installation_Macros_Ver_14.zip
Severity: B - Major
Customer Impact:
1. Description of the fault
S16 MP0.0 installation macro (CD_Installation_Macros_Ver_13.zip and older) doesn't
copy BOLEROGX image to WDUs root of mcBSC. Same is missing from installation
document.
2. How to observe the fault from the real network?
After MP0.0 installation BOLEROGX is not updated in WDUs root only in BLCODE.
3. What triggers the fault to be active?
Always active when S16 MP0.0 has been installed by macro or manually.
4. How the fault has been corrected in this implementation?
Added copying of BOLEROGX to S16 macro CD_SPECIAL_S16.HIT 6.5-4 and same into
installation instructions.
5. How to recover from the fault without this correction?
Copy manually the BOLEROGX file to the disk root in mcBSC
ZIWY:S:PATH=/mcs15_root_directory/BLCODE,DRIVE=WDU-S;
ZIWY:D:PATH=/,DRIVE=WDU-SB;
ZIBC:BOLEROGX,IMG;

3.4 BJC-A is double restarted after ZUSU MML


Problem report: 99682ESPE04
Exists in: S16
Correction Target: Correction not needed, suggestion for further development
Severity: C - Minor
Customer Impact:
1. Description of the fault?
BJC-A is double restarted when card is restarted with ZUSU MML.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 53

2. How to observe the fault from the real network:


Check card boot up from minicom. It is restarted twice.
3. What triggers the fault to be active?
Execute ZUSU MML command.
4. How the fault has been corrected in this implementation:
5. How to recover from the fault without this correction:
System recovers from the situation automatically after second restart.

3.5 BVCI in unblocked state after PCUM switchover


Problem report: NA05411446, 43209ESPE05
Exists in: S16
Correction Target: S16 PP0.1-3
Severity: B - Major
Customer Impact:
1. Description of the fault
After forced BCXU switchover territory mismatch is seen.
2. How to observe the fault from the real network?
After switchover of PCUM several SEGs do not move to new PCUM. Because of that
BVCIs served by PCUM stuck in UNBLOCKED state instead of WO-EX.
3. What triggers the fault to be active?
After forced BCXU SWO, BCXU restart information is not send PCUMs correctly.

4. How the fault has been corrected in this implementation?


BCXU restart information is sent to appropriate PCUMs after forced SWO by new working
state BCXU.
5. How to recover from the fault without this correction?
Deactivate/activate GPRS in problematic cell.

3.6 Working BCXUs with faulty flags and Radio Network dropped to not available after
cut off power from MCBC0 box
Problem report: NA05422310, 72874ESPE03, 73731ESPE03
Exists in: S16
Correction Target: S16 0.1.4
Severity: A - Critical
Customer Impact:
1. Description of the fault
Alarm 1300 is reported from many units after complete command (ZWRC) during release
upgrade.
LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 54

2. How to observe the fault from the real network?


1. Operate complete command (ZWRC) during release upgrade;
2. Check alarm history by ZAHP command.
Alarm 1300 reported for the units are found in alarm history,
3. What triggers the fault to be active?
Recovery system has one mechanic that NON-SYM unit will check the connection
situation with SYM units by sending supervision messages when the unit received the
"spv_connection_lost" message with SYM units physical address.
If NON-SYM unit checks the connection situation has been broken (there are no ack
messages from any SYM units within 2s), the unit will restart it.
But SYM units are busy rather than handling the supervision message from NON-SYM
unit within 2s, the NON-SYM will restart itself.
4. How the fault has been corrected in this implementation?
Recovery system removed the mechanic for checking the connection situation.
Then, the non-unit will not restart it when receiving "spv_connection_lost" message with
sym address.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

3.7 BCSU0&5 abnormal


Problem report: NA05382905
Exists in: S15
Correction Target: S15 MP7.0
Severity: B - Major
Customer Impact:
1. Description of the fault
1178 alarm caused the BCSU switchover, after switchover, CS & PS is both abnormal in
BCSU-0,
2. How to observe the fault from the real network?
After the BCSU abnormal switchover, we didn't see the alarm 0690 point the BCSU-0 from
SP to WO, but BCSU-0 already as WO-EX state.
3. What triggers the fault to be active?
When BCSU do fault switchover, if there is no response and unit state has been changed,
RCXPRO will not send stop_updating_s. This will cause some problem in ABI area.
4. How the fault has been corrected in this implementation?
One timer added. If there is no response from USAPRO but unit state has been changed,
RCXPRO will send stop_updating_s.
5. How to recover from the fault without this correction?
There is no recovery or workaround without correction.

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 55

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.

LGF_BSC_2013_08
Copyright 2013 Nokia Solutions and Networks. All rights reserved.
CONFIDENTIAL
APPROVED 1.0

Page 56