GO - NAST3016 - E01 - 1 GSM Network Optimization Case Analysis 58

Case Analysis on GSM Networ
k Optimization
Contents
 Call Drop
 Handover
 Congestion
 Coverage
 Paging
 Interference
 Allocation Failure
Severe call drops caused by the illegal user
 Description:
 2 cells of the GSM network in XX had severe call drop problem, about dozens
of times per hour in the day time.
 Cause Analysis & Procedure:

 According to the 24-hour performance statistics, most of the call drops were i
n the daytime. While very few of them were in the night. So the engineer susp
ected that the problem was related with the user behavior.
© ZTE Corporation. All rights reserved

 After tracing the Abis interface signaling, we found:

 (1) The handsets with the call drop problem all used the same IMEI number.
 (2) The dialed numbers were all the emergency number: 112;
 (3) The call drop occurred about 10s after the call was connected. After the cal
l drop, the user continued to dial 112 again and again.
Based on the above factors, we made the judgment: the call drop was caused
by the user himself. For example, the workers in a factrory were testing the ba
tteries of handsets, and they took out the battery while the call was still going
on. So if we disable the emergency call function of the cell, the user will try to
use another operator's network. After the operation, we found that the amou
nt of call drops in the cell was greatly reduced. After we enabled the emergen
cy call function later, the call drop problem didn't occur any more, becasue th
e user selected another operator's network.

 Summary:
 By analyzing the Abis signaling file, we can make judgement about the call dr
op problem and find out the regularity of the problem. The network performa
nce index and user experience may be harmed when the network resource is
occupied by some illeagle user. We can find out the illeagle user by signal tra
cing or analyzing the CDR from the switching side.

Call drops caused by handover failure of the han
dset
 Description:
 After the equipment been swapped to the GSM network, one subscriber com
plained that under the mobile environment, his call was automatically hanged
up within one minute after connection. The subscriber's handset is HS-D907 a
nd it worked normally under the MOT equipment network before the swap. A
nother subscriber complained that when he made a call by HS-D907 on the hi
ghway, the call was frequently hanged up about dozens of seonds after conn
ection. In addition, the subscriber said the handset never had the above probl
em in other places.

dset
 The engineer traced the Abis interface MM signaling from the switching side.
 When the XX handset is the calling party, it enters the Conversation state afte
r receiving "connect Ack". Several seconds later, the BSSAP entity sends a "cbc
learcmdEvent" message to the handset, and the handset automatically hangs
up.
 When the XX handset is the called party, it enters the Conversation state after
receiving "connect Ack". Several seconds later, the BSSAP entity also sends a
"cbclearcmdEvent" message to the handset, and the handset automatically h
angs up.
 According to the signaling tracing analysis, the core network makes the judge
ment that the connection is actively released by the wireless side. The releasin
g reason is 1, and the meaning of this value is:
1=Radio interface failure(1)

dset
 The engineer traced the Abis interface signaling from the OMCR
side.
 After tracing the signaling in the 900/1800 area of Cell 3 and conducting call t
race by MA10 software, we found that the handset released the channels afte
r the handover failure, and the handovers were all simultaneous handovers
 During the conversation, every time when the handover command was initiat
ed, the handset pointed to "full rate or half rate version 3", then the handover
was failed.

dset
 After comparing the version with the BSC voice version, the core
network engineer found that the preferred full rate voice version
for the wireless side was version 2, while the switching side only s
upported voice version 1 and 3, voice version 2 was not selected.
 Steps:
 In "Configure the relation between BSC and trunk group", the engineer added
the TFRV2 to the property of all trunk groups of the 79 and 80 BSC from the s
witching side. After that, the automatic hang up never happened again during
the dialing test.

dset
 Under the AMR mode, the HS-D907 handset misunderstands the
encrypted fields in the handover command, so the handover will
be failed. Once the encrypted fields contain non-encription infor
mation, the handset will report invalid mandatory filed, then the
handover is failed, and the call drop occurs.

Contents
 Call Drop
 Handover
 Congestion
 Coverage
 Paging
 Interference
Slow handover caused by improper handover pa
rameters
 Description:
 During the drive test, the engineer found that the handover from the Negotia
tion Building (covered by the 1800 network) to the Hongyan Primary School
(covered by the 900 network) was too slow.
 The testing vehicle moved from the north to the south, and the MS occupied
