White Paper:

Debug guide for CTU and CTU2 radios exhibiting high interference on idle (IOI)

Abstract The purpose of this document is to provide the local office and customer with a guide to trouble shooting and analyze high IOI issues on CTU2s and CTUs.

Julien Drouet and Justin Annes November 23, 2004 - Version 2.0

BTS Center of Excellence Global Telecom Solutions Sector Motorola, Inc

Debug guide for CTU and CTU2 radios exhibiting high IOI

Revision History
Date 23 Nov 2004 26 Jan 2005 Version 1.0 2.0 Issued By J. Drouet J. Annes J. Drouet
Miscellaneous updates Original

Changes

References
Ref. 1 Version
V8.15.0 (2002-06)

Issued By
3GPP ESTI 5.08

Title
3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Radio subsystem link control (Release 1999) Maintenance Information GSM Statistics Application Service Manual Horizonmacro outdoor Category 523 Maintenance Information (Maint.) Chapter 3 - FRU replacement procedures Service Manual: Horizon II macro Chapter 7: FRU replacement procedures

2 3

GSR6 (HII) 02 May 2003 68P02902W02-A

68P02901W56-M GSD Documentation

68P02902W96 B

GSD Documentation

Signoff History
This section shall include signoffs following document review. Title/Position Senior Resource Manager Name R. Scott Swenson
RE IOI white paper RSS.msg

Approval (Email or signature)

Engineering Manager

Himanshu Desai
RE IOI white paper HMD .msg

Page 2 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

Table of Contents
1. 2. 3. 4. Overview ................................................................................................................ 4 Description of the interference on idle statistic ....................................................... 5 Possible sources for high IOI ................................................................................. 6 Data and information to be gathered ...................................................................... 8 4.1. General information.......................................................................................... 8 4.2. TEST #1: Calibration issue............................................................................... 9 4.3. TEST #2: Environment issue.......................................................................... 14 4.4. TEST #4: Cabinet/Cabling issue .................................................................... 17 4.5. TEST #3: Radio HW issue.............................................................................. 19 APPENDIX .................................................................................................................... 21

Page 3 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

1. Overview
Interference on idle (IOI) is usually monitored by customers to ensure optimal performance of the network. This document is going to provide customers or local offices an analytical and systemic method to identify the possible root cause of high IOI as well as giving them an understanding of what IOI is. Scope of the problem It is important to understand the extent of a high IOI problem if any by identifying if the problem is isolated to a single radio (RTF) or if the problem is present on all the radios of the site: If the problem exists only on one radio, customers can try to change the configuration of the site (e.g. move the RTF of the high IOI radio to another radio) and determine if the problem followed the RTF or stayed on the radio. If the problem exists on all or multiple radios in the site, then focusing on the cabinets cables, the SURF, and the environment should be the first stage of the investigation. Recalibration of the high IOI radios Calibrating the radio exhibiting the problem can quickly resolve the problem since invalid/inaccurate calibration has been identified as a recurrent issue on customers networks. Presence of interference in the natural environment Sometimes, a poor cell planning or the presence of other equipment nearby, transmitting at the same frequency of our GSM receiver, can result in the addition of an undesired interferencing signal. Tools are available to scan the radios environment and check if the natural environment sources the high IOI. Interference due to our equipment or software Once the extent of the problem is known and the two issues described above have been rejected (namely invalid/inaccurate calibration, and the presence of interference in the natural environment), it is important to analyze each HW part of the sites received path and the way the software is used to understand where the problem could originate. The remaining sections of this document will describe in detail how to proceed with the high IOI investigation and will provide tools and tips to root cause a high IOI issue.

Page 4 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

2. Description of the interference on idle statistic

