LOOP TEST FAILED

What is LOOP TEST FAILED ?

Its is TS/TRC (Transcoder) related alarm, every single TRX having 8 TS (Time Slot) and all TS are using
Transcoder device. So Particular TS is not performing LOOP TEST with Transcoder device. This alarm is
classified as a Major alarm (Alarm class: A2)
What is the Impact ?
It is minor service impact alarm as that particular TS having failed to LOOP TEST with Transcoder. Means
that this TS is unable to carry traffic. Remember a single TS can handle a single subscriber.
What is the reason for raising this alarm ?
There are having a certain time interval, an Automatic LOOP TEST is performing for testing the traffic
carrying capacity between TS and Transcoder devices. if an automatic loop test of the traffic carrying
capabilities has failed then "LOOP TEST FAILED" alarm will be Generate. Also this Alarm may arise by
Transmission or BSC/TRC hanging in RBLT devices.
How to analysis this problems ?
By running this command you will get the all major alarms of all sites. Find out LOOP TEST FAILED alarm.
allip:acl=a2;
You can get this alarm by giving bellow two commands also.
For Getting TG from CELL, Here cell id is KT53541!
rxtcp:moty=rxotg,cell=kt53541;
For getting MO fault on TG-427, TG-427 belongs to KT53541
rxasp:mo=rxotg-427;
For checking the MO(TRX-427-1) status to identify the TS problem, here
RXOTS-427-1-0 NOOP BLO it indicates TS having faults. Need to troubleshoot
rxmsp:mo=rxotrx-427-1 ,subord;
How to Solve the Problem ?

Give following command to block the TS. Here TS RXOTS-427-1-0 NOOP BLO
rxbli:mo=RXOTS-427-1-0;
Giving manual TRC-BTS LOOP TEST for checking the results whether the test is successful or not. if the
test is successful. Then give below two commands
rxlti:mo=RXOTS-427-1-0;
For testing MO (RXOTS-427-1-0) whether any faults is indicating or not. Here shows NO FAULT
INDICATIONS. Means that no fault persisting
rxtei:mo=RXOTS-427-1-0;
Give following command to deblock the TS.
rxble:mo=RXOTS-427-1-0;
Now you can run following commands to check the problem is still persisting of not. As per the print out no
problem is persisting.
rxmsp:mo=rxotrx-427-1 ,subord;
rxcdp:mo=rxotg-427;
rxasp:mo=rxotg-427;
allip:acl=a2;
Command summery for Resolving LOOP TEST FAILED alarm.
1st step fault diagnosis
allip:acl=a2;
rxtcp:moty=rxotg,cell=kt53541;
rxasp:mo=rxotg-427;
rxmsp:mo=rxotrx-427-1,subord;
2nd step fault resolution (Troubleshoot)
rxbli:mo=RXOTS-427-1-0;
rxlti:mo=RXOTS-427-1-0;
rxtei:mo=RXOTS-427-1-0;
rxble:mo=RXOTS-427-1-0;
3rd step fault salvation check after resolution
rxmsp:mo=rxotrx-427-1,subord;

rxcdp:mo=rxotg-427;
rxasp:mo=rxotg-427;
allip:acl=a2;

TS SYNC FAULT
What is TS SYNC FAULT ?

Its is TS/TRC(Transcoder)/Transcoder and Rate Adaptation Unit (TRAU) channels related alarm, Every sing
TRX having 8 TS (Time Slot) and Always all TS are synchronizing with Transcoder device using TRAU frame
So Particular TS is not performing Synchronization with Transcoder device via TRAU channels. This alarm
classified as a Major alarm (Alarm class: A2)
What is the Impact ?

It is minor service impact alarm as that particular TS having failed to Sync with Transcoder. Means that th
TS is unable to carry traffic. Remember A single TS can handle a single subscriber. If you get more TS Sy
Fault alarms then the number of TCH (Traffic Channel) will be blocked. From RLCRP command you can get
see the blocking TCH.
What is the reason for raising this alarm ?

