2013Q4 Core Network Cases Analysis CS USC)

Core Network Product Training Technical Cases
Core Network Cases Analysis
2013
i
HUAWEI Confidential
Table of Contents
MSC Server Case.................................................................................................................... 3

Case01 CS to NGN via SIP (over UDP) call failure...........................................................3
Case02 GMSC is sending an early ACM...........................................................................5
Case03 M3UA link fault alarm appears after every 10 minutes.........................................8
Case04 Message received and send little lead to the Average Acknowledgement Delay
of M3UA signaling links increase.....................................................................................11
Case05 Half of the calls are silent between two MSCs due to CIC mismatch.................14
Case06 BICC CIC count inconsistency...........................................................................16
Case07 Wrong Correspondence between TID and CIC in Data Planning.......................18
Case08 Silence in voice channel of SIP direction caused by sending.............................20
Case09 MSC can't release call after no-answer timer expired........................................24
Case10 Call Rejection due to wrong Codec selection.....................................................27
MGW Case............................................................................................................................. 29
Case01Echo observed on PSTN Trunk Group connected with Gateway MGW due to tail
length............................................................................................................................... 29
Case02 The analysis report for silent call (after upgraded the UMG)..............................34
Case03 DSCP marking not ok on UMG after configuring PRITODSCP table.................37
Case04 call failed caused by insufficient resources. Out of ip resource..........................42
Case05 Call failure in AOIP............................................................................................. 44
Case06 How to segregate IP domains on MGWs when various offices communicating
through IP........................................................................................................................ 47
USC Cases............................................................................................................................. 50
Case1 Database Backup Failed Daily because of DMU Hard disk Space not Enough. . .50
Case2 PGW Web LMT is not working because standby module of PGW was not
configured........................................................................................................................ 54
Case3 The false connect of the fiber cable between USI3 and S3100 caused Alarm-4835
on LMT............................................................................................................................ 57
Case4 Inappropriate parameter causes slow provisioning system..................................62
Case5 Unable to connect to LTE network by using dongle due to missing APN
information from dongle................................................................................................... 64
Case6 UPCC Service Condition overlap lead to IP-CAN Session termination temporarily
........................................................................................................................................ 66
2
HUAWEI Confidential
Chapter 4 MSC Server Case
Title CS to NGN via SIP (over UDP) call failure

Keywords NGN
Case code MSC SERVER-001 Case type Signaling Problem
Case is Update
Huawei Support site 13．07．30
from Time
Product
MSC SERVER Product MSOFTX3000
Family
Case01 CS to NGN via SIP (over UDP) call failure

1. Phenomenon Description
At operator a in country A, a test call from CS to NGN is performed. After the

configuration of office data, route analysis data and number analysis data, test call is
performed. However, the call failed.
2. Alarm Information
None
3. Trace Information
CSMSS03_NGN call failed_2013-07-23-17-11-33.ptmf
CSMSS03_UserLog_2013-07-23-17-12-23.ptmf
4. Cause Analysis
1. From the MSS IP Message trace, the PING message sent to peer IP (NGN via SIP) is
reachable. The SIP signaling connection is up.
2. From the MSS User Message trace, the signaling trace of IU interface shows call
proceeding without assignment complete message follow by disconnected message.
3. From the MSS User Message trace, there is no INVITE message sent out from MSS
as well.
From step 1 to step 3, signaling to NGN, connection to IU, number analysis configuration
is normal. The error is located at route analysis table. Attached call trace for reference.
3
HUAWEI Confidential
5. Handling Process
The commands related to route analysis are: ADD OFC, ADD OFCMGW, ADD SRT,
ADD RT, ADD RTANA and ADD SIPTG.
Each command is checked and the problem is found.
In the ADD RTANA command, the Route Selection Name and Route Selection Source
Name are configured to NGN as shown in example below:
ADD RTANA: RSN="NGN", RSSN="NGN", TSN="DEFAULT", RN="to NGN",
ISUP=SIP_M;
This configuration indicates that the Route name to NGN will be only selected when both
the caller and callee are from NGN. As for the test call, the caller was from RAN and
callee from NGN. Therefore, MSoftX3000 can’t find a matching record and route analysis
failed.
Change the Route Selection Source Name to ALL. The test call is successful.
6. Suggestions and Summary
Most of the VMSC network call routing design are simple. Therefore when we configure
ADD RTANA command, we can configure the wildcard ALL in the Route Selection
Source Name (RSSN) parameter.
4
HUAWEI Confidential
Title GMSC is sending an early ACM

Keywords Early ACM
Case code MSC SERVER-002 Case type Signaling Problem
Case is Update
from Time
Product
Family
Case02 GMSC is sending an early ACM

Customer want to remove the early ACM from a call where the MSOFTX3000 work's as
GMSC. When the GMSC send's the early ACM with all parameters as "no indication" the
Pre-pay platform cannot charge this call. Because the Pre-pay platform use the ACM
message to charge the call (charge indicator at ACM message) and with all parameters
as "no indication", it will no charge one call that must be charge.
(NGN Fixed Network) -> SIP-I -> (GMSC) -> BICC -> (VMSC - Ericsson)
None
MSOFTX_UserInterface_2013-05-24-15-15-21.ptmf
4. Cause Analysis
1. GMSC send "early ACM" when receives INVITE message with IAM in the ISUP body.
5
HUAWEI Confidential
2. GMSC sent two CPG messages. The first one is when receive the ACM from VMSC
and the second is when receive the CPG message from VMSC.
The problem is that the ACM sent by GMSC go out with all parameters as "no indication"
so the Pre-pay platform cannot charge this call. Because the Pre-pay platform use the
ACM message to charge the call (charge indicator at ACM message) and with all
parameters as "no indication", it will no charge one call that must be charge.
5. Handling Process
1. Check the configuration in OFC table for the Early ACM, the GMSC must stop send
Early ACM. Change to "No" if the parameter "ISEACM" is set to "Yes".
2. Check the configuration in CNACLD table for the Early ACM, the GMSC must stop
send Early ACM. Change to "No" if the parameter "ISEACM" is set to "Yes".
6
HUAWEI Confidential
3. Check the configuration in SIPTG table of Peer Entity Type, the GMSC must stop send
Early ACM. Change the “PeerEntityType” of SIPTG to MSC, when the value is "NGN" the
GMSC also send an early ACM.
None.
7
HUAWEI Confidential
Title M3UA link fault alarm appears after every 10 minutes

Keywords Early ACM
Case code MSC SERVER-003 Case type Data Configuration Problem
Case is Update
from Time
Product
Family
Case03 M3UA link fault alarm appears after every 10 minutes

Version Information: MSOFTX3000 V100R008C03:

Networking Mode: MSC Pool with IU Flex
M3UA link between MSOFTX3000 and RNC514 fails after every 10 minutes.
In the signaling topology, RNC connect to MSX via direct M3UA link.
Alarm ID 1811: M3UA Link Fault.

This alarm appears every 10 minutes
MML_MSOFTX3000_2013-01-07-14-20-25.txt
NRBMSS04_Ping_2013-01-07-14-13-30.tmf
4. Cause Analysis
1. Check M3UA Link configuration on MSOFTX3000 side:
+++ NRBMSS1 2013-01-07 14:16:03+03:00

O&M #6000717
%%LST M3LNK: LSNM="M3LS_RNC514", LTP=LOCAL; %%
RETCODE = 0 Operation succeeded
M3UA link table

Link name WBSG module number Linkset name Local IP address1 Local IP address2 Local port
number Peer IP address1 Peer IP address2 Peer port number Client/Server mode Transfer
8
HUAWEI Confidential
model QoS flag TOS/DSCP value Whether to check quality Server name Domain name Link
number
M3LK_RNC514_00 145 M3LS_RNC514 10.15.20.2 10.15.20.10 15006

