You are on page 1of 16

Radio Controllers

CN-id: SG5_0572

Title:
Incorrect display of messages from CBC

Version of the SW-build:


S16 8.13-0

Valid for Product(s):


BSC3i1000
BSC3i2000
BSC3i660
Flexi BSC
mcBSC

References:

Reason for the Change Note:


1.Description of the fault?
There is hung CB messages in CBFILE and not in CBAFIL.

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


Broadcast CB messages from CBC when BTS is in overloaded. CB messages are
broadcasted from CBC and CBH will write CB message in CBFILE and not in CBAFIL.

Impact to End-User:
NA
Impact to Operator:
NA

3.What triggers the fault to be active?


Send Write-replace message from CBC on overloaded BTS.

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


If BTS is overloaded CB messages will not be written into CBFILE. And if some hung CB
message found in CBFILE then CB messages will be deleted periodically.

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


Clear the CBFILE and CBAFIL using below steps:

Load new CBA CBF and CBN images into LFILE directory of BSC and execute the below
commands. This will clear all the file content

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 1(3)
ZDFM:MCMU,0:NBR=7040000:I:;
ZDFM:MCMU,0:NBR=7050000:I:;
ZDFM:MCMU,0:NBR=8CE0000:I:;
ZDFM:MCMU,1:NBR=7040000:I:;
ZDFM:MCMU,1:NBR=7050000:I:;
ZDFM:MCMU,1:NBR=8CE0000:I:;

Corrected Fault Reports:


CAS-103802-D2H6

Modified components:

Component Version
CBH_BGSX 25.12-0

Testing Information:
CBH_BGSX.PAC Module Testing Done.

Change effects:

Effects on end-user

Effects on Operator

Other effects

New functionality

Customer Impact
Stability
Fault Management

Special Conditions for installation:

Testing Instructions for the change

Pre-requirements:
-

Test execution:
This correction is very difficult to be verified in the live network. The correction has been
tested internally in the Nokia internal test environments and correction is working as expected.

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 2(3)
Expected results:
-

Unexpected results:
-

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 3(3)
Radio Controllers

CN-id: SG5_0573

Title:
Zero calls in many sites

Version of the SW-build:


S16 8.13-0

Valid for Product(s):


BSC3i1000
BSC3i2000
BSC3i660
Flexi BSC
mcBSC

References:

Reason for the Change Note:


1.Description of the fault?
Zero calls in many sites

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


No calls in some sites, 7738 alarm reported.

Impact to End-User:
Call setup fails in some sites

Impact to Operator:
KPI impact

3.What triggers the fault to be active?


When CBH cell_list is corrupted CBH will send broadcast request to wrong family.

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


Before broadcasting the CB message CBH will check computer id and family id are proper. If
computer and family id are corrupted CBH will correct it by reading it from Database

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


Kill and restart CBH process.

Corrected Fault Reports:

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 1(2)
CAS-176419-N9B2

Modified components:

Component Version
CBH_BGSX 25.12-0

Testing Information:
CBH_BGSX.PAC Module Testing Done.

Change effects:

Effects on end-user

Effects on Operator

Other effects

New functionality

Customer Impact
Capacity &
PerformanceCall Setup
Success

Special Conditions for installation:

Testing Instructions for the change

Pre-requirements:
-

Test execution:
This correction is very difficult to be verified in the live network. The correction has been
tested internally in the Nokia internal test environments and correction is working as expected.

Expected results:
-

Unexpected results:
-

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 2(2)
Radio Controllers

CN-id: SG5_0575

Title:
CR0272 Improved algorithm for some of the 72 series counter update

Version of the SW-build:


S16 8.13-0

Valid for Product(s):


Flexi BSC
mcBSC

References:

Reason for the Change Note:


1. Description of the fault?
As part of the pronto PR402206, the accuracy of following counters is improved as configured
by UTPFIL parameter œUTPFIL index ADAPTIVE_INITIAL_CODING_SCHEME 218
(0xDA)•

Counter Name Counter Description


------------------------------------
72092 UL_TBF_ESTABLISHMENT_FAILED
72094 UL_EGPRS_TBF_REL_DUE_NO_RESP
72001 MAX_DUR_UL_TBF
72003 AVE_DUR_UL_TBF_SUM
72004 AVE_DUR_UL_TBF_DEN
72011 MAX_DUR_UL_TBF_UNACK_MODE
72013 AVE_DUR_UL_TBF_UNACK_MODE_SUM
72014 AVE_DUR_UL_TBF_UNACK_MODE_DEN
150004 NODE_UL_EST_FAIL_DUE_NO_RESP

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


The above mentioned counter values would have more accurate values as configured by
UTPFIL parameter œUTPFIL index ADAPTIVE_INITIAL_CODING_SCHEME 218
(0xDA)•