Whenever a TS in the BTS detects loss of communication with the remotely located Transcoder. The
synchronization has been lost on the uplink or downlink Transcoder and Rate Adaptation Unit (TRAU
channels. And for this reason TS SYNC FAULT alarm is issued by TS.
How to analysis this problems ?
By running this command you will get the all major alarms of all sites. Find out TS SYNC FAULT alarm.
allip:acl=a2;
You can get this alarm by giving bellow two commands also.
For Getting TG from CELL, Here cell id is dh00051!
rxtcp:moty=rxotg,cell=dh00051;
For getting MO fault on TG-37, TG-37 belongs to dh00051!
rxasp:mo=rxotg-37;

For checking the MO(TRX-37-5) status to identify which TS is facing problem, here RXOTS-37-5-5
value 2000. it indicates TS having faults. Need to troubleshoot.

LM

rxmsp:mo=rxotrx-37-5,subord;

Give following command to check the Abis path whether the DCP value and Devices are in right or wron
mapped. Abis path should be mapped in correct order. And it is showing Abis path mapped in correct order.
rxapp:mo=rxotg-37;

Give following command for getting the device number from TS. Here RXOTS-37-5-5 is allocated for th
device RBLT2-1200.
rxmdp:mo=RXOTS-37-5-5;

Give this command in order to find the other time slots that mapped on that particular device (RBLT2-1200
In the print out here I am seeing another 3 TS in deferent TRX is also allocated with the device (RBLT
1200). Means that I have to troubleshoot on that 4 TS along with the device also. TS are RXOTS-375,RXOTS-37-5-6,RBLT2-1200,RXOTS-37-6-5, and RXOTS-37-7-5.
rxmdp:moty=rxots,dev=RBLT2-1200;
How to Solve the Problem ?
Give following commands to block and out of service that 4 TS which is belongs to RBLT2-1200.
rxbli:mo=RXOTS-37-5-5; ! To block the TS
rxese:mo=RXOTS-37-5-5; ! To out of service the TS
rxbli:mo=RXOTS-37-5-6;
rxese:mo=RXOTS-37-5-6;
rxbli:mo=RXOTS-37-6-5;
rxese:mo=RXOTS-37-6-5;
rxbli:mo=RXOTS-37-7-5;
rxese:mo=RXOTS-37-7-5;

For checking again is there any TS belongs to the device RBLT2-1200.showing none as all TS are already ke
in MBL state.
rxmdp:moty=rxots,dev=RBLT2-1200;

Give following command to bock the device (RBLT2-1200).

blodi:dev=RBLT2-1200;
Give following command to make the device (RBLT2-1200) out of service.
exdae:dev=RBLT2-1200;
Give following commands to deblock and in service that 4 TS which is belongs to RBLT2-1200.
rxesi:mo=RXOTS-37-5-5; ! To in service the TS!
rxble:mo=RXOTS-37-5-5; ! To deblock the TS !
rxesi:mo=RXOTS-37-5-6;
rxble:mo=RXOTS-37-5-6;
rxesi:mo=RXOTS-37-6-5;
rxble:mo=RXOTS-37-6-5;
rxesi:mo=RXOTS-37-7-5;
rxble:mo=RXOTS-37-7-5;
Lastly give following two commands to make the device (RBLT2-1200) in service.
For in service the device (RBLT2-1200)
exdai:dev=RBLT2-1200;
For debock the device (RBLT2-1200).
blode:dev=RBLT2-1200;

Now you can run following commands to check the problem is still persisting or not. As per the print out n
problem is persisting.
rxasp:mo=rxotg-37;
rxmsp:mo=rxotrx-37-5,subord;
allip:acl=a2;
Command summery for Resolving TS SYNC FAULT alarm.
1st step fault diagnosis
allip:acl=a2;
rxtcp:moty=rxotg,cell=dh00051;

rxmsp:mo=rxotrx-37-5,subord;
rxasp:mo=rxotg-37;
rxapp:mo=rxotg-37;
rxmdp:mo=RXOTS-37-5-5;
rxmdp:moty=rxots,dev=RBLT2-1200;
2nd step fault resolution (Troubleshoot)
rxbli:mo=RXOTS-37-5-5; !To block the TS!
rxese:mo=RXOTS-37-5-5; !To make the TS out of service!
rxbli:mo=RXOTS-37-5-6;
rxese:mo=RXOTS-37-5-6;
rxbli:mo=RXOTS-37-6-5;
rxese:mo=RXOTS-37-6-5;
rxbli:mo=RXOTS-37-7-5;
rxese:mo=RXOTS-37-7-5;
blodi:dev=RBLT2-1200;
exdae:dev=RBLT2-1200;

!To block the Device!

!To make the Device out of service!

rxesi:mo=RXOTS-37-5-5; !To make TS in service!

rxble:mo=RXOTS-37-5-5; !To deblock the TS!
rxesi:mo=RXOTS-37-5-6;
rxble:mo=RXOTS-37-5-6;
rxesi:mo=RXOTS-37-6-5;
rxble:mo=RXOTS-37-6-5;
rxesi:mo=RXOTS-37-7-5;
rxble:mo=RXOTS-37-7-5;
exdai:dev=RBLT2-1200; !To make the Device in service !
blode:dev=RBLT2-1200; !To deblock the Device !
3rd step fault salvation check after resolution
rxmsp:mo=rxotrx-427-1,subord;

rxcdp:mo=rxotg-427;
rxasp:mo=rxotg-427;
allip:acl=a2;

ABIS PATH UNAVAILABLE

What is ABIS PATH UNAVAILABLE?

It is TS related alarm, one TRX contains 8 TS (Time Slot) and all TS are using device. So Particular TS is n
getting ABIS path or device. This alarm is classified as a Major alarm (Alarm class: A2)
What is the Impact?

It is minor service impact alarm as the EDGE users on that particular site will not be able to use intern
properly. The EDGE users might get interruption to access internet.
What is the reason for raising this alarm?
There is no more 64K transmission devices exists between the BSC and RBS
Here on the ABIS path there is only two 64K devices is reserved for the EDGE.

Where minimum three devices is needed to reserve for EDGE as every BRS contains Three cells. Also no
that it is actually depending on operator initial EDGE configuration, but the normal sense is like that if th
EDGE users are increased on that particular site. At the same time the amount of EDGE capable devises m
have to be increased also.
How to analysis this problems?

By running this command you will get the all major alarms of all sites. Find out ABIS PATH UNAVAILABL
alarm.
allip:acl=a2;
You can get this alarm by giving bellow two commands also.
For Getting TG from CELL, Here cell id is DH03271.
rxtcp:moty=rxotg,cell=dh03271;
For getting MO fault on TG-119, TG-119 belongs to DH03271.
rxasp:mo=rxotg-119;

For checking Configuration data of TG-119.here RXOTS-119-10-2 showing SELECT.

it means problematic TS.
rxcdp:mo=rxotg-119;

For checking whether the CELL is GPRS Supported or not, and showing GPRS Enable, I have taken print o
for 3rd cell because the alarm found in TRX-119-10 which is belongs to 3 rd CELL.
rlgsp:cell=dh03273;

For checking ABIS path on TG-119, it is showing how many Device is attached with TG-119.Total 31 devis
are attached with the TG-119.among them 25 devices are used for SPEECH/DATA, 2 Devices are reserve
for EDGE. And 4 devices are in idle state. Here 64K (=YES) means it is reserved only for EDGE.
rxapp:mo=rxotg-119;
How to Solve the Problem?

Earlier I told minimum 3 devices are required for resolving this problem. From RXAPP printout tells me that
devices (64k YES) are already reserved for EDGE. And one more EDGE supported device is required to sol
the problem. Then total EDGE supported device will be 3 for that particular RBS.

Now I have to work on idle devices as other devices are already used. From 4 idle devices I will take any on
that device I will be reserved for EDGE.
For example I am taking device RBLT2-3833, DCP value 25 as it is IDLE & UNDEF

This command is used to detach the DCP 25 from the TG-119.note that before attaching any device with ne
feature (like EDGE 64K) in TG-119. you have to detach it first.
RXAPE:MO=RXOTG-119,DCP=25;

For checking whether the DCP value 25 as well as the device RBLT2-3833 is removed or not from TG-11
notice that in the print out you will not get it.
rxapp:mo=rxotg-119;

Now run this command to attach the device (RBLT2-3833, DCP value 25) on TG-119 & also to reserve th
EDGE (RES64K).
RXAPI:MO=RXOTG-119,DEV=RBLT2-3833,DCP=25,RES64K;

For checking whether the DCP value 25 as well as the device RBLT2-3833 is attached or not in TG-11
Note that in the print out it is showing the device (RBLT2-3833, DCP 25 64k YES) is performing as EDG
device.
rxapp:mo=rxotg-119;
For checking the problem is still persisting of not. As per the print out no problem is persisting.
rxmsp:mo=rxotg-119,subord;
rxcdp:mo=rxotg-119;
rxasp:mo=rxotg-119;
allip:acl=a2;
Command summery for Resolving ABIS PATH UNAVAILABLE alarm.
1st step fault diagnosis
allip:acl=a2;
rxtcp:moty=rxotg,cell=dh03271;
rxasp:mo=rxotg-119;
rxcdp:mo=rxotg-119;
rlgsp:cell=dh03273;
rxapp:mo=rxotg-119;
2nd step fault resolution (Troubleshoot)
RXAPE:MO=RXOTG-119,DCP=25;
RXAPI:MO=RXOTG-119,DEV=RBLT2-3833,DCP=25,RES64K;
3rd step fault salvation check after resolution
rxapp:mo=rxotg-119;
rxmsp:mo=rxotg-119,subord;
rxcdp:mo=rxotg-119;
rxasp:mo=rxotg-119;
allip:acl=a2;

PERMANENT FAULT
What is PERMANENT FAULT?

It is TRX or TX/RX or TS related alarm, whenever this alarm generate in this four MOs, it goes down an
cant function properly. this alarm could be solved by doing normal troubleshooting ,This alarm is classified
a Major alarm (Alarm class: A2)
What is the Impact?
It is minor service impact alarm as that particular TRX having failed to carry Traffic.

Here one things need to remember if this alarm came in the TRX-0,TRX-4 or TRX-8 then the respecti
CELL of that TRX will go down as those three TRX are having BCCH data. As per configuration TRX-0
responsible for 1st CELL,TRX-4 for 2nd CELL and TRX-8 is for 3rd CELL. So whenever any type of alarms raise
by those three TRX should take immediate action on it other than CELL might go down.
What is the reason for raising this alarm ?

Without carrying traffic All MOs are doing own supervision all the times also. here own supervision is bein
performed automatically within the certain number of times or period to ensure the smooth operation .S
whenever any TRX,TX,RX or TS will be permanently blocked by own supervision and it goes from Enable stat
to FAIL state means that during its own supervision any Faults in those MOs have been occurred. An
respective MOs will be generating the PERMANENT FAULT Alarms.
How to analysis this problems?

By running this command you will get the all major alarms of all sites. Find out PERMANENT FAULT alarm.
allip:acl=a2;
You can get this alarm by giving bellow two commands also.
For Getting TG from CELL, Here cell id is dh01691
rxtcp:moty=rxotg,cell=dh01691;
For getting MO fault on TG-214, TG-214 belongs to dh01691
rxasp:mo=rxotg-214;

For checking the MO(RXOTRX-214-4) status to identify which TRX is facing problem, here RXOTRX-214-4
FAIL BLO
0001 003A
RES it indicates TRX having faults. And need to troubleshoot.
rxmsp:mo=RXOTRX-214-4,subord;

How to Solve the Problem?

By giving following 4 commands this problem can be solved
rxbli:mo=rxotrx-214-4,subord,force; ! Block the TRX-4
rxese:mo=rxotrx-214-4,subord; ! Out of service the TRX-4
rxesi:mo=rxotrx-214-4,subord;
rxble:mo=rxotrx-214-4,subord;

! Bring The TRX-4 in service

! Deblock the TRX-4

rxmsp:mo=rxotrx-214-4,subord; ! Checking the TRX-4 status

Now you can run following commands to check the problem is still persisting or not. As per the print out n
problem is persisting.
rxasp:mo=rxotg-214;
rxmsp:mo=rxotrx-214-4,subord;
allip:acl=a2;
Command summery for Resolving PERMANENT FAULT alarm.
1st step fault diagnosis
allip:acl=a2;
rxtcp:moty=rxotg,cell=dh01691;
rxasp:mo=rxotg-214;
rxmsp:mo=RXOTRX-214-4,subord;
2nd step fault resolution (Troubleshoot)
rxbli:mo=rxotrx-214-4,subord,force;
rxese:mo=rxotrx-214-4,subord;
rxesi:mo=rxotrx-214-4,subord;
rxble:mo=rxotrx-214-4,subord;
3rd step fault salvation check after resolution
rxasp:mo=rxotg-214;
rxmsp:mo=rxotrx-214-4,subord;
allip:acl=a2;

BTS INTERNAL

What is BTS INTERNAL?

It is TRX, TX or RX internal alarm. when there is a internal fault persist in the TRX that time the respecti
TRX will be generating BTS INTERNAL alarm and TRX went down for this alarm, most of time it can b
solved by doing normal troubleshooting This alarm is classified as a Major alarm (Alarm class: A2).
What is the Impact?
It is minor service impact alarm as that particular TRX having failed to carry Traffic.
What is the reason for raising this alarm?

When any TRX, TX or RX are being internally affected by some internal fault code that time TRX genera
BTS INTERNAL alarm.
How to analysis this problems?
For getting BTS INTERNAL alarm, run bellow command and find respective alarm
allip:acl=a2;
It will show like this
RXOTX-415-8

MCNR5444

BTS INTERNAL

By running bellow two commands you will get the BTS INTERNAL alarms also.
For Getting TG from CELL, Here cell id is NR54441
rxtcp:moty=rxotg,cell=NR54441;
For Getting Internal fault of the Site NR54441, here TG-415 belongs to NR54441
rxasp:mo=rxotg-415;
Bellow print out indicates BTS internally affected by TX-8
RXOTX-415-8
MCNR5444
BTS INT AFFECTED
For checking TRX status
rxmsp:mo=RXOTRX-415-8,subord;

Bellow print out indicates TX went blocking state

RXOTX-415-8 NOOP BLO
0002 0014 0140 DIS UNCONF
How to Solve the Problem?
This type of problem you can solve by giving following Four commands
rxbli:mo=RXOTRX-415-8,subord,force; !Block the TRX
rxese:mo=RXOTRX-415-8,subord; ! Out of Service the TRX
rxesi:mo=RXOTRX-415-8,subord; ! Inservice the TRX
rxble:mo=RXOTRX-415-8,subord; ! Deblock the TRX
Now you can run bellow commands to check the problem is still persisting or not.
rxmsp:mo=RXOTRX-415-8,subord;
rxasp:mo=rxotg-415;
allip:acl=a2;
Command summery for resolving BTS INTERNAL alarm.
1st step fault diagnosis
allip:acl=a2;
rxtcp:moty=rxotg,cell=NR54441;
rxasp:mo=rxotg-415;
rxmsp:mo=RXOTRX-415-8,subord;
2nd step fault resolution (Troubleshoot)
rxbli:mo=RXOTRX-415-8,subord,force;
rxese:mo=RXOTRX-415-8,subord;
rxesi:mo=RXOTRX-415-8,subord;
rxble:mo=RXOTRX-415-8,subord;
3rd step fault salvation check after resolution
rxmsp:mo=RXOTRX-415-8,subord;
rxasp:mo=rxotg-415;
allip:acl=a2;

TRX LOCAL MODE

What is Local mode?

It is CF or TRX hardware related alarm, If Local mode alarm is coming from a TRX then there is no contact
TRX with BTS means that not accessible from Remote end . This alarm is classified as a Major alarm (Alar
class: A2)
What is the Impact?

It is minor service impact alarm, a single TRX having 8 TS (Time slot) means that it can handle 8 subscriber
So whenever Local mode alarm came with any TRX then all TS within the TRX goes to blocking state an
unable to carry traffic.
What is the reason for raising this alarm?

When there is no contact or communication with DXU and TRX then the LOCAL MODE alarm will be issue
by the TRX. Also the LOCAL MODE alarm might come for Problematic TRX hardware.
How to analysis this problems?
By running this command you will get the all major alarms of all sites. Find out LOCAL MODE alarm.
allip:acl=a2;
Bellow print out indicates TRX having LOCAL MODE alarm.
RXOTRX-135-10

MRJP1807

LOCAL MODE

You can get this alarm by giving bellow two commands also.
For Getting TG from CELL, Here cell id is jp18071!
rxtcp:moty=rxotg,cell=jp18071;

For getting MO fault on TG-135, TG-135 belongs to jp18071!

rxasp:mo=rxotg-135;
Bellow print out indicates TRX having OML FAULT alarms
RXOTRX-135-10
MRJP1807
LOCAL MODE
RXOTRX-135-11
MRJP1807
LOCAL MODE
For checking the MO(TRX-135-10) status.

rxmsp:mo=RXOTRX-135-10,subord;
rxmsp:mo=RXOTRX-135-11,subord;
Bellow print out indicates TRX having faults. Need to hardware check.
RXOTRX-135-10 NOOP BLO
0440 008A
RES
RXOTRX-135-11 NOOP BLO
0440 008A
RES
How to Solve the Problem?

This type of problem you can solve by Remote OMT tools, before access to the site via Remote OMT you ha
to know the Node IP, port number, TG id and password, after giving all those properly you will be able
access to the site. in the menu bar there is a image (like Book, for read IDB) Just click on it, after readin
IDB all option will be appear, now go to DTRU option and find out TRX10 & TRX11,keep cursor on it after th
click left button & you will get to see Local to Remote just click on it. now go back to the WinFoil termin
for checking the status of TRX10 & TRX11.hope it will work.
After finish your job, you need to disconnect Remote OMT, so that others can use it.

If those TRX is not in-service, you need support with FME, raise TT and escalate it to FME as physical DTR
reset is required, there are few way it can be done like bellow as example
1st Step:
DTRU hard reset (There is a push/pull button, just push and release)
2nd Step:

DTRU power reset (There is a power switch button in IDM, make it OFF and wait some time after resettin
power then turn it ON)
3rd Step:

Pullout DTRU from cabinet & insert it again (Respective power switch turn OFF is required before pullout th
DTRU)
4th Step:
If the DTRU is not coming into service by doing above procedure then try to swap

with other DTRU which is working well. if the same type of problem is still persisting means that DTR
hardware is faulty and change is required. So change the DTRU with new one.

Please remember that to avoid outage dont try to swap with 1st, 3rd & 5th DTRU as this three DTRU a
carrying BCCH data.
Following hardware FME can also check:
1) Check cable connection Y-link cable of those TRX (faulty cable or faulty port).
2) Check CXU, DXU, ECU, Local Bus, TRU backplane etc.
3) Check Power related issue like TRX power supply unite PSU, IDM, BFU, earthing connection
Now you can run following commands to check the problem is still persisting or not.
rxasp:mo=rxotg-135;
rxmsp:mo= RXOTRX-135-10,subord;
rxmsp:mo= RXOTRX-135-11,subord;
allip:acl=a2;
Command summery for Resolving LOCAL MODE alarm.