10.65.145.209 10.65.145.213 15006 Server side Economize bandwidth TOS
MIN_COST True LOCAL PUBLIC 5
M3LK_RNC514_01 147 M3LS_RNC514 10.15.20.3 10.15.20.11 15007
10.65.145.213 10.65.145.209 15007 Server side Economize bandwidth TOS
MIN_COST True LOCAL PUBLIC 5
(Number of results = 2)
--- END
The configuration seem ok.
2. Check related alarm.
No other alarm is present
3. Perform continuous ping trace to peer IP to check IP backbone quality:
From trace ping response is 100% indicating bearer network is fine.
4. Perform SCTP trace to locate SCTP layer faults:
No abnormal message at the SCTP Layer.
5. Compare M3UA link parameter with peer RNC device.
The following IP and port numbers have been configured on MSOFTX3000 and RNC
side:
MSX Side:
Local IP1 10.15.20.19 Local IP 2 10.15.20.27
Peer IP 1 10.65.80.133 Peer IP 2 10.65.80.129
RNC Side:
Local IP1 10.65.80.129 Local IP 2 10.65.80.133
Peer IP 1 10.15.20.19 Peer IP 2 10.15.20.27
It is noted that peer IP set on MSOFTX3000 does not match local IP set on RNC.
After changing the peer IP on the link, the alarm does not appear again.
5. Handling Process
If M3UA configuration adopt multi homing mode, local IP and Port should match peer
configuration.
In this case, it is obvious that the primary IP address used by the peer end in the local
configuration is different from that used by the peer end in the peer configuration. This
causes configuration asymmetry.
System normally performs periodic verification of SCTP association on each M3UA link
after every 10 minutes. When the local and peer parameters are not consistent, the
association is released, then it will try to establish the association again. This cause the
link to flap continuously.
Please refer to MSOFTX3000 Unified Maintenance Manual - SIGTRAN Volume[V3.1.0]
link attached.
9
HUAWEI Confidential
For interworking with peer devices, make sure the negotiated parameters are correctly
verified before configuration.
10
HUAWEI Confidential
Message received and send little lead to the Average Acknowledgement

Title
Delay of M3UA signaling links increase
Keywords Average Acknowledgement Delay
Case code MSC SERVER-004 Case type Link Problem
Case is Update
from Time
Product
Family
Case04 Message received and send little lead to the Average
Acknowledgement Delay of M3UA signaling links increase

The Average Acknowledgement Delay of M3UA signaling links from TWGMSS1 to

AHMSS1（basis of ATCA platform）as follows: 105 ~161ms.
The Average Acknowledgement Delay of M3UA signaling links from TWGMSS1 to
TAMSS1（basis of CPCI platform）as follows: 51~58ms.
Customer want to know why ATCA platform is longer than CPCI platform for
MSOFTX3000.
None
3. Cause Analysis
Average Acknowledgement Delay：This measurement entity measures the average

acknowledge delay of an M3UA signaling link. The measurement starts when a message
is sent on the M3UA signaling link and stops when the acknowledgement from the peer is
received.
Rule of sent Acknowledgement：
1. Acknowledgements must be sent when the signaling link will be closed or receive the
first packet；
2. An acknowledgement will be delayed when the signaling link receives one packet
within 200ms. When another packet arrives within 200ms, the 2、received endpoint must
immediately send an acknowledgement with no delay;
3. The data packets send by received endpoint will be bundled with an
acknowledgement.
11
HUAWEI Confidential
4. Handling Process
AHMSS1（ATCA）：
Analyze Counter of Traffic over M3UA Signaling Links:
The number of message received and send is more, the Average Acknowledgement
Delay was short from 02/20/2012 17:00:00 to 02/20/2012 22:00:00.
The number of message received and send is little, the Average Acknowledgement
Delay was long from 02/20/2012 06:00:00 to 02/20/2012 16:00:00.
Analyze trace information：

Average Acknowledgement Delay was short:
From above information, we can find that: the number of message received and send is
little, the Acknowledgement Delay was long for the first: 1528802682- 1528802671
=11tick =110ms, the Acknowledgement Delay was short for the second: 1528802682-
1528802679 =3tick =30ms.
TAMSS1(CPCI)：
Analyze Counter of Traffic over M3UA Signaling Links:
12
HUAWEI Confidential
From above information, we can find that: The number of message received and send is
more, the Average Acknowledgement Delay was short from 02/19/2012 17:00:00 to
02/20/2012 01:00:00. The number of message received and send is little, the Average
Acknowledgement Delay was long from 02/20/2012 02:00:00 to 02/20/2012 07:00:00.
The number of message received and send is little, the acknowledgement will be delayed
to send.
13
HUAWEI Confidential
Title Half of the calls are silent between two MSCs due to CIC mismatch
Keywords CIC silent 50% timeslot half
Case code MSC SERVER-005 Case type Link Problem
Case is Update
from Time
Product
Family
Case05 Half of the calls are silent between two MSCs due to
CIC mismatch
In a trial project, when A-party subscribers call B-party subscribers, sometimes

everything is fine, other times the conversation is OK, but A and B cannot hear each
other, and the probability of silent call is strictly 50%.
The Topology: VMSC-A----E1----- MGW- A----IP----GMSC-A----IP-----MGW-B----GMSC-B
None
3. Cause Analysis
1. The most possible reasons for voice issues:

(1) IP QoS too low;
(2) VPU Board of MGW faulty;
(3) E1 Interface faulty;
(4) CIC mismatch. For each possible reason, make tests and analysis respectively, we
can locate the root cause and solve it.
4. Handling Process
In this project, when we first met the silent call issue (the call between A and B is
connected, but neither of them can hear the other one), we made another 30 calls, the
result was 15 calls normal, 15 calls when A and B hear not each other. However, all the
calls in GMSC-B internally are fine, only calls involved GMSC-A have this problem.
Therefore, we think the problem exists at a side, and what we did is as below:
1. Made IP Bearer Auto Test (IP QoS test) which proved IP Bearer network’s quality fine
2. In MGW-A (UMG8900), disabled each of the two VPU board one by one, silent call
still happened, so VPU is not involved in this issue.
3. Made single-channel remote loop on MGW-A respectively, but silent call issue still
14
HUAWEI Confidential
happened in both situations. We thought it might be because of E1 back board (E63
board) faulty, but after we replaced with another E1 board, the issue still happens.
4. We decided to leave only one Circuit idle while block 29 of the 30 timeslots every time
by order, and we found when the idle circuit is between CIC 1 and 15, silent call didn’t
happen; when the idle circuit is between CIC 17 and 31, silent call happened. When we
activated all the 30 timeslots (CIC 1~15,CIC17~ 31),we found CIC 31’s status was
always UCIC (Unequipped CIC), which reminded us that this might be because the
VMSC of third party configured mismatched CIC. Our CIC and.
Actually our CIC and Timeslot mapping is CIC 17~31, Timeslot 17~31, and third-party
VMSC mapping is CIC 16~30, Timeslot 17~31. Once we removed the CIC 17~31 of
GMSC, silent call issue never happened again.
None.
15
HUAWEI Confidential
Title BICC CIC count inconsistency

Keywords BICC CIC inconsistency
Case is Update
from Time
Product
Family
Case06 BICC CIC count inconsistency

MSOFTX3000:V100R008C03SPH230
Customer XX reported the count of BICC CIC to be inconsistent between the two MSCs.
None
3. Cause Analysis
When the BICC circuits were displayed on module level, it was found that display of LST
and DSP was different:
DSP was showing 640 block circuits on module 35.
Module No. Office direction Idle Busy Blocking Unknown Installation
35 XX 104(13.54%) 12(1.56%) 640(83.33%) 12(1.56%) 768
While LST command was showing only 127 circuits.
Office direction name Start CIC End CIC Cic convert type Cic convert value Master
Control Server name Domain name Module Number
N-GS81-MS80 3840 3967 No Change 0 Controlling LOCAL PUBLIC 35
4. Handling Process
The problem was observed due to use of MOV TKC command and it cause circuits to
exist in double modules.
We have to manually fix it, and please follow below steps:
For current problem module 22/31/35/36/39/40
1. Use STR CRC: MN=255, CRCTYPE=DB; command to check bam database and bam
files is consistent or not, if not, please FMT
2. Use SET BAKMODE to close backup for problem module.
3. Reset standby CCU module.
4. After standby CCU module become normal, then reset active CCU module.
16
HUAWEI Confidential
5. Then use SET BAKMODE to open backup.
MOV TKC: CT=BICC; command, this command will cause CIC exist in double module for
BICC.
Suggest RMV BICCCICMDU then add it again if we want adjust CIC resource in future.
17
HUAWEI Confidential
Title Wrong Correspondence between TID and CIC in Data Planning

Keywords no audio wrong correspondence between TID and CIC
Case code MSC SERVER-007 Case type Conversation Problem
Case is Update
from Time
Product
Family
Case07 Wrong Correspondence between TID and CIC in Data
Planning
CPCI platform is adopted in a multi-area network topology at S province in C country. In