the Cell5 (CI ： 10355 ， BCCH ： 700) of the Negotiation Building for convers
ation. When the vehicle moved on, the MS gradually entered the coverage of
G1 cell of Hongyan Primary School (CI ： 11551, BCCH ： 115), and the level o
f the serving cell gradually turned to be -86db and became lower and lower. F
rom the table, we can see that the level of the G1 cell was -50db, but the servi
ng cell was not switched to the G1 cell of the school. So the level turned to be
worse, and the quality also became worse.

rameters
 Tmicro timer
 The 900 network and the 1800 network were set to be on the same layer, and
the Tmicro timer was set to be 8S. So when the handset occupied the cell 5 of
the Negotiation Building under the 1800 network, it could not be switched to
the 900 network at the same layer within 8S after it sent the PBGT handover r
equest. And after 8S, since the frame error rate became higher, the device cou
ldn't decode the corresponding neighbor cell. In order to solve the problem o
f slow PBGT handover from the 1800 network to the 900 network, we need to
reduce the value of the Tmicro timer.

rameters
 Pre-processing Parameter
 Description: The survey report contains the large amount (message amount) of Abi
s interface information. Preprocess of the survey report can be transferred to BTS t
o reduce the burden of Abis interface link. After preprocess, BTS averages the surv
ey data of MS by its own, and reports to BSC in a lower frequency. Average reporti
ng period can be two, three or four SACCH multi-frames (480 ms). That is, the freq
uency decreases from the original twice/s to once/2 s, so the message amount of
Abis interface decreases. However, the decrease of message amount still depends
on whether the message length before preprocess is same as that after preprocess.
This parameter determines whether to execute pre-processing or not, and it also
determines the period of pre-processing.
 Reducing the period of pre-processing will greatly impact the handover. It will spe
ed up the handover, as well as increase the times of handover.
 When the pre-processing period is 3, the average window is 4, and the P/N value i
s 2/3, the handover decision will take 9S. When the pre-processing is turned off , t
he average window is 6, and the P/N value is 3/4, the handover decision will take 4.
5S.

rameters
 The related parameters may be adjusted as follows:
Parameters Original Value Adjustment value
Tmicro 8s 5s
Pre-processing window 3 0

rameters
 Summary:
 After the adjustment of related parameters, the problem of slow handover fro
m the Negotiation Building to the Hongyan Primary School was solved.
 Accoring to the site conditions, we can adjust the pre-processing parameter, t
he decision window and the Tmicro timer to ensure the prompt handover and
prevent the call drop.

Inter-MSC Trunk Congestion Leading to Low Ha
ndover Success Rate
 Description:
 One network uses dual bands, 900M is our equipment and 1800 M is Nokia. R
ecently one IBSC was commissioned, kept under the new MSC. Performance s
tatistics shows that handover success rate of this IBSC is low, specifically, its o
utgoing handovers are basically normal, and its incoming handover success ra
te is low. Based on the handover statistics of the cells in this IBSC with low ha
ndover success rate, most failures happen during handovers from Nokia 1800
M to 900M of our company.

ndover Success Rate
 Based on the observation and performance statistics of our MSC, the handov
er failures causes are mainly mchMapCauseErr_M.
 From the failure observation of the core network, we found that when the fail
ure occurs, the MSC-B has already sent MAP － Prep － HO Rsp containing the
handover number to the MSC-A. The MSC-A should send IAM to the MSC-B
according to the handover number, then MSC-B send the ACM to the MSC-A
to indixate that the inter-office trunk is ready. And then the MSC-A will send
HO Cmd to the BSC to inform the BSC to initiate the handover.
 At this time, if MSC-A, due to some reasons, such as trunk congestion, can no
t send the IAM message, the MAP interface timer will time out and release M
AP. MSC-A will not send HO Cmd message, and the handover fails.

ndover Success Rate
 Based on the field test, the inter-MSC trunk between our MSC an
d Nokia MSC are congested, and the traffic volume of each line is
more than 0.9 Erl.
 Thus, it can be concluded that the low inter-MSC handover success rate is cau
sed by the trunk congestion from Nokia MSC to our MSC, leading to acquisiti
on failure of inter-MSC trunk and then handover failure.
 We perform the capacity expansion of the inter-MSC trunk, and t

