PDA

View Full Version : Excessive TCH interference



harrypotter
2011-07-10, 01:25 PM
Does anyone experienced an Excessive TCH intereference alarm in NSN 2G? Please share your resolution.

kilisuci_kdr
2011-07-10, 02:48 PM
This alarm 7744 is inform us about there were interference (internal or external).
1. If this alarm only appear in several TRx so big problem is internal interference can came from TRx problem and you can change it.
2. If this alarm occur in BCCH only, probably it has co channel.
3. But if this alarm appear in many TRx in that sectors and sometimes followed by 7745 majority is because of external interference.
Some information about caused external interference can also check from statistic counter UL-interference (>1,2).
Also you can check from ND.190 that show us hourly condition of the interference level.

Rgds,
-SC-

adewijaya
2011-07-10, 06:40 PM
Interference level in cell = 100x (1- -------------------------------------------------------------------- ) %
sum(ave_idle_f_TCH_1/res_av_denom4+ ave_idle_f_TCH_2/res_av_denom5+ ave_idle_f_TCH_3/res_av_denom6+ ave_idle_f_TCH_4/res_av_denom7+ ave_idle_f_TCH_5/res_av_denom8)

If there are more than 95-97% of calls out of band 1, the cell is suffering form quality problem due to interference. Check the following possible reason :
1 Is it In-band Interference? Check from frequency plan .If it is not this reason, go to 2.
2 Is it External Interference? Check by drivetest or spectrum Analyzer. If it is not, go to3.
3 Is there receiver faulty? Check the alarm history .If it is not, go to .4.
4 Is there TRX faulty? Check the alarm history. If it is not this reason,go to 5

Once interference source has been identified then send the job to system planning to retune frequency and / or reconfiguration.

5. Check the average downlink signal strength vs. the average timing advance, for evidence of coverage problem that you can use report 213. If the bad coverage is possible for call problem, send a job to system planning for a required new site or reconfiguration of existing sites. (To consider signal level and quality problem associated with poor coverage) . If not go to 6
6. Check hardware alarms for any hardware problems that may be affecting the TRX, such as faulty timeslot etc. If there are any hardware alarms (the last topic in report 213 is the alarm occurring inthat on specify time, or use alarm monitoring in NMS2000), check the manual for steps to solve the problem. If not go to 7


7. Check the drop reason (report 160) .If they drop due to radio failure in handover or A-if failure in handover, check on those cells it most likely to be directed retry neighbors by analyzing a coverage plot or drivetest .Is it a coverage problem ? If it is, run observation to obtain further information. If not go to 8

Ratio of the TCH call drops to started calls, (call re-est. is not compensated) =
sum(a.tch_radio_fail+a.tch_rf_old_ho+a.tch_abis_fail_call+a.tch_abis_fail_old+
a.tch_a_if_fail_call+ a.tch_a_if_fail_old+ a.tch_tr_fail+ a.tch_tr_fail_old+
a.tch_lapd_fail+ a.tch_bts_fail+ a.tch_user_act+ a.tch_bcsu_reset+
a.tch_netw_act+a.tch_act_fail_call)
100 –100* ----------------------------------------------------------------------------------------------------------- %
sum(a.tch_norm_seiz) ;(normal calls)
+ sum(c.msc_i_sdcch_tch+c.bsc_i_sdcch_tch+c.cell_sdcch_tch) ;(DR calls)
+ sum(a.tch_seiz_due_sdcch_con) ; FACCH call setup calls


8. If the drop dues to A-bis failure, check hardware alarms for any hardware problems that may be affecting the site. Checks alarm monitoring for that site or use network doctor report 213.If there are any hardware alarms, check the manual for steps to solve the problem. If they are no hardware alarm, Check the transmission related. E.g. : Synchronization in BSC and BTS by command:Check the clock unit in BSC : ZDRI; (Otherwise reset the BTS or send the job to maintenance to investigate the site and check the antenna system)

9. If drop call is not from A-bis failure, check for congestion on SDCCH by report 130. Verify thathow many SDCCHs are defined for the number of TCH and also check whether the cell is on aLocation area boundary.
sum(a.SDCCH_busy_att)
Blocking on SDCCH = 100* --------------------------------------------- %
sum(a.SDCCH_seiz_att)

plaosan
2011-07-14, 10:05 AM
7744 EXCESSIVE TCH INTERFERENCE