Z city, I found that no audio occurred in part of the audio service between the new
GMGW1 and VMSS of Y operator.
MSoftx3000 version: V100R007C03SPH018
UMG8900 version: V200R008C02SPH135
None
3. Cause Analysis
Generally, no audio probably results from wrong parameter concerned with CIC.
4. Handling Process
1. Checked CIC with customer manually. It seemed normal, but the problem still existed.
2. Checked configuration of optical port mode, including overhead byte, lucent mode, and
E1 load mode and so on, which were all right.
3. Made trunk test call. It’s fund that from the 4th to the last E1 of the first optical port all
had problems.
4. We doubted whether the S2L is OK or not. So we replaced the S2L, but problem still
existed.
5. We configured the service to other optical ports (service was shifted from slot 13 of
frame 1 to slot 15 of the same frame), i.e. all the changed configuration was remade
instead of using the original data planning. The problem was solved.
6. Since slot 15 is no problem, we considered slot 13 shouldn’t have problem either. So
we configured the service back to slot 13 and remade the data configuration in field. The
problem was also solved.
18
HUAWEI Confidential
7. So we back to the original data planning and checked it carefully, at last we found that
there was a wrong correspondence between CIC and TID, which is shown in red as
below.
1. The most direct way to find the problem of no audio is to make trunk test call. So we
must be familiar with this skill.
2. Data planning cannot be too careful.
3. When meet problem, do not believe original data planning blindly. Be calm and clarify
thoughts in the first instance. If it needs to check data, do it one by one patiently rather
than randomly.
19
HUAWEI Confidential
Title Silence in voice channel of SIP direction caused by sending

Keywords SIP ptime G711silnce IP
Case is Update
from Time
Product
Family
Case08 Silence in voice channel of SIP direction caused by
sending
Calling subscriber cannot hear announcement played by platform which are connected
by SIP protocol.
Purpose of Telligent platform (next in text as “platform”) is to establish a call charged by
called subscriber. Call scenario is following:
1. Calling subscriber dial number of called subscriber.
2. Serving MSC route a call to the platform.
3. The platform plays an announcement “tell me your name...hold on the line while a call
is establishing” to calling subscriber and ask to pronounce his name.
4. Then based on routing information the platform makes a call to the called subscriber.
5. Called subscriber replies and the platform plays him announcement “you are having an
incoming call from <name of the calling>. If you want to pay for this call, dial 0. If you
want to decline call, dial 1”.
6. Called subscriber choose 0 and the platform connect both subscribers with each other.
According to this flow we can divide call onto two parts: MO - originating (steps 1-3) and
MT - terminating (steps 4-6).
The problem happened when the platform connected to MSOFTX3000. Calling

subscriber dialed number of called subscriber but couldn’t hear an announcement played
by platform (look above step 2). So further we’re going to consider only MO flow.
None
20
HUAWEI Confidential
Traces.rar
ip1mrf1-2012-03-26-14-44.rar
4. Cause Analysis
Topology of network:
First of all we should check signaling.

Normal signaling call flow should be like this:
In trace we can see the same signaling message sequence. So we should check content
of signaling messages of MO flow:
1. In Invite message the MSOFTX3000 sends local SDP which contents of list of
available codec and their parameter. Ptime=20ms.
21
HUAWEI Confidential
2. The platform check intersect list of codec supported by MSOFTX3000 and own codec.
Consequently, it has chosen G.711 A law, ptime=20ms and sent it in 183 message.
3. Upon the receipt of this message, the MSOFTX3000 send MOD Req command to
UMG8900 where provides information about chosen codec and how to connect channel.
In our case it send G711Alaw and SendRecv parameter. SendRecv means that
UMG8900 should connect SIP direction and ISUP direction transparently in both ways.
According to signaling UMG8900 should transparently connect channels but why calling
subscriber cannot hear an announcement?
We should check voice on both directions: TDM and IP.
We have to set “user interface trace” with inter-module messages on MSOFTX3000.
Then set FullFlow trace on UMG8900 with following flags:
Execute MML command on UMG8900: SET RECPARA: NPRP=DSP2IP-1&IP2DSP-1,

TCRP=TXFM-1&RXFM-1&DXPCM-1, IPOFRP=BP2IPSIT-1&IP2BPSIT-1, RT=180;
After call has done, there need to download folder and their content
C:\RECFILE
C:\GET_INFO
Knowing context ID (take it from ADD_Rply message) you can find corresponded folder
in RECFILE folder: C1234567, where 1234567 is context id.
Records of TDM bearer direction are saved in file with prefix in name such as DXPCM,
22
HUAWEI Confidential
RXFM, and TXFM. These could be played in CoolEditPro or GoldWave software (Sample
rate=8000, Channels=Stereo, Resolution=8-bit, 8-bit A-law Compressed).
Records of IP bearer direction are saved in file with prefix in name such as BP2IPSIT,
IP2BPSIT. If you don’t have special software to decode these file then contact with R&D
for help.
In our case we checked IP bearer direction and could hear voice in both directions
(including announcement). Thus, we confirm that IP part is ok. Then we checked TDM
bearer direction and could hear only one-way voice from MSC to MSOFTX3000. Thus,
we concluded, that back way (from platform to calling subscriber) cannot be transcoded
on UMG8900 in correct way.
5. Handling Process
We collected RTP traffic from IP bearer by mirroring port on datacom equipment to check
if ptime is really 20ms. Filtering RTP packets for direction “Platform-> MSOFTX3000” we
found that packets are sent every 10ms but not 20ms as reported in signaling.
So, the problem is on platform which in signaling reports ptime=20ms but in fact, sends
packets every 10ms. That is why UMG8900 cannot decode voice and transfer it to TDM
properly.
To change ptime on MSOFTX3000 to 10ms there need to change configuration only on

MSOFTX3000.
MOD OFC: ON="XXX", IFADJUSTCODEC=YES, CODECPRI1=PCMA-1;
ADD CODECCFG: ON="XXX", CODECID=G.711A, PAYLOADTYPE=8, PKTIME=10.
23
HUAWEI Confidential
Title MSC can't release call after no-answer timer expired

Keywords no-answer timer, Tone ID Configuration, failure cause code
Case is Update
from Time
Product
Family
Case09 MSC can't release call after no-answer timer expired

Msoftx3000 Version: V100R009C00SPH713

When calling from other office to local subscriber (incoming call), if local subscriber didn't
answer, after no-answer timer expired which is 45sec default, MSC can’t send REL
message to release ISUP circuit.
None
MSC can't release call after no-answer timer expired.rar
4. Cause Analysis
1. Check user interface trace < MSOFTX3000_User_Message_Trace_2013-10-02-15-

30-53 noanswer.tmf >, we can see, on line 30, called subscriber didn’t answer the call
after the 45sec no-answer timer expired, then IU interface released the call on line32.
After that MSC didn’t send REL to opposite office to release the ISUP call. So it’s
definitely MSC problem
24
HUAWEI Confidential
2. After checking full flow user interface trace< MSX_User_Message_Trace_2013-10-07-

09-48-20.tmf >, on line186, RNC sent RN_CC_DISCONNECT to MSC to release IU
interface resource after no-answer timer expired. Then on line197, MSC inquired
TONECONFIG table failed. It means MSC trying to send play-tone to opposite direction
failed.
3. By running LST CAUSETONE, we can see if the released cause of call is No reply
from mobile subscriber, MSC will try to play tone of "Mobile called no-answer”.
+++ MKIBH01 2013-10-07 13:48:43+03:00 DST
O&M #374820
%%LST CAUSETONE: CAUSE=CV101; %%
Cause to Tone table
-------------------
Failure cause code = 101: No reply from mobile subscriber
Internal tone type = TID61: Mobile callee not answer tone
--- END
By running LST TONECFG, we can see there is no associated tone resource configured
on MSC side. So MSC doesn’t know what should do.
+++ MKIBH01 2013-10-07 14:02:39+03:00 DST
25
HUAWEI Confidential
O&M #374860
%%LST TONECFG: INTTID=TID61; %%
No matching result is found
--- END
5. Handling Process
Two methods can resolve this problem:

1. Run MOD CAUSETONE: CAUSE=CV101, TT=TID127; to modify the "no-answer
release tone" as inefficacy tone.
2. Run ADD TONECFG to add the tone resource for TID61.
At last, customer adopted the first method.
1. Reading about internal user trace can help for troubleshooting.

2. In this case, MSC has defect, it’s incorrect that MSC didn’t send REL to release ISUP
call if no-answer timer expired but also Tone configuration missing.
26
HUAWEI Confidential
Title Call Rejection due to wrong Codec selection

Keywords Codec
Case is Update
from Time
Product
Family
Case10 Call Rejection due to wrong Codec selection