Without giving soft reset command (Like to all MO or Abis path), There is no other such troubleshootin
command which can resolve the LOCAL MODE alarm in TRX. By giving soft reset it might come in to servi
but after some time the same type of problem again arise. As it is not permanent solution I would not like
mention the soft reset command in this topics .So it is highly recommended that the physical check
necessary to solve this type of problem.
1st step fault diagnosis
allip:acl=a2;
rxtcp:moty=rxotg,cell= jp18071;
rxasp:mo=rxotg-135;
rxmsp:mo= RXOTRX-135-10,subord;
rxmsp:mo= RXOTRX-135-11,subord;
2nd step fault resolution (Troubleshoot)

Without giving soft reset, There is no other troubleshooting command for Resolving the LOCAL MOD
alarm.
3rd step fault salvation check after resolution
After solving this problem by FME you can check the status of those TRX

rxmsp:mo= RXOTRX-135-10,subord;
rxmsp:mo= RXOTRX-135-11,subord;
rxcdp:mo=rxotg-135;
rxasp:mo=rxotg-135;
allip:acl=a2;

TRX OML FAULT

What is OML FAULT?

It is TRX hardware related alarm, Communication is not possible with the particular TRX which having OM
FAULT. As there is no communication with the TRX caused that all the time slots within the TRX will b
blocked. This alarm is classified as a Major alarm (Alarm class: A2)
What is the Impact?

