Professional Documents
Culture Documents
Ericsson Rbs Fault Rectification
Ericsson Rbs Fault Rectification
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)
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.
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.
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.
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;
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;
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)
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.
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.
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.
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-37-
5,RXOTS-37-5-6,RBLT2-1200,RXOTS-37-6-5, and RXOTS-37-7-5.
rxmdp:moty=rxots,dev=RBLT2-1200;
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 commands to deblock and in service that 4 TS which is belongs to RBLT2-1200.
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.
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;
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;
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;
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)
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.
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.
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 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;
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;
PERMANENT FAULT
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.
Without carrying traffic All MO’s 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 MO’s have been occurred. An
respective MO’s will be generating the “PERMANENT FAULT” Alarms.
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 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?
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;
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).
It is minor service impact alarm as that particular TRX having failed to carry Traffic.
When any TRX, TX or RX are being internally affected by some internal fault code that time TRX genera
“BTS INTERNAL” alarm.
For getting “BTS INTERNAL” alarm, run bellow command and find respective alarm
allip:acl=a2;
By running bellow two commands you will get the “BTS INTERNAL” alarms also.
For Getting Internal fault of the Site NR54441, here TG-415 belongs to NR54441
rxasp:mo=rxotg-415;
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
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;
rxesi:mo=RXOTRX-415-8,subord;
rxble:mo=RXOTRX-415-8,subord;
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)
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.
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.
By running this command you will get the all major alarms of all sites. Find out “LOCAL MODE” alarm.
allip:acl=a2;
You can get this alarm by giving bellow two commands also.
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
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 don’t try to swap with 1st, 3rd & 5th DTRU as this three DTRU a
carrying BCCH data.
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;
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.
allip:acl=a2;
rxtcp:moty=rxotg,cell= jp18071;
rxasp:mo=rxotg-135;
rxmsp:mo= RXOTRX-135-10,subord;
rxmsp:mo= RXOTRX-135-11,subord;
Without giving soft reset, There is no other troubleshooting command for Resolving the “LOCAL MOD
alarm.
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;
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)
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.
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.
By running this command you will get the all major alarms of all sites. Find out “OML 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 KL52391!
rxtcp:moty=rxotg,cell=KL52391;
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
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 don’t try to swap with 1st, 3rd & 5th DTRU as this three DTRU a
carrying BCCH data.
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;
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.
allip:acl=a2;
rxtcp:moty=rxotg,cell=KL52391;
rxasp:mo=rxotg-87;
rxmsp:mo= RXOTRX-87-10,subord;
rxmsp:mo= RXOTRX-87-11,subord;
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
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)
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 MO’s within the Site goes
blocking state and unable to carry traffic.
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.
By running bellow two commands you will get the Load file missing alarms.
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 MO’s fault code. there are some Fault code decoder software or fau
code PDF are available in the KS Tools.
FAULT CODES CLASS 2A
25
This type of problem you can solve by giving following single command
rxpli:mo=RXOTG-293,uc; ! Loading software unconditionally
Please note that don’t 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;
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 can’t function properly and as a results BTS we
down. This alarm is classified as a Major alarm (Alarm class: A2)
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 MO’s within the Site goes to blocking sta
and unable to carry traffic.
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.
By running bellow two commands you will get the “LOADFAIL” alarms.
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
Please note that don’t 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;
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).
It is non service impact alarm, for this alarm ODP performance will be degrade.
Most of case when any fluctuation in the Transmission path are occurred, it caused
DIGITAL PATH FAULT SUPERVISION alarm.
For getting “DIGITAL PATH FAULT SUPERVISION” alarm, run bellow command and find out respective alarm
allip:acl=a2;
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
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;
ADD TRX
RXMOI:MO=RXOTRX-248-11,DCP1=277,DCP2=278&&285,TEI=11,SIG=CONC;
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;
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;