For customer network they have 3G VMSC and 2G VMSC, and they use different Codec.
After making some configuration for 3G VMSC it was found that the incoming and
outgoing call between PSTN and 2G VMSC failed. In the trace message in Huawei
GMSC, it shows the IAM message is received from PSTN to 2G VMSC, then the call is
released.
The Huawei GMSC release the call due to "Network Out Of Order".
3. Cause Analysis
Checking the cause for release the call, from MGW it is reported the “unavailable-
27
HUAWEI Confidential
Resources” message.
The call log in MGW shows when MGW try to allocate the TC resource it is failed.
Checking the H.248 “MOD_REQ” message, Terminal ID T300020a4 was using “UMTS-
AMR” codec. This Codec set is only applicable to WCDMA calls.
Checking in the Codec Set in MGW, just one VPU board set as “WCDMA”. It means
when the traffic is high, no enough TC resource to connect the call, then the call drop.
4. Handling Process
Change the configuration for the codec priority for 3G VMSC <-->PSTN and 2G VMSC<--
>PSTN scenarios:
While 3G VMSC <-->PSTN, select AMR codec.
While 2G VMSC<-->PSTN, select G.729 codec.
When integrating new MSC which use different Codec than the current MSC, its
necessary to confirm the priority and the correct Codec needed to connect the call for
different interconnection.
28
HUAWEI Confidential
MGW Case
Echo observed on PSTN Trunk Group connected with Gateway MGW due
Title
to tail length
Keywords echo MGW Tail Length PSTN
Case code MGW-001 Case type Conversation
Case is Update
from Time
Product
MGW Product UMG 8900
Family
Case01Echo observed on PSTN Trunk Group connected with
Gateway MGW due to tail length

It was reported by customer that Echo is being observed on calls with PSTN on specific
Trunk Group configured on Gateway MSC and MGW. The Echo is observed only on one
Trunk Group connected to PSTN Point Code “XXXX”. The Echo is observed only on
Mobile Subscriber Side it is not heard on PSTN Subscriber end.
No Alarm Information is available
3. Cause Analysis
Please refer the below diagram describing the scenario in detail.
29
HUAWEI Confidential
First of all we check the EC Mode setting in the Trunk Group Configuration of MSC side
and found it to be OK.
We checked the ECPARA configurations on MGW end and found everything to be OK.
+++ HUAWEI UMG8900 2012-10-30 18:41:59
O&M #16
%%LST ECPARA:;%%
RETCODE = 0 accomplished
EC work parameters of VPU
EEC tail length(ms) = 64
AEC tail length(ms) = 400
Nonlinear processor switch = Enable
Comfort noise generation mode = Noise
Bypass EC switch = Disable
Automatic gain control switch = Disable
Tone detection switch = Enable
30
HUAWEI Confidential
Tone detector type = G.165
EC option = YES
Tfo switch = Disable
Tfo mode = 16_bit_transparent
Notch switch = Disable
Notch mode = 50HZ
EC work parameters of ECU
EEC tail length(ms) = 64
AEC tail length(ms) = 400
Nonlinear processor switch = Enable
Comfort noise generation mode = Noise
Bypass EC switch = Disable
Automatic gain control switch = Disable
Tone detection switch = Enable
Tone detector type = G.165
EC option = YES
Tfo switch = Disable
Tfo mode = 16_bit_transparent
Notch switch = Disable
Notch mode = 50HZ
--- END
All the Echo Cancellation related configurations were found to be normal on both the
MSC and MGW.
As per the traces captured below our MGW is allocating the TC resource for the
problematic call and hence should be able to cancel the echo.
IAM Message:
ACM Message:
31
HUAWEI Confidential
MOD REQ Message:
After that we performed the testing with Bearer Fault of UMG8900 and recorded the
voice call. For details on how to make the Voice Record and loop back testing using the
Bearer Fault Tool, you can consult the help guide available with the tool.
It is also evident from the flow diagram made by the Bearer Fault Location Tool for the
problematic call, that the MGW is successfully adding the EC resource for this call, but
still the Mobile user is hearing the echo in the voice.
The recorded voice was further analyzed by GTAC and below findings were made,
The echo energy is not high, and the echo length coming from PSTN is 262ms. As per
the current configuration, our MGW can erase the Echo with length in between 64ms.
Considering the maximum capability of Huawei MGW, it can erase the echoes of up to
128m. See the command SET ECPARA on MGW LMT.
32
HUAWEI Confidential
As the tail length of the echo is out of range of MGW capability so it cannot be handled at
Huawei end, this need to be checked at PSTN end.
4. Handling Process
As the echo length of problematic calls is 262ms, and MGW maximum capability is
128ms, so it cannot be handled at Huawei MGW end. This need to be checked at PSTN
end.
If the customer still insist that the solution to be provided by the Huawei side then we can
involve the Huawei Solution Team to look into the matter.
33
HUAWEI Confidential
Title The analysis report for silent call(after upgraded the UMG)
Keywords silent one way audio HRB swap
Case code MGW-002 Case type Conversation
Case is Update
from Time
Product
MGW Product UMG8900
Family
Case02 The analysis report for silent call (after upgraded the
UMG)
Customers met silent call problem after upgrading to UMG8900 R008.

Notes: the issue disappeared after swapped the HRB board.
NULL
3. Cause Analysis
1. Trying to recur the problem, then got the MGW trace and recording files for finding the
root cause, but can’t recur it.
2. Base on the MGW logs and the board position, we can find only the RPU board
swapped after upgrading to UMG8900V200R005C10SPC301.
 The frame 1 slot 14 RPU board is master board before upgrading.
 The frame 1 slot 15 RPU board is master board after upgrading
34
HUAWEI Confidential
3. And GE port of G1O boards do not swap; we can confirm the bear path don’t change.
 The working port is frame 1 slot 14 G1O board before upgrading
GigabitEthernet0 is up line protocol is up
5 minutes input rate 44013574 bytes/sec, 472447 packets/sec
5 minutes output rate 47454442 bytes/sec, 508145 packets/sec
 The working port is frame 1 slot 14 G1O board after upgrading
4. According to the analysis above, doubt the frame 1 slot 15 RPU board is faulty, and
then led the silent call problem.
According to the system log, it indicate the RPU send the UP message to peer side
failed.
(2013-05-29 09:08:13) HRB-1-15-FRONT {MRPU_IPB:44 TICK:2780929} <ipb_api.c
line:335>
Reason: c=548816, t=8204,cas=T(C548816T8204) UP(I2D2S2W1F1E51)
Fail.RIP:UDP=212.220.23.188:27648.
From the point 3 above, We know the bear path don’t change, so we think the inner
exception of RPU cause the issue.
Then, we find there are many reset records of RPU in frame 1 slot 15.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Reset time : 2013-05-21 21:39:20
Reset type : 1(PROGRAM)
Reset info : Reset Board at rpu_mnt_intr.c(2800)
Start time : 2013-05-21 21:41:18
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Reset time : 2013-05-21 18:34:56
Start time : 2013-05-21 18:36:54
35
HUAWEI Confidential
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Reset time : 2013-05-21 15:30:25
Start time : 2013-05-21 15:32:23
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Reset time : 2013-02-12 12:02:30
Start time : 2013-02-12 12:04:25
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Reset time : 2013-02-11 14:37:47
Start time : 2013-02-11 14:39:42
What’s the reason about the reset for rpu_mnt_intr.c (2800)?
The Inner core chip will send the test message to the SFU logic chip on time. If the core
chip dose not receive the response message from SFH for 3 times, then RPU will reset
itself to try recover the exception. When the exception occurred very frequently, it
indicate the path between core chip and SFU logical chip have some hardware
exception.
Manual swap frame 1 slot 14/15 RPU board (slot 14 RPU board is master board); And
customer don’t meet the silent call any more.
4. Handling Process
The frame 1 slot 15 RPU board is fault.

Replace the frame 1 slot 15 RPU board by new one.
NULL
36
HUAWEI Confidential
Title DSCP marking not ok on UMG after configuring PRITODSCP table