As required in ETSI 05.08 [REF 1], one task of the BSS is to generate raw statistics for reporting network performance. The OMC-R processes these raw statistics to create custom statistics. One of these statistics is the interference on idle. This measurement is known at the OMC as INTF_ON_IDLE [REF 2]. Interference on idle (IOI) is aimed at providing an indication of the receiver noise floor. In order to optimize the receiver performance, one has to make sure that no significant interferences are added to the desired signal. If an undesired signal is added to the one coming from the mobile, the quality of the received signal (hence of the phone calls) may be degraded. The OMC INTF_ON_IDLE metric is a statistic derived on a timeslot basis and represents the average of DRIs received power (RXLEV) when there is no call being processed on the timeslots. When there is a phone call the RXLEV is reported as part of the measurement report (see graph below).

The IOI measurement is given by the INTF_ON_IDLE statistic which can take the values defined in the table below: Signal level RXLEV or IOI values dBm Level 0 Less than -110 dBm 1 -110 dBm to -109 dBm 2 -109 dBm to -108 dBm 62 -49 dBm to -48 dBm 63 Greater than -48 dBm

Page 5 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

IOI acceptable limit: There is not a hard limit to what is acceptable for IOI. To determine if one radio exhibits high IOI, you need to compare the IOI on this radio to the others on the site. You also need to talk to the team that deployed the network originally to make sure that the IOI value you are getting now is much higher/different than/from that which is be expected. Note that it is totally acceptable to have IOI values varying throughout the day since there will most likely be more interferences in the natural environment during peak hours of the day than during non-peak hours.

3. Possible sources for high IOI

There are four different possible known sources of high IOI: 1. Presence of interference in the natural environment: o Some communication equipment can be transmitting on the same frequency as our GSM receiver. o Some communication equipments can be transmitting on other frequencies but can have a poor pass band filter, hence letting some power through in the receive band of our GSM receiver. o The cell planning could have been poorly done or have changed and another cell close to the one exhibiting high IOI can be transmitting at the same frequency. 2. HW problem with the DRI: A hardware (HW) component of the transceiver (CTU or CTU2) could have failed which results in abnormal noise in the transceiver. 3. HW/Connection problem with the cabinet slot/cabling/antenna: An element in the receive path may have failed, or may not be used/ installed correctly: backplane, cabling 4. SW/FW error and/or the way SW/FW are configured & used: The version of the code being used may have a SW/FW issue that has not been identified yet. Further investigation by local offices and development teams would be needed. In this document, we will describe how to identify if the high IOI problem falls in one of these four categories. Your investigation will follow the flowchart below.

Page 6 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

Flowchart #1: CTU & CTU2 Interference-on-Idle (IOI) Troubleshooting Action Flow

High IOI detected? - Contact the network optimization team and/or - Modify the frequencies to be used on this sector

Yes
Section 4.1: Gather generic configuration information on the radio and the site. Calibrate the radio and monitor IOI again information

Yes

TEST #1 Section 4.2: Is the calibration data accurate?

No
Return or fix the faulty equipment and monitor the IOI again

Yes

TEST #2 Section 4.3: Is the problem due to the environment?

No

No

TEST #3 Section 4.4: Is there a HW failure other than the radio?

Yes

No

TEST #4 Section 4.5: Is the problem due to the radio

Yes

FURTHER INVESTIGATION: - Check to see if an SR already exits for this issue, if so then follow or update - Open an SR (provide a description of the problem and attach the logs you gathered during your investigation) AND -Contact the network optimization team

Page 7 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

4. Data and information to be gathered

WARNING: Throughout this procedure, keep logs of all MMI commands and all the results of your tests.

4.1. General information

In this section, we want to have a snapshoot of: the radios state and configuration, and the sites performance.

Please answer the following questions below before you change anything in the site: How many radios/sectors are affected? What type of radio is affected (CTU, CTU2, both)? What type of cabinet is/are the radio(s) in (InCell, MCell, Horiaon, Horizon2)? For all radios of the site, get OMC INTF_ON_IDLE statistic. Did the problem start after an upgrade, a cell replanning, or HW change? Have you checked with LO for known IOI issues? Is there a RX amplifier? Run the following commands for the site at the MMI-RAM:

disp_proc 0 disp_proc <site number> state <site number> disp_cell_status <site number> disp_gsm_cell <site #> disp_hop <site #> disp_hop <cell_number> active state <site #> rtf * * disp_neighbor <cell id> disp_act_alarm <site number> disp_version Run (at the MMI-RAM) the following commands for ALL DRIs/RTFs that of the site: disp_rtf_chan <site> <RTF id 0> <RTF id 1> disp_eq <site number> rtf <RTF id 0> <RTF id 1>
Page 8 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

disp_eq <site_number> dri * * full disp_eq <site number> dri <DRI id 0> <DRI id 1> full disp_cal_data <site_number> dri <DRI id 0> <DRI id 1> Connect to the GPROC emon and type the object and swfm read all command. Connect to the MCU emon and type the object and swfm read all command. Connect to the RSS emon and type the object and swfm read all command. Provide a map showing the special organization of the site under investigation with respect to its neighbors and specify the frequencies being used.

4.2. TEST #1: Calibration issue

In this section, we will verify that the calibration data is valid for the antenna and branch(es) being used. (Note: It is recommended to calibrate all antennas but in some cases, only the antenna being used is calibrated by the customer).

4.2.1. Verification that the calibration data is valid

Verification that the calibration data is valid: (a) CTU radio At the EQCP MMI prompt, enter the following commands:
EQCP TEST > calchk EQCP TEST > RX Branch 1: AIC AGC BAY BBG DCO FREQ IFG RSSI TX DET PWR TX VVA CAL YES YES YES YES YES YES YES YES CAL YES YES YES YES CHECKSUM RX Branch 2: CAL CHECKSUM 0001 AIC YES 0007 d3f0 AGC YES b845 7f3b BAY YES 7f3b 002a (This is for both branches.) 3ef0 DCO YES 169b ffe3 FREQ YES fe21 0006 IFG YES 0005 a19a RSSI YES a0ce CHECKSUM 5865 04a2 0000 a3c7

Page 9 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

Verify that the "CAL" values for the row titled BAY is "YES". If there is a NO, then the result for TEST #1 is NO and you should recalibrate the radio and monitor the IOI again. If you wish to monitor the IOI in real time from the site, please refer to Section 4.5, Steps (6), (7), and (8) of this document. Otherwise run section 4.2.2. below. (b) CTU2 radio

At the DSP MMI prompt, run the following commands:

CTU2.carA.ts_0>chg Enter Password: pizza Access Level 3 Granted CTU2.carA.ts_0>cal_status tall Cal Ca Br Status Result Valid Checksum Ver S/HC --------------------------------------------------------------------RF Lop A 0 pass valid 0x0672d5b5 1 / 1 RF Lop B 0 pass valid 0x0d7b5025 1 / 1 RX RF A 0 pass valid 0x2ae0b9fc 1 / 1 RX RF A 1 pass valid 0x2bb91f4a 1 / 1 RX RF B 0 pass valid 0x2c1ed905 1 / 1 RX RF B 1 pass valid 0x2b063b6b 1 / 1 RX IF A 0 pass valid 0xc8bc3caf 1 / 1 RX IF A 1 pass valid 0xc8d99f37 1 / 1 RX IF B 0 pass valid 0xc8dadb3f 1 / 1 RX IF B 1 pass valid 0xc8bfbd0a 1 / 1 RX FR A 0 pass valid 0xa8fe3af6 1 / 1 RX FR A 1 pass valid 0xa8e8ba39 1 / 1 RX FR B 0 pass valid 0xa8fb5db7 1 / 1 RX FR B 1 pass valid 0xa8f593e0 1 / 1 RX CAB A 0 pass valid 0x53703256 0 / 1 RX CAB B 0 pass valid 0x45562835 0 / 1 TX VVA A 0 pass valid 0xb0be7eb2 1 / 1 TX VVA B 0 pass valid 0x96686359 1 / 1 TX DSA A 0 pass valid 0x01a775df 1 / 1 TX DSA B 0 pass valid 0x01a7863a 1 / 1 TX FP A 0 pass valid 0x09e81286 1 / 1 TX FP B 0 pass valid 0x07c8ee22 1 / 1 TX Ver A 0 pass valid 0x064b1162 1 / 1 TX Ver B 0 pass valid 0x063b5e9a 1 / 1 TX CAB A 0 pass valid 0x019e2da9 1 / 1 TX CAB B 0 pass valid 0x01bd2da9 1 / 1 PA Det A 0 pass valid 0x15cc24be 1 / 1 PA Det B 0 pass valid 0xd7dc8932 1 / 1 PA VVA A 0 pass valid 0xda5d5f94 1 / 1