It is minor service impact alarm, a single TRX having 8 TS (Time slot) means that it can handle 8 subscriber
So whenever any TRX went down at the same time TS within the TRX goes to blocking state and unable
carry traffic.
What is the reason for raising this alarm?

When there is no communication is possible with any TRX or if a fault is exists in the communications lin
between the BSC and RBS then the OML FAULT alarm will be issued by the TRX. Please also remember th
the OML FAULT alarm might come when DTRU have been physically removed from RBS but not remove
from IDB. So whenever FME or Project guys want to remove the TRX from RBS at the same time they shou
remove TRX from IDB also. otherwise the OML FAULT alarm will be remaining.
How to analysis this problems?
By running this command you will get the all major alarms of all sites. Find out OML FAULT alarm.
allip:acl=a2;
Bellow print out indicates TRX having OML FAULT alarms
RXOTRX-87-10
MCKL5239
OML FAULT
You can get this alarm by giving bellow two commands also.

For Getting TG from CELL, Here cell id is KL52391!

rxtcp:moty=rxotg,cell=KL52391;
For getting MO fault on TG-87, TG-87 belongs to KL52391!
rxasp:mo=rxotg-87;
Bellow print out indicates TRX having OML FAULT alarms
RXOTRX-87-10
MCKL5239
OML FAULT
RXOTRX-87-11
MCKL5239
OML FAULT
For checking the MO(TRX-87-10) status.
rxmsp:mo= RXOTRX-87-10,subord;
rxmsp:mo= RXOTRX-87-11,subord;
Bellow print out indicates TRX having faults. Need to hardware check.
RXOTRX-87-10 NOOP BLO
0040 0008
STA
RXOTRX-87-11 NOOP BLO
0040 0008
STA
How to Solve the Problem?