he traffic volume of every line is reduced and IBSC6 handover suc
cess rate becomes normal.

Contents
 Call Drop
 Handover
 Congestion
 Coverage
 Paging
 Interference
SDCCH congestion caused by group sending SM
S
 Description:
 As shown from the performance report, one site has heavy congestion on the
SDCCH channel. But the TCH traffic volume of the site is not high and the site
is not at the bordering sections of several location areas. We think the SDCCH
congestion may be caused by the huge amount of SMS.

SDCCH congestion caused by group sending SM
S
 At first, we tried the signaling tracing. And the result showed that most of the
CM service requests are SMS.
 Then we conducted CALL TRACE. After we conducted CALL TRACE for two co
ntinuous requests, we found both of them were initiated by the IMSI:4600287
03084110, and the interval between the two requests was very short. So we th
ought the IMSI was group-sending the SMS.
 According to the signaling trace, the cell has initiated 4536 requests (includin
g the calling/called request, the SMS request and data service request) in tota
l during the traced period. The amount of SMS requests was 3454 (including 3
125 SMS requests initiated by that IMSI), and the amount of location update r
equest was 247.
 So we were sure that the SDCCH congestion was caused by the group sendin
g of SMS from the IMSI number.

Serious SD congestion caused by core network
module problem
 Description
 About one third of the cells on 2 iBSC of the XX site had serious SDCCH cong
estion. The cell-level statistics shows that nearly one third of the cells have ser
ious congestion for all the time. The rate of successful paging was decreased f
rom 80% to 50%.

module problem
 Troubleshooting process
 According to our analysis, the data configuration of the cell was normal, the a
larming of the BSC was normal, and the CPU usage was normal. Compared wi
th the core network, the data of the cell was OK. And the load on the A interfa
ce was not increased.
 After checking the basic CS measurement of the cell, we found the amount of
calling /called attempts was small, and most of the attempts were about locat
ion update.
 After analyzing the signaling of the cell, we found that a lot of location updat
es were failed. The handset didin't receive responses after sending the identit
y response. After the T3120 timer timed out,the channel was released. During
this period, the SD channel was occupied for about 20s.
 In mormal location update, the handset will receive the response from the net
work in about 100ms after it sends the identity response:

module problem
 In mormal location update, the handset will receive the response
from the network in about 100ms after it sends the identity respo
nse:
 Since the failed location update occupied the SD channel for lon
g time, serious congestion occurred on the SD channel. Due to th
e 3210 Timer on the handset timed out, the failed location updat
e occupied the channel for 20s.
 After the handset sent the location update request, there were ID
request and ID response between the core network and the hand
set. It means the SCCP layer is OK, but the core network didn't re
spond to the handset.

module problem
 Conclusion
 After troubleshooting, the core network found two modules were in problems.
After the supporting A5/1 encryption algorithms of all the cells were disabled
by the wireless side, the SD congestion was temporarily settled. And the cong
estion problem did not happen after the algorithms was enabled again.

Contents
 Call Drop
 Handover
 Congestion
 Coverage
 Paging
 Interference
Handling the shrinking of BTS coverage
 Description:
 According to the statement from the network optimization engineer of China
Unicom in ZhouKou, the coverage of ZTE's BTSs in some counties shrinked aft
er certain period of operation, thus some originally covered areas became cov
erage holes or areas with weak coverage. This situation has great impact espe
cially for the sub-urban areas, since the sub-urban areas had more omni-direc
tional BTSs, and the distances between the BTSs in sub-urban areas are wider.
The shrinked coverage can easily lead to coverage holes. Therefore, the opera
tor may frequently receive complaint from the subscriber that the signal in so
me area becomes weak.

Handling the shrinking of BTS coverage

 According to the subscriber's complaint, we conducted drive test for the BTS
with serious problem of shrinked coverage. According to our analysis on the
drive test data, the coverage of some BTSs indeed shrinked, especially for tho
se BTSs that had been commissioned for long time.

Problem 1: The coverage of the BTS in FuCaoLou
shrinked badly
 Description
 From the table of project parameters, we found that the BTSs in FuCaoLou To