Page 10 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

Verify that the rows for the "RX CAB A" and RX CAB B values are pass and valid. If this is not the case, then the result for TEST #1 is NO and you should recalibrate the radio and monitor the IOI again. If you wish to monitor the IOI in real time from the site, please refer to Section 4.5, Steps (6), (7), and (8) of this document. Otherwise run section 4.2.2. below.

4.2.2. Recalibration of the radio

Re-calibrate the radio according to the procedure described in REF [3] (CTU) or REF[4] (CTU2) and then run the disp_cal_data <site_number> dri <DRI id 0> <DRI id 1> command at the MMI-RAM. Verify that the new calibration offsets are not too different from the initial ones you got in Section 4.1 for this radio. To do that, use the CheckRecalibration.xls excel spreadsheet that can be found at http://compass.mot.com/go/154713360 (If you do not have access to this web site, contact the local office in your country to provide this tool). (1) Select the radios frequency (850, 900, 1800, or 1900) (2) Copy and paste the initial and new values into the spreadsheet (3) Look at the differences between the initial and new data. If the difference for the antenna being used is more than 2 dB for most of the offsets, the result for TEST #1 is NO and you should monitor the IOI again with the new RX calibration offset values. Otherwise run section 4.2.3. below.

4.2.3. Manual verification

It is important to verify that the bay level offset is accurate. This procedure can be performed to manually identify an invalid offset as an invalid offset can cause IOI issues. WARNING: If the radio exhibiting high IOI is a CTU and the BCCH, then do NOT run this section and go to Section 4.3. For verification of the cabinet calibration follow the following procedure: (1) This procedure requires a signal generator to inject a RF signal into the antenna (ANT) port of the duplexer. Therefore radio must be taken out of service.
Page 11 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

At the RSS MMI prompt: MMI-RAM 1015 -> lock <site> pchn <dri0> <dri1> <ts_number> Example: MMI-RAM 1015 -> lock 52 pchn 0 0 6 This command must be entered for each time slot of each DRI connected to the duplexer. There should be no TX power into the duplexer. (2) Disconnect the antenna from the duplexer (3) Attach a good RF cable from the signal generator to the ANT port using appropriate adapters (4) Set the signal generator to a power level of -70dBm and the frequency of the desired RX channel to be measured. See appendix for a list of ARFCNs and corresponding frequencies. For this example we will use ARFCN 512 1710.2MHz (5) Log into the radio and set the ARFCN being measured. example it is 512. At the EQCP TTY ts a chan 512. (6) Now measure RXLEV. CTU2 use rxlev. (a) CTU Radio
EQCP > .gsmfw EQCP > test WARNING: The EQCP is now in test mode. EQCP TEST > ts a chan 512 EQCP TEST > The data for all timeslots has been changed. EQCP TEST > EQCP TEST > self cal rx_lev EQCP TEST >

For this

For CTU, use self cal rx_lev, and for

Power into radio: B1 Rx Lev: B2 Rx Lev:

(AIC is assumed out.)

-66.1049 dBm -105.4468 dBm

Power into cabinet: B1 Rx Lev: B2 Rx Lev: EQCP TEST > -71.4258 dBm -112.6094 dBm

(b)

CTU2 Radio

CTU2.carA.ts_0> CTU2.carA.ts_0>ch Enter Password: pizza Access Level 3 Granted

Page 12 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI CTU2.carA.ts_0>set_c cara Setting carrier to carrier A CTU2.carA.ts_0> CTU2.carA.ts_0>ts a chan 512 Name rx_synth_channel