As it is TRX hardware related problem. please do not try to troubleshoot by giving block/deblock or out
service/in service command in the TRX. if you troubleshoot by running those 4 commands, its state will b
change from OML FAULT to LOCALE MODE .So for this case just raise TT to FME and tell FME to go
the site as physical DTRU reset is required, there are few way it can be done like bellow as example:
1st Step:
DTRU hard reset (There is a push/pull button, just push and release)
2nd Step:

DTRU power reset (There is a power switch button in IDM, make it OFF and wait some time after resettin
power then turn it ON)
3rd Step:

Pullout DTRU from cabinet & insert it again (Respective power switch turn OFF is required before pullout th
DTRU)

4th Step:
If the DTRU is not coming into service by doing above procedure then try to swap

with other DTRU which is working well. if the same type of problem is still persisting means that DTR
hardware is faulty and change is required. So change the DTRU with new one.

Please remember that to avoid outage dont try to swap with 1st, 3rd & 5th DTRU as this three DTRU a
carrying BCCH data.
Following hardware FME can also check:
1) Check cable connection Y-link cable of those TRX (faulty cable or faulty port).
2) Check CXU, DXU, ECU, Local Bus, TRU backplane etc.
3) Check Power related issue like TRX power supply unite PSU, IDM, BFU, earthing connection
Now you can run following commands to check the problem is still persisting or not.
rxasp:mo=rxotg-87;
rxmsp:mo= RXOTRX-87-10,subord;
rxmsp:mo= RXOTRX-87-11,subord;
allip:acl=a2;
Command summery for Resolving OML FAULT alarm.
There is no such troubleshooting command which can resolve the OML FAULT in TRX. As physical check
necessary to solve this type of problem. Actually it is an hardware related problem.
1st step fault diagnosis
allip:acl=a2;
rxtcp:moty=rxotg,cell=KL52391;
rxasp:mo=rxotg-87;
rxmsp:mo= RXOTRX-87-10,subord;
rxmsp:mo= RXOTRX-87-11,subord;
2nd step fault resolution (Troubleshoot)
There is no troubleshooting command for Resolving the OML FAULT alarm.