Keywords DSCP Packet marking
Case code MGW-003 Case type Traffic Statistic Problem
Case is Update
from Time
Product
MGW Product UMG 8900
Family
Case03 DSCP marking not ok on UMG after configuring
PRITODSCP table
There is UMG in customer M network, we took wire shark traces on various locations and
found all packets marked by UMG are not EF, From analysis we found 98% packets are
EF and 2% are BE Version of UMG: UMG8900V200RV2R8C3SPH137.
NULL
3. Configuration Information
37
HUAWEI Confidential
4. Cause Analysis
1. Captured wire shark traces and analyze RTP packets for both EF and BE type found
as below.
2. Check PRITODDSCP table and found values for normal QOS =EF and issue is
happening in normal hours as well so this table no issue.
3. Captured H248 traces and found all ADD request to MGW include priority field based
on this field UMG will check PRITODSCP table and mark packets.
38
HUAWEI Confidential
4. Check H248 Protocol and found there are some scenario that UMG don’t packet IP
message base on MSX assign H248 priority field.
Case1: TrFO calls in this case UMG will not use MSC provided Priority field to mark
packets as it is TC free operation. If UMG receive a BE message, will send out BE
message too, don’t relation with MSX assign which level priority.
5. Checked RTP trace on wire shark and found two cases trace TrFO case where UMG
not mar packets and Non TrFO where UMG mark packets
39
HUAWEI Confidential
It is clear TTL=122 means packets generated by far side UMG just transfer, for all
packets generated by UMG TTL=128.
5. Handling Process
1. Captured wire shark traces and analyze RTP packets for both EF and BE type found
as below.
2. Check PRITODDSCP table and found vlaues for normal QOS =EF and issue is
happening in normal hours as well so this table no issue
3. Captured H248 traces and found all ADD request to MGW include priority field based
on this field UMG will check PRITODSCP table and mark packets
4. Check H248 Protocol and found There are some scenario that UMG don’t packet IP
message base on MSX assign H248 priority field.
Case1: TrFO calls in this case UMG will not use MSC provided Priority field to mark
packets as it is TC free operation . if UMG receive a BE message, will send out BE
message too, don’t relation with MSX assign which level priority.
5. Checked RTP trace on wire shark and found two cases trace TrFO case where UMG
not mar packets and Non TrFO where UMG mark packets
40
HUAWEI Confidential
It is clear TTL=122 means packets generated by far side UMG just trasfer, for all
packets generated by UMG TTL=128
So for this case only solution is ask Peer side including DCE ensure mark packets for
above scnerio other wise core network can do nothing .
Deep IP packet knowledge and telecom protocol theory can enable fast troubleshoot
multi product issues.
41
HUAWEI Confidential
Title call failed caused by insufficient resources. Out of ip resource

Keywords ficient resources out of ip resource umg
Case code MGW-004 Case type Data Configuration Problem
Case is Update
from Time
Product
MGW Product UMG8900
Family
Case04 call failed caused by insufficient resources. Out of ip
resource
Network: RNC----- (ip) --------gateway------- (ip) -------umg

Fault: A and B under the same RNC cannot make a call to each other. After called side
send call confirmed, MSC send disconnect to RNC.
NULL
4. Cause Analysis
1. According to the call flow, it is time to establish bearer. So check ADD message.
42
HUAWEI Confidential
UMG response an error, insufficient resources. Out of ip resource. Need to check bearer.
1. On umg board HRU ping the ip go RNC -----ok, so the IP is right.
2. In the line 104 of attachment, there is one error "insufficient resources. Out of ip
resource".
It means umg cannot use the ip to bear service.
3. If correct service ip cannot bear service, we can say the IP cannot connect to the
gateway.
5. Handling Process
1. On umg board HRU ping the ip go RNC -----ok,so the IP is right.

2. Check UMG configuration, ADD GWADDR is not configured.
3. After ADD GWADDR, the call is ok.
When use IP bearer, UMG first check whether PING gateway is ok, if gateway is not
reachable, UMG will not choose this IP as bearer IP. For IP bearer site, ADD GWADDR
must be configured.
43
HUAWEI Confidential
Title Call failure in AOIP

Keywords AoIP, TC resource insuffient
Case code MGW-005 Case type Codec Problem
Case is Update
from Time
Product
MGW Product UMG8900
Family
Case05 Call failure in AOIP

Subscriber in MGPD301 can’t make a call to subscriber MGPD302 (MGPD302 is the

MGW has implemented AoIP).
After tracing user message trace have many call fail with reason "TC Resource
insufficient".
This is happened after customer modify codec in MGW (MGPD301).
NULL
BPDG7(Under MGPD301)_08195900042_to_BPRM1(under MGPD302)_08197501883_NOK.ptmf
BPDG7(Under MGPD301)_081933690041_to_BPRM1(Under MGPD302)_087895510308_NOK.ptmf
BPDG7(under MGPD301)_081959000974_to_BPRM1(Under MGPD302)_NOK.ptmf
4. Cause Analysis
1. After check the trace through MGPD301 have many call fail to MGPD302, because
have error message TC Resource insufficient.
44
HUAWEI Confidential
After we check codec that configured in MGPD301 there is no codec GSM HR in

MGPD301.
So we need to configure this codec in MGPD301 to connect to AoIP MGW (MGPD302).

After AoIP reconstruction is complete, the BSC does not provide transcoder channel (TC)
resources regardless of the networking mode. The TC resources are provided by the
MGW on the core network. As the MGW consumes a large number of TC resources, the
MGW must be configured with VPU boards that support GSM codec.
5. Handling Process
Many unsuccessful call from BPDG7 under MGPD301 to BPRM1 under MGPD302. After
check no codec GSM HR in MGPD301, it’s possible cause subscriber can’t make a call.
And this is reason in trace call errorText:"Insufficient resources.Out of TC resource.".
Solution is add GSM HR codec. After add GSM HR all call from BPDG7 under MGPD301
45
HUAWEI Confidential
to BPRM1 under MGPD302 is success.
From trace call have many call fail due to MGPD301 have TC resource insufficient.
So check in MGPD301 as following:
1. DSP MEDIARES to check VPU load
2. LST CODECCAP to check codec configured
From LST CODECCAP we find if in MGPD301 no have GSM HR. So we add new codec
GSM HR.
SET CODECCAP: BN=2, CODEC=NGN-0&WCDMA-0&GSM-0&G711_CAS-0&CDMA-0&VIG-
0&GSMHR-1&WCDMAWB-0&FPTC-0&MPTY-0&CAS-0&CTM-0&EVRC-0&CDMANOTFO-0;
After add GSM HR codec problem solved.
46
HUAWEI Confidential
Transmission Product Training Technical Cases
How to segregate IP domains on MGWs when various offices
Title
communicating through IP
Keywords IP domains segregation on MGW.
Case code MGW-006 Case type Codec Problem
Case is Update
from Time
Product
MGW Product UMG8900
Family
Case06 How to segregate IP domains on MGWs when
various offices communicating through IP

Mosftx3000: V1R8C03 SCP 200

UMG8900: V2R8C02SPC100
Star topology: two STPs involved in the network.
3 MGWs registered with single MSX. MGW_A, MGW_B and MGW_C. Interfaces: NC
interface TDM (ISUP) and SIP. Nb interface IPoE1.Planed to test 3G voice and video
call.
Intra calls in MGWB were fine but calls between MGW_A and MGW_B were affected. All
calls were established successfully but due to no voice, calls were ending after 2 or 3
seconds.
There was no alarm on alarm panel but only the CSSR KPI rate decreased abruptly. Too
many complains received from customers in the coverage of MGW_A and MGW_B.
When checked from the Band width utilization command on MGW_A DSP IPBRES:
TP=DOMAIN, DOMAIN=0;
The Band Width has been increased from 35MB to almost 548MBfor result check the
attached snap shot.
47
HUAWEI Confidential
3. Cause Analysis
We analyze the cause following the bellow steps.

1) We checked which coverage area is affected.
2) Local calls under the MGW_B coverage were fine.
3) Calls between MGW_B and MGW_C were fine.
4) Calls between MGW_A and MGW_C were also fine.
For IPoE1 we have to add IP address for the VT interface but we don’t need to add Gate
way. When we added the IP address and Gate way for the GE interface of HRB board
to communicate with new added RNC and select domain 0 which is the default domain
on MGW.
MOD IPIF: IFT=GE, BT=HRB, ENABLE=YES, DOMAIN=0;
ADD GWADDR: BN=2, DOMAIN=0, IPADDR="x.x.x.x", GWIP="y.y.y.y", TIMEOUT=No
Aging;
Default domain 0 was already adopted for IPoE1 communication between MGW_A and
MGW_B.
MSC was directing MGW which IP domain0 as added in the ADD OFC;
ADD OFC: OOFFICT=RNC, OFCTYPE=COM, SIG=NONBICC/NONSIP, SVQE=NO,
IPD=0;
The IP domain 0 was routed towards GW y.y.y.y due to which there was no voice after
call establishment.
4. Handling Process
The following steps adopted to solving this problem.