wn of Taikang County were 40W omni-directional stations with the height of
50m. This kind of BTS generally can cover a distance of 4 km. According to th
e above figure, we can see that the coverage of the BTS (frequency point 124)
in FuCaoLou is too small. The receiving level of the handset decrerases to － 8
5dBm when the handset is 1 km away from the BTS.
 Cause analysis
 We found that the BTS in FuCaoLou had been commissioned for more than 2
years. However, the dust filter of the cabinet had never been cleaned during t
he period. Since lots of dusts were accumulated on the dust filter, the ventilati
on and cooling function of the fan on the cabinet was greatly affected, thus t
he working of the carrier, power amplifier and combiner were affected.

Problem 2: The BTS in Wulikou has different cov
erage in different direction
 Description
 从 From the Rxlev chart, we can see that the BTS in Wulikou has different cove
rage in different direction. The coverage to the east is very samll, about 1 km,
while the coverage to the north-easte reaches 5 km.
 Cause analysis
 There are 2 platforms on the tower of the BTS. This site is shared by the BTSs
of CDMA network and GSM network. The CDMA network was commissioned
earlier, it uses the upper platform, then the omni-directrional antennas of the
GSM network were placed on the lower platform. So some omni-directrional
antennas were obstructed by the iron tower, and the coverage in that directio
n is smaller.

Coverage became weaker due to repeater frequ
ency is inconsistent
 Description:
 A subscriber from Shao Yang city complained that due to the unstable signals
at ShenJiaCun, he couldn't make a call untill he climed to the top of his buildi
ng.

 According to our test at the site, the strength of the signal from the repeater i
s -90dbm and the signal disappears randomly. After several times of dialing t
est, we confirmed the reported problem.
 From the BTS side, we found the equipment was working normally. After quer
ying, we found that the data of the repeater were not updated after the BTS w
as changed from omni-directional to directional. Then the repeater didn't wor
k, and the signal strength became weak.
 After we changed the frequency of the repeater to be the frequency of the sig
nal source, the problem was solved.

Contents
 Call Drop
 Handover
 Congestion
 Coverage
 Paging
 Interference
"The subscriber is not in the service area" caused
by large CRO value
 Description:
 Some subscribers complained that the signal was very weak near the BTS. For
most of the handsets, the signal strength was only 2 grids when the handset
was 500 m away from the BTS. The maintenance engineer said, the signal stre
ngth displayed on the handset was normal, but when the subscriber was calle
d, the calling party got the response "the subscriber is not in the service area".

by large CRO value
 According to our analysis, the above problem of subscriber not in the service
area was caused by "no response to paging". The possible causes are as follo
ws:
1 The system was congested or over-loaded

If the MSC, the Abis interface signaling link, the BSC, the TRX or the wireless interfac
e is overloaded, "no response to paging" may occur.
2 The cell was interferred by radio signal


If the cell is interferred by strong radio signal for a long time, "no response to pagi
ng" may occur.
3 The communication equiment is failed or working unsteadily


If the LAPD link, the uplink or downlink signal from the BTS is poor, “no response t
o paging” may occur.

If the handset has some problem itself, “no response to paging” may occur, and t
here will also be problems when the handset is the calling party.

by large CRO value
4 The BSC has data configuration error

It mainly refers to that the "Cell Module Information Table" is in error. The content
of the table should be in consistency with all the modules of the BSC.
5 The handset was executing other processes, so it didn‘t respond to the pagin
g

It's a coincidence that a new call is inintiated when the location update, SMS, call rel
easing process is not completed. This kind of "no response to paging" cannot be av
oided in the GSM system. In this case, the calling party only needs to redial the num
ber later.
6 The subscriber is indeed not in the service area or the handset is power-off

In this case, "The subscriber is not in the service area" is the correct response from t
he GSM.

by large CRO value
 For the complaint of the signal was very weak near the BTS, the engineer suspecte
d that the RF system and antenna feeder system had problems. But no problem w
as found when the engineer checked the hardwares of the BTS, the RF connection
cable and the antenna feeder system. And the signal was not improved when the
engineer adjusted the pitch angles of the antenna. Then the engineer tested the h
andset and found that the serving cell used by the handset belonged to the neigh
bor BTS in area B. The signal strength of the serving cell was only -85dBm, but the
CRO was set to be 40. So it is very easy for the subscriber to select this BTS. Then t
he level of the serving cell was too low, it was easy to cause "The subscriber is not
in the service area" . After the CRO setting was changed from the background, the
problem was solved.
 Generally, the CRO value should not be too large, especially for the sub-urban are