TS 0 1 2 3 4 5 6 7 ------- -------- -------- -------- -------- -------- -------- -------- -------State OVRD OVRD OVRD OVRD OVRD OVRD OVRD OVRD OVRD 200 200 200 200 200 200 200 200 rt 21b 21b 21b 21b 21b 21b 21b 21b Decimal Equivalent OVRD 512 512 rt 539 539 Freq. 1710.2 1710.2 Name tx_synth_channel 512 539 1710.2 512 539 1710.2 512 539 1710.2 512 539 1710.2 512 539 1710.2 512 539 1710.2

TS 0 1 2 3 4 5 6 7 ------- -------- -------- -------- -------- -------- -------- -------- -------State OVRD OVRD OVRD OVRD OVRD OVRD OVRD OVRD OVRD 200 200 200 200 200 200 200 200 rt 21b 21b 21b 21b 21b 21b 21b 21b Decimal Equivalent OVRD 512 512 rt 539 539 Freq. 1805.2 1805.2 CTU2.carA.ts_0> CTU2.carA.ts_0>rxlev TS 0 512 539 1805.2 512 539 1805.2 512 539 1805.2 512 539 1805.2 512 539 1805.2 512 539 1805.2

------- -------Hex Dec dBm TS b9a1 47521 -70.371 0

------- -------Hex Dec dBm 8736 34614 -120.789

CTU2.carA.ts_0>

(7) The CTU command will report both the cabinet and the radio power measured. The CTU2 command will report only the cabinet power measured. The cabinet power reading should be -70dBm +/-4dB or between -66 to 74dBm. (8) If diversity is used, connect the signal generator to the appropriate diversity connection on the SURF or SURF2. Repeat the procedure to measure reported power on all utilized branches.

If the radio reads a value that is off by more than 4dB on the main or diversity path, then the result for TEST #1 is NO and you should monitor the IOI again with the new RX calibration offset values.
Page 13 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

4.3. TEST #2: Environment issue

In this section, we will check that there is not a signal in the radios environment at the frequency (or frequencies) which the radio is tuned to. There are two procedures to determine the result for TEST #2

4.3.1. Use of a spectrum analyzer

For this procedure, you will have to power down the whole sector for approximately 15 minutes (1) Using the output of the disp_gsm_cell <site #> command, get the list of frequencies the radio exhibiting high IOI uses. (2) Turn off all of the radios of the site. This procedure should take only 15 minutes, so the customer should not be inconvenienced too much. (3) Using the diversity path of the SURF or SURF2, connect the sector of interest to port 0B of the SURF/SURF 2. (4) Connect the spectrum analyzer to the expansion port B of the Surf/Surf 2. (5) Look for obvious spurs or humps in the noise floor on or near the center frequency, narrow the span to 1MHz to determine how close to on-channel the noise/spurs are.

Start with a wide bandwidth, this picture shows what a typical noisy site might look like.

Page 14 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

Set the bandwidth to 1MHz to see if the spur lands on the RX channel you are investigating. In this case, the interfere is just left of center. This picture shows interference on the desired frequency.

This is what a clean or ideal environment should look like. If you find spurs or humps on the frequencies being used by the radio then the answer to TEST #2 is YES. Otherwise, its NO.
Page 15 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

4.3.2. Use of a site survey tool

