bo68-100407 sdcch kpi location update problem @ 07abr10

7/28/2019 BO68-100407 SDCCH KPI Location Update Problem @ 07Abr10

1/12

SDCCH Access KPI ProblemRamdom Location Update Increase

07-April-2010


2/12

SDCCH Access KPI drop for one or more hours for a BTS randomly (KPI drop more than 20%

Some times drop more than 60 % )

It happen in all BSC6000 and BSC32.it happen at any hour with low or high traffic in three sector of the BTS at same time

Problem has increase in last two months but it is happening from more than one year ago

There are not congestion in SDCCH Channels at that hours

It is not consequence of recent BTS and BSC Software Upgrade because it continue happening

after and before upgrades.

Fail is random in time, so there are not high KPI BSC impact per hour because problem occur at

different hours at different days in different BTS but KPI in BTS is bad during these hours

There are not BTS alarms at these hours

Channel Request amount for MOC and MTC and traffic are normal at that hour, so traffic is

normal for some users at these cells during KPI problem.

Channel Request amount for Location Updates Increase dramatically (but why increase up to

1000%? And MOC/MTC does not increase ?) . It looks like there is some problem in location

upgrade procedure, but randomly. Some examples for this problem are not border LAC sectors .Problem happens in rural and urban

areas or isolated BTS, so it is not a coverage or border LAC ping pong problem.

This problem can be causing Paging loosing because MS are doing locations update for so many

times . There are many client who claim that call can not completed because target user in call is

power off, but really it was not power off according with client claim descriptions

It is not happening in 3G Network for periodic registration, so it is just 2G problem.

Problem Description and some clues found until now


3/12

% SDCCH Access vs SDCCH Request Times x Service Type

EXAMPLE: Aranjuez

Location Update

Problem (All three

Sectors)All cases location

Update (green line)

increase more than

1000%. And KPI SDCCH

Access decrease (Purple

line)


4/12


OTHER EXAMPLE:

BTS Lazaro Location

Update Problem (All

BTS Sectors)Febrero-Abril


5/12


Octubre-Diciembre 09

Febrero-Abril

Other Example:

BTS GAB Update

Problem (All BTS

Sectors)


6/12

RBS TAR1A

BSC32 TARIJA

RBS VMEABSC6000 LA PAZ

Other Example: BSC6000 VMEA

History from Jan10 (3 Months)

Problem Has Increase 1 Month ago

Other Example: BSC32 TAR1

History from Jan10 (3 Months)

Problem Has Increase 2 Month ago


7/12

RBS TARA

BSC32 TARIJA

Other Example: BSC32 TAR

History from Jan10 (3 Months)Problem Has Increase 3 Month ago


8/12

SDCCH ACCESS BSC6000SCZ2 x Sector . EXAMPLE for a Cluster

Other Example: All BTS from a cluster

History from two weeks. All Cluster has

same behaviour

Problem Happen randomly for almost all

BTS at different days and different hours


9/12

RBS SRO Santa Rosa

BSC6000 SCZ2

June-September 09

Other Example: SRO

Last Two Weeks

BTS SRO

Six Months (Last Year)


10/12

BTS SRO Santa Rosa BSC6000 SCZ2History for 3 Months just between 1am y 7am morning. Jan-Apr10.

So,it happen during not peak hours too


11/12

* RBS SRO Santa Rosa BSC6000 SCZ2 Same behaviour in A,B,C* No alarmas, no sdcch Congestion no drop calls. Traficc normal

* Rural Isolate Site .No interacion with other cellls

* Mobile Originating and terminating calls (MOC, MTC) are OK,

(red and blue lines) but Location Update increase about 1000%

for some hours and SDCCH Accesability decrease Green vs

Purple Line


12/12

There is a problem in location update (there are not geographical, cluster, BTS model or time

patterns for failure). It is random ant it has been increasing in last two months.

Huawei has a current Urgent ticket form TIGO some weeks ago, because clients claims that some

times theirs MS looks like it were power off when people call them, but MS is really ON at that

moment. So, this location update situation could be related with this issue , because it is know that

MS can not be located by paging message when it is executing a location update.

It is a General 2G Network Problem. Period Registration in 3G are normal.

Making end to end 2G MS traces could be difficult to reproduce the problem, because call trace

have to be in idle state, and periodic registration in 2G is each 4 hours and all BTS doesnt fail every

day but just some hours randomly. But Huawei can propose any other way to do it.

We recommend continues finding out in details in BSC, MSC, HLR counters for signalink in 2G

location update procedure in order to find more clues about random failures of location update

We will be continuing finding out together with Huawei about this problems but it is important to

get Head Quarter Huawei support for this situation.

Some Brand of 2G MS is not discarded yet, but this theory is very difficult to support because

claims come from different brand (alcatel, Sony Ericsson, Nokia, etc)

Resume until now and suggestions

bo68-100407 sdcch kpi location update problem @ 07abr10

Documents