3rd step fault salvation check after resolution

After solving this problem by FME you can check the status of those TRX
rxmsp:mo= RXOTRX-87-10,subord;
rxmsp:mo= RXOTRX-87-11,subord;
rxcdp:mo=rxotg-87;
rxasp:mo=rxotg-87;
allip:acl=a2;

LOADFILE MISSING
What is LOADFILE MISSING?

It is CF internal alarm. Due to Load file Missing CF goes down and it will be generate internal fault code cla
2A 25 which is Software related alarm, for this alarm CF cant not function properly and as a results RB
became down. This alarm is classified as a Major alarm (Alarm class: A2)
What is the Impact?

It is major service impact alarm, Subscriber on that particular sites will get interruption to access th
network. So whenever LOADFILE MISSING alarm came with any Sites, all MOs within the Site goes
blocking state and unable to carry traffic.
What is the reason for raising this alarm?

By seeing this alarm It is very difficult to identify the root cause for raising this alarm, but here I am givin
there are few reasons that might caused the loadfile Missing alarm. Many times BTS software ge
corrupted, respective TG of that site gets hang. A lots of Bit Error Rate (BER) alarms in the Transmissio
path (in DIP). IDB can be corrupted during Transmission fluctuation (for this case Load the fresh IDB usin
Remote OMT software).DXU flash card faulty, or DXU got faulty due to power fluctuation or DXU intern
another faults.
How to analysis this problems?
By running bellow two commands you will get the Load file missing alarms.
For Getting TG from CELL, Here cell id is bo65281
rxtcp:moty=rxotg,cell=bo65281;

