Sie sind auf Seite 1von 2

Hi,

This is a very comman problem. It's 'coz of multiple reasons. See any call is basically a circuit or
channel. I.e:
Call(Circuit made of this call) =

TRX-TS,KSW-TS,GPROC-TS,TS-on the E1 port at site ==> TS-E1 port at BSC --> ksw-TS-> TS at E1
port going towards transcoder ==> ts- e1 transcoder-> KSW-TS ==> MSC E1 Pool (physical cables).

[
TS = time slot / channel of trx or ksw or gproc or E1 link.

gproc= proccessor at site,bsc,xcdr.

ksw= kilo port switch== multiplexer high way, distributing the ch/TS to/from E1 port to their correct
destination(tS/CH on E1 port, trx, gproc .). It is inside site, BSC, transcoder.

E1= 32(30) 64kbps channels (=2Mbps) port. It is a serial to parallel - wise versa converter.

]

So problem could be at any of these parts of the complete circuit.

CIRCUIT = RCI + CIC

RCI= trx-ts,site e1 etc. radio part.
CIC= bsc to msc via trascoder.

But generally you find problems in :-

1) Hardware problem at site-bts.
OR
2) E1 link(32 chs/ TS) cross connection at any of these interface.



1:- Hardware problem:- E.g: In motorola system, we get RCI Alarms for one/more TS of one/more
TRX. This indicates us that we have "mute" problem. The problem could be at any of above.
But we try to reset the trx.
If multiple such alarm comes, & if there is a common factor , e.g a common E1 link(port), we try to
reset this MMS(MSI) -E1 port.
This may clear the ALARM; BUT wait if the alarm reccurs(i.e. when the same circuit being used
again), means the problem still exists.

If by analysis we are pretty sure we try to replace the faulty dev(trx or e1-port).

2:- TRANSMISSION GUY PROBLEM:- The links(E1-32 chns) might have been cross-connected, means-
call-circuit of one goes to other. This's totally meaning less hence no-audio problem.

Confirm which is the ch/ts of which E1. Ask the transmission team to check at these interfaces. Site-
ddf, bsc-ddf, msc-ddf. DDF=distribition frame(like cable hub- a mess!).

You can Also do drive test of the area to confirm the cells, trx, cics with this problem.

Also you can enable call-trace (CTP) on the affected area(during busy hour), hoping you capture the
faulty circuit.
!!But one warning if you enable a BSC-Level trace for say 1/2 hour without setting maximum calls, a
BSC may be making more than 5000 calls per half hour. Associated ctp huge data
transfer&proccessing from BSC -TO-OMC, might make the BSP(Master proceessor at BSC utilised
100%) -ineffect loading the BSC & STATS not coming in the OMC. Or worse BSC proccessor getting
reset= BSC getting reset ===> YOU ARE FIRED.

Das könnte Ihnen auch gefallen