1. MGW part
As there are almost 1000 IP domain supported by large scall MGW.
1) configured new doamin with the IP segment selected for RNC.
SET DOMAIN: DOMAIN=4, DNAME="RNC ", DESC="new domain for RNC",
ASTART="x.x.x.x";
2) reconfigured the MOD IPIF and select domain 4.
MOD IPIF: IFT=GE, BT=HRB, DOMAIN=4;
3) reconfigured the Gate way with ip domain 4.
48
HUAWEI Confidential
MOD GWADDR: BN=2, DOMAIN=4, IPADDR="x.x.x.x", GWIP="y.y.y.y";
2. MSC part :
MOD OFC: ON="HRNC_0", IPD=4;
So, eventually we segregate MGW_B domain from new added RNC domain and the
problem solved.
In case of IP communication, it should be realized that which IP domain is used for which
office. A small mistake can cause very big service affect.
IP communication includes, BICC, SIP, IPoE1 solution, AoIP and IUoIP.
The IP Domain number selected in ADD OFC number, MSC will send this number to
MGW for directing the voice path. Although IP related communication configuration in
mobile network is easy but risky at the same time as well. We should be very care full
and meticulous.
49
HUAWEI Confidential
USC Cases
Case1 Database Backup Failed Daily because of DMU Hard disk Space not
Title
Enough
Keywords Database backup, hard disk, DMU board
Case code USC-001 Case type Database Problem
Case is Update
from Time
Product
USC Product GU HLR9820 V9
Family
Case1 Database Backup Failed Daily because of DMU Hard
disk Space not Enough

Site Name: HLR-BE-SBY1

Number of Subscriber ; Dynamic : 19.1 million , Static : 38.1 million
There was alarm Database Backup or Restoration Failed in HLR-BE-SBY1 start from
July 15th, the Backup Physical Database process has been stopped since that time.
Besides that, there was alarm Free Storage Space Insufficient every morning and hit
95% load in USDMU Subrack 0 Slot 10, but cleared normally.
We have automatic backup physical database daily at 4.00 AM, the parameter of the
backup save mode is set to NOSTOSERVER so the backup files are stored in the
/opt/USCDB/backup/data directory on the hard disks of the DMU boards
+++ USCDB/*MEID:6*/ 2013-08-19 14:10:27+07:00 O&M #139

%%LST BACKUP:;%%
The result is as follows

------------------------
Database ID = Database
Backup configuration ID = 0
Automatic backup switch = On
Automatic backup time = 04:00:00
Maximum number of stored backup periods = 1
Save mode = Not save to server
NDF module number = 201
50
HUAWEI Confidential
Local IP address = NULL
Local gateway = NULL
Local subnet mask = NULL
Local network port = NULL
Server IP address = NULL
User name = NULL
Password = *****
Path = NULL
Server port number = NULL
--- END
Managed Element ID = 6
Alarm Severity = Major
Alarm Name = Database Backup or Restoration Failed
Raised/Cleared Time = 2013-07-15 06:40:08+07:00
Parent Serial No. = 0
Serial No. = 345386
Alarm ID = 11002
Event Type = Running
Module No. = 201
Location Info = Subrack number=0, Slot number=10, Cause=Database
backup failed
Repeat Times = 0
Auto Clear = Yes
Cleared Type = Uncleared
Managed Element ID = 0
Alarm Severity = Critical
Alarm Name = Free Storage Space Insufficient
Raised/Cleared Time = 2013-07-22 06:23:21+07:00/2013-07-22 06:54:14+07:00
Parent Serial No. = 0
Serial No. = 24207
Alarm ID = 1009
Event Type = Running
Module No. = 510
Location Info = Rack number=0, Position number=0, Subrack number=0,
Slot number=10, Location=Front, Board type=UPBA2,
Logical storage space name=/opt, Free storage space
size(MB)=5876, Total storage space size(MB)=118519,
51
HUAWEI Confidential
Used storage space rate(%)=95, Alarm level=4th
level, Alarm threshold(%)=95
Repeat Times = 0
Auto Clear = Yes
Cleared Type = Normally cleared
3. Cause Analysis
1) Signaling flow of the SMSCF as below:
2) From the trace of B number (called number). HLR return SRI_SM_Rsp to SMSC
with the MSC number of subscriber B. And then the subscriber B receives SMS, not
subscriber C (FTN subscriber) as the flow.
3) We also trace C number but there is no message.

4) So in this case HLR cannot send out the SRI_SM_Req for C number. There should
be something wrong in signaling configuration.
There are 2 key tables to implement SMSCF:
a) SSN MSC (0x8) for the point code of HLR. This one will make HLR work as
MSC/SMSC function to send out SRI_SM_Req
b) SCCP GT for the FTN number.
4. Handling Process
1) Check the configuration of HLR FE, there is no configuration of SSN MSC (0x8) for
the point code of HLR. Configure it:
ADD SCCPSSN: SSNNM=" HFHC01H_MSC ", NI=NAT, SSN=MSC, SPC="
H'002062", OPC=" H'002062";
52
HUAWEI Confidential
2) After configuring it, SMSCF is success for local network case but failed in case
forward to other PLMN. From the trace message of FTN number, HLR has sent out
the SRI_SM_Req but there is no response and HLR send Abort then.
It should be problem of STP or other PLMN HLR.

3) Check the STP.
Normally HLR working as HLR self, so when HLR send message to other NE, the
calling SSN is HLR. That’s why everything is ok in normal SMS flow.
But this time, HLR of number B working as a SMSC role, when HLR send SRI REQ
to HLR of number C, the calling SSN is MSC. From our HLR side, we already
configured MSC SSN for HLR DPC.
But, after HLR of number C reply SRI RSP to our HLR with called SSN=MSC, when
message goes through STP. If the translation policy from STP to our HLR is route on
DPC+SSN, the STP should configure one more SSN, configure HLR DPC as MSC
SSN.
After configure HLR DPC as MSC SSN, the SMSCF service is OK. All the trace
message is attached.
There are 2 key tables to implement SMSCF:

1) SSN MSC (0x8) for the signaling point code of HLR. This one will make HLR work as
MSC/SMSC function to send out SRI_SM_Req. Remember to configure it in both
HLR and STP
2) SCCP GT for the FTN number.
53
HUAWEI Confidential
Case2 PGW Web LMT is not working because standby module of PGW
Title
was not configured
Keywords PGW, Web LMT, Operator not logged in
Case code USC-00 Case type Data Configuration Problem
Case is Update
from Time
Product
Family
Case2 PGW Web LMT is not working because standby
module of PGW was not configured

HLR version is V900R006C07SPC300

When we tried to access Web LMT for Subscriber Provissioning data, it was found that
PGW was inaccessable.
None
3. Cause Analysis
1) ME configuration is not standard configuration,only one PGW module has been

configured.
2) DEBUG logs were taken at the same time during the problem appearing but no
problem was found in the log.
3) Database was also consistant as there was no error returned when we ran STR
CRC and CHK DATA command.
4) ME configuration was checked and it was found normal.
4. Handling Process
1) Only one UPBA6 board arrived in configuration for PGW, so it was decided to add
stand-alone PGW module.
2) PGW module 21 configuration was done as stand-alone:
ADD MODULE:MID=21,MT=PGW,SRN1=0,SN1=1,MNAME="PGW21";
PGW Module 21 was found normal.
54
HUAWEI Confidential
3) When we tried to access Web LMT for Subscriber Provissioning data, it was found
that PGW was inaccessable.
4) We tried to add another port for subscriber provissioning 7775

ADD
PORT:PORTNO=7775,PORTTYPE=PORT_FOR_PROV,PORTTYPENAME=PORT
_FOR_MML,DISABLEPORT=NO,PORTBUSSTYPE="GU-
HLR",PORTSHKTYP=NORMAL,PORTCONTENT=SHK-
HND,SHKLEN=10,SNDSHKIMM=SNDIMMEDIATELY;
Upon accessing Web LMT, we found that system was returning error: Operator not
logged in
55
HUAWEI Confidential
5) After analysis with HLR experts, another PGW module 22 was added with standby
module configured together with DIU.
ADD
MODULE:MID=22,MT=PGW,SRN1=0,SN1=1,SRN2=0,SN2=10,MNAME="PGW22";
Both module and Web LMT of PGW became normal.
PGW modules must be configured on active and standby configuration because this is
system limitation that PGW modules together support Web LMT and operator login
facility. Otherwise, we are unable to access the Web LMT of PGW.
56
HUAWEI Confidential
Case3 The false connect of the fiber cable between USI3 and S3100 caused
Title
Alarm-4835 on LMT
Keywords 4835, S3100, Fiber cable
Case code USC-003 Case type HDU Problem
Case is Update
from Time
Product
Family
Case3 The false connect of the fiber cable between USI3 and
S3100 caused Alarm-4835 on LMT

1) There was ALM-4835 on LMT