For Getting Internal fault code of the Site BO6528, here CF-293 belongs to BO6528
rxmfp:mo=rxocf-293;

Bellow print out indicates CF having Fault code 2A 25 (2A 25 means LOADFILE MISSING).From fault cod
decoder you can get the meaning of all MOs fault code. there are some Fault code decoder software or fau
code PDF are available in the KS Tools.
FAULT CODES CLASS 2A
25
How to Solve the Problem?
This type of problem you can solve by giving following single command
rxpli:mo=RXOTG-293,uc; ! Loading software unconditionally

Please note that dont apply this command for another CF related Problem like CF FAIL,CF resetting Or CF
blocking state for another reason. Run this command according to fault code only.
If you get hues error in the transmission path (DIP),then reset the respective DIP
for resetting DIP ,Please check DIP Quality Supervision Topic in this Documents.
If not works then raise TT and send FME to check the Transmission path, some other cable connectivity,
all are ok then check the DXU flash card, other than change the DXU
Now you can run following commands to check the problem is still persisting or not.
rxmfp:mo=rxocf-293;
rxmsp:mo=rxotg-293,subord;
Command summery for Resolving LOADFILE MISSING alarm.
1st step fault diagnosis
rxtcp:moty=rxotg,cell=bo65281;
rxmfp:mo=rxocf-293;
rxmsp:mo=rxotg-293,subord;
2nd step fault resolution (Troubleshoot)
rxpli:mo=RXOTG-293,uc;
3rd step fault salvation check after resolution
rxmfp:mo=rxocf-293;

rxmsp:mo=rxotg-293,subord;

LOADFAIL BTSREJ
What is LOADFAIL?

It is CF internal alarm. Due to DXU Loading fail CF goes down and it will be showing LOADFAIL BTSRE
means that CF unable to load the program to DXU as it is showing BTSREJ (or BTS Rejected the softwa
loading) which is Software related alarm, for this alarm CF cant function properly and as a results BTS we
down. This alarm is classified as a Major alarm (Alarm class: A2)
What is the Impact?

It is major service impact alarm, Subscriber on that particular sites will get interruption to access th
network. So whenever LOADFAIL alarm came with any Sites, all MOs within the Site goes to blocking sta
and unable to carry traffic.
What is the reason for raising this alarm?

By seeing this alarm It is very difficult to identify the exact reason for raising this alarm, but here I a
giving, there are few reasons that might caused the LOADFAIL alarm. Many times BTS software ge
corrupted, respective TG of that site gets hang. Huge Bit Error Rate (BER) alarms in the Transmission pat
(in DIP). IDB can be corrupted during Transmission fluctuation (for this case Load the fresh IDB usin
Remote OMT software).Problematic flash card as well as DXU or DXU flash card faulty, or DXU got faul
due to power fluctuation or DXU internal another faults.
How to analysis this problems?
By running bellow two commands you will get the LOADFAIL alarms.
For Getting TG from CELL, Here cell id is bh50051
rxtcp:moty=rxotg,cell=bh50051;
For Getting Internal fault of the Site bh50051, here CF-459 belongs to bh50051
rxmfp:mo=rxocf-459 ;
Bellow print out indicates CF loading fail due to loading rejected by BTS.
NOOP BLO
00000
LOADFAIL BTSREJ

How to Solve the Problem?

This type of problem you can solve by giving following two commands
rxmop:mo=rxotg-459; ! For getting Software version B4403R013J
rxmsc:mo=rxotg-459,swver=B4403R013J; ! Changing Software version

Please note that dont apply this command for another CF related Problem like CF FAIL,CF resetting Or CF
blocking state for another reason. Run this command according to CF fault code only.
If you get hues error in the transmission path (DIP),then reset the respective DIP
for resetting DIP ,Please check DIP Quality Supervision Topic in this Documents.
If not works then raise TT and send FME to check the Transmission path, some other cable connectivity,
all are ok then check the DXU flash card, other than change the DXU
Now you can run following commands to check the problem is still persisting or not.
rxmfp:mo=rxocf-459 ;
rxmsp:mo=rxotg-459,subord;
Command summery for Resolving LOADFAIL alarm.
1st step fault diagnosis
rxtcp:moty=rxotg,cell=bh50051;
rxmfp:mo=rxocf-459 ;
rxmsp:mo=rxotg-459,subord;
rxmop:mo=rxotg-459;
2nd step fault resolution (Troubleshoot)
rxmsc:mo=rxotg-459,swver=B4403R013J;
3rd step fault salvation check after resolution
rxmfp:mo=rxocf-459 ;
rxmsp:mo=rxotg-459,subord;