For this procedure, you will not have to power down the sector but you will have to lock all the timeslot 4 pchns for all the radios of the sector. You will have to run a radio MMI script that is intended to gather data about the site. It iterates through each channel and antenna and collects information about the RF environment by the radio. This is an Excel spreadsheet which extracts and installs a DLL. The spreadsheet has an application which will communicate with the radio via a serial comport. It is compatible with Windows 2000 or Windows XP. Before you go to the site, do the following: (1) Download the spreadsheet named SiteSurvey.xls. Everything you need is embedded in the spreadsheet. These files can be found at the following location: http://compass.mot.com/go/154713360 (If you do not have access to this web site, contact the local office in your country to provide this tool). (2) Open the spreadsheet. Click the Start button. It should display an error message but you want to make sure that you computer can run these scripts prior to going to the site. (3) Make sure you have the cables required to connect your computer to the EQCP TTY of the radio (which the script will ask you to do). On the site, do the following: (1) Using the output of the disp_gsm_cell <site #> command, get the list of frequencies the radio exhibiting high IOI was tuned to. (2) Lock the pchns for all timeslot 4 of the sector under investigation: MMI-RAM 1015 -> lock <site> pchn <dri0> <dri1> 4 Example: MMI-RAM 1015 -> lock 52 pchn 0 0 4 (3) Browse to the directory where you copied the spreadsheet, open it, fill in any appropriate information, and click Start. From this point on, the tool will guide the operator to enter in various pieces of information and to connect cables to the radio. (4) When the tool is finished running on that radio, it will produce a new sheet in the workbook with the data for that radio. A log file is also produced that will be at C:\Motorola_BTSCoE\Logs\. Run the excel script that can be found at http://compass.mot.com/go/154713360 on the newly created file and look at the frequencies the radio was tuned to see if a signal is present when there should be no mobile transmitting at that frequency(ies). If you see a signal

Page 16 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

at one of the frequencies the radio was tuned to, then the answer to TEST #2 is YES. Otherwise, its NO.

4.4. TEST #4: Cabinet/Cabling issue

In this section we will discuss the various items that could be broken or damaged on the cabinet. In many situations all that is required is a close inspection of the cabinet looking for damaged connectors and cables. There are three places to look to identify this type of failure: TX path, RX path and the combined TX/RX path. There are two other possibilities, though less likely, in which interference can be generated. These are after the duplexer combining and a bad SURF/SURF2. TX Path Lock the radio and power down. Inspect the short TX cable that goes from the CTU/CTU2 to the duplexer. Make sure there are no cuts or frays or places where it looks like the cable is coming apart. If there is damage replace the cable. If the short TX cable looks ok, remove the cable connecting the CTU/CTU2 to the duplexer. Inspect the center conductor on the cable, the CTU/2, and the duplexer. If there is damage to the cable or the cables center conductor is bent, replace the cable. If it looks like the CTU/CTU2 connector is damaged or loose, return the CTU/CTU2 for repair and note the damaged connector on the RMA. Inspect the duplexer center conductor and return if there is damage or if the connector is bent. Inspect any other cables that might be used in the TX path such as cables connected to combiners, add-on VSWR units, and external filters. RX Path Lock the radio and power down. Pull out the radio and inspect the connectors on the back of the radio for damage. Replace if damaged and make note of it on the RMA. Remove the RX cable, for the desired path, from the duplexer and SURF. Inspect the cable for damage and cuts. If it looks like the cable is breaking near the connector, it is bad. Replace this cable as necessary. Also inspect the NType connector on the SURF/SURF2 and the duplexer. Look closely at the center conductor to see if there is any damage. If one prong is bent or missing or if the prongs are spread far apart, then the connector is bad. Replace the unit and mark the reason on the RMA. If it is ok to take down the entire site, the SURF/SURF2 can be removed to inspect the SURF connectors. Again, look for any damage to this connector. Look closely to see if prongs are bent or missing and center conductor is ok.

Page 17 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