Impact to End-User:
No Impact

Impact to Operator:

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 1(3)
Operators have a flexibility to configure UTPFIL parameter (set to 1) in case they wish to have
a more accurate algorithm for above mentioned counters.

3.What triggers the fault to be active?


Not Applicable

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


Based on the UTPFIL parameter value, a flexibility is given to operator either to use the
existing algorithm or more accurate algorithm for above mentioned counters.
The default value UTPFIL parameter œUTPFIL index
ADAPTIVE_INITIAL_CODING_SCHEME 218 (0xDA) is ˜0™, which means the existing
counter algorithm is used.
If the value is set to ˜1™, then more accurate algorithm would be used.

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


Not Applicable.

Corrected Fault Reports:


PR402206

Modified components:

Component Version
IGWMPPQD 12.59-0
MPCUGBCB
MPCUAICB 7.56-0
MPCUGBCA
IGWMNDSD 7.56-0
ABI_BXSX
IGWMNDSE 9.56-0
IGWMPPQE
MPCUAICA 26.59-0
IGWMPDSD
IGWMPDSE 34.37-0
IGWMNPQD
IGWMNPQE 17.59-0
12.59-0
9.56-0
12.59-0
12.59-0
26.59-0
17.59-0

Testing Information:
MPCUGBCA.PAC Module Testing . Done.
MPCUAICA.PAC Module Testing . Done.
MPCUGBCB.PAC Module Testing . Done.
MPCUAICB.PAC Module Testing Done.
IGWMNDSD.PAC Module Testing Done.
IGWMNPQD.PAC Module Testing Done.
IGWMNPQE.PAC Module Testing Done.
IGWMNDSE.PAC Module Testing Done.

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 2(3)
IGWMPDSD.PAC Module Testing Done.
IGWMPDSE.PAC Module Testing Done.
IGWMPPQD.PAC Module Testing Done.
IGWMPPQE.PAC Module Testing Done.
ABI_BXSX.PAC Module Testing Done
Functional Testing : Passed

Change effects:

Effects on end-user

Effects on Operator

Other effects

New functionality

Customer Impact
New feature/functionality

Special Conditions for installation:

Testing Instructions for the change

Pre-requirements:
-

Test execution:
This correction is very difficult to be verified in the live network. The correction has been
tested internally in the Nokia internal test environments and correction is working as expected.

Expected results:
-

Unexpected results:
-

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 3(3)
Radio Controllers

CN-id: SG5_0576

Title:
ST command support for Mute call detection alarm

Version of the SW-build:


S16 8.13-0

Valid for Product(s):


Flexi BSC
mcBSC

References:

Reason for the Change Note:


1.Description of the fault?
Whenever Mute call is raised it is difficult to debug as there is no ST command

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


When packets are not received this alarm is raised in ETMA/ETPA/ETPET/ETME cards

Impact to End-User:
No impact
Impact to Operator:
ST command added to help to debug the mute calls.

3.What triggers the fault to be active?


When packets are not received or wrong BCF configuration causes the packets drop.

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


New ST command implemented to debug faster as these kind of alarms are raised on need
basis.

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


WS analysis takes time to to give the feedback to the customer.

Corrected Fault Reports:


PR403112

Modified components:

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 1(2)
Component Version
GGNETMGT 6.13-0
GGNETSES
5.11-0

Testing Information:
GGNETMGT.PAC Module Testing Done.
GGNETSES.PAC Module Testing Done.

Change effects:

Effects on end-user

Effects on Operator

Other effects

New functionality

Customer Impact
Operation & Maintenance
Operability
ST command improvement

Special Conditions for installation:

Testing Instructions for the change

Pre-requirements:
-

Test execution:
This command to be executed on mcBSC/FlexiBSC/ ASBSC varient.

Expected results:
This ST command gives the details of the latest 5 mute call instance which has happened with
details. So that the debugging will be much faster.

Unexpected results:
This ST command may not give the details of latest mute call instance.

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 2(2)
Radio Controllers

CN-id: SG5_0577

Title:
ETPA units become unstable after GSM17/GSM18 SW Upgrade

Version of the SW-build:


S16 8.13-0

Valid for Product(s):


mcBSC
Flexi BSC

References:

Reason for the Change Note:


1.Description of the fault?
The ETPAs are loosing supervision after raising alarm 3742 & 14029 alarm on Mgmt BCSU.
ETPSIG configuration seems to be fine both on BSC & SWUs. The issue has started after
GSM17 upgrades.

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


ETPA units become unstable after GSM17/GSM18 SW Upgrade.
Customer is experiencing ETPAs restarts very frequently i.e. a occurrence in a day or two.

Impact to End-User:
Existing calls on the ETPA will drop and calls will not be established for a certain duration
when ETPA is restarting.