Meaning

During the supervision period, the TCH time slot has suffered
excessive interference in idle mode that is equal to or higher than
the operator-defined alarm threshold percentage. That is, the
interference in the time slot has lasted longer than is acceptable.
The interference level classified as excessive is defined by the
operator. The alarm is used to supervise the BTS traffic capacity.
Supplementary information fields

1-8 the percentage (per each TRX time slot) that the channel has
spent in excessive interference during the supervision period.
The number is a hexadecimal, 0 - 64 %.
If the time slot is not a TCH time slot, the value is 0

9 the threshold level of excessive interference. The values are
0, 1, 2, 3 and 4

10 the TCH channel's alarm threshold percentage of the time spent
in excessive interference, 1 - 100 %. The alarm is generated if
at least one TRX time slot reaches the threshold
Instructions

Measure the interference level on the traffic channel in question.

Check that the parameters affecting the alarm are reasonable.
MML command EEO outputs the radio network supervision parameter values,
EEN command modifies the parameter values.

Parameters, with their default values, affecting the alarm:
ZEEN:HIFSHR= TCH interference level threshold value (50 %)
HIFLVL= excessive interference level threshold value (4)
PRDHIF= TCH interference supervision measurement (120 min)
Cancelling

Do not cancel the alarm. The system cancels the alarm automatically
when the fault has been corrected.

pater0
2011-07-14, 07:53 PM
Mate, run a ZERO command and check the I-level column. These should all show "0" for all good timeslots on each TRX. If a couple show "1" it should still work OK, but "3" or "4" are bad and indicate a problem.
If you see these problem timeslots all one a single TRX, try giving it a reset. If this doesn't work then get a field engineer to swap the TRX with another TRX on the same sector. If the fault moves then the TRX is faulty and will need to be replaced. If not then you possibly have a real source of interference. Occasionally you may get problems only on the half of the timeslots of a TRX (e.g 0,1,2,3 or 4,5,6,7). In this case the DSP may be faulty.
Run a 196 report if you have access to NSN reporting suite and this will give you an idea of when the interference is occurring. I've seen cases that only happened during shopping hours. After some intensive field testing we found it was caused by the "shoplifting beeper alarms" in a nearby clothing store which were transmitting in an adjacent band.
Note that you can also view these timeslot I-levels in real-time using Service Terminal.

adewijaya
2011-07-14, 08:02 PM
Mate, run a ZERO command and check the I-level column. These should all show "0" for all good timeslots on each TRX. If a couple show "1" it should still work OK, but "3" or "4" are bad and indicate a problem.
If you see these problem timeslots all one a single TRX, try giving it a reset. If this doesn't work then get a field engineer to swap the TRX with another TRX on the same sector. If the fault moves then the TRX is faulty and will need to be replaced. If not then you possibly have a real source of interference. Occasionally you may get problems only on the half of the timeslots of a TRX (e.g 0,1,2,3 or 4,5,6,7). In this case the DSP may be faulty.
Run a 196 report if you have access to NSN reporting suite and this will give you an idea of when the interference is occurring. I've seen cases that only happened during shopping hours. After some intensive field testing we found it was caused by the "shoplifting beeper alarms" in a nearby clothing store which were transmitting in an adjacent band.
Note that you can also view these timeslot I-levels in real-time using Service Terminal.

follow my step above, all problem will cleared ;) related to Interference both UL or DL

bobe868
2011-07-18, 02:53 PM
Most of our excessive TCH interference has been due to intermod or external interference.
We have many devices being bought and used in this country that broadcast across our uplink band.
As stated check to see if its just affecting one frequency/trx or multiple in the sector.
If you have a spectrum analyser check your uplink band to see if there is external interference or intermod. Intermod should worsen with traffic.
If you suspect intermod, turning off the trxs should make the intermod disappear on your spec an'r.
I always connect the spec an'r to an output on your rx multicoupler/amp..
See if the I levels increase with site traffic..:)

harrypotter
2011-07-18, 05:22 PM
Can you please provide procedures on how to do this?

adewijaya
2011-07-18, 06:30 PM
Can you please provide procedures on how to do this?

What kind procedure? i already state above how to do it

Yoda
2011-07-23, 06:29 AM
Harry Potter are you familiar with the use of Spectrum Analysers, and if so what kind of instrument do you have. Is the equipment concerned Talk family or Ultrasite?:)