In some cases an external LNA is used before the duplexer to improve the sensitivity. If this is the case try removing the LNA for a period of time to see if the interference goes away. If an LNA is used, it is important to calibrate the cabinet with the LNA connected to account for the extra gain. RX/TX Path Remove the ANT connector from the duplexer. Inspect both the antenna feeder cable connector and the duplexer connector. Look closely for bent or missing pins/prongs. If there is damage replace either the cable or duplexer. External Combining, Filtering, Amplification Motorola certifies all equipment used on the cabinet to ensure that a minimum amount of interference exits. If add-on combining is used, it is important that (1) the part is rated to handle the power and (2) the part does not generate any additional interference. If interference is detected on a cabinet, and the problem does not appear to be related to the environment, then try removing any external components not supplied by Motorola for a period of time to see if the interference subsides. SURF/SURF2 It is possible but not likely that the SURF/SURF2 might generate interference in the form of an oscillation. There is no record of this type of occurrence but you can check it in two ways. 1. The SURF/SURF2 can be swapped with another SURF/SURF2 to see if the problem clears. This will require a cabinet TX and BAY RX offset calibration. If the interference clears by simply swapping the SURF then return the SURF/SURF2 for repair and note the failure on the RMA. If you have found a faulty cable, connector, equipment, etc. then the answer to TEST #4 is YES - replace the faulty part and re calibrate both the TX and BAY offsets. If no faulty equipment is found the answer to TEST #4 is NO, open an SR (provide a description of the problem and attach the logs you gathered during your investigation) AND Contact the network optimization team.

Page 18 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

4.5. TEST #3: Radio HW issue

In this section, we will check that there is no hardware problem with the radio itself. In order to determine the result for TEST #3, you need to: Before you go to the site, do the following: (1) Get a copy of the Perl script interpreter at the following location (download and install the latest ActivePerl Windows MSI package):
http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl

(2) Save the Perl script perl_ioi.pl located in http://compass.mot.com/go/154713360 into an new directory on your computer (If you do not have access to this web site, contact the local office in your country to provide this tool). (3) Test that the installation of the Perl script interpreter was done correctly before going to the site by using the test data file perl_ioi_test_data.txt located in http://compass.mot.com/go/154713360 (If you do not have access to this web site, contact the local office in your country to provide this tool). Save this file in the same directory as the Perl script. Launch a command window. CD to the directory you created and run the following command: perl_ioi.pl perl_ioi_test_data.txt > ioi_test_result.txt (4) Compare the new file generated ioi_test_result.txt with the results you should have gotten in perl_ioi_test_expected_result.txt. On the site, do the following: (1) Find a radio that exhibit high IOI and a radio that does not. (2) Check if the preserve bay level calibration feature is enabled on these radios: lock <site_number> dri <dri0> <dri1> disp_cal_data <site_number> dri <DRI id 0> <DRI id 1> If there is no data in the database then the preserve bay level calibration feature was not activated. If there is data then the preserve calibration feature was activated. (3) Turn off both radios and swap them. (4) If the preserve calibration data feature is not enabled on the site, then you need to recalibrate the two radios you have just swapped (see REF [3] (CTU) & [4] (CTU2)). Also make sure that the RTF are still assigned to the same DRI as they were prior to the swap. (5) If the preserve calibration data feature is enabled, just verify that the RTF are still assigned to the same DRI as they were prior to the swap. (6) Log to the RSS emon of this radio: rl <site_number+1> <processor_id>
Page 19 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

(7) Monitor the IOI values for the radio that was originally exhibiting high IOI values by running the following filter for 30 seconds: fil create src 50 dest 49 msg[0] 0c1h fil start all After 30 seconds, disable the filter using the following commands: fil stop all fil delete all (8) Then store the file with the filters outputs and run the Perl script perl_ioi.pl using the following command: perl_ioi.pl <capture_file_name> > output_file.txt (9) Re-run step (4) and (5) on the radio that was initially fine.

If you see that the high IOI problem follow the radio then the answer to TEST #3 is YES, otherwise it is NO.

Page 20 of 21

Debug guide for CTU and CTU2 radios exhibiting high IOI

APPENDIX
ARFCN to Frequency Calculation: The carrier spacing is 200 kHz. The carrier frequency is designated by the absolute radio frequency channel number (ARFCN). If we call Fl(n) the frequency value of the carrier ARFCN n in the lower band, and Fu(n) the corresponding frequency value in the upper band, we have: E-GSM DCS 1800 Fl(n) = 890 + 0.2*n Fl(n) = 890 + 0.2*(n-1024) Fl(n) = 1710.2 + 0.2*(n-512) 1 n 124 975 n 1023 512 n 885 Fu(n) = Fl(n) +45 Fu(n) = Fl(n) +95

Page 21 of 21