Impact to Operator:
Overall KPI will degrade as each ETPA restart will result in call drop.

3.What triggers the fault to be active?


ETPA monitors RTP and RTCP Connections for 32 MGW IP™s simultaneously.
Call running on a MGW index grater than 32 (example 40) is getting reassigned to another
MGW due to TLA change then the ETPA has a flaw in handling the incoming call context and
lands in a crash.

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


SW improvement done to handle the reassigned call context when source MGW index is 32.
The ETPAs are stable with this correction.

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

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 1(3)
Restricting no of MGW IP addresses per ETPA to 32 will avoid the issue.
For example for ETPA-0:
ETPAB/0drtcp
------------------------------------------------------------
---- Command drtcp executed on [16/12/2018 16:31:8:795011] ----
------------------------------------------------------------
------------MGW ID#0--------------------
------------MGW ID#29--------------------

Corrected Fault Reports:


CAS-150364-M8X5
CAS-156636-C6B9

Modified components:

Component Version
GGNABSES 4.17-0
GGNAAMGT
METAMGTA 5.18-0
METAMGTB
GGNAASES 9.22-0
GGNABMGT
METAUPCB 7.23-0
METAUPCA
4.18-0
5.17-0
7.22-0
9.20-0

Testing Information:
METAMGTA.PAC Module Testing Done.
METAMGTB.PAC Module Testing Done.
METAUPCA.PAC Module Testing Done.
METAUPCB.PAC Module Testing Done.
GGNAAMGT.PAC Module Testing Done.
GGNAASES.PAC Module Testing Done.
GGNABMGT.PAC Module Testing Done.
GGNABSES.PAC Module Testing Done.
Functional Testing : Passed.

Change effects:

Effects on end-user

Effects on Operator

Other effects

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 2(3)
New functionality

Customer Impact
Stability
Unit restart

Special Conditions for installation:

Testing Instructions for the change

Pre-requirements:
-

Test execution:
This correction is very difficult to be verified in the live network. The correction has been
tested internally in the Nokia internal test environments and correction is working as expected.

Expected results:
-

Unexpected results:
-

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 3(3)
Radio Controllers

CN-id: SG5_0578

Title:
Inter BSC and Inter MSC HO attempts from NetAct showing all Zero after upgrade

Version of the SW-build:


S16 8.13-0

Valid for Product(s):


Flexi BSC
mcBSC

References:

Reason for the Change Note:


1.Description of the fault?
After upgrade (to BSC18 MP2.0) ZERO HO attempts scenario was arising when Total FEP
measurement (99) is enabled.

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


Follow the Inter BSC and Inter MSC HO attempts success.

Impact to End-User:
Call Drops will be experienced by moving end user as no handover attempts are made when
Total FEP Measurement is enabled at BSC end.

Impact to Operator:
ZERO BSC outgoing and MSC outgoing handovers, leading to Handover KPI drops.

3.What triggers the fault to be active?


Upgrade the BSC from BSC17 SW to BSC18 SW keeping the Total FEP measurement (99)
enabled at BSC.

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


It was identified that the BTS MODIFY message which was indicating the change in BCCH
Allocation list (BA list) to radio controller and supervision module (RCSPRB) has the spare
field populated with INVALID value. As per the fix done for an existing BSC17 issue (CAS-
68706-C9C9) this 'spare field' was getting used for indicating a change in ADJ list of the BTS.
This mentioned fix was done in RCSPRB and MRFPRB module.
Now in current fault scenario the same 'BTS MODIFY' message is received by RCSPRB from
GUPDAT module however in such a case, the GUPDAT was not initialized the 'spare field'.
This uninitialized/invalid value of 'spare field' was not getting handled properly in RCS. One of

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 1(3)
the parameter ADJ COUNT used in creation of the frequency list would be passed as ZERO
in this negative leg and hence the INDEX list was not having any values. This results in
Handovers not getting triggered. The fix is to process the spare field at RCS end only if the
BTS MODIFY is received from MRF PRB

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


NA

Corrected Fault Reports:


CAS-190519-P5H5

Modified components:

Component Version
RCS_BXSX 30.53-0

Testing Information:
RCS_BXSX Module Testing Done.
Functional Testing : Passed.

Change effects:

Effects on end-user

Effects on Operator

Other effects

New functionality

Customer Impact
Capacity & Performance
Handover Success

Special Conditions for installation:

Testing Instructions for the change

Pre-requirements:
Enable Total Measurement at BSC

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 2(3)
Test execution:
Make Calls and then trigger handover
Wait for the collection period of total FEP measurement and then again retry step 1.

Expected results:
Handovers are successful

Unexpected results:
Handovers fails

Copyright © Nokia Solutions and Networks 2019. All rights reserved.


CONFIDENTIAL 3(3)

You might also like