as. Because the signal received by the MS is depending on the actually received le
vel. If the two cells around the MS have similar C2 value and the actually received
levels are quite different, it is very easy to cause cell reselection, thus lead to the p
roblem of unstable signal when the MS is in idle state.

by cross-location-area cell reselection
 Description:
 The subscribers in one office building complained that they often received th
e response " the subscriber is powered off" or "the subscriber isnot in the serv
ice area" when the signal on the handset of the called party was very good.

 The office buiding is a high-rise building. Most of the complaint a
re from the subscribers on the 10th floor to 13th floor. According
to the observation at 11th floor, the level received by the test ha
ndset is -70dbm to -90dbm. However, the handset detected mult
iple frequencies, including 900M and 1800M. And the signal stre
ngths of different frequencies were quite similar. There were ma
ny 900M frequence points taht belonged to different location are
a. The handset frequently reselected the cell in idle state.

 Cell reselection is needed in the following conditions:+
(1) Great loss of radio path occurs on the current registered cell (C1<=0);
(2) The downlink of current registered cell failed;
(3) The current registered cell is blocked;
(4) According to C2, another cell in the same location area is better than the curr
ent registered cell; Or according to CRH, a cell in another location area in the
selected netrwork is better than the current regitered cell.
(5) The handset has not accessed the current regidtered cell successfully after th
e random access times reached the maximum number broadcasted on the BC
CH.

 When the handset is in idle state, it frequently reselects the cell. If th
e cell reselection is crossing different location areas, a location updat
e will be initiated. After times of dialing tests, we found that “the su
bscriber is not in the service area” may occur if the handset frequen
tly conducts the location update.
 According to the dialing test, some 900M frequence points are from
a BTS that is in different location area. So there are two location area
s for the 900M nertwork. Added by the location area of the 1800M n
etwork, the office building receives signals from 3 different location
areas. So the cross-location-area cell reselection frequently occurs o
n the handset. The number of complaints were significatntly reduced
after we requested the operator to adjust the downtilt angle of the
900M BTS antenna, since the office building cannot receive the signa
ls from that BTS. 。

Contents
 Call Drop
 Handover
 Congestion
 Coverage
 Paging
 Interference
Interference caused by Excessive Strong Back Sig
nals of the Directional Antenna
 Description:
 During the drive test performed in one GSM network optimization process, it
was found that the area which was more than one kilometer away from the sit
e (S122) and should be covered by cell 3 received stronger signals from cell 1.
Cell 1 signals brought severe interference to other sites.

1. The engineers first walked 100 meters away from the site, circled the BTS tower to
test the signals with the MS. and the signals of all directions were found normal.
2.The engineers walked one kilometer away from the site and performed the test. It w
as found that the areas which should be covered by cell 3, was covered by cell 1, a
nd the signals from cell 1 were about 5 dB stronger than that of cell 3.
3. The engineers first suspected that the jumper connection of the antenna system wa
s wrong, and cross connection might exist. They checked the jumper and no probl
em was found.
4. The engineers checked the jumpers of the antenna and found no problem. This pro
blem will not affect the transmission of the TRX and the VSWR, which can not locat
ed by SITEMASTER.
5. Therefore the engineers suspected that the directivity of the directional antenna of
one cell is poor, and the back signals are not shielded. Because the site is space div
ersity, change the TRX/Main antenna with the diversity receiving antenna.

 Then it showed that the directivity of the antenna was poor, the b
ack signals of the antenna were not shielded, which led to the gr
eat transmission strength of the opposite coverage direction of t
he cell.
 Because this cell was one TRX cell, and the power did not deterio
rated through using the combiner. Therefore the areas which sho
uld be covered by cell 1 received better signals from cell 1.
 The antennas of cell 1 had 3 degree depression angle and the tes
t near the site did not show. The areas which should be covered
by cell 2 were not severely affected, because the TRX of cell 2 is b
locked from that of cell 3 by the tower.

Bad KPI of the Cell Caused by External Interferen
ce
 Description:
 In one project, cells such as KBL029 had very poor voice quality, high call drop
