Very low traffic !!!!

[justdream]

Experts,
I've in my network cells with very low daily traffic like 0.003 Erlang/day

Which parameters? I should check and optimize...

[isha]

hi,
which network are u working on, ?
check layer thresholds of surrounding sites, prob they'll be carrying traffic.

Experts,
I've in my network cells with very low daily traffic like 0.003 Erlang/day

Which parameters? I should check and optimize...

[kamy]

mostly the problems come from hardware, esp baseband processing unit or channel processing unit you should check it first. another can be interference. In my network(cdma) we faced this problems. there are some causes such as feeder, antenna, filters...
you should swap cards between sectors (the normal and abnormal) first and keep monitoring, i think

[telwind]

another problem come from parameter is set wrong. field test will show all call failures.

[ash_or]

1. Check Cell ID in Core, create or not
2. Check database parameter, compare with other cell with similar type.
3. Check HW and Database
4. Check statistik any attempt or not
5. Check layering and neighbouring

[byron]

Are you using E******* BSC/MSC??
1. Check HCS, LAYERTHR, ACCMIN.

what is the usage of the cell in peak hour?

[ludali]

Hi,

I think before deciding on whether hardware (alarms, loose connections, etc) or TX issues are a reason for this recorded low traffic, u may need to tell if there are signs subscribers are available to generate more traffic than this.

The easy way for you to do this is fby irst checking counters and KPI's on accessibility to tell on how many attempts are there and out of which which proportion is successful and/or failure.

With too high attempts failing, it's possible there are problems and you'll need to start assessing ur system for alarms and radio parameters. Otherwise if most attempts get through successfully, it means that's all the traffic your subscribers can generate in that location and more marketing will be needed to boost up your business.

Cheers,

Ludali

[oswe]

We had that problem "sleeping site " we used to call it...
the only way to know was through customer's complain.
No RRC nor RAB failure was detected (nor even attempts) that's why we didnt notice that bloddy site....
but if you see the erlangs month before you can see the starting point of the problem.
no one identified the real cause... it seems to be hw/sw problem altogether.

regards.

[s52d]

With rapid development (new features, HSPA+, EDGE EVO etc..) and
cost saving in test&verification: we have bugs in the SW.
Also, some operators change parameters: it is quite likely for piece of code
to execute for the first time in my network due to unique parameter configuration never
tested before.

So, we never trust our system to work OK.
We monitor stats: if we notice strange behaviour, not easily correlated with alarms,
then our first step is restart.
This helps often - and it is much faster as sending TEMS team out.

If this fails, and we can not find obvious reason:
- maybe stats are wrong: test with different counters and traces
- check and recheck parameters
- test for external interference (oscilating repeaters, hanging terminals, TV preamplifiers, jammers ...)
- test GPEH and IuB/Abis traces
- check with call center/customer complains
- restart transport (deleta/configure IuB/Abis path again)
- test clock/sync
- swap HW boards
- downgrade SW one release
- swap antenna feeders: does problem move to another cell?

If all this fails, it is time for woodoo magic!
- call in vendor to do their detailed analysis
- swap whole transport/adio HW

I recall one crazy Node-B: we just moved all boards to different sites and they worked fine.
They just hate to be together in same cabinet. Probably tolerances on some bus timings?

Twice I found GSM cell transmitting with wrong frequency: actual ARFCN was 10,
while it announced it is 13 in system messages. No calls, no incomming handovers....'
Found with BA-list recording, changing BCCH/BSIC to another value and back helps.

How about GSM cell with no system information 6 (or 5)?
Calls could be started in the cells, and handovers out were OK.
Incomming handovers were OK.
Just calls comming in with handovers could not go out same way, and they were dropped.

We like those cases: makes our job fun, and breaks boring routine.

BR
s52d

We had that problem "sleeping site " we used to call it...
the only way to know was through customer's complain.
No RRC nor RAB failure was detected (nor even attempts) that's why we didnt notice that bloddy site....
but if you see the erlangs month before you can see the starting point of the problem.
no one identified the real cause... it seems to be hw/sw problem altogether.

regards.

[frog96]

Following these steps below:
1. Checking data defined in BSC/RNC
2. Checking data defined in MSC.
3. Checking power parameters.
4. Checking other parameters: layer, acc ...