2) The command to "mppUtil -S" show that one link between USI and S3100 was down
hlr_db01:~ # mppUtil -S
H5C0T0 Active Active S3100
H3C0T0L000 Down H1C0T0L000 Up
3) 3: Customer tried to use OceaStor software GUI tool to switch the LUN from
Controller B to Controller A, but failed.
ALM-4835 Disk Array Status Abnormal.
3. Cause Analysis
1) ALM-4835 means one or more links between host and disk array was fault.
problem cause:
a:The fault of controller of disk array
b:The fault of SFP of controller
c: The fault of SFP on USI
d: Fault of fiber cable
From the primary log as below:
57
HUAWEI Confidential
It showed that both hlr_db01 and hlr_db02 has one link to Controller A of disk array
was fault.
So it is unlikely be 2 fiber cable, or 2 SFP on different board went fault at the same
time.
Or both the SFP on Contrller A are fault.
The probably reason for this issue should be Contoller A is fault. But, after customer
had replaced the fault controller, the problem still exist.
2) Collect below information:

a: run on both host
#vxdisk list
#mppUtil -a
#mppUtil -S
#vxprint -g datadg
#ping 172.16.128.201 and 172.17.128.202
b: collect S3100 all support data
use OceaStor management software collect support data as below figure.
4. Handling Process
1) Check the logs of S300 disk arrayFrom the log of storageArrayProfile.txt in all
support data.
a:Controller A is online that means controller A is ok.
Controller in Tray 85, Slot A
Status: Online
58
HUAWEI Confidential
Current configuration
Firmware version: 06.19.15.00
Appware version: 06.19.15.00
Bootware version: 06.19.15.00
NVSRAM version: N399X-619834-400
b: check Drive interface and host interface of controller A

the drive interface is used to connect to S3100 internel drive disk.
the host interface is used to connect to host, such as hlr_db01/hlr_db02
Drive interface: Fibre
Channel: 1
Link status: Up
Drive interface: Fibre
Channel: 2
Link status: Up
Host interface: Fibre
Channel: 1
Data rate control: Auto
Link status: Down
Topology: Not available
World-wide port name: 20:02:00:a0:b8:50:c5:67
World-wide node name: 20:02:00:a0:b8:50:c5:66
Part type: HPFC-5700 revision 5
Host interface: Fibre
Channel: 2
Data rate control: Auto
Link status: Down
Topology: Not available
World-wide port name: 20:02:00:a0:b8:50:c5:68
World-wide node name: 20:02:00:a0:b8:50:c5:66
Part type: HPFC-5700 revision 5
The host interface status is down , this is consist with the result of "mppUtil -S"
C: check the SFP information of Controller A

usually, in HLR93, we can only see 2 SFP on one Controller, it is attached to host-
side, but in this case we see 4 SFP, 2 for host side, and 2 for drive side.
the SFP for drive side is used to connect other disk array for expand
SFP status: Optimal

Attached to: Host-side of controller A
Vendor: PROLABS
Date of manufacture: December 10, 2012
59
HUAWEI Confidential
SFP status: Optimal
Attached to: Host-side of controller A
Vendor: PROLABS
Date of manufacture: December 10, 2012
SFP status: Optimal

Attached to: Drive-side of controller A
Vendor: JDSU
Date of manufacture: February 24, 2009
SFP status: Optimal

Attached to: Drive-side of controller A
Vendor: JDSU
Date of manufacture: February 24, 2009
2) Check the "vxdisk list" result

hlr_db01:~ # vxdisk list
DEVICE TYPE DISK GROUP STATUS
sda auto:none - - online invalid
sdb auto:cdsdisk datadisk1 datadg online
sdc auto - - error
sdd auto - - error
sde auto - - error
sdf auto:cdsdisk - - online invalid
sdg auto - - error
sdh auto - - error
sdi auto:cdsdisk - - online invalid
sdj auto - - error
sdk auto - - error
We see disks much more than we expected, the sdc to sdk, 9 disk must be in disk
array, and caused by the fiber cable connect to the drive SFP of controller A.
After customer revised the fiber cable, and reboot hlr_db01 and hlr_db02, problem
sovled.
Make sure all cable is exactly connected as product document said.
60
HUAWEI Confidential
61
HUAWEI Confidential
Title Case4 Inappropriate parameter causes slow provisioning system

Keywords provisioning system, slow ,BATSEQLEN,batch ,PGW
Case code USC-004 Case type Provisioning Problem
Case is Update
from Time
Product
USC Product HSS9860
Family
Case4 Inappropriate parameter causes slow provisioning
system
Version:HSS9860 V900R008C00.
Provisioning system tried to execute batches on HSS9860, the execution was very slow
It takes more than 3 hours, and this happened sometimes, and it’s not often.
None
3. Cause Analysis
1) After checking the record of commands in the batch and the operation log,We find
that the command type of the normal batch and abnormal batch the same?
(Command type means “MOD””ADD” and so on.)
And both abnormal and normal batches are running in the same period in the day
And there is no timing task may influence the performance of the PGW when you
execute the batches
There is nothing abnormal
2) When we check the software parameter.
We find the value of (BATSEQLEN) =1 which is the default value
Batch operation queuing length (BATSEQLEN)
This parameter specifies the maximum number of messages
Description
that can be cached in a queued batch operation.
Value Value range: 1 to 300
Range Default value: 1
When the batch operation efficiency of the PGW cannot meet
Application
requirements, modify the value of this parameter to increase
Scenario
the batch operation efficiency.
Please refer to the HEDEX when setting this parameter value (the advised value
62
HUAWEI Confidential
between 1 and 30).
NOTE:
 The value of this parameter can be modified only on the active USCDB.
 If only active and standby PGW modules are configured or only the active and
standby PGW modules process batch operation tasks, you are advised to set this
parameter to a value between 1 and 30. This setting applies to the scenario in
which only one batch operation is performed each time.
 If batch operation tasks are processed by multiple PGW modules that work in
load-sharing mode, you are advised to set this parameter to a value between 1
and 30. This setting applies to the scenario in which multiple batch operations
need to be performed at the same time and load-sharing PGW modules process
most of the batch operation tasks.
 The value of this parameter varies depending on the PGW module configuration
and the complexity of batch operation commands. Engineers from each FE need
to set this parameter to a proper value based on the recommended value range
and perform service tests to verify whether the parameter value is appropriate.
4. Handling Process
Modify this software parameter as following:

(Only in active HSS, need to restart the active and backup PGW module, in the HSS
Restart the PGW module in a low service time, and don’t execute batches when restart)
MOD INSP: INSPT=PGW, INSPN=BATSEQLEN, INSPV=10;
Restart the module, use the following commands
RST MODULE: MID=21;
After HSS parameter update, we noticed that batch time is fair now same as usual
expected time.
Samples:
%%CHK BATSTAT: TASKID=536871076;%%
TASK ID> <START TIME> <END TIME> <STATUS> <TOTAL> <SUCCESS>

536871076 2013-06-23 12:38:48 2013-06-23 12:46:02 COMPLETED 36491 36217
%%CHK BATSTAT: TASKID=536871077;%%
< TASK ID> <START TIME> <END TIME> <STATUS> <TOTAL> <SUCCESS>
536871077 2013-06-23 12:55:05 2013-06-23 12:56:08 COMPLETED 36491 36491
After HSS parameter update, we noticed that batch time is fair now same as usual
expected time.
63
HUAWEI Confidential
Case5 Unable to connect to LTE network by using dongle due to missing
Title
APN information from dongle
Keywords EPS bearer, Default APN, Dongle
Case code USC-005 Case type
Case is Update
from Time
Product
USC Product HSS9860
Family
Case5 Unable to connect to LTE network by using dongle due
to missing APN information from dongle

Version:HSS9860 V900R008C00SPC103
Test user was unable to connect to LTE network by using dongle.
None
3. Cause Analysis
Customer configured "internet.test.com" as the APN in dongle and tried to attach to LTE
network, however, the dongle cannot attach to LTE network successfully.
As per checking in PDN-GW, APN "internet.test.com" has been assigned for LTE service
in DNS.
1) As per checking in MME, the error code for this subscriber is "unknown or missing
APN". Meanwhile, MME was unable to decrypt the APN message of the subscriber in the
log. Thus, we suspected the dongle was not sending any APN information to MME during
the attach request.
2) According to 3GPP 23401 protocol, if UE does not provide any APN information, the
EPS bearer will be establish by using the default APN of the subscriber:
3) As per checking in HSS, the default APN of this subscriber was "http.test.com", and
this APN was not assigned for LTE service in DNS. Thus, using APN "http.test.com" to
establish EPS bearer will not be success in the attach request.
4. Handling Process
1) Set up user trace in LMT FE. From the trace, MME was sending purge message to
HSS after diameter authentication and diameter location update:
64
HUAWEI Confidential
2) In HSS PGW, LST OPTGPRS. This subscriber has been subscribed to APN
"internet.test.com" and "http.test.com". The default APN was "http.test.com".
3) Double checking on the APN configuration in dongle, it was "internet.test.com".
4) As per checking in PDN-GW, APN "internet.test.com" has been assigned for LTE
service in DNS.
5) As per checking in MME, the error code was "unknown or missing APN". Meanwhile,
MME was unable to decrypt the APN message in the log. Thus, we suspected the
dongle was not sending any APN information to MME during the attach request.
6) Insert the SIM card to LTE handphone and use APN "internet.test.com" to attempt to
attach to LTE network. Attach to LTE network successfully.
7) Double checking in PDN-GW, APN "http.test.com" was not allowed for LTE services.
8) According to 3GPP protocol, if UE does not provide any APN information, the EPS
bearer will be establish by using the default APN of the subscriber. Thus, execute
command MOD OPTGPRS in HSS PGW to configure APN "internet.test.com" as the
default APN for this subscriber.
Example of the MOD OPTGPRS and CNTXID=1 is the context ID for APN
"internet.test.com":
MOD OPTGPRS: IMSI="XXX", PROV=MODPDPCNTX, CNTXID=1,
APN_TYPE=EPS_APN, DEFAULTCFGFLAG=TRUE;
9) Then, we tried to attach to LTE network by using the dongle. The UE attached to
LTE network successfully.
In order to avoid similar attach issue, the default APN for the subscriber should be the
APN that has been assigned for LTE service in DNS.
65
HUAWEI Confidential
Case6 UPCC Service Condition overlap lead to IP-CAN Session

Title
termination temporarily
Keywords IP-CAN Session, Termination, Performance
Case code USC-006 Case type Service Problem
Case is Update
from Time
Product
USC Product UPCC
Family
Case6 UPCC Service Condition overlap lead to IP-CAN
Session termination temporarily

UPCC service two condition overlap lead to new rule install unsuccessfully and IP-CAN
Session termination request appear at 8:00 every day and then IP-CAN Session can be
reestablished successfully.
UPCC Version：V300R005C015SPC100
UGW9811 Version：V900R009ENGC01SPC300.
None
3. Cause Analysis
1) After swap the traffic to the huawei UPCC, the performance number of successful
IP-CAN session terminate request shows comparative more IP-CAN Session
termination request appear at 8:00 every day, and the performance number of
successful IP-CAN Session establishment request shows IP-CAN Session can be
reestablished successfully.
66
HUAWEI Confidential
2) By tracing the diameter message, we found that in 24 service when qci equals 8,
UPCC send RAR message to UGW at 8:00 everyday, including remove the rule
Unlim_LTE_throat, but no install the new rule, then lead to UGW send CCR-
termination message, and users detach temporarily, and then can reattach
successfully.
3) According to the tracing diameter message, we check service 24(Unlim_LTE)

configuration.In UPCC service configuration, one condition configuration has
something wrong, and leads to 24(Unlim_LTE) two condition has part overlap as
follow table described.
67
HUAWEI Confidential
Service
Rule Name Predefined Name Condition
Name
CG_OR{
24-
Quota.QuotaStatus(Unlim_LTE_Quota
Unlim_LTE_nolimit Unlim_LTE_throat
) < Exhaust
_qci_8
}
CG_AND{
24(Unlim_
Quota.QuotaStatus(Unlim_LTE_Quota)
LTE)
24- > Normal
Unlim_LTE_nolimit Unlim_LTE_throat Quota.QuotaStatus(Unlim_LTE_Quota) <
_qci_9 Level 4 (60G)
System.DateTime=(01:00-08:00)(night)
}
4) Users of subscribed 24(Unlim_LTE) service which qci equals 8, will detach at 8:00
every day temporarily, because timer range change, the rule is removed, but the
same rule is not installed. But when users attach again, then it matches the
appropriate condition, the rule installed successfully and then can reattach
successfully.
4. Handling Process
Modify the service 24-Unlim_LTE condition as follows.

Service
Rule Name Condition Modify
Name
CG_AND{ CG_AND{
Quota.QuotaStatus(Unlim_LT Quota.QuotaStatus(Unlim_LT
E_Quota) > Normal E_Quota) > =Exhaust
24- 24-
Quota.QuotaStatus(Unlim_LTE Quota.QuotaStatus(Unlim_LTE
Unlim_LT Unlim_LTE_noli
_Quota) < Level 4 (60G) _Quota) < Level 4 (60G)
E mit_qci_9
System.DateTime=(01:00- System.DateTime=(01:00-
08:00)(night) 08:00)(night)
} }
Then the service 24-Unlim_LTE all conditions are independent and cover all service
scene.
The performance on M2000 is all normal. And we trace 24-Unlim_LTE service message,
the message flow is normal.
UPCC service condition is complicated. The condition should independent and avoid
intersection, also should cover all service scene. Especially while refer to time range
change, the service test before migration should cover different time range and also
involve change of time range, check if the right rule is removed and installed
68
HUAWEI Confidential
successfully.
69
HUAWEI Confidential

2013Q4 Core Network Cases Analysis CS USC)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2013Q4 Core Network Cases Analysis CS USC)

Uploaded by

Copyright:

Available Formats

Core Network Product Training Technical Cases

Core Network Cases Analysis

MSC Server Case.................................................................................................................... 3

Chapter 4 MSC Server Case

Title CS to NGN via SIP (over UDP) call failure

Case01 CS to NGN via SIP (over UDP) call failure

At operator a in country A, a test call from CS to NGN is performed. After the

CSMSS03_NGN call failed_2013-07-23-17-11-33.ptmf

6. Suggestions and Summary

Title GMSC is sending an early ACM

Case02 GMSC is sending an early ACM

6. Suggestions and Summary

Title M3UA link fault alarm appears after every 10 minutes

Case03 M3UA link fault alarm appears after every 10 minutes

Version Information: MSOFTX3000 V100R008C03:

Alarm ID 1811: M3UA Link Fault.

1. Check M3UA Link configuration on MSOFTX3000 side:

+++ NRBMSS1 2013-01-07 14:16:03+03:00

M3UA link table

M3LK_RNC514_00 145 M3LS_RNC514 10.15.20.2 10.15.20.10 15006

6. Suggestions and Summary

Message received and send little lead to the Average Acknowledgement

Case04 Message received and send little lead to the Average

Acknowledgement Delay of M3UA signaling links increase

The Average Acknowledgement Delay of M3UA signaling links from TWGMSS1 to

Average Acknowledgement Delay：This measurement entity measures the average

Analyze trace information：

5. Suggestions and Summary

In a trial project, when A-party subscribers call B-party subscribers, sometimes

1. The most possible reasons for voice issues:

5. Suggestions and Summary

Title BICC CIC count inconsistency

Case06 BICC CIC count inconsistency

5. Suggestions and Summary

Title Wrong Correspondence between TID and CIC in Data Planning

Case07 Wrong Correspondence between TID and CIC in Data

CPCI platform is adopted in a multi-area network topology at S province in C country. In

5. Suggestions and Summary

Title Silence in voice channel of SIP direction caused by sending

Case08 Silence in voice channel of SIP direction caused by

The problem happened when the platform connected to MSOFTX3000. Calling

First of all we should check signaling.

Execute MML command on UMG8900: SET RECPARA: NPRP=DSP2IP-1&IP2DSP-1,

6. Suggestions and Summary

To change ptime on MSOFTX3000 to 10ms there need to change configuration only on

Title MSC can't release call after no-answer timer expired

Case09 MSC can't release call after no-answer timer expired

Msoftx3000 Version: V100R009C00SPH713

MSC can't release call after no-answer timer expired.rar

1. Check user interface trace < MSOFTX3000_User_Message_Trace_2013-10-02-15-

2. After checking full flow user interface trace< MSX_User_Message_Trace_2013-10-07-

Two methods can resolve this problem:

6. Suggestions and Summary

1. Reading about internal user trace can help for troubleshooting.

Title Call Rejection due to wrong Codec selection

Case10 Call Rejection due to wrong Codec selection

5. Suggestions and Summary

Case01Echo observed on PSTN Trunk Group connected with

Gateway MGW due to tail length

No Alarm Information is available

Please refer the below diagram describing the scenario in detail.

MOD REQ Message:

+++ USCDB/MEID:6/ 2013-08-19 14:10:27+07:00 O&M #139