rate and high handover failure rate. KPIs were as follows:

 KBL used PGSM as BCCH (105-124), and TCH used EGSM 1*3 frequency hoppi
ng (975-995). Based on TRX measurement, idle interference band of these cell
s were distributed on TCH TRX instead of BCCH TRX, assignment failed and m
ost were on TCH TRX.

ce
 It was decided that the cells with strong interference were the cel
ls marked in red in the following figure:

ce
 Therefore the interference existed in the red areas, and the interf
erence is only on the TCH TRX that used the EGSM. The engineer
s were required to performe a scanning test

ce
 The result shown that the EGSM frequency used by ET was strong
ly interfered externally and the interference power level was abou
t -8 dB.
 The scanning result was submitted to ET, and the government co
nfirmed that it was caused by the military troops of one country
and therefore the problem could not be solved.

Contents
 Call Drop
 Handover
 Congestion
 Coverage
 Paging
 Interference
Long delay in receiving the "recharging is succes
sful" message
 Description
 One subscriber complained that he had to wait for a long time to receive the
"recharging is successful".

sful" message
 Signaling of the core network: the core network releases the CC c
onnection after sending the short message, then it sends the sho
rt mesage, and after sending the short mesage, it releases the RR
connection.

sful" message
 Even if the handset has hanged up, the core network will continue to sen
d the message. After receiving the clear request 12s later, it will release t
he connection. If the sending of short message is failed, the core networ
k will resend the "recharging is successful" when the handset is in Idle st
ate.

sful" message
 Cause for the failure of sending the message for the first time
 From the signaling of the Abis interface, we found that after receiving the "rel
ease complete" message for 10s, the handset sent a "release indication" mess
age to clear the connection. So the sending of "recharging is successful" was f
ailed.
 The handset cleared the connection 10s after receiving the "release complete",
because the T3240 timer of the handset was timed out then.

sful" message
 Judging form the process, we can see the handset will receive the
"recharging is successful" if it receives the CP-DATA message wit
hin 10s.
 The engineer recorded the signaling of the recharging process a
gain. According to the air interface signaling, it takes10s in total f
or the BTS to send the "recharging is successful" to the handset i
n 11 steps.

sful" message
 T3240 was started when the handset released the connection. An
d it was stopped when the handset received the CP-DATA messa
gem T3240. In the signaling, the interval between receiving " rele
ase complete" and "release indication" was 10s, that means the ti
mer was not stopped.
 There are two possible reasons.
 One is that the BTS had not send the CP-DATA message to the handset in tim
e.
 The other one is that the handset may have some problem itself, that it didn't
stop the T3240 timer after it received the CP-DATA message.

sful" message
 Conclusion
 Based on the above analysis, if the handset actively hangs up after the rechar
ging, it cannot receive the CP-DATA message within the time specified by the
T3240 timer, and it will release the connection, so it will not receive "the recha
rging is successful" message. According to the subscriber behavior, most subs
cribers hang up the handset after they hear "the recharging is successful". So
the first time of sending the message is failed.
 So there are two solutions for this problem:

 One is to shorten the message of recharging success, so as to let the total tim
e of message sending + link creation be less than the value of T3240.
 The other one is to change the time for sending the message. The core netwo
rk will send "the recharging is successful" to the handset when the handset is
in idle state after the recharging.

GO - NAST3016 - E01 - 1 GSM Network Optimization Case Analysis 58

Uploaded by

Copyright:

Available Formats

You might also like

GO - NAST3016 - E01 - 1 GSM Network Optimization Case Analysis 58

Uploaded by

Document Information

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

GO - NAST3016 - E01 - 1 GSM Network Optimization Case Analysis 58

Uploaded by

Copyright:

Available Formats

Case Analysis on GSM Networ

 Cause Analysis & Procedure:

© ZTE Corporation. All rights reserved

 After tracing the Abis interface signaling, we found:

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

Parameters Original Value Adjustment value

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

 We perform the capacity expansion of the inter-MSC trunk, and t

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

 Cause Analysis & Procedure:

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

 Cause Analysis & Procedure:

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

2 The cell was interferred by radio signal

3 The communication equiment is failed or working unsteadily

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

 Cause Analysis & Procedure:

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved