10 GSM Case Analysis On GSM Network Optimization

Case Analysis on GSM Network
Optimization
ZTE University
Contents
Call Drop
Handover
Congestion
Coverage
Paging
Interference
Allocation Failure
Severe call drops caused by the illegal user
Description:
z 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 in the daytime. While very few of
them were in the night. So the engineer suspected that
the problem was related with the user behavior.
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 call 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 batteries 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 amount of
call drops in the cell was greatly reduced. After we enabled the
emergency call function later, the call drop problem didn't occur any
more, becasue the user selected another operator's network.
Summary:
z By analyzing the Abis signaling file, we can make
judgement about the call drop problem and find out the
regularity of the problem. The network performance
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 tracing or
analyzing the CDR from the switching side.
Call drops caused by handover failure of the
handset
Description:
z After the equipment been swapped to the GSM network,
one subscriber complained that under the mobile
environment, his call was automatically hanged up
within one minute after connection. The subscriber's
handset is HS-D907 and it worked normally under the
MOT equipment network before the swap. Another
subscriber complained that when he made a call by HS-
D907 on the highway, the call was frequently hanged up
about dozens of seonds after connection. In addition,
the subscriber said the handset never had the above
problem in other places.
handset
z The engineer traced the Abis interface MM signaling from the
switching side.
z When the XX handset is the calling party, it enters the
Conversation state after receiving "connect Ack". Several seconds
later, the BSSAP entity sends a "cbclearcmdEvent" message to the
handset, and the handset automatically hangs up.
z 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 hangs up.
z According to the signaling tracing analysis, the core network makes
the judgement that the connection is actively released by the
wireless side. The releasing reason is 1, and the meaning of this
value is:
1=Radio interface failure(1)
handset
The engineer traced the Abis interface signaling
from the OMCR side.
z After tracing the signaling in the 900/1800 area of Cell 3
and conducting call trace by MA10 software, we found
that the handset released the channels after the
handover failure, and the handovers were all
simultaneous handovers
z During the conversation, every time when the handover
command was initiated, the handset pointed to "full rate
or half rate version 3", then the handover was failed.
handset
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
supported voice version 1 and 3, voice version 2
was not selected.
Steps:
z 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
switching side. After that, the automatic hang up never
happened again during the dialing test.
handset
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 information,
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
Allocation Failure
Slow handover caused by improper handover
parameters
Description:
z During the drive test, the engineer found that the handover
from the Negotiation Building (covered by the 1800 network)
to the Hongyan Primary School (covered by the 900 network)
was too slow.
z The testing vehicle moved from the north to the south, and
the MS occupied the Cell5 (CI10355BCCH700) of the
Negotiation Building for conversation. When the vehicle
moved on, the MS gradually entered the coverage of G1 cell
of Hongyan Primary School (CI11551, BCCH115), and
the level of the serving cell gradually turned to be -86db and
became lower and lower. From the table, we can see that the
level of the G1 cell was -50db, but the serving cell was not
switched to the G1 cell of the school. So the level turned to
be worse, and the quality also became worse.
parameters
Tmicro timer
z 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 request. And
after 8S, since the frame error rate became higher, the
device couldn't decode the corresponding neighbor cell.
In order to solve the problem of slow PBGT handover
from the 1800 network to the 900 network, we need to
reduce the value of the Tmicro timer.
parameters
Pre-processing Parameter
z Description: The survey report contains the large amount (message
amount) of Abis interface information. Preprocess of the survey report
can be transferred to BTS to reduce the burden of Abis interface link.
After preprocess, BTS averages the survey data of MS by its own, and
reports to BSC in a lower frequency. Average reporting period can be
two, three or four SACCH multi-frames (480 ms). That is, the
frequency 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.
z Reducing the period of pre-processing will greatly impact the handover.
It will speed up the handover, as well as increase the times of
handover.
z When the pre-processing period is 3, the average window is 4, and the
P/N value is 2/3, the handover decision will take 9S. When the pre-
processing is turned off , the average window is 6, and the P/N value
is 3/4, the handover decision will take 4.5S.
parameters
The related parameters may be
adjusted as follows:
Original
Parameters Value Adjustment value
Tmicro 8s 5s
Pre-processing window 3 0
parameters
Summary:
z After the adjustment of related parameters, the problem
of slow handover from the Negotiation Building to the
Hongyan Primary School was solved.
z Accoring to the site conditions, we can adjust the pre-
processing parameter, the decision window and the
Tmicro timer to ensure the prompt handover and
prevent the call drop.
Inter-MSC Trunk Congestion Leading to Low
Handover Success Rate
Description:
z One network uses dual bands, 900M is our equipment
and 1800 M is Nokia. Recently one IBSC was
commissioned, kept under the new MSC. Performance
statistics shows that handover success rate of this IBSC
is low, specifically, its outgoing handovers are basically
normal, and its incoming handover success rate is low.
Based on the handover statistics of the cells in this
IBSC with low handover success rate, most failures
happen during handovers from Nokia 1800M to 900M of
our company.
z Based on the observation and performance statistics of our
MSC, the handover failures causes are mainly
mchMapCauseErr_M.
z From the failure observation of the core network, we found
that when the failure occurs, the MSC-B has already sent
MAPPrepHO 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.
z At this time, if MSC-A, due to some reasons, such as trunk
congestion, can not send the IAM message, the MAP
interface timer will time out and release MAP. MSC-A will not
send HO Cmd message, and the handover fails.
Based on the field test, the inter-MSC trunk
between our MSC and Nokia MSC are congested,
and the traffic volume of each line is more than 0.9
Erl.
z Thus, it can be concluded that the low inter-MSC
handover success rate is caused by the trunk
congestion from Nokia MSC to our MSC, leading to
acquisition failure of inter-MSC trunk and then handover
failure.
We perform the capacity expansion of the inter-
MSC trunk, and the traffic volume of every line is
reduced and IBSC6 handover success rate
becomes normal.
Contents
Call Drop
Handover
Congestion
Coverage
Paging
Interference
Allocation Failure
SDCCH congestion caused by group sending
SMS
Description:
z 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
SMS
z At first, we tried the signaling tracing. And the result
showed that most of the CM service requests are SMS.
z Then we conducted CALL TRACE. After we conducted CALL
TRACE for two continuous requests, we found both of them
were initiated by the IMSI:460028703084110, and the
interval between the two requests was very short. So we
thought the IMSI was group-sending the SMS.
z According to the signaling trace, the cell has initiated 4536
requests (including the calling/called request, the SMS
request and data service request) in total during the traced
period. The amount of SMS requests was 3454 (including
3125 SMS requests initiated by that IMSI), and the amount of
location update request was 247.
z So we were sure that the SDCCH congestion was caused by
the group sending of SMS from the IMSI number.
Serious SD congestion caused by core
network module problem
Description
z About one third of the cells on 2 iBSC of the XX site had
serious SDCCH congestion. The cell-level statistics
shows that nearly one third of the cells have serious
congestion for all the time. The rate of successful
paging was decreased from 80% to 50%.
Troubleshooting process
z According to our analysis, the data configuration of the cell
was normal, the alarming of the BSC was normal, and the
CPU usage was normal. Compared with the core network,
the data of the cell was OK. And the load on the A interface
was not increased.
z 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 location update.
z After analyzing the signaling of the cell, we found that a lot of
location updates were failed. The handset didin't receive
responses after sending the identity response. After the
T3120 timer timed out,the channel was released. During this
period, the SD channel was occupied for about 20s.
z In mormal location update, the handset will receive the
response from the network in about 100ms after it sends the
identity response:
In mormal location update, the handset will receive the
response from the network in about 100ms after it
sends the identity response:
Since the failed location update occupied the SD
channel for long time, serious congestion occurred on
the SD channel. Due to the 3210 Timer on the
handset timed out, the failed location update 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 handset. It means the SCCP
layer is OK, but the core network didn't respond to the
handset.
Conclusion
z 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 congestion problem did not happen
after the algorithms was enabled again.
Contents
Call Drop
Handover
Congestion
Coverage
Paging
Interference
Allocation Failure
Handling the shrinking of BTS coverage
Description:
z According to the statement from the network
optimization engineer of China Unicom in ZhouKou, the
coverage of ZTE's BTSs in some counties shrinked
after certain period of operation, thus some originally
covered areas became coverage holes or areas with
weak coverage. This situation has great impact
especially for the sub-urban areas, since the sub-urban
areas had more omni-directional BTSs, and the
distances between the BTSs in sub-urban areas are
wider. The shrinked coverage can easily lead to
coverage holes. Therefore, the operator may frequently
receive complaint from the subscriber that the signal in
some area becomes weak.
Handling the shrinking of BTS coverage

z 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 those BTSs that had been commissioned
for long time.
Problem 1: The coverage of the BTS in
FuCaoLou shrinked badly
Description
z From the table of project parameters, we found that the
BTSs in FuCaoLou Town 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 the
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 85dBm when
the handset is 1 km away from the BTS.
Cause analysis
z 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 the period.
Since lots of dusts were accumulated on the dust filter, the
ventilation and cooling function of the fan on the cabinet was
greatly affected, thus the working of the carrier, power
amplifier and combiner were affected.
Problem 2: The BTS in Wulikou has different
coverage in different direction
Description
z From the Rxlev chart, we can see that the BTS in
Wulikou has different coverage 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
z 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
direction is smaller.
Coverage became weaker due to repeater
frequency is inconsistent
Description:
z 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 building.
z According to our test at the site, the strength of the signal
from the repeater is -90dbm and the signal disappears
randomly. After several times of dialing test, we confirmed
the reported problem.
z From the BTS side, we found the equipment was working
normally. After querying, we found that the data of the
repeater were not updated after the BTS was changed from
omni-directional to directional. Then the repeater didn't work,
and the signal strength became weak.
z After we changed the frequency of the repeater to be the
frequency of the signal source, the problem was solved.
Contents
Call Drop
Handover
Congestion
Coverage
Paging
Interference
Allocation Failure
"The subscriber is not in the service area"
caused by large CRO value
Description:
z 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 strength displayed on the handset was
normal, but when the subscriber was called, the calling
party got the response "the subscriber is not in the
service area".
zAccording 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 follows:
1 The system was congested or over-loaded
If the MSC, the Abis interface signaling link, the BSC, the TRX or the
wireless interface 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 paging" 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 to paging" may occur.
If the handset has some problem itself, "no response to paging" may
occur, and there will also be problems when the handset is the calling
party.
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 paging
It's a coincidence that a new call is inintiated when the
location update, SMS, call releasing process is not
completed. This kind of "no response to paging" cannot be
avoided in the GSM system. In this case, the calling party
only needs to redial the number 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 the GSM.
For the complaint of the signal was very weak near the BTS, the
engineer suspected that the RF system and antenna feeder system
had problems. But no problem was 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
handset and found that the serving cell used by the handset belonged
to the neighbor 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 the 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 areas. Because the signal received by the MS is depending
on the actually received level. 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 problem of
unstable signal when the MS is in idle state.
caused by cross-location-area cell reselection
Description:
z The subscribers in one office building complained that
they often received the response " the subscriber is
powered off" or "the subscriber isnot in the service 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 are from the subscribers on the 10th
floor to 13th floor. According to the observation at
11th floor, the level received by the test handset is
-70dbm to -90dbm. However, the handset
detected multiple frequencies, including 900M and
1800M. And the signal strengths of different
frequencies were quite similar. There were many
900M frequence points taht belonged to different
location area. 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 current 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 the random access times reached the
maximum number broadcasted on the BCCH.
When the handset is in idle state, it frequently reselects the cell.
If the cell reselection is crossing different location areas, a
location update will be initiated. After times of dialing tests, we
found that "the subscriber is not in the service area" may occur if
the handset frequently 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 areas for the 900M nertwork. Added by the location
area of the 1800M network, the office building receives signals
from 3 different location areas. So the cross-location-area cell
reselection frequently occurs on 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 signals from that
BTS.
Contents
Call Drop
Handover
Congestion
Coverage
Paging
Interference
Allocation Failure
Interference caused by Excessive Strong
Back Signals of the Directional Antenna
Description:
z 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 site (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 was found that the areas which should be
covered by cell 3, was covered by cell 1, and 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 was wrong, and cross connection might exist. They
checked the jumper and no problem was found.
4 The engineers checked the jumpers of the antenna and found no
problem. This problem will not affect the transmission of the TRX and
the VSWR, which can not located 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 diversity, change the TRX/Main
antenna with the diversity receiving antenna.
Then it showed that the directivity of the antenna was poor,
the back signals of the antenna were not shielded, which
led to the great transmission strength of the opposite
coverage direction of the cell.
Because this cell was one TRX cell, and the power did not
deteriorated through using the combiner. Therefore the
areas which should be covered by cell 1 received better
signals from cell 1.
The antennas of cell 1 had 3 degree depression angle and
the test 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 blocked from that of cell 3 by the tower.
Bad KPI of the Cell Caused by External
Interference
Description:
z 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:
z KBL used PGSM as BCCH (105-124), and TCH used
EGSM 1*3 frequency hopping (975-995). Based on
TRX measurement, idle interference band of these cells
were distributed on TCH TRX instead of BCCH TRX,
assignment failed and most were on TCH TRX.
Interference
It was decided that the cells with strong interference
were the cells marked in red in the following figure:
Interference
Therefore the interference existed in the red areas, and the
interference is only on the TCH TRX that used the EGSM. The
engineers were required to performe a scanning test
Interference
The result shown that the EGSM frequency used
by ET was strongly interfered externally and the
interference power level was about -8 dB.
The scanning result was submitted to ET, and the
government confirmed 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
Allocation Failure
Long delay in receiving the "recharging is
successful" message
Description
z One subscriber complained that he had to wait for a
long time to receive the "recharging is successful".
successful" message
Signaling of the core network: the core network releases the CC
connection after sending the short message, then it sends the short
mesage, and after sending the short mesage, it releases the RR
connection.
successful" message
Even if the handset has hanged up, the core network will continue to send
the message. After receiving the clear request 12s later, it will release the
connection. If the sending of short message is failed, the core network will
resend the "recharging is successful" when the handset is in Idle state.
successful" message
Cause for the failure of sending the message
for the first time
z From the signaling of the Abis interface, we found that
after receiving the "release complete" message for 10s,
the handset sent a "release indication" message to
clear the connection. So the sending of "recharging is
successful" was failed.
z The handset cleared the connection 10s after receiving
the "release complete", because the T3240 timer of the
handset was timed out then.
successful" message
Judging form the process, we can see the handset
will receive the "recharging is successful" if it
receives the CP-DATA message within 10s.
The engineer recorded the signaling of the
recharging process again. According to the air
interface signaling, it takes10s in total for the BTS
to send the "recharging is successful" to the
handset in 11 steps.
successful" message
T3240 was started when the handset released the
connection. And it was stopped when the handset
received the CP-DATA messagem T3240. In the
signaling, the interval between receiving " release
complete" and "release indication" was 10s, that
means the timer was not stopped.
There are two possible reasons.
z One is that the BTS had not send the CP-DATA
message to the handset in time.
z 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.
successful" message
Conclusion
z Based on the above analysis, if the handset actively hangs
up after the recharging, 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
recharging is successful" message. According to the
subscriber behavior, most subscribers 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:
z One is to shorten the message of recharging success, so as
to let the total time of message sending + link creation be
less than the value of T3240.
z The other one is to change the time for sending the message.
The core network will send "the recharging is successful" to
the handset when the handset is in idle state after the
recharging.

10 GSM Case Analysis On GSM Network Optimization

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

10 GSM Case Analysis On GSM Network Optimization

Încărcat de

Drepturi de autor:

Formate disponibile

Case Analysis on GSM Network

Cause Analysis & Procedure:

Cause Analysis & Procedure:

According to the dialing test, some 900M frequence points are

S-ar putea să vă placă și