ODP FAULT

What is ODP FAULT?

It is ODP and supervision related alarm this alarm is known as DIGITAL PATH FAULT SUPERVISION ,most of time w
get Four type of ODP faults such as ERATE,RDI,LOF,LOS ,this type of ODP faults could be solved by doing norm
troubleshooting, This alarm is classified as a Major alarm (Alarm class: A2).
What is the Impact?
It is non service impact alarm, for this alarm ODP performance will be degrade.
What is the reason for raising this alarm?
Most of case when any fluctuation in the Transmission path are occurred, it caused
DIGITAL PATH FAULT SUPERVISION alarm.

How to analysis this problems?

For getting DIGITAL PATH FAULT SUPERVISION alarm, run bellow command and find out respective alarm
allip:acl=a2;
It will show like this
0ODP49
ERATE
0ODP45
RDI
0ODP479
LOF

100822 193100
100822 193100
100822 193100

dtstp:dip=all,state=abl; ! It will show all DIP status and which is ABL (Automatically Blocked)
0ODP49 MO
ABL
ERATE
0ODP45 MO
ABL
RDI
0ODP479 MO
ABL
LOF
How to Solve the Problem?
This type of problem you can solve by giving following two commands
dtbli:dip=0ODP49; ! ODP Block
dtble:dip=0ODP49; ! ODP Deblock
dtbli:dip=0ODP45;
dtble:dip=0ODP45;
dtbli:dip=0ODP479;

dtble:dip=0ODP479;
Now you can run bellow commands to check the problem is still persisting or not.
dtstp:dip=all,state=abl;
allip:acl=a2;
Command summery for resolving ODP FAULT alarm.
1st step fault diagnosis
allip:acl=a2;
dtstp:dip=all,state=abl;
2nd step fault resolution (Troubleshoot)
dtbli:dip=0ODP49;
dtble:dip=0ODP49;
3rd step fault salvation check after resolution
dtstp:dip=all,state=abl;
allip:acl=a2;

ADD TRX
Initiate TRX or TRX define
DCP1=268, The digital connection point (DCP), DCP1 268 is used for signaling.
DCP2=269&&276, DCP2 from 269 to 276 this 8 DCPs are used for speech and data traffic.

TEI=10, Terminal endpoint identifier (TEI), TEI value will be same as TRX id, Here TRX-10 so TEI value w
be 10.and same for TRX-11 or TEI=11.
SIG=CONC,
Here Signalling type will be LAPD Concentration.
RXMOI:MO=RXOTRX-248-10,DCP1=268,DCP2=269&&276,TEI=10,SIG=CONC;
RXMOI:MO=RXOTRX-248-11,DCP1=277,DCP2=278&&285,TEI=11,SIG=CONC;
CELL Attach with TRX-10, TRX-11
Attaching
CELL JS51063 with TRX-248-10 and TRX-248-11. Now both TRX are set to the CELL JS51063.
RXMOC:MO=RXOTRX-248-10,CELL=JS51063;
RXMOC:MO=RXOTRX-248-11,CELL=JS51063;

Initiate TX or TX define
The
TX supports the GSM 1800 frequency band and the TX output power is 45 dBm.
RXMOI:MO=RXOTX-248-10,BAND=GSM1800,MPWR=45;
RXMOI:MO=RXOTX-248-11,BAND=GSM1800,MPWR=45;
CELL Attach with TX-10, TX-11
Attaching
CELL JS51063 with TX-248-10 and TX-248-11.now both TX are set to the CELL JS51063.
RXMOC:MO=RXOTX-248-10,CELL=JS51063;
RXMOC:MO=RXOTX-248-11,CELL=JS51063;
Initiate RX or RX define

The RX supports the GSM 1800 frequency band and the RXD=Receiver diversity AB Receiver diversi
employed
using antennas A and B.
RXMOI:MO=RXORX-248-10,BAND=GSM1800,RXD=AB;
RXMOI:MO=RXORX-248-11,BAND=GSM1800,RXD=AB;
Initiate TS or defines TS
TS-0
to TS-7 MOs in the TRX-10 & TRX-11
RXMOI:MO=RXOTS-248-10-0&&-7;
RXMOI:MO=RXOTS-248-11-0&&-7;
Bring the TRX-10 and TRX-11 in-Service
rxesi:mo=RXOTRX-248-10,subord;
rxesi:mo=RXOTRX-248-11,subord;
Deblock the TRX-10,TRX-11
rxble:mo=RXOTRX-248-10,subord;
rxble:mo=RXOTRX-248-11,subord;
Check the TRX Status
rxmsp:mo=RXOTRX-248-10,subord;
rxmsp:mo=RXOTRX-248-11,subord;

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log

BACK TO RBS ALARMS

Go to Print out or log